Standards in Avionics System

Development
(Overview on DO-178B)

Ákos Horváth
Dept. of Measurement and Information Systems

Budapest University of Technology and Economics

Department of Measurement and Information Systems
 Abstract
 DO-178B (and DO-278) are used to assure safety
of avionics software. These documents provide
guidance in the areas of SW development,
configuration management, verification and the
interface to approval authorities (e.g., FAA, EASA)

2
 Agenda
 Introduction to DO-178B
 System Aspects
 Software Lifecycle Management
 Certification Artifacts and Techniques
 Future: DO-178C

3
 Overview
 DO-178B - Software Considerations in Airborne
Systems and Equipment Certification
 Standard of RTCA Incorporation (in Europe it is ED-
12B and standard of EUROCAE)
 Represents the avionics industry consensus to ensure
software safety
 Acceptable by FAA and EASA certification authorities
 „The FAA and the civil aviation community recognize
RTCA’S DO-178B as an acceptable means of
compliance to the FAA regulations for SW aspects of
certification.”
4
 History of avionics SW complexity
Ref: Subra de
400
A-310 (1983) Salafa and
350 Paquier
A-320 (1988)
300
A-340 (1993)
250
200
150
100
50
0
MIPS LOC Mbyte/10 Digital links

Exponential Both A380 and B 787 have

Growth 100’s of millions LOC
5
 History
 DO-178 in 1982
o Basic concepts of SW design assurance
o Three levels of SW safety
 DO-178A in 1985
o Concentrates on testing and configuration management
 DO-178B in 1992
o Five levels of SW safety
o From Testing focus  requirement-based
 DO-278 in 2002
o Interprets DO-178B to ground and space based-systems
 DO-178C in 2012
o Incorporates modern SW development and analysis
techniques
6
 DO178B Document Structure
System Aspects Relating To Overview of Aircraft and Engine
Software Development (Sec 2.) Certification (Sec. 10.)

SW Life Cycle Process Integral Process

SW Verification (Sec. 6.)
SW Life Cycle (Sec. 3.)
SW Configuration Mgt (Sec. 7.)
SW Planning (Sec. 4.)
SW Quality Assurance (Sec. 8.)
SW Development (Sec. 5.) Ceritfication Liasison (Sec. 9.)

SW Life Cycle Data(Sec. 11.)

Additional Considration (Sec. 12.)

ANNEX A & B (FAA checklists) Appendices

7
 Software Levels in DO-178B
 Different failure conditions require different
software conditions  5 levels

8
 Examples DO-178B Safety Levels
 Safety-Critical Levels C&D  Safety-Critical Levels A&B
o Anti-missile defense o Fly-by-wire controls
o Data mining o Auto-pilot
o Health monitoring o Air-traffic Separation Control
o Mission planning and o Glass Cockpit Information
implementation Display
o Mission simulation and o Radar
training o Jet Engine Control
o Network-centric operation o IFF (friend or foe)
o Real-time data recording and o Missile guidance
analysis o Missile launch
o Self-healing communication o Missile self-destruct
networks
o Telemetry
o Weapons targeting

9
 Objectives for Safety Levels
 Different levels of safety requires different objectives
to be fulfilled
o e.g., Level A 66, Level B 65
 Defined by 10 tables in ANNEX A
 Example: Table A-6 Objective 3.
Control
Applicability Category
Objective Output
by SW Level by SW
Level

Description Ref A B C D Descriptions Ref. A B C D

Executable Object Software Verification
Code compiles with Cases and Procedures
low-level 6.4.2.1. Software Verification 11.13 1 1 2
requirements 6.4.3. ●●○ Results 11.14 2 2 2
10
 Objectives for Safety Levels
 Different levels of safety requires different
How to store the
objectives
to be fulfilled evidence
o e.g., Level A 66, Level B 65
 Defined by 10 tables in ANNEX A
 Example: Table A-6 Objective 3.
Control
Independence is
Applicability Category
Objective
required (full means yes)Level Output
by SW by SW
Level

Description Ref A B C D Descriptions Ref. A B C D

Executable Object Software Verification
Code compiles with Cases and Procedures
low-level 6.4.2.1. Software Verification 11.13 1 1 2
requirements 6.4.3. ●●○ Results 11.14 2 2 2
11
 Objectives Distribution in DO-178B
45
Level A (66)
40
35 Level B (65)
30 Level C (57)
25
Level D (28)
20
15
10
5
0
Planning Dev. Verif. CM QA Cert.

12
 Objectives Distribution in DO-178B
Statement Coverage is
45
required (the only obj. Level A (66)
40 difference)
35 Level B (65)
30 Level C (57)
25
Level D (28)
20 Not just testing 
15 assuring the correctness
10 (reviews, testing and
5 analysis)
0
Planning Dev. Verif. CM QA Cert.

