Aviation & Defense Systems Development

ALM for Software Development in the Aviation, Aerospace & Defense Industries

Compliance with RTCA DO-178C (EUROCAE ED-12C) and DO-254

aviation-168x168 Aviation & Defense Systems Development

Avionics manufacturers increasingly rely on embedded software to enhance the functionality offered by their airborne products, thus creating value to their customers while avoiding adding further weight to their aircrafts. However, since human lives are dependent on the reliable functioning of airborne flight equipment, ensuring the safety and reliability of these products is of paramount importance for manufacturers and developers in the industry. To prove the airworthiness of civilian aircrafts and systems, compliance with DO-178C is necessary.

Aviation software is often created parallel to hardware and therefore, integration can occur late in the development lifecycle. Detecting and mitigating possible risks early on in the process, or better still: using development processes that help eliminate risks “on the fly” supports developers in maintaining absolute safety and quality, while saving costs and reducing their products’ time to market.

In the world of aviation, two terms sum up the difficulties associated with software development: “real-time” and “safety criticality”. These terms define how airborne application development is carried out to meet the rigorous requirements of Federal Aviation Administration (FAA), European Aviation Safety Agency (EASA) regulations, or those of other regulatory bodies. These regulations provide guidance to manufacturers in order to meet the Technical Standard Orders (TSO) requirements for certification.

Key to obtaining certification of airworthiness is the guidance (and de facto standard) that is known as DO-178B, and its updated version DO-178C (RTCA DO-178B and C, or EUROCAE ED-12B or C). In Europe, functional safety certification is supported by the CASS scheme to assess compliance with IEC 61508 and related standards.

RTCA/DO-254, titled Design Assurance Guidance for Airborne Electronic Hardware, is another important standard that provides guidance to the development of airborne electronic hardware systems. DO-254 can be regarded as a counterpart to DO-178C, and their combination aims to ensure the safety and reliability of avionics equipment containing both hardware and software components.

codebeamer-TÜV-trusted-tool-certification-336x336 Aviation & Defense Systems Development codeBeamer ALM has obtained TÜV “Trusted Tool” certification for supporting development in accordance with the requirements of IEC 61508 and ISO 26262. This qualification assures users of codeBeamer that the platform’s specific features are fit for use in development lifecycles requiring compliance with IEC 61508.

Intland’s Avionics DO-178C Template

The flexible architecture and advanced capabilities of codeBeamer ALM help you ensure and show gapless traceability throughout the development lifecycle, as well as facilitate compliance with DO-178B and DO-178C, as well as DO-254 and other relevant international safety standards. Intland’s Avionics DO-178C Template leverages codeBeamer’s advanced capabilities to support compliant processes, and to facilitate audits.

codeBeamer’s Features for Aviation, Aerospace & Defense Development

Aviation Requirements Management

Using Intland’s Avionics DO-178C Template, you can systematically manage initial and changing requirements for your software or hardware project. codeBeamer’s capabilities let you specify, organize and document your requirements, while the system also serves as a central information repository for requirements attributes, status information, and associations to tests, source code or regulatory documents. Requirements may be saved in libraries for re-use. To ensure data consistency and to support collaboration between both internal teams and 3rd party suppliers, a round-trip export-import feature is offered via MS Excel and MS Word.

Link Requirements to Tests and Derive Actionable Work Items

Clearly specifying your requirements is only the beginning of the work. codeBeamer will also help you connect actual feature requests, change requests, tasks, defects and test cases to the requirements captured. Both the requirements and the actionable work items can be organized into hierarchies in order to better model the problem domain.

Gapless End-to-end Traceability

Due to codeBeamer’s flexible data model and artifact linking capability, the whole lifecycle of your product can be precisely tracked from the requirement capturing phase through development and testing, all the way to release. A full change history is logged on all work items & may be browsed any time. A Traceability Browser helps visualize and overview the links between your artifacts, and lets you trace your requirements all the way through to the released product.

Aviation Quality Assurance & Test Management

codeBeamer’s QA & Testing functionality lets you define test cases, compose test sets, and execute tests on multiple hardware and software configurations. Parameterized testing is supported, and test may be saved into libraries for re-use. Associating tests with requirements and releases helps maintain complete traceability. Test result data drilling is supported, with coverage analysis (Test Coverage Browser) and customizable dashboards. Tests may be automated via codeBeamer’s Jenkins integration.

Regulations and Standards Compliance

codeBeamer’s wide range of security and process workflow features are designed to comply with regulations and standards defined by the FAA and EASA, which demand applying DO-178B or C (ED-12B or C in Europe) for the software development processes of airborne flight equipment (avionics software).

Security and Approval Workflows

Intland’s Avionics DO-178C Template provides project- and role-based security features, and preconfigured workflows to support compliance. Projects serve as secure working environments where access permissions can be set on different layers and granularity levels. Highly customizable workflows with optional electronic signatures for approval help ensure that important documents and specifications are reviewed before being published.

Best Practices and Repeatable Processes

codeBeamer’s customizable workflows and processes can easily be configured to support your company’s standard operating procedures. Workflows may be easily visualized, and conditional actions (triggered by certain events) as well as guards can be easily set. Repeatable processes ensure higher product quality, less errors and reduced project costs.


