1. 客户一句“要国产化”,把选型变成了两难
1.1 现场的真实需求
上个月一个做智能仓储改造的朋友找我,说他们正在替客户做产线升级,其中有一台老旧工控机要换掉。客户要求很明确:设备必须满足国产化要求,CPU不能再用进口产品,操作系统能跑现场原有的组态软件,还得在三个月内上线。他一开始挺乐观,觉得国产工控机现在多得是,随便选一台就行。结果打开选型页面一看,傻眼了:有基于国产X86的,有基于国产ARM的,价格差两倍还不止,功耗差好几倍,软件支持差别更大,到底选哪个心里完全没底。
他说了句特别扎心的话:“我关心的是现场那套PLC能不能通讯上、旧的组态工程能不能直接打开、设备到了现场高温环境下会不会死机。但所有厂家都在给我讲核数、主频、内存,没一个人告诉我这些。”
这可能就是当前工控机选型最大的问题:芯片参数看得见,但生态兼容、驱动支持、预期寿命、散热设计这些真正决定现场能不能跑起来的东西,反而没人说清楚。X86和ARM之间的选择,从来不是“谁性能强就买谁”的问题,而是你的现场软件环境、使用周期、维护团队技术栈甚至验收标准共同决定的综合决策。
1.2 两难的本质是什么
先放下具体品牌不谈,把两种架构的本质差异说清楚。
X86是复杂指令集架构,诞生于上世纪七十年代末,一路推进到今天,积累了半个世纪的软件生态。Windows、Linux、各种组态软件、工业通讯库、数据库、PLC编程工具,绝大多数原生就是给X86开发的。而国产X86,本质上是在X86指令集许可框架下自研芯片,指令集兼容,软件生态上的历史包袱和红利同时继承了下来。
ARM是精简指令集架构,最初为低功耗移动端设计,近十年才大举进入工业与边缘计算领域。它的优势是能效比高、芯片集成度高、成本低,最近几年很多带NPU的ARM芯片在边缘AI场景表现非常亮眼。但ARM平台的软件生态要薄很多,很多老的工控软件根本没有ARM版本,你在X86上双击就装的驱动、控件、运行库,到了ARM上可能连安装包都找不到。
所以这个两难的本质是:要稳定性与兼容性,X86更省心;要功耗与创新,ARM更有潜力。你的项目更在乎哪一头,决定了答案方向。选型不是芯片竞赛,是把自己的项目条件一项项摆出来跟平台的优劣势做匹配。下面我按两个平台分别展开讲,最后会给出可落地的评估表和配置单。
2. 国产X86工控机:坐拥兼容性的“稳重派”
2.1 能喊出国字号名的X86平台有哪些
市面上真正能在工控机里担纲“国产X86”的,主要是兆芯和海光两大系。兆芯的KX-6000系列、KX-7000系列是工控领域见到的比较多的一档,KX-U6780A八核2.7GHz、KX-6640MA四核,都有不少工控主板在做。海光更多偏服务器与高性能计算,工控整机里也有,但相对少一些,而且功耗普遍偏高,我这里重点讲兆芯。
另一个现实情况是,很多所谓“国产工控机”本质是Intel/AMD平台,只是组装厂在国内。这类机器符合“国产品牌”的一部分要求,但不符合“国产CPU”要求。如果客户的指标写的是“国产化率不低于多少”“关键部件自主可控”,那就必须上兆芯、飞腾这类真正国产芯片的整机。这个细节在招标阶段经常被忽略,等验货时才发现用错了平台,整个项目重来,我见过不止一次。
兆芯平台的工控主板,外形上和传统X86工控主板几乎一致:标准ITX或Micro-ATX版型,带PCIe x16插槽、PCI插槽、双千兆网口、多路串口和USB,很多还保留老式PS/2接口和并口。这种“长得像老主板”本身就是优势——意味着老机箱、老扩展卡、老外设可以直接迁移,机柜不用改。
2.2 兼容性到底能省多少事
国产X86最大的杀手锏是:它真的可以装Windows。这不是随便说说,而是整个软件兼容链路的起点。
我自己的经验里,至少一半的工控现场还在用组态王、力控、WinCC这些组态软件,或者是国外的iFIX、InTouch。这些软件大部分没有官方Linux版本,更没有ARM版本。只要你换到国产X86平台,安装包直接双击装,授权狗插上能用,老的组态工程文件原样打开。这是一个巨大的隐性成本节约——如果换ARM,意味着整套软件重新选型、重新组态、重新培训,人力成本轻松超过一台工控机的价格。
更关键的一层是硬件驱动和工业通讯库。很多PLC通讯卡、CAN卡、运动控制卡、数据采集卡,厂商只提供Windows驱动,甚至只提供特定版本的DLL和SDK。你在X86国产平台上,把这些DLL往SysWOW64目录一放,程序就能跑起来。到了ARM上,你得去问每一家板卡厂商“有没有aarch64的库”,答案大概率是没有。这不是一家两家的事,是整个产业链长期围绕X86+Windows发展形成的结果。
那有人问:国产X86跑Linux行不行?当然可以。兆芯平台装统信UOS、麒麟系统都很成熟,很多信创项目就是国产X86配国产Linux。这意味着国产X86可以把选择权留给用户——想要Windows兼容就装Windows,想要纯国产软硬件栈就装国产Linux,两边通吃。ARM平台在选择自由度上就窄得多。
2.3 性能与功耗的真实水平
谈到性能,需要冷静一下。兆芯KX-6000系列的单核性能大致相当于Intel第七代酷睿的水平,多核性能看具体型号,与当时主流X86有一定差距。KX-7000比KX-6000强不少,内存通道和PCIe版本也提上来了,但和同期Intel/AMD新平台比仍不是同一代产品。
这个差距对工控场景意味什么?做HMI、数据采集、远程监控、生产管理、简单视觉定位——完全够用。跑数据库、跑中等规模视觉检测、跑复杂运动控制算法——需要实际测试,不建议拍脑袋。功耗方面,KX-U6780A的TDP大概在60W上下,整机功耗随负载浮动比较明显,普通工控机箱需要内置风扇或较大面积的散热器,完全无风扇设计会有点吃力。
我这里有个真实对比数据供参考。我在同一个视觉检测项目里,先用一台Intel赛扬J6412工控机跑基于OpenCV的模板匹配,帧率稳定在28帧左右;换到兆芯KX-U6780A平台,经过同样的优化后帧率能到22帧左右;再换到瑞芯微RK3588平台,反而能到35帧以上,因为后者的四核A76单核性能并不弱,且支持NEON加速指令。这个例子说明:同价位的国产X86不一定比国产ARM全面占优,具体性能要落到你跑的负载类型上判断。
2.4 哪些项目优先考虑X86
结合我的经验,以下四类项目建议优先锁定国产X86:
你现场软件强依赖Windows生态。比如用了WinCC、组态王、老版LabVIEW,或者Visual Studio编的上位机程序,没有重写计划。
你有很多旧PCI/PCIe扩展卡要沿用。国产X86工控机的主板上,PCI插槽仍然很常见,这是ARM平台几乎不具备的能力。
你的维护团队只熟Windows和X86。工厂电工、设备工程师、IT支持人员都会处理Windows问题,但如果有台ARM工控机跑Linux,开机起不来可能都没人会排查。
你对性能上限有预期但不确定,希望保留后续上更高性能的余地。国产X86平台的高性能档位选择比ARM更多。
这几类并不是说ARM完全不能做,而是说在X86平台上,你的试错成本要低得多。项目工期紧、无法大规模重写软件、现场又要求国产化,X86往往是那个“不会错的选择”。
3. 国产ARM工控机:低功耗边缘场景的“机会派”
3.1 ARM平台的分布范围
国产ARM工控机的芯片来源比X86更丰富。飞腾是工控领域比较老牌的选择,FT-2000/4四核、D2000八核2.3GHz,在信创整机里出现频率很高。瑞芯微则是另一支生力军,RK3568四核、RK3588八核并带6TOPS NPU,成了这两年边缘AI工控机的主力平台,做边缘计算盒子、视觉检测一体机、数据采集网关的厂家非常多。华为鲲鹏处理器主要面向服务器场景,工控整机接触到的少一些,但如果项目本身依托鲲鹏的服务器生态,那么终端用同架构设备会更顺。
从产品形态上看,ARM工控机明显更“嵌入式”:板子小、无风扇、接口精简、支持宽温,往往只有几个串口和千兆网口,扩展性远不如X86工控主板。很多ARM整机箱体尺寸和一块砖头差不多,导轨安装或背板安装非常方便。这本来就是ARM的优势领域——你不可能在一条空间紧张的装配线上塞一台笨重的4U工控机,但一台巴掌大的ARM盒子可以有多种“塞”法。
3.2 性能功耗比与外设特色
ARM工控机最让人舒服的是功耗。建一个简单的现场设备监控网关,用RK3568,整板典型功耗5W左右,跑Linux和一个数据采集程序,加上一个4G模块待机,整机也就十几瓦。无风扇、无机械部件,意味着粉尘环境里不用担心风扇堵转导致过热,也少了一个寿命最短的故障点。对比X86平台的几十瓦功耗与风扇散热,这个差距在恶劣环境里是实打实的可靠性优势。
最近两年的ARM芯片集成了很多对工业场景有用的功能,这一点容易被忽略。RK3568/RK3588自带NPU,可以在边缘端做缺陷检测、读码、字符识别、人员安全帽检测等轻量AI,不用额外购买GPU或AI加速卡,整机成本可以压下来。飞腾D2000虽然没有NPU,但作为八核A64架构CPU,跑通用Linux服务和中等负载业务完全没问题,很多电力、交通领域的边缘节点就是它。
接口方面,ARM工控机普遍提供RS485/RS232、CAN、GPIO、双千兆网口,有些还带5G/WiFi/4G模块槽位。这个接口组合非常贴合数据采集、协议转换、物联网关这类场景。相比之下X86工控板的GPIO和CAN接口往往是选配或通过扩展卡实现,反而不如ARM整机来得直接。
3.3 别踩生态暗坑
ARM工控机的短板,前面提过一部分,这里展开说几个我在项目中真实踩过的坑,比参数表上写的任何数字都更有参考价值。
组态软件是个大坑。客户现场有两台设备需要通过Modbus TCP采集数据并显示到触摸屏和上位机,原方案是X86工控机上跑组态王。想降成本换ARM,一问:组态王没有ARM版,力控有Linux ARM版但需要单独授权、控件和驱动要重新适配,WinCC就别谈了。最后是改用Web组态方案,前端在浏览器显示,后端用Python在ARM上吃Modbus,整个工程重做,工期多花两周。如果当初一开始就知道这个结果,大概率不会选ARM。
工业相机SDK同样是高频暗坑。主流的海康、大华的相机SDK都有ARM Linux版本,能正常调用,但不少专业相机品牌、线扫相机、智能相机的SDK只提供Windows x64版。我做视觉项目前一定会先去厂商官网逐项核对“Linux aarch64”“Arm Linux”有没有下载链接,没有就直接排除ARM方案。别被“能用”骗了——有些厂商说支持ARM,但实际只有压缩包能解压,里面的示例代码编译就过不了,等你在现场发现这个问题,已经晚了。
驱动程序是第三层坑。像USB转串口芯片、特定采集卡、加密狗、某些通信模块的Linux驱动,在ARM架构下不一定有现成的内核模块。有些是内核版本太旧,比如某些RK3588开发板的BSP还停留在内核4.19,一些新款USB转串口芯片驱动需要自己编译或根本编译不过。还有些厂商官方只维护X86驱动,ARM下要靠社区或者自己动手解决。所有这些时间成本,都应该在选型之前算进去。
3.4 哪些项目适合ARM
总结下来,我一般建议以下几种情况优先考虑国产ARM:
- 边缘数据采集与协议转换:大量PLC、传感器、仪表的数据需要集中、转发,ARM盒子做Modbus网关、OPC UA边缘网关非常合适,低功耗、小体积、长寿命都是加分项。
- 边缘AI推理:目标检测、读码、OCR等轻量AI场景,ARM平台自带NPU,省掉了X86平台外接加速卡的成本和功耗。
- 无人值守与恶劣环境站点:野外通信站、变电站、车间角落、户外设备柜,无风扇无尘垢,ARM宽温设计更耐造。
- 全新项目、软件可自主开发:团队自己写程序和运维,没有历史Windows包袱,完全可以在Linux ARM生态下开发,成本低且维护灵活。
如果项目满足这些条件,ARM平台可以帮你在成本、功耗、体积上都拿到明显优势。反过来说,只要有老软件、老驱动、老外设或者Windows依赖,ARM的风险就会指数级上升,光“能不能跑起来”这一个问题就可能耗掉整个项目的利润。
4. 选型不能靠感觉:六维评估表与权重打分法
4.1 六个核心维度怎么量化
与其在那里纠结“X86好还是ARM好”,不如把需求拆开,一项项打分。我这些年做工控项目,逐渐形成了六个维度的评估框架:性能余量、软件生态兼容、功耗与散热、扩展性、供应链与国产化合规、总拥有成本。每个维度根据项目实际权重设分,最后算出总分大小,跟谁符合选谁。
下面这张表是我常用的评估维度与打分参考,你可以直接复制来当模板用:
| 评估维度 | 具体考察内容 | 打分标准(1-10) |
|---|---|---|
| 性能余量 | CPU单核/多核是否满足未来三到五年负载增长;是否有AI算力需求;内存扩展空间 | 8-10:游刃有余;5-7:主负载没问题,高并发或复杂函数有压力;1-4:明显吃紧 |
| 软件生态兼容 | 现有软件、中间件、驱动、SDK有无对应版本;是否可不用重写代码 | 8-10:全兼容,装完即用;5-7:部分兼容,需适配;1-4:基本不兼容 |
| 功耗与散热 | 现场环境温度、是否密闭、有无散热条件;整机功耗是否有上限 | 8-10:无风扇稳定运行;5-7:小风扇或加强散热即可;1-4:需要主动冷却,环境苛刻 |
| 扩展性 | 是否需要PCIe/PCI插卡、多串口、CAN、GPIO、显示器数量 | 8-10:接口和插槽充足且有冗余;5-7:基本够用但余量小;1-4:需要取舍或转接 |
| 供应链与合规 | 国产化率要求、指定CPU列表、操作系统认证、供货周期 | 8-10:在目录内无风险;5-7:可替代但需证明;1-4:可能不满足投标要求 |
| 总拥有成本 | 含整机价、软件重开发成本、维护成本和培训成本 | 8-10:低于预算;5-7:接近预算;1-4:明显超支 |
关键点是:一定要先跟客户确认“国产化”的具体定义。是指CPU必须国产,还是整机品牌国产即可?有没有指定的目录清单?要不要过检测认证?很多项目在这个环节栽过跟头:客户口头说要国产化,最后验收却要求CPU在特定目录里,而项目组已经按普通品牌机采购了,只能退货重来。
4.2 权重打分实际怎么用
假设一个项目是这样的:产线HMI监控,现场已有组态王工程,机柜空间紧张,环境粉尘较多,后期想加一个读码视觉检测。那我们给各项分配权重时可以这样处理:软件生态兼容权重最高(0.3),因为组态王那是硬门槛;性能余量权重0.2,因为要预留视觉检测;功耗散热0.2,因为粉尘环境无风扇很重要;扩展性0.15,两个串口、一个千兆网口基本够用;供应链合规0.1;成本0.05。然后分别给X86和ARM方案的每项打分(1-10),乘以权重再求和。
我给自己手头这个项目实际打过分:X86方案总分7.9,ARM方案总分6.4。原因是ARM在软件兼容和组态软件两项上被扣了太多分,尽管功耗和成本都很漂亮。最终选了X86方案,理由很直接:组态工程照搬、无需重开发,节省的可不只是软件授权费,还有两个月的调试工期。
这个打分表的好处是,你把抽象的感觉变成了可以讨论的数字。以后拿方案给客户或领导汇报时,不用再说“我觉得ARM不太行”,而是说“ARM方案在软件兼容维度评分低,因为组态软件无ARM版,替代方案需要重写,成本约X万元、工期多Y周”,说服力是完全不同的。
5. 按场景抄作业:五类典型项目的整机配置参考
5.1 边缘数据采集网关
这种设备常见于工厂设备联网、能耗监测、环境监测。现场设备多是PLC、电表、传感器,通讯协议五花八门,Modbus RTU、Modbus TCP、OPC UA、DL/T645都有。网关要做的就是把数据在边缘解析、汇聚、清洗,再通过MQTT/HTTP转发到上层系统。
我的推荐配置是ARM平台:瑞芯微RK3568或飞腾FT-2000/4,4GB DDR4内存,32GB eMMC,双千兆网口,4路RS485,2路CAN,1个USB和1个TF卡槽。系统用麒麟或统信UOS的ARM版,或直接Python/Go写采集服务常驻运行。整机无风扇,导轨式安装。成本大概在千元级到两千元级,一个项目用几十台也不心疼。
这类场景几乎不涉及复杂GUI和Windows软件,全部运行在命令行级别,ARM生态完全够用。唯一提醒:modbus轮询逻辑和断线重连机制一定要写好,这是边缘网关稳定性的核心,跟架构无关。
5.2 人机界面HMI/组态监控
现场有一个触摸屏或者一台显示器,要展示产线流程图、实时曲线、报警信息,同时保存历史数据。这类项目如果客户已有组态工程,我的默认答案就是国产X86加Windows兼容方案,或者国产X86加国产Linux方案。
具体配置参考:兆芯KX-U6780A八核2.7GHz或KX-6640MA四核,8GB内存,256GB SSD,带HDMI和VGA双显示接口,至少2个千兆网口,4个串口。机箱用标准工控箱或壁挂箱,带一个温和风扇就好。系统按客户要求装Windows 10或统信UOS/麒麟。
这里再说一句经验之谈:HMI项目的屏幕权限和开机自启动经常出幺蛾子。装Windows的X86机器,组态王要设置好开机自启、掉电恢复后的自动运行、屏保和休眠全部禁用。装国产Linux的就要用systemd管理自启服务和进程守护,确保断电重启后不需要人再去点一下“运行”。这些都是细节,但六个项目里有四个最后都卡在这种地方,提前处理好能省很多售后电话。
5.3 机器视觉检测
这是当前最纠结的场景,因为视觉负载本身分三六九等,没有一概而论的答案。
如果只是简单的存在检测、有无判断、固定位置的读码OCR,用RK3588完全可行,NPU加OpenCV的NEON优化足够跑。整机功耗低,可以塞进原有设备柜,不需要大改。视觉软件自己用Python/C++开发,工业相机选海康或大华ARM可用的型号,光源控制器选串口或IO触发的,整体成本能压在一个很舒服的区间。
如果涉及高精度测量、高帧率动态检测、复杂深度学习模型,或者客户指定要商用视觉软件(比如Halcon、VisionPro),那几乎只有X86一条路。配置建议升级到兆芯KX-7000平台,加一块NVIDIA显卡,不过在国产X86平台上要重点验证GPU驱动和PCIe带宽,兆芯新平台对常见显卡兼容性还可以,但拿到样板一定先跑一遍Halcon的Benchmark再批量采购。
我自己做过一个折中方案:检测主机用X86跑视觉算法与结果界面,同时旁边挂一台RK3588小盒子做热成像温度数据采集和报警判断,两个系统通过Modbus TCP互联。一边兼顾了商用视觉软件的兼容,一边用上了ARM的低功耗采集优势,两边各取所长,现场效果也不错。这就是双平台混用的思路,在复杂项目里值得一试。
5.4 运动控制与PLC系统
运动控制,尤其是多轴联动、高速插补场景,对实时性要求是硬指标。这类项目中X86平台几乎还是首选。CODESYS SoftPLC Runtime在X86上有成熟的方案,Windows加RTX(Arduino? 应该是INtime或RTX)的方案在高端运动控制里已有大量验证,国产X86在指令集兼容的前提下,也能跑这些实时扩展层。ARM平台也有跑CODESYS的例子,但支持的驱动、总线主站卡(如EtherCAT主站)数量有限,很多在X86上随便用的实时网卡到了ARM上就是找不到驱动。
配置上,运动控制器使用兆芯KX-6000或KX-7000,配16GB内存,至少一个PCIe x16插槽(EtherCAT主站卡或运动控制卡),双千兆网口,串口若干。操作系统首选Windows 10 LTSC或带实时补丁的Linux,具体取决于你的运动控制软件支持情况。要特别说明的是:做运动控制的工控机最好整机买、整机测试,不要自己东拼西凑,因为运动控制对中断延迟和定时抖动非常敏感,杂牌主板在负荷高的时候可能出现莫名丢脉冲或者看门狗误触发,查起来非常痛苦。
有人可能问:ARM带Preempt-RT的Linux能不能做软PLC?理论上可以,我也见过柜子里跑着CoDeSys软PLC的ARM盒子在小设备上应用,但目前它在大型项目里的成熟案例还是少。如果你头铁要走这条路,务必先做至少72小时的满负荷实时性测试,记录最大抖动值,再决定能不能上产线。
5.5 信创合规替换项目
最后是这一轮里越来越多的信创软硬件替代项目。这类项目的核心不是技术参数多高,而是满足合规清单和运行稳定性。
合规项目通常有明确的整机目录和CPU名单,不同行业目录有差异,有的认可兆芯,有的指定飞腾,两者都有覆盖。拿到项目的第一步是去查目录,不是先选芯片。如果我需要一台既能满足信创要求、又能跑Windows组态软件的机器,兆芯平台加Windows是成本最低的路径,因为软件不用改。如果项目明确要求国产操作系统和办公软件全家桶,那飞腾D2000配麒麟或统信UOS是常见组合,明确要求国产操作系统的场景用兆芯也可以,但要额外确认所有软件是否都做了X86 Linux版和ARM版的适配。
信创项目的另一个坑是外设兼容:打印机、扫描枪、加密狗、USB Key、身份证阅读器这些设备往往只有特定架构的驱动,不兼容就现场抓瞎。做选型时务必根据现场外设清单逐项确认驱动和中间件是否在目标平台上可用。建议在项目启动时就制作一个“外设兼容性矩阵表”,列出所有外设、型号、驱动版本、验证状态,这比任何采购合同都管用。
6. 货到验收:最容易翻车的六个细节
6.1 一次粗糙的到货验收现场
有一次项目在交付阶段,现场工程师反馈工控机间歇性死机。我过去一看,机器是国产ARM平台,客户环境是一个金属柜子,柜门关着,没有通风口,设备开机运行时CPU都能上到80多度。厂商说这机器可以无风扇宽温运行,但那是65℃环境温度的前提下,柜子里热风散不掉,加上旁边还有变频器和伺服驱动器在发热,整机一直在高温边缘挣扎,不死机才怪。
后来换装了X86方案,带主动风扇,又在柜门上开了散热孔,问题才彻底解决。这个案例说明,验收时先把现场的热环境看清楚,比看一千遍参数表管用。
6.2 常见问题清单与现场处理
我在多个项目里积累了一张到货验收时的检查清单,分享出来,建议你照着跑:
| 检查项 | 具体操作 | 常见的坑 |
|---|---|---|
| 压力测试 | 用stress-ng或BurnInTest跑满CPU至少24小时 | 很多ARM板在满载时降频,性能缩水明显,不测根本发现不了 |
| 串口连通性 | 每个串口逐一回环测试或接真实设备通讯 | 部分板卡串口默认是TTL电平,不是RS232;有的RS485方向切换有问题,发包就乱码 |
| 看门狗功能 | 开启看门狗,故意让系统卡死,验证自动复位 | 很多国产板BIOS里看门狗默认关闭,且触发条件写在没文档的GPIO上,只能找厂商要要点 |
| 断电重启 | 循环断电上电50次,确认系统能自动恢复 | 掉电后eMMC/SSD数据损坏、启动顺序错乱是常见问题 |
| 网口速率 | 千兆网口实测吞吐,抓包看丢包率 | 便宜的ARM板的网卡性能缩水,实测只有600Mbps;有的驱动问题导致大量丢包 |
| 外设兼容性 | 逐个接入客户现场会用到的所有外设,跑完整业务流程 | 这是最花时间的,但也是唯一能避免现场事故的办法 |
特别是串口那个坑,我踩过不止一次。RK3568的很多底板,串口引脚默认是TTL 3.3V电平,而客户现场用的设备是标准RS232电平,接上去要么没反应要么收乱码。你以为自己程序写错了,查了半天,最后在原理图小字里找到一句“默认TTL”,那种感觉非常浪费时间。所以验收时一定先确认整机接口有没有做过电平转换,是RS232还是TTL,写进验收单里。
6.3 样板测试要覆盖真实负载
很多项目的问题在于,测试的时候用的是厂商提供的无业务负载的出厂系统,看起来一切正常,一旦跑起真实业务就垮。建议你在测试阶段就把目标环境完整复现出来:操作系统、运行库、数据库、业务软件、通讯链路、第三方SDK,全部按生产环境装上,再并发跑满。X86平台如果跑的是Windows,要特别测试开机启动项的稳定性;ARM平台如果跑Linux,要重点验证内核版本和所有外设驱动的匹配性。
我通常的流程是:拿到样板后,先花三天搭一套与现场基本一致的完整软件栈,然后连续跑72小时业务仿真,期间每天记录CPU温度、内存占用、运行日志和异常次数。这一步虽然短时间看不出产出,但它能提前引爆90%以上的隐性坑。有个朋友做项目时跳过这一步直接批量采购了20台ARM工控机,结果一到现场发现某品牌USB转485模块的Linux驱动在批量设备上只有一半能正常枚举,最后只能紧急更换型号,多花了近两周时间,数字上看起来省了钱,实际亏得更多。
另外,测试记录一定要留档。不仅仅是“能跑不能跑”这个结果,而是把型号、固件版本、内核版本、驱动版本、测试步骤、耗时、日志都记下来。后期设备批量出问题排查时,这些记录是还原现场的唯一依据。
最后说一个我自己的习惯:无论选X86还是ARM,我都会在合同里约定“到货后提供不少于7天的现场兼容性测试期”,并把验收标准量化成具体指标,比如“70℃环境温度下满载连续运行24小时无死机重启”“串口24小时连续通讯丢包率低于万分之一”“断电重启后30秒内自动恢复业务”等等。这样写的好处是,验收时双方都在同一个标准上对话,不容易出现项目组和厂商互相推诿扯皮的局面。选型并不难,真正难的是把需求和现场条件翻译成一条条可验证的契约条款,再让平台优势去匹配它们。