4、系统与软件接口：系统需求到软件需求的分配、系统安全性评估（如ARP4754A、ARP4761）与软件等级（DAL）的确定

在DO-178C的实践中，软件并非孤立存在，而是嵌入在航空系统（如飞控计算机、发动机FADEC、导航处理器）中的组成部分。适航认证的起点并非软件代码，而是系统层面的需求定义与安全性评估。本章聚焦于系统与软件的接口——即系统需求如何被正确分配为软件需求，以及系统安全性评估过程（依据ARP4754A与ARP4761）如何决定软件的适航等级（DAL）。理解这一接口是确保软件认证成本合理、安全性达标的关键前提。

4.1 核心原理：系统需求与软件需求的层级关系

ARP4754A（民用飞机与系统研制指南）定义了从飞机级需求到系统需求、再到软硬件需求的层级分解过程。软件需求并非凭空产生，而是系统需求在软件实现域中的投影。这一过程的核心原则是双向可追溯性：每条软件需求必须向上追溯到一条或多条系统需求，而每条系统需求也必须向下覆盖到软件或硬件需求。

在实际工程中，系统需求通常以自然语言或SysML模型表达，包含功能行为、性能指标（如响应时间、吞吐量）、接口协议（如ARINC 429、CAN、AFDX）、安全性约束（如故障响应时间、监控阈值）以及物理环境约束（温度、振动、EMC）。软件需求则将这些系统级描述转化为软件可实现的规格，包括：

• 功能需求：软件必须执行的具体操作，如“当接收到高度表数据时，以100ms周期更新输出”。
• 性能需求：时间约束、内存占用、CPU利用率上限等。
• 接口需求：数据格式、协议帧结构、信号电平、时序要求。
• 安全性需求：由系统安全性评估导出的特定保护机制，如“检测到传感器失效时，在50ms内切换至备份通道”。

需求分配过程中最常见的错误是需求丢失——系统级隐含假设未在软件需求中显式声明。例如，系统可能假设软件在启动时自动执行自检，但该假设未写入软件需求，导致后续验证遗漏。因此，DO-178C要求软件需求与系统需求之间建立完整的追溯矩阵，并在软件计划阶段（PSAC）中明确追溯方法。

4.2 系统安全性评估与DAL确定方法

软件等级（DAL）的确定并非软件工程师自行决定，而是由系统安全性评估过程推导得出。ARP4761（民用机载系统安全性评估过程指南）提供了标准方法，其核心流程如下：

1. 功能危险评估（FHA）：在飞机和系统层面识别功能失效状态，并分类其严重性。例如，飞控系统“失去俯仰控制”被归类为灾难性（Catastrophic），而“座舱温度调节失效”可能仅为轻微（Minor）。
2. 初步系统安全性评估（PSSA）：在系统设计阶段，通过故障树分析（FTA）、失效模式与影响分析（FMEA）等方法，将飞机级失效状态分解为系统级失效条件，并分配安全性需求。
3. 系统安全性评估（SSA）：在系统实现后，验证设计是否满足PSSA中定义的安全性需求，并确认实际失效概率满足目标。

DAL的确定遵循DO-178C Table 1的映射关系：

失效状态分类	定义	允许概率（每飞行小时）	软件DAL
灾难性（Catastrophic）	阻止飞机继续安全飞行或着陆	< 10⁻⁹	A
危险性（Hazardous）	安全裕度大幅降低，机组无法完成任务	< 10⁻⁷	B
重大（Major）	显著降低安全裕度，机组工作负担增加	< 10⁻⁵	C
轻微（Minor）	轻微降低安全裕度，乘客不便	< 10⁻³	D
无影响（No Effect）	不影响安全性	无要求	E

值得注意的是，DAL分配是逐功能、逐失效状态进行的。一个软件组件可能同时包含多个功能，每个功能对应不同的DAL。此时，整个软件组件的DAL取所有功能中的最高等级。例如，一个飞控计算机软件中，俯仰控制功能为DAL A，而维护数据记录功能为DAL D，则整个软件必须按DAL A开发。

4.3 案例拆解：某飞控计算机的DAL分配与需求分配实践

以下通过一个简化案例说明系统需求到软件需求的分配过程及DAL确定逻辑。

背景与约束：某无人机飞控计算机需要实现三个核心功能：①主飞行控制（俯仰/滚转/偏航）；②飞行数据记录；③地面维护接口。飞机级FHA识别出“失去主飞行控制”为灾难性失效状态，概率目标<10⁻⁹/飞行小时；“飞行数据丢失”为轻微失效状态，概率目标<10⁻³/飞行小时；“维护接口误操作导致飞行参数错误”被评估为重大失效状态，概率目标<10⁻⁵/飞行小时。

分析判断过程：

• 主飞行控制功能 → DAL A（灾难性）
• 飞行数据记录功能 → DAL D（轻微）
• 地面维护接口 → DAL C（重大）

由于三个功能运行在同一颗CPU上，共享内存和I/O，因此整个软件组件必须按DAL A开发。但为了控制成本，系统架构师决定采用分区隔离方案：将主飞行控制放在独立的内存分区（分区1），数据记录和维护接口放在另一分区（分区2），通过ARINC 653分区调度器隔离。这样，分区2的软件可以按DAL C开发，而分区1按DAL A开发，分区调度器本身按DAL A开发。

需求分配示例：

系统需求（SR-001）：当俯仰角速率传感器失效时，飞控系统应在50ms内切换至备用传感器。
  → 软件需求（SWR-001）：软件应每10ms读取俯仰角速率传感器状态字；
     若连续3次读取到失效标志，则切换传感器通道。
  → 软件需求（SWR-002）：切换操作应在检测到失效后的20ms内完成（含中断延迟）。
  → 软件需求（SWR-003）：切换后应生成维护日志，记录失效时间与切换动作。

结果与复盘：该方案使DAL A软件的代码量从约50,000行降至12,000行，验证成本显著降低。但代价是引入了分区调度器的额外验证工作，且需要证明分区间的时空隔离有效性（DO-178C中多核/分区相关要求）。复盘经验：DAL分配应在系统架构阶段尽早进行，避免在软件编码阶段才发现高DAL范围过大。

4.4 常见误区与总结复盘

总结复盘：系统与软件接口的核心在于“需求分配”与“安全性驱动”。需求分配不是简单的文字改写，而是将系统级意图转化为软件可验证的规格；DAL确定则是安全性评估的量化输出，直接决定软件开发的严格程度。在实际项目中，建议在系统需求评审（SRR）阶段就完成初步DAL分配，并在PSSA更新后重新确认。同时，建立需求追溯工具（如DOORS、Reqtify）来维护系统需求与软件需求的映射关系，确保每次需求变更都能评估其对DAL和验证活动的影响。