DO-178_Safety Critical Soft

8/3/2019 DO-178_Safety Critical Soft

http://slidepdf.com/reader/full/do-178safety-critical-soft 1/33

7/23/01 © 2000 Wind River Systems, Inc. 1

DO-178B and Safety-Critical

SoftwareTechnical Overview

Joseph Wlad

Product Marketing Manager Wind River

Alameda, CA




Agenda

n DO-178B Overview

– Background and History

– Certification Levels

n Software Verification

– Software Safety and Level A and Level B

n VxWorks Real-Time Operating System and DO-178B – Certifiable Subset Overview




DO-178B Overviewn DO-178B: Software Considerations in Airborne Systems and

Equipment Certification, circa 1992

– Evolved from DO-178A, circa 1985

n DO-178B is a guidance document only and focuses on software

processes and objectives to comply with these processes – Developed by RTCA, Inc (a not for profit company) and its members toensure that software meets airworthiness requirements

n Called out in many certification requirements documents as therecommended method to obtain approval of airborne software

– Design Approvals through FAA Technical Standard Orders and

Supplemental Type Certificates, among others

– Others calling out DO-178B: Military programs, Nuclear, Medical

n Many other standards exists: SEI-CMM, DEF STAN 00-55, ISO,DOD-2167, IEC 61508




Working Groups and Committees create and evolve

RTCA DO-178B/ED-12B

AvionicsIndustry

D O - 1 7 8 B

E D - 1 2 B

RTCA EUROCAE

SC-167 WG-12

CAST(Certification

AuthoritySoftwareTeam)

Cast PositionPapers

SC-190 / WG-52

SC-190 / WG-52

RTCA DO-248,others




DO-178B Overviewn DO-178B is not prescriptive

– Vendors are allowed to decide how objectives are satisfied

n DO-178B objectives vary, depending upon how softwarefailures can affect system safety

n

Consider two aircraft examples – 1) Software controlling the coffeemakers in the aft galley fails

• Outcome: Likely some grumpy customers, but passenger safety notcompromised (air rage issues due to lack of coffee aside)

– 2) Software controlling the aircraft during an automatic landing in zerovisibility conditions fails

• Outcome: Possibly catastrophic and lives lost

n Obviously these two software applications need not bedeveloped to the same rigor




DO-178B Overviewn For this reason, DO-178B defines five software levels

n Each level is defined by the failure condition that can resultfrom anomalous software behavior

Failure ConditionFailure Condition Software LevelSoftware Level

Catastrophic Level A

Hazardous/Severe - Major Level B

Major Level C

Minor Level D

No Effect Level E




DO-178B Overviewn Once a system safety assessment is done and the

safety impact of software on is known then the levelis defined

n Level A has 66 objectives, Level B 65 objectives,

Level C 57 objectives, Level D 28 objectives

n Does DO-178B help make software safe?

– Maybe: Heuristically, it appears to help but absence of failures isnot a guarantee that the process helped eliminate them

n How do we know when software is safe?




DO-178B Overview

We Don’t Know !!We Don’t Know !!

n What is our best guess about software safety? – When applicable processes have been followed

– When the code has been verified “from within”

– When this has been checked and checked…...

and checked…..

and checked……...

and checked……………….




DO-178B Overview

n But, use of standard processes and compliance with pre-determined objectives help avoid the common pitfalls ofsoftware development

n DO-178B defines the following processes (as well as objectivesfor each):

– Planning Process

– Development Process

– Requirements Process

– Design Process

– Coding and Integration Process

– Testing and Verification Process – Configuration Management Process

– Quality Assurance Process




DO-178B Overview

n Each process has inputs, outputs and transition criteria

n Descriptions of evidence needed to demonstrate an objectivehas been satisfied is included

– For example: Is the source code verifiable?

• Are analyses or tests provided that show the source code does notcontain structures that can not be tested

n The important point is that all these software lifecycleprocesses are linked in any given application: the lifecycleactivities must be traceable!




Traceability

Linkage

Test Results

Test Procedures

Source Code

Design

Requirements

Review

Review

Review

Review

Review




Software Verification




Software VerificationDO-178B Definition:

Verification is not simply testing. Testing, in general,cannot show the absence of errors.

As a result the DO-178B subsections use the term “verify”

instead of “test” when the software verification processobjectives being discusses are typically a combination ofreviews, analyses and tests.




Software TestingBlack Box Testing

White Box Testing

Requirements Based Testing

Decision Coverage

Boundary Value

DO-178B discusses requirements-based testing and coverage analysis




Level A and Software Safety

n Level A – Software whose anomalous behavior, as shown by the systemsafety assessment process, would cause or contribute to a failure of systemfunction resulting in a catastrophic failure condition for the aircraft.

n Software Safety - Ensure & verify that software takes Positive Positive

Measures Measures to enhance the safety of the system & control

errors that reduce the safety of the system.n Added Benefits include:

– Higher reliability

– Improved maintainability

– More robust system

n Level A requires that compiler added functionality be addressed – If compiler adds range checking, divide by zero, etc, then applicant must test

these features




Differences between Level A and Level B

n Independent verification of

– Software Design process

– Source Code compliance

– Source Code accuracy

– Object Code robustness

– Test Objectives

n Test coverage (Modified Condition/Decision) optional for LevelB

n Level A: MCDC Testing

n Level B: Decision Coverage

n Level C: Statement Coverage

Analysis rigor much more severe for level A




Multiple Condition/Decision testing

if A=0 and B<2 and C>5 then P; ......

A=0 B<2 C>5

T TTT

FTTF

T FTF

T FT F

P

For Level A, each outcome must be tested once




