Software Life Cycle Process - DO-178B



Similar documents
SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE. Cheryl A. Dorsey Digital Flight / Solutions cadorsey@df-solutions.

DO-178B/C Differences Tool

SOFTWARE VERIFICATION RESEARCH CENTRE SCHOOL OF INFORMATION TECHNOLOGY THE UNIVERSITY OF QUEENSLAND. Queensland 4072 Australia TECHNICAL REPORT

Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center

1. Software Engineering Overview

SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-178B LEVEL A & B

Certification of a Scade 6 compiler

Introduction for Software Configuration Management Training

Certification Authorities Software Team (CAST) Position Paper CAST-13

AC REUSABLE SOFTWARE COMPONENTS

ELECTROTECHNIQUE IEC INTERNATIONALE INTERNATIONAL ELECTROTECHNICAL

How To Write Software

Certification Authorities Software Team (CAST) Position Paper CAST-26

3SL. Requirements Definition and Management Using Cradle

Impact of Safety Standards to Processes and Methodologies. Dr. Herbert Eichfeld

Application of software product quality international standards through software development life cycle

Software Test Plan (STP) Template

Software Configuration Management Plan

IEC Overview Report

asuresign Aero (NATEP Grant MA005)

System Development Life Cycle Guide

Rev 1 January 16, 2004

CHAPTER 7 Software Configuration Management

RTCA DO-178B/EUROCAE ED-12B

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

DO-178B compliance: turn an overhead expense into a competitive advantage

WORKSHOP RC EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior

An Introduction to the ECSS Software Standards

Parameters for Efficient Software Certification

FSW QA Testing Levels Definitions

Subject Software Aspects of Certification

8. Master Test Plan (MTP)

Implementation of ANSI/AAMI/IEC Medical Device Software Lifecycle Processes.

The Impact of RTCA DO-178C on Software Development

NATO GUIDANCE ON THE USE OF THE AQAP 2000 SERIES

Example Software Development Process.

Software Review Job Aid - Supplement #1

Procedure for Assessment of System and Software

<name of project> Software Project Management Plan

R214 SPECIFIC REQUIREMENTS: INFORMATION TECHNOLOGY TESTING LABORATORY ACCREDITATION PROGRAM

Reduce Medical Device Compliance Costs with Best Practices.

WIND RIVER RTCA DO-178 SOFTWARE CERTIFICATION SERVICES

CERTIFICATION MEMORANDUM

Interactive Guidance for Safety Critical Avionics

VAIL-Plant Asset Integrity Management System. Software Development Process

SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE. Version A.4, January 2014 FOREWORD DOCUMENT CONVENTIONS

Meta-Model specification V2 D

Design Specification for IEEE Std 1471 Recommended Practice for Architectural Description IEEE Architecture Working Group 0 Motivation

How To Write An Slcm Project Plan

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

CDC UNIFIED PROCESS PRACTICES GUIDE

Space Project Management

Revision History Revision Date Changes Initial version published to

Chap 1. Introduction to Software Architecture

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

An integrated life cycle quality model for general public market software products

Software testing. Objectives

To introduce software process models To describe three generic process models and when they may be used

The Role of CM in Agile Development of Safety-Critical Software

Montana Department of Transportation Information Services Division. System Development Life Cycle (SDLC) Guide

Systems Engineering Process

How To Validate Software

Enterprise Test Management Standards

