4、RBC通信协议基础：RBC与车载ATP的无线通信协议
各位好，我是老张。今天咱们聊聊RBC和车载ATP之间怎么“说话”的。说白了，就是无线通信协议那点事。
我在现场调试时经常遇到一个问题：明明RBC发了报文，车就是没反应。查来查去，最后发现是协议栈配置错了。所以这块内容，我建议你认真看。
4.1 Euroradio协议栈：无线通信的骨架
RBC和车载ATP之间用的是Euroradio协议栈。这不是什么新东西，ETCS标准里早就定好了。它分好几层，每层干每层的活。
我个人习惯把Euroradio协议栈分成三块来看：
- 安全层：负责加密、认证、完整性校验。说白了，就是防止有人篡改报文。
- 传输层：负责可靠传输。丢包了重发，乱序了重排。
- 应用层：负责解析报文内容。比如MA（行车许可）里写了什么。
你想想看，这三层缺一不可。安全层出了问题，报文可能被篡改；传输层出了问题，报文可能丢了；应用层出了问题，车看不懂报文。
关键点：Euroradio协议栈的核心是“安全+可靠”。不是简单的TCP/IP能替代的。
4.2 安全应用中间件（Safe Application Middleware）的作用
嗯，这里要注意。安全应用中间件，简称SAM。它是个什么东西呢？
说白了，SAM就是RBC和ATP之间的“翻译官”加“保安”。它负责两件事：
- 报文格式化：把RBC要发的数据，按照标准格式打包。
- 安全校验：加上时间戳、序列号、CRC校验码。
我在项目中遇到过一件事：有个同事自己写了个报文解析程序，没走SAM。结果呢？车收到报文后直接报错，因为时间戳不对。从那以后，我再也不敢绕过SAM了。
避坑指南：我曾经见过有人试图自己实现SAM的功能。结果呢？花了三个月，最后还是用回了标准库。我的建议是：别折腾，直接用现成的。
4.3 报文结构与编码规则
RBC和ATP之间传的报文，不是随便写的。它有固定的结构。我把它拆成三部分：
| 字段 | 长度（字节） | 说明 |
|---|---|---|
| 报文头 | 8 | 包含报文类型、长度、时间戳 |
| 安全字段 | 16 | 包含序列号、CRC校验码 |
| 数据字段 | 可变 | 包含MA、临时限速等实际数据 |
编码规则用的是Uper（Unaligned Packed Encoding Rules）。说白了，就是按位压缩。能省一点是一点。
举个例子：
// 一个简单的MA报文示例
报文头: 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08
安全字段: 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1A 0x1B 0x1C 0x1D 0x1E 0x1F 0x20
数据字段: 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28你可能会问：为什么这么复杂？直接发明文不行吗？
不行。铁路信号讲究的是“故障导向安全”。万一有人恶意篡改报文，车收到错误指令，后果不堪设想。
警告：千万不要在正式线路上使用未经认证的报文编码方式。我曾经见过一个测试团队，为了省事，自己写了个简易编码器。结果呢？测试时没问题，一上线就出故障。最后查出来是编码规则没对齐。
4.4 实际应用中的注意事项
最后，我总结几条实际经验：
- 时间戳必须同步：RBC和ATP的时间要一致，否则报文会被丢弃。
- 序列号不能重复：每个报文都有唯一序列号，防止重放攻击。
- CRC校验不能省：哪怕只错一个bit，也要能检测出来。
嗯，今天就聊到这。下一章咱们讲讲RBC如何生成行车许可（MA）。那才是真正有意思的部分。
总结：Euroradio协议栈是RBC和ATP通信的基础。SAM是安全中间件。报文结构分三部分，编码用Uper。记住这三点，你就掌握了RBC通信的核心。
公众号:蓝海资料掘金营，微信deep3321