第二章：系统需求分析
好，咱们进入第二章。需求分析，说白了就是搞清楚「我们要造个什么东西」。
我见过太多项目，上来就画电路板、写代码，结果做到一半发现需求没对齐，推倒重来。PIS系统尤其如此——它直接面向乘客，一出错就是群体性事件。所以，这一章咱们把需求掰开揉碎了讲。
2.1 功能需求分析
功能需求，就是「系统要干什么」。PIS系统的核心功能，我归纳为四大块：
- 信息发布：到站信息、换乘指引、紧急通知。这是最基础的功能，也是乘客最在意的。
- 广播控制：自动报站、人工广播、紧急广播。注意，广播和显示必须同步，不能出现「显示已到站，广播还在报上一站」的情况。
- 乘客交互：触摸查询、紧急通话按钮。这部分我建议做防误触设计，你想想看，小孩子乱按紧急按钮，后台会疯掉的。
- 系统管理：设备状态监控、日志记录、远程升级。嗯，远程升级这个功能，我在项目里吃过亏——升级过程中断电，设备变砖。后面会讲怎么处理。
重点提醒：功能需求一定要区分「必备」和「可选」。比如紧急广播是必备，但触摸查询在某些低端线路可以砍掉。别让甲方把所有功能都写成「必须」，否则项目周期会失控。
2.2 性能需求分析
性能需求，就是「系统要跑多快、多稳」。我习惯从三个维度去拆解：
| 维度 | 指标 | 我的建议值 |
|---|---|---|
| 实时性 | 信息更新延迟 | ≤ 200ms（从列车定位到屏幕显示） |
| 并发性 | 同时服务终端数 | 单台服务器支持 ≥ 200个终端 |
| 存储容量 | 日志与媒体存储 | 至少保留30天数据，按1天1GB估算 |
这里有个坑——实时性。很多人以为只要网络快就行，其实不然。我曾经遇到一个项目，网络延迟只有10ms，但屏幕刷新还是卡顿。查了半天，发现是UI渲染线程被广播解码占用了。所以，性能分析一定要考虑「资源竞争」。
我的小技巧：做性能分析时，先画一张「数据流图」。从传感器到服务器，再到终端，每个环节标注延迟预算。这样哪里是瓶颈，一目了然。
2.3 可靠性需求分析
可靠性，说白了就是「别关键时刻掉链子」。PIS系统一旦失效，轻则乘客投诉，重则引发恐慌。
我一般把可靠性分成三个等级：
- 单点故障不扩散：一个终端坏了，不影响其他终端。这个通过独立供电和独立通信链路实现。
- 关键功能冗余：比如广播服务器，我建议做1+1热备。主备切换时间控制在5秒以内。
- 降级运行：当主系统崩溃时，本地终端能独立播放预存信息。嗯，这个功能我在某地铁项目里救过场——那次中心服务器宕机了4小时，全靠本地降级模式撑着。
注意：可靠性不是堆硬件就能解决的。我曾经见过一个项目，双机热备做得很好，但切换逻辑有bug——主备同时认为自己是主，结果两台机器互相打架。所以，可靠性测试一定要做「故障注入」，人为制造各种异常场景。
2.4 安全性需求分析
安全性，分两块：功能安全和信息安全。
功能安全，主要针对广播系统。你想想看，如果紧急广播被误触发，或者音量突然爆增，会是什么后果？我建议参考IEC 61508标准，至少达到SIL 2等级。
信息安全，现在越来越重要。PIS系统虽然不直接控制列车，但它连接着内部网络。一旦被黑客攻破，可能成为跳板攻击其他系统。
我总结了几条必须做的安全措施：
- 网络隔离：PIS系统必须与列车控制网络物理隔离。别用同一个交换机，别问我为什么知道——
- 身份认证：所有远程操作都需要双因子认证。密码+动态令牌，或者密码+生物识别。
- 数据加密：敏感信息（如乘客隐私数据）传输时必须加密。AES-256起步。
- 日志审计：谁在什么时候做了什么操作，全部记录。出了事能追溯。
避坑指南：我曾经遇到一个项目，甲方要求「所有数据必须加密」，结果没考虑嵌入式设备的算力限制。加密解密把CPU占满了，导致广播卡顿。后来我们改用硬件加密芯片，才解决问题。所以，安全方案一定要和硬件性能匹配。
2.5 接口需求分析
接口需求，就是「系统怎么跟外界打交道」。PIS系统的接口，我分成三类：
| 接口类型 | 对接对象 | 协议/方式 |
|---|---|---|
| 列车接口 | TCMS（列车控制与管理系统） | MVB、CAN、以太网 |
| 地面接口 | 中心服务器、OCC（运营控制中心） | TCP/IP、MQTT、HTTP |
| 人机接口 | 乘客、维护人员 | 触摸屏、按键、语音 |
这里有个关键点——接口协议一定要「松耦合」。我习惯的做法是：在PIS系统内部定义一个「标准数据模型」，所有外部接口都通过适配器转换成这个模型。这样，即使列车接口从MVB换成CAN，我只需要改适配器，核心逻辑不用动。
另外，接口文档一定要写清楚「异常处理」。比如，如果TCMS突然断连，PIS系统应该怎么办？是保持最后一次有效数据，还是切换到本地预存模式？这些细节，在需求阶段就要定下来。
我的经验：接口需求分析时，最好拉上对接系统的工程师一起开会。别自己闷头写文档，否则你会发现——你理解的「数据帧格式」和对方理解的完全不一样。这种事，我经历过不止一次。
好了，第二章的需求分析就到这里。下一章，咱们开始聊硬件架构设计——怎么选主控芯片、怎么搭通信网络。到时候我会分享一些选型时的血泪史，敬请期待。