System Requirements Specification (SRS) (Subsystem and Version #)

ISO COMPLIANCE WITH OBSERVEIT

codebeamer INTLAND SOFTWARE codebeamer Medical ALM Solution is built for IEC62304 compliance and provides a wealth of medical development knowledge

Software Testing Standards: Do They Know What They re Talking About?

How to Upgrade SPICE-Compliant Processes for Functional Safety

Certification Authorities Software Team (CAST) Position Paper CAST-18

SOFTWARE DEVELOPMENT AND DOCUMENTATION

TITLE: Control of Software

Request for Proposal for Application Development and Maintenance Services for XML Store platforms

Introduction to a Requirements Engineering Framework for Aeronautics

Safety Issues in Automotive Software

SOFTWARE QUALITY MANAGEMENT THROUGH IMPLEMENTATION OF SOFTWARE STANDARDS

Syllabus. REQB Certified Professional for Requirements Engineering. Foundation Level

Medical Software Development. International standards requirements and practice

Mission Operation Ground. ESA. Mario Merri GSAW, Los Angeles, USA 2 Mar 2011 ESA UNCLASSIFIED

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

CDC UNIFIED PROCESS JOB AID

2015. All rights reserved.

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

A DEVELOPMENT FRAMEWORK FOR SOFTWARE SECURITY IN NUCLEAR SAFETY SYSTEMS: INTEGRATING SECURE DEVELOPMENT AND SYSTEM SECURITY ACTIVITIES

System Design Description template

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

ITS Projects Systems Engineering Process Compliance Checklist

What is ISO/IEC 15288? (A Concise Introduction)

Page 1 of 7 Effective Date: 12/18/03 Software Supplier Process Requirements

An Increase in Software Testing Robustness: Enhancing the Software Development Standard for Space Systems

Information Technology Engineers Examination. Information Security Specialist Examination. (Level 4) Syllabus

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

ENEA: THE PROVEN LEADER IN SAFETY CRITICAL AVIONICS SYSTEMS

SOFTWARE ASSURANCE STANDARD

Software in safety critical systems

Anwendung von Polyspace im Software Entwicklungsprozess nach IEC München, , Dr.-Ing. Jörg Barrho

Certified Software Quality Engineer (CSQE) Body of Knowledge

5 Certifiable safe airborne software process analyses

Using TechExcel s DevSuite to Achieve FDA Software Validation Compliance For Medical Software Device Development

Transcription:

1(19) Cross reference tables for H ProgSäk (E) and DO-178B A comparison has been made between requirement areas covered by H ProgSäk (E) and DO-178B respectively. Tables for correspondences and differences are presented below. An exact mapping of requirements from one document on associated requirements of another document is not possible. Formulation, structuring and refinement of the requirements within a specific area will always differ between compared documents. The presented tables are therefore only indicative of where matching requirement areas can be found. Section 1 summarizes the main differences between the compared documents. Section 2 contains tables for all requirements of H ProgSäk 1, each identified by a unique label (cf. Legend ). Section 3 includes requirements of DO-178B not covered by H ProgSäk (E). Section 4 and 5 present acronyms and references used in this document. 1. Comparisons between H ProgSäk (E) and DO-178B Both H ProgSäk and DO-178B include guidelines as well as requirements for safety-critical software and describe processes for development of such software. DO-178B requires a System Safety Assessment Process (SSA), which not is described in DO-178B or in any of its referenced documents. Software Life Cycle Process - DO-178B Input from System Life Cycle Process System Requirements allocated to SW, SW Level, Design Constraints, HW Definition Planning Resources Development Products Integral SW Development Environment Configuration Management Quality Assurance Standards Plans Problem Reports SW Development plan SW Certification plan SW Verification plan SW CM Plan SW QA plan SW Req. std. SW Design std SW Development Process System req alloc to sw, hw interfaces, system architecture SW Requirements Data, high-level requirements & derived requirements Design Description, SW architecture & low-level requirements Source Code, compiler instructions, linking&loading data Executable Object Code SW Verification Cases, Procedures & Results Baseline SW Code std. SW req std dev env highlevel compiler Requirement process test env SCM Records, SCM Index, SW Life Cycle Environment Configuration Index, Traceability, Archive SQA Records Software Planning Process Prototyping SW design std Iterations Previously developed SW Design process Low-level req sw architecture Verification process SW code std Coding process Configuration Management process Quality Assurance process Certification Liaison process Source code Verification Cases & Procedures Source code Source code Integration process Object code SW Verification Result SW Accomplishment Summary Ouput to System Life Cycle Process Fault Containment Boundaries, Error Sources identified/ eliminated, SW requirements & architecture 1 Basic requirements (i.e. requirements common to safety-critical as well as non-critical software) are found in H ProgSäk: Chap. 5. General safety requirements for software can be found in H ProgSäk: Chapters 2-4.

2(19) DO-178B specifies requirements for: A Certification Liaison Process aiming towards an airworthiness certificate. Project plans for the development project including plans for development, verification, configuration management (CM), and quality assurance (QA). The planning involves establishment of standards for requirement specification, design and coding. The processes for requirements, design, coding and integration The support processes for verification, configuration management and quality assurance Documentation to be produced within the defined processes. DO-178B defines Failure Condition Categories and Software Levels. Some guidance for technical solutions and how to handle COTS and reused software is provided. DO-178B is not a complete lifecycle standard but a complement focused on safety-critical issues for projects developing software for airborne equipment. H ProgSäk requires also a system safety process, described and specified in H SystSäk for the parties involved in procurement of systems for the Swedish Armed Forces (FM), e.g. the FM, the Defence Materiel Administration (FMV), and the Industry. H SystSäk includes safety requirements for all types of systems, the activities and organisation of the system safety work, methods for safety analyses and how to specify and refine the requirements on system and component level. H SystSäk also describes how to attain, maintain and verify safety requirements on system level during development, operation and disposal. For development of safety-critical software the 1996 edition of H SystSäk 2 refers to unspecified sectors of the MIL-STD-498 and the DOD-STD-2168 standards. Society: The public tolerance of deaths and injuries expressed in laws and ordinances. FM specifies the tolerable risk level for a new FM system in a TTFO/ TTEM. FMV produces a system specification including safety requirements. Industry applies a system safety methodology on the system under development and compiles the safety effort in a SCA. FMV produces a Safety Statement, including recommended Safety Restrictions. FM issues a Safety Release/ BOA including Safety Restrictions. H ProgSäk specifies safety requirements for the entire software lifecycle from the conceptual phase to development, operation, maintenance and retirement of the safety-critical software. The 2001 edition of H ProgSäk refers to specific parts of the software lifecycle standard IEC 12207 and the software quality standard ISO 9000-3. Compared to DO-178B, H ProgSäk covers a larger part of the lifecycle, specifying more detailed requirements for the lifecycle processes, the software products and their stakeholders. H ProgSäk also contains explanations of different software safety concepts, discussions on various safety issues, safety analysis techniques suitable for software as well as overviews and comparisons between safety standards and handbooks of interest to the defence sector. 2 A new version is planned.

3(19) 2. DO-178B compliance with H ProgSäk (E) requirements Compliances and differences in relation to requirements areas covered by H ProgSäk (E). Legend: Column Explanation H ProgSäk Id H ProgSäk Id is a unique requirement identity consisting of 3 parts: The 1 st part (6.) is a unique number for the handbook H ProgSäk within FMV. The 2 nd part is the section number in H ProgSäk where the requirement statement is found. The 3 rd part is letter K followed by the sequence number for the requirement in the section. For a H ProgSäk Id associated to a basic requirement 1 a reference is given to the section in table 5.1 or 5.2 where the basic requirement is listed (e.g. 6.321K1: Cf. 5.2. ). A single H ProgSäk Id addressing several sections in ISO/IEC 12207 is below refined by appending the section number within quotes (e.g. 6.5121K1 6.3 in Table 5.1). One table entry per section is provided (see table 5.1 below). A further refinement into subsections is made if needed for the comparison (e.g. 6.5223K1 6.4. in Table 5.2). Critic. The criticality categories for which the requirement H ProgSäk Id applies are specified: H(igh), M(edium), L(ow) for software of high, medium or low criticality, B(asic) for a requirement relevant to safety-critical as well as non-critical software. DO-178B References to matching requirements in DO-178B are provided in the following format: paragr. a) Specified references are either one or a few direct references to matching sections in DO- 178B, or a broader reference to an entire chapter (the latter denoted Chap. ). b) A parenthesized reference means that the referred section is in the spirit of the H ProgSäk requirement, but without any obvious match. c) - denotes that the requirement area is not at all covered by DO-178B (further explanations may then be provided in the Comments column). d) + indicates that matching DO-178B references are listed in the subtable specified in the Comments column (may be relevant to a H ProgSäk Id representing a basic requirement). Comments The column includes remarks concerning the type of partial coverage that the specified DO-178B reference involves (case a-b above), requirement areas not covered by DO-178B (case c above), the subtable in this document, where for a basic requirement matching DO-178B sections are listed (case d above), or DO-178B Annex A other explanations or exceptions. Capital letters A-D in references to DO-178B Annex A refers to DO-178B software levels. Letters in reverse background denotes software lifecycle data which must be created with independence (from the developing organisation). A blank in any of the first 3 columns in the tables below is a sign of omission, which should be solved.

