DO-178C and Avionics Software Architecture in Sparx EA

DO-178C traceability is not a documentation problem. It is a repository-governance problem — and the programs that struggle at certification review are the ones that assembled their evidence by hand from disconnected documents instead of generating it from a governed model.

DO-178C — Software Considerations in Airborne Systems and Equipment Certification — imposes rigorous traceability, documentation, and verification 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 that compliance: a requirements hierarchy from System through High-Level to Low-Level requirements, software level assigned as tagged values on components, SysML diagrams capturing system structure and interfaces, and a Relationship Matrix that generates the traceability artifacts auditors need at every gate. Baseline management preserves the certification snapshots at PDR, CDR, and first flight.

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 regulation in itself — the regulatory requirements for airborne software appear in FAR Part 25, FAR Part 23, CS-25, and related airworthiness standards — but in practice it is the accepted means of compliance. Software in an airborne system cannot be certified without demonstrating DO-178C compliance (or an alternative means agreed with the certification authority, which is rare).

It applies to any software that contributes to an aircraft-level safety function: flight control computers, engine control units (FADEC), avionics displays, navigation, communication, flight management, and the embedded software 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 addressing 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 rigor of objectives that must be satisfied. DAL A requires the most stringent coverage (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 bidirectional requirements traceability — every High-Level Requirement traces to a System Requirement, every Low-Level Requirement to a High-Level Requirement, source code to Low-Level Requirements, and test cases to Low-Level Requirements, all demonstrable to the Designated Engineering Representative and certification authority. It requires software architecture documentation showing how components are structured, communicate, and partition (especially for mixed-DAL systems using ARINC 653); a software design description detailing the low-level design traceable to Low-Level Requirements; and verification evidence — tests, reviews, and analyzes demonstrating the software meets its requirements at each level with the required structural coverage.

The Sparx EA approach to DO-178C architecture

Requirements hierarchy

The DO-178C requirements hierarchy is implemented in Sparx EA as a nested Requirements package:

Level	Source	Verified by
System Requirements (SRS)	ARP4754A system analysis	System integration test
High-Level Requirements (HLR)	Software Requirements Analysis	System / requirements-based test
Low-Level Requirements (LLR)	Software Design	Software test + structural coverage
Source Code Design Notes	Detailed design	Code review, design-to-code trace
Derived Requirements	Design decisions (no system parent)	Safety review for derived items

Each requirement element carries tagged values for DAL applicability, verification method (Analysis / Review / Test), status (Draft / Under Review / Approved / Baselined), verification status (Open / In Progress / Complete / Passed / Failed), and source (parent requirement GUID or external reference).

Software level assignment on components

Software components (modeled 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 is the governance hook: architecture principles can require that DAL A components run on partitioned hardware, that DAL A/B components have independence review, and that mixed-DAL software complies with ARINC 653 spatial and temporal partitioning. In a mixed-DAL system — say an Integrated Modular Avionics platform hosting DAL A flight control and DAL D utility management on shared hardware — the component DAL also drives the partitioning architecture: which components share which ARINC 653 partitions, what memory and time budgets each carries, and how inter-partition communication is managed.

Software design description artifacts

The Software Design Description (SDD) describes the detailed design of components — data structures, algorithms, inter-module interfaces, and the design decisions that realize the Low-Level Requirements. In Sparx EA, SDD artifacts are produced by:

• UML Class Diagrams capturing the data structures used by each component
• UML Sequence Diagrams capturing control flow and inter-module communication for key scenarios
• UML Activity Diagrams capturing algorithm logic for computationally complex requirements
• Interface Specification elements capturing inter-module contracts (function signatures, message formats, timing constraints)

These elements are linked to the Low-Level Requirements they realize, creating the design-to-requirement traceability 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 LRU and module level. A BDD might show the Avionics System decomposing into a Flight Management System (DAL B), a Flight Control Computer (DAL A) containing Primary Flight Control and Flight Control Monitor software (both DAL A), a Display Management System (DAL C), and a Communication Management Unit (DAL D). This 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 system blocks: ARINC 429 bus connections between LRUs, ARINC 664 (AFDX) network connections in modern IMA architectures, MIL-STD-1553 interfaces in military avionics, and discrete signals. Each interface port carries tagged values for bus type, data rate, word encoding, and the interface control document reference. For DO-178C purposes, the IBD definitions become the input to the software interface specification — the external interfaces the software must implement, test at integration level, and verify against.

Requirements Diagrams for traceability

SysML Requirements Diagrams provide a visual representation of the requirements hierarchy and the traceability relationships between requirements and the system or software elements that satisfy them. A diagram showing a High-Level Requirement with satisfy relationships to the component blocks that implement it, and derive relationships to the System Requirements it traces to, is both an architecture artifact and direct DO-178C traceability evidence.

Generating DAL evidence in Sparx EA

Traceability matrices from the Relationship Matrix

Sparx EA's Relationship Matrix generates the bidirectional traceability matrices DO-178C requires. Configure it to show, for example, all LLR elements in rows and all source-code design notes in columns, with cells populated where a satisfy or realize relationship exists. A complete matrix indicates full coverage; empty rows or columns identify gaps. These are useful directly as DAL evidence: they are generated from the live repository, reflect the current model state, and can be regenerated at any point to show the traceability status at a specific baseline.

Requirements coverage reports

Sparx EA's reporting generates requirements coverage reports showing, for each requirement, its verification method, verification status, and the traceability completeness of its child requirements. Run against a baselined repository version, these 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 software lifecycle data — requirements, design, code, tests, reviews — is placed under configuration management with baselines at key gates. Sparx EA's baseline management 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 as they existed at the gate, providing the configuration management evidence DO-178C and the Software Configuration Management Plan require. The same model can feed a program dashboard so managers see where traceability gaps exist before they become certification findings.

Frequently asked questions

Establish your avionics architecture repository

The programs that struggle at certification review are the ones that assembled traceability evidence manually from disconnected documents rather than generating it from a governed model. Configure the Solution from Sparx Services establishes the DO-178C-compliant Sparx EA repository for your program — requirements hierarchy, DAL tagged values, SysML conventions, and traceability matrix templates — with ongoing support available through certification gates. For programs beginning their EA and MBSE journey, Paralysis to a Plan first assesses the documentation landscape and compliance readiness. See why Sparx EA is the platform safety-critical programs standardize on.