.jpg)
DO-178C - Overview
The purpose of this page is to present a simple and global view of the DO-178C
It should be read and understood as a prelude to more comprehensive training, where we can go into greater detail and provide more examples
A 2-day training course on the DO-178C is quite dense and experience shows that trainees can become saturated if they have no idea about the subject when they arrive at the training
Preamble
What is ARP-4754A, DO-178C/DO-254 and other standards for ?
This section is intended for people who wonder where these aviation standards or "norms" come from and what their purpose is. It deliberately takes shortcuts and simplifications to get to the point of the message
The law
Depending on the country, the laws are identified via various media, for example the CFR: Code of Federal Regulations in the USA. It is a little more complicated for the states of the European Union, but concerning the laws relating to aeronautics, the content of these laws is more or less the same in most countries, particularly in the USA and in Europe
The laws concerning aeronautics have as origin, for almost all of them, the safety of people
Safety first
Under the law, and among other laws, the development of an aircraft, system or equipment on board an aircraft, requires safety analyses. The standards (guides) recognized and applied by the aircraft manufacturers and their suppliers for the realization of these analyses are ARP-4754A and ARP-4761. These analyses start at the aircraft level and then continue at the systems and equipment level.
From these analyses, a criticality level is determined for each system and equipment. The highest criticality level is "Catastrophic", the lowest is "no effect on safety". For example, it can be understood that the total loss of braking for landing is catastrophic
Using a method proposed in ARP4754A, starting from criticality and architecture, a Design Assurance Level (DAL) is determined for each system and equipment
DAL
The DAL (Design Assurance Level) is arbitrarily represented by a letter: A for the highest, E for the lowest. The DAL being linked to the criticality, it is fundamental to understand the following concept:
- The higher the DAL, the more numerous and thorough the verification activities will be
- The higher the DAL, the more independence is needed in these verifications
These objectives aim to guarantee a certain level of confidence (Design Assurance) in the design of the system, equipment, electronics or software under consideration. The higher the DAL, the higher the level of confidence should be
Standards
Laws are written in non-technical forms, such as "critical systems must be safe". Standards attempt to translate these high-level rules into objectives and activities that can be understood, and for which evidence can be provided. The standards are written by working groups involving aircraft manufacturers (Airbus, Boeing, ...), system manufacturers (Thales, Safran, Honeywell, ...) and authorities (EASA, FAA, ...).
ARP-4754A, DO-178C/DO-254
These standards, but others as well (DO-200, DO-326, DO-330, DO-356...), identify objectives based on the DAL as well as the need for independence to meet these objectives. Each standard contains, towards the end of the document, tables of objectives. Knowing the DAL, it is sufficient to look in the columns "DAL" what applies to the project. Let's take a concrete example with DO-178C:
Responsibility
In conclusion, the applicable aviation standards are dictated by laws that originate in the safety of people. It is important for the stakeholders to understand that they have a responsibility for their correct application. It is important to keep in mind that the majority of systems on board aircraft are critical systems.
Overview of activities
Here we present the main activities related to the objectives of DO-178C. As explained above, some activities are not mandatory or must be modulated according to the DAL.
Planning
As explained previously, the DO-178C contains a table of objectives according to the DAL.
The first activity is to develop plans that will establish the way of working (methods) to be in compliance with these objectives.
The plans are not written for informational purposes for a certification authority, they are applicable by the development team.
An authority (e.g. EASA, FAA, etc.), or its representative (e.g. Airbus, etc.) may conduct audits during development (SOI#1, SOI#2, SOI#3, SOI#4). Once it has approved the plans as being in line with the objectives through SOI#1, it will conduct audits and carry out sampling to ensure that the plans are implemented and correctly implemented.
NOTE: DO-178C expresses objectives but does not propose a solution. For example, one objective is to establish coding rules that can make the code readable, maintainable, etc., with the ulterior motive of limiting the risks of errors inherent in "tortuous" coding. These coding rules are to be defined by the project; the DO does not impose them. It often happens that a company decides to have rules common to all projects or to use standardized rules (e.g. MISRA), in which case we will speak of "standards" that will be referenced in the plans.
The specification
Once the plans are established (for the record they contain the development methods applicable to the project), the development begins with the first step: specifying the needs.
In a specification we find "requirements".
In a specification we usually find a group of requirements for each function and requirements related to various factors (performance, interfaces, etc.). For example (simplified) for a display function:
Requirement #1 The display of the text xxx must be of color xxx and size xxx
Requirement #2 Altitude display must be in feet
...
Note that the requirements are described in terms of needs or expectations, not solutions.
The way to capture/write requirements follows rules identified in the plans.
Each requirement must have a unique identifier (again, nothing imposed by the DO, everyone is free to determine how to identify a requirement). This will be used in particular for traceability.
The design
Once the specification has been checked (see section about verification) and approved, the next step is the design.
The objective of design is to establish a solution to meet the requirements of the specification. The design phase has two main aspects:
- The architecture (functions, real-time aspects, task distribution around an OS, etc.)
- Low-level requirements (refinement of the specification into more detailed requirements, algorithms, etc.)
The design (architecture plus low-level requirements) will be the entry point for coding. In principle, except for the coding rules, the coder will only need this information (plus possibly information on interfaces with the hardware) to code.
NOTE:
HLRs (High Level Requirements) are the high-level requirements, they are the requirements of the specification (for the record) which express the need and not the solution.
LLRs (Low Level Requirements) are the low-level requirements, they are the design requirements (expressed in terms of solution).
Coding and integration
Once the design has been checked (see slides on checks) and approved, the next step is coding (in real life we proceed in pieces, we don't wait until the end of the design to code the first line, in this high-level presentation we don't enter into a slightly more complex discussion involving configuration management)
These phases are well known to developers, we are talking here about:
Source coding (C, C++, ADA…)
Compilation (assembler production)
Link (production of the executable)
NOTE 1: As mentioned above as an example, the coding, in addition to having to conform to the design, must also conform to the coding rules
NOTE 2: If object-oriented language (C++…) is used, another DO (DO-332) applies, which contains additional objectives
The verifications
Depending on the DAL, DO-178C identifies a number of checks to be carried out, sometimes independently
As a reminder, the more critical the software, the more layers of verification there are.
This presentation is simplified but provides an overview of the checks applicable for a DAL A (therefore the maximum):
Verification of plans (verify that all applicable objectives are covered)
High-level requirements verification (verify that HLRs are correct and complete)
Low-level requirements verification (verify that LLRs are correct and complete)
Architecture verification (verify that the architecture is compatible with the specification)
Source code verification (verify that the code complies with the design and coding rules)
Establishment of test cases (for each requirement, test cases cover the requirement in question, see slide 3/3)
Verification of test cases (verify that the test cases completely cover the requirements)
Establishment of test procedures (for each test case, establish the test procedure, see slide 3/3)
Verification of test cases (verify that the test procedures are compliant and cover the test cases)
Verification of test results (verify that the results comply with the expectations identified in the test cases)
Structural coverage check (check if some parts of the code were not exercised during testing)
WCET (Worst Case Execution Time) (verify that all tasks have time to execute in the worst CPU load scenarios)
Check that the code generated by the compiler does not contain unwanted behaviors
Check integration outputs (check compilation and link outputs)
Difference between test cases and procedures:
Test cases are written from requirements, a test case identifies:
•The requirement (or group of requirements) that the case addresses
•The objective of the test (which part we want to test)
•The test entry requirements
•The expected result
The procedures are written from the test cases:
•Either in terms of actions to be carried out by the tester, or for example in Python for automatic execution, or a combination of the two
•Once executed, the procedures generate the results (which will then be compared to the expectations identified in the test cases)
Traceability
Among the advantages of traceability we can note:
•Top-down (for example from specification to design): we make sure that we don't forget anything
•Upward (e.g. from design to specification): we ensure that we do not introduce unwanted behaviors
The expected traceability levels depend on the DAL
Below is the case of DAL A (therefore maximum):
•Between the equipment specification and the software specification
•Between software specification and design
•Between design and source code
•Between source code and object code
•Between requirements (HLRs & LLRs) and test cases
•Between test cases, test procedures, test results
And generally speaking, there must be traceability between the different elements (specification, design, code, etc.) and the verification evidence (see checklist). For example, between the source code and the verification evidence for compliance with the coding rules.
In theory, traceability can be managed with one or more Excel files, which is feasible for a small project, the main difficulty being configuration management. In general, many manufacturers use dedicated tools (JAMA, DOORS, etc.)
The quality
At least one software quality manager must be designated for the project
Its role is to ensure that plans, once approved, are implemented. And, if not, to define a way to return to normal.
Quality should be independent of development. In principle, it refers directly to management in the company's organizational chart, or at least to the body above the development team.
He/she fulfills his/her task by carrying out inspections and audits throughout development
Quality has its own plan which determines the methods and tools used but also the planning of its activities correlated with the development planning
The quality manager must have a good knowledge and understanding of DO-178C, or at least of the applicable plans
Configuration management
•How to identify “items” (e.g. a plan, a specification, a source file, etc.), and their version at a given time T
•How to identify their status (eg verified and no open action, open actions, etc.)
•How and when to implement a change tracking system
Setting up this activity is not easy
The primary interest (in terms of certification) of configuration management is to be able to draw credit, in terms of certification, from an activity
For example, if we want to be able to prove that a source file has been checked for compliance with coding rules, we will first need a method to identify this file and its version. This will allow the verification report (e.g. a review report or an analysis tool output) to refer to this file and its version. Subsequently, if this file is modified, we will need to be able to identify that the file has been modified, and to identify the need for a re-verification, even partial.
Note that configuration management not only helps to justify the achievement of certification objectives, but above all helps the project manager to know exactly where the project is, what is finished and what remains to be done (or redone).
Other considerations
DO-178C identifies objectives specific to certain specific situations. For example, we have already discussed object-oriented design, which makes DO-332 applicable. Below are some examples of specific cases that result in additional objectives:
Model-based development, entails the application of DO-331
Tool qualification: in some cases it is necessary either to use an already qualified tool or to qualify the tool. Tool qualification is dealt with partly by DO-178C but mainly in DO-330
Using in-service editable configuration files
Request for certification credit for using software already in use on other programs
In summary
This presentation skips over a host of details for each activity which, even with a 2-day training course, could not all be discussed exhaustively.
Many subtleties are learned by doing. Often, it is not necessary for an engineer to master all of DO-178. For example, an engineer dedicated to writing test cases or procedures will need to be informed of the procedures described in the "Verification Plan" and certain aspects of configuration management described in the "Configuration Management Plan." He/she will have little or no need for other elements.
For a beginner with the DO-178C it is important to remember the following information
•The objectives identified in DO-178C aim to improve as much as possible the confidence that can be had in software, for the purpose of personal safety. If DO-178C is applicable to a project, it is law, it is not optional.
•The objectives identified in DO-178C, apart from those for Quality, are directly linked to development techniques (the auditors of the authorities who monitor you, in principle, have a background as designers and can rely on a panel of experts)
•DO-178C identifies objectives but does not propose solutions. The solutions to achieve these objectives are to be determined by the company responsible for the project and are detailed in the “plans & standards” applicable to the project.
When you arrive on a project, you should be informed of what applies to you based on your role. Either you are given the plan that applies to you or it is explained to you.