Making DO with Safety Standards

In the first of a two-part article, we look at the evolution of DO-178C and its influence on safety critical software

In 2023, Patrica Lustiq and Gill Ringland proposed the concept of Fractured Backbones. A backbone is an agreed set of rules which are shared and support the way that things work.

In today’s modern world, software is the digital backbone responsible for enabling a milieu of systems, from cash registers to satellites. Safety critical software is a class of software, often embedded in systems, where failures of the software can cause failures in systems that can result in damage to the system, environment, or property, as well as injury or loss of life of the people using these systems, or substantial financial and reputational damage.

As Gary Gilliland, Vice President of Marketing at DDC-I states, this type of software is developed and tested with the utmost care to prevent failures and manage or isolate failures in such a way as to protect the system.

Steve DiCamillo, Technical Marketing and Business Development Manager at LDRA adds that, “In practice, most functional safety standards specify the use of hazard analyses and system safety assessments to arrive at a level of criticality – from non-critical to catastrophic. The higher the level of criticality, the greater the reduction in system safety resulting from a software failure.”

Another dimension to the definition is added by Olivier Charrier, Principal Functional Safety Specialist at Wind River, who avers that software is just one component of the equation. “Usually, such equipment has been identified to have a risk of creating some aspect of harm, and as soon as an equipment is identified to be part of a harmful situation, then all the pieces of this equipment need to be reviewed against safety critical aspects,” he says. He argues you need both safety critical hardware and safety critical software, and “you need to do a safety critical integration of all of them together.”

According to Charrier two of the main reasons why there is a fracture in the digital backbone of software allowing accidents to occur are because either the wrong requirement was written into it or there is an integration issue.

“So, usually it’s because it’s not well written. So, if it’s not well written, it’s not well verified, and it can create a situation that can create an accident.”

That’s why safety standards keep improving, to try to help on this, he says.

Safety coded
“With increasing levels of criticality, functional safety standards generally require more rigorous processes, practices, activities, and engagement with regulatory agencies around the planning, development, and verification of software,” says DiCamillo.

“Safety criticality influences software development by imposing stringent requirements on the entire software lifecycle,” asserts Dr Benjamin Brosgol, a senior member of the technical staff at AdaCore. “This includes rigorous planning, meticulous design, comprehensive testing, and thorough verification and validation processes. Development methodologies for safety critical software often involve automated static analysis (including formal methods) and manual code reviews to ensure that the software behaves as intended under all circumstances.”

This software must be developed to safety standards that are prescribed for the industry, explains Gilliland. “In the case of aircraft avionics, the software development standard utilised is DO-178C (FAA) or ED-12C (EASA). These standards define a set of design assurance levels (DALs) from DAL-A for very critical safety requirements down to DAL-E systems which have no safety requirements. Additionally, for multi-core systems there sets of guidance in A(M)C 20-193 that systems must follow depending on the DAL requirements of the system. Depending on the safety criticality of the system there also may be redundancy in software as well as hardware.”

What’s in a name?
Rapita’s technical writer, Dr Daniel Wright claims that for safety critical software, the bar for required verification and quality assurance is much higher than for non-safety critical software, commensurate to the huge risk should the software fail.

“In the context of DO-178C, the level of this bar depends on the DAL of the software. This has an impact on all aspects of development, from selection of hardware, software languages, standards and architectural models, and tools, including verification tools, to quality assurance processes and verification, and even organisational structure of departments involved in development, verification and quality assurance.”

DO-178C, formally titled ‘Software Considerations in Airborne Systems and Equipment Certification,’ is a critical standard in the international aerospace industry. It provides guidelines for developing safety critical software in commercial airborne systems and is also being adopted for military systems. It defines the objectives, activities, and artefacts required to achieve confidence that the software used in aircraft systems is safe and reliable. The standard categorises software into different levels of criticality, known as Design Assurance Levels (DALs), ranging from A (most critical) to E (least critical). DO-178C ensures that the software life cycle processes include sufficient rigour to meet the safety requirements associated with each DAL, thereby reducing the risk of software-related failures in aircraft.

