3. XG-X系统软件可靠性基础

在讨论XG-X系统的可靠性时，硬件往往是最先被关注的对象：相机本体、镜头、光源、控制器、线缆。但从工程实践看，真正让一条产线“看起来正常、实际不可信”的，常常是软件层。XG-X系统的软件可靠性可以拆成三个相互耦合的层面：固件（运行在控制器与相机内部的底层程序）、配置软件（XG-X Vision Editor等用于建模、标定、参数下发的上位工具）、通信协议栈（PLC链路、以太网、串口、I/O触发等数据通道）。三者失效特征不同，验证边界也不同，不能混为一谈。

固件：稳定但“沉默”的失效

固件是XG-X控制器与相机模组的运行基础，负责图像采集时序、曝光控制、触发响应、内部缓存管理和基础图像处理调度。它的典型特征是：一旦版本确定，行为高度一致，但一旦出现异常，往往表现为“沉默失效”——没有报错弹窗，只是结果偏移、节拍变慢或偶发丢帧。

固件的失效特征主要有四类：

• 触发响应抖动：外部触发到曝光开始的延迟从标称的数十微秒漂移到数百微秒，导致与产线编码器位置不同步。
• 缓存溢出丢帧：连续采集时内部帧缓存被占满，表现为“采集计数正常但图像序号跳变”。
• 版本行为差异：同一配置在不同固件版本下，边缘检测阈值或滤波结果出现系统性偏移。
• 长时间运行退化：连续运行数十小时后，内存碎片或句柄泄漏导致响应变慢，重启后恢复。

固件的验证边界在于：不能只验证“功能是否实现”，而要验证“在边界条件下是否仍然一致”。例如，验证触发抖动时，应在标称节拍、1.5倍节拍、2倍节拍三档下各采集1000次，记录触发到曝光的延迟分布，观察P99值是否超出工艺允许窗口。若标称节拍下P99为80μs，而2倍节拍下P99跳到300μs，说明固件在高负载下的调度策略存在边界问题，不能仅凭“功能正常”放行。

配置软件：人为引入的“隐性缺陷”

配置软件是工程师与XG-X系统交互的主要入口。它本身不直接参与产线运行，但它生成的配置、标定参数、检测逻辑会固化到控制器中，成为运行时行为的一部分。因此，配置软件的可靠性问题，本质上是“配置正确性”与“配置可复现性”问题。

常见的失效特征包括：

• 参数边界未校验：例如将二值化阈值设为0或255，软件不报错，但运行时检测结果全白或全黑。
• 标定数据与当前工位不匹配：更换镜头或调整安装距离后，未重新标定，导致像素当量错误，测量值系统性偏大或偏小。
• 配置版本漂移：现场调试时直接修改参数未保存版本，导致“昨天能过、今天不能过”，无法追溯。
• 依赖关系断裂：某个检测区域引用了已被删除的ROI或标定文件，软件在编辑态不报错，下载到控制器后运行时报错或静默跳过。

配置软件的验证边界是：不能只验证“编辑态能保存”，而要验证“下载到控制器后行为与编辑态一致”。一个可执行的做法是建立“配置基线快照”：每次现场调试后，导出完整的配置包（含标定文件、ROI定义、通信映射表），并记录对应的固件版本、镜头型号、安装距离。下次复现问题时，先比对快照差异，再判断是配置漂移还是硬件变化。

通信协议栈：最容易被低估的失效源

XG-X系统通常需要与PLC、上位机、MES或机器人控制器通信。通信协议栈涵盖物理层、链路层、应用层，常见链路包括EtherNet/IP、PROFINET、Modbus TCP、串口RS-232C以及硬线I/O。通信层的失效往往不是“完全断连”，而是间歇性丢包、延迟抖动、数据错位，这类问题最难排查，也最容易在验收时被忽略。

典型失效特征：

• 心跳超时误判：PLC侧心跳周期设为100ms，但XG-X在高负载下响应延迟达到150ms，导致PLC误判断线并触发安全停机。
• 数据对齐错误：多字节测量结果（如浮点坐标）在字节序或寄存器映射上不一致，导致PLC读到“看似合理但完全错误”的数值。
• 触发与结果竞争：PLC在收到结果信号前就发送下一次触发，导致结果寄存器被覆盖，出现“结果跳变”。
• 协议栈资源耗尽：长时间运行后TCP连接数或缓冲区未释放，新连接无法建立。

通信协议栈的验证边界是：不能只验证“单次通信成功”，而要验证“在节拍压力、异常注入和长时间运行下的稳定性”。例如，验证EtherNet/IP通信时，应构造以下测试序列：连续发送10000次触发，每次记录“触发发出→结果返回”的往返时间，统计P50、P95、P99；同时注入一次网络闪断（拔插网线2秒），观察恢复后是否出现结果错位或连接假死。若P99超过PLC扫描周期的1.5倍，或闪断恢复后首次结果错误，则通信边界未通过。

三层耦合：为什么不能分开验证

把固件、配置软件、通信协议栈分开看，每一层都有相对清晰的验证方法。但实际工程中，三者的失效会相互掩盖。例如：固件在高负载下触发响应变慢，导致通信层心跳超时，PLC误判断线；工程师排查通信链路，更换网线、调整心跳周期，问题暂时消失，但固件退化仍在累积。又例如：配置软件中某个ROI引用了旧标定文件，运行时检测结果偏移，工程师误以为是相机固件版本问题，反复刷固件却无效。

因此，XG-X系统软件可靠性验证的边界，不应按“层”划分，而应按“可观测的工程现象”划分。建议在验证计划中明确三类观测点：

这张表的意义在于：它把“软件可靠性”从抽象概念转化为可采集、可判断的工程数据。固件层看延迟分布，配置层看快照差异，通信层看往返时间与异常恢复，三者共同构成XG-X系统软件可靠性的验证边界。边界之内，系统可信；边界之外，即使功能“看起来正常”，也不能放行到量产。