- Software Considerations in Airborne Systems and Equipment Certification.

By Jacinth Paul

What is DO-178B?
y A guidance document : y For the production of software for airborne systems

and equipment. y To determine if the software will perform reliably in an airborne environment. DO-178B specifies that each line of code is required and tested, and that no unused code exists in the application program build
By Jacinth Paul

DO-178B benefits?
y verifiable software quality y higher reliability y consistency y greater re-usability y lower lifecycle costs y decreased maintenance cost y faster hardware integration and y greater portability.

By Jacinth Paul

Five levels of software are defined in DO-178B. Each software level has a specific set of objectives that must be satisfied.

By Jacinth Paul

How are the Levels Categorized?

y The Design Assurance Level (DAL) y Determined from the safety assessment process and

hazard analysis by examining the effects of a failure condition in the system. y The failure conditions are categorized by their effects on the aircraft, crew, and passengers.

By Jacinth Paul

Software Levels
Software Level Failure Condition Failure condition interpretation in the Aircraft / Aviation context Prevent continued safe flight or landing Potential fatal injuries to a small number of occupants Impairs crew efficiency, discomfort or possible injuries to occupants Reduced aircraft safety margins, but well within crew capabilities Does not effect the safety of the aircraft at all A B Catastrophic Hazardous

Major

Minor

By Jacinth Paul

No effect

Software Analysis
The certification authorities require and DO-178B specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. y requirements analysis y top level design analysis y detailed design analysis y code level analysis y test analysis and y change analysis.
By Jacinth Paul

Objectives
y Any software that commands, controls, and monitors

safety-critical functions should receive the highest DAL - Level A. y For each software level, DO 178B identifies a specific set of objectives that must be satisfied. 1. Level A 66 objectives 2. Level B 65 objectives 3. Level C 57 objectives 4. Level D 28 objectives 5. Level E none
By Jacinth Paul

Few Key Points

DO-178B specifies the information flow between system processes and software processes.
The focus of information flow from the software process to the system process is to ensure that changes in the software

requirements, including the introduction of derived requirements (those not directly traceable to a parent requirement), do not adversely affect system safety.

Certification liaison process should begin during the projects planning phase.
By Jacinth Paul

Few key Points

y DO-178B is not intended as a software development standard, it is software assurance using a set of tasks to meet objectives y Traceability from system requirements to all source code or executable object code is typically required (depending on software level) y Verification objectives outnumber all others in DO-178B, accounting for over two thirds of the total. y The key to accomplishing testing correctly to meet DO178B objectives in a cost-effective manner is to maintain a constant focus on requirements. y This Requirements-based test approach is recommended.
By Jacinth Paul

Processes are intended to support the objectives, according to the software level.

By Jacinth Paul

Objective-based nature of DO-178B allows a great deal of flexibility in regard to following different styles of software life cycle.

Life-cycle processes include the Software development processes

Planning process

Requirements, Design, Code, and Integration

Integral processes

Verification, Configuration management, Software quality assurance, and Certification liaison

By Jacinth Paul

Processes
y DO-178B defines objectives for each of these processes

as well as outlining a set of activities for meeting the objectives. y Transition criteria: the minimum conditions, as defined by the software planning process, to be satisfied to enter a process. y DO-178B discusses the software life-cycle processes and transition criteria between life-cycle processes in a generic sense without specifying any particular lifecycle model.
By Jacinth Paul

Software Planning Process

y DO-178B defines five types of planning data for a software

development. y These plans should include consideration of methods, languages, standards, and tools to be used during the development.

Plan for Software Aspects of Certification (PSAC) Software Development Plan Software Verification Plan Software Configuration Management Plan Software Quality Assurance Plan
By Jacinth Paul

Software Development Process

y DO-178B allows for requirements to be developed that detail the y y y y

system s functionality at various levels. DO-178B refers to these levels as high- and low-level requirements. The design process yields low-level requirements and software architecture. The coding process produces the source code, typically either in a high-order language or assembly code. The result of the integration effort is executable code resident on the target computer along with the various build files used to compile and link the executable. Each of these outputs is verified, assured, and configured as part of the integral processes.
By Jacinth Paul

Development Process
The development process output documents: y Software requirements data (SRD) y Software design description (SDD) y Source code y Executable object code Typically used software development process: y Waterfall model y Spiral model y V model
By Jacinth Paul

Integral Processes
y DO-178B defines four processes as integral, meaning

that they overlay and extend throughout the software life cycle. These are the : y Software verification process y Software configuration management y Software quality assurance and y Certification liaison process.

By Jacinth Paul

Verification
y Verification objectives out number all others in DO-

178B, accounting for over two thirds of the total. y DO-178B defines verification as a combination of reviews, analyses, and testing. y Verification is a technical assessment of the results of both the software development processes and the software verification process. y There are specific verification objectives that address the requirements, design, coding, integration, as well as the verification process itself.
By Jacinth Paul

Verification
y As test cases are designed and conducted,

