Graphic showing a car driving on a road and an airplane taking off, connected by the MXAM logo. It represents model-based development that meets automotive and avionics requirements alike.
Image: DO-178C and DO-331: MXAM Now Supports Automotive and Aerospace Standards

For model-based development teams, DO-178C and DO-331 are not just aerospace standards to be aware of. They can influence how models are developed, verified, documented, and used as part of a certification-oriented software lifecycle.

Teams developing safety-critical software in the automotive industry are often familiar with ISO 26262, the international standard for functional safety of electrical and electronic systems in road vehicles. In this environment, requirements, traceability, verification evidence, modeling guidelines, and tool-supported quality checks are already part of daily engineering work. When these teams move toward aerospace software development, many of these engineering principles remain relevant. But the quality assurance context changes. Airborne software development follows a different set of expectations, with a stronger focus on software assurance, verification evidence, and certification-oriented lifecycle data.

This creates a practical challenge: model-based teams may already have mature engineering practices, but they need to understand how these practices fit into the aviation-specific context of DO-178C and DO-331.

The following sections explain what these standards cover, how they relate to familiar ISO 26262 concepts, and why standards mapping can help connect high-level assurance objectives to concrete model-based development activities.

What Are DO-178C and DO-331?

DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is the core guidance document for airborne software development assurance. The current version, DO-178C, was published in 2011 and is referenced for use by the FAA’s Advisory Circular AC 20-115D. Rather than focusing on one specific implementation method, DO-178C provides a framework for developing and verifying airborne software in a structured and evidence-based way.

DO-331 is the Model-Based Development and Verification Supplement to DO-178C and DO-278A. It is a supplemental document for projects in which model-based development or model-based verification is part of the software lifecycle.

For model-based development teams, DO-331 helps answer questions such as:

  • How should models be developed and verified?
  • How can models support software development activities?
  • How should model-based development and verification be integrated into the software lifecycle?
  • What kind of model-related evidence may be relevant for certification-oriented workflows?

In short, DO-178C defines the software assurance objectives, while DO-331 explains how these objectives can be interpreted when model-based development becomes part of the software lifecycle.

DO-331 should not be treated as a standalone standard but should be applied together with DO-178C or DO-278A when model-based development or verification techniques are used.

ISO 26262 and DO-178C are related because both address safety-critical software development, but they apply to different industries and follow different quality assurance approaches. ISO 26262 is rooted in automotive functional safety. It focuses on safety-related electrical and electronic systems in road vehicles and uses Automotive Safety Integrity Levels, or ASILs, to guide development activities. DO-178C, by contrast, is used in aviation software assurance. It focuses on certification-oriented objectives for airborne software, with assurance expectations depending on software criticality. For model-based teams, model-based development and verification are explicitly addressed through DO-331, the model-based supplement to DO-178C.

Although both standards address model-based development activities, they are not interchangeable. However, engineering concepts familiar to automotive teams through ISO 26262 can be useful in an aerospace context.

The table below summarizes the main differences:

Topic ISO 26262 DO-178C
Industry Automotive Aerospace / aviation
Main scope Functional safety of E/E systems in road vehicles Software assurance for airborne systems
Assurance logic Risk-based safety lifecycle with ASIL classification Certification-oriented objectives based on software criticality
Model-based development Can be used as part of the development process Explicitly addressed through DO-331
Main output Safety argumentation, evidence, and work products Certification evidence, verification results, and assurance data

Although there are differences, engineering concepts that are already familiar to automotive model-based teams working with ISO 26262 can become useful when entering an aerospace assurance context.

Despite the differences between the standards, they share also several similarities:

  • Requirements: Safety-critical development depends on clear and verifiable requirements.
  • Traceability: Development artifacts must be connected and understandable across the lifecycle.
  • Verification: Evidence is needed to show that the implementation meets defined requirements.
  • Guideline-based development: Consistent modeling and development rules help reduce ambiguity and errors.
  • Tool-supported processes: Automation supports repeatability, consistency, and efficiency.

These similarities are especially relevant for organizations already using model-based development. Many concepts known from ISO 26262-oriented environments, such as traceability, verification automation, and guideline-based modeling, also play an important role in aviation software development. The difference is that, in the DO-178C and DO-331 context, these practices need to be connected more explicitly to certification-oriented objectives and evidence.

What Does Mapping Mean in the Context of Standards?

In the context of model-based development, standards mapping means connecting high-level assurance objectives from standards such as DO-178C and DO-331 with concrete engineering activities, modeling guidelines, verification methods, and model checks. DO-178C and DO-331 describe what needs to be achieved to support airborne software assurance. However, engineering teams still need to decide how these objectives are addressed in their specific development workflow.

This creates a practical challenge: which modeling guideline, verification activity, or model check supports which standard objective?

In simplified form, mapping acts as a translation layer:

Standard objective ➡️ Engineering interpretation ➡️ Modeling or verification guideline ➡️ Model check ➡️ Verification result or evidence

For example, if a standard objective requires model-based artifacts to be traceable, consistent, and verifiable, the mapping can point to guideline categories such as requirements links, model structure, interface clarity, data flow, and reviewability. These guideline categories can then be assessed through concrete model checks.

This does not mean that mapping replaces certification judgment or project-specific assessment. Instead, it helps model-based development teams understand how their daily engineering activities can contribute to certification-oriented objectives.

For teams coming from ISO 26262-oriented development environments, this is especially useful: familiar practices such as traceability, guideline-based modeling, automated checks, and verification evidence can be connected more clearly to the aviation-specific context of DO-178C and DO-331.

