第一章：PIS系统概述
1.1 什么是PIS系统
PIS系统，全称是乘客信息系统（Passenger Information System）。
说白了，它就是轨道交通的「嘴巴」和「眼睛」。你在地铁站里看到的那些显示屏、听到的广播、手机上刷到的列车到站时间，背后都是PIS系统在干活。
我个人习惯把PIS系统比作「车站的大脑神经」。它不直接控制列车跑多快，但它告诉乘客什么时候该上车、哪边门会开、下一站是哪里。没有它，乘客就像蒙着眼坐车。
我在项目中遇到过不少这样的情况——甲方觉得PIS就是个「播报系统」，随便搞搞就行。结果一上线，乘客投诉说听不清广播、屏幕显示错乱、到站信息延迟。嗯，这时候他们才意识到PIS的重要性。
核心定义：PIS系统是利用多媒体技术，为乘客提供列车运行信息、换乘指引、紧急通知等服务的综合信息系统。它是轨道交通运营中与乘客交互最直接的窗口。
1.2 PIS系统的核心功能
PIS系统到底能干些什么？我把它拆成四个核心模块来讲。
1.2.1 信息发布功能
这是PIS最基础的功能。包括：
- 列车到站信息：下一班车几分钟到、终点站是哪
- 换乘指引：在哪个站台换乘、步行距离多远
- 运营公告：末班车时间调整、临时停运通知
- 紧急信息：火灾、地震等突发事件的疏散指引
你想想看，如果到站信息延迟了10秒，乘客可能就错过了一班车。我曾经在一个项目里遇到过，因为网络抖动导致信息延迟，乘客在站台上干等了3分钟，投诉电话被打爆了。
1.2.2 广播功能
广播不是简单的「放录音」。它要能做到：
- 自动播报：列车进站时自动触发「开左边门」的提示
- 分区广播：站台区和站厅区播不同的内容
- 紧急广播：一键切换，覆盖所有区域
- 多语言支持：中文、英文，有些线路还有方言
这里有个坑。我记得有一次测试，广播系统在高峰期同时触发20个播报请求，结果系统直接卡死了。后来发现是并发处理能力没做够。嗯，这就是性能测试要解决的问题。
1.2.3 显示功能
显示屏是PIS的「脸面」。常见的显示内容有：
- LED条屏：显示简单的文字信息，比如「列车即将进站」
- LCD显示屏：显示动态地图、换乘路线、广告
- PDP大屏：显示列车时刻表、运营公告
我个人建议，显示内容的刷新频率至少要控制在1秒以内。超过2秒，乘客就会觉得「这屏幕是不是坏了」。
1.2.4 监控与联动功能
PIS不是孤立的系统。它要和信号系统、广播系统、消防系统联动。比如：
- 信号系统告诉PIS「列车还有30秒到站」，PIS就自动触发广播和显示
- 消防系统触发报警，PIS立刻切换到紧急疏散模式
我在项目中见过最头疼的问题，就是联动接口的响应时间。信号系统发来一个数据包，PIS要解析、处理、再推送到终端。如果这个链路超过500毫秒，乘客看到的信息就是滞后的。
避坑指南：我曾经因为忽略了联动接口的性能测试，上线后发现PIS和信号系统的数据同步延迟高达3秒。后来花了整整两周做接口优化。所以，联动接口的性能测试一定要放在前期做。
1.3 PIS系统的典型架构
PIS系统的架构，我习惯分成三层来看：
| 层级 | 名称 | 主要设备 | 功能 |
|---|---|---|---|
| 第一层 | 中心层 | 服务器、数据库、管理工作站 | 数据汇聚、策略下发、全局监控 |
| 第二层 | 车站层 | 车站控制器、交换机、本地服务器 | 本地数据处理、终端控制、断网自运行 |
| 第三层 | 终端层 | 显示屏、广播设备、查询机 | 信息展示、乘客交互 |
1.3.1 中心层
中心层是PIS的「大脑」。所有运营数据都在这里汇聚。比如列车时刻表、运营计划、紧急通知，都是从中心层下发到各个车站的。
中心层的性能瓶颈通常出现在数据库和消息队列上。我记得有一次做压力测试，模拟100个车站同时请求数据，中心服务器的CPU直接飙到95%。后来加了缓存和读写分离，才把压力降下来。
1.3.2 车站层
车站层是PIS的「神经中枢」。它负责接收中心层下发的数据，然后控制本站的所有终端设备。
这里有个关键点：车站层必须支持离线运行。万一中心网络断了，车站层要能根据本地缓存的数据继续工作。我见过一个项目，网络断了之后车站层直接瘫痪，所有屏幕都黑了。这就是架构设计没考虑容错。
1.3.3 终端层
终端层是PIS的「手脚」。包括站台上的LED屏、车厢里的LCD屏、站厅里的广播喇叭。
终端层的性能测试重点在于：
- 响应时间：从中心下发指令到终端显示，不能超过2秒
- 并发能力：高峰期同时更新100块屏幕，系统不能卡顿
- 稳定性：7×24小时连续运行，不能死机
警告：终端设备的性能测试往往被忽视。很多人觉得「屏幕显示个文字能有什么性能问题？」但实际测试中，我发现终端设备的CPU和内存资源非常有限。如果推送的数据量太大，终端会直接黑屏重启。所以，终端层的性能测试一定要做，而且要做极限测试。
1.4 为什么PIS系统需要性能测试
讲到这里，你可能会问：PIS系统不就是播报信息吗？性能测试有那么重要吗？
我直接告诉你答案：非常重要。
原因有三：
- 实时性要求高：列车到站信息延迟几秒，乘客就可能坐过站
- 并发量大：早晚高峰期，一个车站可能有上万人同时查看信息
- 可靠性要求高：PIS系统一旦崩溃，整个车站的运营都会受影响
我曾经参与过一个地铁线路的PIS系统验收测试。当时模拟了早高峰的并发场景，结果发现系统在500个终端同时请求数据时，响应时间从0.5秒飙升到了8秒。甲方当场就拒绝了验收。后来我们花了三周时间做性能优化，才把响应时间压回到1秒以内。
所以，性能测试不是「锦上添花」，而是「雪中送炭」。没有性能测试的PIS系统，就像没有安全带的汽车——平时看着没事，一出事就是大事。
本章小结：PIS系统是轨道交通的「信息中枢」，核心功能包括信息发布、广播、显示和联动。典型架构分为中心层、车站层和终端层。性能测试是保障PIS系统稳定运行的关键环节，不能忽视。