AI 编程工具与 AADL 架构建模结合起来,在 Visual Studio Code 里形成一个“可验证、可分析”的工程闭环

架构建模真正难的不是“画框框和连线”，而是捕捉足够的工程上下文和数据，来回答关于系统行为的关键问题，例如：

• 传感器到执行器的路径能否满足端到端延迟要求？
• 部署后的通信架构容量够不够？
• 系统能进入哪些运行模式组合？
• 软件执行假设与硬件资源分配是否一致？

AADL（Architecture Analysis & Design Language，架构分析与设计语言）是 SAE 国际标准，专门用来描述软件线程与进程、处理器与内存、物理与虚拟总线、类型化通信、部署绑定、运行模式以及工程分析所需的属性。

但问题在于：一个“看起来合理”的模型，可能包含未解析的组件引用、错误应用的属性、不完整的流，或者本意并非如此的时序假设。分析就绪的模型必须是有效的。

二、解决方案：把 AADL 搬进 VS Code，并接入 AI

SEI 研究人员开发了一套开源 AADL 工具套件，让 AADL 模型可以脱离传统桌面环境 OSATE（Open Source AADL Tool Environment）来使用。其中包括一个Visual Studio Code 扩展，把 OSATE 的语言服务和部分架构分析能力带入许多软件工程师和 AI 编程工具已经在用的环境。

这个扩展是开源的，可在 VS Code Marketplace 获取，源码在 SEI 管理的 OSATE GitHub 组织下的 AADL Tooling 仓库中。

对项目管理者和工程领导者的价值

加速架构建模的价值不只是写模型更快，而是：

• 帮助大团队一致地应用稀缺的架构专业知识；
• 缩短“设计变更”到“了解其后果证据”之间的时间；
• 降低设计风险，让模型、分析结果和文档保持一致；
• 让时序、资源和集成风险更早暴露，此时处理成本更低。

AI 的角色

AI不替代工程判断或审批权，而是减少常规建模工作，让专家专注于假设、权衡和验收标准。

提出了一个关键问题：

当一个 AI 编程工具不仅能编写 AADL 模型，还能从 AADL 语言服务器接收反馈、实例化模型、运行分析并检查结果报告时，会发生什么变化？

三、把 AADL 移入工程循环

“把 AADL 移入工程循环”意味着：把架构模型当作一个受版本控制、可分析的工件，让它随系统一起演进，而不是只在评审节点才查阅的文档。

扩展提供了两类能力：

语言感知的编辑器服务：

• 语法验证与诊断
• 补全、导航、大纲、面包屑、代码注释悬停信息
• 访问内置的 AADL 包和属性集

架构分析能力：

• 组件实例化
• 端到端延迟分析
• 绑定总线负载分析
• 模式可达性分析（支持 HTML、DOT、SMV 输出）

强调：生成式 AI 可以产出“像 AADL”的文本，但“像”不是有用的验收标准。语言服务器能识别语法错误、未解析名称、非法特性和无效属性使用；实例化检查声明式架构能否被展开为具体系统实例；分析则在这个实例上运行，暴露时序、通信、绑定和模态属性的后果。

由此形成反馈闭环：

1. 工程师陈述架构目标与约束；

2. AI 编程工具创建或修改候选 AADL 源码；

3. 语言服务器返回模型相关的诊断；

4. AI 和工程师利用诊断修订源码；

5. AI 调用扩展实例化架构模型并执行相关分析；

6. 分析产生报告，指导下一步设计决策。

这和 AI 编程工具在软件开发中变得有用的基本模式相同：生成与编译器、测试、静态分析配对。对 AADL 而言，反馈关乎架构及其建模的系统质量，而不仅是源码行为。

四、飞行控制器示例

他们用这个扩展和一个 AI 编程代理（OpenAI Codex with GPT-5.6 Sol）构建了一个飞行控制器示例，覆盖扩展当前暴露的所有分析。模型分为四个 AADL 包：

架构包括：任务模式下的主飞行控制路径、降级模式下的备份路径、两种模式下都活跃的健康遥测路径。顶层模式机表示启动、任务、降级、维护；嵌套的健康监控模式机表示监控和隔离。

1. 描述带时序的软件

导航软件包含一个周期性滤波线程，属性包括：

• Dispatch_Protocol => Periodic
• Period => 20 ms
• Deadline => 20 ms
• Compute_Execution_Time => 3 ms .. 5 ms
• Priority => 210
• Stack_Size => 32 KiByte
• Code_Size => 96 KiByte
• SEI::MIPSBudget => 220.0 MIPS

