8-2 Do-178

An overview of
Avionics System
Development
Part 2 – DO-178
Gilles MOTET / INSA Toulouse
[email protected]
https://www.safety-engineering.org/
https://seamonline.insa-toulouse.fr/
© Gilles Motet (2024)
Gilles MOTET / INSA Toulouse 1
Contents
Principles
Processes
Software Planning Process
Software Development Processes
Software Verification Process

Principles
DO-178 “Software consideration

in airborne systems and
equipment certification”
Concern the implementation

with software technologies of
critical avionics systems

Principles

Principles
ARP 4761 ARP 4754
Functions
lead to
Systems
which lead
to Items
To be
implemented
with
software
technology

Principles
Items requirements specify
A functional specification (from
ARP 4754), and
A Development Assurance Level
(DAL) which depends on the
failures effects (from ARP 4761)

Principles
Pay attention:
DAL does not depend on the
software component but depends on
the overall aircraft function it
implements
Ex. A software controlling a video
display is more critical in the
cockpit than in a cabin
DO 178 has to be used after ARP

4754 & 4761
So, a subprogram cannot be

labelled with a DAL
Principles
If a software component (or
item) contributes to more than
one failure condition then the
most severe category must be
considered
Note: Specific issues for

user modifiable software
(configurable for specific
airliners)
Loadable software and data (road
map)
Principles
Reminder:
No fault model
If A<B …
No failure rate: human errors
DO 178 based on 2 principles
No dirty pipe:
DO178 specifies requirements on the
software development activities:
quality of the processes
Clean pipe → Clean water (Wrong)
Safety case to have insurance of the
activities results: quality of the
products of the processes
Principles
DO178 is pragmatic
Means for implementing the two
previous principles are not 100%
efficient:
Their use increases the guarantee
Questions to be handled:
What is the effectiveness of the
technique?
Ex. Functional testing vs. Formal proof
What is the efficiency of the technique
use?
Ex. Functional testing vs. Formal proof
So, several means will be used

Principles
DO178 is pragmatic
Resources (time, people, money)
are limited:
Questions to be handled:
What effort is acceptable (effectiveness)
Ex. Completeness of test sequence:
● Not finite loops (“while”)
● Floating inputs
“Because we cannot demonstrate how well

we’ve done, we show how hard we’ve tried”
(John Rushby, Stanford Research Institute)
But expenditure are limited
Ex. A380: 4 lines of test / line of code!
100 MLoC embedded (1 BLoC developed)

Principles
Means are based on principles
Independence between development
team and assurance team
Verification of the verification
process results:
Does the test sequence execution
highlighted failures?
All these questions have to be

addressed for
providing an increasing
certification authority
confidence …
… at a reasonable cost
Contents
Principles
Processes

Processes
Faults come from human errors
Human activities divided into
processes (“divide to
conquer”)
1. Software Life Cycle process
2. Software planning process
3. Software development process
4. Software verification process
5. Software configuration process
6. Software Quality Assurance
process
7. Certification liaison process
Integral processes (4 to 7)
Processes
The standard does not impose a
structuration of the processes
into one software life cycle
To be defined for each project
The processes implementations

must be conform with
objectives specified in DO178
These objectives depend on the
DAL (effort to be done)
Specified in Annex. Example . . .
Processes
= Independence
Processes
Number of objectives
Failure With
Level Objectives
condition independence
A Catastrophic 66 25
B Hazardous 65 14
C Major 57 2
D Minor 28 2
E 0 0
• Number of objectives depends on the DAL

• Main difference concerns verification process
• Objectives similar for other processes
• Dependence depends on the DAL (Cost)

Processes
Processes
1. Software Life Cycle process
5. Software configuration process
6. Software Quality Assurance
process
7. Certification liaison process
Six elements to be specified
for each process…
Processes
for each process (1/2):
Ex. On the “Software
development process”
1. Assurance objectives
Ex. Detect a fault introduced
during development
2. Means to achieve objectives
Ex. Combination of reviews,
analysis and tests
3. Process inputs
Ex. Specification, code and
verification plan
Processes
for each process (2/2):
4.Process activities
Ex. Review of certain parts, test
for requirements
5. Process outputs (products)
Ex. Test sequence, procedure,
verification results
6. Transition criteria before the
process realization
Ex. When process inputs available

