2. 系统架构：PIS系统与列车控制系统的分层架构与数据流
好，咱们直接切入正题。这一章，我重点聊聊PIS系统和列车控制系统之间，到底是怎么“搭”在一起的。
很多人一上来就盯着接口协议看，其实这是误区。我个人习惯，先看架构。架构对了，接口定义就是水到渠成的事。你想想看，如果两层楼之间的楼梯位置都没定好，你光研究扶手用什么材料，那不是白费劲吗？
2.1 分层架构：谁在上，谁在下？
在轨道交通信号系统里，列车控制系统（ATC）是绝对的核心安全层。PIS系统呢？它是服务于乘客的信息层。这两者之间，存在一个清晰的“上下级”关系。
我把它总结为三层模型：
- 底层：列车控制层（ATC层） —— 负责安全、速度、车门、定位。这是“大脑”和“神经”。
- 中间层：数据交换层（骨干网/网关） —— 负责协议转换、数据隔离、安全过滤。这是“桥梁”。
- 上层：乘客信息层（PIS层） —— 负责广播、显示、对讲、视频监控。这是“嘴巴”和“眼睛”。
这里有个关键点：PIS系统绝对不能直接控制列车。它只能“请求”或“接收”信息。我曾经在一个改造项目中见过，有人试图让PIS直接触发紧急制动，结果被安全评审直接打回。嗯，这是红线，碰不得。
核心原则： PIS是ATC的“数据消费者”，而非“数据生产者”。所有涉及安全的数据流向，必须是单向的，或者经过安全编码的。
2.2 数据流：信息是怎么跑的？
搞清楚了谁在上谁在下，咱们再看数据怎么流。说白了，就两条路：
- 下行数据流（ATC → PIS）：这是主要流向。ATC告诉PIS：“列车现在到哪了”、“下一站是XX”、“当前速度是多少”、“车门要开了”。
- 上行数据流（PIS → ATC）：这是受限流向。PIS告诉ATC：“紧急对讲按钮被按下了”、“司机请求开门”、“乘客报警”。
我建议你在设计接口时，把下行数据当成“常态”，上行数据当成“异常”。这样你的逻辑会清晰很多。
2.3 接口位置：数据在哪交接？
数据不是在任意地方都能交换的。在工程实践中，接口位置通常固定在两个点：
| 接口位置 | 说明 | 典型协议 |
|---|---|---|
| 车辆级接口 | 在每节车厢或每列车内部，PIS控制器与ATC车载设备（VOBC）之间。 | MVB、CAN、以太网（TRDP） |
| 轨旁级接口 | 在控制中心或车站，PIS服务器与ATS（自动列车监控）系统之间。 | TCP/IP、UDP、MQTT |
这里有个避坑指南：我曾经在一个项目里，把车辆级接口和轨旁级接口混为一谈，结果导致列车在隧道里收不到PIS的实时位置更新。为什么？因为轨旁数据有延迟，而车辆数据是实时的。后来我们不得不增加一个本地缓存机制才解决。
我的经验： 如果你做的是地铁项目，优先保证车辆级接口的实时性。如果是市域铁路或干线铁路，轨旁级接口的可靠性更重要。场景不同，侧重点完全不同。
2.4 典型数据流示例（以到站预报为例）
光说理论太干，咱们看个实际例子。假设列车要进站了，PIS需要显示“下一站：人民广场”。
数据流是这样的：
- ATC车载设备 通过信标或测速，计算出列车位置。
- ATC通过车辆总线（如MVB），发送一个数据包给PIS控制器。数据包里包含：当前站区ID、下一站ID、预计到达时间。
- PIS控制器 收到后，解析数据包，查表找到“下一站ID”对应的中文名和英文名。
- PIS控制器将文本和语音指令，分发给车厢内的LCD屏和广播模块。
- 乘客看到“下一站：人民广场”，听到“The next station is People's Square”。
你看，整个过程里，PIS没有参与任何定位计算，它只是忠实地执行了ATC的指令。这就是分层架构的好处——各司其职。
2.5 数据流中的“坑”
最后，我分享几个实际项目中踩过的坑：
- 数据延迟： 我曾经遇到PIS显示的车门状态比实际慢了2秒。排查发现是ATC发送的数据包在网关里排队了。解决办法是给PIS相关的数据包设置最高优先级。
- 数据丢包： 在无线环境下，PIS偶尔收不到ATC的广播。后来我们增加了“心跳包”和“重传机制”。
- 数据格式不统一： 不同厂家的ATC，发送的“站区ID”编码方式不同。有的用整数，有的用字符串。PIS这边必须做一个适配层。
注意： 千万不要在PIS系统里写死ATC的数据格式。一定要做成可配置的。否则换一个车型，你的PIS就得重新开发。我见过太多这样的教训了。
好了，这一章就到这里。下一章，咱们聊聊具体的接口协议——MVB和以太网，到底该怎么选。