二、系统架构基础：PIS系统典型架构
好，咱们进入正题。PIS系统说白了就是给乘客看信息、听广播的那套东西。但你别小看它，地铁跑起来之后，所有信息都得靠它传下去。我这些年经手的项目，架构选型往往是第一个坑——选对了后面顺风顺水，选错了后期改起来真要命。
2.1 集中式架构 vs 分布式架构
先聊聊两种主流架构。我个人习惯把它们比作「大脑」和「神经网络」的区别。
集中式架构
集中式架构，就是所有信息处理都交给一个中央控制器。车上所有显示屏、广播终端都直接连到这台主机上。好处是什么？管理简单，升级方便，你只需要动主机就行。
但我遇到过一个问题：某条线路的PIS系统就是集中式的。有一次中央控制器宕机了，整列车的信息显示全黑。你想想看，乘客看着黑屏，广播也不响，那场面...嗯，从那以后我对集中式的可靠性就特别敏感。
分布式架构
分布式架构就不一样了。每节车厢都有自己的控制器，各自独立工作。就算某一节车厢的控制器坏了，其他车厢照常运行。说白了就是「各扫门前雪」。
我记得在做一个跨海线路项目时，业主明确要求用分布式。为什么？因为线路长，车厢多，一旦中间某节出问题，不能影响全车。分布式架构天然支持这种场景。
| 对比项 | 集中式 | 分布式 |
|---|---|---|
| 维护复杂度 | 低（单点维护） | 高（多点维护） |
| 可靠性 | 低（单点故障） | 高（故障隔离） |
| 升级成本 | 低（只升级主机） | 高（逐节升级） |
| 实时性 | 依赖主机性能 | 本地处理，延迟低 |
2.2 骨干网络拓扑
架构定下来之后，接下来就是网络怎么连。骨干网络拓扑，说白了就是数据怎么在车厢之间跑。
目前主流的有两种：
- 环形拓扑：所有车厢首尾相连，形成一个环。数据可以顺时针或逆时针走。好处是有冗余路径，坏处是一旦环断了，得花时间重新收敛。
- 线性拓扑：从头车到尾车，一条线拉到底。简单直接，但中间任何一点断了，后面的车厢就失联了。
我个人更倾向环形拓扑。为什么？因为轨道交通环境太恶劣了——振动、温度变化、插头松动...你永远不知道哪根网线会突然罢工。环形拓扑至少给你留了一条后路。
我曾经在一个项目中吃过线性的亏。当时为了省成本，用了线性拓扑。结果运行半年后，第三节车厢和第四节车厢之间的连接器出了问题，后面五节车厢全部离线。从那以后，我再也不敢在主干网上省冗余了。
2.3 冗余设计原则
冗余设计，说白了就是「别把所有鸡蛋放在一个篮子里」。但怎么放、放多少，这里头有讲究。
2.3.1 设备冗余
核心设备必须双套。比如中央控制器、网络交换机、电源模块。我一般建议用1+1热备，也就是主备同时运行，主设备挂了备设备无缝接管。
但注意，不是所有设备都需要冗余。显示屏、广播终端这些末端设备，坏了只影响局部，成本又高，没必要冗余。你想想看，一节车厢8块屏，每块屏都配个备份，那成本得翻多少倍？
2.3.2 网络冗余
网络冗余有两种常见做法：
- 双网冗余：每台设备配两个网口，分别接到两个独立的交换机上。一个网络断了，自动切到另一个。
- 链路聚合：把两条物理链路捆绑成一条逻辑链路。带宽翻倍，同时一条断了也不影响。
我个人习惯用双网冗余。链路聚合虽然带宽大，但配置复杂，而且一旦配置出错，两条链路一起挂。双网冗余简单粗暴，维护人员也容易理解。
2.3.3 电源冗余
PIS系统对电源要求很高。列车上的电源波动大，而且经常有断电再上电的情况。我建议：
- 每节车厢配独立的电源模块
- 电源模块支持宽电压输入（DC 24V~110V）
- 关键设备加装UPS（不间断电源），至少撑5秒
为什么是5秒？因为列车断电后，通常3~5秒内会重新上电。UPS只要撑过这个窗口期，系统就不会重启。我之前有个项目没加UPS，每次列车过分相区（断电区）系统就重启一次，乘客投诉说「每次过隧道屏就黑一下」...后来加了UPS，问题解决。
2.4 小结
架构选型没有绝对的对错，只有合不合适。集中式适合短编组、低成本项目；分布式适合长编组、高可靠性项目。网络拓扑优先选环形，冗余设计遵循「核心设备双套、末端设备单套」的原则。
嗯，这一章就到这里。下一章咱们聊聊PIS系统的核心数据流——从TCMS到PIS，信息到底是怎么传的。