Processes
Generally, no means are
specified for implementing
process
Introduction of 3 processes:

Contents
Principles
Processes

Planning
Software Planning process aims
at producing software plans
and standards that direct the
software development process
and other processes
That is, means which will have

to be used for producing
software that
Satisfy system requirements and
Provide the level of confidence
consistent with the DAL
Planning
To be done in this process
Define
Activities of processes
Software life cycle
Tools for activities
Standards conform with safety
objectives
. . .
Examples . . .

Planning
DO178 provides guidance to
define activities of processes
Two guidance examples
1. “Methods and tools should be
chosen that provide error
prevention in the development
processes.”
Example 1: Ada instead of C
Pop(Element *List, Element *E)
Pop(List: in Type_List,
E: out Type_Element)

Planning
Example 2: Exclude hazardous
features. Ex. No global variables
Example 3: Guidelines for language
use
“Ada style guide” WikiBook (2013) 329p
“MISRA C” Motor Industry Software
Reliability Association (2012)
Cf. Fault prevention

Part 4 of “Software Dependability”

Planning
Second example of guidance
2.“The software planning process
should provide coordination
between the software development
and integral processes”
Integral = verification,
configuration, quality assurance
Ex. At what location in the

development process, an action of
the verification process has to
be done?

Planning
The Software plans to be
developed include (examples):
Software development plan which
defines the software life cycle
and the software development
environment (tools…)
Software verification plan: means
to be used in the verification
process to check that its
objectives are satisfied

Contents
Principles
Processes

Development processes
DO178 does not impose one
development process
It proposes 4 processes
and their (->) products
Requirements process
-> High-level requirements
Design process
-> Architecture & Low-level
requirements
Coding process
-> Source code
Integration process
-> Executable code

DO178 does not impose one
development process
So, for each specific
development, a Software
Development process has to be
defined in the Software
Planning Process and expressed
in the Software Development
Plan.
Combining the 4 previous
processes: V, spiral, etc.

DO178 specifies guidelines to
check the 4 processes
One example of guideline given

for each process:
1.Requirement process
2.Design process
3.Coding process
4.Integration process

check the 4 processes (1/4).
Example on Requirements
process -> High-level
requirements
“The system functional and

interface requirements that are
allocated to software should be
analysed for ambiguities,
inconsistencies and undefined
conditions”
So, requirement engineering tools
have to be used

Example on Design process ->
Architecture & Low-level
requirements
“Low-level requirements and

software architecture should be
traceable”
So, traceability tools have to be
used

Design process.
Redundant architecture may reduce
the DAL

Design process.
DO178 notices 2 types of
redundancies:
N-Version
Safety monitoring (detection +
handling)
Recovery blocks
Retry mode
Termination mode
Does not mention “Functional safety”
As only failures are handled
Details in Part 6 (Fault tolerance)

of “Software dependability”
Example on Coding process ->
Source code
“Source code should implement

the low level requirements and
conform to architecture”
Example 1. Typing: 1 design

concept = 1 program data type
Example 2. Preserve the behaviour
evt1 State:=1;
1 loop
2 case state is
evt2 1: wait(evt1);
evt1 evt2 State:=2;
2: wait(evt);
3 if evt=evt1 State:=3;
4
loop evt1 else State:=4;
wait(evt1); 3: wait(evt2);
wait(evt); State:=1;
if evt=evt1 then wait(evt2); 4: wait(evt1);
else wait(evt1); State:=3;
wait(evt2): end case
end if; end loop;
end loop; Not automatic
No traceability
Example on Integration process
-> Executable code
Traceability between source

code and executable code:
No optimization of the compiler
No deactivated code (reuse of
subprograms whose statements are
not all executable)
Implementation of case (Ada) or switch (C) statement
case Choice is
when Choice = 1 => Treatment_1;
. . .
when Choice = N => Treatment_N;
when others => Treatment_others;
end;
Implementation 1: Branching by address table

1 -> @Treatment_1
N -> @Treatment_N
N+1 -> @Treatment_others
M -> @Treatment_others
Fast but unsafe
Example / programming language / implementation of case
case Choice is
when Choice = 1 => Treatment_1;
. . .
when Choice = N => Treatment_N;
when others => Treatment_others;
end;
Implementation 2: Successive if
if Choice = Choice_1 then T_1;
elsif Choice = Choice_2 then T_2;
...
elsif Choice = Choice_N then T_N;
else Treatment_Others;
end if;
Slow but safe
Contents
Principles
Processes

