4. 接口协议与数据规范解析

CBTC联锁系统并不是孤立运行的设备，它需要与列车自动监控（ATS）、区域控制器（ZC）、计算机联锁相邻站、计轴/轨道电路、道岔转辙机以及维护监测系统等外部子系统持续交换信息。这些信息能否被正确理解、及时送达并可信执行，取决于接口协议与数据规范是否被准确解析和落实。本节聚焦四个关键层面：通信协议栈与安全协议、报文结构、周期与触发机制、安全校验与超时处理。

一、通信协议栈：从TCP/IP到安全协议

联锁与外部子系统之间通常采用以太网承载，传输层使用TCP或UDP。工程上常见两种组合：对可靠性要求高、报文长度不固定的接口（如联锁与ATS之间的状态与命令）多采用TCP，借助序号、确认与重传保证可靠交付；对实时性要求高、报文短小且周期性强的接口（如联锁与ZC之间的安全相关状态）多采用UDP配合应用层安全协议，以避免TCP重传带来的不确定时延。

需要特别强调的是，TCP/IP本身只提供“尽力而为”的可靠传输，并不提供功能安全意义上的完整性、真实性和时效性保证。因此安全相关接口必须在应用层叠加安全协议，典型做法是采用符合EN 50159（铁路通信安全）思路的安全层：在应用数据外封装安全头，包含源/目的标识、报文序号、时间戳和安全校验码（MAC或CRC），接收方据此判断报文是否被篡改、重放、丢失或过期。工程中常见的RSSP-I/RSSP-II、CIPS等安全协议即属于这一层。理解这一点是解析报文的前提：应用数据之前往往还有安全封装，解析时必须先剥安全层、再解应用层。

二、报文结构：字段定义决定解析正确性

报文结构是接口数据规范的核心。一个典型的联锁接口报文可划分为帧头、安全头、应用数据、校验尾四段。帧头负责同步与长度界定，接收方据此从字节流中切出完整一帧；安全头携带源标识、目的标识和报文序号；应用数据承载真正的业务字段，例如“道岔当前位置”“区段占用状态”“进路锁闭命令”；校验尾包含时间戳与MAC/CRC。

解析时最容易出错的是字段的字节序、位宽和编码约定。例如某接口规范约定：道岔状态用1字节表示，0x01为定位、0x02为反位、0x00为无效；区段占用用位图（bitmap）表示，每字节8个区段，bit=1表示占用。若开发人员误按大端解析而规范要求小端，或把位图顺序理解反了，就会出现“道岔显示反位但实际在定位”这类隐蔽错误。因此工程实践中必须建立字段字典，逐字段写明偏移、长度、类型、取值范围和无效值含义，并在联调前用抓包工具逐帧比对。

下面给出一个简化的字段字典示例（参数为教学假设，非实测值）：

三、周期与触发：两类数据不能混为一谈

联锁接口的数据按发送机制可分为周期数据和事件触发数据。周期数据用于持续反映状态，例如区段占用、道岔位置、信号机显示，通常以固定周期（如100 ms或200 ms）发送，接收方依靠“连续多个周期未收到即判通信失效”来监控链路健康。事件触发数据用于命令和状态跳变，例如进路建立命令、道岔转换命令，一旦产生就立即发送，并要求接收方回送确认；若在设定时间内未收到确认，发送方需重发，重发若干次仍失败则上报接口故障。

这里有一个工程要点：周期数据的“周期”与安全层的“超时”必须匹配设计。若周期为100 ms，接收方超时阈值设为300 ms（即连续3个周期未收到），则单次丢包不会误判失效，而链路真正中断时能在300 ms内被检出。超时阈值过小会导致误告警，过大则延长故障响应时间，需结合线路运营要求和安全完整性等级权衡确定。

四、安全校验与超时处理：让错误“可发现、可隔离”

安全校验解决“数据是否可信”，超时处理解决“数据是否还新鲜”。接收侧的标准处理顺序是：先做帧同步与长度合法性检查，长度不符直接丢弃；再计算MAC/CRC并与报文中的校验值比对，不一致则丢弃并计数；然后检查报文序号是否连续、时间戳是否在允许窗口内，序号回退或时间戳过期视为重放或过期报文，予以丢弃；全部通过后才把应用数据交付联锁逻辑使用。

超时处理则贯穿链路层与应用层。链路层依靠周期报文的心跳判断通信是否存活；应用层对命令类报文设置确认超时，例如道岔转换命令发出后若500 ms内未收到“转换到位”回执，则判本次转换失败并进入故障处理。工程上还应设置校验错误率、超时次数的统计阈值，超过阈值时触发接口降级或切换，而不是等到完全断链才反应。

综上，接口协议与数据规范解析的落脚点在于：明确协议栈各层职责、建立可核对的字段字典、区分周期与触发两类机制、并把安全校验与超时阈值作为接口设计的一部分同步确定。只有这四者一致，联锁与外部子系统之间的数据才能真正做到“发得出、收得对、判得准”。