SECTION OF DO178B

1 introduction

2 system aspects of relating to software development

3 software life cycle

4 software planning process

5 software development process

6 software verification

7 software configuration management

8 software quality assurance

9 certification liaison

10 overview of aircraft and engine certification

11 software life cycle data

12 additional consideration

Software life cycle data

1 plan for software aspects of certification

2 software development plan

3 software verification plan

4 software configuration management plan

5 software quality assurance plan

6 software requirement standard

7 software design standard

8 software code standard

9 software requirement data

10 software design description

11 source code

12 executable object code

13 verification cases and procedure

14 verification results
15 software configuration index

16 problem reports

17 software configuration management record

18 software quality assurance record

20 software accomplishment summary

NOTE: there are 66 objectives or do178b

Objectives of verification of output of code process

1 source code complies with high level requirement

2 source code complies with software architecture

3 source code is verifiable

4 source code conform to software code standards

5 source code is traceable to low level requirements

6 source code is accurate and consistence.

7 output of software integration process is correct and correct.

Do178b is a air born system and equipment certification guidelines document focuses on software
process and objectives which consist of software life cycle from the planning to certification liaison and
software levels based on the failures which is also known as design assurance levels in which level A is
high risk level and level E is low risk level. it is developed by RTCA (radio technical commission for
aeronautics) published in 1992. Basically it insures the software reliably in airborne environment and it is
use as worldwide avionics software guidelines.

DO178C is a updated version of DO178B with more objectives publish in 2011

Important questions of DO178B

1 what is DO178B?

It is a Software considerations in air born system and equipment certification is a guidance document
that focuses on software process and objectives.

It is developed by a RTCA (radio technical commission for aeronautics)

Do178b provide guidelines for the production of software for air born system and equipment that
perform its intended functionality with a level of confidence is safety that compiles with air worthiness
requirements

FAA mandates that the any software system installed on commercial aircraft must meet DO178B

Do178b is in the form of

1 objectives for software life cycle process

2 description of activities and design consideration for achieving those objectives

3 description of evidence that indicate that the objectives have been satisfied

2 DO178B is standard or guideline?

Although technically a guideline it was a de facto standard for developing avionics software systems
until it was replaced in 2012 by DO178C.

3 what is software life cycle process or processes of phases?

Software life cycle process consist of

1 planning process: in this process the objectives like

1 process activities, plans, standards are defined

2 software life cycles, development environment, method, tools are defined

3 transition criteria between processes are established

4 all objects of DO178B guidelines are defined

Deliverables:

1 plan for software aspects of certification

2 software development plan

3 software verification plan

4 software configuration management plan

5 software quality assurance plan

6 software requirement standard

7 software design standard

8 software code standard

2 development process or SDLC:

 1 requirement process: in this process the software requirement is collect from the customer in the
form of customer requirement specification (CRS) and convert in to software requirement specifications
(SRS) and provided to the technical team.

2 design process: in this process based on the software requirements the architectures develops low
level and high level design of the software which is software architecture and designs of each
component of the software.

3 coding process: in this process developer start writing the code by seeing low level design and
software requirements.
 4 integration process: it is the process of integrating different sub systems software in to single system
in to single system and performing system testing on it.

3 integral process:

1 verification process:

2 configuration management process:

SCM: supply chain management

3 software quality assurance process:

4 certification liaison:

4 what is dead code: the code that never be executed at run time is called dead code

6 what is deactivated code: it is a executable code that is design in such way that it will be only execute
in certain configuration.

What is all coverage of requirement based testing of all levels?

Level A: requirement based testing coverage analysis + statement coverage analysis + data coupling and
control coupling analysis+ decision coverage analysis+ mc/dc coverage analysis

Level B: requirement based testing coverage analysis + statement coverage analysis + data coupling and
control coupling analysis+ decision coverage analysis

Level C: requirement based testing coverage analysis + statement coverage analysis + data coupling and
control coupling analysis

Level D: requirement based testing coverage analysis

Level E: no specific requirement

Why structural coverage analysis is perform?

It is performed to identify any uncover code due to

1 deficiency in MCDC coverage, block coverage, condition coverage, statement coverage, decision
coverage, loop coverage, function coverage or function call coverage.

2 to identify and remove dead code.

3 to identify and descript inactivated code.

What if FAA?

Federal aviation administration the organization which is responsible for controlling air traffic safety in
US it takes do178b as an standard.
What are the planning documents?

1 plan for software aspects of certification

2 software development plan

3 software verification plan

4 software configuration management plan

5 software quality assurance plan

6 software requirement standard

7 software design standard

8 software code standard

8 what is design description?

The purpose of the software design document is to provide a description of the design of a system fully
enough to allow a description of the design of a system fully enough to allow for software development
to proceed with an understanding of what is to be built and how it is expected to build

