DO 178 B Brief Notes

Amity Institute of Space Science & Technology

Avionics Software Engineering : LN 5 : DO 178 B/C : A Brief Note Prof M S Prasad This brief note on DO 178 B/C standards is for Grad/ Post Grad students of AVIONICS. This LN has been prepared based on available open literature for instructional purposes only.

AVIONICS SOFTWARE ENGINEERIN : LN 5 DO 178 B /C : Aviation Software Standard

[ This is a brief introduction to DO 178 B/C standards , for Grad/ Post Grad

students of Avionics . The software developers are suppose to go

through the standards manual in original ]

DO-178B has become a de facto standard. Produced by Radio Technical

Commission for Aeronautics, Inc. (RTCA), the FAA's Advisory Circular AC20 -

115B established DO-178B as the accepted means of certifying all new aviation

software. Sometimes refereed as RTCA DO 178 B also. The RTCA creates DO-178 in 1980, while EUROCEA works on ED-35.The merged result is DO-178 / ED-

12: the first common certification criteria for production of avionics software.

DO-178B is primarily concerned with development processes. As a result,

certif ication to DO-178B requires delivery of multiple supporting documents and

records. The quantity of items needed for DO-178B certif ication, and the amount

of information that they must contain, is determined by the level of certif ication

being sought.

The targeted DO-178B certif ication level is either A, B, C, D, or E.

Correspondingly, these DO-178B levels describe the consequences of a

potential failure of the software: Catastrophic ( A) , Hazardous-severe( B), Major

( C) , Minor ( D) , or no-effect( E) .

The DO-178B certification process is most demanding at higher levels. A

product certified to DO-178B level A would have the largest potential market,

but it would require thorough, labor-intensive preparation of most of the items

on the DO-178B support list.

Conversely, a product certifying to DO-178B level E would require fewer

support items and be less taxing on company resources. Unfortunately, the

product would have a smaller range of applicability than if certified at a

higher level.

The failure criteria as defined in DO 178 A/B ( software levels )

Level Failure

condition

Description Objective

associated

A Catastrophic Failure may cause a crash 66

B Hazardous

Failure has a large negative

impact on safety or performance,

or reduces the ability of the crew

to operate the plane due to

physical distress or a higher

workload ,or causes serious or

fatal injuries among the

passengers.

65

C Major

Failure is significant, but has a

lesser impact than a Hazardous

failure (for example, leads to

passenger discomfort rather than

injuries)

57

D Minor

Failure is noticeable, but has a

lesser impact than a Major

failure (for example ,causing

passenger inconvenience or a

routine flight plan change)

28

E No effect

Failure has no impact on safety,

aircraft operation, or crew

workload

0

DO-178B establishes processes that are intended to support the objectives,

according to the software level. In general, theres Integral and Development

processes as shown in Figure 2 below .

Fig 2 Association of processes in DO 178

DO-178B translates these software levels into software specific objectives

that must be satisfied during the development process. An assigned software

level determines the level of effort required to show compliance with

certification requirements, which varies with the failure condition category.

This means that the effort and expense of producing a system critical to the

continued safe operation of an aircraft (e.g. a fly-by-wire system) is

necessarily higher than that required to produce a system with only a minor

impact on the aircraft in the case of a failure (e.g. the in-flight entertainment

system).

Intended to provide confidence in the safety of avionic systems by ensuring

that they comply with airworthiness objectives, DO-178B covers the complete

software lifecycle: planning, development and integral processes to ensure

correctness, control and confidence in the software . These integral processes

include requirements traceability, software design, coding and software

validation and verification.

DO-178B Process Objectives

DO-178B recognizes that software safety and security must be addressed in

a systematic way throughout the software development life (SDLC). This

includes the requirements traceability, software design, coding, validation

and verification processes used to ensure correctness, control and

confidence in the software.

Key elements of the DO-178B SDLC are the practices of traceability and

coverage analysis. Traceability (or Requirements Traceability) refers to the

ability to link system requirements to software high-level requirements, from

software high-level requirements to low-level requirements, and then from

