📚 课程目录第4章可靠性机制

4、可靠性机制：SECS I的硬件流控与CRC校验、HSMS的TCP重传机制与心跳包、断线重连策略对比

说到可靠性，这其实是选型时最容易被忽略、但出问题后最让人头疼的部分。我见过不少项目，前期只盯着传输速度选型，结果现场跑起来三天两头断线、数据错乱，最后不得不返工换方案。

SECS I 和 HSMS 在可靠性上的思路完全不同。一个靠硬件硬扛，一个靠软件协议兜底。咱们今天就把这两套机制掰开揉碎了讲清楚。

SECS I 是 RS-232 时代的产物。那个年代，线路质量不稳定，干扰也多。所以它的可靠性设计非常「物理」——直接在硬件层面做文章。

说白了，就是靠两根额外的信号线来协调收发节奏。发送方在发数据前，先问接收方：「你准备好了吗？」接收方拉高 CTS 线，发送方才能开始发。

我在一条老旧的半导体封装线上遇到过一个问题：设备端的缓存只有 256 字节，但上位机一次发过来 1KB 的数据包。如果没有硬件流控，数据直接溢出丢失。后来我检查发现，CTS 信号线根本没接。嗯，这就是典型的「省一根线，多一堆坑」。

  关键参数：
  RTS（Request To Send）：发送方请求发送
CTS（Clear To Send）：接收方允许发送
流控粒度：按字符级别控制，不是按包

SECS I 在 Message 层使用 CRC-16 校验。每一条完整的消息块（Block）末尾都会附加 2 字节的 CRC 值。接收方收到后重新计算，如果对不上，直接丢弃并要求重传。

你想想看，RS-232 在工厂环境里很容易受到电机启停、变频器干扰，偶尔会有一两个 bit 翻转。CRC 就是用来抓这种「小概率但致命」的错误的。

我的经验： 曾经有一条 50 米的 RS-232 线缆，波特率设到 19200，结果 CRC 错误率高达 5%。后来降到 9600，错误率直接降到 0.1% 以下。所以 SECS I 的可靠性，很大程度上依赖于你实际布线的质量。

HSMS 跑在 TCP/IP 上，TCP 本身已经提供了可靠传输。但半导体设备对可靠性的要求远高于普通网络应用，所以 HSMS 在 TCP 之上又加了两层保险：应用层心跳和连接监控。

TCP 的重传是操作系统内核自动完成的。发送方发出数据后，会启动一个定时器。如果在超时时间内没收到 ACK，就自动重传。重传间隔会指数退避——第一次等 200ms，第二次 400ms，第三次 800ms……直到达到上限。

但这里有个坑：TCP 重传只保证数据到达，不保证应用层能及时处理。我遇到过一种情况：网络偶尔闪断 2 秒，TCP 重传成功了，但设备端的应用层因为超时已经断开了连接。这就是典型的「网络层 OK，应用层 NG」。

HSMS 定义了一种特殊的控制消息——Separate 和 Heartbeat。Separate 用于正常断开，Heartbeat 用于检测连接是否还活着。

实际项目中，我一般建议心跳间隔设为 10~30 秒。太短了浪费带宽，太长了发现断线不及时。你想想看，如果一条生产线每分钟生产 100 片晶圆，断线 30 秒才发现，那就是 50 片晶圆的数据丢了。

注意： HSMS 标准并没有强制要求心跳包的实现。很多设备厂商为了省事，直接跳过了心跳检测。结果就是：网络断了，双方都不知道，一直等到应用层超时才报错。我个人强烈建议——不管设备端还是上位机，一定要实现心跳。

断线重连是两种协议最大的差异点之一。SECS I 基本没有重连机制——线断了就是断了，需要人工干预。HSMS 则有一套完整的重连策略。

SECS I 的物理层断线后，设备端和上位机都会进入「离线」状态。要恢复通信，必须重新执行一遍 ENTER/ONLINE 流程。说白了，就是人工插拔线缆或者重启设备。

我曾经在一个老工厂里看到，操作员每天上班第一件事就是检查 RS-232 线缆有没有松脱。这种场景在今天看来确实有点原始，但在一些老旧产线上依然存在。

HSMS 定义了两种角色：主动方（Active）和被动方（Passive）。主动方负责发起连接，被动方负责监听。断线后，主动方会按照预设的重连策略自动尝试重新建立连接。

标准的重连策略是这样的：

  避坑指南： 我曾经遇到过一个案例，重连间隔设得太短（1 秒），结果网络抖动时，双方都在疯狂重连，反而把网络带宽占满了。后来我改成 5 秒间隔 + 指数退避，问题就解决了。

下面这张图把两种协议的可靠性机制放在一起对比，方便你快速理解整体架构。

选型建议： 如果你的设备部署在洁净室内部，线缆距离不超过 15 米，环境干扰小，SECS I 的硬件流控 + CRC 完全够用。但如果设备分布在整条产线，需要跨机柜、跨楼层通信，HSMS 的 TCP 重传 + 心跳 + 自动重连才是靠谱的选择。