4(19) H ProgSäk E Chapter 2. CLIENT/END-USER (FM) Personnel 6.21K1 - No requirements for the client. 6.21K2-6.21K3-2.2 Control processes 2. System safety planning, management and assessment 6.221K1 - No requirements for the client. 6.221K2a - 6.221K2b - 6.221K2c - 2.3 The FM Defence Materiel Acquisition Process No requirements 2.4 Products 2.4.1 TTFO, TFOTM (TTEM, TEMU) 6.241K1 - No requirements for the client. 6.241K2-6.241K3-6.241K4-6.241K5 -

5(19) Chapter 3. ACQUIRER (FMV) 3.1 Personnel 6.31K1 - No requirements for the purchaser. 3.2 Control processes 3. Project planning, management and assessment 6.321K1: Cf. 5.2. B - No requirements for the purchaser. 3.2.2 System safety planning, management and assessment 6.322K1-6.322K2 - No requirements for the purchaser. 6.322K3-6.322K4-6.322K5-3.2.3 Quality control 6.323K1: Cf. 5.2.2.2 3.2.4 Quality assurance 6.324K1: See 5.1. B - 6.324K2a - 6.324K2b - 6.324K2c - 6.324K2d - 6.324K2e - B - No requirements for the purchaser. No requirements for the purchaser. 3.3 The FMV Defence Materiel Acquisition Process H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 3.3.1 Studies 3.3.2 Procurement 6.332K1: See 5.1.3.1 B - No requirements for the purchaser. 3.3.3 Operation and Maintenance (Lifecycle Management, LCM) 6.333K1: See 5.1.3.2 3.3.3.1 Modifications of a completed system 6.3331K1-6.3331K2-6.3331K3-6.3331K4-3.3.4 Disposal B - No requirements for the purchaser. No requirements for the purchaser. 3.4 Products H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 3.4.1 Statement of Work (SOW) 6.341K1 - No requirements for the purchaser.

