PLC故障诊断汇总逻辑解析与ST语言移植实践

一、问题背景：这段程序为什么“看不懂”

在PLC开发中，故障诊断与汇总是一类高频出现的经典逻辑。这段代码之所以显得晦涩，通常有三个原因：

1. 表达风格偏底层。代码采用指令表（IL，Instruction List）风格编写，围绕累加器、地址寄存器和逻辑结果状态位组织运算，程序行为分散在多条指令之间，不像结构化文本那样“一行表达一个完整语义”。
2. 大量使用间接寻址。程序并非直接访问某个具名变量，而是先把地址寄存器指向某个数据区，再通过“寄存器+偏移量”的方式读取数据，访问目标要到运行期才能确定。
3. 位级操作密集。掩码、按位与、与零比较等操作以32位双字为单位进行，读者必须同时理解“位编码的含义”和“指令的语义”才能还原设计意图。

下面按照“整体数据流—逐段拆解—ST标准实现—工程化改进—调试验证”的顺序，完整还原这段逻辑。

二、整体逻辑鸟瞰：一条三级故障处理流水线

抛开具体指令，这段程序做的事情可以概括为一条三步流水线：

• 采集：从状态数据区读取原始状态双字，从补充故障区读取补充状态双字；
• 判定：对基础状态字做“非零检测”得到基础故障；对补充状态字先做掩码过滤再做“非零检测”得到附加故障；
• 汇总：把两类故障做逻辑或，得到最终的总故障状态。

用数据流示意：

原始状态双字 ──(与0比较)──> 基础故障标志
补充状态双字 ──(AND掩码 → 与0比较)──> 附加故障标志
基础故障 OR 附加故障 ──> 总故障状态

三、逐段拆解

3.1 基础故障检测：间接寻址 + 非零比较

程序首先将地址寄存器定位到某个状态数据区，然后以“寄存器+零偏移”的方式读取一个双字（32位）。在这类设计中，双字中的每一个位通常对应一个被监控对象的状态：0表示正常，1表示异常。

随后将读到的双字与0比较，意义非常直接：只要32位中有任意一位被置1，就说明至少一个监控对象异常，于是判定为“基础故障”。

在指令表语言中，比较指令会更新一个“逻辑运算结果”状态位，后续的赋值指令把这个状态位写入变量。等号在这里并不是数学等式，而是“把当前逻辑结果存储下来”的动作，语义上等价于结构化文本中对布尔变量的赋值。因此，“比较+赋值”两步在ST中可以合并为一个布尔表达式。这也是两种语言思维方式的根本差异：指令表是“指令驱动、状态位接力”，ST是“表达式驱动、一步到位”。

3.2 附加故障检测：指针重定位 + 掩码过滤

这是整段代码最有技术含量的部分。程序先把地址指针重新定位到“补充故障”数据区，然后对读到的双字执行一次按位与运算，掩码为16#FFFF_FF00。

该掩码的二进制形态是：高24位全为1，低8位全为0。按位与的结果是：低8位被无条件清零，只有高24位保留原值。可以把它想象成在一排32个开关上盖了一块只露出高24个开关的模板，低8个开关无论处于什么状态，后续逻辑都“视而不见”。

为什么要这样设计？工程上常见动机有三：

1. 分级处理：低8位可能存放提示级、预警级信息（例如通信延迟、轻微偏差），它们需要被记录或显示，但不应该触发“附加故障”这种需要上报的级别；
2. 保留位屏蔽：低8位可能是协议保留区或调试区，其内容不具备稳定语义，直接参与判断会造成误报；
3. 语义对齐：低8位可能另作他用（如故障分类编号），真正的“故障位集合”存放在高24位。

掩码过滤之后，程序再次与0比较：如果高24位中还存在至少一个1，就判定存在“附加故障”。换句话说，这个判断等价于“补充状态字的高24位是否非零”。

3.3 汇总上报：一次逻辑或完成分类合并

最后用逻辑或把两个中间结论合并：只要基础故障与附加故障中任意一个成立，总故障状态即被置位。

值得注意的是这里的三层变量设计：

• 检测结果变量：直接反映某一路判定的布尔结论；
• 传输结构体成员：把各路故障归档到统一结构体，便于整体传递给界面层、记录层或跨程序块调用；
• 汇总状态位：只关心“系统有没有故障”这一最终结论。