18 what are the verification strategies mentioned in DO178B?

19 can you explain the relationship between the software levels and failure conditions?
21 what is the major difference between the software level A and B?

MCDC

22 can you explain structural coverage objective for each software levels?

Level A: statement coverage analysis + data coupling and control coupling analysis+ decision coverage
analysis+ mc/dc coverage analysis

Level B: statement coverage analysis + data coupling and control coupling analysis+ decision coverage
analysis

Level C: statement coverage analysis + data coupling and control coupling analysis

Level D and E no specific objective for structural coverage

Level E: no specific requirement

24 what is structural coverage analysis and what it is performed?

It is perform to check the how much portion of a program will get execute and to find the defects like

1 mission of requirement

2 mission of test case

3 to find out dead code

4 deactivated code

5 deficiency in code coverage due deficiency in MCDC, statement, condition etc.

6 overflow and underflow of variables with respect to given range

25 is DO178B is applicable for both military and civilians aircraft?

The guideline applies only for commercial aircraft’s and there are separate military standards but and at
times defense may use it.

Number of objectives in do178b

1 planning 7

2 development 7

3 verification 40

4 SCM 6

5 SQA 3

6 certification liaison 3

Level A 66 objectives
what are objectives for different levels?

A: 66 catastrophic

B: 65 hazardous

C: 57 major

D: 28 minor

E: 0 no effect

What are the difference between D0178B and ISO26262?

DO178B use for avionics development ISO26262 use of automotive development

It is guideline (recommend) It is standard (should follow)
It include only software It include both hardware and software
Flexible to define software lifecycle Prescriptive (fixed)

Sections or chapters of ISO26262

1 vocabulary

2 management of functional safety

3 concept phase

4 product development: system

5 product development: hardware level

6 product development: software level

7 production and operation

8 supporting processes

9 ASIL-oriented and safety-oriented analyses

10 guideline on ISO 26262

What is functional safety?

Functional safety is defined as the “absence of unreasonable risk due to hazards(means harm to the
passenger or vehicle) caused by malfunctioning behavior(unintended errors on system failures) of
electrical/electronic system.

Where this functional safety applies in phases:

All phases of product development it should apply

EX:

Requirement phase
Design phase

Implementation phase

Testing phase

Verification and validation etc.

Why ISO26262 important?

ISO 26262 standards provides safety to passengers driver and vehicle safety(to reduce damage of
vehicle)

It we apply safety standards we can avoid and control systematic failures.

We can also detect hardware failures, before vehicle production.

What is ASIL?
ASIL: automotive safety integrity level it helps to find out criticality of individual components

Based on the ASIL level we have to defined our product criticality level there are some activities that are
mandatory for some levels.

Four ASIL Levels (automotive Hazard levels):

Lower->ASIL-A-> Rear light

Moderately low->ASIL-B-> Head Lights, Rear view camera

Moderately high->ASIL-C-> Engine Management, Active suspension

Highest->ASIL-D-> Power steering, Airbag, Antilock Braking.

Reference:

Quality management level lesser than ASL A level it involve less risk associated with and it is similar to
ASL A

QM represents hazards that do not dictate any safety requirements

The safety critical mean that the failure of these components can risk the driver or the passenger life

ASIL – A is minimum level of risk and ASIL – D is maximum level of risk

Hazard analysis: identifies the unintended situations that could occur in time of failure

Risk analysis: deals with the possibility severity and controllability of a component failure or
malfunctions.

Risk analysis involves 3 factors for both software and hardware

1 exposure

2 severity
3 controllability

how to measure ASIL levels:

it will measure based on three parameters

1 severity: intensity of the damage and it’s impact on the vehicle and the occupants and it is measure in
S0, S1, S2, S3

It measure damages due to system failure on people and vehicle.

S0 no injuries

S1 light to moderate injuries

S2 severe to life-threatening (survival probable) injuries

S3 life-threatening (survival uncertain) to fatal injuries or incidents

2 exposer: probability of occurrence of the fault in the component and it is measure in E0,E1,E2,E3,E4

it says how frequent it happens.

E0 incredibly unlikely

E1 very low probability (possibility) (injury could happen only in rare operating conditions)

E2 low probability (possibility)

E3 medium probability (possibility)

E4 high probability (injury could happened under most operating conditions)

controllability: it is measure in C0,C1,C2,C3

it measures hazard or failure occurs, how much possibility to control by driver or external measures.

C0: controllable in general

C1: simply controllable

C2: normally controllable (most drivers could act to prevent injury).

C3: difficult to control or uncontrollable

Reference:

Based on this ASIL levels the ISO26262 compliance get strict from one level to another level

And based on this maximum risk levels they will derive what are the tools use to in development and
testing process and what are the quality process we need to maintain to provide the automotive safety
standards.

