提到冗余PLC，人们很容易想到一个直观结构：两台控制器，一台运行，一台备用，主机故障后，备机立即接管。但真实工业现场的故障，很少像一道只有“正常”和“损坏”两个选项的判断题。有时，CPU已经停止正常运行，却仍然保持供电；有时，只是通信光缆短暂中断，控制器本身并没有故障；有时，主备CPU之间失去联系，但主CPU依然能够控制现场设备；还有些异常只是网络瞬时抖动，几毫秒后就恢复正常。当备用CPU收不到主机信息时，它首先面对的问题不是“怎样切换”，而是主CPU真的失效了吗？中断的是控制器，还是通信链路？现在接管，究竟是在挽救系统，还是在制造新的风险？如果判断过于保守，备用机可能错过最佳接管时机；如果判断过于激进，一次普通的通信故障也可能触发CPU角色切换。

最危险的情况，是两台CPU同时认为自己是主机，并同时向现场设备发出控制指令。这种“双Active”状态通常被称为“脑裂”。在连续生产系统中，两个控制中心同时输出，比单台PLC停止运行更不可控。因此，衡量一套冗余系统是否成熟，不能只看它能不能完成主备切换，更要看它是否能够回答三个问题：为什么切、什么时候切，以及切换后怎样确保系统中始终只有一个控制中心。

冗余技术真正的门槛，就藏在这三个问题里。

为了让备用CPU能够在故障发生后直接接管，天行T426EH采用双CPU并行运行架构。两台独立的T426EH PLC通过自主研发的双冗余光缆连接。单根光缆最远支持10公里传输距离，最高同步速率可达1Gbps，两根光缆互为备份。其中一根链路发生异常，系统仍可通过另一根链路保持同步。更重要的是，备用CPU并不是停止运行、等待唤醒的冷备设备。主CPU与备用CPU并行执行同一套用户程序，程序变量、运行状态和中间结果通过冗余链路，在每个运行周期内持续同步。备用CPU始终知道系统执行到了哪一步，当前控制状态是什么，各项变量处于什么位置。主CPU一旦失效，备用CPU不需要重新加载程序，也不需要从初始状态重新计算，而是可以从当前运行位置继续接管控制。这也是毫秒级切换能够成立的基础。

T426EH冗余系统 系统架构示意图

T426EH冗余系统的主备切换时间最短可达到10毫秒，典型值不超过50毫秒。50Hz交流电的一个周期约为20毫秒，最短10毫秒的切换时间相当于半个交流电周期。在这段极短的时间内，系统已经完成从发现故障到接管控制的全过程，将控制中断对现场设备和生产工艺的影响压缩到最低。但速度只是结果。持续同步解决的是“能否接得上”，故障判断解决的才是“究竟该不该接”。

答案并不一定。假设两根冗余光缆同时失去通信，背后可能存在两种完全不同的原因。一种情况是主CPU整体失效，导致两条通信链路在极短时间内同时中断。此时备用CPU必须迅速接管，否则系统可能失去现场控制。另一种情况是，两根光缆因外部原因先后损坏，但主CPU仍在正常运行。如果备用CPU仅凭“通信中断”就直接转为Active，系统中就可能同时出现两个主机。为了区分这两类故障，T426EH引入了包括双缆故障判定阈值在内的多种判断机制。

当两根光缆在设定阈值内先后中断时，系统更倾向于判断主CPU整体失效，由备用CPU接管；当两根光缆断开的时间间隔超过阈值时，系统则倾向于判断为链路故障，备用CPU主动退至STOP状态，避免形成“双Active”。看起来只是一个时间差判断，背后实际上是在平衡两种风险：既不能因为迟疑而错失接管机会，也不能因为急于切换而制造控制权冲突。更极端的情况下，Active CPU可能已经崩溃，却没有完全断电，也无法向备用CPU发出明确的掉电信号。此时系统很难百分之百确认主CPU是否还具有控制能力。

天行T426EH冗余系统同时支持EtherCAT、Profinet、Profibus-DP和Modbus TCP四种主流总线，并覆盖主站冗余与通信介质冗余。但“支持四种总线”并不是把同一套方案复制四遍。不同总线服务于不同工业场景，其故障特点和冗余重点也并不相同。

EtherCAT面向高速、高实时性的新建产线。每台PLC可通过两个EtherCAT接口接入独立环网。当局部网络设备或多条线路发生故障时，系统仍可利用剩余路径维持从站控制。它重点解决的是高速通信场景下，局部链路故障不能演变成整线停机。

