Industries
Aerospace is defined by a characteristic that separates it from almost every other EA context: the systems it produces must not fail catastrophically. This is not a quality aspiration: it is a legal requirement backed by certification standards, airworthiness authorities, and in some cases criminal liability.
Enterprise architecture in aerospace carries a weight it does not carry elsewhere. An architecture decision that creates an unverifiable requirement trace is not a governance problem: it is a certification problem. A system architecture that does not explicitly model safety integrity levels is not a design gap: it is a safety case gap. A repository that cannot produce certification evidence on demand is not an inefficiency: it is a compliance risk.
Sparx Enterprise Architect is the tool of choice for safety-critical aerospace EA and MBSE work because it supports SysML, ArchiMate, BPMN, and UML in a single governed repository with requirements traceability that can span from stakeholder requirements through design to test results. For programs subject to DO-178C, DO-254, AS9100, or IEC 61508, that traceability is not a nice feature: it is the certification foundation.
A safety-critical system is one where failure can result in loss of life, serious injury, or major environmental harm. Avionics systems, flight management computers, engine control units, and autonomous vehicle platforms are all safety-critical. The consequence of this classification is a mandatory engagement with formal safety analysis methods: Fault Tree Analysis (FTA), Failure Mode and Effects Analysis (FMEA), HAZOP, and safety integrity level (SIL) determination.
Enterprise architecture in safety-critical contexts must accommodate these safety engineering artefacts. The architecture repository is not just a description of what the system is: it is part of the evidence base that shows the system is safe enough to certify.
Every safety-critical aerospace program is governed by a certification standard that dictates how software and system development must be conducted:
DO-178C (Software Considerations in Airborne Systems and Equipment Certification) governs software development for avionics. It defines five software levels (A–E) based on the severity of a software failure: Level A is the most stringent (catastrophic failure) and Level E is the least (no safety effect). DO-178C objectives: covering planning, development, verification, configuration management, and quality assurance: must all be satisfied with traceable evidence.
DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) governs FPGA, ASIC, and custom hardware development for avionics. It mirrors DO-178C’s assurance level structure for hardware.
AS9100 is the quality management system standard for the aviation, space, and defense industry: based on ISO 9001 but with significant additional requirements for design and development traceability in safety-critical contexts.
IEC 61508 (Functional Safety of E/E/PE Safety-Related Systems) is the foundational standard for functional safety, from which sector-specific standards are derived. It defines SIL 1–SIL 4 and the systematic capability requirements for development processes at each level.
Model-Based Systems Engineering (MBSE) is the practice of using formal models: not documents: as the primary medium for systems engineering work. For complex aerospace programs, MBSE is not optional: the complexity of modern aircraft systems cannot be managed through document-based methods.
A commercial aircraft contains over 100 systems, thousands of interfaces, and hundreds of thousands of requirements. These cannot be understood, verified, or certified without model-based approaches that make structure, behavior, and interfaces explicit and navigable.
Sparx EA is the primary MBSE tool used alongside dedicated systems engineering platforms. It provides SysML modeling, requirements management, traceability matrices, and a governed repository that can maintain models through multi-year certification programs.
SysML (Systems Modeling Language) is the OMG-standardized language for systems engineering: a profile of UML adapted for systems engineering work. It adds:
Sparx EA provides a complete SysML 1.x implementation with all diagram types, stereotypes, and toolboxes. SysML 2.x support is in active development across the tool ecosystem.
Defense aerospace programs: military aircraft, unmanned systems, defense satellite systems: typically combine MBSE (for system-level modeling) with DoDAF or NAFv4 (for operational and capability architecture). The UPDM (Unified Profile for DoDAF and MODAF) profile in Sparx EA supports this combination in a single repository.
Aerospace prime contractors and program organizations use TOGAF at the enterprise layer: for capability maps, operating model design, and IT strategy. The TOGAF work lives above the system-level MBSE work: TOGAF describes the enterprise context (what the organization needs to be able to do), while MBSE describes the technical systems (how the systems that deliver those capabilities are designed).
Capella is an open-source MBSE tool (developed by Thales and contributed to the Eclipse Foundation) used for model-based system architecture work in aerospace and defense. It uses the ARCADIA method and produces models in its own notation. Sparx EA and Capella are increasingly used in combination: Capella for detailed system-level architecture, Sparx EA for enterprise context, requirements management, and repository governance. Sparx Services can advise on appropriate toolchain boundary decisions and implement the integration.
A SysML-based aircraft systems architecture in Sparx EA follows a hierarchical block decomposition from aircraft to system to subsystem to component:
Aircraft ├── Avionics System │ ├── Flight Management System (FMS) │ │ ├── Navigation Function │ │ ├── Performance Management Function │ │ └── Flight Planning Function │ ├── Displays and Controls │ └── Data Communication System ├── Propulsion System ├── Electrical Power System └── Hydraulic System
Each block in the hierarchy is specified with properties (power consumption, weight, operating temperature range, certification level), ports (the interfaces through which the block connects to other blocks), operations (the functions the block performs), and requirements (linked from the requirements package). Internal Block Diagrams show the connections between blocks at each level of decomposition. Parametric Diagrams model power budget allocation across systems.
Certification evidence in DO-178C programs is not a collection of documents: it is a network of artefacts with explicit traceability relationships. An avionics software project produces requirements, design documents, test cases, and test results: and the certification authority must be able to trace from any requirement through the design to the tests that verify it.
Sparx EA’s requirements management supports this traceability at the architecture and design levels:
This trace is the certification audit trail. When the certification authority asks “where is the evidence that requirement SR-047 has been verified?”, the answer is the path from SR-047 through design elements to test cases and recorded test results.
Defense aerospace programs require capability architecture that spans from strategic capability requirements through program architecture to system design. DoDAF viewpoints: Capability Viewpoint (CV), Systems Viewpoint (SV), Operational Viewpoint (OV): provide the structured framework for this work, with Sparx EA’s UPDM profile delivering full DoDAF/NAFv4 support in a governed repository.
A safety case is a structured argument, supported by evidence, that a system is acceptably safe for a defined application in a defined operating environment. Safety cases are required for avionics certification by airworthiness authorities (FAA, EASA, CAA) and for defense platform acceptance.
A safety case typically takes the form of a goal-structured argument:
Sparx EA supports safety case modeling through Goal Structuring Notation (GSN): a modeling approach for structured safety arguments. GSN elements (Goals, Strategies, Evidence, Context, Assumptions) are implemented as stereotype extensions with relationships representing the argument structure.
What makes enterprise architecture different in aerospace?
In aerospace, the EA repository is part of the certification evidence base, not just an organisational planning tool. Architecture decisions must be made with explicit regard for safety integrity levels, certification standards (DO-178C for avionics software, DO-254 for hardware, AS9100 for quality management), and the requirement to produce traceable evidence from requirements through design to verification. An architecture gap that would be a governance problem in other sectors can be a certification-blocking problem in aerospace.
What is MBSE and why is it important for aerospace programs?
MBSE (Model-Based Systems Engineering) uses formal models: rather than documents: as the primary medium for systems engineering. In aerospace, the complexity of safety-critical systems makes document-based approaches inadequate: a modern aircraft avionics system has thousands of requirements, hundreds of interfaces, and complex state machine behavior that cannot be managed in documents. MBSE in Sparx EA provides structured decomposition, interface specification, requirements traceability, and safety case modeling in a single governed repository.
How does Sparx EA support DO-178C certification?
Sparx EA supports DO-178C through requirements management (stakeholder to system to software requirement traces), design modeling (SysML block and state machine diagrams), traceability matrices (linking requirements to design elements, test cases, and test results), and configuration management through Sparx EA’s baseline and version control capabilities. It does not replace a formal DO-178C process: it provides the model-based architecture and requirements infrastructure that the process generates and maintains evidence within.
What is the relationship between SysML and enterprise architecture frameworks like TOGAF?
SysML operates at the system engineering level: it describes what a specific system is, how it is decomposed, how its parts interface, and how it behaves. TOGAF operates at the enterprise architecture level: it describes the capability landscape, operating model, and IT architecture of the organization. In aerospace, both are needed: TOGAF describes the enterprise context the systems must fit within; SysML describes the systems that satisfy enterprise capability requirements. In Sparx EA, both coexist in a single repository with explicit traceability links between the enterprise and system layers.
Does Sparx Services work with Capella alongside Sparx EA?
Yes. Capella (the Eclipse ARCADIA MBSE tool) and Sparx EA are used in combination on some aerospace and defense programs: Capella for detailed operational and system architecture using the ARCADIA method, Sparx EA for enterprise context, requirements management, and repository governance. Integration approaches vary by program toolchain and organization. Sparx Services can advise on appropriate Capella/Sparx EA boundary decisions and implement the integration between the two tools.
How does Sparx Services help aerospace organizations with MBSE implementations?
Sparx Services supports aerospace MBSE implementations through two primary engagements. Amplify ($45K–$160K) is for organizations with existing EA or MBSE repositories that need improved governance, better traceability, and connection to reporting and AI tools. Platform Support is for complex MBSE environments that need ongoing expert advisory, toolchain governance, and architect development. Contact Sparx Services to discuss the right engagement for your program’s phase and complexity.
Safety-critical MBSE implementations require sustained expert support: not a one-time deployment. Sparx Services provides ongoing expert advisory for complex aerospace programs through Platform Support, and delivers governance and toolchain improvements through Amplify engagements.
Amplify ($45K–$160K): for organizations with existing EA or MBSE repositories that need improved traceability, better MDG governance, and connection to reporting and AI tools.
Platform Support: for programs that need ongoing Sparx EA expert advisory, toolchain governance, and architect capability development.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.