The development of embedded aeronautics systems and software follows a complicated lifecycle. For avionics embedded systems developers, orchestrating the engineering, design, production, testing and integration of an extremely large set of hardware items with great precision is just part of the task.
Various hardware devices are controlled by embedded software, the development of which in and of itself is an immense task – not only because of the volume and complexity of code, but also due to the fundamental requirements of safety and reliability. Adhering to the specifications of various aviation safety standards, guidelines and regulations (in short: compliance) is key to developing safe and reliable flight equipment and airborne embedded software.
DO-178B and C: Software Considerations in Airborne Systems and Equipment Certification
As the primary standard applied in aviation development for over two decades, DO-178B (Software Considerations in Airborne Systems and Equipment Certification) is the general guideline that aims to guarantee the airworthiness (safety and reliability) of software systems used in civilian aircrafts. The standard’s updated version, DO-178C (also known as ED-12C), was put into force in 2011 and is considered a “means of compliance with the applicable airworthiness regulations for the software aspects of airborne systems”.
The standard, which has been adopted by certification authorities worldwide (RTCA, EUROCAE, FAA, EASA, Transport Canada, CAAC, etc), focuses on certain objectives and is not prescriptive in nature. In other words, it tells you what you need to achieve, but it doesn’t tell you how to get there. As various avionics development companies have devised their own ways of “getting there”, they are facing the problem of updating their custom processes to keep pace with technological and methodological development.
The core of the updated standard DO-178C isn’t much different to its predecessor DO-178B – while some processes will have to be revised, if you have been complying with DO-178B, making the transition to the updated standard shouldn’t be a problem.
In general, DO-178C specifies the objectives of software lifecycle processes, the ways (processes and considerations) to achieve these goals, and describes the verification activities proving that those objectives have been satisfied. The document defines three groups of processes:
- Software planning: these processes define and manage all the software development-related activities
- Software development:requirements, design/engineering, coding and development, testing and integration
- Verification: processes that aim to guarantee the correctness, control, and confidence in the safety and reliability of all previous lifecycle processes, as well as their end products.
Compliance with DO-178B/C
The standards defines criticality levels for software components based on how they could fail, and the effects of a potential failure. Ranging from “No effect” (for instance, in-flight passenger entertainment systems) to “Catastrophic” (e.g. the software driving the autopilot or navigational systems), these safety-criticality levels determine how rigorous the standards’ applied requirements are.
While it’s methodology-agnostic, DO-178C does outline a lifecycle model that resembles the traditional V-model in that planning and certification are important stages of the process that support compliance and communication between regulatory bodies. Following planning, you will have to define the high-level and low-level requirements, as well as the requirements derived from these. The updated standard (DO-178C) contains considerations of deactivated code, so you’ll also have to describe your efforts to ensure that deactivated code cannot be activated during operation.
After coding, the software will have to be integrated, tested and verified. In this two-level process, the adequacy of requirements, architecture, code, etc. will have to verified, as well as testing procedures executed. Requirements-based testing is also a stipulation that aims to ensure the coverage of all requirements with test cases. Therefore, as with all other industry standards applicable to other safety-critical industries (automotive, medical, railway, etc) traceability is of vital importance, and is a basic requirement of the configuration and management processes described by DO-178C. Finally, having carried out quality assurance activities, proving compliance and acquiring certification is the last step of the process.
Development tooling solutions
While in several mission-critical industries, some companies still stick to their old tooling and workflow solutions (e.g. manual processes using MS Word or Excel files for requirements management), the complexity of avionics development necessitates the transition to smart toolsets that automate or reduce the effort-costs of complying with certain parts of DO-178C. Specifically, establishing and proving traceability on all work items from requirements all the way to released product, even in the case of a large number of artifacts, is a task that would be impossible without relying on smart software solutions.
Through leveraging the powerful capabilities and the single repository architecture of codeBeamer ALM, Intland’s Avionics DO-178C Template helps comply with DO-178C and other safety regulations by automatically taking care of fundamental processes. The template allows you to efficiently define, collaborate on, and manage aviation-specific requirements, to associate all work items automatically for complete traceability, and to ensure the visibility of all your development processes during the lifecycle. Testing is also greatly supported, as is the analysis of your requirements’ test coverage, the re-use of relevant work items to support variants management, and documentation and reporting to facilitate compliance.