Scribd
Upload
347 views5 pages

Do178b Do-178b

Airworthiness guidelines

Uploaded by

abhishekmshimnit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
347 views5 pages

Do178b Do-178b

Airworthiness guidelines

Uploaded by

abhishekmshimnit
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

DO178B

DO-178B enforces the stringent and rigorous process guidelines governing the entire
development life cycle of embedded software in airborne equipment.

DO178B is primarily a process oriented document. For each process, Objectives are defined and
a way to satisfying these objectives.

You should remember following abbrevations:


DO178B: DO (Document) 178 (Number) B (Version)
RTCA: Radio Technical Commission for Aeronautics
EUROCAE: European Organization for Civil Aviation Equipment
JAA: Joint Aviation Authorities
FAA: Federal Aviation Administration
DER: Designated Engineering Representative

Certification
For civil aerospace applications, certification is required for systems whose failure will put
human life at risk. The Federal Aviation Administration (FAA) in the US and the European
Aviation Safety Agency (EASA) in Europe recognize DO-178/ED-12 (Software Considerations
in Airborne Systems and Equipment Certification) as an acceptable standard for the approval of
software in airborne systems. DO-178/ED-12 are prepared and maintained by the RTCA and
European Organization for Civil Aviation Electronics (EUROCAE), and these are the most
stringent software certification standards in the world.

Critical Categories

Level Failure Condition


A Catastrophic
B Hazardous
C Major
D Minor
E No effect

Example of software in Aircraft for each categories

Level A : Flight control system, Engine control system


Level B: Flight Management System (FMS)
Level C: The collection of critical internal BITE faults or other faults that INOP indications
Level D: Functionalities related to maintenance - The maintenance functionality consists of the
following items: Flight History, RS-232 terminal interface, keyboard monitor commands, and
self-test reporting.
Level E: Entertainment equipment

DO178B processes:

Software Planning Processes – How product is to be developed?

 PSAC (Plan for software Aspects of Certification)


 SDP (Software Development Plan)
 SVP (Software Verification Plan)
 CMP (Software Configuration Management Plan)
 SQAP (Software Quality Assurance Plan)
 TQP (Tool Qualification Plan)
 Requirements/Design/Code Standards

Software Development Processes – Create the product

 Requirement Process
 Design Process
 Coding Process
 Integration Process

Integral Processes – Ensures the Product is correct

 Software Configuration Management Process


 Software Quality Assurance Process
 Software Verification Process
 Certification Liaison Process

Verification

Requirement based test coverage analysis – The objective of this analysis is to determine how
well the requirements based testing verified the implementation of the software requirements.
This analysis show that -

 Test cases exist for each software requirements


 Test cases satisfy the criteria of normal and robustness testing

Statement coverage analysis – Every statement in the program has been invoked at least once.

Decision coverage - Every point of entry and exit in the program has been invoked at least once
and every decision in the program has taken on all possible outcomes at least once.

Modified condition/Decision coverage - Every point of entry and exit in the program has been invoked at
least once, every condition in a decision in the program has taken all possible outcomes at least once, every
decision in the program has taken all possible outcomes at least once, and each condition in a decision has
been shown to independently affect that decision's outcome. A condition is shown to independently affect a
decision's outcome by varying just that condition while holding fixed all other possible conditions.

Coupling - The degree of dependence of one module upon another; specifically, a measure of the chance that
a defect in one module will appear as a defect in the other, or the chance that a change to one module will
necessitate a change to another.

Data Coupling – The dependence of a software component on data not exclusively under control of that
component.
Control Coupling – The manner of degree by which one software component influences the execution of
another software component.

Verification Scope for each software critical level

Level A:

 Requirement based test coverage analysis


 Statement coverage analysis
 Data coupling and control coupling
 Decision coverage
 MC/DC (Modified Condition/Decision coverage)

Level B:

 Requirement based test coverage analysis


 Statement coverage analysis
 Data coupling and control coupling
 Decision coverage

Level C:

 Requirement based test coverage analysis


 Statement coverage analysis
 Data coupling and control coupling

Level D:

 Requirement based test coverage analysis

Level E:

 No specific requirement

How many test cases need to write for MC/DC coverage?