low-level requirements to source code and the associated test cases.

Coverage (or code coverage analysis) refers to measuring the degree to

which the source code of a system has been tested. Through the use of these

practices it is possible to ensure that code has been implemented to address

every system requirement and that the implemented code has been tested to

completeness.

The planning process is where all the Software Development plans are made.

We have gathered system-level requirements and we want to calculate an

approach towards effectively and safely satisfying the requirements.

The Software Development Plan is meant to define the software life -cycle and

the development environment.

The Software Verification Plan is the proposed method of verification that will

satisfy all objectives of the software verification process.

The Software Configuration Plan is similarly the proposed method of

configuration management.

The Software Quality Assurance Plan is the proposed plan for satisfying the

objectives of the software quality assurance process.

So again these documents are intended to outline what will be done to

achieve the objectives of the following processes : ( Refer Fig below )

There are 2 sections of the DO-178B guidance document where the use of

the Software testing tools are significantly used.

Section 5.0 - Software Development Processes

Section 6.0 - Software Verification Process

Software Development Processes (Section 5.0 )

Fig : DO 178 Document Structure

Software Life Cycle Process

Software

Life Cycle Process

Objective

Software Life Cycle

Data (process outputs)

Planning Produce the software plans and standards that direct the software

development processes and the integral processes

PSAC

SDP SVP

SCMP

SQAP

Plan for SW Aspects of

Certification SW Development Plan

SW Verification Plan

SW Config Management Plan

Software

Life Cycle Process

Objective

Software Life Cycle


SRS SDS

SCS

SW Quality Assurance Plan SW Requirements

Standards SW Design

Standards SW Code Standards

Requirements Develop the high-level

requirements

SRD SW Requirements

Data

Design Develop the software architecture

and low-level requirements from the high-level requirements

SDD

SECI

SW Design

Description SW Environment Config Index

Coding Implement the source code from the software architecture and the

low-level requirements

SRC Source Code

Integration Build the executable object code and load it into the target hardware to detect and report

errors/bugs that may have been introduced during the software

development processes by creating test cases, test procedures and analyses

EOC SVCP

SVR

SCA

SCI

SAS

Executable Object Code SW Verification

Cases & Proc. SW Verification

Results Structural Coverage

Analysis SW Configuration

Index SW Accomplishment

Summary

Configuration

Management

Provide a defined and controlled

configuration of the software throughout the software life cycle

and to provide the ability to consistently replicate the Executable Object Code

- SCM Records

Problem Reports

Verification Detect and report errors/bugs that

may have been introduced during the development processes

- Review Records

Quality Provide confidence that the - SW Conformity

Software

Life Cycle Process

Objective

Software Life Cycle


Assurance software life cycle processes produce software that conforms to its requirements by assuring that

these processes are performed in compliance with the approved

software plans and standards

Review SQA Records

Certification

Liaison

Establish communication and

understanding between the applicant and the certification

authority throughout the software life cycle to assist the certification process

- PSAC, SAS, SCI

Outputs are in the form of Conformance documents which are to be

certified.

Four high level activities are identified in the DO-178B Software Development

Processes section; Software requirements process, Software design process,

Software coding process and Integration process . In addition, there is a

section on requirements traceability (section 5.5) that embodies the evolution

and traceability of requirements from system level requirements to source

code.

As part of Section 5.3, the software development process, DO-178B specifies

that software must meet certain software coding process requirements. These

include adherence to a set of software coding standards and traceability from

low level design requirements to the source code and object code.

Further definition of the software coding standards are provided in Section

11.8 of DO-178B:

Programming language(s) to be used and/or defined subset(s). For a

programming language, reference the data that unambiguously defines the

syntax, the control behaviour, the data behaviour and side-effects of the

language. This may require limiting the use of some features of a language.

Source code presentation standards, for example, line length restriction,

Indentation, and blank line usage and source code documentation standards,

for example, name of author, revision history, inputs and outputs, and

affected global data.

Naming conventions for components, subprograms, variables and

constants.

Conditions and constraints imposed on permitted coding conventions, such

