2. 系统与软件交互：系统需求到软件需求的映射、系统安全评估过程
好，咱们进入第二章。这一章讲的是系统跟软件怎么“对话”。说白了，就是系统需求怎么变成软件需求，以及安全评估怎么贯穿始终。
我见过不少团队，系统工程师把需求文档往墙上一扔，说“你们软件看着办吧”。结果呢？软件做完了，系统集成时发现牛头不对马嘴。嗯，这其实是个大坑。
2.1 系统需求到软件需求的映射
系统需求是“飞机要能飞多高、多快”。软件需求是“飞控软件要每秒采集100次高度数据”。这两者之间，差了一个“映射”的过程。
我个人习惯，把这个映射分成三步走：
- 分解：把系统级的功能，拆成软件能执行的动作。
- 分配：明确哪些功能由软件实现，哪些由硬件实现。
- 追溯：建立双向追溯表，确保每条软件需求都能找到“爹”。
核心原则：软件需求必须可验证、可测试、无歧义。系统需求可以写“提高安全性”，但软件需求必须写“当高度低于100米时，触发告警”。
我在项目中遇到过一件事。系统需求里写了一句“系统应具备故障自诊断能力”。软件团队直接写了个“每5秒跑一次自检”。结果硬件那边根本没设计自检电路。你看，这就是映射没做好——软件需求必须明确“自检什么、怎么检、结果给谁”。
2.2 系统安全评估过程
安全评估，DO-178C里叫“系统安全评估过程”（SSAP）。它跟软件开发是并行的，不是事后补的。
你想想看，如果等到代码写完了才发现某个功能会导致灾难性故障，那改起来得多痛苦？
安全评估的核心输出是：
- 功能危险评估（FHA）：识别每个功能失效会带来什么后果。
- 初步系统安全评估（PSSA）：分析系统架构能否满足安全目标。
- 系统安全评估（SSA）：验证最终实现是否满足安全要求。
我的小技巧：在PSSA阶段，我会让软件工程师也参与进来。因为有些失效模式，只有写代码的人才知道。比如“数据溢出”这种，系统工程师根本想不到。
2.3 安全等级与软件等级
系统安全评估会给出每个功能的安全等级（A、B、C、D、E）。这个等级直接决定了软件要按哪个软件等级来开发。
举个例子：
| 失效影响 | 安全等级 | 软件等级 | 开发要求 |
|---|---|---|---|
| 灾难性 | A | Level A | 最严格，需独立验证 |
| 危险的 | B | Level B | 严格，需结构覆盖分析 |
| 主要的 | C | Level C | 中等，需语句覆盖 |
| 次要的 | D | Level D | 较低，需基本测试 |
| 无影响 | E | Level E | 无特殊要求 |
注意：我曾经见过一个项目，系统工程师把某个功能标成了Level C，结果软件团队按Level C开发。后来发现这个功能失效会导致“危险的”后果——因为系统工程师漏掉了一个级联失效场景。所以，安全等级的分配一定要经过独立评审。
2.4 系统与软件的交互接口
系统跟软件之间，不是单向的“需求传递”。它们需要几个关键接口：
- 系统需求文档（SRD）：系统给软件的“输入”。
- 软件需求文档（SRD）：软件给系统的“承诺”。
- 系统安全评估报告（SSAR）：安全评估的“结论”。
- 软件等级确定文档：明确软件要按哪个等级开发。
我个人习惯，在项目启动时就把这些文档的模板定好。不然到了后期，你会发现大家都在“补文档”，而不是“用文档”。
2.5 核心逻辑框架图
下面这张图，是我自己总结的“系统与软件交互”核心逻辑。你看一眼就能明白整个流程：
这张图的核心逻辑是：系统需求先做FHA，得出安全等级。安全等级决定了软件等级。同时，PSSA和SSA贯穿始终，确保安全目标被满足。最后，软件需求必须跟安全评估结果保持一致。
避坑指南：我曾经在一个项目中，软件需求写完了才发现安全等级是A，但软件需求里根本没有考虑冗余设计。结果只能返工。所以，我建议在写软件需求之前，先确认安全等级和软件等级。
2.6 映射过程中的常见问题
我总结了几条“血泪教训”：
- 需求遗漏：系统需求里写了“故障告警”，但软件需求里只写了“告警”，没写“故障检测逻辑”。
- 需求冲突：系统要求“响应时间小于10ms”，但软件架构设计出来只能做到50ms。
- 安全等级误判：把灾难性功能误判为次要功能，导致软件验证不足。
特别提醒：DO-178C要求“双向追溯”。也就是说，每条软件需求都要能追溯到系统需求，每条系统需求也要能查到它被哪些软件需求实现了。这个追溯表，建议用工具管理，别用手工Excel——我吃过这个亏，后期维护起来想哭。
好了，这一章就到这里。系统与软件的交互，说白了就是“翻译”和“验证”的过程。翻译要准确，验证要严格。下一章我们会深入软件需求的具体编写方法。
公众号:蓝海资料掘金营，微信deep3321