6(19) 3.4 Products H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 6.341K2 H - 6.341K3-6.341K4 HM - 6.341K5 H - 6.341K6-6.341K7-3.4.2 Time Plans (Operational Plans) (TP) 3.4.3 Lifecycle Management Support (LCMS) 6.343K1a - No requirements for the purchaser. 6.343K1b - 6.343K2 H - 3.4.4 Technical Specification (TS) 6.344K1 - No requirements for the purchaser. 6.344K2-6.344K3 H - 6.344K4-6.344K5 HM - 6.344K6 - H ProgSäk E Chapter 4. SUPPLIER 4.1 Personnel 6.41K1 - Requirements for personnel can only be derived 6.41K2a - from the process requirements. 6.41K2b - 6.41K3 H - 6.41K4 M - 6.41K5 HM - 6.41K6-6.41K7-6.41K8-6.41K8a H - 6.41K8b M - 6.41K8c L - 6.41K8d - 4.2. Control processes 4. Project planning, management and assessment 6.421K1: See 5.2. B + See 5.2. 6.421K2 - No requirements for staff. 4.2.2 System safety planning, management and assessment

7(19) 4.2. Control processes 6.422K1 - A System Safety Program Plan (SSPP) is assumed to exist on the level above the one addressed by DO-178B. 4.2.3 Quality control 6.423K1: See 5.2.2.2 B - 4.2.4 Quality assurance 6.424K1: See 5.2.2.3 B + See 5.2.2.3 6.424K2 6.3, 6.4 4.2.5 Configuration management 6.425K1a: See 5.2.2.4 B 7.1a + See 5.2.2.4 6.425K1b: See 5.2.2.4 B 7.2.9 + See 5.2.2.4 6.425K1c: See 5.2.2.4 B 11.0h + See 5.2.2.4 4.3. Production processes 6.43K1: See 5.2.3 B + See 5.2.3 6.43K2 H 1.1 A SSA Process is assumed to exist on the level above the one addressed by DO-178B. 6.43K3 H - 6.43K4 H - 4.3.1 Development model 6.431K1: See 5.2.3.1 B + See 5.2.3.1 4.3.2 Development methodology 6.432K1: See 5.2.3.2 B + See 5.2.3.2 4.3. Formal methods 6.4321K1 HM 12.3.1 6.4321K2 (6.4.1a) Does not cover formal methods. 4.3.2.2 Verifications 4.3.2. iews (manual verification) 6.43221K1 6.3 4.3.2.2.2 Static analysis (source code verification) 6.43222K1 6.3.4 6.43222K2a 6.3.4b A-5.2(ABC) 6.43222K2b 6.3.4d A-5.4(ABC) 6.43222K2c 6.3.4d A-5.4(ABC) 6.43222K2d HM 6.3.4d A-5.4(ABC) 6.43222K2e H (6.3.4f) A-5.6(ABC) 6.43222K3 11.14 4.3.2.2.3 Behaviour analysis

8(19) 4.3. Production processes 4.3.2.2.4 Object code analysis 6.43224K1 H (6.4.4.2b), 6.1d, 12.2 6.43224K2 H 11.14 4.3.2.2.5 Dynamic analysis (verification by test) 6.43225K1: See 5.2.3.3 B + See 5.2.3.3 6.43225K2.1 Safety requirements are handled as high-level 6.43225K3a 6.4 6.43225K3b HM 6.4 6.43225K3c H 6.4 6.43225K4a - 6.43225K4b - 6.43225K4c - requirements allocated to software. Different test levels not explicitly addressed. 6.43225K5 HM 6.4.4.2a, 6.4.4.3c-d A-7.7(ABC) 6.43225K6 H 6.4d, 6.4.4.2a, 6.4.4.3a A-7.6(AB) A-7.7(ABC) 6.43225K7 H - Same as 6.43225K6 in the spirit of DO-178B. 6.43225K8 6.4.4.1b, 6.4.4.2a, 6.4.4.3a DO-178B has no specific requirements for testing of multiple simultaneous error conditions. A-7.6(AB) A-7.7(ABC) 6.43225K9 - No requirement for when testing shall be conducted. 6.43225K10 6.4.4.2a, 6.4.4.3a A-7.6(AB) A-7.7(ABC) 6.43225K11 6.4.2.2 6.43225K12 HM 6.4.4.3c-d Deals with all code which is not used in operational modes. 6.43225K13 6.4.4.3d 6.43225K14 6.2c, 6.4.1a The term final test does not exist in DO-178B. 6.43225K15-6.43225K16-4.3.2.2.6 Statistical failure analysis Failure forecasting 6.43226K1 H - 6.43226K2 H - 4.3.2.2.7 Resource analysis 6.43227K1-6.43227K2 6.3.1c, 6.3.2c A-4-3(AB) 6.43227K3 6.4.3a-bullit-2 6.43227K4 6.4.3a 4.3.3. Software safety analysis 6.433K1-6.433K2-6.433K3-6.433K4-6.433K5 H - 6.433K6-6.433K7 HM - 6.433K8 - SSA is not part of DO-178B.

