2. 无人机系统与安全关键软件基础

无人机并非单一飞行器，而是一个由机载系统、地面系统与链路系统共同构成的复杂系统。要理解无人机安全关键软件测试，必须先建立“系统—软件—安全等级—适航标准”这条主线：系统组成决定软件边界，飞控架构决定软件分层，安全关键等级决定测试强度，DO-178C/ED-12C 则给出可审查的符合性证据框架。

一、无人机系统组成：从物理平台到软件边界

典型无人机系统（UAS）可划分为机载平台、地面控制站、数据链和保障系统四大部分。机载平台包括机体结构、动力系统、飞控计算机、传感器组、执行机构、电源与任务载荷；地面控制站负责任务规划、遥控遥测、状态监控与数据记录；数据链承担上行遥控、下行遥测与载荷数据；保障系统则覆盖运输、发射回收、维护与训练。

从软件测试视角看，真正需要关注的是“软件能影响飞行安全”的边界。飞控软件直接控制舵面、电机与发动机，属于最高风险域；任务管理软件影响航路与载荷，属于中高风险域；地面站软件若具备上传航点或切换控制权的能力，同样可能间接导致飞行事故。因此，系统组成图不仅是硬件拓扑，更是软件安全边界的划分依据。

二、飞控软件架构：分层与余度

飞控软件通常采用分层架构：最底层是硬件抽象层与板级支持包，负责驱动传感器、执行机构与总线；中间层是飞行控制律与状态估计，包括姿态解算、导航滤波、控制律计算；上层是任务管理与模式逻辑，负责飞行模式切换、航点跟踪、返航与失效保护。层与层之间通过明确定义的接口交互，接口的稳定性直接决定测试用例的可复用性。

安全关键飞控还普遍采用余度设计。常见形式包括双余度或三余度飞控计算机、交叉通道数据监控、表决算法与故障隔离。测试时必须覆盖“单通道故障—表决—降级—安全返航”的完整链路，而不仅是验证正常通道的功能正确性。余度管理软件本身也是安全关键软件，其错误可能导致错误表决或故障扩散。

飞控软件典型分层：
应用层    任务管理 / 模式逻辑 / 失效保护
控制层    姿态控制律 / 导航滤波 / 制导律
抽象层    传感器驱动 / 执行机构驱动 / 总线通信
硬件层    FCC 主板 / IMU / GPS / 舵机接口

三、安全关键等级划分：DAL 与失效后果

安全关键等级用于回答一个核心问题：如果该软件失效，最坏后果是什么？在航空领域通常采用 DAL（Development Assurance Level）划分，从 A 到 E 共五级。A 级对应灾难性后果，B 级对应危险后果，C 级对应较大后果，D 级对应轻微后果，E 级对应无安全影响。等级越高，对需求追溯、结构覆盖、独立验证与配置管理的要求越严格。

四、DO-178C 与 ED-12C：适航符合性框架

DO-178C 是机载软件适航符合性的核心标准，ED-12C 是其欧洲对应版本，两者技术内容一致。标准并不规定“必须用什么工具”，而是要求建立从系统需求到软件需求、设计、代码、测试用例与结果之间的双向追溯关系，并针对不同 DAL 等级规定目标与活动。

其核心过程可概括为：软件计划、软件开发、软件验证、配置管理与质量保证、适航审定联络。测试在其中承担“验证目标是否满足”的证据生成角色。对于 A 级软件，还需满足独立验证、结构覆盖分析、最坏执行时间分析等附加目标。DO-178C 还配套了 DO-330 工具鉴定、DO-331 模型化开发、DO-332 面向对象技术、DO-333 形式化方法等补充文件。

五、案例与复盘：从系统边界到测试策略

某中型固定翼无人机在返航阶段出现高度异常。复盘发现：飞控软件本身通过了功能测试，但地面站上传的航点高度字段在数据链协议中被错误解析，导致飞控收到错误目标高度。问题根源不在飞控控制律，而在“地面站—数据链—飞控”跨系统接口。若前期按系统组成划分软件安全边界，并将接口协议纳入 A/B 级验证范围，该问题可在集成测试阶段暴露。

该案例说明：无人机安全关键软件测试不能只盯着单个软件模块，而应沿着“系统组成—飞控架构—安全等级—适航目标”逐层展开。先明确哪些软件可能影响飞行安全，再确定其 DAL 等级，最后依据 DO-178C/ED-12C 选择相应的验证方法与证据强度。只有这样，测试活动才既有技术深度，又具备适航可接受性。