做高可信嵌入式系统，项目一开始就要把开发与验证放进设计保证体系。以民用机载软件为例，DO-178C 对计划、开发、验证、构型管理、质量保证和审定联络都有相应的过程与目标。软件等级决定了哪些目标适用、验证要做到什么程度、哪些工作需要独立完成。系统层面还要做好需求分配、安全性评估和软硬件协调。

AI 进入这样的工程，也要沿着这套体系工作。它生成的代码，要回到需求和设计中检查；它提出的测试，要说明验证什么、怎样判断正确；运行中发现的差异，要有分析、有处理，也有重新验证的记录。

此前写《从标准、流程到需求与设计，适航智能体如何做工程》时，我们已经展示了适航智能体如何借助标准、知识库和工程工作流，协助完成需求分解与设计。需求、设计、源码和测试用例有了组织方式，后面的工作还要继续。源码在哪里构建和运行？测试用例怎样施加到实际程序上？得到结果以后，又怎样回到原来的工程资料？

这次要接上的，就是嵌入式开发环境和全数字仿真验证平台。我们把它们与适航智能体组织在同一个“嵌入式软件智能研制与验证平台”中，让生成的源码进入开发环境，让测试用例进入数字仿真环境，再把运行结果和分析证据带回来。下面用一个小项目，看看这几处工作怎样接在一起。

几个软件怎样共同完成一项工程

总控平台负责组织完整项目，关联各阶段的资料、版本、交接记录和验证证据。适航智能体、嵌入式开发环境、全数字仿真验证平台分别承担专业工作，也保留各自独立使用的能力。

图 1 总控客户端的软件启动台。三个专业软件各有独立入口；图中的协作服务连接状态与软件本身的运行状态分别显示。

几处工作的交接关系，可以放在同一张图里看。适航智能体交付源码与两类测试用例，两个验证环境分别执行，再把结果带回受控工程。

图 2 总控平台组织完整项目，三个专业软件完成各自的工作。源码与低层用例进入开发环境，高层用例转换后进入仿真平台；程序与模型双向通信，验证结果沿追溯关系回到需求、设计与下一轮研制。

对这个“嵌入式软件智能研制与验证平台”感兴趣的话，欢迎添加微信畅聊。

项目目录也按这个关系组织。大项目之下，三个专业软件各有独立的项目目录；总控层另外维护交接、完整资料视图和证据目录。某条需求发生变化时，先修改它的来源资料，再沿追溯关系更新相关设计、代码和测试。这样可以避免三个软件各存一份不同版本，却都把自己的内容当成当前依据。

这里有一个贯穿全篇的分工。源码由适航智能体依据设计生成，嵌入式开发环境负责接收、构建和运行。AI 参与整理资料、分析影响和提出修改时，工程中仍保留它依据的具体文件与版本。

选取一个小项目，把流程演示清楚

为了演示这套环境，我们构造了一个小型的机载电子设备热管理项目。可以把它理解为两个需要分别控制温度的设备区域，称为 A 区和 B 区。两个区域各有温度传感器、风扇和加热器，操作人员可以分别设置目标温度。控制器的任务，就是根据测得的温度，决定各区的风扇和加热器应当怎样工作。

在正常自动控制下，区域温度偏低时，控制器提出加热请求；温度偏高时，提出散热请求。一个区域的目标温度发生变化，不应改写另一个区域的目标。软件每个控制周期都重新读取温度、检查输入状态，再按控制规律和保护条件更新输出。

温度控制之外，项目还设置了几类异常场景。一个测点失效后，软件需要判断剩余测量是否还能用于控制；温度过高时，需要执行规定的保护；发出了风扇命令却收不到有效反馈时，需要识别异常并按要求限制输出。供电变化、故障恢复和复位请求也都有明确的处理规则。读者可以沿着这些具体场景，看需求怎样变成设计、代码和测试。

演示中，温度传感器和执行器由全数字仿真环境提供。热过程模型根据加热、散热、环境温度和热负荷计算温度变化，把新的温度送回实际运行的控制程序。程序再计算下一轮输出，模型继续响应。由此可以观察正常调节，也可以注入故障，检查程序的保护和恢复行为。