as the degree of coupling between software components and the complexity

of logical or numerical expressions and rationale for their use .

Software Verification Process (Section 6.0)

Per Section 6.1 of DO-178B, the objectives of the Software Verification

Process are to detect and report errors that may have been introduced

during the software development processes. Per Section 6.2 of DO-

178B,these objectives are satisfied through a combination of reviews,

analyses, the development of test cases and procedures, and the subsequent

execution of those test procedures. Review and analyses provide an

assessment of the accuracy, completeness and verifiability of the software

requirements, software architecture and source code.

DO-178B Structural Coverage Analysis Objectives

Structural Coverage Analysis (SCA) is used to analyse the effectiveness of

the requirements-based test procedures. All testing must be performed at the

system level and be driven from the software requirements that is, using

requirements-based functional tests. Following that, SCA is applied to

measure the effectiveness of this testing, i.e. measuring how much of the

code has been exercised as a result of the requirements-based functional

tests. The feedback gained as a result of this analysis helps to validate that

the code base has been tested to completeness, and also to ensure that

there is no unintended code in the system software by validating that all of

the code is traceable to a specific system requirement or set of requirements.

SCA is one of the closing steps in the requirements coverage/traceability

process. SCA is an empirical measurement of requirements test

effectiveness, helping to link the source code implementation and associated

test procedures back to the system requirements while ensuring that the

system code has been tested to the level of completeness required by the

system software level.

Following is the pertinent extract from DO-178B with respect to SCA:

Structural Coverage Analysis

The objective of this analysis is to determine which code structure was not

exercised by the requirements-based test procedures. The requirements

based test cases may not have completely exercised the code structure, so

structural coverage analysis is performed and additional verification produced

to structural coverage. Guidance includes:

a. The analysis should confirm the degree of structural coverage appropriate

to the software level.

b. The structural coverage analysis may be performed on the source code,

unless the software is level A and the compiler generates object code that is

not directly traceable to source code statements. Then, additional verification

should be performed on the object code to establish the correctness of such

generated code sequences. A compiler-generated array bound check in the

object code is an example of object code that is not directly traceable to the

source code.

c. The analysis should confirm data coupling and control coupling between

the code components. The SCA objectives for each software level are

summarized in the following table :-

Ite

m

Description DO178

Referenc

e

DO

17

8 A

DO

17

8 B

DO

17

8 C

Do17

8

D

5 Test Coverage

of software

structure(MC/D

C is achieved)

6.4.4.2 R NR NR NR

6 Test coverage

SW structure (

decision

coverage is

satisfied )

6.4.4.2.a

and

6.4.4.2 b

R R NR NR

7 Statement

coverage is

satisfied

6.4.4.2 a

& b

R R R NR

8 Data Coupling

&Control

coupling is

satisfied

6.4.4.2c R R R NR

Item no 1 -4 are manual procedures .

Control Coupling

Defined by DO-178B to be The manner or degree by which one software component

influences the execution of another software component.

Data Coupling

Defined by DO-178B to be The dependence of a software component on data not

exclusively under the control of that software component,

Software Configuration Management

Verification of the various outputs discussed in DO-178B are only credible when there is

clear definition of what has been verified. This definition or configuration is the intent of

the DO-178B objectives for configuration management. The six objectives in this area

are unique, in that they must be met for all software levels. This includes identification of

what is to be configured, how baselines and traceability are established, how problem

reports are dealt with, how the software is archived and loaded, and how the

development environment is controlled.

While configuration management is a fairly well-understood concept within the

software engineering community (as well as the aviation industry as a whole), DO-178B

does introduce some unique terminology that has proven to be problematic. The

concept of control categories is often misunderstood in a way that overall development

costs are increased, sometimes dramatically. DO-178B defines two control categories

(CC1 and CC2) for data items produced throughout the development.

The authors of DO-178B intended the two levels as a way of controlling the overhead

costs of creating and maintaining the various data items. Items controlled as CC2 have

less requirements to meet in the areas of problem reporting, base lining, change control,

and storage. The easiest way to understand this is to provide an example. Problem

