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