题目：
今天写一个现场很容易遇到、但很多程序没有认真处理的小功能：多路传感器表决器。
压力、温度、液位、流量这些重要过程量，有时不会只装一只传感器。为了提高可靠性，设备可能会安装 3 只传感器，同时采集同一个过程变量。
问题也随之而来：3 个数值不一样时，到底信谁？如果程序直接把 3 个数值平均，坏掉的那一路就会把结果往错误方向拉。现场最后看到的是一个“看起来平滑、实际不可信”的数据。
本例用 SCL 写一个 2oo3 表决器。2oo3 的意思是 3 路信号中至少有 2 路彼此接近，才认为结果有效；如果有 1 路明显偏离，就使用另外 2 路，同时把异常通道指出来；如果找不到可靠的 2 路，输出直接判无效。
这个思路适合做过程量冗余诊断，也适合用来讲清楚一个工程原则：数据处理不能只有计算结果，还要把“这个结果是否可信”一起给出来。
设计分析：
3 路传感器完全相等，在真实现场几乎不可能。传感器精度、量程、安装位置和采样时刻都会带来一点差异，所以表决器不能要求它们一模一样，而要设置一个允许偏差 tolerance。
本例采用下面的判断顺序：
3 路都有效，并且最大值与最小值的差不超过 tolerance：3 路平均，结果有效，状态健康。
存在 2 路有效信号，并且这 2 路差值不超过 tolerance：取这 2 路平均，结果有效，但保留通道异常或冗余降级报警。
3 路都有效，但只有某一对信号彼此接近：取最接近的一对，另一通道标记为异常。
找不到任何一对满足偏差要求的信号：结果无效，置位 insufficientAlarm，后续控制逻辑不能继续盲目使用。
这里的 2oo3 是应用层的数据表决逻辑，不等同于经过认证的安全仪表系统或安全功能。涉及安全保护时，还要按照项目的安全架构、风险评估和相关规范设计。
创建功能块：
本例创建一个 FB，命名为：
SensorVoter2oo3
为什么用 FB？
本例的表决计算本身可以写成 FC，但 mismatchAlarm 和 insufficientAlarm 需要保留报警痕迹，使用 FB 可以把报警锁存状态放在实例 DB 中。以后同一套逻辑要用于压力、液位和温度，只需要分别调用不同实例即可。
定义接口变量：
定义输入变量：
enable：功能使能。
reset：报警复位。建议先恢复传感器条件，再执行复位。
sensor1/sensor2/sensor3：3 路传感器的工程值，类型为 LReal。
sensor1Valid/ sensor2Valid/sensor3Valid：对应通道的数据有效标志，可以来自模拟量诊断、通信状态或质量码。
tolerance：允许的最大偏差，例如压力单位为 bar 时，可以设置为 0.20。
定义输出变量：
outputValid：表决结果是否有效。
votedValue：表决后的过程值。
validSensorCount：当前有效传感器数量。
maxDeviation：当前有效信号中的最大偏差。
allHealthy：3 路都有效且彼此一致。
mismatchAlarm：存在有效但不一致的通道，报警锁存。
insufficientAlarm：没有找到满足要求的 2 路信号，报警锁存。
selectSensor1/2/3：本次表决实际采用了哪些通道。
badSensor1/2/3：当前被判定为无效或偏离的通道。
程序代码：
第一部分：
第二部分：
第三部分：
调用方法：
可以建立一个全局 DB，命名为：
GdbSensorVoter
在 DB 中定义实参变量：
在 OB1 或设备主 FB 中调用：
一个小例子：
假设 3 只压力传感器的当前值如下，允许偏差 tolerance 设置为 0.20 bar。
情况一：Sensor1 = 5.00，Sensor2 = 5.04，Sensor3 = 5.02。最大偏差只有 0.04，3 路全部参与平均，votedValue 约为 5.02，AllHealthy 为 TRUE。
情况二：Sensor1 = 5.01，Sensor2 = 5.03，Sensor3 = 6.30。Sensor1 和 Sensor2 的差值只有 0.02，Sensor3 明显偏离。程序使用前两路平均，BadSensor3 为 TRUE，同时 MismatchAlarm 锁存。
情况三：Sensor1 = 5.00，Sensor2 = 6.10，Sensor3 = 8.00。任意两路的差值都超过 0.20，程序无法确认哪两路可信，OutputValid 为 FALSE，InsufficientAlarm 为 TRUE。
注意，情况二虽然有有效输出，但它已经不是“3 路健康运行”，而是“2 路表决、1 路异常”。控制程序可以继续使用 votedValue，也应该根据项目风险决定是否降载、停机或等待维护。
代码测试：
调试时可以用监控表逐组修改输入值，建议至少覆盖下面几组测试：
3 路输入都在允许偏差内，确认 OutputValid 和 AllHealthy 为 TRUE，3 个 Select 信号都为 TRUE。
只让 Sensor3 偏离，确认输出仍采用 Sensor1 和 Sensor2，BadSensor3 和 MismatchAlarm 正确置位。
把 Sensor1Valid 置 FALSE，确认有效数量变为 2，程序仍能在 Sensor2 和 Sensor3 接近时输出有效值。
让 3 路输入互相差异很大，确认 OutputValid 为 FALSE，InsufficientAlarm 置位，不能输出一个伪造的平均值。
恢复输入后执行 Reset，确认锁存报警可以清除；如果传感器条件没有恢复，报警应当重新出现。
把 tolerance 设置为负数或极小值，确认程序的边界处理和报警行为符合预期。
工程注意事项：
第一，不要把 3 路模拟量直接平均。
直接平均是最容易写的算法，但它没有处理异常值。一路传感器断线、量程溢出或通信数据卡住时，平均值可能仍然看起来很“正常”。
第二，tolerance 要按工艺和仪表精度确定。
允许偏差太小，正常的测量误差也会频繁报警；允许偏差太大，异常值又可能混进结果。这个参数不能凭感觉填，要结合量程、精度、过程波动和现场调试记录。
第三，有效标志和数值偏差是两层诊断。
sensorValid 解决“这一路数据在通信和硬件层面是否可用”；tolerance 解决“几路可用数据在过程值上是否互相一致”。两者不能互相替代。
第四，表决结果要和报警分开使用。
OutputValid 表示当前是否有可用结果，MismatchAlarm 表示冗余已经降级，InsufficientAlarm 表示无法形成可靠结果。不要只给 HMI 一个 Online 或 Good 标志，把这些信息揉成一个 Bool。
第五，表决器不能代替动作联锁。
即使 votedValue 有效，后续设备动作仍然要经过上下限、超时、阀位反馈、急停和工艺联锁判断。表决器只负责给出较可信的过程值和诊断信息。
常见问题：
第一，只有一路有效时还继续输出。
2oo3 的核心就是至少要有两路相互支持。只剩一路时，程序可以把它显示给维护人员参考，但不应该把它当成自动控制的可靠输入。
第二，出现异常通道后自动把报警清掉。
如果第三路传感器恢复，程序可以重新得到有效输出，但故障痕迹是否保留，要根据设备风险决定。重要设备一般建议保留锁存报警，让维护人员知道冗余曾经降级。
第三，只显示 votedValue，不显示采用了哪两路。
调试时最关键的问题往往不是结果是多少，而是程序为什么相信这个结果。SelectSensor1、SelectSensor2 和 SelectSensor3 能让 HMI 和监控表直接看到表决路径。
第四，把安全保护完全交给普通 PLC 里的一个 FB。
普通控制程序里的表决逻辑可以提高工程可靠性，但不能自动变成安全认证功能。安全相关项目必须单独核对硬件、软件、诊断覆盖率和验证要求。
老炮儿建议：
如果项目里有多组冗余传感器，建议把 sensorValue、valid、tolerance、votedValue、badChannel 和 alarm 统一封装成 UDT，再给每一组传感器分配一个 FB 实例。
HMI 至少显示 VotedValue、OutputValid、ValidSensorCount、MaxDeviation、AllHealthy、MismatchAlarm、InsufficientAlarm 和三个 BadSensor 状态。
对动态变化很快的过程量，可以在表决前增加合理的采样保持或变化率诊断，但不要用过度滤波掩盖真实故障。
现场参数修改要有权限和记录。tolerance 不是普通画面参数，改得太大可能直接改变设备的故障判断边界。
在设备说明书和调试记录里写清楚：什么情况下允许降级运行，什么情况下必须停机。程序给出状态，工程师还要给出处理规则。
总结：
本例用 SCL 写了一个 2oo3 多路传感器表决器。
它没有把 3 路数据简单平均，而是先检查有效数量，再寻找满足 tolerance 的可靠信号对；3 路一致时取 3 路平均，1 路偏离时取另外 2 路平均，找不到可靠信号对时直接判无效。
这个例子真正有价值的地方，不只是算出了 votedValue，而是同时告诉我们：结果是否有效、当前用了哪几路、哪一路可能异常、报警是否曾经发生。
在 PLC 工程里，可靠的数据处理通常不是把公式写得多复杂，而是让程序在数据不可信时，明确地说“不可信”。
实例分享链接：
https://pan.quark.cn/s/d4920d40d62f
下一主题