VxWorks and DO-178B Certification




Software Components of a System

VxWorks

User Code

Target System

System

Operating

System




VxWorks Description

n Commercial RTOS enviroment in use for > 10 years

n VxWorks consists of:

– High performance Real-time Kernel

– I/O System: Network, serial, pipes, drivers, etc.

– Utility Libraries: timers, interrupts, messages, memory allocation, etc.

– Shared memory objects for multiple processors

– Board Support Packages: drivers, timers, memory mapping, etc.

• Over 100 targets supported

– Tools: simulator support, logic analyzer and performance evaluation

– SLOC: 2,000,000 lines

• BSPs and drivers: 800,000 lines• Network: 250,000 lines

– architectures supported: 32+




Real-time Kernel description

n Wind Kernel at the heart of VxWorks• Scalable Micro-Kernel

• Multi-tasking

• Pre-emptive priority based scheduling

• Optional round-robin (fair) scheduling

• inter task communication (messages and semaphores) and synchronization• Fast context switching

• Low interrupt latency

• Fast interrupt response time

• Nested interrupts support

• 256 priorities




VxWorks Certification Strategy

n Plan: Reverse Engineer VxWorks version 5.4 to meet theobjectives of RTCA/DO-178B, Level A

– VxWorks subset API rationale guidelines

• FAA guidelines to Level A objectives as defined by RTCA/DO-178B

• Requirements from RTCA/DO-255 and ARINC 653 taken into consideration

• API of the subset remains consistent with VxWorks• Functions compromising predictability and leading to memory fragmentation

are eliminated





n Start with examination of the source code and architecture

– determine functions which are predictable and certifiable

– eliminate unnecessary functionality and any features that may

compromise a safety-critical application

n Define a true subset of VxWorks that may be certified

– removed:

• network protocol support and file systems

• shared memory for multiple processors

• Object-oriented features: Dynamic links, other C++ features

• Debug facilities, BSPs, and various tools

• Dynamic allocation and de-allocation of memory





n Create a subset definition and rationale

– results in a scaled-down version of VxWorks

• 15K SLOC

n Create Software Hazard Analysis

– Identifies potential failure conditions in the software, their potential

impact, and proposed mitigation

– updated at each phase of the software lifecycle

n Create a Plan for Software Aspects of Certification (PSAC) thatdescribes the reverse engineering strategy

– Provides the Certification Authorities an overview of the means of

compliance and insight into the planning aspects for delivery of the

product





n Reverse Engineering Approach: Meet all 66 objectives of DO-178B, Level A

n Reverse Engineer = Planning, Requirements, Design, Code,Tests, SCM and SQA

– Existing Software Life Cycle Items:

• Fully functional VxWorks software (source code and objects)

• Design documentation in the form of headers and comments

• Configuration management and corporate SQA policy

– Configuration Items to be reverse engineered:

• Software Quality Assurance Plan

– Defines the SQA process and activities

• Software Configuration Management Plan – Defines the CM system and change control process.




Code Exists - Requirements re-engineered

Requirements

Design

Code

Test

1

2





n Configuration Items to be reverse engineered (con’t):

– Software Development Plan

• Defines the processes used for requirements analysis, development, and

test for the software product. Includes the standards for requirements,design, and code. Includes:

» Software Requirements Standards» Software Design Standards

» Software Coding Standards

– Software Verification Plan

• Defines the test philosophy, test methods and approach to be used to verify

the software product

– Software Requirements Specification

• Defines the high-level requirements applicable to the certifiable VxWorkssubset






– Tool Requirements Document

• Defines the required functional behavior of a verification tool under normal

operating conditions

• Verification Tool to support MCDC testing






– Software Design Document

• Describes the design of the certifiable VxWorks subset components

– Use off-the-shelf tools to examine the software design

– Software Development Folder

• Software Development Folder includes as a minimum:

– Reference to the applicable requirements

– Reference to the implementation (Design & Code)

– Evidence of reviews for the Requirements, Design, Code, and Test

procedures

– Software Test Procedures

– Software Test Results – Change History (CM System)

– Applicable Problem Reports






– Version Description Document with Software Configuration Index andSoftware Life Cycle Environment Configuration Index

• Identifies the components of the certifiable VxWorks subset with version

information necessary to support regeneration of the product. Includes the

tools used to build and test VxWorks image

– Tool Qualification Document

• Documents the qualification evidence for a verification tool against the

requirements established in the PSAC and Tool Requirements Document

– Traceability Matrix

• Provides traceability from the requirements, to implementation, to test for the

delivered software product






– Software Accomplishment Summary

• Documents the actual versus planned (per PSAC) activities and results for

the project. Provides a summary of the means of compliance used for the

software.

– Sources• Provides the Source files for:

– Certifiable VxWorks subset

– Test Procedures

– Build and Test Scripts

– Results

• Documents the results of the functional and structural coverage testing. Thisincludes the actual results and any applicable analyses performed including

coverage analysis





n Approval Process

– Wind River delivers all evidence of DO-178B compliance with itsoperating system and tools

– Relationship with Application Developer DER or regional FAA office

– Application Developer begins the DO-178B certification process for the

application (PSAC) – Customer builds application around the OS with the restriction that no

sources are modified

– Attempts to build a modified image will result in compile or link errors

– Customer certifies its application under a TSO or STC

• Wind River OS is “certified” along with the application

– Wind River will defend its certification materials during any audits





n Current Status

– FAA audits passed and complete as of July 17, 2001

– Currently working on extensions to OS and BSP certification

– Work on VxWorks AE certification has begun

Sources: DO-178B, Wind River and Verocel, Inc.