13
 Agenda
 Introduction to DO-178B
 System Aspects
 Software Lifecycle Management
 Certification Artifacts and Techniques
 Future: DO-178C

14
Typical Development road plan

15
System Development Process
 System Aspects and System Safety
 System requirements „have to be trusted”  start all
over if changed
 Failure Condition Categories (Catastrophic, major,
etc.)
 System Safety Assessment based on SAE ARP 4761
o Fault Tree Analysis, Dependence Diagram, Markov Analysis,
Failure mode and Effect analysis, Common Cause and
mode Analysis, etc.

 SW requirements derived from System requirements

 however, certain SW requirements can have
impact on System requirements!
17
 SW Safety
 SW Safety level based on potential failure conditions
o Level A  „failure in the SW would result in catastrophic
failure condition the aircraft”
 DO-178B defines the interface with the systems
 DO-178B software classes
o User-modifiable software
• Entertainment software
o Option-selectable software
• Cartography software
o Commercial Off-The-Shelf software
• RTOS
o Field-Loadable software
• Maintenance software
18
 Agenda
 Introduction to DO-178B
 System Aspects
 Software Lifecycle Management
o Planning
o Development
 Certification Artifacts and Techniques
 Future: DO-178C

19
 Software Life Cycle
 Planning should proceed all development activity
 Four building blocks : Example processes:
o Define Requirements (R) R-D-C-I  Waterfall
o Design the program (D) R-C-I-C-I-C-I-R-D-C-I  Rapid
prototyping
o Code the program (C)
R-I  Previous designed SW
o Integrate the program (I)
 Allows various development sequences

20
 The plans
 Five different plans
o SW Development Plan
o SW Verification Plan
o SW Quality Assurance Plan
o SW Configuration Plan
o SW Aspects of Certification
 Verification, management, quality assurance and
certification are overlaid on the defined
development process

21
 Software Planning
 Transition criteria
o „the minimum conditions, as defined by the software
planning process, to be satisfied to enter a process”
o Tells when you are done and can proceed
o Good characteristics: quantifiable, documented 
 Additional considerations
o COTS
o Previously developed components
 Environments
o Methods and notations
o Language with any constraints
o Development and verification tools
22
 Software Planning
 SW development standards
o SW requirements standard
• Language to be used (e.g., plain 500 English)
o SW design standards
• Complexity limits, exclusion of recursion, dynamic memory
allocation
o SW Code standards
• Syntax, semantics and constraints

23
 SW Development
 High-Level requirements
o Based on system analysis
and safety assessment
o Black-box view of the
software component
o System level considerations

o Functional requirements by
mode of operation
o Performance criteria
o Timing requirements
o Memory size constraints
o HW and SW interfaces

24
 SW Development
 Low-Level requirements
and Software Architecture
o SW requirements
o Derived from High-Level
requirements
o Design constraints
• Task allocation
• Algorithms
• Data Structures
o Input/output definitions
o Data and Control flows
o Resource management and
scheduling (e.g., partition
scheduling in ARINC 653)
o Design Methods

25
 SW Development
 Source Code
o Usually collection of „high-
level” language and
assembly
o Includes linker files, compile
commands etc.

 Executable
o Completely target computer
specific
o „machine readable”

 Final output is the

integrated system on the
target platform

26
 Agenda
 Introduction to DO-178B
 System Aspects
 Software Lifecycle Management
 Certification Artifacts and Techniques
o Verification
o Configuration Management
o Quality Assurance
o Certification/Approval Liaison
 Future: DO-178C

27
 Integral Process - Verification
 Two purposes
o Demonstrate intended function
o Demonstrate (to the extent possible) the absence of
unintended function
 Consists of
o Reviews
o Analysis
o Testing

 Important: The FAA or EASA representative needs to

accept all part of the verification process. (e.g., test
cases)
28
 Integral Process - Verification
 Reviews
o Qualitative assessment of the process or product
o Typical implementation: checklist
o Applied on all SW Development process step (HLR,
LLR, SA, SC, Test cases, etc.)
 Analysis
o Provide repeatable evidence of correctness
o Typical implementation: timing, stack analysis, data
flow and call-tree

29
 Traceability DO-178B
 Through the complete product REQ_HLR_SAFE_4_3_2_12:
life-cycle (30+ years) The take-off angle cannot be
more than 55°
 From requirements to byte code
(Level A)
REQ_LLR_TOM_3_67: in the eps_line
 Essential for maintainability method the calculated s1 variable

Traceability
 Back-annotation of errors represents the angle of attack

 Typical implementation:
o Excel 
o Rational RequisitePro
o Rational Doors
 Code generators usually gives
extensive support
 Hard in case of multiple
development tools
Integral Process – Verification Software Testing

32
Integral Process – Verification Software Testing
 Categories of Tests