9(19) 4.3. Production processes 6.433K9 H - 6.433K10-6.433K11-6.433K12-6.433K13-4.4 Production environment 4.4.1 Support tools 4.4.1.1 Configuration management system 6.4411K1 HM Chap. 7 DO-178B dictates no requirements for tools. Tools are however necessary to fulfill the requirements. 6.4411K2: See 5.2.4.1.1 B + See 5.2.4.1.1 4.4.1.2 Failure reporting system 6.4412K1 7.2.3 DO-178B only covers software development and documentation for the continued life-cycle. DO-178B dictates no requirements for tools. 6.4412K2: See 5.2.4.1.2 B + See 5.2.4.1.2 6.4412K3 (7.2.3) However not nearly as detailed as in 4412K3. 6.4412K4 - No requirements for how tools shall work. 4.4.1.3 Requirement management tools 6.4413K1 H (6.3.1f, 6.3.2f, 6.3.4e) DO-178B dictates that requirements shall be traceable. There is however no requirement for any tools. 6.4413K2a H (7.1h) 6.4413K2b H (7.1h) 4.4.2 Software tools 6.442K1a 4.4 6.442K1b H 12.2 No requirements for independent qualification nor for official standards. 6.442K2 H 12.a-b 6.442K3 (12.2) Necessary SSA done outside DO-178B. 6.442K4-4.4. Formal tools 6.4421K1 12.2 4.4.2.2 Code generators 6.4422K1 H 4.4.1, 12.2 6.4422K2 HM (12.2.3.2) Known bugs can be perceived as an operational limitation. 6.4422K3 H 12.2 6.4422K4 12.2 6.4422K5 4.4.2c 6.4422K6 4.4.2c 6.4422K7 HM (12.2) DO-178B allows any optimization as long as such are qualified. 6.4422K8 L 4.4.2a

10(19) 4.4 Production environment 6.4422K9 H - 6.4422K10 H - 6.4422K11 ML 4.4.2b, 6.4.4.2b A-7.7(ABC) 4.4.2.3 Static and dynamic analysis tools 6.4423K1 HM - 6.4423K2 HM - 6.4423K3 - DO-178B dictates no requirements for usage of tools. 4.4.3 Emulated target machine 6.443K1 4.4.3 DO-178B does not dictate any minimum level of similarity between target and emulator. 6.443K2 (12.2.3) DO-178B requires qualified tools to be documented. 6.443K3 - Not explicitly stated in DO-178B, however understood. 4.5 Products 4.5.1 Standard products Reused components Off the shelf items 6.451K1 H 1.6-6.451K2a ML (12.3.5) 6.451K2b ML - 6.451K2c ML 1.4, 11.3i, 6.451K3 1 6.451K4-6.451K5 2.3.1 The requirement is true for all software. 6.451K6 6.451K7 6.451K8 6.451K9 6.451K10 HM 6.451K11 HM 6.451K12 6.451K13 6.451K14a 1, 7.2.4d, 6.451K14b 7.2.5b, 11.3h 6.451K14c 6.451K14d 6.451K14e 4.5.2 New software development 4.5. Specification 6.4521K1: See 5.2.5. 6.4521K2 H 5.1.2h, 5.1.2i, 5.1, 5.5 6.4521K3 M 5.1.2h, 5.1.2i, 5.1, 5.5 4.5.2.2 Software architecture / top level design 6.4522K1 2.3 (1) Falls within possibly necessary tasks to satisfy 1, but not nearly this detailed in DO-178B. B + See 5.2.5. Regression tests are not mentioned in DO-178B. It is however in practice necessary to achieve a certification if changes are made.

11(19) 4.5 Products 4.5.2.3 Fundamental design principles 6.4523K1 4.1e, 4.5c, 5.2.2a A-1.5(ABC) 6.4523K2, 5.2.2c-e, 11.10 6.4523K3 - A fraction of this is covered in 11.10.l 4.5.2.4 Safety-oriented design principles 4.5.2.4.1 General principles 6.45241K1 4.5c, 6.3.3d-e, 6.3.4c-d 6.45241K2 - Follows automatically from using DO-178B. 6.45241K3-6.45241K4-6.45241K5 7., 11.4 6.45241K6 2.3.1 No strict correspondence between DO-178B partitioning and SW configuration items in general. 6.45241K7 HM (5.1.2a) In a general sense. 6.45241K8 HM - 6.45241K9 6.4.4.3c 6.45241K10 HM 6.4.4.3c 6.45241K11 6.4.4.3d 6.45241K12 HM 5.5c, 6.4.4.3d 4.5.2.4.2 Risk reduction 6.45242K1a.2, How to handle risks is part of the SSA and not 6.45242K1b described in DO-178B. 6.45242K1c 6.45242K2 HM 2.3.3c 6.45242K3-6.45242K4-6.45242K5 2.3.1 6.45242K6 2.3.1 6.45242K7 ML 2.3.3c 6.45242K8 H 2.3.3 No requirement for physical separation. 6.45242K9 - SSA not part of DO-178B. 4.5.2.4.3 Resource and time allocations (real-time) - Scheduling algorithms 6.45243K1 6.3.2c, 6.3.4f, 6.4.2.2e 6.45243K2 - No requirement for memory allocation. 4.5.2.4.4 Defensive programming 6.45244K1-6.45244K2-6.45244K3-6.45244K4-6.45244K5-6.45244K6-6.45244K7-6.45244K8-6.45244K9-6.45244K10-6.45244K11 - DO-178B contains no instructions on defensive programming.