这种“分项检测—结构化归档—最终汇总”的分层写法，是故障管理类程序的常见范式：分项结果服务于定位与显示，汇总结果服务于联锁、停机等控制动作。

四、ST语言的标准实现

将上述逻辑翻译为结构化文本：

// 1. 基础故障：状态双字任一位非零即判定
IF dwStatusRaw <> 16#0 THEN
    #Fault          := TRUE;
    #Transfer.Fault := TRUE;
ELSE
    #Fault          := FALSE;
    #Transfer.Fault := FALSE;
END_IF;
// 2. 附加故障：先按位与掩码过滤低8位，再做非零判断
#ExtraFault          := (dwSupplementRaw AND 16#FFFF_FF00) <> 16#0;
#Transfer.ExtraFault := #ExtraFault;
// 3. 汇总：任一分类故障成立即总故障
#Status.Fault := #Transfer.Fault OR #Transfer.ExtraFault;

与指令表版本对照可以明显看到ST的优势：每个语义单元对应一条赋值语句，不存在累加器、状态位接力等中间概念，比较结果直接就是布尔表达式。

五、工程化改进建议

直接翻译只是第一步，落到真实项目中还可以进一步优化：

5.1 消除魔数，集中定义常量

掩码16#FFFF_FF00属于典型的“魔数”，含义只存在于作者脑中。建议将其定义为具名常量并补充注释：

VAR_GLOBAL CONSTANT
    MASK_SUPPLEMENT : DWORD := 16#FFFF_FF00; // 保留高24位故障位，屏蔽低8位（低8位为提示级/保留区）
END_VAR

5.2 封装为功能块，参数化复用

把检测与汇总逻辑封装成功能块，输入输出显式声明，便于多设备复用与单元验证：

FUNCTION_BLOCK FB_FaultAggregator
VAR_INPUT
    dwBaseStatus : DWORD; // 基础状态双字：任一位非零即基础故障
    dwSupplement : DWORD; // 补充状态双字：低8位被掩码屏蔽
END_VAR
VAR_OUTPUT
    bBaseFault  : BOOL;
    bExtraFault : BOOL;
    bTotalFault : BOOL;
END_VAR
bBaseFault  := (dwBaseStatus <> 16#0);
bExtraFault := (dwSupplement AND MASK_SUPPLEMENT) <> 16#0;
bTotalFault := bBaseFault OR bExtraFault;

5.3 面向扩展的汇总写法

当故障源从一个扩展到多个时，用数组加循环替代手工罗列：

bTotalFault := FALSE;
FOR i := 0 TO 7 DO
    bTotalFault := bTotalFault OR (aStatusWord[i] <> 16#0);
END_FOR;

5.4 增加故障定位与防抖

• 定位：在“有故障”之后，往往还需要回答“是哪一位”。可通过移位配合逐位检测，输出最低置位位序号作为故障编号，供界面与记录使用；
• 防抖：对判定结果增加确认时间窗（例如持续为真若干扫描周期才置位），避免瞬时干扰引起联锁误动作。

六、调试与验证要点

1. 用例覆盖：至少构造四类输入——全零（应无故障）、仅低8位置位（应被掩码屏蔽、无附加故障）、仅高24位置位（应有附加故障）、高低同时置位（基础与附加同时成立）；
2. 分步观测：在线监控时优先观察中间布尔量（基础故障、附加故障），再核对汇总位，出问题时能快速区分是“判定错”还是“汇总错”；
3. 平台差异确认：双字的字节序、十六进制字面量的书写格式在不同开发环境可能存在差异，跨平台移植时应先确认字面量与位排列约定；
4. 文档同步：掩码每一位的含义应形成位定义表并与代码注释保持一致，这是故障类程序长期可维护的关键。

七、小结

这段“看不懂”的程序，本质上是一个“位集合的非零检测 + 掩码分类过滤 + 布尔或汇总”的三段式故障管理逻辑。读懂它的关键在于三点：理解间接寻址下“读出的是什么数据”、理解掩码运算“保留了哪些位、丢弃了哪些位”、理解指令表中“比较+赋值”与ST布尔表达式的等价关系。迁移到ST语言后，逻辑收敛为三个表达式，可读性、可测试性与可扩展性都显著提升；再辅以常量定义、功能块封装、循环汇总与防抖设计，就能把一段晦涩的示例代码升级为规范、健壮的工程级故障诊断模块。