The challenging part of architecture modeling is not the act of drawing boxes and connecting lines, but capturing sufficient engineering context and data to answer critical questions about system behavior:

• Can a sensor-to-actuator path meet its end-to-end latency requirement?
• Does the deployed communication architecture have enough capacity?
• Which combinations of operational modes can the system attain?
• Are software execution assumptions consistent with the hardware resource allocations?

The Architecture Analysis and Design Language (AADL), now an SAE International standard, is designed to answer questions such as these on the basis of an analyzable architecture model. AADL can describe software threads and processes, processors and memories, physical and virtual buses, typed communications, deployment bindings, operational modes, and the properties needed by engineering analyses. The challenge is that an analysis-ready model must be valid. A model can appear plausible while containing an unresolved component reference, an incorrectly applied property, an incomplete flow, or a timing assumption that does not mean what its author intended.

SEI researchers developed an AADL open-source suite for working with AADL models outside the traditional desktop environment for AADL, which is the Open Source AADL Tool Environment (OSATE). This includes an extension for Visual Studio Code that brings language services and selected architecture analyses from OSATE into the same environment used by many software engineers and AI coding tools.

The extension was developed as open source and is available on the Visual Studio Code Marketplace. The source is available through the SEI-managed OSATE GitHub organization in the AADL Tooling repository.

For program managers and engineering leaders, the potential value of an accelerated architecture modeling capability is not simply faster model authoring. For example, it can help larger teams apply scarce architecture expertise consistently, shortening the time between design changes and evidence about their consequences, which both reduces design risk and helps keep models, analysis results, and documentation aligned. From the perspective of program management, that means timing, resource, and integration risks can surface earlier, when they are less expensive to address.

AI has a role in this extension to OSATE. The AI capability does not replace engineering judgment or approval authority, but it can reduce routine modeling effort so specialists can focus on assumptions, tradeoffs, and acceptance criteria.

If we are to realize these potential benefits, we must address a critical question: What changes when an AI coding tool can not only author AADL models, but also receive feedback from an AADL language server, instantiate those models, run analyses, and inspect the resulting reports?

As detailed later in this post, we piloted this approach by building a flight-controller system that models both software and hardware. Our prototype system did not prove that AI can design or certify a flight-control system. It did, however, demonstrate something narrower and more useful: when coupled with domain-specific validation and analysis, an AI coding tool can help an engineer create and refine a nontrivial AADL model while producing evidence that reviewers can inspect and trace back to model elements and assumptions.

Moving AADL into the Engineering Loop

Moving AADL into the engineering loop means treating the architecture model as a version-controlled, analyzable artifact that evolves with the system rather than documentation consulted only at review milestones. Each change can be checked while design decisions are still being made, shortening the distance between an architectural choice and evidence about its consequences. By placing these capabilities in Visual Studio Code, the extension gives engineers and AI coding tools an integrated environment for making, evaluating, and reviewing model changes.

To support this workflow, the extension provides both language-aware editor services and architecture-analysis capabilities:

• syntax validation and diagnostics
• completion, navigation, outline, breadcrumbs, and code comment hover information
• access to bundled AADL packages and property sets
• component instantiation
• end-to-end latency analysis
• bound bus-load analysis
• mode-reachability analysis, including HTML, DOT, and SMV output

This combination of editor services and expanded capabilities matters because a generative AI model can produce text that resembles AADL, but resemblance is not a useful acceptance criterion. The language server can identify malformed syntax, unresolved names, illegal features, and invalid property use. Instantiation then checks whether the declarative architecture can be elaborated into a concrete system instance. Analyses operate on that instance and expose the consequences of its timing, communication, binding, and modal properties.

Together, these capabilities create a feedback loop:

1. The engineer states an architectural objective and its constraints.
2. The AI coding tool creates or modifies candidate AADL source.
3. The language server returns model-specific diagnostics.
4. The AI and engineer use those diagnostics to revise the source.
5. The AI calls the extension to instantiate the architecture model and to execute the relevant model analyses.
6. The analyses produce reports that can inform the next design decision.

This is the same basic iterative pattern that makes AI coding tools more useful for software development: generation is paired with a compiler, tests, and static analysis. For AADL, the feedback concerns the architecture and its modeled system qualities, not only source-code behavior.

A Flight-Controller Example

We used the extension and an AI coding agent (OpenAI Codex with GPT-5.6 Sol) to build a flight-controller example that exercises every analysis currently exposed by the extension. The model is divided into four AADL packages:

The architecture includes a primary flight-control path in mission mode, a backup path in degraded mode, and a health-telemetry path active in both. A top-level mode machine represents startup, mission, degraded, and maintenance. A nested health-monitor mode machine represents monitoring and isolating.

We intentionally built our model to scale beyond syntax. The model has enough timing, rate, payload, protocol, and binding information to support quantitative analysis.

Describing Timed Software

The navigation software includes a periodic filtering thread:

In AADL syntax, => denotes binding of a value to a property identifier. The properties above serve different purposes. Period, Deadline, and Compute_Execution_Time contribute to timing analysis. Priority and dispatch properties record scheduling assumptions. Code, stack, and MIPS budgets make resource expectations explicit even though the current extension does not yet run analyses over all of them.

That distinction is important. Adding a property to a model does not imply that every analysis consumes it. A useful AI workflow must know which values are descriptive, which are checked, and which are inputs to a particular analysis.

Connecting Logical Traffic to Physical Communication

The hardware package models a physical avionics bus with virtual networks and protocol overhead:

The deployment model binds application connections through the virtual channel hierarchy and assigns a budget to each connection:

Payload Data_Size, source Output_Rate, protocol overhead, connection bindings, and bandwidth capacities give the bus-load analysis the information it needs to compute actual traffic at each level. Because the control channel uses a broadcast protocol, a navigation message sent to both the active controller and the health monitor is counted once on that channel rather than twice.

Making Requirements Modal

The model declares different end-to-end paths for nominal and degraded operation:

In AADL syntax, -> in flows signifies sequencing of steps in a state machine model.

The analysis does not have to infer which controller should be active. That intent is part of the model. The latency bounds are also model elements, not values copied into a separate analysis spreadsheet.

Coupling System and Subsystem Behavior

The top-level mode transitions include fault and recovery behavior:

The health-monitor process has its own mode machine:

This AADL syntax above signified event-driven state transitions. For example, when in the monitoring state and in receipt of a fault_in event, a transition is made to the isolating state.

Event connections route the same fault and recovery triggers into the nested mode machine. A flight-control fault therefore moves the system from mission to degraded and the health monitor from monitoring to isolating as one coupled transition. This relationship becomes visible in the reachability result.

What the Analyses Found

We validated and analyzed the example with prototype build 0.0.2. The AADL source produced zero diagnostics, and the system implementation instantiated without warnings. The generated instance was then used for all three analyses. The latency run used asynchronous-system timing, the major partition frame, worst case as deadline, an empty queue for best case, and queuing latency enabled.

The latency report provides more than a pass/fail result. It decomposes each path into device processing, connection delay, periodic sampling, thread processing, delayed communication, and queuing contributions. For example, the maximum health-telemetry result includes the 100 ms health-monitor deadline and a possible 64 ms queue delay at the telemetry sink. Those details give an engineer places to investigate if a requirement is later tightened.

The bus-load report similarly shows how the total was formed. In mission mode, the navigation-state broadcast contributes 9.8 KB/s on the control channel. The report lists both destination connections but counts the broadcast once. The physical-bus total, including the modeled protocol overhead, is 33.6 KB/s. Switching to the backup control path in degraded mode changes the traffic structure and reduces the total to 31.9 KB/s.

The reachability analysis exposes a different class of result. Four top-level modes and two health-monitor modes might suggest eight combinations. Only seven are reachable. The missing combination is not an error in this model: the fault trigger that enters degraded also enters isolating. However, the same finding in another architecture could reveal an unintended coupling, a missing recovery transition, or a state that requirements assume exists but the implementation model can never enter. The generated HTML, DOT, and SMV artifacts make that behavior available for review and further analysis.

Together, the three analyses answer complementary questions. Latency follows functional paths through periodic software and communication. Bus load aggregates modal traffic over a bound network hierarchy. Reachability checks the state space in which those modal paths and connections can exist.

What AI contributed, and What it Did Not

The AI coding tool accelerated several parts of the experiment:

• decomposing the example into reusable type, hardware, software, and deployment packages
• generating repetitive component declarations, connections, flows, and property associations
• responding to language-server diagnostics across multiple files
• adding the property detail required by each analysis
• inspecting generated reports and tracing results back to model elements
• maintaining a README with reproducible analysis steps and expected results

Those are meaningful productivity gains, especially for a textual language with cross-file references and a large property vocabulary. Importantly, they do not make the AI the authority on the architecture.

