Going for Gold
In the second of a two-part article, we continue our look at DO-178C, and the efforts behind compliance at every stage.
As was discussed in our previous article (‘Making Do with safety Standards’, Aerospace Innovations Q3 October) DO-178C was introduced to address several deficiencies and ambiguities in DO-178B. The revision primarily sought to enhance clarity, reflect modern software engineering practices, and provide better guidance on using advanced technologies without increasing the effort needed to demonstrate compliance.
The revision was necessary to align the standard with technological advancements and to address the evolving complexities in software development, ensuring that the standard remains relevant and effective in mitigating risks in safety-critical software.
According to Dr Daniel Wright, technical writer at Rapita, DO-178C is used not only in the context of civil avionics, but is often seen as the gold standard for safety-critical software verification in other contexts, and many of the principles of DO-178C are used by standards in other fields such as military avionics or space software.
“DO-178C and associated guidance acts as an appropriate safeguard to the release of novel, unproven technologies into commercial airspace, such as AI technologies. These technologies can offer huge benefits in many areas, but first and foremost, we need to make sure they’re used safely.”
As Dr Benjamin Brosgol, a senior member of the technical staff at AdaCore explains, “DO-178C is applied as part of an overall systems engineering effort; safety is a pervasive system-level property that needs to be addressed early.” Expounding, Brosgol says that as part of the system life processes, system requirements are specified and allocated to either software or hardware, and the software level (DAL) is determined. These requirements include functional requirements for ensuring correct operation, and safety requirements for preventing hazardous conditions. The requirements and associated DAL serve as input to the software life cycle processes defined in DO-178C.
DO-178C defines three kinds of software life cycle processes, which are performed concurrently: Software Planning Processes, Integral Processes (Software Verification, Configuration Management, Software Quality Assurance, Certification Liaison), and Software Development Processes (Software Requirements, Software Design, Software Coding, and Integration). An organisation complying with DO-178C needs to have a well-defined software production infrastructure in order to meet the objectives specified for these processes. “Effectively performing integral processes such as Configuration Management and Quality Assurance (QA) is critical,” Brosgol asserts.
Digital demands
“Most aviation system providers have been developing software to DO-178(A/B/C) for many years and have refined their processes in conjunction with the certification authorities designated engineering representatives (DERs) to meet their development needs,” states Gary Gilliland, VP of Marketing at DDC-I. “I believe the digitalisation of the design has prompted more use of model-based development and the use of simulation environments to design, build and test new systems. Utilising the guidance in DO-178C to certify these systems presents a challenge for the certification authorities to understand these new technologies and how the proof of the design is represented.”
With the increasing digitalisation of aviation—encompassing everything from design and manufacturing to operation and maintenance—the need for standards like DO-178C has grown.
Brosgol agrees that digitalisation introduces new complexities and a greater reliance on software, heightening the risks associated with software failures. “Adherence to DO-178C helps mitigate these risks by ensuring that digital systems are developed with the required attention to safety and reliability,” he says.
It’s a point of view upheld by Sysgo’s Technical Product Marketing Manager, Amani Karchoud. “The growing digitalisation in aviation heightens the need for such standards to ensure software integrity and reliability given the increased complexity and integration of digital systems in aircraft.”
To all intents and purposes, DO-178C is the codification of best software engineering practices for developing and verifying airborne systems. Its benefits are multitude and includes increasing the confidence in the safety, reliability, maintainability and traceability of airborne software, facilitating regulatory certification, and providing a transparent, structured approach to conducting the software life cycle processes. It helps organisations avoid the potentially catastrophic consequences of software failures, thereby protecting lives and reducing legal and financial liabilities.
A question of costs
Following DO-178C to realise these benefits does come with an increased cost of development, testing, and certification. However, as Steve DiCamillo, Technical Marketing and Business Development Manager at LDRA points out, this saves money in the long run by practically avoiding catastrophic failures resulting in loss of life, loss of equipment, and civil penalties.
While upfront costs are higher due to the stringent processes, these are often offset by the benefits of having highly reliable software in critical applications.
It’s an assessment shared by Brosgol, who adds that over the lifetime of an airborne system, adhering to DO-178C can reduce costs associated with fixing post-deployment issues, avoiding legal repercussions, and maintaining a solid industry reputation. He acknowledges that while compliance with DO-178C does add additional costs to software development — due to the rigorous processes, extensive documentation, and thorough verification required — these costs are justified by the high level of safety assurance that the standard provides.
Admitting that compliance adds additional costs to software development, Wright says this is commensurate with the importance that the software does not fail. More details are given by Gilliland.
“DO-178C processes do add additional costs to the software development process. This is really about the manpower required to guarantee the software does what it is supposed to do reliably. The development of detailed requirements, requirements-based test code, code reviews and verification with independent engineering groups is a significant effort especially for DAL A. The benefit of this process if done correctly, is that the software has very few defects and if defects are found the documentation, tests and traceability from requirements to code provide an easily understood explanation of the problem.”
Development goals
Companies work hard to accomplish the criteria of system requirements and system implementation conforming to these obligations. They typically establish robust development environments with strong quality assurance processes, use advanced tools for design and verification, and conduct extensive testing, says Karchoud, who adds that building the right product involves close collaboration with stakeholders, rigorous compliance to standards, and continuous feedback loops during the development process.
Rapita’s motto is safety through quality. The company develops its products, shares recommendations, and delivers training and engineering services, including process definition services, with DO-178C guidance firmly in mind. Wright says that while efficiency is a key motivating factor in its solutions, within the context of DO-178C solutions, safety is always the most critical factor.
Gilliland believes that DDC-I as a real-time operating system (RTOS) provider is in a unique position in the certification process. For example, the company’s Deos RTOS was first certified in a system in 1998 and is currently certified and flying in systems in over 10,000 aircraft.
“Deos was designed from the ground up to meet the safety and certifiability requirements of avionics systems,” explains Gilliland. “As such, Deos provides some unique capabilities that enable the developer to create applications built out of components that are independently verifiable and linked on the target. This component-based model greatly reduces the cost of certification and enables rapid product line innovation.”
According to Gilliland, for multi-core systems, Deos provides patented capability to manage contention for resources such as cache and memory busses. “All the requirements for the Deos RTOS are derived requirements based on the set of capability that we believe the industry needs,” he states, adding that, “Our customers system requirements trace to the Deos functional requirements for the application interfaces that they use to implement their software. This provides the necessary traceability throughout the entire system. Over the years as we create new verification baselines, we add capability to support new processors and functionality as well as additional software APIs and compiler functionality to meet the needs of our customers”
Conversely, DiCamillo says that LDRA solutions focus on the verification of software – ensuring the software (product) is built correctly, in compliance with its requirements. “That is somewhat different than assuring the requirements are correct,” he asserts.
For DiCamillo, the LDRA tool suite plays a crucial role in achieving DO-178C compliance for software projects in the aerospace industry, providing comprehensive support for the achievement of objectives throughout the software development life cycle. He claims that static and dynamic analysis capabilities allow developers to identify and rectify issues early in the development process in accordance with the standard.
As an example, he cites that LDRA static analysis tools automate the scanned “inspection” of the source code, highlighting non-conformances as required by DO-178C §6.4.3d. Static analysis is valuable both for catching errors as code is written, and for highlighting those issues that only become apparent during integration (DO-178C §5.4).
Other highlights include the on target “test cases and procedures” supported by the dynamic analysis functionality of the LDRA tool suite include low-level tests, integration tests, and system tests in accordance with DO 178C §6.4.4.2. The tool suite automates structural coverage analysis for all metrics specified in the standard, including MC/DC. LDRA also offers a range of tools to support project managers as comprehensively as developers and testers, particularly through Stage of Involvement (SOI) reviews.
Taking counsel
DO-178C addresses more modern software development practices such as use of object-oriented technology, model-based development and formal methods, to expand the acceptable methods for verifying software. Organisations developing safety critical software are required to provide detailed documentation of the design and proof that the software performs its functions correctly, reliably and safely. By reason of these requisites, it can be daunting to those embarking on developing safety critical software in compliance with DO-178C, but words of encouragement are at hand.
“Start at the beginning,” advises Gilliland. “In order to be successful, you must have a good understanding of what you are trying to accomplish and how to manage development of the software.”
A detailed set of requirements are key to developing safety critical software. Both Brosgol and Karchoud advocate for investment in the training development teams and their familiarisation with DO-178C processes. Without this the constant changing of requirements and iteration of software tends to adversely affect the software development costs, warns Gilliland.
Brosgol also favours emphasising requirements engineering. “Invest time in accurately capturing and validating system requirements and in specifying whether these requirements will be met through software or through hardware. Ambiguities or errors at this stage can lead to significant issues later,” he cautions.
Another piece of advice proffered by Brosgol is the use of safe languages. Stating that programming languages vary in their ability to catch errors early in the development life cycle, Brosgol says an organisation can reduce its certification cost by choosing a language that helps avoid vulnerabilities such as “buffer overrun”, referencing the Ada language, which was designed to enforce sound software engineering principles.
A common recommendation from those approached was to utilise automation and qualified tools to streamline compliance. Leveraging static and dynamic analysis tools can improve the safety and reliability of software and simplify the certification effort.
For example, conforming with “Code Standards” (i.e., ensuring that the source code stays within a specified subset of the programming language and adheres to complexity or other restrictions) is one of the objectives in DO-178C. Qualified analysis tools can expedite demonstrating that this objective is met, whilst dynamic analysis tools can help show that the relevant requirements-based test coverage objectives have been met.
At the highest software level (DALA) formal methods and tools such as AdaCore’s SPARK Pro can facilitate meeting some of the verification objectives. As Brosgol explains, SPARK Pro starts with a firm foundation – the SPARK language. “Unlike most programming languages, in which it is easy to misuse pointers or get an unexpected result on integer overflow, SPARK Flow and SPARK Proof prove that code is memory safe, free from runtime errors, and uses pointers and other features correctly,” he says.
Getting into more details, Brosgol asserts that SPARK Proof provides formal verification that is automatic, reproducible, and integrated into the software development process. “In many software applications, especially low-level, embedded applications like firmware, testing is impractical for some parts of the code. But once you’ve used the SPARK language to capture your functional requirements as contracts (assertions about the state of the program at specific points in the source code), SPARK Proof will prove, with mathematics-based logic, that your code satisfies its contracts. This is done through static analysis, without executing the program; there is no run-time overhead. So, you can be sure your software meets the requirements embodied in the contracts, even when testing is impossible or impractical,” he states.
Other points on the advisory list include implementing rigorous documentation and traceability processes. Adopting an iterative development approach with regular reviews and audits can help ensure compliance and catch potential issues early. DO-178C also requires the preparation of a large number of artefacts: plan and allocate resources to produce and maintain the necessary artefacts throughout the development process; Engage with certification authorities early in the development process to ensure that the approach to compliance is aligned with their expectations; and encourage a culture where safety is prioritised in every aspect of software development. This mindset should permeate the entire organisation, from developers to management.
Expect the unexpected
For DiCamillo, ultimately, no matter how well a company plans for cost, time-to-market, and risk factors, an evolving landscape hides unexpected setbacks, which can range from supply chain and workforce shortages to cybersecurity threats and new regulatory requirements.
“The avionics and aerospace industry are cautious for good reason,” he says. “But in many organisations, that caution can lead to hesitation to change development and testing processes, tools, and models. Gap analysis to assess the additional processes and resource to achieve compliance allows business executives to question development and testing processes and tooling, even as standards are evolving and issues such as cybersecurity are gaining attention and enforcement.”
He believes that successful organisations understand that the future will only become more challenging, and that the time to address concerns and make fundamental changes is now—not during a future critical product launch. “A flexible, robust, and scalable development process offers the best chance for successfully addressing challenges and reducing risk and uncertainty,” he says.
“With a comprehensive verification tool suite boasting consistent user interface for all aspects of verification and validation, teams are well-armed with documentation and shared knowledge throughout the process. Integration with associated development tools throughout the product development lifecycle provides a foundation for overcoming the challenges of certifying next-generation flight software.”
Wright agrees asserting that for organisations new to DO-178C, one of the biggest cost drivers is underestimating the impact of compliance on the project as a whole, including the development process.
“For efficient software development and compliance, the entire project life cycle, from planning to approval, should be DO-178C compliant. For some organisations, that may mean forgetting everything you think you know about project planning, software development and verification, and starting again with DO-178C training, gap analysis, process definition and selection of hardware, software language, standards, and architectural models, and verification tools.”
By Alex Preston
