1. PIS网络基础：轨道交通乘客信息系统概述、PIS网络架构演进、核心业务与流量特征

1.1 什么是乘客信息系统？

乘客信息系统，圈里人习惯叫它PIS。说白了，就是让乘客在车站和车厢里能获取到有用信息的系统。

你想想看，每天几百万人在城市地下穿梭。他们需要知道：下一班车什么时候到？换乘怎么走？前方有没有故障？这些信息怎么传给他们？靠的就是PIS。

我个人习惯把PIS拆成三个层面来看：

• 信息采集层：列车调度系统、广播系统、时钟系统，这些是信息的源头
• 网络传输层：把信息从源头送到终端设备，这就是我们今天要聊的核心
• 信息展示层：LCD屏、LED屏、广播喇叭，乘客最终看到听到的东西

我在项目中遇到过不少客户，上来就问「你们PIS能不能播视频？」。能，当然能。但你要知道，播视频和播文字，对网络的要求是天差地别的。这个后面会细说。

1.2 PIS网络架构的演进之路

PIS网络不是一天建成的。我入行那会儿，还是「单线独立部署」的时代。每条地铁线自己拉自己的网，互不相通。后来发现，换乘站的信息共享成了大问题。

嗯，这里要注意，PIS网络架构大致经历了三个阶段：

阶段	架构特点	典型问题
第一代（2000-2010）	单线独立，星型拓扑	单点故障多，换乘站信息孤岛
第二代（2010-2018）	线路级环网，冗余交换机	跨线路互通仍需人工干预
第三代（2018至今）	线网级互联，SDN+冗余架构	成本高，运维复杂度上升

我曾经参与过一个二线城市的PIS改造项目。他们用的还是第一代架构，车站交换机坏了，整条线的PIS就瘫痪了。乘客在站台上干等，广播也不响。那场面，说实话挺尴尬的。

从那以后，我设计PIS网络时，冗余就成了第一优先级。

1.3 核心业务：PIS到底在跑什么？

很多人以为PIS就是「放放视频、报报站名」。其实它的业务远比你想象的复杂。我列几个核心的：

• 实时到站信息：列车位置、预计到站时间、拥挤度。这些数据每1-2秒就要刷新一次
• 紧急信息发布：火灾、故障、延误。这类信息要求5秒内全网推送，延迟超过10秒就算事故
• 多媒体播放：站台LCD屏播广告、车厢内播新闻。视频流对带宽要求高，但允许几秒的延迟
• 广播对讲：司机和调度中心的语音通信。这个对实时性要求极高，延迟超过200ms就会感觉「卡」
• 时钟同步：全线的时钟必须一致，误差不能超过1秒。否则到站信息就乱了

你想想看，这些业务混在一起跑在同一个网络上。视频流占带宽，紧急信息要低延迟，时钟同步要精准。怎么协调？这就是网络架构要解决的问题。

1.4 流量特征：摸清PIS网络的脾气

做网络设计，第一件事就是摸清流量特征。PIS的流量，我总结为「三多一少」：

• 广播多：到站信息、时钟同步，都是全网广播。一个车站发，全线都要收
• 视频多：高清视频流，一路1080p就要4-8Mbps。一条线几十个站，加起来带宽需求不小
• 突发多：早晚高峰、节假日，信息更新频率暴增。平时1秒一次，高峰时可能0.2秒一次
• 控制流量少：设备配置、状态查询这类流量占比很小，但丢了也不行

为什么会这样？因为PIS本质上是一个「一对多」的系统。一个信息源（调度中心），要同时发给几十个车站、几百个车厢。这不就是典型的组播场景吗？

我个人习惯在项目初期就做流量测算。给你一个参考公式：

单站带宽需求 = 视频路数 × 单路码率 + 信息刷新频率 × 数据包大小 + 冗余余量（20%）

举个例子：一个车站有4块LCD屏，每路视频8Mbps，信息刷新每秒1次，每次数据包约50KB。那么：

单站带宽 = 4 × 8Mbps + 1 × 50KB × 8 + 20% ≈ 38.4Mbps + 0.4Mbps + 20% ≈ 46.6Mbps

嗯，这只是保守估算。实际项目中，我还会考虑视频编码波动、网络协议开销等因素。建议留出30%的余量。

1.5 小结：打好基础再谈冗余

这一章我们聊了PIS是什么、架构怎么演变的、跑什么业务、流量有什么特点。这些都是后续讲冗余设计的基础。

你想想看，如果连业务都不清楚，怎么设计冗余？视频流断了可以等几秒，紧急信息断了可是要出事的。不同的业务，冗余策略完全不同。

下一章，我会详细讲PIS网络的冗余设计原则。包括链路冗余、设备冗余、协议冗余，还有我踩过的那些坑。咱们到时候细聊。