这个项目的功能范围便于说明和复现，又包含了多种接口、状态转换及故障保护，适合用来演示研制流程。

系统需求继续定义这些接口的方向、字段、量纲、更新周期和异常处理规则。后续的软件实现、节点配置和测试判据，都从同一份接口约定出发。本轮 Windows 演示通过网络传输完成接口适配，同时保留上述业务协议语义；真实总线和目标硬件相关验证另有相应的环境与证据要求。

适航智能体先把需求、设计与测试依据组织起来

适航智能体接收系统任务与约束，协助形成系统需求，再将分配给软件的职责细化为软件高层需求，通常简称 HLR。软件设计进一步形成低层需求，通常简称 LLR，并说明架构、数据、算法、接口及异常处理。工程人员在这一过程中审查正确性、一致性、可验证性和追溯关系。

当前示例工程保存的资料规模如下。

图 3 当前系统需求的真实条目视图，共61条。右侧展示双温区独立控制要求，以及与软件需求的追溯关系。

系统需求先回答设备应当完成什么。以双温区独立控制为例，两个温区分别接受目标温度，单区设定变化不能改写另一区的目标，同时还要服从共享保护规则。这些规定随后进入软件需求，成为实现与测试的共同依据。

图 4 当前软件高层需求的真实条目视图，共196条。需求正文、工程状态和上下游关系可以在同一页面查阅。

系统把职责分给软件以后，高层需求说明软件应当怎样响应，低层需求和设计继续细化算法、数据和接口。AI 在这里能做的事情很具体。哪条异常处理没有写，哪个边界有两种解释，两个条目是否互相冲突，都可以连同原文一起找出来，再提交工程审查。

图 5 当前软件低层需求和设计说明的真实条目视图，共644条。界面展示接口解码规则、源码与测试关系；草稿和待确认状态如实保留。

测试用例沿着两类需求分别形成。基于高层需求的用例检查软件对外行为，基于低层需求的用例检查设计细节的实现，两者各有输入、前置条件、操作步骤和预期结果，也都包含正常范围与健壮性场景。项目分别维护《高层需求测试用例》和《低层需求测试用例》两个文件，保留各自的直接需求依据。

AI 可以帮助展开边界条件、补充固定输入和判断方法，预期结果仍要来自需求、设计和接口约定。源码由适航智能体依据设计说明生成，交给开发环境构建。源码、用例和后续驱动的来源与版本随工程保存。

图 6 基于高层需求的597条测试用例，单独保存在高层需求测试文件中，页面显示直接的软件需求依据及候选关系状态。

图 7 基于低层需求的775条验证用例，单独保存在低层需求测试文件中。资料中的关系审查状态与执行报告中的需求绑定分别记录。

追溯关系的用处，要到修改时才看得更清楚。某个保护条件改变了，可以从系统要求找到受影响的软件需求、设计、源码与测试；某条测试失败了，也可以反向找到它的判断依据。AI 做影响分析时，就有具体关系可查。确属派生的需求则需要识别并反馈给上游过程，不能随意补一条连线了事。

最新资料已通过交付版适航智能体的真实项目打开入口核对，完整读取2,302条工程对象与6,649条追溯关系，扫描错误、悬空及版本不一致等追溯检查发现均为0。这个结果说明资料可以完整读取和关联，设计与候选关系的专业审查仍按工程过程开展。

嵌入式开发环境把源码变成可运行的软件

适航智能体交付的源码进入嵌入式开发环境后，先核对版本和交接清单，再配置构建、运行及通信接口，完成编译与链接。生成的程序在开发环境中启动，持续接收仿真输入，执行控制逻辑，并输出执行器命令和运行状态。

图 8 当前开发工程中的温度控制源码。开发环境接收适航智能体交付的代码，提供构建、调试及验证与分析入口；逐条执行结论在对应的验证报告中查看。

