PLC 程序评审清单：7 类检查项、7 个证据要件与 P0–P3 分级

原创

用户1758543

修改于 2026-11-04 16:37:49

1040

一套跑了三年的博途程序，编译 0 错误、0 警告。投运第三天，空料位时进料输送机还在转，把箱子推到了不该去的地方。

编译器只查语法和一致性：块能不能调用、标签类型对不对、指令参数够不够。它不查"没箱子的时候这条带子该不该动"，也不查"这个阀只收到一个扫描周期（10 ms）的脉冲来不来得及动作"。这类跨网络的逻辑缺陷，只能靠投运前逐条过一遍。

下面是我在实际项目里用的审查方法：7 类检查项、每条发现的 7 个证据要件、一次反证、P0–P3 分级。整个过程只读，不改工程。

清单的作用是防止只看自己熟悉的方向。PLC 程序的缺陷分布很均匀，只盯时序的人会漏掉地址，只盯命名的人一条都会漏。

	类别	典型缺陷
1	结构与调用	块存在但从未被调用；调用条件恒为 0；同一 FB 被两处调用却共用一个实例 DB
2	状态与保持	置位没有配对复位；断电保持位未定义初值；停机再启动后执行器自启动
3	时序与扫描	双线圈（同一输出在多个网络被赋值，后者覆盖前者）；边沿存储位被多处复用；用 TON 做累计计时
4	互锁与安全	互锁只锁了自己的输出，没锁对方；急停被写成普通逻辑；安全回路只在硬接线里，程序完全不知情
5	数据与地址	类型越界（INT 当 REAL 用）；I/O 地址与硬件通道不一致；编译警告提示"使用了硬件中不存在的 I/O"
6	可维护性	命名与工艺不符；网络无注释；同一段逻辑复制三份，改一处漏两处
7	可测试性	逻辑依赖真实 I/O 电平才能进入分支；没有可注入的测试点，仿真跑不进异常路径

只写"这里不规范"的报告没人能修。每条候选发现都要能回答下面 7 个问题，缺一条就不进报告。

最后一条最容易被跳过，也最容易出错。

对每条"看起来像问题"的候选，先问三句，答不上来才保留：

反证过后，报告里只留能证实的部分。把"看起来像问题"当成"已确认的缺陷"，是这类审查里最常见的失败方式——它会让报告失去可信度，也会让真正 P0 的那条被埋在噪声里。

级别	判据	例子
P0	可能造成人身伤害或设备损坏，且已确认	急停只清输出不复位状态机，恢复后继续执行上一段动作
P1	会造成停机、错料、批量不良	三个网络同时驱动进料带，无料时也运行；左右链条可能同时动作
P2	特定条件下失效，或依赖外部补偿	出料执行器只得到一个扫描周期脉冲，电磁阀可能不动作
P3	待确认，需要工艺或硬件信息	程序内无急停逻辑（原机可能为硬接线安全回路）

早期的写法是把 P3 也写成 P1，报告看起来很吓人，然后没人再打开第二份。

报告里每条发现都要标注用的是哪一种验证，不能拿其中一种冒充另一种。特别地：编译结论只信编译器，不要拿文本导出代替真实编译——导出的 SCL/STL 文本里出现拼接伪影，看起来像语法错误，实际编译是 0 错误 0 警告。

审查阶段不改任何对象、不保存工程，报告末尾写明只读范围与时间。原因很实际：审查和修复混在一起，就分不清"这条缺陷是原本就有，还是改动引入的"。

修复是另一条流程，按级别排序、每条带验证方法。安全相关的结论必须由有资质的人复核——程序审查不能替代安全评审，也不能从"程序里没有"推出"设备不安全"。

这套清单可以直接当 MR / 评审模板用：7 类检查项做表头，7 个要件做列，反证三问做最后一道闸。老工程先只出报告、不改代码，通常一轮就能把 P0/P1 收敛。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。