How Can Model-Based Teams Apply These Standards?

Model-based teams can apply DO-178C and DO-331 more effectively by connecting certification-oriented objectives to concrete guideline sets, verification activities, and model checks.

Instead of interpreting standard documents only manually, engineers can work with structured topics, applicable guidelines, and automated checks. This reduces interpretation effort and supports more repeatable verification processes.

This is where structured standards mapping becomes useful in practice. Once certification-oriented objectives are connected to model-level topics, teams need a way to apply these topics consistently during development and verification.

This principle forms the basis of the MES Model Exminar® (MXAM)’s standards mapping approach, which is introduced in the next section.

How Does MXAM Support DO-178C and DO-331?

In a DO-178C and DO-331-oriented model-based development workflow, the practical challenge is not only understanding the standards. Teams also need to translate selected objectives into concrete model-level activities, such as modeling guidelines, consistency checks, traceability reviews, and verification evidence.

MXAM supports this model-level part of the workflow by helping teams assess models against defined guideline sets and automated checks. In the context of standards mapping, this means that standard-related topics can be connected more clearly to the modeling rules and checks used during development and verification.

For example, if a mapping identifies traceability, interface consistency, model structure, or reviewability as relevant topics, MXAM can help assess whether the model follows the corresponding guideline expectations. The result is not a certification decision, but structured feedback that engineering teams can use during model reviews, quality assurance, and verification preparation.

This distinction is important: MXAM does not replace certification planning, project-specific assessment, or coordination with certification authorities. DO-178C and DO-331 remain objective-driven frameworks, and project teams must define how applicable objectives are addressed in their specific lifecycle. The FAA also describes DO-178C as an acceptable means, but not the only means, of showing compliance for airborne software, and emphasizes that applicable objectives, activities, and lifecycle data must be addressed. Instead, MXAM can support teams by making the model assessment step more systematic and repeatable. It helps connect the language of standards mapping with concrete model checks, guideline results, and reviewable evidence at the model level.

In practice, this can help teams:

  • identify model-level guideline topics related to selected standard objectives,
  • apply modeling checks consistently across projects,
  • detect model quality issues earlier in the lifecycle,
  • document check results for review and verification activities,
  • create a clearer connection between engineering work and assurance-oriented evidence.

Modeling practices such as strong data typing can be verified through specific modeling guidelines, for example misra_slsf_002. In MXAM, these guidelines are additionally linked to relevant DO-178C and DO-331 objectives. This allows developers to see directly within the tool which certification objectives a particular guideline can help support.

This is how it looks in MXAM:

Screenshot of the MXAM interface showing the new DO-178C/DO-331 mapping information.
Image: Mapping of Do-178C and Do-331 Objectives in MXAM

This mapping is provided across the modeling guidelines available in MXAM and covers areas such as naming conventions, model configuration, defensive implementation techniques, data typing, and other model quality and verification aspects.

 

Need to apply DO-178C or DO-331 in a model-based workflow?

Conclusion

DO-178C and DO-331 are highly relevant for teams working with model-based development in aviation. While they differ from automotive standards such as ISO 26262, they share familiar engineering concepts such as requirements, traceability, verification, evidence, and guideline-based development.

For aerospace model-based development teams, DO-178C and DO-331 are not simply another set of standards. They represent a different assurance context in which familiar engineering practices must be connected to aviation-specific certification objectives. A structured alignment of these objectives with day-to-day development activities helps close this gap. High-level assurance objectives can be translated into concrete modeling guidelines, verification activities, model checks, and supporting evidence, making the expectations of DO-178C and DO-331 easier to interpret and apply in model-based development workflows.

MXAM supports this process by mapping aviation-specific assurance objectives with actionable model verification activities. For organizations extending established automotive model-based development practices into aviation software assurance, this provides a practical bridge between familiar engineering workflows and aerospace-specific certification expectations.

References

  • [ISO 26262] ISO 26262 ‘Road vehicles – Functional safety’. International standard, 2nd edition, ISO 2018
  • [Pan23] Panchal, P.; Hein, L.; Myschik, S.; Holzapfel, F.: A Systematic and Agile Approach to Developing DO-178C Compliant Model-Based Safety-Critical Software. Deutscher Luft- und Raumfahrtkongress 2023, published 2024. DOI: 10.25967/610224
  • [RTCA] RTCA: DO-178C: Software Considerations in Airborne Systems and Equipment Certification. RTCA, 2011. https://www.rtca.org/do-178/
  • [FAA] FAA: Airborne Software Development Assurance Using EUROCAE ED-12( ) and RTCA DO-178( ). 2017. https://www.faa.gov/documentLibrary/media/Advisory_Circular/AC_20-115D.pdf

Related Topics

This image is a thumbnail representing the Safety of the Intended Functionality (SOTIF) for Automotive Professionals training page.

Safety of the Intended Functionality (SOTIF) for Automotive Professionals

Training Details
This image is a thumbnail representing the webinar for the Top 10 Simulink Modeling Mistakes.

Top 10 Simulink Modeling Mistakes

Webinar Details
This image is a thumbnail used for the webinar MISRA Autocode and Beyond: Key Takeaways from the MISRA Conference 2026.

MISRA Autocode and Beyond: Key Takeaways from the MISRA Conference 2026

Webinar Details

Contact Us

This image shows Elena Bley.
Elena Bley
Senior Manager Webinars & Training

* Mandatory field

What is the sum of 2 and 4?