第三章：系统总体架构设计
好，咱们进入正题。前面两章聊了PIS系统是什么，以及核心需求。这一章，咱们要真正动手画图了——系统总体架构设计。
说实话，架构设计这活儿，最怕的就是「纸上谈兵」。我见过太多方案，画得漂漂亮亮，一到现场就崩。为什么？因为没把硬件、软件、网络、数据流、分层这五件事揉在一起想。
这一章，我就把这五块掰开揉碎了讲。你跟着我的思路走一遍，基本就能搭出一个靠谱的PIS系统骨架。
3.1 硬件架构设计：选型与布局
硬件是PIS的「骨架」。骨架歪了，后面软件再牛也白搭。
我个人习惯，先画一张物理拓扑图。把设备摆上去，看看谁跟谁连，谁管谁。
核心硬件模块：
- 中央控制器（CCU）：整列车的大脑。一般放在司机室或设备柜里。我建议用工业级ARM Cortex-A系列处理器，比如i.MX8或RK3588。别用消费级芯片，车上振动大、温度高，消费级芯片撑不过三个月。
- 客室控制器（VCU）：每节车厢一个。负责本车厢的LCD屏、LED屏、广播、紧急对讲。我习惯用STM32MP1系列，双核A7+M4，既能跑Linux做应用，又能跑裸机做实时控制。
- LCD显示屏：现在主流是21.5寸或24寸，1080P起步。嗯，这里要注意——屏的亮度必须≥1000cd/m²，否则阳光一照啥也看不见。我在项目里吃过这个亏，后来全换了高亮屏。
- LED信息屏：车头、车侧、车内。车头屏要能显示线路号、终点站。车侧屏显示当前站和下一站。
- 广播功放：每节车厢一个，驱动4-8个喇叭。功率建议60W-100W。
- 紧急对讲装置：每节车厢2-4个。要带麦克风和摄像头。
硬件架构要点：
- CCU和VCU之间用工业以太网（M12接口，防震防松）
- VCU到LCD屏用LVDS或HDMI，距离别超过5米
- 所有设备供电统一用DC 24V或DC 110V（看列车制式）
- 别忘了加防反接、防浪涌电路——我曾经有一批板子因为没加TVS管，被雷击浪涌打坏了一半
3.2 软件架构设计：分层与模块
软件架构，说白了就是「谁负责什么，谁跟谁说话」。
我习惯把PIS软件分成四层。你想想看，这样分层之后，每一层只关心自己的事，改起来也方便。
| 层级 | 名称 | 职责 | 技术栈 |
|---|---|---|---|
| L4 | 应用层 | UI显示、广播调度、紧急对讲逻辑 | Qt/QML、C++、Python |
| L3 | 业务逻辑层 | 到站判断、语音合成、信息同步 | C++、状态机 |
| L2 | 通信中间件层 | 数据收发、协议转换、心跳检测 | DDS、MQTT、自定义TCP协议 |
| L1 | 硬件抽象层 | 驱动LCD、LED、功放、GPIO | C、Linux驱动、RTOS |
为什么要这么分？我举个例子。有一次客户要求换一种LCD屏，接口从LVDS改成eDP。如果没分层，我得改UI代码、改业务逻辑、改驱动——全乱套。但有了硬件抽象层，我只需要改L1的驱动，上面三层完全不动。这就是分层的价值。
我的经验：通信中间件层一定要用DDS（数据分发服务）。为什么？因为PIS系统里数据种类太多——到站信息、故障告警、广播状态、视频流...DDS的发布/订阅模型天然适合这种多对多通信。我早期用MQTT，后来发现实时性不够，果断换了DDS。
3.3 网络架构设计：冗余与隔离
网络是PIS的「血管」。血管堵了，系统就瘫了。
列车环境有个特点：电磁干扰大、振动大、空间有限。所以网络设计要特别讲究。
网络拓扑：
- 采用环形冗余网络。每节车厢一个工业交换机，首尾相连成环。万一某节车厢的交换机坏了，数据还能从另一条路走。我记得第一次做环网测试时，故意拔掉一节车厢的网线，数据延迟只增加了2ms——嗯，这效果让我放心了。
- 控制网和乘客网要物理隔离。控制网走CCU到VCU的实时数据，乘客网走Wi-Fi和4G/5G。别混在一起，否则乘客刷视频可能把控制数据挤掉。
- 用VLAN做逻辑隔离。如果物理条件不允许双网，至少用VLAN把控制流和媒体流分开。
避坑指南：我曾经在一个项目里，为了省成本，用了消费级交换机。结果列车过隧道时，交换机频繁重启。后来查原因——隧道里湿度大，消费级交换机没有防潮涂层。从那以后，我坚持用工业级交换机，至少IP40防护等级。
3.4 数据流设计：谁产生，谁消费
数据流设计，说白了就是搞清楚「数据从哪里来，到哪里去，经过谁的手」。
我习惯画一张数据流图。咱们以「到站信息显示」这个场景为例：
- 数据源：列车TCMS（列车控制管理系统）发出「下一站：人民广场」信号。格式通常是MVB或CAN总线数据。
- 数据接收：CCU通过MVB/CAN接口卡接收，解析成内部格式。
- 数据分发：CCU通过DDS发布到「到站信息Topic」。所有VCU订阅这个Topic。
- 数据消费：VCU收到后，做三件事：
- 更新LCD屏上的站点地图（高亮当前站）
- 更新LED屏显示文字
- 触发语音合成模块，播报「下一站，人民广场」
- 数据反馈：VCU把执行结果（屏是否正常显示、喇叭是否正常播放）上报给CCU。
你看，这个流程里，数据是单向流动的，但又有反馈闭环。我建议所有关键数据都要有确认机制——CCU发出去的命令，VCU必须回ACK。如果3秒内没收到ACK，CCU要重发。我曾经遇到过VCU死机的情况，就是因为没有重发机制，结果整列车的信息都不更新了。
3.5 系统分层设计：从物理到应用
最后，咱们把前面四块整合起来，看看完整的系统分层。
我习惯用「五层模型」来描述PIS系统：
| 层级 | 名称 | 内容 | 示例 |
|---|---|---|---|
| L5 | 应用交互层 | 乘客看到的、听到的 | LCD界面、LED文字、广播语音 |
| L4 | 业务逻辑层 | 数据处理、决策、调度 | 到站判断、语音合成、故障诊断 |
| L3 | 通信网络层 | 数据传输、协议转换 | DDS、TCP/IP、MVB/CAN网关 |
| L2 | 硬件控制层 | 设备驱动、IO控制 | LCD驱动、LED驱动、功放控制 |
| L1 | 物理设备层 | 实际硬件 | CCU、VCU、屏、喇叭、交换机 |
这个分层的好处是：每一层都可以独立升级、独立测试。比如，我想换一种语音合成算法，只需要改L4，L5的界面完全不用动。反过来，我想把LCD屏从21.5寸换成32寸，只需要改L2和L5，L3和L4不受影响。
核心原则：层与层之间通过标准接口通信。我建议用JSON或Protobuf作为数据格式。别用自定义二进制协议——虽然省带宽，但调试起来能把你逼疯。我早期就吃过这个亏，后来全部改成Protobuf，开发效率提升了一倍。
好了，这一章的内容就这些。硬件、软件、网络、数据流、分层——五件事，一个都不能少。你把这些想清楚了，PIS系统的骨架就搭起来了。下一章，咱们开始聊具体的硬件选型和电路设计。