do 178b overview
TRANSCRIPT
- 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 buildBy 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 LevelsSoftware 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
C
Major
D
Minor
E
By Jacinth Paul
No effect
Software AnalysisThe 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
Objectivesy 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 noneBy Jacinth Paul
Few Key PointsDO-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 Pointsy 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
Processesy 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 Processy 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 PlanBy Jacinth Paul
Software Development Processy 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 ProcessThe 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 modelBy Jacinth Paul
Integral Processesy 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
Verificationy 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
Verificationy 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 LevelsLevel 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 ManagementThe 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 ManagementDocuments maintained by the configuration management process: y Software configuration index (SCI) y Software life cycle environment configuration index (SECI)
By Jacinth Paul
Software Quality Assurancey 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
SQAOutput 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 Processy 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 Summary1.By Jacinth Paul
Previously Developed SoftwarePDS 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 levelBy Jacinth Paul
Toolsy 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 toolsBy Jacinth Paul
Levels of Structural Testingy SC: Statement Coverage. y DC: Decision Coverage y MCDC: Modified Condition Decision CoverageLevel 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 Risksy 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 coverageBy Jacinth Paul
DO-178B Certification Risksy 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 fy y y y y y y y y y y y y y y
17
c
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