12(19) 4.5 Products 6.45244K12 H - 4.5.2.4.5 Error handling - Error recovery - Fault tolerance 6.45245K1-6.45245K2-6.45245K3-6.45245K4-6.45245K5-6.45245K6 HM - Must be handled in external system requirements or design standards. 6.45245K7-6.45245K8-6.45245K9-4.5.2.5 Language and language constructs 6.4525K1 12.2 6.4525K2-6.4525K3 11.8 6.4525K4-6.4525K5-6.4525K6-6.4525K7-6.4525K8-6.4525K9-6.4525K10-6.4525K11-6.4525K12a - 6.4525K12b - 6.4525K12c - 6.4525K13a - 6.4525K13b - 6.4525K13c - 6.4525K13d - 6.4525K13e - 4.5.2.6 Language constraints 6.4526K1 4.5c, 11.8 6.4526K2 11.8a 6.4526K3 HM - 6.4526K4-4.5.2.7 Coding Instructions 6.4527K1a 11.8 6.4527K1b 11.8b, 11.8c 6.4527K1c 11.8d 6.4527K1d 11.8e 6.4527K1e 11.8 Not explicitly mentioned but may very well be part of a good coding standard. 6.4527K2-6.4527K3 6.3.4d 4.5.2.8 Interfaces 6.4528K1-6.4528K2 HM - 6.4528K3 -

13(19) 4.5 Products 6.4528K4-6.4528K5-6.4528K6-6.4528K7-6.4528K8-6.4528K9-6.4528K10-6.4528K11-6.4528K12-6.4528K13-6.4528K14-6.4528K15 HM - 6.4528K16-6.4528K17-6.4528K18-6.4528K19 HM - 6.4528K20 HM - 6.4528K21-6.4528K22-6.4528K23 HM - 6.4528K24 M - 6.4528K25 H - 6.4528K26-6.4528K27-4.5.2.9 Detailed design 4.5.0 Test software for operation and maintenance 6.45210K1-6.45210K2 6.4.4.3d 6.45210K3-6.45210K4-4.5.1 Implementation / Code 4.5.2 Changes during production 6.45212K1a 7.2.5b SSA is not part of DO-178B. 6.45212K1b 7.2.5 6.45212K1c - 6.45212K1d 7.2.4b 6.45212K1e 1.1, 11.3h Regression tests are not explicitly mentioned. 6.45212K1f 1.1, 11.3h Regression tests are not explicitly mentioned. 4.5.3 Documentation / Information 6.45213K1: See 5.2.5.2.2 B + See 5.2.5.2.2 6.45213K2 11.20 DO-178B defines the Software Accomplishment Summary as the primary data item to show compliance with the Plan for Software Aspects of Certification. Aimed to airworthiness certification of SW controlled equipment. 6.45213K3 HM (Chap. 7) No strict requirements addressing the level of granularity. 6.45213K4 L (Chap. 7)

14(19) 4.5 Products 4.5.3.1 Development 6.452131K1a 11.9-11.14 Approximately 11.9, 11.10. 6.452131K1b 11.9-11.14 In particular 11.10 4.5.3.2 System Lifecycle Management (LCM) 6.452132K1a - 6.452132K1b - 6.452132K1c - 6.452132K1d - 6.452132K1e - 6.452132K1f - 6.452132K1g - 6.452132K1h - 4.5.3.3 Software maintenance 6.452133K1a - 6.452133K1b - 4.5.3.4 Documentation list 4.5.3 Target computer environment 6.453K1a 2.3.3 6.453K1b (2.3.3) 6.453K1c - 4.5.3.1 Operating and run-time systems 6.4531K1-6.4531K2 2.4f 2.4f deals with all COTS (including O/S). 6.4531K3 2.4f 2.4f deals with all COTS (including O/S). 6.4531K4-6.4531K5: See 5.2.5.3.1 B - 6.4531K6a - 6.4531K6b - 6.4531K6c - 4.5.3.2 Hardware equipment 6.4532K1 - H ProgSäk E Chapter 5. BASIC REQUIREMENTS 5.1 Acquirer H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 5.1.1 Personnel (blank section) 5.1.2 Control processes 5.1. [3.2.4. Quality assurance] 6.5121K1 6.3 - No requirements for the purchaser. 6.5121K1 6.4-6.5121K1 6.5-6.5121K1 6.6-6.5121K1 6.7-5.1.3. The FMV Defence Materiel Acquisition Process