Gilliland provides further elucidation. “DO-178C defines a process for creating and documenting the software development lifecycle for safety critical systems. It starts with creating a set of requirements for the software that states what needs to be done such that there is no ambiguity. The software is developed, using best practices and coding standards, to meet the requirements that have been documented. Developers must show traceability from the software to the requirements.

“Test software is developed by a different set of engineers to verify that software correctly implements the requirement as stated. Along the way there are code reviews to check that coding standards and best practices are followed by independent reviewers. In addition, the certification authority will conduct audits at various stages of the program to ensure processes and procedures are in place and being followed.”

DO-178C includes a total of 114 objectives, and the objectives that should be met depend on the DAL of a software item, which is determined based on the level of risk should the software fail. While DO-178C prescribes objectives, it doesn’t prescribe how they should be met, and a range of approaches are taken by DO-178C applicants, though many similarities exist across organisations. A collection of supplementary guidance documents has been introduced since the publication of DO-178C to cover the use of new technologies or specific aspects of design assurance, for example tool qualification.

Developing a fix
As Lustig and Ringland promote, when Backbones work well, they provide the resilience needed to adapt to disruptions and threats. A Backbone will have been designed for a set of circumstances, but it needs monitoring and maintaining. When a Backbone fractures, rather than evolving to fit the needs, it becomes a disruption they argue.

The increased use of software in airborne systems, and safety of that software, prompted the creation of DO-178.

DO-178() was originally published in 1982 by the Radio Technical Commission for Aeronautics organisation (now known as RTCA, Inc.) in collaboration with EUROCAE. It is the core document for defining both design assurance and product assurance for airborne software. The objective is to ensure that the software performs its intended function with a level of confidence in safety that complies with airworthiness requirements. The guidelines provided specify objectives for software life-cycle compliance, a description of activities and design considerations for achieving those objectives, and a description of the evidence indicating that the objectives have been satisfied.

As DiCamillo expounds, DO-178 has been revised several times since then and has been joined by a series of supplements and guidance documents (DO-330, DO-331, DO-332, DO-333). He says that ongoing work around the development of DO-178C has focused on maintaining the safety and reliability of airborne software systems in the wake of further technological advances. Examples of resulting guidance include “AC 20-193, Multi-core Processors” and “AC 20-170A, Integrated Modular Avionics”.

Gilliland augments the overview further. “DO-178C defines a process for creating and documenting the software development lifecycle for safety critical systems. It starts with creating a set of requirements for the software that states what needs to be done such that there is no ambiguity. The software is developed, using best practices and coding standards, to meet the requirements that have been documented. Developers must show traceability from the software to the requirements. Test software is developed by a different set of engineers to verify that software correctly implements the requirement as stated. Along the way there are code reviews to check that coding standards and best practices are followed by independent reviewers. In addition, the certification authority will conduct audits at various stages of the program to ensure processes and procedures are in place and being followed.”

DiCamillo adds that the tables in DO-178C Annex A serve as a practical tool to summarise and clarify the objectives and activities described in the main body. These tables provide a structured way to ensure that all necessary steps are followed and documented – but they do not include the same level of detail.

DO-178C (and DO-278A) are part of a broader set of documents that provide a comprehensive avionics development and certification framework.

Keeping up with the times
In a paper presented to the 2012 American Institute of Aeronautics and Astronautics Infotech, Stephen A. Jacklin, an aerospace engineer at the NASA Ames Research Center, in Moffett Field, California, charted the background behind the release of DO-178C.

In 2005, the RTCA created special committee 205 (SC-205) to produce a revision of DO-178B to account for new software development and verification technologies that were deemed immature at the time DO178B was written. The new version, DO-178C “Software Considerations in Airborne Systems and Equipment Certification”, was released in December 2011. Rather than placing all of the new guidance in DO-178C, the special committee decided to place the vast majority of the new guidance in six other documents. These documents were released together with DO-178C.

They are:

• RTCA DO-278A3: Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems
• RTCA DO-248C4: Supporting Information for DO-178C and DO-278A
• RTCA DO-3305: Software Tool Qualification Considerations
• RTCA DO-3316: Model-Based Development and Verification Supplement to DO-178C and DO-278A
• RTCA DO-3327: Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A
• RTCA DO-3338: Formal Methods Supplement to DO-178C and DO-278A

