4、介质冗余（Media Redundancy）：MRP协议在EtherCAT中的应用
说到工业网络的可靠性，环网冗余是个绕不开的话题。我个人习惯把EtherCAT的冗余方案分成两类：一类是设备级的冗余，另一类就是今天要聊的介质冗余。说白了，介质冗余解决的是“线断了怎么办”的问题。
你想想看，在一条流水线上，如果某根网线被叉车压断了，或者某个连接器松动了，整个网络就瘫了。生产停摆一分钟，损失可能就是几万块。所以，我们需要一种机制，让网络在物理链路出问题时，还能继续工作。
4.1 MRP协议在EtherCAT中的应用
MRP，全称Media Redundancy Protocol，是IEC 62439-2标准里定义的一种环网冗余协议。它最早是为PROFINET设计的，但后来也被EtherCAT采纳了。为什么？因为它的恢复速度够快，而且实现起来相对简单。
MRP的工作原理，其实有点像“逻辑断路”。正常情况下，环网中有一个节点被指定为“冗余管理器”（Redundancy Manager，简称RM），它会阻塞其中一个端口，防止数据在环里无限循环。当链路断了，RM会检测到，然后立刻打开那个阻塞的端口，让数据从另一条路走。
核心要点：MRP的恢复时间通常在10ms到200ms之间，具体取决于环网的大小和节点数量。对于大多数工业应用来说，这个速度已经足够了。
我在项目中遇到过这样一个场景：一个汽车焊装车间，用了30多个EtherCAT从站，组成了一个环网。刚开始用的是普通的星型拓扑，结果一个月内因为线缆问题停了三次产。后来改成了MRP环网，虽然恢复时间在50ms左右，但再也没有因为单点故障导致全线停摆。
MRP在EtherCAT中的配置要点
- 冗余管理器（RM）：通常由主站或一个专用的交换机担任。我个人建议把RM放在主站上，这样管理起来方便。
- 冗余客户端（RC）：环网中的其他节点都是客户端，它们只需要转发MRP报文即可。
- 环网端口：每个节点需要有两个端口，一个接环的“左臂”，一个接“右臂”。
- 测试报文：RM会定期发送测试帧，检查环的完整性。如果收不到，就认为链路断了。
我的经验：配置MRP时，一定要把环网的最大节点数算清楚。有些交换机的MRP实现有节点数量限制，比如最多支持50个节点。我曾经因为没注意这个，导致环网在扩容后无法正常工作。
4.2 MRPD（介质冗余协议）详解
MRPD，全称Media Redundancy for PROFIsafe and PROFINET with MRPD，是MRP的增强版。它解决了MRP的一个痛点：在环网切换期间，数据包可能会丢失。
为什么会这样？因为MRP在切换时，需要先检测到故障，然后重新配置端口。这个过程需要时间，而在这段时间里，正在传输的数据帧就丢了。对于普通IO数据，丢几帧可能问题不大，但对于安全相关的数据（比如急停信号），丢一帧都可能引发事故。
MRPD的做法是：在发送数据时，同时往环的两个方向各发一份。这样，即使环上某处断了，数据也能从另一个方向到达目的地。说白了，就是“双路径冗余”。
MRPD的关键特性：
- 无切换时间：因为数据本来就是双份发送的，所以链路断了也不需要切换，数据自然从另一条路走。
- 零丢包：理论上，MRPD可以做到在链路故障时完全不丢包。
- 带宽翻倍：代价是每个数据帧都要发两遍，所以网络带宽的利用率会降低一半。
我记得有一次给一个半导体工厂做方案，客户要求环网切换时不能有任何数据丢失，因为他们的设备对时序要求极高。MRP肯定不行，最后我们上了MRPD。虽然带宽占用高了一些，但客户验收时非常满意。
MRPD与MRP的对比
| 特性 | MRP | MRPD |
|---|---|---|
| 恢复时间 | 10ms - 200ms | 0ms（无切换） |
| 丢包率 | 切换期间可能丢包 | 零丢包 |
| 带宽利用率 | 正常（单路径） | 减半（双路径） |
| 实现复杂度 | 低 | 高 |
| 适用场景 | 普通IO控制 | 安全通信、高实时性要求 |
注意：MRPD需要主站和从站都支持。目前只有部分高端EtherCAT从站控制器（ESC）支持MRPD。选型时一定要确认芯片型号。
4.3 环网恢复时间测试
理论说得再好，不如实际测一测。环网恢复时间，是衡量冗余方案好坏的核心指标。我一般用两种方法测：一种是软件打时间戳，另一种是用示波器抓信号。
测试方法一：软件打时间戳
这种方法比较简单。在主站上跑一个测试程序，每隔1ms发一个数据帧，并记录发送时间。然后在从站上接收，也记录接收时间。当环网断开时，从站会有一段时间收不到数据，这个时间差就是恢复时间。
// 伪代码示例
// 主站发送端
while(1) {
send_frame(timestamp);
sleep(1ms);
}
// 从站接收端
while(1) {
frame = receive_frame();
if (frame.timestamp - last_timestamp > 2ms) {
// 检测到中断
recovery_time = frame.timestamp - last_timestamp - 1ms;
printf("Recovery time: %d ms\n", recovery_time);
}
last_timestamp = frame.timestamp;
}我的习惯：测试时，我会故意在不同位置断开链路，比如在RM旁边断一次，在环的最远端断一次。因为不同位置的断链，恢复时间可能会有差异。
测试方法二：示波器抓信号
这个方法更精确。在从站的IO输出口接一个示波器，然后让主站周期性翻转这个IO。当环网断开时，IO会停止翻转，直到网络恢复。示波器上就能看到一段“平线”，这段平线的长度就是恢复时间。
我曾经用这个方法测过一个MRP环网，结果发现恢复时间比理论值大了不少。后来排查发现，是其中一个从站的固件版本太旧，处理MRP报文的速度太慢。升级固件后，恢复时间就正常了。
测试结果参考
| 环网节点数 | MRP恢复时间（典型值） | MRPD恢复时间 |
|---|---|---|
| 10个 | 10ms - 30ms | 0ms |
| 30个 | 30ms - 80ms | 0ms |
| 50个 | 50ms - 150ms | 0ms |
| 100个 | 100ms - 200ms | 0ms |
避坑指南：我曾经遇到过一个问题：环网恢复时间测试结果忽大忽小，不稳定。后来发现是测试时网络上有其他流量干扰。所以，测试时一定要确保网络是“干净”的，最好只跑测试数据。
嗯，关于介质冗余，今天就聊到这里。MRP和MRPD各有各的适用场景，选哪个取决于你的项目对实时性和可靠性的要求。下一章，我们会聊聊设备级冗余，也就是如何让主站或从站本身也具备冗余能力。