15(19) 5.1 Acquirer H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 5.1.3.1 [3.3.2. Procurement] 6.5131K1 - No requirements for the purchaser. 5.1.3.2 [3.3.3. Operation and Maintenance (Lifecycle Management, LCM)] 6.5132K1 - No requirements for the operational phase. 6.5132K2-5.2. Supplier H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 5. Personnel (blank section) 5.2.2 Control processes 5.2. [4.. Project planning, management and assessment] 6.5221K1 7.1 Chap. 4 DO-178B does not cover project management tasks such as time schedules, resource allocation, responsibilities, costs or progress reports. 6.5221K2a - Resource and time estimates are not covered by DO-178B. 6.5221K2b Chap. 4 6.5221K2c Chap. 4 4.4.1 Environment, 4.4.2 Language and compilers. See also 12.2 Tool Qualification. 6.5221K2d Chap. 4 6.5221K2e - DO-178B does not explicitly cover stepwise development. 6.5221K2f - Covered at some extent in additional considerations 1 6.5221K2g - DO-178B does not explicitly handle how-to introduce corrections with respect to regression tests. 5.2.2.2 [4.2.3. Quality control] 6.5222K1-6.5222K2 - DO-178B does not cover any general QA-system. 5.2.2.3 [4.2.4. Quality assurance] 6.5223K1 6.3 Chap. 8 DO-178B SQA-process dictates no requirements for the commercial contracts, staff knowledge/training or for any general organisational QA-system (e.g. ISO9001). 6.5223K1 6.4. (Contr. verif.) 6.5223K1 6.4.2.2 (Process verif.) 6.5223K1 6.4.2.3 (Req:s verif.) - A-1.1 (ABCD) A-1.2 (ABC) A-1.3 (ABC) A-1.4 (ABCD) A-1.5 (ABC) A-1.7 (ABC) A-9.1 (ABCD) A-9.2 (AB) A-9.3 (ABCD) 4.6 A-1.6 (ABC) A-1.7 (ABC) 6.3.1, 6.3.2 A-3.1 (ABCD) A-3.2 (ABCD) A-3.3 (AB) A-3.4 (ABC) A-3.5 (ABC) A-3.6 (ABCD) A-3.7 (ABC) A-4.1 (ABC) A-4.2 (ABC) A-4.3 (AB) A-4.4 (AB) A-4.5 (ABC) A-4.6 (ABC) A-4.7 (ABC)