到这一步，设计说明里的控制逻辑开始实际运行。源码版本、构建方式和运行配置随工程保存，后面发现问题时，才能把相同的程序和输入重新拿出来复现。

程序运行起来，还需要接到它要面对的外部环境。先看仿真平台怎样把传感器和执行器接进来，随后再回到开发环境中的低层测试和分析。

全数字仿真平台建立软件的外部运行环境

双温区热过程以可执行仿真模型的形式接入平台，工程中采用 FMU 模型文件。测温、执行器、操作端、维护端及输入输出通道分别配置成相应的节点和通信关系。

图 9 当前仿真工程的节点管理界面，展示热过程模型、通信适配节点和路由交联。本图为待初始化配置状态，用于说明环境组织。

节点配置接着落实到协议和信号。温度从模型进入控制软件，风扇与加热器命令从软件返回模型，执行器反馈再送回控制器。操作命令、运行状态和维护消息沿各自通道传输，形成系统需求中规定的交联。

图 10 同一仿真工程的节点协议界面，节点集合与管理页面一致。模型输入、输出及数据类型在这里配置。

联调要把一轮控制过程看完整。模型发来的温度有没有被接收，软件给出了什么命令，模型是否随输出变化，下一轮温度又是多少，都有记录可以检查。确认这条路径能够运行以后，自动测试才有了施加输入、注入异常和观察结果的地方。

高层需求测试用例怎样进入全数字仿真平台

适航智能体里基于高层需求形成的测试用例，已经说明了要验证什么。到了仿真平台，还得把这件事变成具体操作。用哪个节点提供温度，怎样建立初始状态，何时发送命令，从哪里读取输出，这些都需要落实。

AI 按照源测试用例和接口配置，辅助形成这些平台执行步骤。转换后的交付物就是能够直接导入全数字仿真平台并执行的原生自动测试用例。每条用例保留源规格和需求关系，转换前后的验证意图需要核对一致。

例如，测试过温保护时，要先建立规定的正常运行条件，再通过仿真输入使温度达到要求的异常状态，检查保护动作和输出；恢复阶段继续验证规定的恢复条件。用例要负责场景准备、激励、观察、判定与清理，使下一条用例能够从明确状态开始。

图 11 当前工程内原生自动测试的实际界面，显示用例、平台执行步骤及保存的状态。用例与执行记录关联各自的源码、模型和配置版本。

执行结束后，平台把预期、实际结果，以及程序、模型和配置版本一起保存。如果某个场景没能建立起来，就保留未完成状态，继续补执行条件。这样，后面分析失败时，才能分清究竟是软件行为不对，还是测试尚未真正执行到判断那一步。

自动测试结果怎样推动下一轮迭代

第一次整批运行的结果并不整齐。有些用例通过了，有些实际输出与预期不符，还有不少用例缺少完整的执行条件。把它们分开看，下一步该做什么才清楚。

图 12 从当前平台打开保存的历史执行记录。通过与失败均保留，可以进入原运行轮次检查测试步骤和实际观测。

看到失败，先回查依据。AI 可以把相关需求、设计、测试和日志放在一起，帮助工程人员判断差异从哪里来，然后再确定修改位置。

有一次，测试要求温度继续升高时，风扇输出也应增加。回查控制规律才发现，两次输入都已经让风扇达到输出上限。于是修改测试选点与预期，把正常调节区间和输出上限分别验证，控制算法保留原要求。另一次差异则来自实现，状态输出没有完整检查本轮决策的一致性，修改设计细化与源码后，再用原失败输入复测。相同的“失败”，实际需要改动的对象并不相同。

每次处理都要经过几个软件。适航智能体更新相关依据与候选修改，开发环境重新构建程序，仿真平台执行原场景和必要回归，总控工程保留前后记录。某项检查曾出现预期与实际不符，修改后先重新运行原场景，再进入平台回归；两次运行分别保存结果，供工程人员核对。

前期联调保留了一次平台整批运行记录。该批609条自动测试全部通过，0次重试，共执行11,358项判定检查。它反映当时的源规格和执行配置，后续资料已重新整理，当前高层需求测试文件为597条。

