多协议网关：一套传感器适配多种总线

关于多协议网关，先给结论：能直接选对应协议的传感器，就不要加网关。网关本质上是把两侧协议的数据做映射搬运，它不会凭空提高性能，反而必然带来三样东西：额外延迟、额外故障点、诊断信息断层。只有在少数确实无法直连的场景下，网关才是合理选择。本文说明网关的代价、适用边界与配置要点，协议与产品的对应关系见 总线型全系对比。

网关做了什么，代价是什么

网关内部通常是两个独立的协议栈加一块共享数据区：一侧作为从站接收传感器数据写入映射区，另一侧作为从站/主站把映射区数据交给上层主站。这个结构决定了它的三项固有代价：

• 延迟叠加且不确定。数据要经历"传感器侧周期 → 网关内部搬运 → 主站侧周期"三段。三段周期彼此异步，最坏情况下的端到端延迟接近三者之和，且抖动不可控。对闭环控制而言，不确定的延迟比固定的大延迟更难处理。
• 同步机制无法穿透。EtherCAT 的分布式时钟、Profinet 的 IRT 都只在本侧网络内有效，网关另一侧的采样时刻与之无关。凡是需要多轴严格同步的场合，网关方案基本不可行，机理见 EtherCAT 实时性揭秘：DC 同步与抖动。
• 诊断信息断层。传感器上报的故障（CANopen 的 EMCY、Profinet 的诊断报警）通常无法原样透传到另一侧协议，往往被压缩成映射区里的一个状态位，甚至直接丢失。结果是上层只知道"数值不对"，不知道"为什么不对"，把两侧协议最有价值的诊断能力都浪费掉。

直连与网关方案对比

什么情况下网关确实合理

排除掉"图省事"的动机后，网关在这几类场景中站得住脚：

1. 存量主干网络不可改动。老产线主干是某种协议，新增设备只有另一种协议可选，且改造主干的停机代价过高。
2. 协议侧没有对应型号可选。某些小众或专有协议本身没有传感器直连方案，只能靠网关接入。
3. 纯数据采集，不参与闭环。位置数据只送往上位机、SCADA 或数据平台用于监视与分析，对延迟不敏感。此类需求也可考虑 IO-Link 或 Modbus RTU/TCP 这类通用接口，往往比专用网关更简单。
4. 过渡期方案。分阶段改造中，网关作为临时桥接手段，计划内替换掉。

反过来，不该用网关的信号很明确：需要多轴同步、需要毫秒级确定周期、需要完整设备诊断、或仅仅是因为"手头这批传感器协议不对"。最后一种情况下，换型号的成本几乎总是低于长期维护一台网关的成本。

必须用网关时的配置要点

• 周期设定要分层核算。传感器侧周期不得短于其更新率（磁致伸缩需等扭转波传回电子头，量程越长越慢，较短量程约 0.5 ms 量级、超长量程可达数毫秒）；网关搬运周期应与两侧周期形成整数倍关系，避免拍频效应造成的周期性数据陈旧。匹配方法见 响应时间/刷新率怎么和控制周期匹配。
• 数据类型与字序要逐项核对。位置值为 INT32，两侧协议的字节序、有符号解释可能不同，映射错误的表现是"通信正常但数值离谱"。
• 映射表必须归档。网关的映射配置往往只存在于配置工具里，一旦网关损坏更换，没有归档就要重做全部映射。配置文件应随图纸一起纳入版本管理。
• 把两侧链路状态映射成上层可见的状态位。既然设备级诊断透不过去，至少要让上层知道"网关与传感器之间的链路是否正常"，否则传感器掉线时上层读到的可能是网关缓存的旧值——这是网关方案最危险的失效模式。
• 断电恢复行为要验证。网关重启后是否自动重建两侧连接、映射区初值是否为零，都需要实测确认。位置值本身是绝对位置、不丢零位，机制见 总线型断电保持与同步刷新机制。

选型阶段优先考虑直连方案：CAN 主站体系用 194 CANopen 系列，EtherCAT 主站体系用 197 EtherCAT 系列，西门子新建产线用 199PROFINET 系列。主站与协议的匹配路径见 选型指南：我的 PLC 支持哪种总线，接线通用规范见 总线实操指南。