3. 高可用控制系统的可用性指标与设计约束
在冗余与高可用控制工程中，“可用性”不是一句定性描述，而是一组可以计算、可以验证、可以写进设计规格的量化指标。PLCnext 冗余系统是否值得投入、冗余做到哪一级、维护窗口如何安排，最终都要回到 MTBF、MTTR 和可用率这三个基础量上。本节先建立指标之间的数学关系，再引入故障树分析，最后给出冗余等级的选型方法。
一、三个基础指标的定义与关系
MTBF（Mean Time Between Failures，平均故障间隔时间）描述系统两次故障之间的平均运行时长，反映“可靠性”，单位通常为小时或年。对可修复系统，MTBF 越大，说明系统越不容易坏。需要注意，MTBF 是统计量，来自元器件失效率数据（如 FITS 值）或现场运行统计，不是某台设备的承诺寿命。
MTTR（Mean Time To Repair，平均修复时间）描述从故障发生到系统恢复可用所需的平均时间，反映“可维护性”。它包含故障检测、诊断定位、备件获取、更换或修复、重新投运的全部时间。在冗余系统中，MTTR 的关键在于“能否在线更换”和“诊断是否精确”。
可用率 A（Availability）是系统在任意时刻处于可工作状态的概率，稳态下用下式计算：
A = MTBF / (MTBF + MTTR) × 100%
不可用率 U = 1 - A = MTTR / (MTBF + MTTR)这个公式揭示了一个重要工程结论：提高可用率有两条路——提高 MTBF，或降低 MTTR。当 MTBF 已经很高时，继续提升它的边际收益递减，而缩短 MTTR 往往更经济。例如某单机 PLC 系统 MTBF = 100000 h，MTTR = 8 h，则 A = 100000/100008 ≈ 99.992%，年停机约 0.7 h；若把 MTTR 压缩到 1 h，A ≈ 99.999%，年停机降到约 0.09 h。冗余架构的价值，本质上就是把“故障后修复”变成“故障后切换”，从而把 MTTR 从小时级降到毫秒级。
二、冗余系统的可用率计算
冗余结构不同，可用率模型也不同。设单通道可用率为 A₁，则：
- 串联（无冗余）：A = A₁ × A₂ × …，任一环节故障即系统失效。
- 并联（1oo2 热备）：A = 1 - (1 - A₁)(1 - A₂)，两通道同时故障才失效。
- 2oo3 表决：A = 3A₁² - 2A₁³，允许一通道故障仍正常工作。
以 A₁ = 0.99 为例：串联 A = 0.99；1oo2 并联 A = 1 - 0.01² = 0.9999；2oo3 表决 A = 3×0.9801 - 2×0.970299 ≈ 0.9997。可见冗余对可用率的提升是非线性的，但前提是共因故障（Common Cause Failure）被有效抑制——如果两个通道共用同一电源、同一网络或同一固件缺陷，并联模型就退化为串联模型。因此冗余设计必须关注物理隔离、独立供电、异构诊断和共因失效分析。
三、故障树分析（FTA）
故障树分析从“顶事件”（如“控制系统失去输出”）出发，逐层向下分解为中间事件和底事件，用逻辑门连接。与可用率公式相比，FTA 的优势在于能识别单点故障和共因路径。典型顶事件“CPU 冗余失效”可分解为：主 CPU 故障 AND 备 CPU 故障（与门），或主备切换失败 OR 同步链路中断（或门）。底事件包括电源模块失效、同步光纤断裂、切换逻辑缺陷、看门狗误动作等。
工程上常用最小割集判断薄弱环节：若某底事件单独出现即可导致顶事件，它就是单点故障，必须消除或降级。FTA 的定量结果可反哺 MTBF 估算，与可用率计算形成闭环。
四、设计约束与选型方法
可用率目标一旦确定，就转化为设计约束。假设工艺要求年可用率不低于 99.99%（年停机 ≤ 52.6 min），单机 MTBF = 100000 h、MTTR = 8 h 时 A ≈ 99.992%，看似达标，但这是“平均”结果，实际一次故障就可能停机 8 h，远超预算。因此必须引入冗余，把故障影响时间从 MTTR 压缩到切换时间。
冗余等级选择可按以下逻辑推进：
- 确定停机预算：由工艺、安全、合同或法规给出年允许停机时间，换算为可用率下限。
- 评估故障后果：若失效可能导致人身伤害或重大环境事故，需按 SIL/PL 要求选择 1oo2 或 2oo3 结构。
- 识别共因故障：检查电源、网络、时钟同步、固件版本、机柜环境是否共用；共用项必须隔离或增加多样性。
- 计算并验证：用并联/表决公式估算 A，再用 FTA 找单点故障，若存在单点则降级或补强。
- 核算全生命周期成本：冗余带来的硬件、备件、工程和运维成本，应与停机损失比较。
综上，MTBF、MTTR 与可用率构成高可用设计的量化基础，故障树分析用于暴露单点与共因路径，冗余等级选择则是把停机预算、安全要求和成本约束统一到架构决策上的过程。三者结合，才能让“高可用”从口号变成可验证的工程指标。