Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 14

INTRODUCTION TO DO-178

“Software Considerations in Airborne Systems


and Equipment Certification”
Appendices (A,B,C,D&E)
SOFTWARE LEVELS
• LEVEL A:CATASTROPHIC
• Failure results in preventing the flight from continuing safely or
landing.
eg:engine controller software
• LEVEL B:HAZARDOUS
• Failure results to series or fatal injuries to the aircraft occupants.
eg:Priliminary Flight Displays(PFDs)

• LEVEL C:MAJOR
• Failure results in causing discomfort or injuries to the occupants.
eg:Flight Managment System(FMS),auto pilot landing systems.

• LEVEL D:MINOR
• Failure results in causing some inconvenience to the occupants.
eg:transponders.

• LEVEL E:NO EFFECT


eg:In-flight entertainmant functions and satellite phone internet access
DO 178B Assurance levels

Software Level Objectives Failure Level

Level A 66 Catastrophic

Level B 65 Hazardous

Level C 57 Major

Level D 28 Minor

Level E 0 No Effect
OBJECTIVE DISTRIBUTION
PROCESSES & OUTPUTS

• DIVIDED INTO 5 MAIN PROCESS

– Software Planning

– Software Development

– Software Verification

– Software Configuration Management

– Software Quality Assurance


Software Planning Process
• Purpose is to determine what will be done to produce
safe, requirements-based software.
• Activities addressing system requirements and
certification levels
• Inter-relationships between
processes,sequencing,feedback and transition criteria
• Life cycle environment, including methods and tools

• Expected outputs:
– Plan for Software Aspects of Certification (PSAC)
– Software Development Plan(SDP)
– Software Verification Plan(SVP)
– Software Configuration Management Plan(SCMP)
– Software Quality Assurance Plan(SQAP)
– Software Requirements, Design & Coding
Standards(SRDCS)
Software Development Process
• The software development process is broken
into four sub-processes:
– Software Requirements Process
• High-level requirements in relation to function, performance,
interface and safety.
– Software Design Process
• Low-level requirements used to implement the source code.
– Software Coding Process
• Production of source-code from the design process.
– Integration Process
• Integration of code into a real-time environment.
Expected outputs

• Software requirements data(SRD)


• Software design description(SDD)
• Source code
• Executable object code
• Traceability from system requirements to all source code
or executable object code is typically required
(depending on software level)
Software Verification Process
• The purpose is to identify and report any errors resulting from the
development process
• The verification process objectives can be met with reviews,
walkthroughs, unit testing, integration testing and more

• Expected outputs:
• Software verification cases and procedures (SVCP)
• Software verification results (SVR)

– Review of all requirements,design and code


– Testing of executable object code
– Code coverage analysis
• Anaysis of all code and traceability from tests and results to all
requirements is typically required (depending on software level)
Configuration Managment Process
• The purpose is to establish secure and effective
configuration control for all artifacts.
• The following activities are done within the
process:
– Configuration Identification
– Change Control
– Baseline establishment
– Archiving of the software

• Expected outputs:
– Software configuration index(SCI)
– Software life cycle environment configuration index (SECI)
Quality Assurance Process
• The purpose is to provide assurance that the software life
cycle is going to yield quality software.
• This process performs reviews and audits to show compliance
with DO-178B
• Each process is analysed to show that each process is
producing the expected outputs.
• Any change from originally proposed plans are reported,
evaluated and resolved to ensure process integrity.

• Expected outputs:
– Software quality assurance records(SQAR)
– Software conformity review(SCR)
– Software accomplishment summary(SAS)
CERTIFICATION
• DO-178B very specifically addresses the following which directly
affects product development.
– Certification of a product applies only to it's finished result.

– Certification includes approval of all systems and subsystems,


hardware, software, firmware, development tools, production and testing
of the product.

– Certification is done on the individual application of the product

– Coding practices must be certified to ensure things like "dead code" are
not allowed.
– Certification requires that 'full testing' of the system and all of it's
components (including firmware) be done on the target platform in the
target environment.
" Thank You..."

You might also like