DO-331 and IBM ELM: Navigating Model-Based Avionics Development

Modern aircraft are increasingly defined by software. Flight control logic, cockpit behavior, autonomous functions, propulsion control, and safety-monitoring features are often designed and tested long before they reach physical hardware. For many avionics teams, the model is no longer just a design illustration. It becomes an executable engineering artifact that influences requirements, behavior, verification, and sometimes generated source code. 

This creates a certification question: if a model helps define or verify safety-critical software, how does the project prove that the model and its outputs are trustworthy?

DO-331 answers that question. It is the model-based development and verification supplement to DO-178C and DO-278A. DO-331 does not replace DO-178C. Instead, it adds guidance for projects that use models, model simulation, model-based verification, or automatic code generation as part of the airborne software lifecycle.

DO-331 explains how certification activities should address model-based development and model-based verification. In Europe, the related EUROCAE designation is commonly referenced as ED-218. The practical purpose is straightforward: when models become part of the development or verification record, they must be controlled, reviewed, traced, and verified with the same seriousness as other certification-relevant lifecycle data. 

A DO-331 program may use executable models, behavioral models, state machines, control algorithms, interface definitions, simulation environments, model-based test cases, and code-generation workflows. The standard helps teams understand what additional evidence is needed when these assets are used to support DO-178C or DO-278A objectives.

Traditional DO-178C thinking often starts with written requirements, proceeds to manually written source code, and then verifies the resulting software. Model-based development changes that sequence. Teams can describe behavior in executable models, simulate logic before implementation, test state transitions early, and generate code from a verified model. 

This approach can help engineering teams find design issues earlier, test behavior before hardware is available, and maintain a clearer view of complex system logic. At the same time, certification evidence becomes more complicated. The project must show that the model correctly represents the intended behavior, that model-level verification is meaningful, that generated code preserves the model semantics, and that each lifecycle artifact remains traceable. 

DO-331 was created to bring structure to this shift. It gives teams a way to use modern model-based practices while preserving the predictability, reviewability, configuration control, and audit trail expected in aviation software certification.

In a model-based avionics workflow, the model can become a central lifecycle artifact rather than a supporting diagram. A behavior model may define how a system responds to inputs, state changes, failures, timing constraints, and interface conditions. Because the model can be executed or simulated, teams can evaluate behavior before implementation reaches source code. 

A typical DO-331-oriented workflow begins with system and software requirements, then translates those requirements into behavioral or architectural models. The team simulates the model, verifies model behavior, generates or implements code, performs integration and verification activities, and maintains the resulting evidence for certification review. The important point is continuity: requirements, model elements, verification results, generated code, and problem reports must remain connected throughout the lifecycle.

Model-based verification allows teams to test behavior earlier than they could in a traditional code-first workflow. Instead of waiting until source code and hardware are ready, engineers can simulate operating conditions, review state transitions, introduce fault scenarios, and observe timing behavior inside the model environment. 

This does not remove the need for later verification. It changes where some verification value appears. Early model-level checks can reveal misunderstandings, interface issues, unreachable logic, unsafe transitions, or timing assumptions before they become expensive implementation defects. Under DO-331, those activities must be planned, controlled, and linked to the relevant requirements and evidence records.

Ready to Strengthen Your Model-Based Avionics Process?

Automatic code generation is one of the most important reasons DO-331 matters. If a project generates source code from a model, certification teams must understand the relationship between the model and the generated code. They need confidence that the code accurately preserves the intended behavior and that the generator is used within defined assumptions and constraints. 

Tools such as IBM Rhapsody, MathWorks Simulink, Ansys SCADE, and dSPACE TargetLink may appear in model-based engineering or code-generation discussions. The compliance question is not whether a tool is popular. The question is how the tool is used in a specific project, whether generated outputs are independently verified, and whether tool qualification under DO-330 becomes relevant.

DO-178C remains the core software certification framework. DO-331 adds model-specific considerations, but the underlying expectations still apply. Requirements traceability, verification completeness, configuration management, quality assurance, change control, and Development Assurance Level considerations remain part of the certification picture. 

The main difference is how models are treated. Under DO-331, models may be more than supporting documentation. They may become requirements, design artifacts, verification artifacts, or sources for generated code. That means the project must prove that model content is correct, traceable, reviewed, controlled, and consistent with downstream implementation and test evidence.

Traceability is one of the hardest parts of model-based certification work. A project needs bidirectional links from system and software requirements to model elements, from model elements to generated code or implementation artifacts, from requirements to verification cases, and from verification execution to results and problem reports. 

This is where a connected lifecycle platform becomes valuable. If links are maintained manually across spreadsheets, documents, models, and test folders, the qualification and certification story becomes fragile. A change in one model element can affect requirements, tests, generated code, review evidence, and configuration baselines. Teams need a way to see those relationships clearly.

IBM Engineering Lifecycle Management can help teams manage the evidence chain behind a DO-331 workflow. IBM DOORS Next can capture requirements and maintain bidirectional traceability. IBM Rhapsody can support model-based systems and software engineering with executable behavior, SysML/UML modeling, simulation, and architecture work. 

IBM Rhapsody Model Manager can help teams host, manage, and link Rhapsody models in a collaborative lifecycle environment. IBM Engineering Test Management can organize model-level and software-level test planning, test cases, execution records, and results. IBM Engineering Workflow Management can support change control, task ownership, approvals, defects, and configuration workflows. IBM Engineering Lifecycle Optimization Method Composer can help process owners document and deploy consistent engineering methods, which is especially useful when teams need to turn abstract standard expectations into repeatable project activities. 

Softacus can frame its role around configuring this environment so the evidence is easier to create, connect, review, and maintain. The article should not claim that IBM ELM automatically makes a project compliant. A stronger and safer claim is that a well-configured IBM ELM environment can support the traceability, governance, and evidence management needed for a DO-331 certification argument.

For teams using model-based development under DO-331 expectations, the challenge is not only creating models. The harder challenge is proving how those models connect to requirements, verification activities, generated or implemented code, configuration baselines, change records, and certification evidence. 

Softacus can also help define IBM Engineering Workflow Management processes for model changes, approvals, issue handling, configuration control, and problem reporting. This matters because a small model update can affect requirements, test cases, generated code, safety assumptions, and review records. A well-designed workflow helps teams see what changed, who approved it, which evidence is affected, and whether the lifecycle record is still complete. The commercial value should be framed carefully. Teams gain clearer visibility into model traceability, test coverage, open issues, baseline readiness, and the evidence needed to support a DO-331 certification argument. 

For organizations adopting IBM ELM in safety-critical environments, Softacus can pair the technical configuration with dashboards, reporting views, training, and advisory support. That helps engineering, quality, and certification stakeholders work from one shared process instead of maintaining separate documents, model files, test exports, and review notes.

DO-331 is the bridge between traditional DO-178C certification thinking and model-based avionics engineering. It helps teams use executable models, simulation, model-based verification, and automatic code generation without losing the discipline required for certification. 

For aerospace and defense teams, the real challenge is not only building better models. It is maintaining a clear line from requirements to model behavior, verification evidence, generated or implemented code, configuration baselines, and certification review records. IBM ELM can support that connected lifecycle, and Softacus can help teams configure it in a way that is practical, auditable, and easier to maintain.