重要区分：给模型加属性，不代表每个分析都会消费它。有用的 AI 工作流必须知道哪些值是描述性的、哪些被检查、哪些是特定分析的输入。

2. 把逻辑流量连接到物理通信

硬件包建模了一条物理航电总线，带虚拟网络和协议开销：

• Avionics_Data_Bus
  ：数据大小 8 字节，带宽预算 600 KB/s，容量 1000 KB/s，非广播协议
• Control_Channel
  ：数据大小 16 字节，带宽预算 160 KB/s，容量 240 KB/s，广播协议

部署模型把应用连接绑定到虚拟通道层次，并为每个连接分配预算。由于控制通道使用广播协议，一条发给活动控制器和健康监控的导航消息在该通道上只计一次，而不是两次。

3. 让需求具有模态性

模型为标称和降级运行声明了不同的端到端路径：

• primary_flight_control
  ：在 mission 模式下，延迟 0–120 ms
• backup_flight_control
  ：在 degraded 模式下，延迟 0–180 ms

分析不必推断哪个控制器应该活跃——这个意图是模型的一部分。延迟边界也是模型元素，不是复制到单独分析电子表格里的值。

4. 耦合系统与子系统行为

顶层模式转换包括故障与恢复行为：

• startup -[boot_complete]-> mission
• mission -[flight_control_fault]-> degraded
• degraded -[recovery_complete]-> mission
• mission -[maintenance_request]-> maintenance
• degraded -[maintenance_request]-> maintenance
• maintenance -[reset_request]-> startup

健康监控进程有自己的模式机：monitoring -[fault_in]-> isolating，isolating -[reset_in]-> monitoring。

事件连接把相同的故障和恢复触发路由到嵌套模式机。因此，飞行控制故障会作为一个耦合转换，把系统从 mission 移到 degraded，同时把健康监控从 monitoring 移到 isolating。这种关系在可达性结果中可见。

五、分析发现了什么

他们用原型构建 0.0.2 验证并分析了示例。AADL 源码产生零诊断，系统实现实例化无警告。

表 1：建模架构与假设的分析结果

延迟报告不只是通过/失败，它把每条路径分解为设备处理、连接延迟、周期采样、线程处理、延迟通信和排队贡献。例如，健康遥测最大值包含 100 ms 的健康监控截止时间和遥测接收端可能的 64 ms 排队延迟。这些细节给工程师提供了在需求收紧时调查的切入点。

总线负载报告同样展示总量如何形成。任务模式下，导航状态广播在控制通道上贡献 9.8 KB/s。报告列出两个目标连接，但广播只计一次。物理总线总量（含建模的协议开销）是 33.6 KB/s。降级模式下切换到备份控制路径，流量结构改变，总量降到 31.9 KB/s。

可达性分析暴露了另一类结果。四个顶层模式和两个健康监控模式可能暗示八种组合，但只有七种可达。缺失的组合在这个模型里不是错误：进入 degraded 的故障触发也进入 isolating。然而，同样的发现在另一个架构中可能揭示意外耦合、缺失的恢复转换，或者需求假设存在但实现模型永远无法进入的状态。

三种分析回答互补的问题：延迟沿功能路径穿过周期性软件和通信；总线负载在受限网络层次上聚合模态流量；可达性检查这些模态路径和连接可以存在的状态空间。

六、AI 贡献了什么，没贡献什么

AI 编程工具加速了实验的多个部分：

• 把示例分解为可复用的类型、硬件、软件和部署包；
• 生成重复的组件声明、连接、流和属性关联；
• 跨多个文件响应语言服务器诊断；
• 添加每个分析所需的属性细节；
• 检查生成报告，把结果追溯回模型元素；
• 维护带可复现分析步骤和预期结果的 README。

这些是有意义的生产力提升，尤其对于有跨文件引用和大量属性词汇的文本语言。但重要的是，它们不让 AI 成为架构的权威。

工程师仍然必须决定：120 ms 是否是正确的主动控制延迟需求；建模的执行时间范围是否有测量支持；部署是否代表预期硬件；广播行为是否匹配网络协议。分析可以显示模型在某个边界下内部一致，但不能确立该边界或模型对真实飞机是正确的。

表 2：AI 增强 AADL 工作流中各参与者的角色

没有最后两行，AI 生成的模型可能流畅但不可信；没有第一行，干净可分析的模型仍可能回答错误的问题。

