Developing Software in Compliance with DO-178 Standard

Vyacheslav, could you please share our company’s experience developing software compliant with the DO-178 standard?

First, let me introduce the DO-178 standard, specifically its latest version, DO-178C. This document specifically addresses the functional safety of mission-critical applications, particularly software used in aircraft. It outlines the objectives for the entire software life cycle, from planning to certification, and provides recommended activities and practices to achieve these objectives. Additionally, it includes methods to verify that the development goals for reliable and safety-oriented software have been accomplished.

So, if I understand correctly, most development requests in compliance with this standard come from clients primarily operating in the aerospace industry.

That’s correct, to a certain extent. While our main client for DO-178 development, with whom we have collaborated for over 25 years, specializes in Real-Time Operating System (RTOS) development, the utilization of this RTOS extends beyond just the aerospace industry. It is also adopted by end clients in various sectors, including creating aircraft and spacecraft, as well as other domains like industrial automation.

Is the DO-178C standard applied to the development of safety-critical software in other fields as well?

While there are similarities in the approaches to developing safety-critical software, different industries have historically formed their own dedicated working groups for software safety. They have created industry-specific regulatory documents and established their own certification bodies. Additionally, the target market and the countries where the device and software will be used play a significant role in determining the certification body and the specific functional safety standards to be followed. For instance, developing software for medical devices intended for the EU market must adhere to the IEC 62304 standard and software development for electronic modules installed in mass-produced automobiles must comply with the ISO 26262 functional safety standard.

Does this imply that companies must possess experience in developing software for each particular domain to create safety-critical software for various industries?

Concisely and formally, the answer is yes. Auriga’s significant expertise in developing software for medical devices is worth noting. However, taking a broader perspective, as mentioned earlier, functional safety standards exhibit many common areas, particularly in requirements engineering, coding, and code verification approaches. The areas representing the most resource-intensive aspects of software development are often outsourced to service companies like Auriga. Moreover, collaborative efforts are underway among working groups to align and harmonize these standards. For instance, the standard for medical device software development, IEC 62304, and the standard for automotive electronic system software development, ISO 26262, are both drawn upon the IEC 61508 standard, which serves as the foundation for industry-specific functional safety standards. In essence, when considering this in a broader context, Auriga’s existing experience in developing software for safety-critical applications, complemented by our quality management system, management culture, and engineering practices, enables us to adapt to various industries’ distinct requirements swiftly.

Vyacheslav, you mentioned that DO-178C describes different stages and processes in software development. Does Auriga encompass all of them?

Indeed, the DO-178C objectives encompass all stages of software development, ranging from planning and requirements development to engagement with certification authorities. Furthermore, the standard outlines the necessary integration between software development and the overall system, including hardware components. Therefore, a company seeking to outsource such software development must align its processes with the requirements of DO-178C. Specialized consulting firms can aid in this endeavour by assisting in process alignment and preparation for submission to certification bodies. Auriga’s services focus on the most demanding aspects, including formulating and documenting high-level requirements, developing architecture and low-level requirements, actual programming and code verification, or simply testing.

However, coding and testing are essential components of software development, regardless of whether it is for safety-critical domains or not. What are the distinctions between them?

Certain practices and measures utilized in software development according to the DO-178C standard may also apply to developing non-safety-critical software and be considered best practices there. For instance, the DO-178C requirement that source code must conform to coding standards (such as safety-oriented standards like MISRA C) now has a widespread similar practice known as Coding Style in ordinary software development. So, DO-178C establishes a comprehensive approach and a high rank of software development aimed at safety and quality. One notable aspect is the objective of bidirectional traceability of system requirements in source code and verification procedures, which necessitates a specific code documentation process and is rarely encountered in normal software development.

Can you tell me about Do-178C testing compliance?

Certainly! As mentioned, we clearly understand which requirements each test verifies and vice versa. It is essential to achieve comprehensive coverage, providing evidence that the program effectively implements the requirements. Following the testing phase, we also assess the structural coverage, which measures how much of the code is covered by tests. It is crucial to ensure complete structural coverage, adhering to the principle of including what should be included and excluding what should not. This analysis encompasses both code operators and branching points within the code. In the case of Software A’s safety level (DO-178C DAL A), the evaluation of structural coverage is based on the object code, requiring verification at the Assembly language level. Our QA specialists utilize specialized tools specifically designed for this purpose. We leverage pre-existing, qualified tools readily available in the market to streamline the certification process and enhance efficiency.

Developers often face new bug-fixing tasks when developing ordinary software after testing. What additional tasks emerge after testing when developing software according to the DO-178C standard?

Indeed, testing can reveal shortcomings in structural coverage, and multiple factors contribute to this. Firstly, inadequate test coverage of requirements or insufficient requirements themselves can be a contributing factor. Additionally, incomplete structural coverage may occur due to the presence of «dead code».

«Dead code»? It sounds scary.

Dead code refers to portions of code not executed during a comprehensive verification of the system’s functionality. If this code has not been purposely deactivated or does not serve a protective purpose, its presence is unintentional and should be removed. This is done to prevent unnecessary complexity in the program and mitigate any potential risks it may introduce.

To bury it to ensure it does not hit.

Exactly. Another reason for incomplete structural coverage of the object code, obtained through testing with specialized tools, can be caused by translating high-level source code, in our case, the C language, into object code by the compiler. During this translation process, the compiler relies on patterns, but the depth of the execution flow considered may not encompass the entire function. Additionally, the compiler emits code without this knowledge if the type system needs to be improved to determine the function’s contract. This, combined with compiler optimizations, results in the presence of sections in the object code that will never be executed in the actual system.

And how should this be addressed?

In such cases, engineers delve into these coverage gaps by analyzing the corresponding assembly code. They assess whether these coverage deficiencies stem from a peculiarity in translating the program to object code and evaluate if they present any safety risks.

It sounds very labour-intensive.

Indeed, that is true. However, this effort is essential to prevent catastrophic events. The DAL A level represents the highest level of safety in software development according to DO-178C, and it is implemented in scenarios where the consequences of an error could result in the loss of human lives.

Certainly, it is of utmost importance. What recommendations would you give to companies engaged in or considering developing products that require certification according to DO-178C?

As a project manager, I want to emphasize the importance of well-defined processes. Firstly, it is crucial for the organization to have a mature quality management system in place. This system serves as the foundation for effectively implementing the development processes outlined in the DO-178C standard. Moreover, organizational culture plays a critical role, particularly in the individuals within the organization. Employees should embrace the importance and rationale behind the processes, exhibit personal accountability, and diligently adhere to the development guidelines. In most cases, companies developing products that require certification, according to DO-178C, already possess these qualities. However, they may encounter challenges when selecting a suitable technological partner.

And Auriga can be such a technological partner, can’t we?

Absolutely, we can.

I would like to extend my wishes for success to your team in their work. And thank you for the engaging conversation.

Thank you for the interesting questions. And I wish all readers safe flights.