Learn DO-178: Why is it important? How can it affect your company? These questions and more will be answered in this presentation, including information regarding the purpose of DO-178, Design Assurance Levels (DAL), objectives, and integral processes.
Questions? Email bd@aversan.com for more information.
3. RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification states:
The purpose of these documents is to provide guidance for the
production of software for airborne systems that perform their intended
functions with a level of confidence in safety that complies with
airworthiness requirements.
“
”
Purpose of DO-178C
4. Purpose of DO-178C Cont...
Guidance Includes:
Design Assurance
Objectives
Activities that provide a
means for satisfying these
objectives
Description of the evidence in the
form of software life cycle data
that indicate that the objectives have
been satisfied
Additional considerations (for
example, previously developed
software) that are applicable
to certain applications
5. System Safety Assessment
5
Design Assurance Level (DAL)
The Design Assurance Level (DAL) of a software component is defined by establishing how an
error in a software component relates to the system failure condition(s) and the severity of that
failure condition(s).
The Design Assurance Level establishes
the rigor necessary to demonstrate
compliance with DO-178C
The applicant should establish the
system safety assessment process to
be used based on certification authority
guidance. DO-178C does not describe
how the System Safety Assessment is
performed.
6. System Safety Assessment
6
References
For guidance on the system life cycle processes, refer to the following Aerospace Recommended
Practices (ARPs):
ARP4754 - Guidelines For Development Of Civil Aircraft and Systems
ARP4761 - Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems & Equipment
Functional Hazard Assessment (FHA)
(Preliminary) System Safety Assessment (SSA)
Fault Tree Analysis (FTA)
Failure Mode and Effects Analysis (FMEA)
7. Design Assurance Level
7
Failure Condition Categories
If the anomalous behavior of a
software component contributes to
more than one failure condition, then
the assigned DAL shall correspond
to the most severe failure condition.
Design Assurance Level Failure Condition Category
Level A Catastrophic
Level B
Level C
Hazardous
Major
Level D Minor
Level E No Effect
8. Failure Condition Categories
8
Large, Transport Aircraft
Catastrophic
Failure conditions which would result in multiple fatalities, usually with the
loss of the airplane
Hazardous
Failure conditions which would reduce the capability of the airplane or the
ability 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 task accurately or
…….completely, or
- Serious or fatal injury to a relatively small number of the
…….occupants other than the flight crew.
9. Failure Condition Categories
9
Continued
Major
Failure conditions which would reduce the capability of the airplane or the ability
of the flight 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 conditions
impairing crew efficiency, or discomfort to the flight crew, or physical distress to
passengers or cabin crew, possibly including injuries.
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.
No Safety 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.
11. Design Assurance Level
11
Design Assurance Objectives
Test Coverage
DAL A
Source Code (MC/DC)
Object Code that cannot be directly traced to Source Code
DAL B
Source Code (Decision)
Verification Independence
DAL C
Source Code (Statement)
Data and Control Coupling
Low-Level Requirements
DAL D
High-Level Requirements
12. Tool Qualification
12
Overview
• Software Development or Verification Tools are assigned a Tool Qualification Level (TQL) from TQL-1 to TQL-5
(similar to the DAL) that corresponds to the rigor to which the tool must be qualified.
• RTCA DO-330 “Software Tool Qualification Considerations” provides objectives, activities, guidance, and life cycle
data expectations.
• Vendors typically offer a Tool Qualification Package (TQP) meant to satisfy RTCA DO-330 objectives including:
Requirements, Test Procedures, and other life cycle data.
“Qualification of a tool is needed when processes of this document are eliminated,
reduced, or automated by the use of a software tool without its output being verified”
DO-178C States:
Important:
When gathering quotations for tool pricing, be sure to include TQP costs.
13. DO-178C Integral Processes
13
Embedded Systems
Certification Liaison
Establish communication with
certification authority and
provide compliance
substantiation
Software Development
Define a software life cycle,
decompose system requirements,
develop design details , and
implement the integrated solution.
Validation & Verification (V&V)
Provide assurance, detect and
report errors that may have
been introduced during
development process.
Configuration Management (CM)
Ensure each configuration item,
establish baselines, basis, and
processes. Document and
comply with the CM process.
Quality Assurance (QA)
Ensure plans, standards, and
processes are in compliance
with DO-178C. Reviews,
inspections and/or audits.
Start
Overview
14. DO-178C Integral Processes
14
Certification Liaison
The purpose of the Certification Liaison is to:
Establish communication with the certification authority
- Submit the Plan for Software Aspects of Certification for review.
- Resolve any issues identified by the certification authority.
- Gain agreement on the means of compliance through approval of the plan.
Provide compliance substantiation
- Resolve any issues identified by the certification authority during Stage of
…….Involvement Reviews.
- Submit life cycle data to the certification authority
- At a minimum: Plan for Software Aspects of Certification, Software
…….Configuration Index and Software Accomplishment Summary.
- Make available any other life cycle data or evidence of compliance upon
…….request.
15. DO-178C Integral Processes
15
Embedded Systems
Software Development
Define a software life cycle with entry/exit transition criteria for each phase
of the life cycle
- Waterfall, V-Model, Prototyping, Reverse-Engineering, etc.
Decompose system requirements into software (including derived)
requirements
Develop design details based on software requirements
- Algorithms, Interface Data, Source Code
Implement the integrated solution with formal build and load control procedures
- Executable object code running on representative hardware (i.e. the target)
16. DO-178C Integral Processes
16
Validation & Verification (V&V)
The purpose of Validation is to:
- Provide assurance that the decomposition of system requirements into
…….software requirements (high-level, low-level and derived) is correct and
…….complete.
The purpose of Verification is to:
- Provide assurance that the software implementation meets all of the
…….software (including derived) requirements.
Accomplished by:
- Detect and report errors that may have been introduced during the
…….development process.
- Reviews and Analysis (of Artifacts, Requirements, Design, Code and Tests).
- Normal, Abnormal and Robustness-based testing and simulation.
- Coverage Analysis:
- Requirements-based Testing Coverage Analysis.
- Structural Code Coverage Analysis
17. DO-178C Integral Processes
17
Embedded Systems
Configuration Management (CM)
The purpose of Configuration Management is to:
- Ensure each configuration item, (whether document, design data, code, test
…….materials or records of non-compliances) is labeled unambiguously so that a
…….basis is established for control and reference.
- Establish baselines (approved, recorded configured collection of one or more
…….configuration items) of configuration items to establish traceability between
…….configuration items
- Establish a basis for change control and status accounting
- Establish the process and activities for archive, retrieval and load control
Accomplished by:
- Documenting and complying with the CM process, accounting for the
…….defined control categories
- CC1 = Baseline, Impact Analysis, & Change Authorization
- CC2 = Identify & Archive
18. DO-178C Integral Processes
18
Embedded Systems
Quality Assurance (QM)
The purpose of Quality Assurance is to:
- Ensure that the plans, standards, life cycle processes/transition criteria and
…….artifacts produced by the development effort are in compliance with DO-178C.
- Conduct a conformity review of the software product
Accomplished by:
- Reviews, inspections and/or audits of:
- Plans and Standards
- Life cycle data, processes and transition criteria, ensuring compliance
…………with DO-178C and with the approved plans and standards
- Non compliances or deviations (both current and past), ensuring such
…………items are evaluated and recorded
- Build and load procedures
19. Independence
19
The separation of responsibilities which ensures objective evaluation.
3rd Party
Refers to intellectual independence, such as another individual, not departmental or corporate
independence.
What is it?
For Quality Assurance, independence is achieved by
ensuring that the reviewer of process compliance is
someone or something other than those that
performed the process.
(Including the authority to ensure corrective action.)
For Validation and Verification, independence is
achieved by ensuring that the reviewer of the
technical correctness of the data is someone or
something other than the developer of the data.
Important:
20. About Aversan
Offices
Aversan is a privately-held
Canadian company based out of
Mississauga, Ontario.
Staff
We have over 200 skilled
employees and are qualified as an
ITB SME.
Certified & Registered
Aversan is AS9100C and
ISO9001:2008 Certified. We are
also CGP, ITAR and JCP
Registered.
Experienced
Programs such as the A350
XWB/A380, F-35, F-22, Boeing
777/787/747, Embraer 450,
& many more.
Embedded System (SW & HW) Staff Augmentation IV&V Training & Consulting