七、工程师能用这个组合创建什么

飞行控制器只是一个示例。更多机会在于把扩展用作 AI 增强工程环境中的确定性建模与分析层：

• 从自然语言生成初始架构：工程师用平实语言描述系统架构，让 AI 代理创建初始包结构、组件接口、实现和连接；代理用诊断收敛到有效 AADL，而不是停在看似合理的文本。现有组件库可以约束生成，复用组织的处理器、网络、传感器和软件模式。
• 创建设计替代方案：代理可以把软件绑定到不同处理器、在虚拟通道间移动流量、改变模态激活，同时保留周围架构；扩展可以实例化每个替代方案并重新运行相关分析。这不会自动让代理成为设计空间优化器，但减少了提出和评估权衡所需的机械工作。
• 创建分析回归示例：像飞行控制器这样的模型记录已知的时序、带宽和可达性结果。随着扩展演进，这些模型可以检测解析器行为、实例化、属性解释和分析输出的变化。AI 工具可以帮助扩展用例、解释差异、同步支持文档。
• 形成工程证据包：AADL 源码、序列化实例模型、CSV 结果、可达性表、图和模型检查器输入都可检查，并可纳入版本控制。AI 助手可以总结这些工件或起草评审材料，同时评审者仍能访问摘要背后的源值和分析输出。

提醒：这个实验没有验证相邻可能性，比如把架构模型用作软件脚手架、接口生成、测试构造或数字工程可追溯性的契约。这些工作流需要自己的转换和验证，不应仅因为 AI 工具能提出它们就归功于扩展。

八、仍待理解的问题

当前扩展是早期工具：提供文本编辑体验、实例化和三种分析；不是图形化架构编辑器，也不是通用代码生成器。示例包含处理器调度、内存、MIPS、代码大小、栈大小和硬件重量属性，对未来工作有用，但当前构建并未全部分析。

更根本的是：干净的模型不一定是好模型。

• 零诊断意味着源码满足服务器已知的语言规则；
• 成功实例化意味着声明的架构可以被展开；
• 通过延迟或容量结果意味着在分析配置下，所述属性满足所述边界。

然而，这些都不能确立输入值的来源、架构的完整性或物理假设的有效性。

AI 引入架构建模还带来额外问题：

• 代理应如何为每个生成的属性值保留来源和理由？
• 如何区分占位符与测量参数或已批准需求？
• 当分析失败时，能否提出替代方案而不悄悄弱化需求？
• 不确定和不完整信息应如何表示，而不是用看似合理的数字填充？
• 哪些模型和分析结果是评估 AI 辅助 MBSE 工作流的有效基准？

这些问题指向一个比无约束模型生成更强的模式：AI 应在证据生产循环内运行，有显式需求、可复用领域库、确定性验证、分析结果、来源和人工评审。

九、开源基础

SEI 邀请研究人员和实践者检查集成、复现结果、报告问题、贡献模型示例，并实验新分析和 AI 辅助工作流。扩展在 VS Code Marketplace 上，源码在 SEI 管理的 OSATE GitHub 组织的 AADL Tooling 仓库中。该仓库还提供命令行客户端 osate-cli，支持与扩展相同的功能。

飞行控制器实验演示了核心思想：AI 编程工具可以帮助创建多文件 AADL 模型，结合软件与硬件、部署与通信、时序与容量、标称与降级行为；SEI 扩展随后把文本变成经过验证的实例和具体分析工件。

结果不是自主系统工程，而是一种更纪律化的分工：

• AI 帮助工程师处理详细的文本模型；
• AADL 给模型精确的架构语义；
• 分析暴露其假设的后果；
• 工程师仍然对决策负责。

全文总结与工程启示

1. AI 的边界与价值定位：该研究并未声称 AI 可以独自设计或对飞控系统进行最终适航认证。其实际成果更加务实：AI 承担了繁琐、易错的语法填充与样板连接，而系统专家则专注于假设制定、权衡分析与准入标准。

2. “生成 + 验证”范式的迁移：将现代软件开发中“大模型代码生成 + 编译器检查 + 单元测试/静态检查”的高效闭环，成功泛化到了航天/防务领域的系统架构工程（MBSE）。

3. 前置消除风险：通过在 VS Code 中实时运行 AADL 实例化与物理属性核验，时序违例、总线拥塞和架构不匹配等深层缺陷在概念架构设计期即被暴露并闭环修正，极大压缩了后期集成返工的成本。