接口协议基础：通信协议栈、数据编码与消息格式
各位好，我是老张。在轨道交通信号这行摸爬滚打了十几年，今天咱们来聊聊CBI与ZC之间的“对话规则”——接口协议。说白了，这就是两个系统之间怎么“说话”、用什么“语言”、以及“话”该怎么组织的问题。
我记得刚入行那会儿，有一次在调试现场，CBI和ZC就是连不上。查了两天，最后发现是协议栈的端口号配错了。嗯，从那以后我就养成了一个习惯：先看协议栈配置，再看应用层数据。今天就把这些经验掰开了揉碎了讲给你们听。
一、通信协议栈：TCP/IP vs UDP
CBI和ZC之间的通信，底层跑的无非就是TCP/IP和UDP这两套。你可能会问：为什么不用别的？其实说白了，轨道交通信号系统对实时性和可靠性要求极高，而这两套协议是经过工业验证最成熟的。
1. TCP/IP：可靠但“慢”
TCP/IP的特点就是“可靠”。它建立连接需要三次握手，传输数据有确认重传机制。我在项目中遇到过这样的情况：ZC向CBI发送控制命令，如果丢包了，TCP会自动重传，直到对方收到为止。
关键点：TCP/IP适合传输“必须到达”的数据，比如安全命令、状态切换等。但它的延迟相对较高，不适合对实时性要求极高的周期性数据。
举个例子，CBI向ZC报告“道岔已锁闭”这个状态，如果丢了，系统必须重传。用TCP/IP就对了。但如果是每秒发送100次的列车位置数据，用TCP/IP就有点“大材小用”了——重传机制反而会增加网络负担。
2. UDP：快但“不靠谱”
UDP就简单多了。它不建立连接，发出去就不管了。你想想看，这像不像你喊一嗓子，对方听没听到你不管？
但别小看UDP。在信号系统中，很多周期性数据（比如列车位置、速度信息）用UDP更合适。为什么？因为这类数据即使丢了一两包，下一包马上就到，影响不大。我曾经调试过一个项目，ZC每20毫秒发一次位置数据给CBI，用的就是UDP。如果丢了一包，下一包20毫秒后就来了，系统完全能接受。
注意：UDP虽然快，但应用层必须自己做校验。我在现场见过因为UDP数据包被篡改导致误动作的案例。所以，用UDP时一定要加CRC校验和序列号。
3. 实际项目中的选择
我个人习惯是这样：
- 安全相关命令（如紧急制动、道岔控制）→ 用TCP/IP
- 周期性状态数据（如位置、速度、设备状态）→ 用UDP
- 配置和诊断数据（如版本信息、日志）→ 用TCP/IP
你可能会问：能不能只用一种？理论上可以，但实际项目中很少这么干。因为TCP/IP的确认机制会拖慢周期性数据的传输，而UDP又无法保证安全命令的可靠到达。所以，成熟的系统都是“双栈并行”。
二、数据编码方式：二进制 vs ASN.1
协议栈选好了，接下来就是“语言”问题。CBI和ZC之间传输的数据，到底用什么格式编码？
1. 二进制编码：简单粗暴
二进制编码是最原始的方式。说白了，就是直接把数据按位排列。比如一个道岔状态，用1个bit表示：0表示定位，1表示反位。
// 二进制编码示例
// 道岔状态：0=定位，1=反位
// 信号机状态：00=红灯，01=绿灯，10=黄灯，11=白灯
// 一个字节可以表示：
// bit0: 道岔1状态
// bit1: 道岔2状态
// bit2-3: 信号机1状态
// bit4-5: 信号机2状态
// bit6-7: 保留
// 例如：0x4A = 0100 1010
// 道岔1=0(定位), 道岔2=1(反位)
// 信号机1=10(黄灯), 信号机2=01(绿灯)
我在项目中遇到过用二进制编码的旧系统。优点是效率高，一个字节能塞进8个状态。但缺点也很明显：可读性差，扩展困难。你想加一个新状态？对不起，得重新定义整个字节的位分配，而且新旧版本不兼容。
我的建议：二进制编码适合状态量少、变化不频繁的场景。如果你要传输的数据类型超过10种，就别用二进制了，维护起来太痛苦。
2. ASN.1编码：灵活但“重”
ASN.1（Abstract Syntax Notation One）是另一种选择。它定义了一套标准的数据描述语言，可以描述复杂的数据结构。比如：
-- ASN.1 定义示例
CBI-ZC-Message ::= SEQUENCE {
messageId INTEGER (0..65535),
timestamp INTEGER,
sourceId IA5String (SIZE(1..16)),
destinationId IA5String (SIZE(1..16)),
payload CHOICE {
command CommandMessage,
status StatusMessage,
diagnostic DiagnosticMessage
}
}
CommandMessage ::= SEQUENCE {
commandType ENUMERATED {emergencyBrake, switchControl, routeSetting},
targetId IA5String (SIZE(1..16)),
parameters OCTET STRING OPTIONAL
}
ASN.1的好处是：
- 自描述：数据本身包含了类型信息，解析起来不容易出错
- 可扩展：加一个新字段不影响旧版本
- 跨平台：不同硬件平台都能解析
但缺点也很明显：编码后的数据体积大，解析速度慢。我记得有一次在性能测试中，ASN.1编码的报文比二进制大了3倍，解析时间多了5倍。对于实时性要求高的系统，这可能是个问题。
实际选择：现在的主流信号系统，比如西门子、阿尔斯通，都倾向于用ASN.1。为什么？因为系统越来越复杂，可维护性比那点性能损失更重要。但如果你做的是嵌入式系统，资源受限，二进制编码可能更合适。
三、消息格式定义
协议栈和编码方式都定了，最后一步就是定义“话怎么说”。消息格式定义，说白了就是约定好：第一段说什么，第二段说什么，每段多长。
1. 消息头格式
每条消息都有一个固定的头部。我习惯这样设计：
| 字段 | 长度 | 说明 |
|---|---|---|
| 消息起始符 | 2字节 | 固定为0xAA55，用于同步 |
| 协议版本 | 1字节 | 当前版本号，如0x01 |
| 消息类型 | 1字节 | 0x01=命令，0x02=状态，0x03=诊断 |
| 消息长度 | 2字节 | 整个消息的长度（含头部） |
| 序列号 | 2字节 | 递增，用于去重和排序 |
| 时间戳 | 4字节 | Unix时间戳，毫秒级 |
| 源设备ID | 4字节 | 发送方设备编号 |
| 目标设备ID | 4字节 | 接收方设备编号 |
| 校验码 | 2字节 | CRC16校验 |
你可能会问：为什么头部要这么长？嗯，这里有个教训。我曾经参与过一个项目，消息头只定义了类型和长度，结果现场出现了“幽灵消息”——设备A发给设备B的消息，被设备C收到了。从那以后，我坚持在头部加上源和目标设备ID。
2. 消息体格式
消息体根据消息类型不同而不同。以“状态消息”为例：
// 状态消息体格式（二进制编码示例）
// 总长度：32字节
// 字节0-3: 设备状态字
// bit0: 设备在线
// bit1: 设备故障
// bit2: 设备维护中
// bit3-31: 保留
// 字节4-7: 道岔状态（最多32个道岔）
// 每个bit表示一个道岔：0=定位，1=反位
// 字节8-11: 信号机状态（最多16个信号机）
// 每2个bit表示一个信号机：
// 00=红灯，01=绿灯，10=黄灯，11=白灯
// 字节12-15: 轨道区段占用状态（最多32个区段）
// 每个bit表示一个区段：0=空闲，1=占用
// 字节16-31: 保留（用于未来扩展）
设计原则：消息格式一定要预留扩展空间。我见过太多系统因为没留扩展位，升级时不得不重新定义整个协议。记住：永远在消息体末尾留20%的保留字节。
3. 消息交互流程
定义了格式，还得定义“怎么聊”。CBI和ZC之间的典型交互流程是这样的：
- 握手阶段：CBI发送“连接请求”，ZC回复“连接确认”。双方交换版本号和能力信息。
- 正常运行阶段：CBI周期性发送“状态报告”（如道岔状态、信号机状态），ZC周期性发送“控制命令”（如进路设置、速度限制）。
- 异常处理阶段：一方检测到异常（如通信超时），发送“告警消息”。另一方收到后，进入安全模式。
- 断开阶段：正常关闭时，发送“断开请求”，对方回复“断开确认”。
我曾经在调试时遇到过一个问题：CBI和ZC都正常发送数据，但就是收不到对方的回复。查了半天，发现是双方的“心跳间隔”不一致——CBI每100ms发一次，ZC每200ms才处理一次。结果CBI以为ZC挂了，触发了紧急制动。从那以后，我要求所有项目的“心跳间隔”必须统一配置，并且在握手阶段互相确认。
重要提醒：消息交互中一定要定义“超时重传”和“超时断开”机制。我见过一个项目，因为没定义超时断开，通信中断后双方都以为对方还在线，结果列车越过了危险点。安全第一，超时断开比错误连接更安全。
总结
好了，关于接口协议基础，我就讲这么多。总结一下：
- 协议栈：TCP/IP保可靠，UDP保实时，根据数据类型灵活选择
- 数据编码：二进制简单高效，ASN.1灵活可扩展，看系统复杂度决定
- 消息格式：头部要完整，体要紧凑，一定要预留扩展空间
下一章，咱们聊聊具体的接口数据定义——CBI到底要告诉ZC哪些信息，ZC又要给CBI下什么命令。到时候我会拿一个实际项目的接口文档来拆解，保证你们看完就能上手。
记住：接口协议设计得好，调试就轻松；设计得烂，现场就是地狱。我吃过这个亏，希望你们别重蹈覆辙。