As Amani Karchoud, Technical Product Marketing Manager at Sysgo summarises, DO-178C was developed to address advancements and lessons learned from applying DO-178B.

The differences fall into several categories noted in Appendix A of DO-178C. As well as describing the activities to perform towards the objectives throughout the sections, the major clarifications and improvements for Wright are planning content to cover outsourcing and supplier oversight; the impact of compiler, linker and hardware options on worst-case execution timing, considerations around deactivated or otherwise noncovered code; guidance for parameter data items; and tool qualification guidance including reference to DO-330.

On the latter point, Brosgol expands stating that, “The DO-330 companion standard to DO-178C introduces more rigorous guidelines for the use of software tools, expanding on the DO-178C distinction between verification and development tools. DO-330 is not specific to airborne systems and can be applied in other domains where code certification is required.”

To these improvements, Brosgol adds incorporated supplemental guidance. “DO-178C is supplemented by several documents that provide guidance on using modern technologies during the software life cycle for airborne software: DO-331 (Model-Based Development and Verification), DO-332 (Object-Oriented Technology and Related Techniques), and DO-333 (Formal Methods).”
Additionally, DO-178C provides fixes for known errata and clarification for known inconsistencies, providing consistent terminology, improvements in wording and clarity, clarifying the importance of activities and their related objectives, and clarification and specification of ‘hidden’ objectives, along with other general clarifications.

All about the journey
As Wright stresses, avionics software must be approved before it can be used in the field. “Signoff is required by a Designated Engineering Representative or similar, who is authorised to approve the software on behalf of the FAA or another certification authority (e.g. EASA for ED- 12C). Signoff can be based on demonstration that the software meets the appropriate DO-178C objectives, or it can be through alternative means of compliance. No safety critical software would make it anywhere near operational use without the appropriate signoff.”

The impetus to meet the objectives comes from regulatory requirements and industry best practices says Brosgol. Compliance is necessary to obtain certification from aviation authorities like the FAA in the US or EASA in Europe, without which an aircraft system cannot be legally operated in the airspace controlled by that authority. Additionally, adhering to these standards is a way for companies to demonstrate their commitment to safety and quality, thereby protecting their reputation and reducing liability.
“The main impetus for following these guidelines is to meet regulatory and certification requirements essential for market entry,” says Karchoud. “While prescriptive, these standards are universally recognised as best practices.”

The guidance in DO-178C provides a framework of processes, activities, and objectives to be met, but it does not specify the details of how those objectives are to be met – leaving that decision up to system and software development organisations, says DiCamillo.

Charrier picks up the point, stating that while at once DO-178C is mandatory in its perspective, ie, the objective, the way these objectives are realised is very agile and prospective. This agility can encourage the use of new techniques or the application of new technologies, but caveats Charrier, “there’s nothing preventing the use of new technology, but you need to be aware that it will take time, because you need to educate and discuss it with the authority” and explain how you use that new technology in the context of the objective.

But as DiCamillo warns, while alternative means of compliance are in theory possible and acceptable, the cost to develop them and provide adequate proof of their viability could be prohibitive.

Brosgol deems “prescriptive” not to be the right word in this conversation. “Although it specifies a number of software life cycle processes, DO-178C does not mandate specific ways to develop the software, and indeed, its guidance is not called “requirements” but rather “objectives.” So, in that sense, the standard is goal-based. In fact, it is possible (but not without some work) to take existing software and reverse engineer the artefacts that demonstrate compliance or to use alternative techniques to the ones documented in the standard”.

But admits Brosgol, the guidelines have limitations. “They might not accommodate the latest technological innovations or specific project needs, or they might lead to processes that do not directly contribute to achieving safety objectives, potentially leading to inefficiencies or increased costs.” To these limitations, Karchoud adds potential increased development time and cost. She stresses however, that they provide a framework that significantly mitigates risk of software failure.

Brosgol agrees. “Despite its limitations, the DO-178x series of standards has been successful in practice. It is strongly focused on the verification process, with the purpose of preventing the introduction of errors in airborne software. It achieves this by providing repeated opportunities to detect and eliminate defects before the software is fielded. There have been a very small number of aviation incidents where DO-178x-certified software has been identified as the cause.”

by Alex Preston