第3章：需求分析与建模
安全关键系统的需求规范
做飞控这么多年，我最大的体会是：需求规范写不好，后面全是坑。你想想看，一个飞控系统在天上飞，代码里一个逻辑错误可能就是机毁人亡。所以需求规范这件事，真不是走个过场。
安全关键系统的需求规范，说白了就是要把「人要做什么」翻译成「机器要做什么」。我个人习惯用三层结构来组织：
- 系统级需求：描述整个飞控系统对外表现的行为。比如「飞机在失去GPS信号后，应能保持稳定飞行至少30秒」。
- 软件级需求：描述软件模块要完成的功能。比如「导航模块应在GPS失效后，自动切换至惯性导航模式」。
- 硬件级需求：描述硬件接口和性能约束。比如「IMU采样频率不低于200Hz，数据延迟不超过5ms」。
关键点：每一层需求都必须可验证、可追溯、无歧义。我在项目中遇到过，有人写「系统应快速响应」，结果测试时大家吵了半天——到底多快算「快速」？后来我们统一要求：所有时间指标必须带具体数值。
需求到模型的追溯方法
需求写完了，怎么保证模型真的实现了需求？这就涉及到追溯性。我个人最常用的方法是需求ID + 模型标签。
具体做法是这样的：
- 每条需求分配一个唯一ID，比如
REQ-NAV-001 - 在Simulink模型中，给对应的模块打上标签，比如
req:REQ-NAV-001 - 用工具自动生成追溯矩阵，检查有没有需求没被实现，或者模型里有多余的功能
嗯，这里要注意：不要等到模型做完了再补追溯。我曾经有个项目，团队先画模型再补需求标签，结果发现30%的模型功能根本不在需求文档里——那些都是工程师「顺手加的功能」。这在安全关键系统里是绝对不允许的。
我的小技巧：在Simulink里用Requirements Toolbox，可以直接把需求文档链接到模型模块。鼠标点一下模块，就能看到对应的需求原文。这样审查的时候特别方便。
使用Simulink进行高层级建模
高层级建模，说白了就是先画骨架，再填血肉。我习惯把模型分成三个层次：
| 层次 | 内容 | 抽象程度 |
|---|---|---|
| 架构层 | 系统模块划分、数据流、控制流 | 最高 |
| 行为层 | 状态机、逻辑判断、模式切换 | 中等 |
| 算法层 | 具体控制律、滤波器、数学运算 | 最低 |
做高层级建模时，我建议先画架构层。比如一个飞控系统，我会先画出：
- 传感器输入模块（IMU、GPS、气压计）
- 状态估计模块（融合传感器数据）
- 控制律模块（计算舵面指令）
- 执行器输出模块（发送PWM信号）
这些模块之间用信号线连接，数据流向一目了然。等架构层确认没问题了，再往下细化每个模块的内部行为。
避坑指南：我曾经在架构层偷懒，把传感器融合和导航逻辑画在同一个模块里。结果后来要改导航算法，发现传感器融合也被牵连了。从那以后，我坚持每个模块只做一件事，接口定义清楚。
知识体系结构图
下面这张图，是我自己总结的需求分析与建模的核心逻辑。你可以把它当作本章的「地图」：
一个实际例子
拿「高度保持模式」来说。需求原文可能是：
REQ-ALT-001：当飞机进入高度保持模式时，高度误差应控制在±5米以内。在Simulink里，我会先建一个架构层模块叫 AltitudeHoldController，输入是当前高度和目标高度，输出是升降舵指令。然后在行为层，用Stateflow画状态机：
- 状态1：爬升/下降（误差大时）
- 状态2：微调（误差小时）
- 状态3：保持（误差在范围内）
最后在算法层，填入具体的PID参数。每个模块都打上需求标签 req:REQ-ALT-001。这样审查时，鼠标一点就知道这个模块对应哪条需求。
总结一下：需求规范是地基，追溯方法是钢筋，高层级建模是框架。三者缺一不可。我见过太多项目，模型画得漂亮，但一问「这个模块对应哪条需求」，没人答得上来——这种模型，我不敢让它飞上天。