reports are treated as a CC2 item. If problem reports were a CC1 item and a problem

was found with one of the entries on the problem report itself, a second problem report

would need to be written to correct the first one.

A second nuance of control categories is that the user of DO-178B may define what

CC1 and CC2 are within their own CM system as long as the DO-178B objectives are

met. One example of how this might be beneficial is in defining different retention

periods for the two levels of data. Given the long life of airborne systems, these costs

can be quite sizeable. Another consideration for archival systems selected for data

retention is technology obsolescence of the archival medium as well as means of

retrieval.

Software Quality Assurance

Software quality assurance (SQA) objectives provide oversight of the entire DO-178B

process and require independence at all levels. It is recognized that it is prudent to have

an independent assessment of quality.

SQA is active from the beginning of the development process. SQA assures that any

deviations during the development process from plans and standards are detected,

recorded, evaluated, tracked, and resolved. For levels A and B, SQA is required to

assure transition criteria are adhered to throughout the development process.

SQA works with the CM process to assure that proper controls are in place and applied

to life cycle data. This last task culminates in the conduct of a software conformity

review. SQA is responsible for assuring that the as-delivered products matches the as-

built and as-verified product. The common term used for this conformity review in

commercial aviation industry is First Article Inspection.

The Software Testing Process in general is shown below.

Certification Liaison Process

As stated earlier, the certification liaison process is designed to streamline the

certification process by ensuring that issues are identified early in the process. While

DO-178B outlines twenty distinct data items to be produced in a compliant process,

three of these are specific to this process and must be provided to the certifying

authority. They are

Plan for Software Aspects of Certification (PSAC)

Software Configuration Index

Software Accomplishment Summary

Other data items may be requested by the certification authority, if deemed necessary.

As mentioned earlier, applicants are encouraged to start a dialogue with certification

authorities as early in the process as possible to reach a common understanding of a

means of achieving compliance with DO-178B. This is especially important as new

technology is applied to avionics and as new personnel enter the field.

Good planning up front, captured in the PSAC, should minimize surprises later in the

development process, thus minimizing cost. Just as the PSAC states what you intend to

do , the accomplishment summary captures what you did . It is used to gauge the

overall completeness of the development process and to ensure that all objectives of

DO-178B have been satisfied.

Finally, the configuration index serves as an overall accounting of the content of the

final product as well as the environment needed to recreate it.

Previously Developed Software

PDS is software that falls in one of the following categories:

Commercial off-the-shelf software (e.g., shrink-wrap)

Airborne software developed to other standards (e.g., MIL-STD-498)

Airborne software that predates DO-178B (e.g., developed to the original DO-178 or

DO-178A)

Airborne software previously developed at a lower software level The use of one or

more of these types of software should be planned for and discussed in the PSAC.

In every case, some form of gap analysis must be performed to determine where

specific objectives of DO-178B have not been met. It is the applicants responsibility to

perform this gap analysis and propose to the regulatory authority a means for closing

any gaps. Alternate sources of development data, service history, additional testing,

reverse engineering, and wrappers* are all ways of ensuring the use of PDS issafe in

the new application.

In all cases, usage of PDS must be considered in the safety assessment process and

may require that the process be repeated if the decision to use a PDS component

occurs after the approval of PSAC. A special instance of PDS usage occurs when

software is used in a system to be installed on an aircraft other than the one for which it

was originally designed. Although the function may be the same, interfaces with other

aircraft systems may behave differently. As before, the system safety assessment

process must be repeated to assure that the new installation operates and behaves as

intended.

If service history is employed in making the argument that a PDS component is safe for

use, the relevance and sufficiency of the service history must be assessed. Two tests

must be satisfied for the service history approach to work. First, the application for

which history exists must be shown to be similar to the intended new use of the PDS.

Second, there should be data, typically problem reports, showing how the software has

performed over the period for which credit is sought. The authors of DO-178B intended

that any use of PDS be shown to meet the same objectives required of newly developed

code.

Prior to identifying PDS as part of a new system, it is prudent to investigate and truly

