RVS 3.19 Launched
Rapita is proud to be an ISOLDE Partner
Rapita and SYSGO underline partnership
RVS 3.18 Launched
Measuring response times and more with RapiTime
Why mitigating interference alone isn’t enough to verify timing performance for multicore DO-178C projects
There are how many sources of interference in a multicore system?
Supporting modern development methodologies for verification of safety-critical software
DO-178C Guidance: Introduction to RTCA DO-178 certification
MATLAB® Simulink® MCDC coverage and WCET analysis
Code coverage for Ada, C and C++
AMC 20-193
DASC 2023
DO-178C Multicore In-person Training (Huntsville)
HISC 2023
NXP's MCFA 2023
DO-178
RTCA DO-178C / EUROCAE ED-12C: Software Considerations in Airborne Systems and Equipment Certification is the primary document by which certification authorities such as the FAA and EASA approve civil software-based aerospace systems. Recently, it has become the de facto approach for demonstrating airworthiness in military avionics systems worldwide.
Introduction to DO-178C
DO-178 was originally developed in the late 1970s to define a prescriptive set of design assurance processes for airborne software that focused on documentation and testing. In the 1980s, DO-178 was updated to DO-178A, which suggested different levels of activities dependent on the criticality of the software, but the process remained prescriptive.
Released in 1992, DO-178B was a total re-write of DO-178 to move away from the prescriptive process approach and define a set of activities and associated objectives that a design assurance process must meet. This update allowed flexibility in the development approaches that could be followed, but also specified fundamental attributes that a design assurance process must have, which were derived from the airworthiness regulations.
Many advances in software engineering technologies and methodologies since the release of DO-178B made consistent application of the DO-178 objectives difficult. In 2012, DO-178C/ED-12C was released, which clarified details and removed inconsistencies from DO-178B, and which also includes supplements that provide guidance for design assurance when specific technologies are used, supporting a more consistent approach to compliance for software developers using these technologies. DO-178C guidance also clarified some details within DO-178B so that the original intent could be better understood and more accurately met by developers.
Collins Aerospace
How RapiCover was used for DAL A code coverage analysis for a complex flight control system.
Triumph Group
How Rapita's V&V services produced evidence for certification of actuation system software.
Cobham Aerospace
Rapita tools efficiently produced coverage evidence for DAL C certification of an antenna control unit.
OHB Sweden
How RapiCover improved code coveage analysis for DO-178C attitude orbital control system.
Software Safety Levels
DO-178B introduced (and DO-178C continued to use) the fundamental concept of the Design Assurance Level (DAL), which defines the amount of rigor that should be applied by the design assurance process based on the contribution to Aircraft Safety. The higher the DAL, the more activities and objectives that must be performed and met as part of the Design Assurance process because of the more severe consequences to the aircraft should the software fail or malfunction.
DAL | Condition | Objectives |
|---|---|---|
A | Catastrophic | 71 |
B | Hazardous | 69 |
C | Major | 62 |
D | Minor | 26 |
E | No safety effects | 0 |
DO-178C processes
The typical process for the certification authority to determine compliance is based on four “Stage Of Involvement” (SOI) reviews/audits. These reviews are:
- SOI#1 or Planning Review
- SOI#2 or Development Review
- SOI#3 or Verification Review
- SOI#4 or Certification review
Each of these reviews focuses on an aspect of the process and evaluates the evidence that demonstrates compliance incrementally throughout the development life cycle.
Efficient verification through the DO-178C life cycle
This handbook takes you through the whole DO-178C journey with a focus on verification, leaving you with an understanding of the compliance process as a whole and practical tips to efficiently verify DO-178C software.
Tool qualification
As per DO-178C, you need to qualify any software tool you use that replaces or mitigates any DO-178C process and for which the output is not manually verified. The qualification process ensures that such software tools can be relied upon to produce appropriate and repeatable results.
DO-178C itself describes when a tool must be qualified, but does not go into detail on how this should be done. The DO-330: Software Tool Qualification Considerations supplement to DO-178C expands on this guidance by defining corresponding objectives for the specification, development and verification of qualified tools.
If you use any commercial verification tools to automate DO-178C verification processes and don’t plan on manually reviewing output from the tools, they will need to be qualified at the appropriate tool qualification level. Many commercial verification tools have supporting qualification kits, which include evidence needed to demonstrate that the activities the tool developer must perform have been performed. All qualification kits should include all of the evidence needed from the tool developer. Some qualification kits may also include supporting material to help meet tool user objectives.
How can Rapita help?
The Rapita Verification Suite (RVS) reduces the effort needed to verify DO-178C software by helping to satisfy specific DO-178C objectives.
RVS includes plugins that satisfy requirements-based functional testing, structural coverage analysis and worst-case execution time analysis and is supported by a qualification kit and service to provide DO-330 tool qualification evidence.
To see how RVS could help you, contact us or download a free trial today.
DO-178C handbook preview
Read the first chapter
The safety assessment processes used in all functional safety domains rely on demonstrating that the probability of system failure that could cause harm is below an acceptable threshold.
When a system is made up of mechanical and electronic components, for which the component failure rate is known, the probability of failure for the system can be calculated and achievement of the safety target can be demonstrated. For software, complex systems or electronic hardware, system failures can be caused by design errors (sometimes known as systematic failures) as well as component failures, but there is no agreed way of calculating the failure rate of these design errors. In the aerospace domain, the agreed approach for dealing with design errors is to implement design assurance processes that have specific activities to identify and eliminate design errors throughout the software development life cycle.
DO-178 was originally developed in the late 1970s to define a prescriptive set of design assurance processes for airborne software that focused on documentation and testing.
Design Assurance Levels (DALs)
DO-178B introduced (and DO-178C continued to use) the fundamental concept of the Design Assurance Level (DAL), which defines the amount of rigor that should be applied by the design assurance process based on the contribution to Aircraft Safety. The higher the DAL, the more activities and objectives that must be performed and met as part of the Design Assurance process because of the more severe consequences to the aircraft should the software fail or malfunction. Design Assurance Level A (DAL-A) is the highest level of design assurance that can be applied to airborne software and is applied when failure or malfunction of the software could contribute to a catastrophic failure of the aircraft. The activities and objectives that must be met through the Design Assurance process gradually decrease with each level alphabetically until DAL-E, which has no objectives as there is no consequence to aircraft safety should such software fail or malfunction.
Objectives and activities
The recommendations given in DO-178 fall into two types:
- Objectives, which are process requirements that should be met in order to demonstrate compliance to regulations
- Activities, which are tasks that provide the means of meeting objectives
In total, DO-178C includes 71 objectives, 43 of which are related to verification. The number of these objectives that must be met for compliance reduces as the Design Assurance Level of the system reduces.
Supplementary objectives and guidance
DO-178C introduced three technology supplements to provide an interpretation of the DO-178C activities and objectives in the context of using specific technologies. The three technologies are Model Based Development and Verification (DO-331), Object Oriented Technology and related technologies (DO-332), and Formal Methods (DO-333). Each supplement describes the technology, defines the scope of its use within airborne software, lists additional or alternative activities and objectives that must be met when the technology is used, and includes specific FAQs (Frequently Asked Questions) that clarify objectives and activities relating to the technology.
A further supplement was introduced in DO-178C, Software Tool Qualification Considerations (DO-330), which gives guidance on the qualification of tools used in software development and verification processes. This guidance can be applied to any tools, not just those used for software development or verification, for example systems design or hardware development tools, and acts more like a stand-alone guidance document than the other supplements mentioned.
Many other documents support DO-178C by providing additional clarification or explanations that can help developers to correctly interpret the guidance and implement appropriate design assurance processes. The Supporting Information (DO-248C) supplementary document includes FAQs relating to DO-178C, and the document is commonly referred to by the title Frequently Asked Questions. In addition to the FAQs in DO-248C, the document provides the rationale for the activities and objectives listed in DO-178C and includes discussion papers that provide clarification on specific topics related to software development and verification. A series of documents produced by the Certification Authorities Software Team (CAST) since the release of DO-178B provided information on specific topics of concern to certification authorities in order to harmonize approaches to compliance. These topics have had a greater scope than just Software concerns, and much of the content in CAST documents has been implemented in guidance updates such as DO-178C, or formed the basis of authority publications, such as A(M)C 20-193 to address the use of multicore processors in avionics and A(M)C 20-152A on the development of airborne electronics hardware. CAST has remained inactive since October 2016 and links to most previous CAST papers have been removed from the FAA’s website...........