Safety lifecycle

0 risk assessment
1 safety planning

2 specification

3 validation planning

4 realization

5 verification

6 code simulation

7 validation

Steps involve in determination of ASL for anti breaking system (ABS)

1 malfunctioning: ABS system failure

2 hazard analysis: what unintended situations could happen

3 risk analysis: how likely the hazard to happen

How harmful is the hazard

How controllable is the system if the hazard occur

4 ASL determination:

What level of safety does the system need?

How likely can the malfunction be? Failure rate

How often does the system need to catch it and get to a safe situation?

Effectiveness of failure detection

1. What is ISO 26262?

ISO 26262 is an international standard for the functional safety of electrical and electronic
systems in automobiles. It was created in order to ensure that these systems are designed and
built in a way that minimizes the risks of injury or death in the event of a failure.

Reference points:

ISO26262 is derived from ICE61508 SIL

It use for vehicles which include cars, bikes, scooters.

Draft international standard DIF in mid-2009 and Final draft internal standard FDIF in early-2011 1 st
edition

It applies to electric/electronic systems on road vehicles.

ASIL levels (automotive safety integrity levels)

Level A lower safety level

Level D higher safety level

2. Can you briefly explain the history of ISO 26262?

ISO 26262 is a standard that was created in response to the growing number of safety-critical
systems in automobiles. With the increase in electronic and software components in cars, there
was a need for a standard that would address the safety concerns associated with these systems.
ISO 26262 was created in 2011 and has since been updated to include additional requirements
for safety-critical systems.

3. How do you explain the importance of ISO 26262 to a non-technical person?

ISO 26262 is an international standard for the functional safety of electrical and electronic
systems in vehicles. It is important for ensuring that these systems are safe for use, and that they
will not cause any accidents or injuries.

4. Can you give me some examples of situations in which knowledge of ISO 26262 would be
helpful?

There are a few different situations in which having knowledge of ISO 26262 would be helpful.
For example, if you are working on a project that involves developing safety-critical systems for
automobiles, then it would be important to be familiar with the standard in order to ensure that
the systems you are developing meet the necessary safety requirements. Additionally, if you are
working with suppliers who are providing components for safety-critical systems, it would be
important to be familiar with ISO 26262 in order to ensure that the components meet the
necessary safety requirements.

5. Why is it important to follow ISO 26262 standards when developing safety-related

systems?

There are a number of reasons why it is important to follow ISO 26262 standards when
developing safety-related systems. First and foremost, these standards help to ensure the safety
of both the systems themselves and the people who use them. Additionally, ISO 26262 standards
help to improve the quality of safety-related systems by providing guidelines for development
and testing. Finally, following these standards can help to improve the efficiency of the
development process, as well as the overall cost-effectiveness of the project.

6. What are the differences between ISO 26262 and other industry standards like IEC
61508 or DO-178C?
The main difference between ISO 26262 and other standards is that ISO 26262 specifically
addresses the issue of functional safety in the automotive industry. This standard takes into
account the unique challenges that come with designing safe vehicles, such as the need to
account for human factors in the design process. Other standards, while they may touch on some
of these issues, do not address them in as much depth or with as much specificity.

7. What are the main principles that govern ISO 26262?

The main principles that govern ISO 26262 are safety, risk management, and hazard control.
These principles are designed to help ensure that any products or systems that are developed
according to ISO 26262 will be safe for use.

8. Is it possible to use open source software for devices covered by ISO 26262? If yes, how?

Yes, it is possible to use open source software for devices covered by ISO 26262. One way to do
this is to use a safety monitor, which is a software tool that can be used to check the safety of
open source software. The safety monitor can be used to check for compliance with ISO 26262
and to ensure that the software is safe to use.

9. What does ASIL mean in context with ISO 26262?

ASIL stands for Automotive Safety Integrity Level. It is a classification system used in ISO
26262 to help determine the necessary safety measures for automotive safety-critical systems.
The ASIL scale goes from A (lowest risk) to D (highest risk), with each level having different
requirements for safety and testing.

10. Which parts of ISO 26262 are mandatory?

The standard is divided into eight parts, and each part covers a different aspect of automotive
safety. Part 1 is the general introduction, which covers the scope, objectives, and general
concepts of the standard. Part 2 covers the development process, Part 3 covers risk management,
Part 4 covers hardware development, Part 5 covers software development, Part 6 covers
production and operation, Part 7 covers service and support, and Part 8 covers vehicle disposal.

Of these eight parts, only Part 3 (Risk Management) is mandatory. The other parts are all
recommended, but not required.

11. What’s your understanding of the term “FMEA” as used in ISO 26262?