资料统一以后，高层用例进入平台原生自动测试，低层用例进入开发环境的低层测试。旧平台批次与当前低层批次各自保存版本和结果，本轮新增的完整执行证据来自775条低层用例。要判断现行高层用例的验证状态，还需要对应现行源码和配置的执行记录，历史平台数字不能直接迁移过来。

按照设计保证目标组织开发环境中的验证

仿真平台跑完一批用例，开发环境里还有工作要做。DO-178C 第 6 章把评审、分析和测试共同纳入软件验证，需求、架构、源码、集成输出，以及测试自身的资料与结果，都有相应的验证活动。

所以，使用开发环境中的这些功能时，要先明确本次检查对应哪个目标、需要什么证据。运行按钮给出的是工具结果，工程结论还要结合需求与设计来判断。

编码规则检查怎样帮助定位问题

开发环境按项目选用的编码规则和分析器配置检查源码，报告可能提示参数误用、数值运算、数据初始化等方面的风险。每条发现都有对应规则、文件和位置，工程人员据此核对实际实现，再决定是否修改。

这时，适航智能体中的资料又派上了用场。AI 可以查找相关低层需求和设计约束，把诊断位置与实现依据放在一起，帮助判断需要调整代码、补充设计，还是给出有依据的处置说明。报告页先显示检查范围与发现数量，再按源文件进入单条规则和命中代码。工具诊断需要核实，告警数量不能直接写成软件缺陷数量。

下面先看编码规则、栈、测时和耦合的专项分析页面，再看低层需求测试与限定范围覆盖的全量执行结果。各类记录保留对应的源码基线与分析范围。

图 13 编码规则检查报告。94个项目C及头文件范围内记录1,412项诊断，其中825项警告、587项提示，状态为需审查。诊断数量不等于确认的缺陷数量。

图 14 同一HTML报告的文件级结果。按严重级别、规则和源码位置定位诊断，继续进入具体问题。

图 15 同一HTML报告的单条诊断，展示规则、位置和命中代码。是否需要修改，须结合编码标准、设计和实际调用核实。

低层需求测试从适航资料进入开发环境

低层测试验证低层需求的实现，包括正常范围和健壮性行为。软件集成测试检查软件需求与组件之间的关系，以及架构内组件交互的实现。它们可以在嵌入式开发环境中借助测试驱动、受控输入和结果检查完成，但仍要能追溯到相应需求。

这次在嵌入式开发环境中增加的“低层需求测试”入口，接收适航智能体生成的低层测试用例。每条用例转换后仍保留低层需求编号，接着绑定实际源码入口、固定输入、前置状态和独立预期。开发环境构建执行驱动，调用实际业务代码，逐步比较预期与实际观测，并保存本轮源码和驱动版本。

这项转换曾经暴露出资料的不足。早期全量导入后，775条用例中只有20条能够完成验证，另外755条停在执行前。逐条回查发现，531条对应的低层设计还缺接口和算法细节，82条测试仍停留在意图描述，124条需要补追溯和驱动，15条缺执行驱动，3条需要改用适合的验证方法。

这些发现把工作带回了适航智能体。先依据上层要求和接口约定，补实低层设计中的状态归属、计算规则、输入边界和异常处理，再细化测试的固定输入与独立判据。原始条目、刺激和预期保留在归档中，每项补充都有记录，随后重新转换并导入开发环境。缺少设计依据时，测试继续显示未完成，不能根据当前代码的输出反推一个“正确答案”。

AI 在这里参与了查找依据、展开设计、补充测试和形成执行绑定。开发环境负责验证这些工作是否真的落到了可执行程序上。准备失败、没有采到规定观测、实际结果不符，都会分别留下结果，整套工程测试的成功退出也不能代替每条需求的检查。

本轮重新执行的结果是775条通过，0条失败，0条阻塞，共完成9,924个断言。