The engineer still has to decide, for example, whether 120 ms is the right primary-control latency requirement; whether the modeled execution-time ranges are supported by measurement; whether the deployment represents the intended hardware; and whether broadcast behavior matches the network protocol. The analysis can show that the model is internally consistent with a bound. It cannot establish that the bound or the model is correct for a real aircraft.

As shown in Table 2 below, this separation of responsibilities is central to the workflow:

Without the last two rows, an AI-generated model can be fluent but untrustworthy. Without the first row, a clean and analyzable model can still answer the wrong question.

What Engineers Can Create with this Combination

Our flight controller is one illustrative example. Additional opportunities lie in utilizing the extension as a deterministic modeling and analysis layer within an AI-augmented engineering environment. An engineer can describe a system architecture in plain language, for example, and ask an AI coding agent to create an initial package structure, component interfaces, implementations, and connections. The agent can then use diagnostics to converge on valid AADL instead of stopping at plausible text. Existing component libraries can constrain that generation so the model reuses an organization's processor, network, sensor, and software patterns.

The same workflow can create deployment alternatives. An agent can bind software to different processors, move traffic between virtual channels, or change modal activation while preserving the surrounding architecture. The extension can instantiate each alternative and rerun the relevant analyses. This does not automatically make the agent a design-space optimizer, but it reduces the mechanics required to pose and evaluate a trade.

Teams can also create analysis regression examples. A model, such as the flight controller, records known timing, bandwidth, and reachability results. As the extension evolves, those models can detect changes in parser behavior, instantiation, property interpretation, and analysis output. AI tools can help expand the cases, explain differences, and synchronize supporting documentation.

Finally, the generated artifacts can become part of an engineering evidence package. AADL source, serialized instance models, CSV results, reachability tables, graphs, and model-checker input are all inspectable and can be placed under version control. An AI assistant can summarize those artifacts or draft review material, while reviewers retain access to the source values and analysis output behind the summary.

There are adjacent possibilities that this experiment did not validate. Architecture models may be used as contracts for software scaffolding, interface generation, test construction, or digital-engineering traceability. Those workflows require their own transformations and verification. They should not be attributed to the extension merely because an AI tool can propose them.

What Remains to be Understood

The current extension is an early-stage tool. It provides a textual editing experience, instantiation, and three analyses; it is not a graphical architecture editor or a general code generator. The example contains processor scheduling, memory, million instructions per second (MIPS), code-size, stack-size, and hardware-weight properties that are useful for future work but are not all analyzed by the current build.

More fundamentally, a clean model is not necessarily a good model. Zero diagnostics means that the source satisfies the language rules known to the server. Successful instantiation means that the declared architecture can be elaborated. A passing latency or capacity result means that the stated properties satisfy the stated bound under the analysis configuration. However, zero diagnostics, successful instantiation, and passing latency or capacity results do not establish the provenance of the input values, the completeness of the architecture, or the validity of its physical assumptions.

The introduction of AI in architecture modeling brings with it additional questions:

• How should an agent preserve the source and rationale for every generated property value?
• How can it distinguish a placeholder from a measured parameter or approved requirement?
• When an analysis fails, can it propose alternatives without silently weakening the requirement?
• How should uncertainty and incomplete information be represented instead of filled with plausible numbers?
• Which model and analysis results are effective benchmarks for evaluating an AI-assisted MBSE workflow?

These questions point toward a stronger pattern than unconstrained model generation. The AI should operate inside an evidence-producing loop, with explicit requirements, reusable domain libraries, deterministic validation, analysis results, provenance, and human review.

An Open-Source Foundation for AI-Assisted AADL Workflows

We invite researchers and practitioners to inspect the integration, reproduce results, report problems, contribute model examples, and experiment with new analyses and AI-assisted workflows. The extension is available on the Visual Studio Code Marketplace. The source is available through the SEI-managed OSATE GitHub organization in the AADL Tooling repository so that this work can develop in the open. This repository also provides a command line client for OSATE osate-cli that supports the same functionality as the extension.

Our flight-controller experiment demonstrates the core idea. An AI coding tool can help create a multi-file AADL model that combines software and hardware, deployment and communication, timing and capacity, and nominal and degraded behavior. The SEI extension then turns that text into a validated instance and concrete analysis artifacts.

The result is not autonomous systems engineering. It is a more disciplined division of labor: AI helps engineers work through a detailed textual model, AADL gives that model precise architectural semantics, analysis exposes the consequences of its assumptions, and engineers remain responsible for the decisions.

For more information or to collaborate with the SEI, please send an email to info@sei.cmu.edu.