understand the costs of proving that the PDS satisfies the DO-178B objectives.

Sometimes, it is easier and cheaper to develop the code again!

*Wrappers is a generic term used to refer to hardware or software components that

isolate and filter inputs to and from the PDS for the purposes of protecting the system

from erroneous PDS behavior.

DO 178 Documents

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 Standards (SRS)

Software Design Standards (SDS)

Software Code Standards (SCS)

Software Requirements Data (SRD)

Software Design Description (SDD)

Software Verification Cases and Procedures (SVCP)

Software Life Cycle Environment Configuration Index (SECI)

Software Configuration Index (SCI)

Software Accomplishment Summary (SAS) also includes

supplementary documents such as : -

Software Design Document

Software Requirements Document

Traceability

Test Cases and Procedures

Verification Results

Quality Assurance Records

Configuration Management Records

Problem Reports Records

Software Verification Results (SVR)

Problem Reports

Software Configuration Management Records

Software Quality Assurance Records

Tool Selection

The use of traceability and analysis tools for an avionics project that must meet the DO-

178B certification requirements offers significant productivity and cost benefits. Tools

make compliance checking easier, less error prone and more cost effective. In addition,

they make the creation, management, maintenance and documentation of requirements

traceability straightforward and cost effective. When selecting a tool to assist in

achieving DO-178B acceptance the following criteria should be considered:

Does the tool provide a complete end-to-end Requirements Traceability capability to

enable linkage and documentation from all levels to the source code and associated

test cases?

Does the tool enable analysis for all Structural Coverage Analysis requirements as laid

out in section 6.4.4.2 of the standard?

Can the tool perform MC/DC analysis in assignment statements as well as conditional

statements?

Is there tool availability for all the languages required in your project?

Has the tool been utilised in this manner successfully already?

Will the tool vendor assist in tool qualification?

Is tool support both flexible and extensive enough to meet changing requirements?

Notes

The difficulties that have been identified are the DO-178 requirements for evidence and

rigorous verification... Systematic records of accomplishing each of the objectives and

guidance are necessary. A documentation trail must exist demonstrating that the

development processes not only were carried out, but also were corrected and updated

as necessary during the program life cycle. Each document, review, analysis, and test

must have evidence of critique for accuracy and completeness, with criteria that

establishes consistency and expected results.

This is usually accomplished by a checklist which is archived as part of the program

certification records. The degree of this evidence varies only by the safety criticality of

the system and its software.

References

[1] RTCA Inc., RTCA/DO-178B: Software considerations in airborne systems and

equipment certification, 1992.

[2] V. Hilderman and T. Baghi, Avionics certification: a complete guide to DO-178

(software), DO-254 (hardware), Avionics Communications Inc., 2007.

[3] RTCA Inc., RTCA/DO-248B: Final report for clarification of DO-178B Software

considerations in airborne systems and equipment certification, 2001.

Appendix A

Guidelines for Software Development

(a) A detailed description of how the software satisfies the specified software high-level

requirements, including algorithms, data-structures and how software requirements are

allocated to processors and tasks.

(b) The description of the software architecture defining the software structure to

implement the requirements.

c) The input/output description, for example, a data dictionary, both internally and

externally throughout the software architecture.

(d) The data flow and control flow of the design.

(e) Resource limitations, the strategy for managing each resource and its limitations, the

margins and the method for measuring those margins, for example timing and memory.

(f) Scheduling procedures and inter processor/inter task communication mechanisms,

including time-rigid sequencing, pre-emptive scheduling, interrupts.

(g) Design methods and details for their implementation, for example, software data

loading, user modifiable software, or multiple-version dissimilar software.

(h) Partitioning methods and means of preventing partitioning breaches.

(i) Descriptions of the software components, whether they are new or previously

developed, with reference to the baseline from which they were taken.

(j) Derived requirements from the software design process.

(k) If the system contains deactivated code, a description of the means to ensure that

the code cannot be enabled in the target computer.

(l) Rationale for those design decisions that are traceable to safety-related system

requirements.

---------------------------------------------------------------------------------------------------------------------

--