T426EH冗余系统 EC环网双冗余拓扑示意图

Profinet广泛应用于钢铁、汽车、食品饮料等大中型产线。然而，Profinet S2主站协议栈技术壁垒极高--其协议复杂度、实时性要求、兼容性适配，使全球能够完整实现S2主站冗余方案的厂商屈指可数，国内长期空白，完全依赖进口。

天行冗余系统率先打破这一局面，以国内首家自研Profinet S2主站通讯方案为底座构建起网络层与控制层分层解耦的冗余架构。网络线路或交换设备故障，由MRP环网完成重构;控制器故障，则由S2协议通知备用CPU完成接管。

S2协议栈源码级自主可控--每一行代码在自己手里，既不受制于国外厂商的授权排期与技术封锁，也不存在"能用但不可见、不可改、不可审"的供应链黑盒。

T426EH冗余系统 PN S2 骨干环网拓扑示意图

Profibus-DP更多存在于运行多年的老旧产线。此类现场往往线缆长、干扰复杂，通信介质故障概率可能高于PLC本体。T426EH通过冗余耦合器完成内部角色接管，单点通信故障不必频繁触发CPU切换，从而减少对原有生产系统的扰动。

T426EH冗余系统 DP R1拓扑示意图

Modbus TCP则更多服务于市政水处理、楼宇控制和分布式泵站等长距离通信场景。RSTP负责处理交换机和链路问题，PLC冗余负责处理控制器故障，一个保障通信路径，一个保障控制核心。

T426EH冗余系统 ModbusTCP 环网拓扑示意图

故障发生后，系统能否把影响限制在局部，而不是让一个点的异常扩散为整套系统停机。

冗余系统增加了控制器、通信链路、状态判断和切换逻辑，也天然增加了配置复杂度。但系统内部复杂，并不意味着用户操作也必须复杂。T426EH在软件中加入了同步参数联动机制。用户修改相关参数后，软件自动完成关联配置，减少参数不一致造成的同步异常。在硬件配置上，两台CPU的Rack号出厂时均可保持默认值。连接冗余光缆后，系统能够自动检测设备关系、修改Rack号并完成重启，无需工程师逐项设置。

系统还提供4个专用事件触发Task和2个专用功能块，允许用户根据实际工艺，自定义不同故障下的响应策略，并通过SCADA查看和控制冗余系统状态。如在生产高峰期，某台PLC发生异常后，可以由另一台PLC继续维持现场控制，同时让系统暂时保持单机运行，不立即开放再次切换，待生产低谷期再完成维修和冗余恢复。在轨道交通等场景中，也可以利用功能块主动执行CPU角色对调，在计划检修期验证备用系统是否真正具备接管能力。

故障判断由系统自动完成，工艺边界仍由用户定义。

冗余系统因此不再是固件中的“黑盒动作”，而成为可以监控、配置和验证的控制能力。全栈自主，意味着T426EH从硬件设计、实时操作系统、运行时、编译器到编程组态软件均由宝信软件自主研发，EtherCAT、Profinet、Profibus-DP和Modbus TCP协议栈也实现源码级可控。

对于普通产品而言，自主研发可能意味着减少授权依赖、降低成本或者加快迭代速度。但对于冗余控制系统而言，它还有更重要的一层价值：当故障跨越硬件、操作系统、任务调度、运行时和通信协议时，开发者能否看到完整的问题链路，并真正进入底层修改。

工业用户关心的不只是国产化比例，而是三个更实际的问题：

全栈自主并不自动等于安全可靠，但它为可靠性建立了一个完整的责任闭环。只有硬件、软件和协议均处于可控范围内，系统才能持续吸收现场经验，不断修正故障模型和判断策略。

再可靠的CPU也可能失效，再坚固的光缆也可能被破坏，再完善的网络也可能出现异常。冗余系统的意义是在问题发生之后，系统依然拥有明确状态、唯一控制权和可预测行为。

该切换时迅速接管，不该切换时保持克制；能够安全运行时保持连续，无法确认控制边界时有序停止；让自动化系统负责判断和执行，同时把最终策略交还给用户。从这个角度看，T426EH的价值并不只是两台CPU、两根光缆、10毫秒切换或者四种总线支持。

这些技术最终指向的是同一种能力：在最不确定的故障时刻，让工业系统作出确定的决定。真正的冗余，不只是多准备一台PLC。

它是在那个无法预测的“万一”到来之前，已经为生产准备好了另一条路。

更多信息，详见产品官网 

baosky.baosight.com