4. 软件架构验证实战

在DO-178C的验证体系中，软件架构不是一张“画完就归档”的框图，而是连接高层需求与低层需求的枢纽。架构验证要回答三个问题：架构是否完整实现了高层需求？低层需求是否与架构分配一致？组件之间的耦合是否被控制在可接受范围内？本节围绕这三个问题展开，并给出可落地的检查方法与评审案例。

一、DO-178C对架构的验证目标

DO-178C在Table A-2至A-4中分别对高层需求、低层需求和软件架构提出了目标。与架构直接相关的核心目标包括：

• 软件架构与高层需求一致，且可追溯到高层需求；
• 低层需求与架构一致，且可追溯到架构；
• 架构中不存在不安全的耦合、未定义的数据流或未初始化的接口；
• 架构支持鲁棒性验证，例如分区隔离、故障检测与恢复路径。

这些目标不是靠一次评审就能关闭的，而是通过“追溯矩阵 + 一致性检查 + 耦合度量 + 评审记录”四条证据链共同支撑。对于A级软件，架构验证还必须覆盖分区隔离、时间确定性等额外目标。

二、低层需求与架构一致性检查

一致性检查的本质是双向追溯：从架构组件向下看，每个组件是否都有对应的低层需求；从低层需求向上看，每条需求是否都能分配到某个架构组件。实践中常用“架构-需求分配矩阵”来承载这一检查。

假设某飞控软件采用三层架构：应用层（AP）、平台服务层（PS）、基础软件层（BS）。应用层包含导航解算（NAV）和舵面控制（ACT）两个组件；平台服务层包含健康监控（HM）和总线管理（BM）；基础软件层包含调度器（SCH）和IO驱动（IO）。低层需求LLR-001至LLR-008分别描述各组件的行为。分配矩阵示例如下：

检查时若发现某条低层需求没有对应组件，或某组件没有任何低层需求覆盖，即为“悬空需求”或“悬空组件”，必须回到需求或架构阶段修正。此外，接口方向、数据宽度、单位、刷新周期也需逐项核对，避免“需求说毫秒、架构传微秒”这类隐性不一致。

三、耦合与内聚分析

耦合描述组件之间依赖的强弱，内聚描述组件内部元素围绕单一职责的紧密程度。DO-178C并不直接规定耦合度阈值，但要求架构“避免不安全耦合”，因此工程上需要可度量的检查手段。

常用的耦合类型从弱到强依次为：数据耦合（仅传递简单数据）、标记耦合（传递数据结构）、控制耦合（传递控制标志）、公共耦合（共享全局数据）、内容耦合（直接访问对方内部）。安全关键软件应尽量停留在数据耦合和标记耦合，避免公共耦合与内容耦合。

内聚类型从强到弱依次为：功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。架构评审中，若一个组件同时承担导航解算、健康监控和总线调度，则属于逻辑内聚甚至偶然内聚，应拆分。

可操作的度量方法包括：统计每个组件的扇入（被依赖数）和扇出（依赖数）；统计跨层调用数量；统计共享全局变量的数量。例如，若HM组件扇出为7、扇入为1，且直接读写NAV的内部状态变量，则存在内容耦合风险，应改为通过定义良好的接口传递状态字。

四、架构评审案例

某无人机飞控软件在架构评审中发现以下问题：

1. 问题1：ACT组件直接读取NAV的全局变量nav_state，未通过接口。判定为内容耦合，违反架构隔离目标。整改：定义NAV_GetState()接口，ACT仅通过该接口获取状态。
2. 问题2：LLR-009“地面站指令解析”未分配到任何架构组件。判定为悬空需求。整改：新增COM组件或在BM中增加解析子功能，并更新分配矩阵。
3. 问题3：HM组件同时负责超时监控、故障注入和日志记录，内聚度低。整改：拆分为HM（监控）和LOG（记录）两个组件，故障注入归入测试支持组件。
4. 问题4：BM与SCH之间存在双向控制耦合，调度表切换由双方互相触发。整改：明确单一控制方向，SCH为调度主控，BM仅上报请求。

评审输出应包含：问题描述、违反的DO-178C目标条款、影响分析、整改措施、责任人、关闭证据。整改后需重新运行一致性检查，确认分配矩阵无悬空项、接口方向唯一、耦合类型降级。

五、可复用的架构验证检查清单

将上述检查项嵌入架构评审检查单，并在每次基线变更后执行，可以持续保证架构与需求的一致性，为后续的低层需求验证和代码验证提供可信的追溯基础。