MBD under DO-331

Model-Based Development has become a cornerstone of modern avionics software engineering. As systems grow more complex, traditional code-centric development struggles to provide sufficient abstraction, traceability, and early validation. For this reason, DO-178C introduced DO-331 as a dedicated supplement to address Model-Based Development, commonly referred to as MBD. This article explainsMBD under DO-331by focusing on its objectives, lifecycle integration, compliance expectations, and certification impact. The goal is to clarify how models can serve as development and verification artifacts while still satisfying rigorous airborne software assurance requirements.

Purpose of DO-331 in the DO-178C Framework

DO-331 exists to provide additional guidance for organizations that use models as primary development artifacts. Therefore, it does not replace DO-178C. Instead, it augments it.

DO-331 addresses:

• Use of models as requirements or design artifacts

• Automatic code generation from models

• Model-based verification and testing

• Additional verification objectives introduced by modeling

As a result, DO-331 ensures that MBD remains compatible with DO-178C objectives.

Section summary:
DO-331 supplements DO-178C to enable compliant model-based development.

What Model-Based Development Means in Avionics

Model-Based Development uses executable models to represent system behavior, logic, and interfaces. Consequently, models become central engineering artifacts rather than informal design aids.

In avionics, models may represent:

• Functional behavior

• Control laws

• State machines

• Data flow and timing

Therefore, MBD shifts emphasis from source code to higher-level abstractions.

Section summary:
MBD elevates models to first-class development artifacts.

Relationship Between DO-178C and DO-331

DO-178C defines software objectives independently of development technique. However, DO-331 explains how those objectives apply when models replace or supplement traditional artifacts.

Key relationship points include:

• DO-178C objectives remain mandatory

• DO-331 adds modeling-specific objectives

• Compliance depends on how models are used

Thus, DO-331 operates strictly within the DO-178C framework.

Section summary:
DO-331 extends DO-178C objectives to model-based workflows.

Model Roles Under DO-331

Models may assume different roles depending on the development approach. Therefore, DO-331 defines specific model categories.

Common model roles include:

• High-level requirements models

• Low-level design models

• Executable specification models

Each role determines applicable verification objectives and evidence expectations.

Section summary:
Model role determines verification rigor and certification impact.

Models as Requirements Under DO-331

When models replace textual requirements, they become requirements artifacts. Consequently, they must satisfy all DO-178C requirements-related objectives.

This includes:

• Completeness and correctness

• Unambiguity

• Traceability to system requirements

• Verifiability

Therefore, informal or ambiguous models cannot serve as requirements.

Section summary:
Requirements models must meet the same rigor as textual requirements.

Models as Design Artifacts

Models often represent low-level design from which code is generated. In this case, the model replaces traditional design descriptions.

Design models must:

• Accurately implement requirements

• Remain traceable

• Be verified for correctness

As a result, model quality directly affects software correctness.

Section summary:
Design models carry the same assurance burden as traditional low-level design.

Automatic Code Generation and Compliance

One of the main drivers for MBD is automatic code generation. However, generated code does not remove verification obligations.

DO-331 requires:

• Verification of the model

• Verification of generated code correctness

• Tool qualification for code generators

Therefore, trust shifts from manual coding to tool correctness.

Section summary:
Automatic code generation introduces additional assurance responsibilities.

Model Verification Objectives

DO-331 introduces explicit objectives for model verification. Therefore, organizations must verify models independently of generated code.

Model verification may include:

• Simulation and execution

• Model reviews and inspections

• Structural coverage of models

Model coverage complements code coverage rather than replacing it.

Section summary:
Model verification provides early and high-level assurance.

Verification Independence in MBD

Verification independence remains a key DO-178C concept. Consequently, DO-331 requires independent verification of models where applicable.

Independence considerations include:

• Separate modeling and verification roles

• Independent review authority

• Tool-based checks with qualified tools

Independence strengthens confidence in model correctness.

Section summary:
Independent model verification preserves objectivity.

Tool Qualification Under DO-331

MBD relies heavily on tools. Therefore, tool qualification becomes a central concern.

Tools subject to qualification may include:

• Modeling tools

• Code generators

• Model checkers

Tool classification depends on whether a tool can insert or mask errors.

Section summary:
Tool qualification ensures trust in automated MBD workflows.

Traceability in Model-Based Development

Traceability remains mandatory under DO-178C. Therefore, MBD workflows must support bidirectional traceability.

Traceability links include:

• System requirements to models

• Models to generated code

• Models and code to tests

Automated traceability tools often support this need.

Section summary:
Traceability ensures certification visibility across abstraction layers.

Structural Coverage Considerations

Structural coverage objectives still apply to generated code. Therefore, organizations must collect coverage data even in MBD workflows.

Coverage considerations include:

• Statement, decision, or MC/DC coverage

• Mapping coverage results to model elements

• Justifying gaps through analysis

MBD does not eliminate structural coverage requirements.

Section summary:
Coverage objectives remain mandatory despite higher abstraction.

Certification Authority Expectations

Authorities expect clear justification for using MBD. Therefore, applicants must explain modeling choices clearly.

Authority focus areas include:

• Model role definition

• Verification strategy

• Tool qualification evidence

• Traceability completeness

Clear explanations reduce certification risk.

Section summary:
Authorities assess clarity, rigor, and consistency in MBD application.

Common Pitfalls in MBD under DO-331

Organizations often encounter recurring challenges.

Common pitfalls include:

• Treating models as informal artifacts

• Inadequate tool qualification planning

• Weak traceability

• Overreliance on simulation

Addressing these pitfalls early improves outcomes.

Section summary:
Discipline and planning prevent MBD-related compliance issues.

Benefits of MBD When Applied Correctly

Despite added rigor, MBD offers significant advantages.

Key benefits include:

• Early validation through simulation

• Reduced manual coding errors

• Improved consistency and reuse

• Enhanced system understanding

Therefore, MBD supports both quality and efficiency.

Section summary:
Correctly applied MBD improves assurance and productivity.

Integration with DO-178C Lifecycle

MBD integrates into the standard DO-178C lifecycle rather than replacing it.

Integration points include:

• Planning documents

• Verification activities

• Configuration management

As a result, MBD becomes a compliant development variant.

Section summary:
DO-331 integrates MBD seamlessly into DO-178C processes.

Conclusion

MBD under DO-331 provides a structured and compliant framework for using models in airborne software development. By extending DO-178C objectives to cover modeling activities, DO-331 ensures that abstraction does not compromise safety or certification integrity. When models are treated as formal artifacts, verified independently, and supported by qualified tools, MBD delivers significant engineering and quality benefits. Ultimately, DO-331 enables innovation in avionics software development while preserving the rigorous assurance required for flight safety.