3. 系统与软件关联：系统需求到软件需求的分配、系统安全评估过程（SSA）、功能危险分析（FHA）与软件等级的关系
好，咱们今天聊一个非常核心的话题——系统与软件的关联。很多刚入行的朋友总觉得，搞软件的就把代码写好，搞系统的就把需求写清楚，各干各的。但实际做适航认证的时候，你会发现这两者根本分不开。我这些年踩过的坑，有一半都出在系统与软件的接口上。
3.1 从系统需求到软件需求：不是简单的“翻译”
系统需求怎么变成软件需求？很多人以为就是把系统需求里的“实现什么功能”直接抄过来。其实没那么简单。
我个人习惯的做法是：先搞清楚系统需求里哪些是软件要干的活。举个例子，系统说“飞机在高度低于100英尺时，必须发出近地告警”。这个需求到了软件这边，你得拆解成：
- 软件需要获取高度数据（从哪里来？精度多少？）
- 软件需要判断高度阈值（100英尺是硬阈值还是可配置？）
- 软件需要输出告警信号（什么格式？驱动什么硬件？）
你看，一个系统需求，到了软件层面就变成了好几个具体的软件需求。我在项目中遇到过最头疼的情况是，系统工程师写了个“软件应具备自动导航功能”，结果软件团队花了三个月实现，最后发现系统那边期望的“自动导航”和我们理解的完全不一样。嗯，这就是典型的系统需求到软件需求分配没做好。
关键原则：每个软件需求必须能追溯到至少一个系统需求。反过来，每个系统需求中涉及软件的部分，必须被完整地分配到软件需求中。这叫“双向追溯”。
3.2 功能危险分析（FHA）：危险的源头
功能危险分析，简称FHA。说白了就是回答一个问题：这个功能如果出问题了，后果有多严重？
FHA通常在系统层面做，但它的结果直接影响软件。为什么？因为FHA会给出每个功能失效的“严重性等级”。
我举个例子，你想想看：
- 如果“起落架收放控制”功能失效，飞机可能无法着陆——这是灾难性的
- 如果“客舱灯光控制”功能失效，乘客可能有点不舒服——这是轻微的
FHA的输出就是一张表，里面列着每个功能、失效模式、失效影响、严重性等级。这张表，就是后续所有工作的基础。
我的经验：做FHA的时候，一定要拉上系统、软件、硬件三方的人一起讨论。我曾经见过一个项目，系统自己闷头做FHA，结果软件实现的时候发现有些失效场景根本覆盖不了，最后只能返工改需求。浪费了整整两个月。
3.3 系统安全评估过程（SSA）：验证你的设计够不够安全
系统安全评估，SSA，是在设计完成后做的。它要回答的问题是：我们设计出来的系统，到底能不能满足FHA里定下的安全目标？
SSA和FHA的关系，你可以这么理解：
- FHA是“找问题”
- SSA是“验证解决方案”
举个例子，FHA发现“高度传感器失效”会导致“虚假近地告警”，严重等级是“危险的”。那么SSA就要检查：我们设计的冗余传感器架构、故障检测逻辑、告警抑制机制，能不能把这个风险降到可接受的水平？
我记得有一次做SSA，发现某个失效组合的概率刚好卡在边界上。系统工程师说“差不多就行了”，但我坚持要求加一个额外的监控逻辑。为什么？因为适航审查员不会跟你讲“差不多”。
注意：SSA不是一次性的工作。设计改了，SSA就要跟着更新。我见过不少项目，设计改了三轮，SSA文档还是最初那一版。审查的时候被开了不符合项，得不偿失。
3.4 软件等级：FHA和SSA的“输出”
软件等级，也就是DAL（Design Assurance Level），是从FHA和SSA里推导出来的。具体对应关系如下：
| 失效影响严重性 | 软件等级 | 说明 |
|---|---|---|
| 灾难性的 | DAL A | 导致飞机坠毁或多人死亡 |
| 危险的 | DAL B | 严重降低飞机安全裕度，可能造成伤亡 |
| 重大的 | DAL C | 显著降低飞机能力，可能造成乘客不适 |
| 轻微的 | DAL D | 轻微影响，乘客可能注意到但不危险 |
| 无影响的 | DAL E | 不影响安全 |
这个表看起来简单，但实际应用的时候有很多细节。比如，一个功能可能由多个软件组件共同实现，每个组件的DAL等级可能不一样。怎么分配？这就要靠SSA来分析了。
我曾经参与过一个项目，飞控计算机的主控软件是DAL A，但它的自检软件只定了DAL C。为什么？因为SSA分析证明，自检软件失效不会导致飞控功能丧失，有其他的冗余路径可以兜底。这就是SSA指导DAL分配的典型例子。
3.5 三者之间的关系：一张图说清楚
为了让你更直观地理解FHA、SSA和软件等级的关系，我画了一张流程图：
3.6 实践中的常见问题
说了这么多理论，我分享几个实际项目中常见的问题：
- FHA做得太粗——只分析了功能级，没分析到子功能级。结果到了软件实现时，发现有些子功能的失效模式根本没覆盖到。
- SSA和设计脱节——设计改了，SSA没更新。审查的时候被问“你这个安全分析怎么和实际设计对不上？”
- DAL等级分配不合理——有的项目把所有软件都定成DAL A，觉得“越高越安全”。其实没必要，而且DAL A的开发成本是DAL D的几十倍。合理的做法是通过SSA分析，把高DAL只分配给真正影响安全的部分。
避坑指南：我曾经有一个项目，系统工程师把FHA里所有“危险的”失效都直接对应到DAL B。但后来SSA分析发现，有些“危险的”失效通过硬件冗余已经解决了，软件只需要做DAL C就够了。这一下省了将近30%的开发成本。所以，别偷懒，SSA该做还得做。
3.7 小结
系统与软件的关联，说白了就是一条链：FHA找问题 → 系统需求定目标 → 软件需求接任务 → SSA验证方案 → DAL定等级。每一步都不能跳，每一步都要有文档记录。
你想想看，如果FHA漏了一个失效模式，后面的所有工作都是白费。如果SSA没做透，DAL等级定错了，要么成本失控，要么安全不达标。这就是为什么适航审查员最喜欢看的就是FHA、SSA和DAL分配这三份文档——它们能反映出整个团队对安全的理解深度。
嗯，今天就聊到这里。记住一句话：系统与软件的接口，是适航认证中最容易出问题的地方，也是最能体现工程师水平的地方。
公众号:蓝海资料掘金营，微信deep3321