The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Automatically generated airborne code is not exempt from DO-178C verification. A project can claim certification credit for a code generator only to the extent that the generator is qualified for its intended use and project context. Otherwise, the project must perform the applicable source-code review, analysis and testing objectives as it would for conventionally developed code.
How DO-178C, DO-330 and DO-331 fit together
DO-178C sets the software lifecycle objectives and evidence expected for airborne software, according to the software level assigned from system safety considerations. DO-331 supplements DO-178C when model-based development and verification are used; it does not replace the underlying DO-178C objectives. DO-330 addresses software tool qualification. FAA AC 20-115D identifies these documents, along with DO-332 for object-oriented techniques and DO-333 for formal methods, as part of the relevant guidance family.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
The Next-Generation Aerospace Engineering Compendium: Master Aerodynamics, Propulsion, Flight... | $19.99 | Buy on Amazon |
EASA identifies ED-12C/DO-178C as an acceptable means of compliance and says applicants should satisfy the objectives associated with the assigned software level and produce the associated lifecycle data. Where the model is the basis for development, EASA says to apply ED-218/DO-331 guidance as well. The applicable objectives therefore depend on the project’s software level and development approach—not simply on whether a tool generated the source.
Verification workflow for generated airborne code
- Set the software level and applicable objectives. Establish the software level from the system safety process, then identify the applicable DO-178C objectives and any DO-331 model-based objectives.
- Build end-to-end traceability. Define how high-level requirements trace through model elements and low-level requirements to generated source and executable object code. Keep the links bidirectional enough to show both that requirements are implemented and that model or code elements have a requirement basis.
- Review the generated source and integration code. Check generated source against the design model and applicable coding standards. Analyze interfaces and any manually written integration code; generation does not establish that those parts are correct or compatible.
- Decide whether to claim tool credit. If the project intends to take certification credit for the generator against verification objectives, qualify it as a development tool for that intended use. Define the tool’s operational requirements and the model and configuration limits within which the qualification applies.
- Represent actual generator use in qualification evidence. Qualification test inputs should cover every library element used, combinations of those elements, applicable limits and permitted model complexity. Tool qualification must reflect the project’s operational environment, rather than an assumed generic setup.
- Generate and build the airborne baseline. Run the generator on the qualification inputs and produce executable object code using the same compiler, linker and selected options used for the airborne software baseline.
- Verify behavior and model-to-code consistency. Compare executable behavior against requirements and representative model inputs, and show that the generated code corresponds to the intended model. Qualification evidence should support the specific certification credit claimed.
- Plan and demonstrate structural coverage. State the intended coverage demonstration method in the Software Verification Plan. Demonstrate the coverage required for the assigned software level and resolve any gaps under the applicable DO-178 process.
- Retain the certification data. Preserve plans, tool operational requirements, qualification test cases and results, traceability, and configuration records as part of the project’s certification evidence.
What changes when the generator is unqualified?
An unqualified generator does not remove the project’s conventional verification obligations. EASA’s Certification Memorandum CM-SWCEH-002, in its discussion of ED-12B/DO-178B auto-coding, says that if the source-code generation tool is not qualified as a development tool, no certification credit is granted for using it against source-code verification objectives performed by review, analysis or test. The memo’s cited provisions refer to the earlier DO-178B framework; they explain the credit principle, while a current project should apply the DO-178C/DO-330 objectives and guidance relevant to its approval basis.
In practical terms, the team must still meet the applicable review, analysis and test objectives for source code. It also needs adequate traceability and coverage evidence. Tool qualification is not an alternative to all software verification: it supports credit only for objectives and uses that the qualification actually covers.
Manual coding, qualified generation and unqualified generation
| Development approach | Certification credit from the generator | Verification implications | Qualification and context |
|---|---|---|---|
| Manual coding | Not applicable; there is no code generator to claim credit for. | Perform applicable DO-178C objectives for requirements, source code, executable object code and structural coverage. | No generator qualification. Other tools used in the lifecycle may have their own qualification considerations. |
| Qualified auto-coding | Available only for the intended use and objectives supported by the qualification. | Verify model-to-code consistency and executable behavior, and meet applicable objectives not covered by tool credit. | Qualification inputs and configuration must reflect the project’s library use, model limits, generator, compiler/linker options and operational environment. |
| Unqualified auto-coding | No credit for source-code verification by review, analysis or test on the basis of using the generator, as described in EASA CM-SWCEH-002, section 23.2.10.7. | Perform the applicable conventional source-code review, analysis and test objectives, along with the other lifecycle verification objectives. | No generator qualification evidence supports certification credit; the project still needs the required verification records. |
What structural coverage means for generated code
Generated source and executable code remain subject to the structural-coverage objectives for the assigned software level. Coverage is not a single percentage that can be applied to every project: the applicable objectives depend on the software level and approval basis. The Software Verification Plan should identify how coverage will be demonstrated, and the project must disposition uncovered structures under its applicable DO-178 process.
EASA CM-SWCEH-002 sections 23.2.10.6–23.2.10.7 discuss auto-coding in the ED-12B/DO-178B context and connect tool qualification with structural-coverage credit. Because those quoted provisions cite the earlier framework, use them as context rather than substituting them for the objectives applicable to a DO-178C project.
Can you certify code generated from Simulink?
Potentially, but the fact that a model generates C code does not itself establish compliance or certification credit. The applicant must define the project’s model-based development approach under DO-331, meet the applicable DO-178C objectives, and support any claimed code-generator credit with tool qualification appropriate to the actual use. Qualification kits can provide artifacts, but they do not automatically qualify a customer’s particular installation or project configuration. MathWorks’ DO Qualification Kit FAQ makes the contextual point directly: “Tool qualification must be performed in the context of each specific project and operational environment.”
Recommended Free Tools
The approval question is therefore not just whether a particular generator has been qualified somewhere. It is whether the evidence covers the generator version and configuration, the models and libraries actually used, the target operational environment, and the certification credit being claimed.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
