DO-178C and Avionics Software Architecture in Sparx EA

DO-178C traceability is a repository-governance problem before it is a documentation problem. 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:

Design Assurance Levels

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 analyses 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:

Requirements hierarchy

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), and source (parent requirement GUID or external reference). Where the program keeps requirement status (Draft / Under Review / Approved / Baselined) and verification status (Open / In Progress / Complete / Passed / Failed) in a requirements-management or test-management tool, AI connects to it and relates each result to its requirement, so the model shows verification status without anyone re-keying test outcomes. The verification lead decides what counts as Passed and reviews what was connected, because it ends up in certification evidence.

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. Links that already exist in a requirements or test tool can be brought into the model by AI as proposed links. The software lead confirms each one, because an unreviewed link is a false claim of coverage.

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. Connected data enters a baseline only after it has been reviewed. The same model, with the connected test and review status, can feed a program dashboard in Prolaborate or Power BI so managers see where traceability gaps exist before they become certification findings.

What your architects can now get done

On a certification program, the architect sits between systems engineering, software, verification and the Designated Engineering Representative. The tools help with each job; the skill that decides the result is the architect’s.

Showing verification status at a gate

Today requirement status and test outcomes are copied from the requirements and test tools into the model, or into a spreadsheet, before each gate review.

AI-augmented, the architect says which requirements-management and test-management records are the source for each status, and what Passed and Complete mean, and AI connects to them and relates each result to its requirement in the model. The verification lead reviews the connected results before they enter a baseline.

The skill is defining the statuses precisely and reviewing the exceptions, because the results end up in certification evidence.

Tools that help: Claude + AI Power Tools, GitHub Copilot + AI Power Tools or Kernaro AI Hub.

Finding traceability gaps before the DER does

Today gaps are found by reading matrices row by row, or at the review itself.

AI-augmented, the architect states the coverage rule for each DAL (for example, every LLR traces to an HLR and a test) and asks the model for every requirement that breaks it.

The skill is writing the rule exactly as the objectives require, and judging each finding.

Tools that help: Kernaro AI Hub, Claude + AI Power Tools or GitHub Copilot + AI Power Tools.

Which tool helps depends on the job. Compare the AI options.

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. We teach your architects and systems engineers to build and run the model on your own repository: start at For Architects. Or we build and update it for you (requirements hierarchy, DAL tagged values, SysML conventions, and traceability matrix templates, connected to your requirements and test tools): what we build. Either way, the program dashboards land in Prolaborate or Power BI: Reporting and Power BI. For programs starting with EA and MBSE, Paralysis to a Plan first assesses the documentation landscape and compliance readiness. See why Sparx EA is the platform safety-critical programs standardize on.