Module 9: Aerospace & Defence
How MBSE is applied in aerospace and defence — standards, challenges, certification, and real-world patterns.
Prerequisite: MBSE Module 8Why Aerospace & Defence Led MBSE Adoption
Aerospace and defence (A&D) systems are among the most complex engineered artefacts on the planet. A modern combat aircraft contains millions of parts, hundreds of thousands of requirements, and must remain in service for 30–50 years. These characteristics made the sector a natural pioneer for MBSE.
Drivers of complexity
- Safety-criticality — failure can result in loss of life. Every design decision must be traceable to safety evidence.
- Long lifecycles — platforms like the B-52, F-16, and Eurofighter Typhoon remain in service for decades, requiring models that outlive any single engineer or contractor.
- Multi-contractor integration — prime contractors, sub-system suppliers, and government agencies must share a common understanding of the system. Documents alone cannot maintain consistency across dozens of organisations.
- Regulatory rigour — civil and military certification authorities demand structured evidence of compliance, making model-based traceability highly valuable.
The US DoD Digital Engineering Strategy
In 2018, the United States Department of Defense published its Digital Engineering Strategy, marking a watershed moment. The strategy mandated a shift from document-centric to model-centric acquisition and engineering across all DoD programmes. Its five goals include: formalise the development and use of models, provide an authoritative source of truth, incorporate technological innovation, establish a digital engineering infrastructure, and transform the culture and workforce.
The DoD Digital Engineering Strategy (2018) was not merely a recommendation — it established policy that all major defence acquisition programmes should adopt model-centric approaches. This single policy decision accelerated MBSE adoption across the global defence industry, as allied nations and their contractors aligned with US procurement expectations.
Beyond the US
Europe followed with similar initiatives. The UK Ministry of Defence published its Digital Strategy for Defence, and organisations like ESA (European Space Agency) and Airbus adopted MBSE as standard practice for spacecraft and aircraft programmes. In these contexts, MBSE is not optional — it is a contractual requirement.
Standards Landscape
Aerospace and defence operate within a dense web of standards. MBSE models do not replace these standards — they provide structured evidence that the standards have been satisfied. Understanding which standards matter is essential for any MBSE practitioner working in this domain.
Key standards
| Standard | Scope | MBSE Relevance |
|---|---|---|
| ARP4754A | Development assurance for civil aircraft systems | Defines assurance levels (DAL A–E). MBSE models trace requirements to architecture and verification evidence at each DAL. |
| DO-178C | Software airworthiness | Model-based development supplement (DO-331) explicitly addresses how models can replace or supplement traditional documents for software certification. |
| DO-254 | Hardware (FPGA/ASIC) airworthiness | Similar to DO-178C but for complex electronic hardware. MBSE supports design assurance and traceability of hardware requirements. |
| MIL-STD-882E | System safety (US military) | Hazard analysis and risk assessment. MBSE models capture hazard logs, safety requirements, and mitigation traceability. |
| AS9100 | Quality management for aerospace | Requires documented evidence of design control. MBSE provides a single source of truth for configuration and change management. |
How MBSE supports certification evidence
Certification authorities (e.g. FAA, EASA, military airworthiness authorities) require structured evidence that a system meets its safety and performance requirements. Traditionally, this evidence was a mountain of documents — thousands of pages of requirements, test reports, and traceability matrices maintained in spreadsheets.
MBSE transforms this by embedding traceability directly in the model. A requirement is linked to the architectural element that satisfies it, which is linked to the verification case that confirms it. When an auditor asks "show me the evidence for Requirement X," the answer is a model query — not a manual search through filing cabinets.
For certification, traceability is everything. Build your MBSE model with traceability links from day one — from stakeholder needs through system requirements, architecture allocation, and verification cases. Retrofitting traceability after the fact is orders of magnitude more expensive than building it incrementally.
Unified Architecture Framework (UAF)
While SysML is the dominant modelling language, the Unified Architecture Framework (UAF) is the dominant architecture framework for defence system-of-systems. UAF (formerly known as UPDM/MODAF/DoDAF) provides a standardised set of viewpoints for describing complex military and enterprise architectures.
What UAF provides
UAF organises architectural descriptions into a grid of viewpoints, each addressing a different stakeholder concern. Rather than modelling a single system in isolation, UAF is designed for the system-of-systems level — how multiple systems, organisations, and capabilities interact to deliver a military or enterprise mission.
UAF viewpoint overview
| Viewpoint | Concern | Example Questions Answered |
|---|---|---|
| Strategic | High-level capability goals | What capabilities does the force need by 2035? |
| Operational | Operational activities and information flows | How do units coordinate during a joint operation? |
| Services | Service-oriented architecture | What services does this platform expose to the network? |
| Personnel | Roles, skills, organisations | What training does this system require for operators? |
| Resources | Systems, platforms, physical assets | Which platforms implement this capability? |
| Security | Security constraints and policies | What classification levels apply to each data flow? |
| Projects | Acquisition and delivery timelines | When will each increment be delivered? |
| Standards | Technical and operational standards | Which interoperability standards must be followed? |
UAF is an architecture framework, not a modelling language. It is typically implemented using SysML or UML profiles. Think of UAF as the "what to model" and SysML as the "how to model it." Many defence MBSE projects use both: UAF provides the viewpoint structure, and SysML provides the notation.
When to use UAF vs. SysML alone
For a single system (e.g. one radar unit), SysML with a method like OOSEM or MagicGrid is usually sufficient. UAF becomes valuable when you need to describe system-of-systems — how multiple systems, organisations, and operational processes come together. If your programme involves joint military operations, coalition interoperability, or enterprise-level capability planning, UAF is likely required.
MBSE Patterns in Aerospace
Over two decades of adoption, the aerospace community has developed recurring MBSE patterns — proven approaches to common modelling challenges. Understanding these patterns accelerates your own practice.
Mission thread analysis
A mission thread traces a complete operational scenario from trigger to outcome, crossing system and organisational boundaries. For example, a surveillance mission thread might start with an intelligence tasking, flow through satellite retasking, image capture, downlink, processing, analysis, and dissemination to the operational commander. MBSE models each step as an activity or action, with interfaces and data flows clearly defined at each boundary.
Operational scenario modelling
Before designing the system, engineers model operational scenarios — how users will interact with the system in its intended environment. In aerospace, these scenarios are often safety-critical: what happens during an engine failure? During a loss of communication? MBSE captures these scenarios as sequence or activity models, linked to the requirements they derive from and the architectural elements that must support them.
Failure mode modelling
MBSE connects structural models to safety analysis. Each component in the model can be annotated with failure modes, failure rates, and severity classifications. This enables automated generation of Failure Mode and Effects Analysis (FMEA) and Fault Tree Analysis (FTA) from the same model used for design — eliminating the inconsistency that arises when safety analysis is performed in a separate, disconnected tool.
Interface management across contractors
In large A&D programmes, different contractors build different sub-systems. The interfaces between these sub-systems are contractually binding. MBSE captures interfaces as port definitions with typed flows — electrical, mechanical, data, and fluid. When a change is proposed, the model immediately reveals which interfaces are affected and which contractors must be consulted.
Example: satellite ground station system
Consider a satellite ground station that must interface with multiple space agencies (NASA, ESA, JAXA), multiple satellite constellations, and multiple end-user organisations. The ground station must handle dozens of communication protocols, strict timing constraints, and security classifications ranging from unclassified to top secret. An MBSE model captures all of these interfaces, protocols, and constraints in a single authoritative source — something no collection of documents could achieve without contradiction.
Think of air traffic control. A controller does not manage one aircraft — they coordinate dozens of aircraft from different airlines, each with different performance characteristics, all sharing the same airspace. The controller's radar screen is their "model" — a single, authoritative, real-time view of a complex system-of-systems. MBSE serves the same role for aerospace engineers: a shared, authoritative view of a complex system that no single document could capture.
Challenges and Lessons Learned
Aerospace and defence may lead MBSE adoption, but the journey has not been smooth. Understanding the challenges faced by this sector provides valuable lessons for any industry considering MBSE.
Model scale
A&D models can grow to millions of elements. A single aircraft programme may have 200,000+ requirements, thousands of architectural elements, and millions of traceability links. Current tools struggle with models of this scale — performance degrades, queries slow down, and version control becomes complex. Partitioning models across teams (federated modelling) helps, but introduces synchronisation challenges.
Multi-tool integration
No single tool covers all MBSE needs. A typical A&D programme might use Cameo Systems Modeler for SysML, DOORS for requirements, Matlab/Simulink for simulation, and a custom tool for safety analysis. Integrating these tools so that changes propagate consistently is a major engineering challenge in its own right. Standards like OSLC (Open Services for Lifecycle Collaboration) help, but tool integration remains brittle and expensive.
Intellectual property concerns
When multiple contractors share a model, IP boundaries become critical. Contractor A does not want Contractor B to see its proprietary design details — only the interfaces. Federated modelling with controlled access is the standard approach, but requires careful governance and tool support for access control at the model-element level.
Qualification of model-based evidence
Certification authorities have decades of experience reviewing documents. Reviewing models is new territory. Questions arise: how does an auditor verify that the model is correct? What constitutes sufficient model-based evidence? How is model integrity assured? The industry is still developing standards and best practices for model-based certification, with DO-331 (the model-based development supplement to DO-178C) being the most mature guidance.
Cultural resistance
Aerospace and defence organisations tend to be conservative — and for good reason. When lives depend on engineering rigour, "we have always done it this way" is not mere stubbornness; it reflects hard-won lessons. Introducing MBSE requires demonstrating that model-based approaches are at least as rigorous as document-based ones, and then showing the additional benefits (consistency, automation, reuse) on top of that baseline.
Do not underestimate cultural resistance in safety-critical organisations. Engineers who have spent careers building document-based certification packages will not adopt MBSE simply because management mandates it. Success requires investment in training, pilot projects that demonstrate tangible benefits, and a transition strategy that runs model-based and document-based approaches in parallel until confidence is established.