FMEA is an acronym for “Failure Mode and Effects Analysis”. It is a tool used during the
development process of a product in order to identify potential failure modes and their effects on
the product. This information is then used to help mitigate risks and improve the overall safety of
the product.

12. What is the purpose of using failure modes in ISO 26262?

The purpose of using failure modes in ISO 26262 is to identify all of the potential ways that a
system could fail, and then to assess the risks associated with each failure mode. This
information can then be used to help design systems that are more robust and less likely to fail.

13. Can you describe the different types of Hazard Analysis techniques available under
ISO 26262?

There are three different types of Hazard Analysis techniques available under ISO 26262:
Functional Safety Concept, Systematic Technical Safety Concept, and Technical Safety Concept.
The Functional Safety Concept is the most basic and is used to identify potential hazards in a
system. The Systematic Technical Safety Concept is more comprehensive and is used to identify
both potential and actual hazards in a system. The Technical Safety Concept is the most
comprehensive and is used to identify, assess, and mitigate hazards in a system.

14. What tools can be used to perform Failure Mode Simulation analysis?

There are a few different tools that can be used to perform Failure Mode Simulation analysis.
One popular tool is the FMEA Toolkit, which is a software tool that helps users to create and
manage Failure Mode and Effects Analysis (FMEA) diagrams. Other tools that can be used for
this purpose include the Reliability Block Diagram Toolkit and the Fault Tree Analysis Toolkit.

15. What is included in a Functional Safety Management Plan?

A Functional Safety Management Plan should include a description of the safety functions of the
system, the safety requirements for the system, the safety hazards that could affect the system,
and the safety measures that will be put in place to mitigate those hazards.

16. When should we start testing our product for compliance with ISO 26262 standards?

The answer to this question may vary depending on who you ask, but generally speaking, it is
recommended that you start testing your product for compliance with ISO 26262 standards as
early as possible in the development process. This will help to ensure that your product meets all
of the necessary requirements and can help to avoid any potential delays or issues further down
the line.

17. What is verification and validation (V&V) in the context of ISO 26262?

Verification and validation is the process of ensuring that a product or system meets the
requirements it was designed to meet. In the context of ISO 26262, this includes ensuring that the
system is safe for use and will not cause any harm to users or operators.

18. What are the advantages of V & V over traditional testing models?

There are several advantages of V & V over traditional testing models:

1. V & V can be used to verify the safety requirements of a system.

2. V & V can be used to verify the functional requirements of a system.

3. V & V can be used to verify the system against its environment.

4. V & V can be used to verify the system against its operational profile.

19. What is the difference between hazard detection and risk estimation?

Hazard detection is the process of identifying potential hazards that could lead to an accident.
Risk estimation is the process of assessing the likelihood and severity of the potential accidents
that could occur.

20. Can you tell me what a SW/HW partitioning plan is?

A SW/HW partitioning plan is a document that outlines how the software and hardware
components of a system will be divided up and allocated. This is important for safety-critical
systems, as it ensures that each component is allocated an appropriate level of safety and
reliability.

What is MISRA C/C++?

it is a formal set of guidelines well framed for the automotive software development with c/c++
language as the base

MISRA- the motor industry software reliability association- this is from UK and it totally looks after the
development of these standards

MISRA guidelines are specific for automobiles but any system can follow these guidelines.

Why there has to be a programming standard for automobiles? (just for reference)

For safety

Yes, safety is paramount and the automobiles, it fails, would be catastrophic and fatal

Now a days, most of the automobiles has software as paramount component so, the software is mostly
backed up by c/c++ programming language

MISRA gives you guidelines for the same developers must go with the rules and adhere to the same
without breaking

First version of rules developed in 1998 second in 2004 many more versions are available now and it
keeps growing

Safety is paramount, overall safety design is the core aim.

Safety is paramount, overall safety design is the core aim.

C/C++ language it most preferred for developing embedded applications and it cannot be avoided
C/C++ has some limitations too. A very matured developer shall know them all and avoid but others
might miss them and could use it such usage may cause software leak and could serve as a threat

Three categories of MISRA C

1 mandatory: must follow, no exceptions permitted

2 required: must be followed. But, if there is a situation, these can be exempted.

3 advisory: try to follow, but, not mandatory. This is like, if you follow, it is a good practice.

Some of the MISRA C rules are:

1 identifiers should not be longer than 31 charecters

2 function names should comply with a naming convention

3 switch statements should not be nested

4 conditional operators should not be nested

5 continue should not be used

6 if else if constructs should end with else clauses

7 statements should be on separate lines

8 function parameters should not be reassigned

9 switch statements should have at least 3 case clauses

10 method should not contain unreachable code

11 for loop counters should not have essentially floating type

12 bitwise operators should not be applied to signed operands

13 functions should not have too many parameters

14 break statements should not be used except for switch case

15 unused local variables should be removed