16(19) 5.2. Supplier H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 6.5223K1 6.4.2.4 (Design verif.) 6.3.3 A-4.8 (ABC) A-4.9 (ABC) A-4.10 (AB) A-4.11 (AB) A-4.12 (ABC) 6.5223K1 6.4.2.5 (Code verif.) 6.5223K1 6.4.2.6 (Integr. verif.) 6.5223K1 6.4.2.7 A-4.13 (ABCD) 6.3.4 A-5.1 (ABC) A-5.2 (ABC) A-5.3 (AB) A-5.4 (ABC) A-5.5 (ABC) A-5.6 (ABC) 6.3.5 A-5.7 (ABC) Chap. 11 (Doc. verif.) 6.5223K1 6.5-9.0 Certification Liaison Process covers the aspects of presenting records to authorities for certification. 6.5223K1 6.6-6.5223K1 6.7 8.2d, 8.3 5.2.2.4 [4.2.5. Configuration management] 6.5224K1 6.2 Chap. 7 A-8.1 (ABCD A-8.2 (ABCD) A-8.3 (ABCD) A-8.4 (ABCD) A-8.5 (ABCD) A-8.6 (ABCD) 6.5224K2 7.1b 5.2.3 [4.3. Production process] 6.523K1 5.3 Chap. 3 IEC 12207 Development Process is in general covered in the DO-178B life-cycle processes. 5.2.3.1 [4.3.1. Development model] 6.5231K1 Chap. 5 DO-178B does not specify a development process in detail. 6.5231K2 Chap. 5, 3.3 A- (ABCD) A-2.2 (ABCD) A-2.3 (ABCD) A-2.4 (ABCD) A-2.5 (ABCD) A-2.6 (ABCD) A-2.7 (ABCD) 5.2.3.2 [4.3.2. Development methodology] 6.5232K1 Chap.5, 4.5 DO-178B does not specify any methodology. 4.5 does however call for specifying standards to be used. A-1.5 (ABC) 3 5.2.3.3. Verifications [4.3.2.2.5. Dynamic analysis (verification by test)] 6.5233K1 6.4.4.1 A-7.3 (ABCD) A-7.4 (ABC) 3 See also 6.5221K2c

17(19) 5.2. Supplier H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 6.5233K2 4.3-bullit-3, 11.3 No requirements for during which phases. A-1.1 (ABCD) 4 6.5233K3-6.5233K4 7.2.4d, 11.3h 6.5233K5 6.4 DO-178B specifies the test levels HW/SW, SW integration and object code level. In DO-178B all tests must be formal (as in contrast to ad-hoc). 6.5233K6 - DO-178B does not cover the precise activities. 6.5233K7 - DO-178B does not cover the precise activities. 6.5233K8 11.3c 6.5233K9 6.4 6.5233K10 6.4d 6.5233K11 6.4.4.2a A-7.5 (A) A-7.6 (AB) A-7.7 (ABC) A-7.8 (ABC) 6.5233K12a 6.4.a, 6.4.2.2a 6.5233K12b 6.4.a 6.5233K13a 6.4.2.2c 6.5233K13b (6.4b) If a feature = requirement specified functionality, it will be covered in the requirement based testing. 6.5233K13c 6.4.2.2 6.5233K13d 6.4.2.2 6.5233K13e - 6.5233K13f 6.4.2 If performance is considered a requirement, it will be covered in the requirement based testing. 6.5233K13g - DO-178B does not explicitly cover recovery. 6.5233K14 6.2 5.2.4. Production environment 5.2.4.1. Support tools 5.2.4.1.1 [4.4.1.1. Configuration management system] 6.52411K1 Chap. 7 DO-178B dictates no requirements for tools. Tools are however necessary to fulfill the requirements. 5.2.4.1.2 [4.4.1.2. Failure reporting system] 6.52412K1 - DO-178B dictates no requirements for a Problem Resolution Process. 7.2.3 and 7.2.4 stipulates that the CMprocess shall provide control over such tasks. 6.52412K2 7.2.3, 11.17 A-8.3 (ABCD) 6.52412K3-6.52412K4-6.52412K5 - DO-178B does not dictate any requirements for organisation, staff or roles. 5.2.5. Products 5.2.5.1 Standard product (blank section) 5.2.5.2 New software development 5.2.5. [4.5.. Specification] 6.52521K1 5.1.2 6.52521K2 5.1.2h, 5.5 DO-178B dictates no explicit traceability requirements for defect reports. 4 See also 6.5221K2b

18(19) 5.2. Supplier H ProgSäk Id DO-178B paragr. Comments on DO-178B DO-178B Annex A. 6.52521K3 5.1.2e 5.2.5.2.2 [4.5.3. Documentation / Information] 6.52522K1 - DO-178B only dictates content and purpose of documents (life-cycle data), not how to produce and maintain such. 6.52522K2 11.0 DO-178B does not explicitly dictate that documentation must be correct and current. It will however not pass verification unless it is. 6.52522K3 (11.10d) 5.2.5.3. Target computer environment 5.2.5.3.1 [4.5.3.1. Operating and run-time system] 6.52531K1a - 6.52531K1b - 6.52531K1c - 6.52531K1d - 6.52531K1e - 6.52531K1f -

19(19) 3. Features in DO-178B not covered by H ProgSäk A summary of areas or requirements covered by DO-178B but not by H ProgSäk. H ProgSäk divergence from DO-178B DO-178B Requirement section DO-178B requirement number Comments on H ProgSäk sections 2.4 System Considerations for 2.4a-d Modified COTS addressed in 4.5.1 User-Modifiable Software 2.5 System design Considerations 2.5 for Field-Loadable software 9.0 Certification Liaison Process 9.0 10.0 Overview of Aircraft and 10.0 Engine Certification 12.3.2 Exhaustive Input Testing 12.3.2 12.3.5 Product Service History 12.3.5 4. Acronyms BOA/SR Beslut om Användning /Safety Release (Decision on system usage issued by FM) CM Configuration Management COTS Commercial Of The Shelf FM Försvarsmakten (the Swedish Armed Forces) FMV Försvarets Materielverk (the Swedish Defence Materiel Administration) QA Quality Assurance Software Level Criticality category defined in DO-178B SS Safety Statement (a formal safety approval by FMV submitted to FM) SSA System Safety Assessment. DO-178B assumes a SSA process (System Lifecycle process) generating input to the Software Life Cycle processes. TTEM/TTFO Taktisk Teknisk Ekonomisk Målsättning / Tactical Technical Financial Objective Swedish Armed Forces requirements for defence materiel purchasing 5. References [1] Försvarsmaktens handbok för programvara i säkerhetskritiska tillämpningar, M7762-000531, H ProgSäk 2001 5. [2] Handbook for Software in Safety-Critical Applications, M7762-000621-7, H ProgSäk E (English version) 6. [3] Försvarsmaktens handbok för Systemsäkerhet, M7740-784851, H SystSäk 1996. [4] System Safety Manual, M7740-784861, H SystSäkE 1996 6. [5] Information technology Software life cycle processes, ISO/IEC 12207, 1995. [6] Software Considerations in Airborne Systems and Equipment Certification, RTCA DO-178B, Dec. 1, 1992. 5 See http://www.fmv.se under Publikationer: Handböcker: H ProgSäk 2001. 6 A translation from Swedish of previous reference (for H ProgSäk E see web site listed in footnote 5 under Engelsk version ).