1. 航空软件SIL仿真与回归测试全景
在航空机载软件研制中，仿真测试并不是一个孤立的验证动作，而是贯穿需求、设计、实现与适航符合性证据链的关键手段。要理解SIL（Software-in-the-Loop，软件在环）仿真与回归测试的价值，必须先把它放回航空软件V模型的大框架中，看清它与MIL、PIL、HIL的边界，以及回归测试在DO-178C适航要求下的定位。
一、SIL在航空软件V模型中的位置
航空软件通常遵循V模型开发流程：左侧自上而下是需求捕获、高层需求、低层需求、软件架构与详细设计，右侧自下而上是单元验证、集成验证、软件验证与系统验证。SIL处于V模型右侧偏下的位置——它验证的是“编译后的目标软件代码”，但运行环境并非真实机载硬件，而是在宿主机或仿真平台上运行被测软件，用仿真模型替代被控对象、传感器、执行机构与部分总线。
这意味着SIL的核心特征是：软件是真的，硬件是仿的。被测对象是经过编译、链接、可能已做部分目标化配置的机载软件；而飞机动力学、大气环境、传感器信号、作动器响应、ARINC 429/AFDX/CAN等总线数据，则由仿真模型或激励脚本产生。SIL因此能较早地在真实代码层面暴露逻辑错误、接口不匹配、时序问题和数值异常，而不必等到硬件到位。
在V模型中，SIL通常承接低层需求与详细设计验证，向下衔接单元与集成测试，向上为PIL和HIL提供可复用的测试用例与激励数据。它不是替代HIL，而是把“代码级问题”尽量左移，降低后期硬件测试的成本与风险。
二、MIL、SIL、PIL、HIL的边界
四类在环仿真常被混为一谈，但它们的被测对象和运行环境差异明显：
- MIL（Model-in-the-Loop）：被测对象是控制律或系统模型本身，运行在建模工具（如Simulink）中，验证算法逻辑与需求一致性，不涉及目标代码。
- SIL：被测对象是自动生成的或手工编写的目标软件代码，运行在宿主机/仿真机上，被控对象与环境用模型替代，验证代码行为与模型/需求是否一致。
- PIL（Processor-in-the-Loop）：被测代码运行在真实目标处理器或评估板上，但被控对象仍为仿真模型，重点验证处理器相关的数值精度、编译器行为、时序与资源占用。
- HIL（Hardware-in-the-Loop）：真实机载硬件（含目标处理器、I/O、总线接口）接入实时仿真系统，被控对象与环境由实时仿真机模拟，验证硬件与软件的集成行为、实时性与故障响应。
边界可以概括为：MIL验证“算法对不对”，SIL验证“代码对不对”，PIL验证“在目标处理器上跑得对不对”，HIL验证“装到真实硬件上整体对不对”。SIL是唯一能在没有目标硬件的情况下，对真实代码进行大规模、可重复、可自动化回归的环节，因此它在适航证据链中承担着“代码级持续验证”的角色。
三、回归测试在DO-178C中的适航要求
DO-178C将软件生命周期过程分为计划、开发、验证、配置管理、质量保证与适航联络等过程，并按软件等级（A~E）规定目标与活动。回归测试并非DO-178C中一个独立命名的“过程”，而是验证过程与配置管理过程共同要求下的必然活动：当软件发生更改后，必须确认更改没有引入非预期影响，且原有已验证功能仍然满足需求。
具体而言，DO-178C要求：
- 软件更改后应进行影响分析，确定受影响的需求、设计、代码与测试用例；
- 对受影响部分重新验证，并对未更改但可能受耦合影响的部分进行回归验证；
- 回归测试的覆盖范围应有依据，通常基于需求追溯矩阵、代码变更集、接口依赖与结构覆盖率结果；
- 测试结果、变更记录、影响分析结论应纳入配置管理与适航证据，保证可追溯、可复现。
在SIL环境中，回归测试可以高度自动化：用脚本批量执行测试用例，自动比对输出与期望值，自动生成覆盖率与通过率报告。但适航关注的不是“自动化”本身，而是测试是否充分、结果是否可信、证据是否可追溯。因此SIL回归必须保留用例版本、激励数据、期望结果、实际结果、执行环境与判定准则，形成可审计的测试记录。
四、课程实战项目说明
本课程将围绕一个典型的航空软件SIL仿真与回归测试项目展开：以某型飞行控制计算机中的“俯仰角速率指令计算与限幅模块”为被测对象，输入包括迎角、俯仰角速率、空速与驾驶杆指令，输出为俯仰舵面指令。项目在SIL环境中用仿真模型模拟飞机短周期运动与传感器噪声，用脚本注入正常、边界与故障工况，执行功能测试与回归测试。
实战中会涉及：搭建SIL测试工程、配置被测软件与仿真模型接口、编写测试用例与期望结果、执行自动化回归、分析覆盖率与失败用例、定位代码缺陷并复测。示例参数如采样周期10 ms、俯仰角速率限幅±30 °/s、迎角保护阈值15°等，均为教学假设值，用于说明配置与判定方法，不代表真实机型数据。