图 16 低层需求验证报告。775条验证项通过，0条失败、0条阻塞，共9,924项断言；不同验证方法在逐条证据中区分。

其中769条通过源码动态或实际进程验证，6条纯静态约束采用真实语法树分析完成检查，后者单独记录，不贡献动态覆盖率。涉及模型和监督的用例还运行了实际热过程模型及独立接收进程。验证方法按要求选择，最终每条都有自己的判据和结果。

打开某条用例，还能继续看到它依据哪条低层需求，施加了什么输入，以及每一步预期与实际值是否相符。

图 17 同一实际HTML报告中展开的低层用例。需求关系、执行步骤、预期值和实际值共同构成可回查的测试记录。

低层需求也可以反向查到本轮执行的用例。某条设计修改以后，开发环境据此找到需要重新执行的测试，适航智能体则沿上游关系继续检查需求影响。最新结果已经接入交付工作台的验证历史，下一次运行会形成新的证据轮次，历史记录继续保留。

图 18 同一实际HTML报告中的反向追溯，从低层需求定位本轮执行的用例。该执行绑定与适航资料中的关系审查状态分别管理。

这轮验证也找到了需要修改实现和环境的地方。独立输出许可撤销后，热过程模型原来让输出逐渐衰减，下一模型步仍有残余值；修订后，正常执行路径立即归零，显式卡滞故障继续保留故障输出。并发读取用例要求得到完整状态，宿主运行程序补充了事务交接与读写保护。另有18条用例曾因Windows长路径导致覆盖产物无法创建，修正执行目录后，全量重跑消除了这些环境阻塞。

这些处理经历了同一条交接过程。回查要求，细化设计或环境约束，更新源码、模型及执行配置，再运行原判据与必要回归。低层用例全部通过，也让接下来的覆盖分析有了一组完整的执行依据。

工程本身还保留了便于开发维护的单元和集成测试。本轮重新构建后，工程测试共38项，全部通过。下面两张HTML截图来自此前35项的维护性测试批次，其中30项带单元标签，5项带集成标签；它们与775条需求用例分别记录，标签不能代替低层需求追溯。

图 19 维护性单元测试HTML报告，30项通过。它按工程标签选择测试，需求验证充分性另行检查；最新38项工程回归另有记录。

图 20 同一历史轮次的集成测试HTML报告，5项通过。项目的集成标签用于执行组织，软件集成测试目标仍需按需求和架构交互核对。

高层需求和低层需求的用例各有生成依据、转换方式和执行证据。实际工程中，验证层次由所验证的需求、架构关系和判据确定，某条测试运行在哪个软件里，并不能单独决定它的验证层次。

资源、时序和耦合分析需要相应的证据

堆栈分析需要结合调用链、任务和中断等使用情况，判断栈资源是否满足要求。最坏执行时间分析需要考虑目标处理器、编译配置、执行路径和运行条件。数据耦合与控制耦合分析则要检查组件之间的数据使用和控制关系，并确认基于需求的测试实际执行了相关耦合。

图 21 堆栈分析报告，最大已知单函数栈帧为14,928 B，完整调用路径上界未知。统计范围为宿主构建，报告列出已知栈帧与待补充的调用路径。

图 22 运行时间分析报告。20次主机进程测量在所配置门限下显示失败，测量包含启动开销；适用范围需要核对，不能据此判定目标处理器的最坏执行时间。

报告中最大的栈帧来自宿主主程序，完整调用链上界还没有确定。测时数据来自20次主机进程测量，包含启动与系统调度。这份历史报告采用了10 ms比较门限，观测最大值约48 ms，因此页面显示失败。该差异需要先回查计时对象与门限是否适用，不能由进程启动耗时推断目标机控制周期不满足要求。后续时序验证需要面向目标处理器、规定的执行范围和运行条件建立相应证据。

耦合分析也有单独的 HTML 结果页。该专项批次提取到26条静态关系候选，动态轨迹尚未采纳，报告将它们全部标为待审查。下一步要将已审设计关系与实际测试中的数据使用、调用记录接起来。

