我最早接触工控这个词是在一张又一张产品宣传页上——PLC、伺服、组态软件、HMI大家说这叫工业控制系统。那时候我也以为工控就是把自动化设备连起来、让产线按既定的逻辑跑起来。直到我参与了一个内部代号叫模拟项目X的控制系统项目才彻底改变了看法。这个项目的特殊性在于它带了一层军工体系的标签。这里我得先说明我说的军工体系不是指某个保密厂房或具体型号而是一个符号——它代表一类把可靠性、实时性和长生命周期推到极致的工业控制场景。在那样的体系里工控系统不是能用就好而是必须做到长期稳定、故障可预期、坏了还能修、十年后依然可控。这篇文章我想把我在那个项目里沉淀下来的东西写出来包括需求怎么拆解、冗余怎么搭、硬件怎么选、实时性怎么保证、测试怎么设计、运维怎么做以及那些文档里不写、却非常重要的经验教训。适合谁看如果你在做工业控制、自动化设备、嵌入式控制器或者你所在团队想把产品的可靠性往上拉一个档次这篇文章应该能给你一些可落地的思路。1. 从能用到可靠工业控制系统设计逻辑的分水岭1.1 商业级与高可靠级工控的本质差异很多做惯了普通产线项目的工程师往往对可靠性这个词是麻木的。设备今天能用明天也能用偶尔重启一次忍忍就过去了。但在军工体系这类高可靠场景里这种容忍度完全不存在。我用一张表来说明商业级工控和高可靠级工控的差距这张表是我在实际项目里反复用到的对照维度商业级工控高可靠级工控可用性目标99%~99.9%99.99%~99.999%工作温度范围0℃~45℃-40℃~70℃甚至更宽生命周期3~5年15~25年故障响应重启、换机不停机切换、降级运行维修策略整机返修板级/模块级更换持续备件设计验证功能测试为主高低温、振动、EMC、故障注入成本敏感度非常敏感可靠性优先成本其次这里的差异不是某几个参数变大了而是整套设计哲学变了。普通系统默认故障是意外的高可靠场景默认故障是迟早的——所以真正要做的不是祈祷它别坏而是设计成坏了也不影响任务。1.2 把可靠翻译成可量化的指标在项目启动阶段最忌讳的一句话就是我们要做个可靠的系统。可靠是方向不是指标。必须把它拆成数字。首先是可用性Availability公式很简单A MTBF / (MTBF MTTR)MTBF是平均无故障时间MTTR是平均修复时间。如果MTBF是3年26280小时MTTR是4小时那么A 26280 / 26284 99.985%。这个数字已经是比较高的水平了但要做到99.99%以上要么把MTBF再拉高要么把MTTR压得更低。模拟项目X里我们定的目标是这样的系统可用性不低于99.99%核心控制周期不超过5毫秒周期抖动不超过正负100微秒冗余控制器主备切换时间不超过10毫秒整机设计寿命15年。这些指标写进设计规格书之后后面每一个技术决定——架构选择、器件选型、测试方案——都必须能回答我做的这件事对哪个数字有帮助。其次是功能安全等级。如果系统涉及安全连锁比如紧急停机、阀门控制、危险区域监控那就必须考虑SIL安全完整性等级概念。SIL2和SIL3对系统架构的约束是根本性的SIL2可能允许单通道加诊断SIL3往往要求冗余通道加表决机制比如1oo2、2oo3。这类需求会直接影响硬件架构设计不能等项目做了一半再回头补。1.3 冗余架构的基础形态别让单点故障成为故事我在模拟项目X里最先做的事情不是画功能框图而是做单点故障分析。拿着整机供电图、信号链路图从电源入口一路看下去任何只有一个路径、没有备份的环节都标成红色。红色清单出来后冗余方案的基本形态也就出来了。控制器冗余是核心。两个控制器通过同步链路实时交换运行状态和控制数据主控制器故障时备用控制器会在规定时间内接管输出。这里两个关键参数同步数据量和切换时间。同步数据量越大切换后越能无缝衔接切换时间越短系统对现场设备的影响越小。我们当时用专用同步网口每个控制周期都做一次全量状态镜像切换实测稳定在5毫秒左右。电源冗余主电源模块和备电源模块构成11冗余满负载下热备份运行。单模块故障时无扰切换同时触发诊断报警。这里容易踩坑的是冗余电源共享输出二极管的选择如果用普通二极管压降太大大电流下发热严重要用低压降的肖特基二极管或者理想的MOSFET构成的理想二极管电路。网络冗余控制网采用双链路冗余正常情况下主链路通信备用链路同时接收数据但不发送。链路故障或误码率超阈值时10毫秒内切换。在真正的高可靠场景不建议用RSTP快速生成树协议这种需要重新学习网络拓扑的协议而应该用介质冗余协议MRP或者厂商自研的双链路无缝冗余。原因很简单RSTP收敛时间再快也很难做到几十毫秒以内且收敛期间广播风暴对控制周期的影响是致命的。2. 严苛环境下的硬件选型与降额设计把余量变成规则2.1 环境剖面先把最恶劣的工况列出来做硬件选型前我们习惯先画一张环境剖面表。不能只看厂家手册上标的那一行字要结合实际安装位置是装在恒温机柜里还是露天设备上是沿海盐雾环境还是高海拔区是长期振动还是偶发冲击模拟项目X的剖面清单大致是这样工作温度范围-40℃到70℃温度变化率大于每分钟5℃相对湿度95%不结露需要耐受一定等级的盐雾和霉菌随机振动频率范围5到500赫兹冲击加速度峰值30g持续时间11毫秒。这些数字别忘了也算进运输和存储条件里——很多设备不是工作状态坏的而是被振动、淋雨、暴晒在运输途中搞坏的。普通商用壳体和工业壳体的差异在这里就出来了铝合金压铸外壳带散热齿片、密封硅胶条、防松脱螺丝、带锁紧机构的重载连接器——这些设计不是为了让设备看起来更结实而是每一个特征都在对应一个具体环境应力。2.2 元器件降额器件手册上的极限值不是让你用的降额这个词听起来保守但它背后是实打实的物理规律。元器件在高应力下的失效率呈指数上升尤其是温度。电解电容的寿命和核心温度有个工程经验法则温度每升高10℃寿命减半——这就是所谓的10度法则。一颗标称105℃寿命5000小时的电解电容如果在85℃下工作寿命大约只剩1250小时而且这是理论值实际可能更短。这样的元器件在高可靠系统里是不能用的。降额设计的具体规则我们内部有一套参考红线电阻的功率降额到额定值的50%电解电容的耐压降额到70%同时还要留出纹波电流的余量半导体器件的结温降额到125℃以下理想是110℃连接器的触点电流降额到额定值的60%到70%PCB走线的电流密度要按温升不超过10℃来校核。有一次我分管的部分调试中一个电源模块常温下一切正常但放进-20℃环境后输出电压纹波变大进一步检查发现输入端的电解电容器低温下ESR增大导致稳压环路相位裕量不足。这个问题的根因就是当初只看了额定电压值没算低温ESR也没给电容留出足够的耐压和容值余量。这件事之后低温特性正式写进了我们所有关键电容、电阻的选型检查表。2.3 从PCB到连接器故障往往藏在细节里硬件系统的可靠性不是只靠几个大器件大量隐患都藏在看起来不起眼的地方。PCB方面首先过电流路径。常见普通板子用1盎司铜厚、线宽0.5毫米载流能力有限高可靠系统里电源通道建议用到2盎司铜厚或以上线宽按每安培至少1毫米的经验值来。其次孔径和焊盘振动环境里焊盘孔径比太接近引脚直径焊锡会形成虚焊过孔最好做塞孔处理防止锡珠从背面渗出造成短路。最后铺铜完整性不要在大电流路径上突然断开铺铜否则会成为热点。连接器是振动环境里的第一大故障源。普通排针排母在高频振动下容易瞬间接触不良表现为偶发复位或者通信失败。高可靠系统必须选带锁紧机构的连接器比如螺纹锁紧的圆形连接器、带弹片的工业连接器。镀金厚度也很关键反复插拔和盐雾环境下镀镍或镀锡容易氧化至少要选镀金触点。接线端子方面现场线缆如果采用压接必须严格按照线鼻子规格匹配压线钳压完后做拉力测试——很多人图省力直接用电烙铁焊线这在振动环境里反而容易在焊脚处折断开裂。三防漆敷形涂料是沿海高湿环境的必需品。但涂了三防漆之后带来维修困难返修时需要局部去除漆层很容易损伤相邻元件。所以高可靠产品要在保护和可维修之间平衡。我们的做法是易损件和可更换模块不做三防电路板主控区域做三防维修口附近用可剥离胶保护。2.4 选型清单背后的逻辑一图看懂我的硬件决策树很多团队选硬件是看看之前用的什么牌子的继续用就行。这种习惯在高可靠场景里风险很大。我们的选型决策树大致是这样的第一步列出环境应力和电气应力清单第二步按降额规则算出每个位置器件的电压、电流、功率、结温需求第三步优先选择有工业级或更高等级认证的器件工作温度范围必须覆盖-40℃到85℃第四步查看生命周期排除已经进入停产通知期的型号第五步做可替代性评估至少准备一个同封装、同功能的第二货源第六步把关键器件送去第三方做来料抽检特别是批次一致性。这套流程看起来繁琐但在长周期项目里省的麻烦远远大于前期投入。一旦某颗料到了项目中期突然停产等你反应过来再换料重新测试验证的成本就非常高了。3. 实时控制与确定性让系统始终说一不二3.1 为什么确定性比速度更重要普通工业控制场景里大家更关注CPU主频、扫描周期数值。但在高可靠场景真正的核心指标是确定性——也就是每个控制周期任务是否都能在固定的时间窗内完成有没有偶发的拖延或跳变。打个比方。红绿灯有两种控制方式一种是定时控制红灯固定30秒、绿灯固定45秒不管路口有没有车秩序是确定的另一种是感应控制根据传感器实时调整吞吐量可能更高但秩序感就差一些。工控系统也是类似的控制周期是一个固定节拍逻辑任务、通信任务、诊断任务都必须在这个节拍里被有序执行。如果系统做事件驱动某个任务临时占用大量CPU时间其他任务就会被挤出时间窗控制逻辑就不确定了。所以高可靠控制器的软件架构往往采用固定周期调度的实时方案。处理器哪怕有很多富余算力也不允许某个任务随意延长执行时间。一个5毫秒控制周期内任务的时间分配是预先排好的采样1.0毫秒控制计算1.5毫秒网络发送0.5毫秒数据镜像0.5毫秒自诊断0.5毫秒剩余时间做低优先级的背景任务。每个任务必须在分配的窗口内结束超时就要触发异常记录。3.2 实时通信网络总线不是能通就行控制周期做到5毫秒通信链路也必须跟上。普通的TCP/IP以太网理论上带宽很够但它是一个尽力而为的协议网络堵塞、重传、缓冲区排队都可能导致数据包延迟抖动几十甚至几百毫秒。这在控制回路里是不可接受的。高可靠系统的实时通信方案通常有两种路线。一种是以EtherCAT、Profinet IRT为代表的硬实时工业以太网它们通过时间分片、集中调度、分布式时钟同步等机制把通信的抖动压缩到纳秒级到微秒级。EtherCAT尤其适合高同步精度的运动控制场景它的分布式时钟可以实现从站之间亚微秒级的时钟同步。另一种是传统现场总线如PROFIBUS、CANOpen的升级换代在相当一部分高可靠存量系统里仍然在发挥作用因为它们的确定性模型是经过几十年验证的。模拟项目X的控制器之间和控制单元到IO模块之间我们用的是工业实时以太网。一个典型的同步循环是主站发送同步帧-所有从站同时采集输入-主站计算-所有从站同时输出。整个周期从数据采集到输出刷新固定控制在某个确定值以内。调试系统时最重要的一步是测量每个从站的实际响应时间把响应时间最大的那个从站作为周期预算的瓶颈。布线层面也有讲究。工业以太网线缆现场制作时要严格按照A类或B类屏蔽要求接线屏蔽层要360度接地金属格兰头不能偷懒换成塑料的。很多通信时好时坏的现场问题最后排查出来都是屏蔽层接地不良或者线缆弯曲半径过小导致的内部断芯。3.3 任务调度、看门狗与冗余切换系统的自我保护实时性不只是快还包括知道自己病了并且做出正确反应。这套自我保护机制由三部分组成。看门狗硬件看门狗独立于CPU运行规定时间内CPU不喂狗就强制复位。高可靠场景不能只靠硬件看门狗还要做软件执行监视——比如对每个实时任务记录执行时间如果某个任务连续多次接近甚至超过预算时间系统要考虑主动降级而不是等到崩溃。硬件看门狗管程序死了怎么办软件监视管程序还活着但快不行了怎么办两者缺一不可。心跳机制冗余系统的核心之一。主控制器和备用控制器之间持续交换心跳帧心跳帧里不仅包含我还活着还包含控制数据的序列号和时间戳。备用控制器只需要比较心跳帧连续性和序列号就能判断主控制器是否失联或逻辑是否停止推进。心跳超时阈值要设得非常精确太短可能因为偶发通信抖动误切换太长则故障切换时间无法满足要求。故障切换逻辑确认主控制器故障后备用控制器在若干毫秒内接管输出。接管不是简单地把输出状态拷贝过去还要包括控制回路的初始化确保接管后控制算法的输出不会出现跳变——这涉及到处理器的启动模式和输出状态保持策略。我调试时亲眼见过切换成功后因为控制量初始化不当执行机构猛地动了一下这在现场是绝对不允许的。4. 测试验证把现场故障逼到实验室里提前引爆4.1 高低温与温度冲击设备怕的不是冷而是变高低温测试不是简单地把设备放进恒温箱里跑一遍就完事。真正的关键是复现环境剖面的温度变化率。如果现场温度变化速率是5℃/分钟而测试时用1℃/分钟慢慢升温很多温度应力相关的问题根本暴露不出来。因为热胀冷缩产生的机械应力、材料内部的热失配只有在足够快的温变速率下才会显现。模拟项目X的测试剖面大致分三段。存储温度测试-40℃和70℃各存储若干小时期间不上电恢复常温后做完整功能测试目的是验证设备经受极端温度后依然正常。工作温度测试分别在-40℃、常温、70℃三个温度点运行满载荷并记录所有关键参数——各电源轨电压、处理器结温、通信误码率、控制周期实际抖动。温度冲击测试在-40℃和70℃之间快速切换浸泡到平衡后直接切换等设备温度平衡后再测试。这一项最容易暴露焊点开裂、封装内部断裂等隐患。测试期间不能只看产品是否死机。我用过一个土办法软件里跑一段连续自检任务记录每一次复位、每一次通信重传、每一次参数越限测试结束后统计频次。哪怕没有完全死机只要复位次数明显增加说明硬件在温度应力下已经出现不稳定需要回去追根因。4.2 振动与冲击不是测一测就完要找到共振点振动测试常见的误区是我把振动台开起来震动了几小时没发现问题应该没问题。实际上随机振动测试的目的是模拟运输和使用环境的累积应力需要知道PSD谱型功率谱密度根据频率范围和谱密度值计算Grms值。举个例子如果PSD在5到500赫兹范围内是0.02g²/Hz的平直谱那么Grms大约等于sqrt(PowerSpectralDensity乘以频带宽度)也就是大约3.1g。如果谱型是在某个频率有峰值Grms就要分频段分别计算再加总。正弦扫频测试是找共振点的利器。在5到2000赫兹范围内以恒定加速度做慢速扫频同时监测设备内部器件和外壳的加速度响应。如果在某个频率响应特别放大该频率就是结构共振点。共振点处的应力会被放大数倍如果正好落在某个电容或晶振的安装位置附近长期共振就会导致引脚疲劳断裂。冲击测试相对简单半正弦波峰值加速度和脉冲宽度按条件执行例如30g、11毫秒三个轴向正负方向各打若干次。冲击后立即做功能检查。只看打完之后还能开机不能是不够的要看有没有出现数据校验错误、通信时序异常和轻微性能退化。4.3 电磁兼容最容易翻车的环节EMC是每个硬件工程师又爱又恨的领域。高可靠场景里控制器往往和变频器、伺服驱动、大功率电源一起安装在同一个柜体里这不是有没有EMC问题的问题而是哪天会被干扰死的问题。我印象最深的一次整改发生在模拟项目X早期样机阶段。静电放电ESD测试每次打在产品外壳接缝处设备就随机复位。刚开始以为是软件看门狗没写好反复查代码没发现问题。后来用示波器监测电源轨发现静电打上去的瞬间主板3.3V电源出现一个持续时间很短、幅度接近2V的跌落低电压复位芯片触发复位。根因是外壳接缝处的导电衬垫没压紧静电通过缝隙直接放电到主板地地弹噪声叠加在电源上。整改措施分三级第一级是结构——所有接缝处增加导电屏蔽衬垫保证外壳的导电连续性第二级是板级——电源输入端加强滤波电容敏感芯片电源引脚增加退耦第三级是接口——对外端子全部加TVS管和共模电感。整改后再次做静电测试直接按标准提高一个等级打依然通过。这里有个经验不要把EMC试验目标定成通过。最好按标准限值加上20%到30%的余量来做。因为现场环境的干扰往往比实验室复杂得多而且设备老化后屏蔽效能和滤波性能都会下降今天刚好达标两年后可能就不达标了。4.4 故障注入测试把这台设备往死里整故障注入是高可靠系统测试里最有价值、也最少人做的一环。它的核心思路是主动制造故障观察系统反应确认系统走到了设计好的安全状态。我们做过的故障注入测试包括以下几类。掉电类瞬间断电、缓慢掉电、多次快速开关机。重点观察掉电瞬间输出是否出现毛刺或错误状态上电时序是否正确有没有因电源竞争导致芯片闩锁。通信类运行中断开通信线、用信号发生器人为注入错误帧和CRC错误包、降低通信接口电压。重点观察系统是否能稳定监听到通信异常并触发报警或切换。信号类把传感器输出短路、断路、叠加漂移信号。重点观察模拟量采集是否异常算法是否把异常值当成真实值参与控制。负载类把执行器负载从额定值突变到1.5倍、再突变到短路状态。重点观察电源和驱动是否能保护性断电而不是烧毁。每一次故障注入测试都要填写测试记录表写清楚注入方式、注入时长、系统观察到的行为、是否达到预期安全状态。如果发现系统行为不符合预期那就是设计缺陷。故障注入往往能发现几个设计时没想到的边界情况。比如有一次我把某个模拟量通道的输入端直接和地短路系统不仅报了通道故障还因为错误数据参与了PID计算导致输出短暂超调。这个问题的修复方式和纸上推演完全不一样等真正做测试才暴露出来。5. 长生命周期运维系统十五年后的维护账5.1 元器件生命周期管理今天买的器件五年后还有没有货普通工业产品生命周期3到5年很多项目压根不用考虑元器件停产问题。但高可靠系统的生命周期是15到25年这就产生一个严肃的问题你现在用的器件五年后大概率停产了。我们的策略是建立一张长周期敏感器件清单。清单里不仅记录型号、厂商、封装、参数还记录停产风险等级、备选型号、最后采购期。元器件原厂发布停产通知EOL后通常会提供一个最后一次采购服务LTB窗口大概在12到18个月。如果错过这个窗口后续只能从分销商手里高价买翻新件或拆机件质量无法保证。项目组里专门有一个人按月巡查原厂的停产公告发现关键器件有停产迹象立刻启动替代料验证流程。第二货源策略在高可靠场景里有一点尴尬。通用器件比如电阻电容、标准逻辑芯片找第二货源不难。但是专用集成电路比如某款专用协议处理芯片往往只有一个供应商。遇到这种情况我的建议是在系统设计阶段尽量把这类专用芯片隔离在一个可替换的模块上让这个模块的接口标准化后续即便换方案也只换这个模块而不必动整个系统。5.2 备件策略与三级维修体系备件的目标只有一个把MTTR压到最低。高可靠系统的备件策略不是坏了再买而是预估坏了的时间提前囤货。备件分三个层次。板级备件最关键的几块板比如CPU板、电源板、通信板现场必须常备一块甚至多块。模块级备件现场可更换的整体模块比如I/O模块、端子模块。系统级备件整机换设备。备件之间存在优先级和数量配比重点备那些故障率最高、采购周期最长的板卡而不是平均分配。三级维修体系是行业内的经典做法。一级维修现场更换板卡或模块故障板卡返厂。二级维修在厂家实验室做模块级维修定位到具体某个器件。三级维修对无法通过模块级修复的板子做元器件级维修需要原理图、测试夹具和足够的维修经验。实际上高可靠系统的维修队伍必须用这套体系运作不然坏一块板换一块新板成本上完全撑不住。5.3 固件与软件的进化陷阱别让升级毁了可靠性硬件可靠了软件却在持续演进这是新风险。固件升级是长周期系统里最危险的操作之一因为任何一次升级都可能引入回归缺陷。高可靠系统对固件升级的策略是控制频次追求稳而不是新。除非有必须修复的安全漏洞或功能缺陷否则不轻易升级。每一次升级必须完整跑一遍回归测试——包括正常工况、高低温、通信异常和故障注入。升级过程本身要支持断点续传和版本回退防止升级中途复位导致设备变砖。软件配置和程序版本管理同样重要。我用Git管理所有的工程文件但这里有个细节工控部署环境的版本号必须和Git提交记录强绑定。每次现场部署都要写清楚设备序列号、部署的固件版本号、配置文件版本、部署日期、操作人。这样出问题时能精准定位这台设备到底是哪一版程序在跑。备份策略采用三重备份设备本地存储一份当前固件现场管理机存一份历史版本离线存档一份出厂标配版本。别嫌麻烦关键时能救命。5.4 文档与知识传承系统比人活得长知识必须沉淀下来长寿命系统还面临一个隐性风险工程师会流动。工程设计在A手里是清楚的交给B之后可能就成了糊涂账。我们采用的方法是做一整套系统认知文档不光是用户手册和维修手册还包括系统架构说明、状态机描述、故障树分析FTA、常见故障对照表和故障处置流程图。特别要强调的是故障树分析它把系统级故障从上到下逐级展开到底层器件失效模式新人真碰到疑难故障时能拿着故障树一步一步缩小范围而不是靠猜。每个故障入库时都要写清根因、现象、处置方式、预防措施。这看起来是管理成本但也正是它让一个15年长的项目不会因为人员更替而出现只有老张会修这台设备的被动局面。6. 复盘与总结文档里不写的经验和教训6.1 如果它坏了系统会怎么做——把可靠性变成一种惯性提问慢慢地我发现高可靠系统的设计能力本质上是习惯问题。它不是某一次评审里多做几项检查而是每个工程师在面对任何一个设计选择时都会本能地问一句如果这个东西坏了系统接下来会做什么FMEA故障模式与影响分析是一个非常好用的抓手但不要照着教科书的格式走流程。我们在实践里把它简化成一张表格功能、故障模式、故障影响、检测手段、应对措施。每次设计评审时拿这张表逐行过。有些故障模式看着一笑而过比如显示屏背光暗了但如果你展开想象——操作员看不清报警信息会不会误判会不会导致安全连带事故——事情就变大了。我见过不少团队做FMEA是为了过评审拿签字做完就永远不会再看。那样的话不如不做。真正有价值的FMEA应该在项目全生命周期里持续更新每发现一个新故障模式就追加上去它最后会变成一本活的经验库。6.2 现场调试最容易被误导的三种假象多年调试经验里我反复遇到过几种看起来像软件问题其实是硬件问题的经典假象。第一种是偶发复位。现场报告设备时不时重启没有任何规律。第一反应通常是查代码、查任务异常、查内存越界。但在一个低温环境项目里我们排查后才发现复位的根因是现场接地桩的接地电阻随着季节变化从2欧姆升到了接近8欧姆导致干扰泄放路径失效干扰脉冲进入复位电路。从那以后我去现场调试第一件事就是量接地电阻和电源质量而不是急着看程序。第二种是通信时好时坏。这类问题最让人抓狂因为抓包时一切都正常拔插几次又复现。根因往往在连接器或线缆工业网线的弯折半径过小导致内部某根芯线接近断开连接器簧片老化导致接触电阻波动。这类问题用仪器抓波形往往抓不出来但用手去摆动线缆时症状就会出现。第三种是低温启动失败。设备在常温一切正常温度降到零下十几度就开不了机。排查发现电源模块的冷启动电路里有一颗电解电容低温ESR增大导致启动电流不足。这不是看原理图能发现的必须实测低温环境的电源波形才能看到。这三个案例的共同教训是遇到系统级问题先怀疑物理层再怀疑逻辑层。物理层的故障经常表现为软件现象的随机性、偶发性如果不从物理层入手排查效率会非常低。6.3 团队里的可靠性文化无责备、要根因、快闭环最后想聊一下人的因素。高可靠系统不是一个人能做的整个团队的做事方式决定了系统的可靠性水平。我们团队有两条铁律。第一条是无责备故障报告永远冲着根因去不许出现编写问题用户误操作这种结论型的甩锅词。第二条是根因导向每个问题至少要连续追问5个为什么一直到追出一个可以采取纠正措施的根本原因为止。比如设备偶发重启第一层为什么因为看门狗超时复位。为什么超时因为某中断处理函数执行时间超出了预算。为什么超出因为该函数里有个循环在特定输入下陷入长等待。为什么陷入等待因为某互斥锁被高优先级任务长时间占用。到这里才能定义出有效的纠正措施。每次故障闭环后还要做一件额外的事把故障场景加入自动化测试用例库。这样下次即使不是同一个人排障系统也会自动执行这类场景测试真发现问题时项目组第一时间就能感知。这种故障变测试用例的做法是我认为团队可靠性文化最好的落地方式。6.4 结尾一点个人体会做完了这个项目之后我对军工体系里的工控力量有了全新的理解。在那些看起来神秘的体系里真正起作用的东西并不神秘反而是非常朴素的一堆工程纪律承认故障会发生所以提前做冗余留足设计余量所以器件长期稳定用故障注入逼出问题所以现场不慌做长周期管理所以十年后系统依然可修可用。这些纪律每一条单拿出来都不难理解难的是把它们从项目开始那天就坚持下去而不是等出问题了再补救。如果让我给还在路上的同行一句建议那就是多保存测试现场的东西。每次高低温测试的波形截图、每次故障注入的时序记录、每次现场复位的时间戳都留好。当时看着没用三年后当你面对一个莫名其妙的偶发故障时这些历史数据就是排障最宝贵的线索。我的很多疑难问题最后都是靠翻几年前的测试记录找到突破口的。