DO-178C/ED-12C
The new software standard for the avionic
industry: goals, changes and challenges
SVEN NORDHOFF
Aerospace Certication / Process Assurance & SPICE Assessor
sven.nordhoff@sqs.com
Sven Nordhoff holds a diploma in Computer Science and has been working
for the SQS Market Unit Industrial Service & Solutions for twelve years. He
is primarily responsible for Aerospace Certication and Process Assurance,
which includes SW / HW monitoring of suppliers at Airbus Operations, Ger-
many. He also is a Principal ISO-15504/SPICE Assessor and teaches seminars
on process improvement, quality assurance and airworthiness standards. As
a member of the international working group EUROCAE/RTCA WG71/SC205,
he has been involved in the development of avionic standard DO-178C from
day one.
DO-178C/ED-12C Page 2
1 MANAGEMENT SUMMARY
The standard DO-178C/ED-12C, Software Consid- The new standard DO-178C/ED-12C is divided into
erations in Airborne Systems and Equipment Cer- the core document, three supplements for the
tication, is the upcoming international standard technology-specic parts (Model-Based Develop-
jointly published by the RTCA and EUROCAE. This ment & Verication, Object-Oriented Technology
new standard will replace DO-178B/ED-12B to be and Formal Methods), and a special document con-
the primary document by which the aviation cer- sidering tool qualication. The key gures are iden-
tication authorities such as the Federal Aviation tied and put into the context of the DO-178C world
Administration (FAA, USA) and the European Avi- of thinking. The usage of this family of standards is
ation Safety Agency (EASA) approve all commer- explained and a possible workow is suggested for
cial software-based aerospace systems. DO-178B/ the introduction of the new standard.
ED-12B had been established in 1992 and it was
necessary to update this standard to clarify some DO-178C/ED-12C is now ofcially nalised the
inconsistencies and introduce some new meth- last plenary session was held in November 2011
odologies and technologies which have already in Daytona Beach, USA. All parts have been com-
been used in the current development and quality pleted and the nal step will be the formal ap-
departments in the avionic industry. In addition, proval of the RTCA (Radio Technical Commission
the new DO-178C/ED-12C has been established to for Aeronautics ) and EUROCAE (a non-prot or-
ensure the validity of this standard for the future, ganisation providing a European forum for resolv-
in view of the fact that the old B version has now ing technical problems with electronic equipment
been in use for over 20 years. for air transport). The aviation authorities have
been requested to determine whether DO-178C/
Essentially, this whitepaper summarises the fol- ED-12C and its supporting documents can be con-
lowing: sidered acceptable means for the certication of
The goal and the methodology of this software-based systems. Once they have been ap-
standard proved by the authorities, these documents will
The history and the activities which brought apply to the next aircraft programmes, to future
this standard to its current form redesign of equipment, or to new equipment for
The main facts about DO-178C/ED-12C existing aircraft or engines.
The differences between DO-178B/ED-12B and
DO-178C/ED-12C in general, and in particular The author of this whitepaper has been a member
regarding technological and methodological of the DO-178C/ED-12C working group from the
aspects very beginning and leads a group of DO-178B/C
The impact of this new standard on specialists within SQS. The gap analysis methods
development and quality departments presented below were established years ago for
all over the world DO-178B and have been complemented to accom-
A short methodology and workow how a modate the new requirements of DO-178C. Many
company can ensure compliance to this companies have dened or improved their DO-178
standard processes with the help of SQS.
A way to avoid stumbling blocks and
inconsistencies
DO-178C/ED-12C Page 3
50
47.8
45
Flight hours
Annual departures and ight hours
40 Departures
35
30
(millions)
25
22.3
20
15
10
0
Year 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10
25
Worldwide Fleet
20,746
20 Boeing Fleet
Number of airplanes
(thousands)
15
12,495
10
5
Source: Jet Information Services, Inc.
0
Year 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10
Figure 1: Annual aircraft departures, ight hours and the number of airplanes in the world
DO-178C/ED-12C Page 4
The future starts right here, with an explosion The increasing usage of commercial aircraft and
of aircraft orders: 797 orders for Boeing 787 the increasing complexity of the aircraft systems
(Dreamliner), and 1,055 orders for Airbus A320 including software do not lead to a higher number
Neo. (() These
Theseaircraft
aircraftdepend
dependupon
uponsoftware-
software- of accidents and fatalities.
based embedded systems, which increases the
necessity of quality assurance activities dramatically. It seems that the introduction of process-related
Other companies from the new strong econ- standards (not only for software), their consistent
omies will enter the market as soon as possible application within the industry, and the rigorous
to get a share of the large cake of selling com- approval of software systems by the airworthi-
mercial aircraft, but in order to be successful ness authorities are reducing the number of fail-
they need to consider the tremendous amount ures caused by these highly integrated and com-
of quality measures which the aircraft author- plex systems. Apart from the strict introduction
ities require. of quality-based components and greater experi-
ence with the structural behaviour of materials,
If we look at the fatal accident rate of aircraft in the application of these process-related stand-
the recent past, it can be observed that it is de- ards is the main success factor. There is no trend
creasing. Figure 2 shows the annual fatal accident to decrease the level of regulation. The introduc-
rate. (') tion of the new standard DO-178C/ED-12C will not
weaken the qualication activities but rather
boost the enforcement of quality.
50
Annual fatal accident rate (accidents per million departures)
40
1.5
1.0
30 0.5
0
Year 91 92 94 96 98 00 02 04 06 08 10
20
10
Year 59 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 00 02 04 06 08 10
Figure 2: Annual fatal accident rates for aircraft worldwide 2010 Statistical Summary, June 2011
DO-178C/ED-12C Page 5
Intended Function,
System
Aircraft Failure & Safety
Design
Function Information
Allocated Functions
HARDWARE DEVELOPMENT Implementation
& Requirements
LIFE CYCLE
DO-254
SOFTWARE DEVELOPMENT
LIFE CYCLE
DO-178B/C
A Catastrophic Failure conditions that would result in multiple fatalities, usually with the loss
of the airplane.
B Hazardous Failure conditions that would reduce the capability of the airplane or the abil-
ity of the flight crew to cope with adverse operating conditions to the extent
that there would be:
a large reduction in safety margins or functional capabilities;
physical distress or excessive workload such that the flight crew cannot be
relied upon to perform their tasks accurately or completely; or
serious or fatal injuries to a relatively small number of persons other than
the flight crew.
C Major Failure conditions which would reduce the capability of the airplane or the
ability of the crew to cope with adverse operating conditions to the extent
that there would be, for example, a significant reduction in safety margins
or functional capabilities, a significant increase in crew workload or in condi-
tions impairing crew efficiency, or discomfort to the flight crew, or physical
distress to passengers or cabin crew, possibly including injuries.
D Minor Failure conditions which would not significantly reduce airplane safety, and
which involve crew actions that are well within their capabilities. Minor failure
conditions may include, for example, a slight reduction in safety margins or
functional capabilities, a slight increase in crew workload, such as routine
flight plan changes, or some physical discomfort to passengers or cabin crew.
E No Effect Failure conditions that would have no effect on safety; for example, failure
conditions that would not affect the operational capability of the airplane or
increase crew workload.
DO-178B/C belong to a family of similar stand- All these standards are based on a clear philosophy:
ards which were established for the avionic indus- To implement only the intended functionality
try for guidance: (and nothing else)
To ensure safety processes and safety To be safety-driven, which means that for
assessment (ARP 4761) safety-critical application the processes are
To ensure quality for complex systems more rigorous
(ARP 4754A) To implement a V-model approach for every
To ensure quality for complex electronic development cycle (SW, HW and systems),
hardware (DO-254) whose components are dependent on each
To ensure quality for software systems other and have clear interfaces
(DO-178B and C)
All these standards share a major goal: the Therefore, the quality criteria for safety-critical SW
concentration on development processes and application within an aircraft, e.g. Flight Controls,
quality aspects specic to the required safety are more rigorous than for uncritical software sys-
level. tems like In-Flight Entertainment Systems.
This concept, on the one hand, ensures that All these standards are based on a categorisation
necessary activities for safety-critical applica- which denes failure conditions as shown in Fig-
tion are clearly specied and measures are de- ure 4 (see DO-178C, 2.3.2, Table 2-1, p. 13). The
ned to safeguard adequate implementation; DO-178C SW standard uses this kind of classi-
on the other hand, for systems which are only cation to dene the objectives to be considered.
used for the comfort of the passenger, process- These quality objectives are requirements which
es are less stringent. need to be proven to demonstrate compliance to
DO-178C/ED-12C.
SYSTEM PROCESSES
SW DEVELOPMENT PROCESSES
Problem Reporting
SW SW SW SW
Requirements Design Coding Integration
Process Process Process Process
The number of quality objectives related to the There is no secret behind this concept nor are the
SW level is identied in Figure 5 to show that the chosen processes specic to the avionic industry.
number of objectives is increasing the higher the However, if we are looking into the details, some
safety level is. Quality objectives need to be ad- of the principles are remarkable:
dressed for the corresponding SW level in con- The usage of high-level requirements (in SW
junction with the level of independence, meaning requirements processes) and low-level require-
that at least one other person has to check the ments (in SW design processes), which have to
adequacy of this activity. The numbers in brackets be tested (veried) adequately.
refer to DO-178B. The concept of derived requirements (without
traceability to the high-level requirements)
No objective (DAL E) does not automatically which need to be analysed within the system
mean that nothing is to be done. For example, safety activities to preclude that these require-
Airbus Directives (ABD) require industry-conform ments contradict the needs based on the
SW engineering practices for SW level E. safety classication.
The usage of a SW Planning Process and Cer-
As mentioned before, the avionic standards main- tication Process to establish an agreement
ly deal with the development life cycle and pro- with the authorities (e.g. EASA, FAA).
cesses. Therefore, DO-178C clearly denes an SW
life cycle and processes which need to be followed.
5 FACTS ON DO-178C/ED-12C
The new DO-178C/ED-12C family is structured as follows:
DO-xxx/ED-215
Tool Qualication Considerations
DO-xxx/ED-218 Model-Based
Development and Verication Supplement
DO-178C/ED-12C
Core Document
DO-xxx/ED-217
Object-Oriented Methods Supplement
DO-xxx/ED-216
Formal Methods Supplement
DO-278A/ED-109A
DO-248C/ED-94C Guideline for Communication, Navigation, Sur-
Supporting Information for ED-12C and ED-109A veillance, and Air Trafc Management (CN8/
ATM) Systems Software Integrity Assurance
The DO-178C core document is the successor of Table A-7 Verication of Outputs of Soft-
DO-178B with the same structure and a similar ware Testing: Objectives 5, 6, and 7 ensure
approach. The main objective for this document that test cases written for requirements
was to be explore the source code with the degree of
only guidance material (with clear rules and rigor required by the software level. For level
objectives) and C, it was deemed satisfactory to demonstrate
technology- and methodology-independent. that all statements in the source code were
explored by the set of test cases. For level
B, the addition of the requirement that all
The structure of the core document is very similar decision paths in the source are covered was
to DO-178B, but the following aspects are either considered sufcient to address the increase
new or have been changed: in the associated hazard category. However,
Establishment of Rationales for every object- for level A, the committee established that all
ive of DO-178C/ED-12C. These rationales are logic expressions in the source code should be
listed in the DO-248C document. For example, explored. The use of techniques such as multi-
the rationales for the objectives concerning ple condition decision coverage, or exhaustive
structural Code Coverage are: truth table evaluation to fully explore all of
DO-178C/ED-12C Page 10
the logic was considered impractical [] The DO-248/ED-94C is a guideline document contain-
compromise was achieved based on hardware ing additional supporting and explanatory mater-
logic testing that concentrated on showing ial, including:
that each term in a Boolean expression can be Frequently Asked Questions (FAQs)
shown to affect the result. The term for this Discussion Papers
type of coverage was Modied Condition/ The DO-178C/ED-12C Rationales
Decision Coverage (MC/DC). Correlation between DO-178C/ED-12C,
Robustness aspects improved DO-278A/ED-109A and DO-248C/ED-94
User-modiable SW aspects improved Difference between DO-178C/ED-12C and
Testing vs. Data and Control Coupling DO-178B/ED-12B
improved
Guidance to auto-code generator added
Untraceable code added DO-278A/ED-109A is the guidance document for
Parameter Data Item consideration added CNS/ATM systems (Software Integrity Assurance
Considerations For Communication, Navigation,
Surveillance and Air Trafc Management Sys-
But the main improvement within the new DO- tems). Its structure is very similar to that of DO-
178C/ED-12C is the establishment of so-called 178C, showing the same approach but with an em-
Supplements providing technology- and method- phasis on Commercial Off-The-Shelf SW (COTS).
specic material which required a more detailed
and restrictive mapping with regard to DO-178C/ The following sections give a short overview of
ED-12C. the core document and its supplements. The de-
tails of DO-248/ED-94C and DO-278A/ED-109A
The following supplements were generated. shall not be considered in this whitepaper.
Software Tool Qualication Considerations
(DO-xxx/ED-215) 5.1 GENERAL OVERVIEW OF THE
Model-Based Development & Verication DO-178C/ED-12C CORE DOCUMENT
Supplement (DO-xxx/ED-218)
Object-Oriented Technology Supplement The main content of the DO-178C/ED-12C core
(DO-xxx/ED-217) document is the denition of SW life cycle pro-
Formal Methods Supplement (DO-xxx/ED-216) cesses and related activities. Among these activi-
ties, the following are the most important:
Planning Process
The RTCA has not yet assigned DO numbers to Establishment of SW Plans
these supplements. Strictly speaking, the Soft- Denition of the SW Life Cycle Environment
ware Tool Qualication Considerations document Language and Compiler Considerations
is not just a supplement, because its use is also Establishment of SW Standards
intended for other industry domains. For the pur- Review and Assurance of the SW Planning
pose of the present whitepaper, however, it shall Process
be treated as a supplement. Requirements Process
Development of High-Level Requirements
Development of Derived High-Level
Requirements
DO-178C/ED-12C Page 11
PSAC Plan for Software Aspects of Plan to describe the means of compli- 11.1 1 1 1 1 N/A
Certification ance for certification-relevant aspects
SDP SW Development Plan Plan to describe the development 11.2 1 1 2 2 N/A
process and standards
SVP SW Verification Plan Plan to describe all verification activities 11.3 1 1 2 2 N/A
Control Category 1 includes all Configuration Control Category 2 includes only a subset
Management Activities defined by DO-178C. of Configuration Management Activities.
A B C D E A B C D E
Figure 9 shows the different process groups and Software tools are widely used to assist in devel-
their corresponding number of objectives; and, as oping, transforming, testing, analysing, produc-
an example, taken from this list, Figure 10 shows ing, and modifying aircraft-based software pro-
Table A-7 Verication of Outputs of Software grammes, their data, or their documentation. And
Testing. in this context, tools that are used to eliminate,
reduce, or automate a specic DO-178C/ED-12C
5.2 SOFTWARE TOOL QUALIFICATION software life cycle process without verication of
CONSIDERATIONS the tool output, need particular qualication.
The purpose of this document is to provide soft- There are ve Tool Qualication Levels (TQLs),
ware tool qualication guidance to help the tool which are used similarly to the SW level in the
vendor and/or user dene the required activities. DO-178C/ED-12C core document. The kind of tool
Additional information is provided in the form of is dened by using three criteria to clarify the
FAQs. amount of qualication activities to be conducted
for a particular tool:
1 A tool whose output is part of the airborne software and thus Development Tool
could insert an error.
3 A tool that, within the scope of its intended use, could fail Verification Tool
to detect an error.
SW LEVEL CRITERIA
1 2 3
Accordingly, the rigour of tool qualication can be The structure of this supplement is very similar to
dened by the criteria and the SW level of the op- the DO-178C/ED-12C core document. The supple-
erational SW for which the tool will be used. ment adds model-based development aspects to
DO-178C/ED-12C and expands chapters affected
The structure of this document is very similar by MBD&V. Chapters of DO-178C/ED-12C which are
to the DO-178C/ED-12C core document. All tool- not affected by MBD&V remain unchanged. From
relevant processes are dened and objectives and a DO-178C point of view, these models represent
activities are listed depending on the Tool Quali- software requirements and/or architecture to
cation Level (TQL). A generic tool development support the software development and verica-
process is established. Moreover, the Objective tion processes.
Tables known from the DO-178C/ED-12C core docu-
ment are established for each process, though For every model, requirements need to be iden-
here they are used for the related tool processes. tied from which the model is developed. Those
requirements should be external to the model and
A rather interesting point is the differentiation be- be a complete set of requirements and set of con-
tween the tool developer and the tool user when straints (see MBD&V Supplement, MB.1.6.1, p. 2).
a COTS tool is used. Both parties need to conduct The supplement deals with two types of models:
their own qualication activities. The task of the Specication Models containing high-level
tool user is limited to planning and integration requirements
activities regarding the operational environment, Design Models containing architecture and
while the tool developer needs to achieve com- low-level requirements
plete compliance to DO-178C/ED-12C. This gener-
ates a degree of effort at TQL1 which is similar to
SW level A activities. Figures 13 and 14 demonstrate the different
usages of models (Light green) within the con-
5.3 MODEL-BASED DEVELOPMENT & text of DO-178C/ED-12C processes (see MBD&V
VERIFICATION SUPPLEMENT Supplement, Table MB.1-1, p. 4).
This supplement deals with Model-Based Devel- The following aspects described in the MBD&V
opment & Verication (MBD&V) and was written Supplement should be highlighted:
to add, modify, and substitute the objectives de- In the Planning Phase and in the planning
ned in DO-178C/ED-12C. documentation, the usage of models needs
Essentially, the models are used to be explained and the model needs to be
To develop an unambiguous expression categorised as a specication or design model.
of requirements and architecture; All MBD&V methods used need to be identied
To assist in automated code generation; during the planning phase, including verica-
To assist in automated test generation; tion methods like model coverage analysis
As analysis tools for the verication of criteria.
requirements and architecture; and SW Model Standards are required.
In simulations for the partial verication of Simulation can be used in design models to
requirements, architecture, and/or an execut- support testing and analysis methods. The
able object code. usage of simulation in a model may produce
DO-178C/ED-12C Page 16
simulation cases, procedures, and results expressed by the design model were not
which need to be veried (MB.C-3 objectives exercised, through verication based on the
MB8MB10: Requirements; MB.C-4 objectives requirements from which the model was
MB14MB16: Design; and MB.C-7 objectives developed.
MB10MB12: Verication). Usage of Model Simulation for
Model Coverage Analysis supports the detec- Verication of the model, and
tion of unintended functions in the design Verication of the executable object code.
model by determining which requirements
Design Model
Software Coding Source Code Source Code Source Code Source Code Source Code
Process
Clarication of the model coverage criteria is language background. This became necessary be-
of crucial importance to identifying unintended cause the terminology of the different OOT and
functions. Figure 14 shows some examples of cri- programming language approaches usually is
teria which are recommended by the supplement quite different, which regularly results in Baby-
(see MBD&V Supplement, Table MB.6-1, p. 32). lonian situations.
The last chapter of the supplement gives some The next chapters of the OOT Supplement are
examples clarifying the usage of the supplement structured similarly to the DO-178C/ED-12C core
with regard to the relationship between a design document, expanded by adding, modifying, or de-
model or specication model and DO-178C high- leting DO-178C/ED-12C objectives relating to OOT.
level requirements, low-level requirements, and
software architecture. The following aspects of the OOT Supplement
should be highlighted:
5.4 OBJECT-ORIENTED TECHNOLOGY In the Planning Phase and in the planning
SUPPLEMENT documentation, the usage of OOT is to be ex-
plained. All virtualisation techniques used and
Object-Oriented Technologies (OOT) and pro- any reuse of components need to be identi-
gramming languages like Java and C++ have ed during the planning phase, including all
been widely used for decades in the commercial/ verication methods employed to achieve the
industrial sectors where safety is not critical. In objectives of DO-178C/ED-12C and its supple-
the avionic industry, the usage of OOT is increas- ments.
ing but the issues with regard to certication The scope of Verication activities must be
did pose a serious problem because no proper widened to verify, e.g., the class hierarchy,
guidelines were available to clarify usage and local type consistency, memory and exception
certication. For example, for SW level A, B and management.
C software, code coverage measures need to be
taken (DO-178C/ED-12C is talking about Structural
Coverage, SW Level A -> MC/DC Coverage, SW The Annex OO.D Vulnerability Analysis deals
Level B -> Decision Coverage, SW Level C -> State- with all the features of OOT, discussing the spe-
ment Coverage). This DO-178C/ED-12C objective cic vulnerabilities and related guidance. In addi-
is very clear for the classical functional program- tion, supporting information (guidelines) is listed
ming languages like C, but for object-oriented in this chapter to help identify possible solutions
languages, e.g. with encapsulation, polymorphism and clarify the advantages and disadvantages of
and overloading, the meaning of Code Coverage the various methods.
is quite different.
Figure 15 shows some examples of possible solu-
The supplement Object-Oriented Technology tions suggested by the supplement to cope with
and Related Techniques (OOT) starts with Chap- OOT-specic problems.
ter OO.1.0 outlining the characteristics of these
techniques. The supplement was written to be
programming-language independent, using den-
itions which are understood without any specic
DO-178C/ED-12C Page 18
Stack allocation
Scope allocation
Structural Coverage An acceptable means for demonstrating type consistency is by showing the
software satisfies the Liskov Substitution Principle (LSP) (see ED-217,
OO.1.6.1.2.1, Liskov Substitution Principle, p. 4). This may be shown through test
or formal methods.
5.5 FORMAL METHODS SUPPLEMENT The following characteristics are associated with
formal methods:
The Formal Methods Supplement deals with Unambiguously describing requirements of
formal methods to be used for avionic projects. software systems
Formal methods are mathematically based tech- Enabling precise communication between
niques for the engineers
Specication, Providing verication evidence such as con-
Development, and sistency and accuracy of a formally specied
Verication representation of software
of software aspects of digital systems (see ED-216, Providing verication evidence of the compli-
FM1.0, p. 1). The mathematical basis of formal ance of one formally specied representation
methods consists of formal logic, discrete math- with another
ematics, and computer-readable languages. The
use of formal methods is motivated by the expect-
ation that performing appropriate mathematical Section FM.1.0 contains explanatory text to aid
analyses can contribute to establish the correct- the reader in understanding formal methods, and
ness and robustness of a design. therefore is not to be taken as guidance.
DO-178C/ED-12C Page 19
Annex FM.A of this document describes how the All assumptions related to each formal analysis
DO-178C/ED-12C objectives are revised in line with should be described and justied; such as, for
this formal methods guidance. example, assumptions associated with the
target computer or about the data range limits.
Establishing a formal model of the software arte- Reviews and analyses of the formal analysis
fact is fundamental to all formal methods. In cases, procedures, and results for require-
general, a model is an abstract representation ments, architecture, and source code are
of a given set of aspects of the software that is necessary.
used for analysis, simulation, and/or code gen-
eration. A model should have an unambiguous,
mathematically dened syntax and semantics. For the verication of SW requirements/SW de-
This makes it possible to use automated means sign, the following additional objectives are de-
to obtain guarantees that the model has certain ned:
specied properties. Formal analysis cases and procedures are
correct (FM8, FM14).
The chapters of the FM Supplement are struc- Formal analysis results are correct and
tured similarly to the DO-178C/ED-12C core docu- discrepancies explained (FM9, FM15).
ment, and expanded by adding, modifying, or Requirements formalisation is correct
deleting DO-178C/ED-12C objectives relating to (FM10, FM16).
FM. Chapters of DO-178C/ED-12C which are not af- The formal method is correctly dened,
fected by formal methods remain unchanged. justied, and appropriate (FM11, FM17).
The following aspects of the FM Supplement
should be highlighted:
In the planning phase and in the planning For the verication of SW testing, the following
documentation, the usage of FM must be additional objectives are dened:
explained. Coverage of high-level requirements is
Requirements or design artefacts can be achieved (FM3).
dened with the help of formal models. This Coverage of low-level requirements is achieved
allows for some of the verication objectives (FM4).
to be satised by the use of formal analysis. Complete coverage of each requirement
With formal analysis, the correctness of life is achieved (FM5).
cycle data with respect to a formal model can The set of requirements is complete (FM6).
be proved or disproved. Unintended dataow relationships
If formal methods are used for verication are detected (FM7).
purposes, the following considerations are Dead code and deactivated code are
important: detected (FM8).
All notations used for formal analysis should
be veried to have a precise, unambiguous,
mathematically dened syntax and semantics.
The soundness of each formal analysis
method should be justied. A sound method
never asserts that a property is true when it
may not be true.
DO-178C/ED-12C Page 20
The following maturity levels can be identied: If, on the other hand, you are using industry-re-
Maturity Level 3 lated processes with only black-box testing and
DO-178B processes were successfully intro- without clear requirements management and
duced before. quality assurance activities (Maturity Level 1),
Maturity Level 2 quite a number of aspects have to be introduced
Safety-related process-driven SW development to be compliant to DO-178B/C. The analysis needs
was introduced, but DO-178B has not been to start with the identication of all the processes
introduced. used. Then the missing processes must be inte-
Maturity Level 1 grated into the existing process landscape. The
Process-driven SW development was intro- nal step is compliance to all DO-178C objectives,
duced, but DO-178B or safety-critical develop- which results in more activities or a more strin-
ment has not been introduced. gent application of existing activities within the
Maturity Level 0 different processes.
No SW processes established to date.
If a company starts from scratch, without having
either a SW process structure or experience with
Maturity Levels 3 and 2 are good starting points the safety-critical development of software, the
to achieve compliance to DO-178C/ED-12C in the management need to be aware of the fact that
short term. a lot of time, a huge amount of investments, and
With Maturity Level 3, the earlier usage of the attendance of DO-178C experts will be neces-
DO-178B-compliant processes only requires a min- sary to reach the aim. With the right spirit though,
imal amount of gap analysis in order to identify it is not impossible.
the differences between DO-178B and C (see the
previous chapter for details). No new processes or The best way to ensure compliance is using a gap
changes in methodologies need to be addressed, analysis with the help of technical and DO-178-re-
which results in manageable efforts. lated expertise and employing a sound strategy to
DO-178C/ED-12C Page 21
identify required process steps and major incon- The process workow in Figure 16 provides a
sistencies. It is necessary to establish a common short overview of which activities are necessary
process framework with a set of standardised to ensure compliance to DO-178C/ED-12C object-
templates for all related DO-178B/C SW plans and ives.
documents.
In general, this workow should ensure compli-
The fullment of DO-178C/ED-12C-related pro- ance to the DO-178C/ED-12C core document.
cesses can be achieved manually, but it will be
easier to build up a set of tools to support the de- As the supplements extend the guidance from
velopment, verication and test activities. Before DO-178C/ED-12C for a specic technology, the
a tool is acquired, it is necessary to check whether gap analysis should rst consider all of the
the tool (and the vendor) is compliant to the rules standards objectives, and then the supplements
of DO-178C/ED-12C. With most of the activities, objectives. After that, any additional considera-
the user has to ensure the tool qualication tions may follow.
the vendor can support the activities but cannot
solve all the problems alone.
Additional Considerations
Objectives / Activities fullled?
Additional Considerations
Objectives / Activities fullled?
Yes
No
Adopt own
No
processes
No
No
Done
The best approach is to consolidate all the ob- ies some aspects by using a vulnerability ana-
jectives of DO-178C/ED-12C and the applicable lysis, the MBD&V Supplement describes examples
supplements. For each objective, it is necessary of models, and the Formal Methods Supplement
to make a statement on how compliance will be gives advice on which activities formal methods
achieved, along with identifying any applicable can be used for.
life cycle data items. Because the objective num-
bering scheme of the Annex A Tables of DO-178C/ Figure 17 shows a general workow used by SQS,
ED-12C and the Annex A Tables of the supple- considering the integration of the different sup-
ments is unique, the identication of the object- plements within the gap analysis.
ives and their document sources will be clear and
unambiguous. The most important aspect when using this work-
ow is to check which guidance needs to be ad-
As mentioned above, the supplements are sub- dressed with regard to the different supplements.
divided into guidance and guideline material. Various examples presented in the supplements
The guidelines include introductory material and show the usage of the guidelines and their ad-
FAQs. The OOT Supplement, for instance, clar- equate interpretation.
ifying the output of a development tool had not already use the methodologies and technologies
been within the scope of DO-178B, and it was time addressed by the supplements are invited to show
to consider this type of tool. compliance as soon as possible. If they fail to do
so, they run the risk of non-compliance in case
Object-oriented languages are very well known they have to re-certify their projects. This aspect
in commercial software development, but in the is the most challenging task of the new DO-178C/
avionic industry OOT is employed mainly at the ED-12, and all companies must address these is-
requirements and design level, for example us- sues at their earliest convenience. DO-178C/ED-
ing UML for a more descriptive representation. 12C experts and quality assurance specialists can
Object-oriented languages have not been used at support them and help them reach these goals in
all for the most safety-critical SW levels AC due time and within budget.
to the fact that compliance to the objectives of
DO-178B is not easily achieved. Additional sup-
porting papers (6) were generated over the last
ten years to close this gap, but without success.
With DO-178C and the OOT Supplement, guidance
now is straightforward, and all companies using
OOT are able to check their compliance.