- N+1 test cases where N is number of conditions

In below example one by one each input is changed which impact the outcome.

(A && B) || C

Here A, B and C are conditions and “(A && B) || C” is decision.

A B C Result Comment
T T F T Base condition
F T F F A is changed, Results also changed
T F F F B is changed, Results also changed
T F T T Now Test case 3 is using as base condition
and C is changed. Results also changed
What is structural and requirement coverage?
Structural coverage analysis provides a means to confirm that requirements based test cases
exercised the code structure.

Requirements based testing involves verifying that the software meets the application's
requirements. Each requirement has a set of tests demonstrating the successful implementation
of that requirement.

What is s/w configuration management process?


software configuration management (SCM) is the task of tracking and controlling changes in the
software. Configuration management practices include revision control and the establishment of baselines.

What is avionics dead code?


DO-178B dead code is executable (binary) software that will never be executed during run time
operations. D0178B generally does not allow for the presence of dead code: it must be removed.
Dead code does not trace to any software requirements, hence does not perform any required
functionality.

What is avionics deactivated code?


DO-178B deactivated code is executable (binary) software that will not be executed during run
time operations of a particular software version within a particular avionics box; however the
code may be executed during maintenance or special operations or be executed within a
different or future version of the software within a different configuration or avionics box.
Unlike dead code (see above), deactivated code may be left in the source baseline. Special DO-
178B deactivated code aspects must be followed.

What is Control category 1 (CC1) and CC2 configuration?


If an artifact is CC1 then it must have all those attributes in the table in section 7 means it needs
to have baselines, change management, etc. If an item/artifact is CC2 then it doesn't need all of
those items. It really only needs to be retained. Simply put a CC1 item needs to be tracked
where as a CC2 item needs to be stored. Typically a CC2 items tends to be "one-shots" like
meeting minutes, reports, problem reports themselves, etc. Whereas CC1 items tend to be
documents that need to be maintained, tracked and baseline. Is it a big deal in DO178B, well
yes. If you don't maintain the CC1 data as per the table, one isn't following the process and
hence can't build the substantiation data required.

What is Stage on Involvement (SOI) review/audit?


The purpose of the software review is to ensure compliance to the DO-178B objectives and
other applicable software policy, guidance, and issue papers. To assess compliance, there are
typically four Stages of FAA Involvement throughout the software life cycle of a project. The
four types of SOI reviews
(1) Planning Review (SOI 1)
(2) Development Review (SOI 2)
(3) Verification Review (SOI 3)
(4) Final Review (SOI 4)

What is the total list of potential deliverables I will need to create for DO-178B
certification?
The following table lists the documents and records you may need to provide for a DO-178B
certification:

DO-178B Software Life Cycle Data List


Document Title Type Section
PSAC Plan for Software Aspects of Certification Document 11.1
SDP Software Development Plan Document 11.2
SVP Software Verification Plan Document 11.3
SCMP Software Configuration Management Plan Document 11.4
SQAP Software Quality Assurance Plan Document 11.5
SRS Software Requirements Standards Document 11.6
SDS Software Design Standards Document 11.7
SCS Software Code Standards Document 11.8
SRD Software Requirements Data Document 11.9
SDD Software Design Description Document 11.10
Source Code Software 11.11
Executable Object Code Software 11.12
SVCP Software Verification Cases and Procedures Document 11.13
SVR Software Verification Results Records 11.14
Software Life Cycle Environment Configuration
SECI Document 11.15
Index
SCI Software Configuration Index Document 11.16
PRs Problem Reports Records 11.17
Software Configuration Management Records Records 11.18
Software Quality Assurance Records Records 11.19
SAS Software Accomplishment Summary Document 11.20

What is Equivalence partitioning and Boundary value analysis?


Equivalence partitioning is a method for deriving test cases. In this method, equivalence classes
(for input values) are identified such that each member of the class causes the same kind of
processing and output to occur. The values at the extremes (start/end values or lower/upper end
values) of such class are known as Boundary values. Analyzing the behavior of a system using
such values is called boundary value analysis (BVA).

What is tool qualification?


Software can automate, assist or otherwise handle or help in the DO-178B processes. If any
DO178B process is removed using tool then that tool must be certified.

You might also like