2. 航电系统需求分析与软硬件分配

航电系统的软硬件协同集成，起点不是代码，也不是电路板，而是需求。需求分析决定了“系统必须做什么”，软硬件分配决定了“由谁来做”。这两步如果含糊，后续的接口定义、模块划分、测试验证都会失去基准。本节围绕功能需求捕获、安全性需求分解、软硬件功能分配原则和需求追溯矩阵建立四个环节展开，重点说明实际工程中如何把一段模糊的飞机级任务描述，逐步转化为可分配、可追溯、可验证的软硬件需求。

功能需求捕获：从任务场景到可验证条目

功能需求捕获不是简单记录“飞行员想做什么”，而是把飞机级任务场景拆解为航电系统必须响应的输入、处理和输出。以“飞行管理系统的航路变更”为例，飞机级需求可能是“机组能够在飞行中修改航路并得到导航引导”。这句话无法直接分配，需要继续分解：输入包括机组在多功能显示器上的航路点选择、当前飞机位置、导航数据库有效性；处理包括航路合法性检查、航段衔接计算、横向引导律更新；输出包括显示航路、向自动驾驶仪输出横滚指令、向导航台调谐。每个条目都要有明确的触发条件、预期响应和可观测结果。

捕获时建议采用“场景—功能—条目”三层结构。场景描述运行背景，功能描述系统能力，条目描述可测试的具体行为。例如“当飞机处于自动驾驶接通状态且新航路点通过合法性检查时，飞行管理计算机应在200 ms内更新横向引导指令，并同步刷新导航显示”。这里的时间指标、状态条件和输出对象都是后续分配和验证的依据。对于航电系统，还要特别标注接口对象：是ARINC 429标签、AFDX虚拟链路，还是离散量。接口信息越早明确，软硬件分配越有依据。

安全性需求分解：从失效概率到软硬件约束

安全性需求分解的核心，是把飞机级安全性目标逐层分配到系统和软硬件。通常先依据适航要求确定失效状态类别，再给出定量概率目标。例如某航电功能被归类为“灾难性”，其失效概率目标为每飞行小时小于10⁻⁹；若归类为“危险性”，则目标为小于10⁻⁷。这些数字不是直接写在软件代码里的，而是通过架构分解转化为冗余、隔离、监控和自检要求。

以一个双通道飞行控制计算机为例，若单通道失效率为10⁻⁵/飞行小时，要满足10⁻⁹量级目标，仅靠单通道无法达成，需要采用双通道比较加监控架构。此时安全性需求分解为：两通道独立采集与计算、交叉通道数据比较、差异超限时切断输出并告警、通道间电源与时钟隔离。再往下，软件安全性需求可能包括“比较周期不超过20 ms”“差异计数器连续3次超限触发通道断开”。硬件安全性需求可能包括“看门狗在软件未按时喂狗时复位处理器”“输出使能电路在监控信号无效时进入高阻”。这些条目必须可追溯到上层失效状态，否则无法证明安全性目标被覆盖。

软硬件功能分配原则

软硬件功能分配没有唯一答案，但有几条工程原则可以指导决策。第一，按实时性和确定性分配：采样、滤波、输出使能、看门狗等对时序要求严格且逻辑简单的功能，优先由硬件或FPGA实现；复杂模式管理、航路计算、人机交互逻辑适合软件实现。第二，按安全性和完整性分配：高完整性监控、独立切断路径、电源隔离通常由硬件承担，避免软件失效同时影响功能和监控。第三，按变更频率分配：频繁调整的算法和显示逻辑放在软件，接口电气特性和安全逻辑固化在硬件。第四，按资源和成本分配：软件复用度高但需要处理器和内存预算，硬件确定性强但增加重量、功耗和布线复杂度。

实际分配时可以用一张“功能—属性—候选实现”表来比较。例如“大气数据高度计算”功能，若要求更新率50 Hz、精度±10 ft、失效概率10⁻⁷，则候选方案有：软件在通用处理器中实现、FPGA实现、专用ASIC实现。软件方案灵活但需要分区隔离和监控；FPGA方案确定性强但开发验证成本高。最终选择往往取决于项目阶段、适航证据和团队能力，而不是单纯技术优劣。

需求追溯矩阵建立

需求追溯矩阵是软硬件协同集成的“账本”。它至少应覆盖四类关系：飞机级需求到系统需求、系统需求到软硬件需求、软硬件需求到设计单元、设计单元到测试用例。矩阵的每一行是一条需求，每一列是追溯目标，单元格填写覆盖状态和证据编号。实际工程中常用需求管理工具维护，但核心字段并不复杂：需求编号、需求描述、来源、分配对象（软件/硬件/接口）、验证方法、验证证据、状态。

建立追溯矩阵时，最容易出问题的是“断链”和“多对多模糊”。断链指某条安全性需求没有对应的软硬件实现或测试用例；多对多模糊指一条需求被多个模块部分实现，却无法判断谁负责最终符合性。解决办法是给每条需求指定唯一责任对象，并在接口需求中明确交互双方。例如“横向引导指令输出”这条需求，责任对象是飞行管理软件，但接口验证需要飞行管理计算机ARINC 429输出和自动驾驶仪接收共同确认，因此矩阵中应同时出现软件需求条目和接口测试用例。

上图把本节四个环节串成一条追溯链：飞机级需求经过功能分解和安全性分解形成系统级需求，再按分配原则落到软件和硬件，最终在追溯矩阵中建立需求、设计单元、测试用例和证据之间的对应关系。实际项目中，这条链不是单向一次完成的，而是随着设计迭代反复核对。每次软硬件分配调整，都要回到矩阵中检查覆盖状态，确认没有需求丢失，也没有出现无人负责的“孤儿需求”。

一个可执行的追溯矩阵示例

下面给出一份可直接参考的追溯矩阵字段示例，适用于航电系统软硬件协同集成阶段。字段粒度可根据项目裁剪，但责任对象、验证方法和证据编号建议保留。

使用这张表时，重点检查三件事：每条安全性需求是否都有对应的软硬件实现和验证证据；接口需求是否同时覆盖发送方和接收方；状态为“待验证”的条目是否已安排测试资源。对于“待验证”条目，不能仅凭设计评审关闭，必须有可观察的测试结果或分析报告作为证据。航电系统的软硬件协同集成，最终要落到这些可检查、可追溯、可关闭的条目上，而不是停留在方案描述层面。