Direct Answer
DO-178C — Software Considerations in Airborne Systems and Equipment Certification — imposes rigorous traceability, documentation, and verification requirements on airborne software from the highest design assurance level (DAL A, catastrophic failure condition) down to DAL E (no safety effect). Sparx EA provides the model-based foundation for DO-178C compliance: requirements are structured in a hierarchy from System Requirements through High-Level Requirements to Low-Level Requirements, with software level assigned as tagged values on software components, SysML Block Definition Diagrams capturing avionic system structure, Internal Block Diagrams defining software interface specifications, and the Relationship Matrix generating the traceability artefacts that auditors need at each design review gate. Sparx EA’s baseline management preserves certification snapshots at PDR, CDR, and First Flight configuration. EA GraphLink surfaces architecture and requirements closure status to programme dashboards, so programme managers understand where traceability gaps exist before they become certification findings.
What DO-178C Requires
The Standard and Its Scope
DO-178C (formally RTCA DO-178C, EUROCAE ED-12C) is the primary guidance document for FAA and EASA certification of software in airborne systems. It is not a mandatory standard in the sense of a regulation — the regulatory requirements for airborne software appear in FAR Part 25 (for transport category aircraft), FAR Part 23, CS-25, and related airworthiness standards — but in practice, DO-178C is the accepted means of compliance. Software in an airborne system cannot be certified without demonstrating compliance with DO-178C (or an alternative means of compliance agreed with the certification authority, which is rare).
DO-178C applies to any software that contributes to an aircraft-level safety function. This includes flight control computers, engine control units (FADEC), avionics display systems, navigation systems, communication systems, flight management systems, and the many embedded software components in modern Line Replaceable Units (LRUs). It does not apply to non-embedded software used in ground support or development tooling (though tool qualification — DO-330 — is a companion standard that addresses development tool certification).
Design Assurance Levels
DO-178C classifies software by the failure condition severity of the function it implements, following the system-level safety analysis conducted under ARP4754A:
| DAL | Failure Condition | Example |
|---|---|---|
| A | Catastrophic — loss of aircraft or lives | Primary flight control software |
| B | Hazardous — large safety margin reduction | Engine fuel control (FADEC) |
| C | Major — significant capability reduction | Autopilot engage/disengage |
| D | Minor — slight safety margin reduction | Cabin crew call system |
| E | No safety effect | In-flight entertainment |
DAL drives the rigour of objectives that must be satisfied. DAL A requires the most stringent coverage requirements (Modified Condition/Decision Coverage — MC/DC — at source code level), the most comprehensive reviews, and the most extensive independence requirements. DAL E requires no specific software lifecycle objectives.
What DO-178C Requires Architecturally
For DAL A and B software, DO-178C requires:
Requirements traceability: Every High-Level Requirement must trace to a System Requirement. Every Low-Level Requirement must trace to a High-Level Requirement. Source code must be traceable to Low-Level Requirements. Test cases must be traceable to Low-Level Requirements. This bidirectional traceability must be demonstrable to the DER (Designated Engineering Representative) and certification authority.
Software Architecture Documentation: A documented software architecture that shows how the software components are structured, how they communicate, how partitioning is implemented (especially for mixed-DAL systems using ARINC 653 partitioning), and how the architecture meets the High-Level Requirements.
Software Design Description: Detailed design documentation describing the low-level design of each software component — data structures, algorithms, inter-module interfaces — traceable to Low-Level Requirements.
Verification evidence: Test results, reviews, and analyses that demonstrate the software meets its requirements at each level of the hierarchy, with the required structural coverage.
Sparx EA Approach to DO-178C Architecture
Requirements Hierarchy
The DO-178C requirements hierarchy in Sparx EA is implemented as a nested Requirements package:
“ Software Requirements ├── System Requirements (SRS level — from ARP4754A system analysis) │ ├── High-Level Requirements (HLR — from SW Requirements Analysis) │ │ ├── Low-Level Requirements (LLR — from SW Design) │ │ │ └── Source Code Design Notes (design-to-code traceability) │ │ └── Software Architecture Requirements (architectural constraints) │ └── Derived Requirements (requirements not traced to system level) └── Safety Requirements (from system FHA/PSSA allocated to SW) “
Each requirement element carries tagged values for:
- DAL applicability: the design assurance level to which this requirement applies
- Verification method: Analysis / Review / Test (the verification method determines the DO-178C verification objective)
- Status: Draft / Under Review / Approved / Baselined
- Verification status: Open / In Progress / Complete / Passed / Failed
- Source: the parent requirement GUID or external document reference
Software Level Assignment on Components
Software components (modelled as UML Component elements or SysML Blocks) carry a software_level tagged value (A / B / C / D / E) assigned from the system safety analysis. This tagged value is the governance hook: architecture principles can require that DAL A components are implemented on partitioned hardware, that DAL A/B components have independence review, and that mixed-DAL software complies with ARINC 653 spatial and temporal partitioning requirements.
In a mixed-DAL system — for example, an integrated modular avionics (IMA) platform hosting DAL A flight control functions and DAL D utility management functions on shared hardware — the component DAL assignment also drives the partitioning architecture: which components share which ARINC 653 partitions, what memory and time budgets each partition carries, and how inter-partition communication is managed through the health monitoring layer.
Software Design Description Artefacts
The Software Design Description (SDD) in DO-178C terms describes the detailed design of software components: the data structures they use, the algorithms they implement, the inter-module interfaces through which they communicate, and the design decisions that realise the Low-Level Requirements. In Sparx EA, SDD artefacts are produced by:
- UML Class Diagrams: capturing the data structures (classes, attributes, relationships) used by each software component
- UML Sequence Diagrams: capturing the control flow and inter-module communication for key scenarios
- UML Activity Diagrams: capturing algorithm logic for computationally complex requirements
- Interface Specification elements: capturing the inter-module interface contracts (function signatures, message formats, timing constraints)
These elements are linked to the Low-Level Requirements they realise, creating the design-to-requirement traceability that DO-178C requires at the SDD stage.
SysML for Avionics Systems Architecture
Block Definition Diagrams for Avionic System Structure
At the system level (prior to the software partition), SysML Block Definition Diagrams (BDD) capture the avionic system structure from aircraft level down to the LRU and module level:
“ Aircraft [System Block] └── Avionics System [System Block] ├── Flight Management System [Block — DAL B] ├── Flight Control Computer [Block — DAL A] │ ├── Primary Flight Control Software [Block — DAL A] │ └── Flight Control Monitor Software [Block — DAL A] ├── Display Management System [Block — DAL C] └── Communication Management Unit [Block — DAL D] “
This BDD structure directly supports the ARP4754A system architecture documentation and provides the context within which DO-178C software requirements are allocated.
Internal Block Diagrams for Interface Control
Internal Block Diagrams (IBD) capture the interface control information between avionics system blocks: ARINC 429 bus connections between LRUs, ARINC 664 (AFDX) network connections in modern IMA architectures, MIL-STD-1553 bus interfaces in military avionics, and discrete signal interfaces. Each interface port on an IBD carries tagged values for the bus type, data rate, word encoding, and the interface control document reference.
For DO-178C purposes, the IBD interface definitions become the input to the software interface specification — the external interfaces that the software must implement, test at integration level, and verify against.
SysML Requirements Diagrams for DO-178C Traceability
SysML Requirements Diagrams in Sparx EA provide a visual representation of the requirements hierarchy and the traceability relationships between requirements and the system/software elements that satisfy them. A requirements diagram showing a High-Level Requirement with satisfy relationships to the software component blocks that implement it, and derive relationships to the System Requirements it traces to, is both an architecture artefact and direct DO-178C traceability evidence.
Generating DAL Evidence in Sparx EA
Traceability Matrices from Relationship Matrix
Sparx EA’s Relationship Matrix generates the bidirectional traceability matrices that DO-178C requires. The matrix is configured to show, for example, all LLR elements in the rows and all source code design notes in the columns, with cells populated where a satisfy or realise relationship exists. A complete matrix with all cells populated indicates full traceability coverage; empty rows or columns identify traceability gaps.
These matrices are directly useful as DAL evidence artefacts: they are generated from the live repository (not assembled manually), they reflect the current model state, and they can be regenerated at any point to show the traceability status at a specific baseline.
Requirements Coverage Reports
Sparx EA’s reporting capability generates requirements coverage reports that show, for each requirement in the hierarchy, its verification method, verification status, and the traceability completeness of its child requirements. These reports are run against a baselined repository version to produce the stage-of-involvement evidence required at PDR (all HLRs allocated, SDD initiated) and CDR (all LLRs complete, SDD approved, test cases written).
Baseline Management for Certification Snapshots
DO-178C requires that the software lifecycle data — requirements, design, code, tests, reviews — is placed under configuration management, with baselines created at key programme gates. Sparx EA’s baseline management functionality creates an immutable snapshot of the repository at a named point — PDR Baseline, CDR Baseline, First Article Configuration — that can be retrieved and compared. The baseline captures the complete requirements hierarchy, component structure, and traceability relationships as they existed at the gate, providing the configuration management evidence that DO-178C and the Software Configuration Management Plan require.
FAQ
What is DO-178C and which software does it apply to?
DO-178C (RTCA DO-178C / EUROCAE ED-12C) is the guidance document for software in airborne systems and equipment certification, published in 2011 as the successor to DO-178B. It applies to any software that contributes to an aircraft-level safety function — flight controls, engine controls, navigation, communication, avionics display systems, and embedded software in Line Replaceable Units. It does not apply to non-safety-affecting software or ground support software (though companion standard DO-330 addresses development tool qualification). DO-178C is not itself a regulation, but the FAA and EASA accept it as the primary means of compliance for airborne software — in practice, no airborne software is certified without DO-178C compliance.
What are Design Assurance Levels and how are they assigned?
Design Assurance Levels (DAL A through E) are assigned to software based on the severity of the failure condition that would result if the software failed to function correctly. DAL assignment flows from the system-level safety analysis conducted under ARP4754A: the system Functional Hazard Assessment (FHA) identifies failure conditions and their severity; the Preliminary System Safety Assessment (PSSA) allocates safety requirements to software components; and the allocated failure condition severity determines the DAL. DAL A (catastrophic — loss of aircraft) requires the most stringent objectives including MC/DC structural coverage. DAL B (hazardous) and C (major) have progressively lighter requirements. DAL D (minor) and E (no safety effect) have minimal or no software lifecycle objectives. In Sparx EA, DAL is a tagged value on software component elements.
How does Sparx EA support DO-178C requirements traceability?
Sparx EA implements the DO-178C requirements hierarchy as nested Requirements packages: System Requirements → High-Level Requirements → Low-Level Requirements → Source Code Design Notes. Traceability relationships between these levels are modelled using realise and derive relationships in UML. The Relationship Matrix generates the bidirectional traceability matrices that DO-178C requires — showing which LLRs trace to which HLRs, which HLRs trace to which System Requirements, and which test cases cover which LLRs. These matrices are generated directly from the live repository at any programme gate and can be produced against a baseline snapshot to show the traceability state at PDR or CDR.
What is the difference between HLR and LLR in DO-178C terms?
High-Level Requirements (HLR) describe what the software must do — the functional and performance requirements from the system level that the software is responsible for implementing. They are written at a level that does not prescribe software design decisions. Low-Level Requirements (LLR) describe the software in sufficient detail to code and verify without design decisions remaining — they describe how the software implements the HLRs, including data structures, algorithms, and interface specifications. The distinction matters for DO-178C because HLRs drive software architecture and are verified by system testing, while LLRs drive detailed design and are verified by software testing with structural coverage measurement. In Sparx EA, this distinction is implemented by nesting LLR elements under HLR elements in the requirements package hierarchy.
How does Sparx EA handle ARINC 653 partitioning for mixed-DAL systems?
ARINC 653 partitioning — the spatial and temporal partitioning mechanism used in Integrated Modular Avionics (IMA) to host multiple DAL software components on shared hardware — is modelled in Sparx EA by creating Partition elements linked to their hosted software components. Each Partition carries tagged values for memory budget, time budget (major frame and minor frame allocation), and the hosted component DALs. Inter-partition communication channels (APEX ports — sampling ports and queuing ports) are modelled as interfaces between Partition elements. The partitioning model supports DO-178C and DO-297 (IMA Development Guidance) evidence requirements: demonstrating that the partition boundaries prevent failures in lower-DAL software from affecting higher-DAL software.
What SysML diagrams are most useful for DO-178C avionics architecture?
Three SysML diagram types are most directly useful for DO-178C avionics architecture: Block Definition Diagrams (BDD) for capturing the system decomposition from aircraft level to software component level, with DAL assigned to each block — this is the system structure documentation required by ARP4754A and referenced by DO-178C. Internal Block Diagrams (IBD) for capturing the interface control documentation between avionics systems and between software components — defining the external interfaces that software must implement and test. Requirements Diagrams for visual representation of the requirements hierarchy and satisfy/derive relationships between requirements and system blocks — directly supporting DO-178C traceability evidence. Sequence Diagrams are also valuable for capturing the inter-component interaction scenarios that drive integration test design.
How does Sparx EA’s baseline management support DO-178C configuration management?
DO-178C requires that software lifecycle data — requirements, design, code, and tests — is placed under configuration management with baselines created at programme gates. Sparx EA’s baseline management creates immutable repository snapshots at named configuration points: PDR Baseline, CDR Baseline, First Article Configuration. Each baseline captures the complete requirements hierarchy, component structure, and traceability relationships. The baseline can be retrieved and compared against later states to identify what changed between programme gates — directly supporting the DO-178C configuration management and problem reporting requirements. The baseline also serves as the configuration identification evidence that the Software Configuration Management Plan references.
What is the recommended Sparx Services engagement for avionics architecture programmes?
For avionics programmes, the recommended engagement is Amplify — the avionics architecture practice engagement — combined with Platform Support for ongoing programme delivery. Amplify establishes the DO-178C compliant repository structure: requirements hierarchy, DAL tagged values, SysML modelling conventions, and the traceability matrix templates. Platform Support provides ongoing Sparx EA expertise embedded in the programme team — managing the repository through PDR, CDR, and certification baseline gates. For programmes beginning their EA and MBSE journey, a Discover engagement first assesses the current documentation landscape and DO-178C compliance readiness. Contact Sparx Services for a scoped estimate based on your programme phase, DAL profile, and repository starting point.
Next Step: Establish Your Avionics Architecture Repository
DO-178C traceability is not a documentation problem — it is a repository governance problem. The programmes that struggle at certification review are the ones that assembled traceability evidence manually from disconnected documents rather than generating it from a governed model.
An Amplify engagement from Sparx Services establishes the DO-178C compliant Sparx EA repository for your programme, with Platform Support available for ongoing programme delivery through certification gates.
Talk to Sparx Services about avionics architecture support
Amplify engagements start at $45K. Platform Support is available from $30K for ongoing programme repository management.
