4、接口数据模型：轨道区段状态、道岔状态、信号机状态、列车位置信息、移动授权（MA）数据
好，咱们进入接口设计的核心环节——数据模型。说白了，CBI和ZC之间到底在聊什么？就是这五类数据。我当年刚接触这个系统时，觉得不就是几个状态量嘛，有什么难的？结果第一次联调就栽了跟头。嗯，咱们一个一个捋清楚。
4.1 轨道区段状态
轨道区段状态，是ZC判断列车能不能往前走的“地基”。CBI告诉ZC：哪个区段空闲，哪个区段占用，哪个区段锁闭了。
我个人习惯把轨道区段状态分为三类：
- 空闲（Clear）：区段内无车，且未被锁闭。这是最理想的状态。
- 占用（Occupied）：有车压在上面。注意，这里包括“物理占用”和“逻辑占用”。物理占用是轨道电路检测到的，逻辑占用可能是ZC推算出来的。
- 锁闭（Locked）：区段被进路锁闭了，即使没车，ZC也不能随便把MA延伸过去。
关键点：轨道区段状态是CBI通过安全通信发给ZC的。ZC拿到后，会结合自己的列车位置推算，做“一致性检查”。
我在项目中遇到过一个问题：CBI报某个区段“空闲”，但ZC的列车位置推算显示那上面有车。结果呢？两边打架，MA死活给不出来。后来查了半天，是轨道电路分路不良导致的。所以，数据模型里一定要预留“状态不确定”的标记位，别只给0和1。
4.2 道岔状态
道岔状态，说白了就是“路往哪边开”。CBI告诉ZC：道岔现在是定位、反位，还是四开（故障状态）。
数据模型里，道岔状态通常用两个bit表示：
| 状态编码 | 含义 | 说明 |
|---|---|---|
| 00 | 定位 | 道岔在直向位置 |
| 01 | 反位 | 道岔在侧向位置 |
| 10 | 四开 | 道岔未密贴，危险状态 |
| 11 | 未知 | 通信中断或初始化状态 |
避坑指南：我曾经见过一个项目，ZC直接拿道岔状态去算MA。结果道岔在转换过程中，CBI报了“正在转动”，ZC却当成“定位”处理了。差点导致列车挤岔。记住：道岔状态必须包含“正在转动”这个中间态，ZC看到这个状态，必须停止MA延伸。
你想想看，如果道岔状态数据模型里没有“正在转动”这个值，ZC就只能猜。猜对了是运气，猜错了就是事故。所以，数据模型要覆盖所有可能的状态，包括故障态和过渡态。
4.3 信号机状态
信号机状态，是CBI给ZC的“视觉提示”。虽然CBTC系统里列车主要靠MA开车，但信号机状态仍然是安全冗余的一部分。
数据模型里，信号机状态通常包括：
- 允许信号：绿灯、黄灯、绿黄灯等。ZC看到这个，知道CBI允许列车通过。
- 禁止信号：红灯。ZC看到这个，必须把MA停在信号机前方。
- 灭灯/故障：信号机坏了。ZC需要降级处理。
嗯，这里要注意：信号机状态和MA不是简单的“与”关系。我记得有一次，CBI报了绿灯，但ZC因为前方区段被占用，只给了很短的MA。司机就纳闷了：信号机是绿的，怎么MA这么短？其实这是正常的，因为MA还要考虑其他安全条件。
个人经验：我建议在数据模型里，把信号机状态和MA的“最终限制原因”关联起来。比如，如果MA被信号机限制，就标记一个“信号机限制”的flag。这样调试时一眼就能看出问题。
4.4 列车位置信息
列车位置信息，是ZC自己算出来的，但CBI也会提供一些辅助信息。比如，CBI告诉ZC：某列车在哪个区段，占用了几个区段。
数据模型里，列车位置信息通常包含：
- 车头位置：精确到米，或者精确到区段边界。
- 车尾位置：同样精确到米。注意，车尾位置决定了后方区段能不能解锁。
- 列车长度：固定值，或者动态上报。
- 置信度：位置是精确的，还是推算的。这个很重要，直接影响MA的计算。
关键点：ZC的列车位置信息，必须和CBI的轨道区段占用信息做交叉验证。如果ZC说车在A区段，但CBI说A区段空闲，那肯定有一方错了。这时候，系统必须进入安全侧。
我曾经遇到过一个案例：列车在折返线上，ZC推算车头已经过了道岔，但CBI的轨道电路显示道岔区段还占用着。两边数据不一致，导致道岔一直锁着，后面的车进不来。后来发现，是ZC的轮径校准参数设错了，导致位置推算偏了3米。所以，数据模型里一定要有“位置误差范围”这个字段，别只给一个点。
4.5 移动授权（MA）数据
移动授权（MA），是ZC给列车的“行车许可证”。它告诉列车：你可以往前开多远，速度上限是多少。
MA数据模型的核心字段包括：
| 字段 | 说明 | 示例 |
|---|---|---|
| MA起点 | 列车当前车头位置 | K12+345 |
| MA终点 | 允许列车到达的最远位置 | K13+200 |
| 速度曲线 | 每个区段的速度上限 | 0-50km/h, 50-80km/h |
| 限制原因 | 为什么MA只给到这里 | 前方道岔未到位 |
| 有效期 | MA的生效时间和失效时间 | 2025-01-01 12:00:00 |
你想想看，MA数据模型里最容易被忽略的是什么？是“限制原因”。我刚开始做设计时，只给了MA终点和速度曲线。结果列车在MA终点前停下了，司机不知道为啥，只能打电话问调度。后来我加了一个“限制原因”字段，司机一看就知道：哦，原来是前方道岔没到位，等着吧。
避坑指南：MA数据模型里，速度曲线必须是分段连续的。我曾经见过一个项目，速度曲线在区段边界处有跳变——从80km/h直接降到0。列车紧急制动，乘客摔了一地。后来改了设计，速度曲线在边界处必须平滑过渡，或者至少给一个“预告点”。
4.6 数据模型的交互逻辑
这五类数据不是孤立的。它们之间有一个“输入-处理-输出”的关系：
- CBI输入：轨道区段状态、道岔状态、信号机状态。
- ZC处理：结合列车位置信息，计算MA。
- ZC输出：移动授权（MA）数据。
说白了，CBI是“眼睛”，ZC是“大脑”。眼睛看到路况，大脑决定怎么走。但眼睛和大脑之间，必须有一套共同的语言——就是咱们刚才讲的数据模型。
个人经验：我建议在数据模型设计阶段，就画一张“数据依赖图”。把每个字段的来源、去向、校验规则都标清楚。这样后期联调时，能省一半的时间。我曾经在一个项目里，就是因为数据依赖没理清，导致CBI和ZC各说各话，联调了三个月才搞定。
嗯，接口数据模型就讲到这里。记住一句话：数据模型是CBI和ZC沟通的“语法”。语法错了，说再多也没用。下一章，咱们聊聊通信协议——怎么把这些数据安全可靠地传过去。