重型机械厂里有一种很普遍的验收动作：在通道上放一块挡板，或推一个模拟障碍物，看叉车AGV会不会停下来。测出来会停，大家签字，安全这块就算过了。但这里藏着一个几乎没人追问的前提——你验的是「设备一切正常时会不会停」。真正的事故，大多发生在设备不正常的时候：镜头积了油膜、雷达角度偏了、接插件松了、程序卡了。这时候，这台车是「坏得明明白白地停下」，还是「坏得悄无声息地继续跑」，才是安全验收真正该回答的问题。载重、车速、调度效率这些参数都可以放一放，本文只深挖一件事：怎么把一个「正常时能停」的系统，验证成「坏掉时也安全」的系统。
任何由电子元件和软件构成的安全功能，都会失效。区别只在于失效的后果。行业里有一对概念，一个叫「安全失效」，一个叫「危险失效」。用大白话说：元件坏了，系统立刻报警、降速、停车，这叫坏得明白，是安全失效；元件坏了，系统毫无察觉、继续全速运行，保护形同虚设，这叫坏得隐蔽，是危险失效。同一套避障功能，架构设计不同，失效的方向就可能完全相反。
重型厂区恰恰是故障的高发土壤，这正是它和电子厂、洁净车间的根本差别。行车起吊时的电流冲击、钢轨传来的持续震动、金属粉尘和油雾在传感器上的积累、热处理区的大温差、地面高频的冲击载荷，每一样都在加速传感器和接插件的劣化。在干净的标准车间里跑一年可能只是轻微磨损的设备，在重型厂区半年就会出现肉眼可见的性能衰退。换句话说，故障不是「万一发生」，而是「一定会发生、而且来得更快」。所以选设备时，参数表往后放，先问一个问题：你的安全功能，被设计成坏掉的时候往哪个方向走？
最危险的一类失效，不是传感器突然坏掉，而是慢慢变瞎，慢到整车看起来一切正常。这种渐变在重型厂区有几种典型路径。
探测窗口结垢是最常见的一种。机加工区的油雾和金属粉尘会在一两个月内，在激光雷达窗口和相机镜头上结成一层半透明膜。膜刚开始时，探测距离只是悄悄缩短，正常自检照样通过，偶尔的避障测试也还过得去。等膜厚到一定程度，行人识别的那点裕度就被吃干净了——可系统层面读到的信号只是「距离变近了」，没有哪个模块会告诉你「你的安全边际已经归零」。
相机对焦漂移是第二种。行车震动和昼夜温差会让镜头组件发生微小位移，深度图里慢慢出现局部黑洞区域。人形识别算法把这片空洞当成背景处理，路径中央站着一个真人，点云里却是一片平整的空地。这种失效尤其阴险，因为它不影响导航——导航还有货架和其他参照物兜底，唯独「人的识别」这一路，空洞区域恰好把人盖掉了。
雷达接插件的老化是第三种。重型厂区的振动会让线缆在弯折处慢慢内断，接插件氧化导致偶发丢帧。偶发性故障最难复现，现场查一遍查不出来，往往被归为「正常波动」，然后不了了之，直到某次它恰好漏掉关键帧。
这三种失效有一个共同点：在「业务导航」的视角里几乎看不出来，因为导航总有其他参照物；唯独「识别行人」这条链，一旦静默劣化，车照跑不误。而此刻系统的表现，就取决于它的架构——危险架构把识别结果送进业务电脑做判断，再由软件请求停车；电脑一卡、软件一抖，把「识别失败」当成「没有障碍」，保护就是空的。安全架构则是另一套逻辑：安全回路独立于业务链路，直连驱动切断，双通道互相监视，任何一路异常立即把整车推进最保守的停车状态，安全功能用的还是通过安全等级认证的元件，不依赖随时可能死机的上位软件存活。判断一台车属于哪一种，不用听宣讲，直接要求供应商出示电气架构图，看安全回路是否独立成环、切断驱动走的是硬线还是软件请求，一目了然。
既然真正的风险在故障态，验收就不该只测正常态。行业里有一种成熟做法叫故障注入，就是故意让设备出故障，观察它往哪个方向反应。这套动作在重型厂区尤其该做，因为这里的故障本来就比标准车间来得密。实际操作可以按下面几类来布置，不需要复杂仪器，多数用现场的随手材料就能完成。
模拟窗口积垢，是最便宜也最该做的一项。让车满载正常运行，中途用一块遮光布蒙住激光雷达窗口，或者用油性污物涂上一层膜，观察系统在多久内报警、是否降速并进入保守停车。合格的系统应当在有限时间内做出可读的反应；如果它蒙着「眼睛」把整段路径跑完，这一项就直接不通过。
制造通道失效，是考验冗余的一招。正常运行中直接断开视觉相机的供电，看激光通道是否接管、系统是否降级到更低的速度或停车。这里要留意的不是「会不会停」，而是「断了一路之后，系统是主动承认自己缺了一路，还是假装什么都没发生」。诚实降级，才是安全架构该有的样子。
触边短路与断路，对应的是近距离兜底。把安全触边人为短路一次、再断路一次，整车应当在任一种情况下立即进入安全态。重载场景里这层兜底通常直连安全回路，如果它反应迟钝，说明硬线链路里夹了不该有的软件环节。
镜面反射干扰，验证的是重型厂区的独有问题。在路径上放一块高反光的不锈钢或抛光件，制造点云空洞，看系统是「误停」还是「漏检后继续前进」。误停是安全方向，最多影响一点效率；漏检就是危险方向，说明感知策略对这类环境没有专门应对。前者的成本是时间，后者的成本可能是事故。
这几类注入的判定标准可以统一成一句话：故障注入之后，系统只允许往保守方向动作——给出可读的报警、主动降速、可控停车。只要出现「毫无反应」或「继续正常运行」，就判定不通过，不需要再讨论参数漂移了多少。
还要提醒一点：故障注入的结果要写进验收文件，逐条记录每个场景下的响应时间和动作，这份记录就是设备运行期的对照基准。重型厂区的环境会让传感器窗口反复结垢，建议同步建立班前点检制度，每个班次开工前擦拭窗口、查看自检日志，把设备自检和人工点检串起来，别让积垢又把安全边际慢慢吃掉。这类验证对供应商的配合度要求很高，谈合同时就要写明：故障注入场景由谁设计、由谁执行、由谁记录，避免验收时互相推诿。武汉本地像湖北铭创达智能装备有限公司这样的供应商，支持在客户实际工况下布置感知与制动验证，本地化的调试和售后响应也方便反复复测，可以列为考察对象之一；但最终结论，仍要以你在自己现场亲手做出来的故障注入结果为准。
最后补一句：故障态验证解决的是「坏的时候怎么停」，至于停下来之后——满载急停后载荷有没有位移、怎么确认、怎么安全恢复，以及物理隔离兜底——那是下一道题。先把故障态验证做扎实，这台车的安全账才算真正对得上。