o Normal range
o Robustness (abnormal range)
 Typical approaches
o Equivalence Classes and Boundary Values
o Multiple Iteration testing for time related functions
o Testing State Transitions
o Initialization with abnormal conditions
o Failure modes of input data
o Boundary values in loops, protection mechanisms

33
Integral Process – Verification Software Testing
 Structural Coverage
o Determine what software structure were not exercised
 Levels:
o Decision Coverage
o Statement Coverage
o Modified Decision Condition Coverage (MCDC)
• Each decision tries every possible outcome
• Each condition in a decision takes on every possible outcome
• Each entry and exit point is invoked
• Each condition in a decision is shown to independently affect the outcome of the decision
 Gaps
o Complier induced code (e.g., array bound checks)
o Deactivated code
o Dead code
 Performed on source code,
o except Level A
• Correspondence must be shown
• Complier optimization can introduce new code
 In addition, coverage of data and control coupling is required

34
Integral Process – Verification Software Testing
IF(C AND( A OR B))
THEN Foo();  Statement Coverage (SC)
Level C
o Each statement is executed
at least once

statement
Foo
# A B C Executed Coverage Minimum # of
1 0 0 0 NO Type Test Cases Possible Combinations
2 0 0 1 NO
3 0 1 0 NO Statement 1 4 or 6 or 8
4 0 1 1 YES
5 1 0 0 NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Integral Process – Verification Software Testing
IF(C AND( A OR B))
THEN Foo();  Decision Condition
Coverage (DC) Level B
o Each decision tries every
decision possible outcome
o Each entry and exit point is
invoke
Foo
# A B C Executed Coverage Minimum # of
1 0 0 0 NO Type Test Cases Possible Combinations
2 0 0 1 NO
3 0 1 0 NO Statement 1 4 or 6 or 8
4 0 1 1 YES
5 1 0 0 NO Decision 2 4 or 6 or 8 + Any NO
6 1 0 1 YES
7 1 1 0 NO
8 1 1 1 YES
Integral Process – Verification Software Testing
IF(C AND( A OR B))
THEN Foo();  Modified Decision Condition
Coverage (MCDC) Level A
o Each decision tries every possible
outcome
o Each condition in a decision takes on
every possible outcome
condition o Each entry and exit point is invoked
o Each condition in a decision is shown to
independently affect the outcome of the
decision
Foo
# A B C Executed Coverage Minimum # of
1 0 0 0 NO Type Test Cases Possible Combinations
2 0 0 1 NO
3 0 1 0 NO Statement 1 4 or 6 or 8
4 0 1 1 YES
5 1 0 0 NO Decision 2 4 or 6 or 8 + Any NO
6 1 0 1 YES
7 1 1 0 NO 2,3,4, and 6 OR 2,4,5
8 1 1 1 YES MCDC 4 and 6
Integral Process – Certification/Approval Liaison
 Communication between application developer
and certification authority
 Proposes compliance and obtain agreement on
the plan
 Software Accomplishment Summary
o Covers all areas
o Legal issues also (if something goes wrong the
developer is responsible!)

42
 SW Development Tools(DO-178B)
 Software Development Tools
o Can introduce errors into the final system
o Same objectives as the development process  verified on
the same level as the developed application!
o E.g., Scade Suite, Matlab Stateflow, Wind River Diab
compiler

Development Tool
 V&V tools (DO-178B)
 Software Verification Tools
o Can only fail to detect errors
o Tool operation req. Must be satisfied under normal
operating conditions
o e.g., static source code analyzer ASTRÉE, CAVEAT

Development Tool
 Agenda
 Introduction to DO-178B
 System Aspects
 Software Lifecycle Management
 Certification Artifacts and Techniques
 Future: DO-178C

46
 DO-178C
 DO-178C - Software Considerations in Airborne
Systems and Equipment Certification
 Awaited in 2011
 New certification for avionics software development
 Incorporates ”novel” development and verification
techniques
 Core is almost the same as DO-178B but
 Dedicated subgroups
o SG3: Tool Qualification
o SG4: Model Based Design and Verification
o SG5: Object-Oriented Technology
o SG6: Formal Methods

47
 DO-178C
 Object Oriented Technology
o C++ and Ada
o Safety Critical Java
o Restricted use (deterministic behavior)
 Tool Qualification
o Special rules for tools
o More than two categories
 Model Based Design and Verification
o Use of models for source code synthesis and verification
o Early model based validation
o Matlab Simulink (already used), AADL
o Largest and most cumbersome subgroup 
48
 DO-178C
 Formal methods
o Already used in many projects
o Mature technologies available
o Defines how certification credits can be earned by its
use
o Can be part of the Development process

o Typical tools
• Model checker
• Static code analyzers
• Theorem provers (only in limited scenarios)
49