requirements coverage analysis is performed to assess that all requirements are tested. y A structural coverage analysis is performed to determine the extent to which the requirements-based test exercised the code. y In this manner, structural coverage is used as a means of assessing overall test completion. y As part of the test generation process, tests should be written for both normal range and abnormal inputs (robustness)
By Jacinth Paul

Software Levels
Level D software verification requires test coverage of highlevel requirements only Low-level requirements testing is required at level C. Decision coverage is required for level B, while level A code requires Modified Condition Decision Coverage (MCDC). For level A, structural coverage analysis may be performed on source code only to the extent that the source code can be shown to map directly to object code

By Jacinth Paul

Document outputs made by this process: Software verification cases and procedures (SVCP) Software verification results (SVR) This process typically also involves: Requirements based test tools Code coverage analyzer tools

Other names for tests performed in this process : Unit testing, Integration testing Black-box and acceptance testing

By Jacinth Paul

Configuration Management
The objectives in this area are unique, in that they must be met for all software levels. Includes Identification of

What is to be Configured

How Baselines and Traceability is eastablished

How software is archived and loaded

How roblem e orts are dealt with

How the develo ment environment is controlled

By Jacinth Paul

Configuration Management
Documents maintained by the configuration management process: y Software configuration index (SCI) y Software life cycle environment configuration index (SECI)

By Jacinth Paul

Software Quality Assurance

y Software quality assurance (SQA) objectives provide

oversight of the entire DO-178B process and require independence at all levels y SQA assures that any deviations duringthe development process from plans and standards are detected, recorded, evaluated, tracked, and resolved. y For levels A and B, SQA is required to assure transition criteria are adhered to throughout thedevelopment process

By Jacinth Paul

SQA
Output documents from the quality assurance process: y Software quality assurance records (SQAR) y Software conformity review (SCR) y Software accomplishment summary (SAS)

By Jacinth Paul

Certification Liaison Process

y To streamline the certification process by ensuring that issues are identified early in the process. y 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.

Plan for Software Aspects of Certification (PSAC) 2. Software Configuration Index 3. Software Accomplishment Summary
1.
By Jacinth Paul

Previously Developed Software

PDS is software that falls in one of the following categories: y Commercial off-the-shelf software (e.g., shrink-wrap) y Airborne software developed to other standards (e.g., MIL-STD-498) y Airborne software that predates DO-178B (e.g., developed to the original DO-178 or DO-178A) y Airborne software previously developed at a lower software level
By Jacinth Paul

Tools
y Tools generating embedded code are qualified as

Development tools. y Development tools produce output that becomes a part of the airborne system and thus can introduce errors. y Has a tool qualification plan A tool accomplishment summary y Tools used to verify the code (simulators, test execution tool, coverage tools, reporting tools, etc.) must be qualified as Verification tools
By Jacinth Paul

Levels of Structural Testing

y SC: Statement Coverage. y DC: Decision Coverage y MCDC: Modified Condition Decision Coverage
Level Level A Level B Level C Level D Level E Coverage MCDC DC SC Explanation Level B + 100% Modified Condition Decision Coverage Level C + 100% Decision Coverage Level D + 100% Statement (or Line) Coverage 100% Requirements Coverage Requirements No Coverage Requirements

By Jacinth Paul

DO-178B Certification Risks

y Simply, doing too much work, and neglecting key artifacts/steps, cause cost overruns averaging 40% y Inadequate DO-178B low-level software requirements y Vagueness within the five key DO-178B process plans prior to initiating those lifecycles; y Insufficient independence of DO-178B reviews y Insufficient DO-178B checklists for reviews y Inadequate DO-178B traceability between components y Insufficient advance FAA coordination/approvals y Incomplete DO-178B structural coverage for decision condition and MCDC coverage
By Jacinth Paul

DO-178B Certification Risks

y Over doing DO-178B tool qualification y Not applying DO-254 to hardware , avionics

outsourcing without a clear DO-178B Project Plan covering details for the avionic outsource team and y Reading the DO-178B document word-for-word and not understanding the true intent

By Jacinth Paul

List f
y y y y y y y y y y y y y y y

17

e ts

Plan for Pla f r Software Aspects of Certification (PSAC) Software Development Plan (SDP) evelop ent Software Verification Plan (SVP) Software Config ration Management Plan (SCMP) Configuration Manage ent Software Q ality Assurance Plan (SQAP) Quality Ass rance Software Req ire ents Standards (SRS) Requirements Software Design Standards (SDS) Software Code Standards (SCS) Software Req ire ents Data (SRD) Requirements Software Design Description (SDD) Software Verification Cases and Proced res (SVCP) Procedures Software Life Cycle Environment Configuration Config ration Index (SECI) Software Config ration Index (SCI) Configuration Software Accomplishment Summary (SAS)
By Jacinth Paul

Do178B Records:
y Software Verification Results (SVR) y Problem Reports y Software Configuration Management Records y Software Quality Assurance Records

By Jacinth Paul

Jacinth Paul

By Jacinth Paul