4. 需求分类与层次：功能需求、性能需求、接口需求、安全需求、系统级与子系统级需求
好，咱们接着聊。上一章我们把需求获取的渠道和方法理清了，但拿回来的东西往往是杂乱的——用户说“我要车跑得稳”，供应商说“接口用MVB”，安全部门又说“必须满足SIL4”。这些需求怎么归类？怎么分层？
我个人习惯，拿到一堆原始需求后，第一件事不是写文档，而是先分类。就像整理工具箱，螺丝刀、扳手、钳子得各归其位。今天我们就聊聊ATO系统里，需求到底该怎么分、怎么分层。
4.1 功能需求：系统“做什么”
功能需求是最直观的。说白了，就是用户按下按钮后，系统该干什么。
举个例子，ATO的核心功能需求包括：
- 自动驾驶：在ATO模式下，列车能根据ATP指令自动加速、巡航、惰行、制动。
- 精准停车：列车进站后，车门对准站台屏蔽门，误差在±30cm以内。
- 车门控制：ATO根据ATP的开门允许信号，自动开/关列车门。
- 折返功能：列车到达终点站后，自动完成换端和折返作业。
这里要注意，功能需求描述的是“行为”，不是“指标”。比如“精准停车”是功能，而“停车精度±30cm”是性能需求。我见过不少新手把这两者混在一起写，结果评审时被问得哑口无言。
关键点：功能需求回答“系统做什么”，不回答“做得多快、多准”。
4.2 性能需求：系统“做得怎么样”
性能需求是功能需求的“量化指标”。没有性能指标的功能需求，就像没有刻度的尺子——没法验收。
我在项目中遇到过这样一个案例：用户提了“列车要平稳运行”的需求。这算功能还是性能？其实两者都有。功能是“能平稳运行”，性能是“冲击率不超过0.75m/s³”。
常见的ATO性能需求包括：
| 性能指标 | 典型值 | 说明 |
|---|---|---|
| 停车精度 | ±30cm | 对标屏蔽门 |
| 速度控制精度 | ±2km/h | 在目标速度附近波动范围 |
| 冲击率 | ≤0.75m/s³ | 保证乘客舒适度 |
| 响应时间 | ≤200ms | 从收到指令到执行动作 |
| 可用性 | ≥99.98% | 系统全年可用时间占比 |
你想想看，如果只写“速度控制要准”，那验收时我说±5km/h算准，你说±1km/h才算准，这就没法玩了。所以性能需求必须写清楚数值和条件。
小技巧：写性能需求时，记得加上“在什么条件下”。比如“在平直线路、干燥轨面条件下，停车精度±30cm”。条件不同，指标可能完全不同。
4.3 接口需求：系统“跟谁说话”
ATO不是孤岛。它要和ATP、ATS、车辆、屏蔽门、无线系统等一堆设备打交道。接口需求就是定义这些“对话规则”。
接口需求通常分三类：
- 硬件接口：比如ATO与ATP之间用MVB总线，波特率1.5Mbps，物理层用RS485。
- 软件接口：比如ATO向ATS上报位置信息，数据格式为JSON，包含“train_id, position, speed, direction”四个字段。
- 人机接口：比如DMI上显示“ATO模式激活”图标，绿色，尺寸30×30像素。
嗯，这里要特别提醒一下。接口需求最容易出问题的地方是“双方理解不一致”。我曾经吃过一次亏：ATO和车辆接口文档里写了“紧急制动指令”用数字0x01表示，结果车辆那边理解成了0x10。联调时一测试，车怎么都不停……后来查了两天才发现是位序搞反了。
避坑指南：接口需求必须双方确认，最好用接口控制文档（ICD）固定下来。别信口头约定，白纸黑字才是王道。
4.4 安全需求：系统“不能出事”
轨道交通是安全苛求系统。安全需求不是“锦上添花”，而是“一票否决”。
安全需求通常来自两个地方：一是危险源分析（比如HAZOP分析），二是安全标准（比如EN 50126、EN 50128、EN 50129）。
典型的ATO安全需求举例：
- 故障导向安全：ATO设备发生任何可检测故障时，必须输出安全侧状态（如紧急制动）。
- 防超速：ATO在任何情况下不得输出超过ATP允许速度的牵引指令。
- 车门安全联锁：列车未停稳时，ATO不得输出开门指令。
- 通信安全：ATO与ATP之间的通信数据必须包含CRC校验，防止数据被篡改。
安全需求有个特点：它往往不是“新增功能”，而是对已有功能的“约束”。比如“自动驾驶”这个功能，加上安全约束后就成了“在ATP监控下的自动驾驶”。
核心原则：安全需求不可协商。如果性能需求和安全需求冲突，安全优先。这是底线。
4.5 系统级与子系统级需求：从“整车”到“零件”
需求不仅要分类，还要分层。我习惯把需求分成两个层次：系统级和子系统级。
系统级需求描述的是“整个ATO系统对外表现出的特性”。比如：
- “ATO系统应支持在CBTC模式下实现自动驾驶。”
- “ATO系统应能在60秒内完成自动折返。”
子系统级需求则是对系统内部各个模块的细化。比如：
- “ATO主控单元应能接收ATP的速度指令，并计算目标速度曲线。”
- “ATO制动控制模块应能根据目标速度曲线输出电制动和空气制动的混合指令。”
为什么要分层？说白了，系统级需求是给用户和总体设计看的，子系统级需求是给开发人员看的。如果混在一起，用户看不懂技术细节，开发又抓不住重点。
我记得有一次评审，用户拿着子系统级需求说“这个CRC校验算法我不关心”，而开发拿着系统级需求说“这个停车精度指标我没法直接实现”。这就是分层没做好的典型症状。
我的做法：先写系统级需求，再逐层分解到子系统。每个子系统级需求都要能追溯到某个系统级需求。这样既保证完整性，又避免“过度设计”。
4.6 各类需求的关系与优先级
最后，我想聊聊这些需求之间的关系。它们不是孤立的，而是相互影响、相互制约的。
举个例子：功能需求“精准停车”驱动了性能需求“停车精度±30cm”，而性能需求又驱动了接口需求“ATO需从测速系统获取高精度位置信息”。同时，安全需求“防超速”对功能需求“自动驾驶”施加了约束。
优先级上，我个人排序是：
- 安全需求（必须满足，否则系统不可用）
- 功能需求（核心能力，缺了就不是ATO了）
- 接口需求（决定了系统能不能跟别人配合）
- 性能需求（决定了系统好不好用，但可以适当妥协）
当然，这个排序不是绝对的。如果用户明确要求“停车精度必须±10cm”，那性能需求就得往前排。但无论如何，安全需求永远是第一位的——这是我在这个行业里学到的最重要的一课。
好，这一章就到这里。下一章我们聊聊怎么把需求写成规范的文档，以及如何做需求评审。到时候我会分享一些我踩过的坑，保证有用。