PLC

PLC 项目先列 10 种坏法：逆向设计比功能清单更能救命

最可靠的自动化项目不是从功能清单开始，而是从失败清单开始：「这条线必须坏的话，它会怎么坏？」十种坏法、三道余量、一次真事复盘。

我见过的最可靠的自动化项目，没有一个是从功能清单开始的。它们从失败清单开始。

在任何人画出顺序、给 PLC 变量起名之前，团队和操作员、维修人员、几位工程师坐在一起，问了一个有点尴尬的问题：如果这条线必须坏，它会怎么坏？

不要问理论上的答案。要问这条产线、这个产品、周五深夜——夜班人手不够、备件柜半空——的时候，它会怎么坏。

这个问题就是逆向思考（inversion）。Carl Jacobi 曾对学生说：「反过来想，永远反过来想。」查理·芒格后来把这个想法带出数学圈：不要只问怎么成功，要问什么会让你失败，然后拒绝那些东西。在工厂里，这个习惯胜过多十页顺利路径的逻辑。

从「它怎么坏」开始

失败清单不是躺在共享文件夹里没人看的风险登记表。它是一组短小、难看的场景，团队能在脑子里看见。比如：冲洗之后一个传感器卡在「高」。一个堵料检测被「临时」旁路之后，输送机在堵料后继续运行。一次配方下载只完成一半，整批产品一半用旧参数、一半用新参数。一个阀门打开了，但反馈线断了，HMI 上显示的还是「关闭」。

用大白话把这些场景写下来。按它们发生的频率和造成的损失排序。先针对排在前面的那些做设计。不能防住某个具名故障的特性，可以往后放。

把失败清单贴在设计评审的墙上。对话就不再是对着屏幕做巡礼，而是走过这条线可能伤人、出废品、或者停一个班次的每一种方式。

把逆向思考和安全余量配对

逆向思考告诉你该避开什么。安全余量告诉你：当你错了的时候，还留有多少空间。

Benjamin Graham 在投资里用这个说法：在你认为某样东西值多少之下留一道缺口，这样一次错误不会把你清零。工程师本来就知道这件事。一座标称十吨的桥，不是按「十吨半才垮」来建的。

在自动化产线上，一切平静的时候，这道余量看起来像浪费：一道互锁在零件损坏之前就拒绝这个循环；一小段缓冲区，让短暂的上游停机不至于级联；对关键状态的第二次确认，因为传感器会脏；一个操作员信任的安全停止，这样他们会用它，而不是去跨接一根线。

在同一次评审里问两个问题。什么会让它必然失败？以及，哪里有空间让我们犯错而不出废品、不伤人？如果第二个问题的答案是「我们希望它别发生」，那么你还没有设计，你只有一个愿望。

为「来恢复它的人」做设计

硬件和软件会失效。人来恢复，或者恢复不了。

恢复得最快的操作员，不是背下所有报警码的那些人。他们理解这个系统为什么存在：这道互锁保护的是什么，把线留在哪个状态是安全的，哪一种「快速修一下」会在明天制造更糟的故障。当操作员参与了失败清单的编写，他们早就认识这些场景。压力之下，他们认得出那个「堵料旁路」的故事。

用失败清单来训练恢复，而不是只训练顺利路径。带人走一遍那些永远不能变成永久的旁路。用夜班自己的话解释一次停机的原因。留下一条写下来的、回到已知良好状态的路径。

我曾经在一次长时间的停机之后，和一支夜班团队坐下来。起因是一个「临时」旁路——它已经活了几个星期。它当初是为了解决某个忙碌日子里一个吵闹的传感器，而失败清单里从来没有写过这条路。从那以后，每次评审都会问：还有哪些临时改动活着，它们掩盖了哪个故障？

下一个旁路，白板上带了失效日期。

一个简短的练习

在一个工位或一个顺序上做这件事：

写下这套自动化在一个糟糕班次上的十种坏法。用车间的语言，不要用厂商的语言。
标出伤害最大的三种。先针对这三种做设计或修改。
为每一种各指名一道余量：额外确认、缓冲、互锁，或者一个明确的安全状态。
请一位操作员把这三种的恢复过程各走一遍。改设计，直到这一遍走下来无聊为止。

逆向思考不会让自动化变得悲观。它让自动化变得诚实。真实车间里的失效模式，比事先画出的完美成功路径更容易看见。先研究它们，为「会错」留出空间，再给运行这条线的人一条回来的路。

工业自动化赢得信任，不是靠承诺它永不失效，而是靠表明：它在设计时就考虑过失效。

我们的整理：把「失败清单」落成 TIA 项目里能查的东西

原文是方法论，落地要具体。把它的十个场景映射到博途工程里可以逐项核对的位置：

原文的场景	在 TIA 项目里查什么
传感器卡在「高」	每个数字量输入是否有「卡死」判据（信号长时间不变 + 工艺不可能持续为真）
「临时」旁路	工程里是否存在被短接的互锁；旁路是否有条件、有失效日期、有记录
配方下载只成功一半	配方写入是否成组提交、失败是否回滚；旧值/新值混用能否被检测
反馈线断了、HMI 显示关闭	状态显示取自命令还是取自反馈；反馈超时如何呈现
顺序卡在某一步	是否有步超时与步监护，超时后是停在那一步还是回到安全步
手动/自动切换瞬间	切换时输出是否保持；是否要求先回到安全位置
断电再来电	上电后是否自动续跑；哪些输出需要重新确认才允许启动
两个写点写同一个输出	同一变量在多少个块里被写；扫描顺序是否决定结果
报警被淹没	首出报警能否识别；报警是否分级并锁存
恢复路径不存在	是否有「回到已知良好状态」的显式步骤，而不是靠人记

三个判断法，比清单本身更耐用：

能防住的故障，必须有一个具名的检查点。 说不清「哪个块、哪一行、哪条判据在防它」，就等于没防。
临时改动的存活时间要可见。 旁路、强制、注释掉的互锁，都要有到期日和复核人。
恢复流程要被走过一次，而不是被写过一次。 让真正值夜班的人走一遍，走完不觉得吃力，才算设计完。

如果想让这套清单在接手遗留项目时更快成型，可以先让工具把工程的调用关系、同符号的读写点与悬空引用整理成一张图（我们做这件事的入口是 TiaLink，它在本机读工程、只读不改、不上传项目文件），再对着上面这张表逐项问：哪个块在写这个输出、这条互锁被谁短接、这个报警位从哪里来。清单负责问对问题，知识图谱负责给出可核对的答案。

来源：Inversion: Designing Industrial Automation By Studying How It Fails（Dr. Krisztián Galánthai Fekete，Automation World，2026-11-09。作者是《Find Your Meaning in 60 Days, In the Age of AI and Robotics》一书的作者）。

本文由汇智网 · Software 2.0 编译整理，转载请注明出处。