Using baselines lets you create lightweight snapshots of the entire set of specifications, including wiki pages, documents, images, attachments, comments, and all other types of artifacts & data. This is the primary means for versioning the states of the rapidly changing requirement specifications along their evolution. Baselines are optimal for comparing two states of documentation, identifying differences between two states for audit & certification purposes.

Configurable and Extendable Solution

codeBeamer is not a static platform: it is inherently flexible and configurable by providing configuration options for work item data types, workflows, etc. in a graphical user interface. Thus, the system adapts to your organization’s needs, and not the other way around. In addition to offering out-of-the-box integrations, using codeBeamer’s REST API (Application Programming Interface), the system can be easily extended beyond this configuration level, customized, and integrated with your own applications, third party tools and services.

Challenges of Standards Compliance in Aviation, Aerospace & Defense Development

Avionics Software Development Lifecycle processes include the planning process, the software development processes (requirements, design, code, and integration), and QA & integration processes (verification, configuration management, software quality assurance, and certification liaison). DO-178C defines objectives for each of these processes, and outlines a set of activities for meeting these objectives.

The guidance provided in DO-178C stipulates objectives that must be met for certification, but does not define how to meet the objectives in detail, except to mention iterative and incremental development as a means. Thus, finding the optimal way to meet these objectives is a challenge.

DO-178C defines 5 software levels based on how safety critical they are (from “No effect” to “Catastrophic”). The greater the safety criticality, the higher the number of objectives (and they entail different levels of documentation and review). All these objectives must be met in order to meet certification requirements. As with all safety critical software applications, the traceability of processes is a core requirement, and is assessed along with operational requirements, test methods and architecture as well as the code quality before certification is granted. The final product must be tested in flight.

As the hardware counterpart of DO-178C, the standard DO-254 deals with hardware considerations, thus taking into consideration the fact that airborne embedded systems contain both hardware and software components, and they could be equally important in ensuring the safety and reliability of these systems. DO-254 defines five levels of compliance from A to E, depending on the severity of failures (the likely effects a failure would produce, ranging from issues not affecting the safety of the aircraft to potentially catastrophic)./p>

Overview of Related Standards

RTCA DO-178B or C / EUROCAE ED-12B or C – Software Considerations in Airborne Systems and Equipment Certification

The set of requirements widely referred to as DO-178B is actually known as both RTCA DO-178B and EUROCAE ED-12B; these are similar guidelines published under different names in the US and in Europe. In 2011, the standard has been revised and published as DO-178C (RTCA DO-178C and EUROCAE ED-12C) with updates and adjustments to its previous version.

It’s important to note that DO-178C is not a standard per se. It’s a set of guidelines on how to carry out the planning, development and verification of safety-critical airborne software. It encompasses software considerations around planning, development process output, verification and quality assurance as well as configuration management in the development of aviation software. DO-178B was not intended to be prescriptive, and thus there may be several possible and acceptable ways to comply with its requirements.

DO-178B provides the following safety criticality levels:

  • Level A – Catastrophic: prevent continued safe flight or landing
  • Level B – Hazardous/Severe-Major: potential fatal injuries to a small number of occupants
  • Level C – Major: impairs crew efficiency, discomfort or possible injuries to occupants
  • Level D – Minor: reduced aircraft safety margins, but well within crew capabilities
  • Level E – No Effect: does not effect the safety of the aircraft at all

For each level, the guidance provides a series of objectives for the various software lifecycle processes and a series of tasks to be carried out to meet aforementioned objectives along with the evidence or artifacts necessary for proving the achievement of these objectives. However, DO-178C alone is not sufficient to guarantee software safety and was / is not intended to be used in isolation, but rather in conjunction with, for instance, IEEE STD-1228-1994 software safety plans, and other standards & regulations.

Emphasis is placed upon demonstrating that the software meets requirements, and the verification of this fact. This is why, during the verification process, testing must be based upon the requirements. The safety analysis is carried out as part of the application lifecycle.

Intland’s Avionics DO-178C Template supports compliance with DO-178C by defining and executing set processes across all product development lifecycle artifacts. Requirements-based development, independent verification, gapless end-to-end traceability, as well as a strong emphasis on change and software configuration management enable teams to implement repeatable processes and provide accurate audit trails.

RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware

As the hardware counterpart of DO-178C, DO-254 addresses considerations of hardware design assurance in airborne electronic hardware products. It aims to ensure the safe and dependable operation of such complex electronic hardware devices, and thus, that of aircrafts.

DO-254 sets forth five levels of compliance based on the severity of risks posed by the failure of the hardware products in question. Ranging from “no effect on the aircraft’s safety” to “catastrophic”, these levels require different levels of verification and validation.

Primarily, the standard requires developers of airborne equipment to capture requirements adequately, and track them through the design and verification process. Essentially, the following documents (to be submitted to the FAA) outline the process to be followed:

  • Plan for Hardware Aspects of Certification (PHAC)
  • Hardware Verification Plan (HVP)
  • Top-Level Drawing
  • Hardware Accomplishment Summary (HAS)

In a nutshell, DO-254 aims to ensure that developers are designing the right system, and designing the system right, thus ensuring the safety and dependability of avionics products.