3. PIS系统软件架构：中心级软件、车站级软件、车载软件、接口协议、数据流走向
各位同行，今天我们来聊聊PIS系统的软件架构。说实话，很多刚入行的朋友一听到「架构」两个字就觉得头大，觉得是高高在上的理论。其实不然，PIS的软件架构说白了就是三块：中心、车站、车载，再加上它们之间怎么说话、数据怎么跑。我这些年调试过的项目，十有八九的问题都出在接口协议或者数据流上，所以这块内容，我建议你仔细看。
3.1 中心级软件：大脑中枢
中心级软件，我习惯叫它「总控台」。它部署在控制中心，负责全局调度。你想想看，一条地铁线几十个站，几百辆车，没有中心软件统一管着，那不乱套了？
中心软件的核心功能包括：
- 信息发布管理：编辑、审核、下发各类运营信息（列车到站、延误通知、紧急广播等）。
- 设备监控：实时监控全线车站和车载PIS设备的状态，说白了就是看它们「活着没」。
- 日志与回放：记录所有操作和事件，方便事后追溯。我记得有一次某站屏幕显示异常，就是靠回放日志定位到是操作员误触了配置。
- 时钟同步：给全线设备授时，保证所有屏幕显示的时间一致。嗯，这里要注意，如果时钟不同步，乘客看到的信息会乱套。
中心软件通常采用C/S架构，服务器端负责数据处理和存储，客户端负责操作界面。我个人习惯在服务器端做冗余配置，一台主一台备，主挂了备自动顶上。这个在轨道交通里是硬性要求，不能有单点故障。
3.2 车站级软件：区域管家
车站级软件部署在每个车站，它相当于一个「区域管家」。中心下发的信息先到车站，车站再转发给站内的终端设备（比如站台屏、站厅屏、广播等）。
车站软件的几个关键点：
- 本地缓存：如果中心网络断了，车站软件能根据本地缓存的信息继续工作。我曾经遇到过中心光缆被施工挖断的情况，还好车站软件有缓存，乘客信息显示没中断。
- 协议转换：中心下来的数据可能是某种标准协议，但站内设备可能用不同的协议。车站软件负责「翻译」，说白了就是做协议适配。
- 优先级管理：紧急信息（比如火灾报警）必须优先于常规信息显示。这个逻辑如果写错了，后果很严重。
车站软件一般跑在工控机上，操作系统以Linux为主，也有用Windows的，但我个人更推荐Linux，稳定、不容易蓝屏。
3.3 车载软件：移动终端
车载软件跑在列车上的PIS控制器里。它和车站软件最大的区别是：车在动，网络环境不稳定。所以车载软件的设计要特别考虑断网重连、数据续传这些场景。
车载软件的功能：
- 动态报站：根据列车位置自动触发报站信息。这个位置信息通常来自信号系统（ATC/ATP）。
- 乘客信息显示：在车厢内的LCD屏上显示到站信息、换乘指引、紧急通知等。
- 广播控制：自动或手动触发语音广播。
- 本地存储：预存线路图、语音文件等，防止网络中断时「哑巴」。
避坑指南：我曾经遇到过车载软件在隧道里频繁断连的问题。后来发现是无线切换时IP地址没及时更新。解决方案是在软件里加了个心跳检测机制，3秒没收到心跳就主动重连。嗯，这个坑踩得值。
3.4 接口协议：设备之间的「共同语言」
接口协议是PIS系统里最容易出问题的地方。不同厂家的设备，用的协议可能不一样。我见过最头疼的情况是：中心软件用TCP，车站设备用UDP，中间还得加个协议转换器。
常见的接口协议：
| 协议类型 | 用途 | 特点 |
|---|---|---|
| TCP/IP | 中心与车站、车站与车载之间的数据通信 | 可靠、面向连接，适合传输控制指令和文本信息 |
| UDP | 实时广播、音频流 | 速度快、但不可靠，适合对实时性要求高的场景 |
| RS-485/Modbus | 站内设备（如LED屏、广播功放）的串口通信 | 抗干扰强、传输距离远，但速率低 |
| CAN总线 | 车载设备之间的通信 | 实时性好、可靠性高，适合列车环境 |
| HTTP/HTTPS | 中心软件与外部系统（如时钟系统、信号系统）对接 | 标准化、易于集成，但实时性一般 |
我个人习惯在项目初期就定好接口规范文档，明确每个字段的含义、长度、类型。否则后期联调时，你会发现「你说的是A，他理解的是B」，那叫一个痛苦。
3.5 数据流走向：信息是怎么跑的？
理解了上面三块软件和协议，数据流走向就很好理解了。我画个简单的逻辑图给你看：
中心软件（控制中心）
↓ ↑ (TCP/IP)
车站软件（每个车站）
↓ ↑ (TCP/UDP/RS-485)
站内终端（站台屏、站厅屏、广播等）
↓ ↑ (无线通信，如Wi-Fi或LTE)
车载软件（列车上的PIS控制器）
↓ ↑ (CAN总线/以太网)
车载终端（车厢LCD屏、广播喇叭）
数据流有几个关键路径：
- 下行数据流：中心 → 车站 → 终端（或车载）。比如发布一条「列车晚点通知」，就是从中心下发到车站，车站再转发给站台屏和车载。
- 上行数据流：终端 → 车站 → 中心。比如设备状态上报、故障告警等。
- 本地数据流：车站软件内部，或者车载软件内部，不经过网络。比如本地缓存的信息直接显示在屏幕上。
重要提醒：数据流设计时，一定要考虑「断网」和「高并发」两个场景。断网时，本地缓存要能撑住；高并发时（比如早晚高峰），服务器不能卡死。我见过一个项目，早高峰时所有车站同时上报状态，中心服务器直接CPU 100%，后来加了消息队列才解决。
个人经验：调试数据流时，我习惯先用Wireshark抓包，看看数据包有没有发出去、有没有收到回复。很多「设备没反应」的问题，其实都是数据根本没发到对方手里。嗯，这个习惯帮我省了不少时间。
注意：接口协议里的「心跳包」和「超时重传」机制一定要实现。我曾经遇到过因为心跳包间隔设置太长（30秒），导致中心以为车站设备离线，实际上设备好好的。后来我把心跳间隔改成了5秒，问题解决。
好了，关于PIS系统的软件架构，我就讲这么多。总结一句话：中心是大脑，车站是神经中枢，车载是移动终端，协议是语言，数据流是血液。搞清楚了这五块，PIS系统在你眼里就没有秘密了。下一章我们聊聊具体的故障诊断方法，到时候见。