图 23 数据耦合与控制耦合分析报告，展示18条数据关系、8条控制关系候选。尚未接入已审设计与动态轨迹，报告保留26条待审查状态。

上述栈、测时和耦合截图属于此前的专项分析批次，本轮低层测试全量通过并没有改写它们的审查状态。组件验证、编码规则发现项、目标环境资源与时序等仍按各自证据判断。

这些结果继续进入同一个工程处理过程。对已确认的问题，修订相应资料、实现或工具配置，再重新执行受影响的验证并审查结果。正式项目还需要按适用软件等级落实独立性要求，并根据工具用途、输出是否得到其他验证等条件判断工具鉴定需求。AI 辅助生成或解释的结果同样纳入这套安排。

结构覆盖分析怎样反过来检查测试与实现

测试通过以后，我们还会打开覆盖报告，看代码哪些地方被执行了，哪些地方没有。这里先要分清两个问题。需求覆盖分析检查测试是否充分验证了软件需求，结构覆盖分析检查基于需求的测试实际执行了哪些代码结构。DO-178C 第 6.4.4 节分别规定了这两类分析。

一段代码变成已覆盖，并不说明相关要求已经检查充分。测试可能经过了那段逻辑，却没有验证某个关键输出。同样，每条需求都挂了一个测试编号，也不能省略对用例质量和实际执行情况的检查。

当前工程沿两条路径采集覆盖数据。高层需求用例转换成平台原生自动测试，在外部场景中驱动控制程序；低层需求用例转换成开发环境里的执行驱动，精确控制源码接口与内部条件。每条路径保留自己的来源和结果，本轮775条低层验证对应的覆盖数据已经单独收集。

把两边数据放在一起分析之前，还要核对生产源码、编译配置、插桩方式和代码结构身份。能够对应的命中才可以合并，并继续保留各自贡献。本轮没有将旧版平台覆盖拼入新版本低层结果。

测试如何组织，要看它验证的需求和运行条件。低层测试检查低层需求的实现，软件集成测试检查组件交互及其对软件需求的实现，软硬件集成测试检查软件在目标硬件环境中的运行。各类基于需求的测试都可以为结构覆盖分析提供数据，同时保留各自的需求依据、输入条件和判据。

在这个项目中，仿真平台与开发环境分别提供外部场景和源码级驱动，形成相互补充的验证证据。分析时先确认相关需求是否已经得到充分验证，再检查对应代码结构是否被执行。需求尚未验证充分，就补充合适的测试；存在未覆盖结构，就回查需求、设计、测试与实现，并按分析结论处理。

先明确统计范围，再看覆盖数据

开发环境早期生成的 HTML 覆盖报告把测试驱动、宿主适配等一起纳入，合计67个文件。打开报告能看到逐文件的行、分支和条件命中，也说明为什么要先限定分母。本轮只统计用户指定的开发工程 src 目录，当前其中共有29个业务C文件。

图 24 gcovr原始HTML报告的逐文件入口。此历史轮次涵盖67个全工程文件，用于演示逐文件入口，与当前29个C文件的覆盖数字分开。

本轮覆盖报告与775条低层用例的执行记录一起生成。29个业务C文件中，可执行行代理覆盖3,467／3,593，达到96.49%；分支覆盖2,621／2,995，达到87.51%；masking MC/DC义务覆盖2,571／2,954，达到87.03%。函数覆盖194／197，达到98.48%。测试驱动与目录外的适配代码没有计入这些分母。

图 25 当前低层验证报告的覆盖页面。统计范围为src下29个C文件，行代理96.49%、分支87.51%、masking MC/DC义务87.03%；工具计数与适航目标分别核对。

此前曾在25文件的旧源码范围内合并高层执行和源码测试命中，得到99.05%的可执行行代理、97.50%的分支和97.46%的条件义务覆盖。那组历史结果继续保留，源码范围和测试集合已与本轮不同，不能把两组百分比直接当成覆盖率的升降。