Software verification
Application of the Software
Verification Process as defined
by the Software Planning Process
The standards specifies 5 classes
of verification defining their
Objectives
Applicability (A, B, C, D)
Products
(outputs)

Five classes of verification:
1. Verification of outputs of
software requirements process
software design process
software coding and integration
process
4. Testing of outputs of integration
process
5. Verification of verification
process results

Verification of outputs of
software requirements process

software design process (1/2)

software design process (2/2)

software coding & integration
process

Testing of outputs of
integration process

Verification of verification
process results

DO178 highlights some
approaches
Traceability between requirements
and their implementation
Review = Qualitative assessment
of correctness
Analysis = repeatable evidence of
correctness
Test analysis
Requirement based (functional
testing)
Structure based (structural testing)

See techniques in Part 5
(“Fault removal”) of “Software
dependability”
Reminder: List of techniques:
1. Static & structural analysis
- Review (walkthrough, inspection)
- Quantitative analysis
2. Static & functional analysis
- Formal proof
- Fault tree method
- Data flow analysis

List of techniques:
3. Functional testing (dynamics)
4. Structural testing
- Condition
- Decision
- C/DC
- MC/DC

To summarize / To remind
Inputs are items (functional
specification + DAL) to be
implemented
Seven processes have to be

implemented beforehand including:
Software development process, and
Software verification process
Taking numerous objectives associated with
the DALs
Then they have to be applied to

the items
And their applications checked
To summarize / To remind
The implemented processes must
be
Effective (achieve the objectives)
Efficient (acceptable resources:
humans, money, time)
No « silver bullet »
Best effort (cf. « Software
dependability »)
Negociation with certification
authorities to obtain their
confidence

Questions?
An overview of
Avionics System Development
Part 2 – DO-178
Gilles MOTET / INSA Toulouse

[email protected]
https://www.safety-engineering.org/
https://seamonline.insa-toulouse.fr/
© Gilles Motet (2024)

8-2 Do-178

Uploaded by

Copyright:

Available Formats

8-2 Do-178

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8-2 Do-178

Uploaded by

Copyright:

Available Formats

An overview of

Software Planning Process

Software Development Processes

Software Verification Process

DO-178 “Software consideration

Concern the implementation

Gilles MOTET / INSA Toulouse 3

Gilles MOTET / INSA Toulouse 4

Gilles MOTET / INSA Toulouse 5

Gilles MOTET / INSA Toulouse 6

DO 178 has to be used after ARP

So, a subprogram cannot be

Note: Specific issues for

Their use increases the guarantee

So, several means will be used

“Because we cannot demonstrate how well

Gilles MOTET / INSA Toulouse 11

All these questions have to be

Software Planning Process

Software Development Processes

Software Verification Process

The processes implementations

• Number of objectives depends on the DAL

Gilles MOTET / INSA Toulouse 17

Gilles MOTET / INSA Toulouse 20

Gilles MOTET / INSA Toulouse 21

Software Planning Process

Software Development Processes

Software Verification Process

That is, means which will have

Gilles MOTET / INSA Toulouse 24

Gilles MOTET / INSA Toulouse 25

Cf. Fault prevention

Gilles MOTET / INSA Toulouse 26

Ex. At what location in the

Gilles MOTET / INSA Toulouse 27

Gilles MOTET / INSA Toulouse 28

Software Planning Process

Software Development Processes

Software Verification Process

Gilles MOTET / INSA Toulouse 29

Gilles MOTET / INSA Toulouse 30

Gilles MOTET / INSA Toulouse 31

One example of guideline given

Gilles MOTET / INSA Toulouse 32

“The system functional and

Gilles MOTET / INSA Toulouse 33

“Low-level requirements and

Gilles MOTET / INSA Toulouse 34

Gilles MOTET / INSA Toulouse 35

Details in Part 6 (Fault tolerance)

“Source code should implement

Example 1. Typing: 1 design

Traceability between source

Implementation 1: Branching by address table

Software Planning Process

Software Development Processes

Software Verification Process

Gilles MOTET / INSA Toulouse 43