本文摘要：航空适航标准DO-178C/DO-254要求机载软件/硬件研发需通过四次关键阶段审查（SOI-1至SOI-4）。与敏捷开发不同，SOI审计强调过程完整性和全生命周期可追溯性，要求每行代码都有需求来源，并通过文档核查确保系统无缺陷。文章详细列出各阶段审查节点、核心目标和必交文档清单，包括规划审计（SOI-1）的开发合规性、开发审计（SOI-2）的代码可追溯性、验证审计（SOI-3）的测试覆盖率（如DALA级需100% MCDC覆盖）和最终审计（SOI-4）的缺陷闭环。特别指出航空审查的严格性，如禁止"先编码后补文档"，强调配置控制和静态测试环境，为eVTOL团队提供全流程合规指南。（149字）
在遵循 DO-178C（机载软件审定标准） 与 DO-254（复杂电子硬件开发指南） 的适航审定生命周期中，局方审查组（CAAC/EASA/FAA）或其委任代表（DER/UM）将对研发团队执行四次关键的阶段性审定审计（SOI, Stages of Involvement）。
对于习惯了敏捷开发、快速迭代和后向修补的智能汽车软件团队而言，SOI 审计是一场毁灭性的"过程完整性"和"可追溯性"大考。局方不仅看最终的固件二进制文件，更通过拉网式的文档核查（Software/Hardware Audit Checklist），确保整个软件工程不存在任何一行缺乏出处的代码，从根本上消灭系统性缺陷。
本附录为 eVTOL 跨界团队提供了一份针对 SOI-1 到 SOI-4 的全流程实战文档核查清单与审计通关指南。
📅 B.1 SOI 审计的四大法定节点与核心目标
[ 软件开发规划期 ] ──────→ 1. SOI-1 (规划审计) ──→ 考核核心计划是否合规、过程是否受控
│
▼ [ 软件架构与编码期 ]
[ 核心代码基线确立 ] ────→ 2. SOI-2 (开发审计) ──→ 抽查代码到需求的全链条双向可追溯性
│
▼ [ 系统级集成验证期 ]
[ HIL / 验证用例 100% 运行 ] → 3. SOI-3 (验证审计) ──→ 见证测试执行，检查 100% MCDC 覆盖率
│
▼ [ TC 结案与发证前夕 ]
[ 关闭全部缺陷单 (PR) ] ──→ 4. SOI-4 (最终审计) ──→ 软件全生命周期封卷，签署放行安全文件📂 B.2 SOI-1（规划审计 - Plan Review）核查清单
-
审计节点： 软件/硬件需求定义前，过程规划文档初稿封卷时。
-
局方核心关注点： 研发团队是否真正理解了 DAL A/B 级的质量管理要求？开发、验证、配置管理和质量保证四个团队是否做到了组织架构上的物理隔离（Independence）？
-
不可跨越的合规红线： 严禁开发人员兼任测试人员；规划文档中必须明确定义所有支持工具的资质（Tool Qualification）方案。
📄 必须提交的符合性工件（Artifacts）核查清单：
| 序号 | 航空法定文档名称 / 标志符 | 汽车/互联网研发对应映射文档 | 局方现场审计重点与必杀问题（Audit Focus） |
|---|---|---|---|
| 1 | PSAC / PHAC (软件/硬件审定计划书) | 研发主项目安全性里程碑计划 | - 是否明确定义了软件的 DAL 等级与审定基础？ - 是否确立了与局方（CPT小组）的数据交互机制？ |
| 2 | SDP / HDP (软件/硬件开发计划书) | 软件架构设计与编码规范指南 | - 编码语言（如 MISRA C）是否进行了极限的安全裁剪？ - 是否禁用了动态内存分配（Malloc）与多线程死锁风险？ |
| 3 | SVP / HVP (软件/硬件验证计划书) | 测试策略与 HIL/SIL 测试方案 | - 是否规划了独立验证（Independent Verification）？ - 如何对结构覆盖率（MCDC）的无法覆盖点进行人工走查规划？ |
| 4 | SCMP / HCMP (软件/硬件配置管理计划) | Git/SVN 提交规范与基线控制策略 | - 变更控制委员会（CCB）的运作流程是否具有一票否决权？ - 软硬件配置项（SCI/HCI）的命名规则是否具备全生命周期唯一性？ |
| 5 | SQAP / HQAP (软件/硬件质量保证计划) | QA 审计流程与质量红线规程 | - QA 团队是否独立于项目经理？ - QA 是否具备向局方直接上报过程不合规（Conformity Issue）的特权通道？ |
🔍 B.3 SOI-2（开发审计 - Development Review）核查清单
-
审计节点： 软件架构设计完成、50% 以上的核心代码（Control Law）或 FPGA 逻辑编码封卷、且软件需求已完全基线化时。
-
局方核心关注点： 需求是否产生了"无边界蔓延"？代码中是否存在大量程序员自嗨编写的"死代码（Dead Code）"或未被需求定义的"无主代码（Deactivated Code）"？
-
不可跨越的合规红线： 任何一行代码，必须能够向顶层系统需求进行 100% 溯源。
📄 必须提交的符合性工件（Artifacts）核查清单：
| 序号 | 航空法定文档名称 / 标志符 | 汽车/互联网研发对应映射文档 | 局方现场审计重点与必杀问题（Audit Focus） |
|---|---|---|---|
| 1 | SRD / HRD (软件/硬件需求数据文档) | SRS (软件需求规格说明书) | - 需求描述是否采用了无歧义的原子化表达（Shall 句式）？ - 是否包含了由于架构冗余衍生出的衍生需求（Derived Requirements）？ |
| 2 | SDD / HDD (软件/硬件设计说明书) | 架构详设与接口控制控制文档 (ICD) | - 模块间是否存在隐蔽的全局变量耦合与数据流/控制流冲突？ - 多核处理器的干扰抑制机制（第 12.1 章所述）是否在架构中落地？ |
| 3 | Source Code / HDL (源代码与硬件描述语言网表) | 核心算法代码库 (C/C++/VHDL) | - 是否通过了 MISRA 静态扫描？零警告的豁免单（Deviation）是否有完整的技术因果论证？ - 汇编层面的编译优化选项是否与 SOI-1 规划完全一致？ |
| 4 | Traceability Matrices (Part 1) (双向可追溯性矩阵 - 需求到代码) | 需求跟踪矩阵表格 | - 拉网式抽查：局方审查员会随机盲选一行 C 代码，研发团队必须在 3 分钟内当场展示该行代码对应的底层需求、高层需求以及 FHA 危害源（第 3.1 章）。 |
🧪 B.4 SOI-3（验证审计 - Verification Review）核查清单
-
审计节点： SIL/HIL/铁鸟台测试用例 100% 运行结束，所有的动态结构覆盖率数据收集封卷。
-
局方核心关注点： 测试用例是否仅仅是"正向逻辑测试"？是否设计了足够残酷的边界值、容错、物理故障注入（Fault Injection）和鲁棒性测试？测试结果的真实性如何保证？
-
不可跨越的合规红线： DAL A 级必须实现 100% 的 MCDC 覆盖率（且必须在机器码二进制目标文件级别执行验证，不能只看 C 语言层面）。
📄 必须提交的符合性工件（Artifacts）核查清单：
| 序号 | 航空法定文档名称 / 标志符 | 汽车/互联网研发对应映射文档 | 局方现场审计重点与必杀问题（Audit Focus） |
|---|---|---|---|
| 1 | SVCP / HVCP (软件/硬件验证情况与用例) | 测试用例脚本与自动化测试集 | - 测试用例是否完全覆盖了正常状态与异常跌落边界？ - 针对硬时钟分时复用（第 14.1 章所述）的抖动边界是否设计了应力测试？ |
| 2 | SVR / HVR (软件/硬件验证结果报告) | 测试报告与 HIL Log 日志打包 | - 所有测试用例是否 100% 执行通过（Pass）？ - 失败用例的整改是否引发了配置控制基线的滚动更新？ |
| 3 | Structural Coverage Analysis (结构覆盖率分析报告) | 代码覆盖率统计表 | - DAL A 级 MCDC 覆盖率、DAL B 级条件/判定覆盖率是否达到 100%？ - 对于编译器引入的编译器特定代码、死代码，是否有可信的底层汇编走查记录？ |
| 4 | Traceability Matrices (Part 2) (双向可追溯性矩阵 - 需求到用例) | 测试覆盖率矩阵 | - 证明每一个软件高层需求/底层需求，都有至少一个正向测试用例和两个边界鲁棒性测试用例与之咬合。 |
🔒 B.5 SOI-4（最终审计 - Final Review）核查清单
-
审计节点： 试飞完成，产品准备交付商业运营（AOC审定）前夕，型号合格证（TC）签发的最后一步。
-
局方核心关注点： 全生命周期里发生的所有缺陷问题单（PR, Problem Reports）是否全部关闭？未关闭的次要缺陷是否有无法触发的逻辑闭锁论证？最终烧录进飞控/航电的二进制固件是否与铁鸟台测试的完全一致？
-
不可跨越的合规红线： 遗留任何未关闭的红色（Warning级）缺陷单，直接拒绝签署放行文件。
📄 必须提交的符合性工件（Artifacts）核查清单：
| 序号 | 航空法定文档名称 / 标志符 | 汽车/互联网研发对应映射文档 | 局方现场审计重点与必杀问题（Audit Focus） |
|---|---|---|---|
| 1 | SAS / HAS (软件/硬件完工总结报告) | 结项总报告与发布说明 (Release Notes) | - 这是通过审定的法定总结宣言。必须清晰向局方陈述：整个生命周期的实际执行与 SOI-1 的规划有哪些偏离？这些偏离如何通过了局方的批准？ |
| 2 | CI / CC Log (配置项清单与配置控制日志) | 最终发布版 BOM 与 Git Commit 总控制流 | - 提供最终取证版 eVTOL 整机完整的软硬件数字身份证，包括所有控制器的二进制文件的 SHA-256 确定性防篡改哈希特征码。 |
| 3 | Open Problem Reports Summary (未决问题单/缺陷最终汇总分析) | Jira 遗留 Bug 严重性评估报告 | - 统计全生命周期上万个缺陷单的闭环轨迹。 - 对极少数遗留的青色/白色（Advisory 级）次要瑕疵，必须通过数学逻辑或物理运行概念（ConOps）绝对证明其在全飞行包线内无法被触发，不对乘员生存产生任何衍生风险。 |
💡 跨界研发总监的 SOI 通关生存指南：
-
切忌"先上车，后补票"： 汽车项目为了赶 SOP 节点，经常采用先写代码、后补文档的权宜之计。在航空 SOI 审计中，SOI-1 没通过之前，后续产生的任何代码在法律层面上都是"零学分"。如果被局方发现文档的修改日期晚于代码创建日期，整个审计会被直接强行中止。
-
拥抱"符合性见证"： 在进行 SOI-3 见证时，测试台架（HIL 或铁鸟台）必须保持完全静态的清洁。测试开始前，必须当着审查员的面执行配置审计（Conformity Check），用万用表和特征码实证台架上的硬件、接头与设计图纸一模一样。
-
克制"敏捷重构执念"： 在 SOI-2 之后，每一次对核心控制律代码的微调，都必须伴随着全套需求文档的更新、双向追溯性矩阵的重新解算以及 HIL 用例的全盘回归测试。用严密的"配置控制链条"去战胜消费电子的随意性，才是确保 eVTOL 项目最终合规通关、跨越天际的最高工程保障。