4. 系统需求分析：功能需求、安全需求、接口需求、性能需求的捕获与建模
好，咱们进入正题。座舱显示系统这东西，说白了就是飞行员的眼睛。需求分析要是做漏了，后面流片回来发现少个接口，那可不是闹着玩的。我个人习惯，拿到项目先别急着写代码，把需求掰开了揉碎了，再动手。
4.1 功能需求：飞行员要什么，我们就给什么
功能需求是最直观的。飞行员要看到空速、高度、航向，要能切换显示模式，要能输入飞行计划。这些都属于功能需求。
我一般会把功能需求分成三类：
- 显示功能：比如主飞行显示器（PFD）要显示姿态、空速、高度、垂直速度。导航显示器（ND）要显示地图、航路点、气象信息。
- 交互功能：按键响应、触摸屏手势、旋钮调节。我记得有个项目，客户要求触摸屏支持戴手套操作，这个在需求里就得写清楚。
- 告警功能：近地告警、风切变告警、空中防撞告警。告警的优先级、显示方式、声音提示，都得一条条列出来。
关键点：功能需求必须可验证。别写“系统应快速响应”，要写“系统应在100ms内响应按键输入”。
举个例子，PFD的功能需求可以这样建模：
需求ID: REQ-PFD-001
描述: 主飞行显示器应显示飞机姿态信息
子项:
- 显示俯仰角，范围±90°，精度±0.5°
- 显示横滚角，范围±180°，精度±0.5°
- 显示侧滑指示
验证方法: 注入模拟姿态数据，检查显示值与输入值偏差4.2 安全需求：不出事，比什么都重要
安全需求，这是座舱显示系统的命根子。你想想看，飞行员在天上全靠这块屏幕。屏幕黑了，或者显示错误数据，后果不堪设想。
安全需求通常来自两个地方：一是适航标准（比如DO-178C、DO-254），二是系统安全评估（比如FHA、FMEA）。
我遇到过最头疼的事，是安全需求写得模棱两可。比如“系统应具备故障容错能力”，这等于没写。要写成“当主显示通道失效时，备份通道应在50ms内接管显示”。
避坑指南：我曾经在一个项目中，安全需求里写了“系统应避免显示错误数据”，结果审查时被问“怎么证明你避免了？”后来我们改成“系统应具备数据交叉校验功能，当两个独立源数据偏差超过5%时，触发告警并显示无效数据标识”。
安全需求建模，我推荐用表格：
| 需求ID | 安全目标 | 失效条件 | 安全等级 | 验证方法 |
|---|---|---|---|---|
| REQ-SAF-001 | 显示数据完整性 | 显示错误空速 | Level A | 注入错误数据，检查告警触发 |
| REQ-SAF-002 | 显示连续性 | 屏幕黑屏 | Level A | 切断主电源，检查备份电源切换 |
| REQ-SAF-003 | 告警正确性 | 误告警或漏告警 | Level B | 模拟告警条件，检查告警输出 |
4.3 接口需求：连不上，一切都是白搭
接口需求，说白了就是系统怎么跟外界通信。座舱显示系统要跟飞控计算机、导航系统、发动机参数采集器、甚至客舱娱乐系统打交道。
接口需求要写清楚三件事：
- 物理接口：ARINC 429、ARINC 664（AFDX）、CAN、以太网。我记得有个项目，客户要求用光纤接口，结果我们没注意光纤的弯曲半径限制，布线时吃了大亏。
- 电气特性：电压电平、信号速率、终端电阻。这些参数错了，信号就收不到。
- 协议格式：数据帧结构、校验方式、更新频率。比如ARINC 429，每个字的Label、SDI、SSM都得定义清楚。
个人经验：接口需求最容易出问题的是时序。我曾经遇到一个情况，飞控计算机每20ms发一次数据，但显示系统处理需要25ms，结果数据一直堆积。后来我们在需求里加了“接收缓冲区至少能缓存3帧数据”。
接口需求建模示例：
接口ID: IF-429-001
类型: ARINC 429 接收
速率: 100 kbps
Label: 206 (空速)
更新率: 50 Hz
数据格式: BNR, 12位数据, 分辨率0.125节
校验: 奇校验
电气: 差分信号, 5V电平4.4 性能需求：快、准、稳
性能需求，就是系统跑得快不快、准不准、稳不稳。座舱显示系统对性能要求极高，因为飞行员的眼睛很敏感。
性能需求通常包括：
- 实时性：画面刷新率、数据更新延迟。我一般要求PFD刷新率不低于60Hz，数据延迟不超过50ms。
- 精度：显示数值的误差范围。比如空速显示误差不超过±1节，高度显示误差不超过±10英尺。
- 可靠性：MTBF（平均无故障时间）、MTTR（平均修复时间）。座舱显示系统MTBF通常要求不低于10000小时。
- 资源占用：CPU使用率、内存占用、GPU负载。这些在需求里就得定好上限，不然后期优化很痛苦。
关键点：性能需求一定要有量化指标。别写“系统应运行流畅”，要写“在最大负载下，CPU使用率不超过70%，内存占用不超过512MB”。
性能需求建模，我习惯用表格加测试用例：
| 需求ID | 性能指标 | 目标值 | 测试条件 |
|---|---|---|---|
| REQ-PERF-001 | 画面刷新率 | ≥60 fps | 全屏显示，最大数据量 |
| REQ-PERF-002 | 数据延迟 | ≤50 ms | 从传感器输入到屏幕显示 |
| REQ-PERF-003 | CPU使用率 | ≤70% | 典型飞行场景 |
| REQ-PERF-004 | 内存占用 | ≤512 MB | 持续运行4小时 |
4.5 需求建模：把需求变成可追踪的资产
需求捕获完了，不能就扔在Word文档里。要建模，要建立需求之间的关联关系。
我常用的建模方法：
- 需求编号：每个需求一个唯一ID，方便追踪。
- 需求层级：顶层需求、子需求、详细需求。比如“显示空速”是顶层，“空速数值显示”和“空速趋势显示”是子需求。
- 需求关联：功能需求关联安全需求，安全需求关联测试用例。这样改一个需求，就知道会影响哪些测试。
- 需求状态：已定义、已评审、已实现、已验证。我习惯用工具（比如DOORS、Jama）来管理，但小项目用Excel也行。
个人习惯：我每个需求都会加一个“来源”字段，是来自客户要求、适航标准、还是系统分析。这样审查时能快速定位依据。
需求建模示例：
需求ID: REQ-PFD-001
层级: 顶层
来源: 客户需求文档 v2.3
关联安全需求: REQ-SAF-001, REQ-SAF-002
关联测试用例: TC-PFD-001, TC-PFD-002
状态: 已实现
备注: 2024年3月评审通过嗯，到这里，需求分析这块基本就讲完了。记住一句话：需求分析做得越细，后面开发越顺。我见过太多项目，需求阶段省了三天，后期返工花了三周。别犯这个错。