4. 航电系统功能分析与需求分配

在航电系统研制中，需求分解不是把一份需求文档拆成若干条文字，而是沿着“功能”这条主线，把飞机级任务目标逐层落到可设计、可验证的系统与设备需求上。功能分析回答“系统要做什么”，需求分配回答“由谁做、做到什么程度、如何证明”。本节围绕功能建模、功能分解、功能到需求的映射以及功能分配矩阵四个环节展开，并给出可直接参考的建模与分配示例。

一、功能建模：把任务目标转成可分析的功能结构

功能建模的输入通常来自飞机级任务需求、运行场景和适航约束。以“飞行管理”为例，飞机级目标可表述为：在给定航路与气象条件下，引导飞机按计划航路飞行并满足垂直与水平导航精度。建模时先识别外部交互对象——飞行员、大气数据、导航传感器、作动系统、显示系统，再定义功能边界与激励/响应。

工程上常用功能流模型（Function Flow Diagram）表达功能之间的输入输出关系。一个可用的建模粒度是“功能—子功能—功能项”三级：功能描述任务级能力，子功能描述可独立分配的中间能力，功能项描述可对应到设备或软件配置项的最小单元。建模时每条功能应具备唯一标识、输入、输出、触发条件、性能约束和失效响应，避免出现只有名称没有接口的“空功能”。

二、功能分解：从任务级到可分配单元

功能分解采用自上而下的方式，把顶层功能逐层展开。以“按计划航路导航”为例，可分解为：航路数据管理、当前位置计算、偏差计算、横向引导指令生成、垂直引导指令生成、引导指令输出。继续向下，“当前位置计算”可分解为多源位置融合、完好性监测、位置输出；“横向引导指令生成”可分解为航迹捕获、航迹保持、转弯协调。

分解过程中要控制两个风险：一是分解过粗，导致功能无法对应到具体设备；二是分解过细，导致功能项数量膨胀、接口管理成本上升。经验做法是：当某个功能项能够对应到一个LRU、一个软件配置项或一个明确的验证方法时，即可停止继续分解。分解结果应形成功能分解树，并标注每个节点的功能编号、父节点、输入输出和性能约束。

三、功能到需求的映射：把“做什么”变成“做到什么程度”

功能本身不是需求，需求是功能加上约束、条件和验证要求后的可验证陈述。映射时，对每个功能项至少生成三类需求：功能需求（该功能必须执行的行为）、性能需求（精度、时延、更新率、覆盖范围等）、接口需求（数据格式、总线协议、电气特性、时序）。必要时补充安全性需求（失效概率、隔离要求）和适航需求（条款引用）。

例如，功能项“多源位置融合”可映射为：功能需求——融合GNSS、IRS、DME等多源位置信息并输出最优位置估计；性能需求——水平位置误差≤0.3 NM（95%），更新率≥10 Hz，完好性告警时间≤2 s；接口需求——通过ARINC 429输出，标签203，刷新周期100 ms；安全性需求——单源失效不得导致输出位置跳变超过0.1 NM。每条需求应分配唯一需求编号，并建立与功能编号的双向追溯。

四、功能分配矩阵：明确“谁做、做到什么程度”

功能分配矩阵（Function Allocation Matrix, FAM）是功能分析与需求分配之间的桥梁。矩阵的行是功能项，列是候选执行主体（系统、LRU、软件配置项或人），单元格填写分配结果、分配类型和约束。分配类型通常包括：硬件实现、软件实现、人机协同、冗余备份、不分配。矩阵还应记录分配依据，例如“依据DO-178C DAL B”“依据ARINC 661显示交互”。

下面给出一个简化的功能分配矩阵示例，用于说明字段与填写方式。示例中的设备名称、精度和总线参数均为教学假设，不代表任何真实机型数据。

填写矩阵时，同一功能项可以分配到多个主体，但必须明确主备关系、切换条件和仲裁逻辑。例如F-NAV-01由FMS软件主用，IRS作为备份，当FMS失效或位置完好性不满足时，由IRS提供降级位置。矩阵中的“分配依据”列用于追溯安全性等级、适航条款和设计规范，避免分配结果无法解释。

从矩阵回到需求，还需要做一次一致性检查：每个功能项是否至少有一条需求覆盖；每条需求是否都能追溯到某个功能项或安全性目标；每个执行主体是否具备承担该功能的资源、接口和适航证据。若发现某功能项没有执行主体，说明分解不完整或分配遗漏；若某执行主体承担了过多高DAL功能，则需要评估资源冲突与冗余架构是否满足要求。

实际项目中，功能分析与需求分配通常与接口管理并行推进。功能项之间的输入输出关系会直接转化为接口需求，而接口需求又反过来约束功能分配。例如，若F-NAV-01与F-NAV-03之间通过ARINC 429传输位置与引导指令，则接口需求中必须明确标签、刷新率、数据位定义和失效状态编码。只有把功能、需求、分配和接口放在同一追溯框架下，后续的验证与确认才能做到“每条需求有出处、每个功能有归属、每个接口有定义”。