Saturday, August 3, 2013

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
SECI Software Life Cycle Environment Configuration Index Document 11.15
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.


10 comments:

  1. Its a nice one.
    Still so many other things(Important) related to DO178B can be added.Example: 1. What is the criterian followed to name the level of a software and who will do that?
    2.How a system can have a software of different Levels?
    3.How development cycle as defined in DO178B makes a robust software?
    4Can these criterions be applied to other ssytems which are not airborne.
    5.What does each documents listed in the blog does and thier importance to the differnt engineers( Developers, System designers, Certifiation Engineers, Verification engineers)

    6.Is testing can be automated?

    ReplyDelete
  2. Thanks Vinay. I will add what have you suggested.

    ReplyDelete
  3. This is really helpful. If you can Provide some examples where ever possible then it will be more helpful.

    ReplyDelete
  4. great job, really this is helpful

    ReplyDelete
  5. you can help other by adding the below topics detail,
    1. CC DC
    2. V module

    ReplyDelete
  6. Yupss, Thanks to the admin who provided very good and useful information for many people. Hopefully in the future it will be more advanced and will share more important information in the future.
    I have some website official and i hope you'll wont to come and visit our website officlian in HTTP://165.22.52.72/ and WWW.DELIMAPOKER.SITE and then TOL PREDICTION

    ReplyDelete
  7. Thank you for this blog post. It was really helpful. But, I just went through a post which was having more comprehensive DO-178C interview questions and answeres - https://thecloudstrap.com/do178c-interview-questions/

    ReplyDelete