报告保留了工具的原始统计名称。可执行行是gcov行代理，与严格语句覆盖需要区分；工具分支也要核对其与软件判定的映射。修正条件／判定覆盖通常简称MC/DC，本轮采用masking统计，工程上还要核对条件独立影响的测试对及适用口径，不能直接把工具计数当成适航目标已经完成的证明。

按 DO-178C 附录 A 的适用目标，C 级软件要求语句覆盖，B 级还要求判定覆盖，A 级进一步要求 MC/DC。具体项目要按所确定的软件等级组织验证。对于 A 级软件，若编译器等生成了不能直接追溯到源码语句的附加代码，还需要补充验证其正确性。

未覆盖代码要回到工程依据逐项解释

覆盖报告中的空白，会引导工程人员和 AI 回看需求、用例和实现。DO-178C 第 6.4.4.3 节给出的处置方向，包括测试不足、需求不足、多余代码以及非激活代码等情况。

“在当前测试中走不到”不足以判定为死代码；“有一个看似合理的不可达解释”也不足以宣布验证结束。需要核对解释依赖的条件是否由设计保证、其他配置是否可能触发，以及最终生成的程序中是否仍存在相关代码。不能直接删除有效测试或调整分母来取得 100%。

图 26 历史gcovr报告的逐行页面，展示已命中、部分命中和未命中结构。当前缺口分析使用对应当前源码基线的覆盖证据。

早期覆盖补充曾沿着接口异常、反馈历史、过温处理、维护通信和复位条件增加有需求依据的测试，在当时未修改25个生产源码文件的情况下，合并命中增加了66行、144个分支和146条条件义务。这一过程说明，覆盖缺口可以引导我们回查需求和测试，再以重新执行的结果判断补充是否有效。

本轮仍有126个可执行行代理、374个分支和383条masking MC/DC义务未命中。例如，温度接收处理文件有116个可执行行代理，其中94个已覆盖；决策核心的82个中，63个已覆盖。下一步分析可以直接从这些位置出发，检查输入是否不足、需求是否遗漏、调用约束是否成立，再确定补测或处置方法。

旧版覆盖台账里的不可达解释，涉及旧版源码与调用条件，需要针对当前实现重新核对才能采用。775条用例通过与结构覆盖达到100%，分别回答不同的问题。

AI 在这一步可以把未覆盖位置、相关需求、调用关系和现有测试放到一起，提出补测或处置建议。适航智能体维护相应设计与测试依据，开发环境执行补充用例并收集覆盖，涉及外部场景时继续交给仿真平台。建议是否成立，再由测试和审查判断，源码改变后重新取得新版本证据。

让下一轮研制从已有工程事实继续向前

当需求发生变化，适航智能体先沿追溯关系识别受影响的软件要求、设计、源码和测试用例，形成候选修改。审查接受后，源码交给嵌入式开发环境重新构建，源测试用例转换成相应的平台自动测试，仿真环境按受影响的接口和场景更新配置。随后重新执行测试、分析差异、补充源码验证与覆盖分析，所有结果回到同一个工程中。

这也是我希望这几个软件配合起来解决的实际问题。每次变化以后，工程人员能够找到原来的依据，知道哪些代码和测试受到影响，接着构建、执行、审查。AI 帮忙完成查找、转换和分析，回归范围则根据变化与验证计划确定，必要时重新执行整批测试。

到这一轮，项目中形成了61条系统需求、196条高层需求、644条统一低层需求，以及分别组织的597条高层测试和775条低层测试。适航智能体中的设计和用例已经能够继续进入源码构建、数字环境与实际执行，低层用例全部完成本轮判据验证，结果又能够沿追溯关系回到资料中。目标环境验证、工程审查和结构覆盖缺口仍按各自目标继续处理。

让这套研制飞轮继续转起来，靠的是每一轮都有可用的输入，也留下可检查的结果。AI参与需求与设计细化、源码生成、测试转换、问题分析和修改建议，几个专业软件接着完成构建、运行、检查与证据保存。工程人员审查依据和结果，下一轮变化就能沿同一条数字化研制过程继续推进。