History of Aerospace Software and Standards

History of Aerospace Software and Standards
Scott Beecher 4-April-2017 This document has been publicly released ©2017 United Technologies Corporation 4-Apr-2017

Engine Manufacturers Strive for Two Types of FAA Certificates
Type Certificate (Design Approval) Declares that the design meets FAA regulations The design includes drawings, specifications, materials and processes, engine ratings and limitations Production Certificate (Quality Approval) Declares manufacturing capability to consistently produce the approved design FAA Audits manufacturer’s quality system for verification Airlines need an additional certificate… Airworthiness Certificate (Safe Operation) Declares that an individual aircraft is safe for flight Aircraft must conform to type design and be in condition for safe operation ©2017 United Technologies Corporation 4-Apr-2017

Must Follow U.S. Code of Federal Regulations (CFR)
Title 14 US - Aeronautics and Space Subchapter C: Aircraft Examples: Part 21 - Certification Procedures Part 25 - Transport Category Aircraft Part 33 - Aircraft Engines Part 34 - Fuel Venting & Emissions Part 39 - Airworthiness Directives (ADs) 4-Apr-2017 ©2017 United Technologies Corporation

FAA Office in Burlington, MA Handles All Engines/Propellers
Engine and Propeller Directorate Burlington, MA Engine Certification Office Engine and Propeller Standards FINDS COMPLIANCE TO 14 CFR PART 33 (ENGINES) (Determines if the engine complies with the rules) “OWNS” 14 CFR PART 33 (ENGINES) (Writes the rules) 4-Apr-2017 ©2017 United Technologies Corporation

©2017 United Technologies Corporation
FAA Delegation System The FAA delegates specifically approved companies and individuals to make findings of compliance on their behalf For engineering, they are called Designated Engineering Representatives (DERs) Saves process time for applicant About 60 days for FAA to review and comment CIPT direct communication with DER saves time DER is the FAA Approvals by DER are audited by FAA Poor audit results = decreased delegation = slow approvals 4-Apr-2017 ©2017 United Technologies Corporation

FAA Certification Process is Very Structured
File FAA application for type certificate Locks in current regulation Engines have 3 years to get TC Preliminary type certification board meeting Inform the FAA of new and novel features, and how we are going to meet the FAA regulations Engine or rig testing FAA accepted analytical methods Similar to existing designs Activities Submit test plans Conformity inspections Testing Submit reports Final type certification board meeting Get type certificate (and possibly production certificate at the same time) Typically TCB is done on site at the FAA 4-Apr-2017 ©2017 United Technologies Corporation

Means of Compliance (MOC) is the FAA/Applicant “Contract”
Means of Compliance Negotiated Between FAA and Applicant Engine Validation Plan (EVP) MUST Reflect Means of Compliance Checklist Excerpt of Means of Compliance Plan (Rain and Hail Ingestion Regulation) Water and hail engine test MUST be part of engine program EVP 4-Apr-2017 ©2017 United Technologies Corporation

Several Ways to Comply with a Regulation
Via engine, rig, or bench set-up. Parts and facility to be conformity inspected and test witnessed by the FAA or delegate. TESTING Part similar to a previously certified part that was FAA tested. Must compare part environment. SIMILARITY Method must be accepted by the FAA. New part and environment must be within the boundaries of the method. ANALYSIS A statement. Example: “Each oil tank must have an expansion space not less than 10% of the tank capacity.” Documentation: sketch of oil tank and capacity. DOCUMENTATION The engine or part does not include the design feature being considered. Example: “rotor locking devices” NOT APPLICABLE 4-Apr-2017 ©2017 United Technologies Corporation

Documentation Required for FAA Regulatory Compliance
Typical Engine Certification Deliverables: ~ 70 FAA Test Plans Engine, Rig, and external components ~70 Test Reports ~30 Similarity Reports Majority are typically external components ~25 General Analytical Reports Rotor lifing, engine cooling, stress analysis, etc. ~ 5 Manuals/Catalogs ~50 Component Maintenance Manuals Total: ~ 250 Data/Analysis Packages 4-Apr-2017 ©2017 United Technologies Corporation

Foreign Regulations Must Be Part of the Certification Plan
Must Validate with Foreign Regulatory Agencies to Have Our Engines on Foreign Country Owned Airlines Some foreign authorities European Aviation Safety Agency (EASA) Civil Aviation Administration of China (CAAC) Directorate General of Civil Aviation (DGAC-Argentina) Transport Canada Civil Aviation (TCCA) Certify Type Design with the FAA Validation Type Design with Foreign Authorities Bilateral agreements (called BASAs = Bilateral Aviation Safety Agreements) between the United States and foreign authorities set the high level validation requirements Applicant to meet foreign regulations above and beyond FAA regulations EASA The applicant (like P&W) typically pays the foreign authority for validation. China 4-Apr-2017 ©2017 United Technologies Corporation

Software Considerations in Airborne Systems
Building an Engine System with Software 4-Apr-2017 ©2017 United Technologies Corporation

Process Guidance for Building an Engine System Safely
ARP 4761 Safety Assessment Methods ARP 4754A System Development Processes DO-178B/C Airborne Software Guidance DO-254 Airborne Hardware Guidance 4-Apr-2017 ©2017 United Technologies Corporation

DO-178B (Airborne Software) Aerospace Standards MIL-STD-2167A/MIL-STD-498 Joint STD-016 (civil version -498) Supersedes MIL-STD-498 IEEE 12207 Commercial SW development, acquisition, IT ISO (automotive standard) No certifying agency, litigation driven Software Engineering Institute (SEI) Capability Maturity Model (CMM) USAF Operational Software Evaluation RTCA DO-278A (aerospace ground) SAE ARP 4754A (aerospace systems) SAE ARP 4761 (aerospace system safety) 4-Apr-2017 ©2017 United Technologies Corporation

DO-178B (Airborne Software) DO-178 History 1981- DO-178 – SC145 1985- DO-178A – SC152 Software Levels 1,2,3 – Critical, Essential, Non-Essential Software Development Steps D1-D5 Software Verification Steps V1-V7 1992- DO-178B – SC167 Objectives Based Tables What, not how Criticality Categories (A,B,C,D,E) / Objectives Matrix 2012- DO-178C – SC205 4-Apr-2017 ©2017 United Technologies Corporation

DO-178B (Airborne Software) Simpler perspective of “what is DO-178B approval process?” “Contract” PSAC SAS Between applicant & FAA Accomplishment Summary Certification Plan Activities Lifecycle Data - evidence Software Plans 4-Apr-2017 ©2017 United Technologies Corporation

DO-178 is issued by RTCA, Inc.
DO-178B (Airborne Software) RTCA DO-178 is issued by RTCA, Inc. RTCA headquarters in Washington, D.C. Sponsors “Special Committees” to generate consensus-based documents including SC-167 preparing DO-178B, and SC-205 preparing DO-178C Joint committee with European Organisation for Civil Aviation Equipment (EUROCAE) Working Group (WG) 12 preparing ED-12B and WG 72 preparing ED-12C RTCA is an association of U.S. aeronautical organizations from both government and industry (EuroCAE is European equivalent) RTCA is NOT an official agency of the U.S. government The findings of RTCA are in the nature of recommendations to all organizations concerned Can software be developed safely and dependably? 4-Apr-2017 ©2017 United Technologies Corporation

But How Did DO-178B Come Into Existence?
Introduction to DO-178B (Airborne Software) Software on Planes and Engines DO-178B: “No Fatalities Attributed to Software” per NTSB But How Did DO-178B Come Into Existence?

DO-178B: “No Fatalities Attributed to Software” per NTSB
Introduction to DO-178B (Airborne Software) Software on Planes and Engines DO-178B: “No Fatalities Attributed to Software” per NTSB DO-178B provides a means of developing software for airborne systems and although other means are possible, the accident track record since DO-178B’s inception demonstrates its effectiveness. But How Did DO-178B Come Into Existence? 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) The FAA Federal Aviation Administration (FAA) United States Regulatory Organization Mission is to provide the safest, most efficient aerospace system in the world Everything revolves around aviation safety Issue TC (Type Certificates), PC (Production Certificates) ACOs (Aircraft Certification Offices) Boston, MA is P&W primary contact ACO, ECO (Engine Cert Office), Engine and Propeller Directorate FAA Headquarters in Washington DC FAA Academy, Records, etc (Oklahoma City) 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Software on Planes and Engines Federal Aviation Regulations (14 CFRs) Part 21 – Certification Procedures for Products and Parts Part 23 – Airworthiness Small Aircraft Part 25 – Airworthiness Standard Transport Aircraft Part 27/29 – Rotorcraft Normal/Transport Categories Part 33 – Airworthiness Standard Engines FAA determines/approves compliance to title 14 of the Code of Federal Regulations (informally referred to as FARs) 4-Apr-2017 ©2017 United Technologies Corporation

Safety Assessment Process Guidelines & Methods (ARP 4761)
Introduction to DO-178B (Airborne Software) What is the scope of RTCA/DO-178B? Where does DO-178B fit with other airworthiness standards Aircraft System Development Process Safety Assessment Process Guidelines & Methods (ARP 4761) Certified System Function, Failure & Safety Information Intended Aircraft Function System Design System Development Processes (ARP 4754) Functional System Hardware Development Life Cycle (DO-254) Implementation Hardware Life Cycle Process Certified System Supports System Cert Software Development Life Cycle (DO-178B) Software Life Cycle Process 4-Apr-2017 ©2017 United Technologies Corporation

SAFETY ASSESSMENT SYSTEM DEVELOPMENT
Introduction to DO-178B (Airborne Software) What is the scope of RTCA/DO-178B? Certifying a system is a multi-step process as defined by the previously mentioned documents. SAFETY ASSESSMENT SYSTEM DEVELOPMENT (Taken from ARP 4761) Aircraft Rqmts. Aircraft FHA Aircraft Functions Failure Conditions, Effects, Classification System Functions Allocation of Rqmts. To Systems System FHA Failure Conditions, Effects CCA Failure Conditions, Effects, Classification, Safety Objectives Development of System Architecture System Architecture Architecture Rqmts. PSSA Separation Rqmts. Separation Verification Items Rqmts, Analyses Required System Implementation Analysis Results SSA Items Rqmts, Safety Objectives Analyses Required Certification 4-Apr-2017 ©2017 United Technologies Corporation

SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAION
Introduction to DO-178B (Airborne Software) A Peek into the 12 chapters of DO-178B SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAION RTCA DOCUMENT NO. RTCA/DO-178B Prepared by: SC-167 December 1, 1992 “Requirements and Technical Concepts for Aviation” Chap 1 – Introduction Chap 2 – System Aspects (ARP 4754 Handoff) Chap 3 – Software Life Cycle (Not Just a Waterfall Life Cycle) Chap 4 – Software Planning Process Chap 5 – Software Development Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Quality Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations (COTS, Tool Qual, etc.) Annex A – Required Process Objectives and Outputs by SW Level Annex B – Acronyms and Glossary … DO-178B is not a large document, mainly because it is objective based. Shown is the document’s cover. 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) A Peek into the 12 chapters of DO-178B SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAION RTCA DOCUMENT NO. RTCA/DO-178B Prepared by: SC-167 December 1, 1992 “Requirements and Technical Concepts for Aviation” It is expected that the software development life cycle phases and the integral processes produce software life cycle data and output documents whose content is outlined in Chapter 11 Software Life Cycle Data (Output Documents) 4-Apr-2017 Time ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) DO-178B Annex A Tables 2 table halves: 1 – Objectives and activities reference, leveled with independence 2 – Outputs and life cycle data reference, leveled with CM rigor (CC category) 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 2 System Aspects Provides description of system interfaces necessary to understand SW life cycle processes Categorization of failure conditions, definition of SW level, and determining SW level (SSA) Catastrophic – prevent continued safe flight (Software Level A) Hazardous/Severe-Major – large reduction in aircraft/crew capability (Software Level B) Major – reduction in aircraft/crew capability (Software Level C) Minor – failure conditions not significantly reducing safety (Software Level D) No effect – (Software Level E) – DO-178B guidance does not apply System level considerations (architecture, option-selectable SW, field-loadable SW, etc) System considerations for software and system verification Software derived requirements flowed to systems 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Software Levels – Determined in SSA process and included (as proposed) in PSAC Level A Catastrophic Level B Hazardous/Severe Major Level C Major Level D Minor Level E No effect Prevention of Safe Flight or Landing Large Reduction of Safety Margin, Crew Physical Distress Reduced Aircraft or Crew Capability to Maintain Safety Margins No Significant Reduction in Aircraft Safety No Operational or Flight Crew Effect 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 3 Software Life Cycle Software life cycle process (waterfall, iterative, spiral, agile etc) “Software Process Overview” Software life cycle definition Sequence and activities of the software life cycle for a particular project Software life cycle transition criteria Transition criteria to enter or re-enter process steps Examples include: SW Verification Reviews completed; input is configured and traceability completed Every input need not be complete before initiating that process step, if transition criteria is established and satisfied 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 4 Software Planning Process Objectives and Activities of Software Planning Process Objectives and required outputs with “leveling” in Annex A Outputs defined in chapter 11 “Packaging” not prescribed PSAC and SDP define organization of output documents Outputs 11.1 to 11.8 plans and standards Plans – PSAC, SDP, SVP, SQAP, SCMP Standards – Requirements, Design, and Coding Output Verification records Output SQA results 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 5 Software Development Processes Development processes defined in the software plans (PSAC/SDP) Objectives and Activities are summarized and “leveled” in table A-2 The four software development processes are: Software Requirements Process Software Design Process Software Coding Process Integration Process Software development may include several levels of requirements Only high and low level requirements recognized per DO-178B (HLRs – trace up to system requirements, LLRs trace down to code) HLRs and LLRs may include derived requirements, must flow up to systems requirements and safety process 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) PSAC - Plan for Software Aspects of Certification PSAC - Primary Document For the FAA Used to Determine Development Rigor versus Software Level Provides Plan for Means of Compliance with Respect to Software “Promise” from applicant to FAA as to what will be done (SAS - SW Accomplishment Summary is document issued at end of project saying what was actually done) Details the Software Level As Allocated from the System & Safety Analysis Process of ARP-4754/4761 The PSAC provides the basis of the means of compliance to the FAA regulations. 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 5 Software Development Processes - 6 SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICAION RTCA DOCUMENT NO. RTCA/DO-178B Prepared by: SC-167 December 1, 1992 “Requirements and Technical Concepts for Aviation” Traceability – 2-way! or rationale…….. SYSTEMS REQUIREMENTS HIGH-LEVEL SOFTWARE REQUIREMENTS HIGH-LEVEL SOFTWARE REQUIREMENTS LOW-LEVEL REQUIREMENTS LOW-LEVEL REQUIREMENTS SOFTWARE SOURCE CODE Traceability – required for verification too! SOFTWARE TEST CASES HIGH-LEVEL SOFTWARE REQUIREMENTS SOFTWARE TEST CASES LOW-LEVEL REQUIREMENTS 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 6 Software Verification Process Software Verification Process is a technical assessment of the results of the software phases from planning to development through to verification (activities defined in the SVP 11.3) Purpose is to detect and report errors that may have been introduced in any of the development phases Objectives and Activities are summarized and “leveled” in tables A-3 to A-7 Verification is NOT just the testing process, it includes reviews and analyses too… Testing generally cannot show the absence of errors Output is the Software Verification Results (11.14) 4-Apr-2017 ©2017 United Technologies Corporation

Verification activities include:
Hmmm… how do I actually accomplish this? Introduction to DO-178B (Airborne Software) Chapter 6 Software Verification Process - 2 Verification activities include: Verifying HLRs and traceability to those HLRs Results of any traceability and/or coverage analyses should show that each software requirement is traceable to the code that implements it, and to the review, analysis, or test case that verified it For code not identical to the airborne software, provide justification for the differences For any testing not completed in a realistic software testing environment, document justification in the SVP or in SV results Deficiencies and errors found in the verification processes must be documented and reported to the development processes for clarification and correction 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 6 - A Peek into the Software Verification Process How do I satisfy these verification objectives and activities? … combo of reviews, analyses, and testing Reviews and Analyses – provide assessment of accuracy, completeness and verifiability Requirements Design/Architecture Code Integration Outputs Test Cases, Procedures and Results Testing Normal Robustness Compatibility (e.g. hardware interfaces) Test Coverage Analysis 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 6 - A Peek into the Software Verification Process - 3 Software Testing Process: 3 Types of SW reqts-based testing: HW/SW Integration Tests SW Integration Tests Low-Level Tests 2 Types of Testing Coverage Analysis (TCA=RCA+SCA): Requirements Coverage Analysis (RCA) Structural Coverage Analysis (SCA) 4-Apr-2017 ©2017 United Technologies Corporation RTCA DO-178B/C

Introduction to DO-178B (Airborne Software) Chapter 6 - A Peek into the Software Verification Process - 4 Software Testing: DO-178B/ED-12B concentrates on creating requirements-based as the primary source of testing. For each high-level & low-level requirement, a test case is generated. Some tests require HW/SW together, others only SW. Allocation of tests to low-level, SW integration, or HW/SW integration will be mostly a function of the SW design and judgement of tester. High-level requirements tests may take credit to cover some percentage of low-level requirements tests. 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 6 - A Peek into the Software Verification Process - 4 Software Testing Process: Normal test cases Equivalence classes, boundary conditions, exercise transitions, algorithms, high-cohesion and low coupling Robustness test cases Invalid equivalence class selections, abnormal conditions, out-of-range loops, exceeding execution frames, arithmetic overflows, etc Requirements-based test cases HW/SW Integration testing (example errors found: Invalid interrupt handling, stack overflow, failure of BIT test) SW Integration testing (example errors found: parameter passing error, incorrect init of variables, data corruption) Low-level testing (example errors found: incorrect logic decision, failure of SW to satisfy requirement, inadequate algorithm precision) 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 6 - A Peek into the Software Verification Process - 5 Software Testing Process - continued: Test Coverage Analysis – 2 types 1. Requirement-based (Functional) coverage analysis Test cases exist for each software requirement Test cases satisfy normal and robustness testing 2. Structural coverage analysis (statement, DC, or MC/DC) Determine which code was not exercised by requirements-based procedures Based on uncovering missing items, improve requirements and requirements-based tests Statement, Decision Coverage, or Modified Condition/Decision Coverage is performed based on software levels C, B or A… Additional verification is required for level A, if compiler inserts object code not directly traceable to source code ( b) Confirm data coupling and control coupling between components Ahhh… what did I miss??? 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 6 - A Peek into the Software Verification Process - 6 Software Testing Process - coverage: Test Coverage – 3 types Statement coverage = every statement invoked at least once Decision coverage = every point of entry/exit in the program evaluated, and evaluated for all possible outcomes of every decision MC/DC (Multiple Condition Decision Coverage) = Statement coverage plus Decision coverage plus… Each decision takes on every possible outcome at least once AND each condition in a decision takes on every possible outcome at least once AND each entry/exit point is invoked at least once AND each condition in a decision has been shown to affect the decision’s outcome independently 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 7 Software Configuration Management Process Software Configuration Management Process is perhaps the most critical process … without it absolutely no control over development Defined in the planning process and specifically by the SCM Plan Objectives: Provide defined/controlled configuration of software throughout life cycle Provide ability to consistently re-create Executable Object Code Provide control of all process inputs and outputs during SW life cycle Control configuration items (CIs) to provide known point for reviews, status, change control and to establish baselines Provide controls to ensure problems get attention and changes are processed Provide evidence of software approval by control of the SW life cycle outputs Aid the assessment of software product compliance with requirements Ensure physical archiving, recovery and control are maintained for all configuration items 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 7 Software Configuration Management Process - 3 Data Control Categories – CC1 and CC2 defined per Table 7-1 Annex A table categorizes SW life cycle data as CC1 or CC2 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 8 Software Quality Assurance Process Software Quality Assurance (SQA) Process assesses the software life cycle processes and their outputs to attain assurance that the objectives are satisfied, deficiencies detected/eval/tracked/resolved, and SW product and life cycle data conform to plans/certification requirements SQA process is defined in the plans – particularly SQAP Objectives of the SQA process are to obtain assurance that: Software development process and integral processes comply with approved plans and standards Transition criteria for software life cycle processes are satisfied Conformity review of the software product is conducted 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 9 Certification Liason Process Certification Liason Process – establish communication between the applicant and the certification authority Applicant proposes a means of compliance through the Plan for Software Aspects of Certification (PSAC) Resolve certification authority issues concerned with the PSAC Obtain agreement from the certification authority on the PSAC For compliance substantiation, resolve issues raised in reviews, submit Software Accomplishment Summary (SAS 11.20), and Software Configuration Index (SCI 11.16), and submit any other data requested by the certification authority Minimum data to be submitted to the authority: PSAC, SCI, and SAS 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 10 Overview of Aircraft and Engine Certification This Overview of Aircraft and Engine Certification is supplied for informational purposes only The authority establishes the “certification basis” for the system defining the particular regulations along with any special conditions The certification authority assesses the PSAC to determine consistency and completeness with the means of compliance that was agreed to satisfy the certification basis Prior to certification, the authority determines whether the software complies with the certification basis The authority reviews the SAS and at its discretion any life cycle data to determine that the software complies with the certification basis 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 11 Software Lifecycle Data Chapter 11 Lifecycle Data Items: PSAC – Plan for Software Aspects of Certification SDP – Software Development Plan SVP – Software Verification Plan SCMP – Software Configuration Management Plan SQAP – Software Quality Assurance Plan Software Requirements, Design, and Coding Standards SRS – Software Requirements Data SDD – Software Design Data Source Code, Executable Object Code Software Verification Cases and Procedures Software Verification Results SECI – Software Life Cycle Environment Configuration Index SCI – Software Configuration Index Problem Reports Software Configuration Management Records Software Quality Assurance Records Software Accomplishment Summary ©2017 United Technologies Corporation 4-Apr-2017

Introduction to DO-178B (Airborne Software) Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary Chapter 12 Additional Considerations Use of Previously Developed Software Assess any modifications and consider effects from different aircraft/engine installation Application/development environment changes Reverse engineering considerations SCM and SQA considerations Intention to take credit for previously developed software is stated in the PSAC 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 12 Additional Considerations – 1 Tool Qualification When processes of DO-178B are eliminated, reduced or automated by a tool without its output being verified by section 6 Software development tools – output is used as part of airborne software and therefore can introduce errors (e.g. automated code generation from LLRs) Qualification criteria – Tool Operational Reqts (TORs), to same level as airborne SW Software verification tools – cannot introduce errors, but may fail to detect them (e.g. static analyzer, tools that automate SW verification activity) Qualification criteria – Verify TORs under normal operational conditions Tool Qualification Plan (or qualifications identified in the PSAC), content Identification, Credit, Qual data produced (CC1 for D-tool, CC2 V-tool), Qual activities, Software level and architecture (D-tools only) Tool Examples: (Verification or Development Tool?) Difference Tool, reads 2 files and lists differences between them (CM support tool?) PtC Tool, takes diagram/picture based logic models and converts them to source code Support system field loader, takes Executable Object Code and installs in aircraft/engine system 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Chapter 12 Additional Considerations – 2 Alternative Methods Formal Methods – formal logic, discrete mathematics, etc (specification and verification) Exhaustive Input Testing – complete understanding of all inputs required Multiple-Version Dissimilar Software Verification – based on architecture and independence Product Service History – demonstrating equivalent safety considering factors: CM of the software Effectiveness of the PR activity Stability and maturity of the software Relevance of the product service history environment Actual error rates and product service history Impact of modifications 4-Apr-2017 ©2017 United Technologies Corporation

Annex A The Objectives of DO-178B
Introduction to DO-178B (Airborne Software) DO-178B Objectives The following lists all the objectives from DO-178B 66 objectives for Level A (plus one – b) 65 objectives for level B 57 objectives for level C 28 objectives for level D 0 for objectives level E Annex A The Objectives of DO-178B Chap 1 – Introduction Chap 2 – System Aspects Chap 3 – Software Life Cycle Chap 4 – Software Planning Process Chap 5 – Software Dev Processes Chap 6 – Software Verification Process Chap 7 – Software Configuration Management Process Chap 8 – Software Qual Assurance Process Chap 9 – Certification Liaison Process Chap 10 – Overview of Aircraft and Engine Certification Chap 11 – Software Lifecycle Data Chap 12 – Additional Considerations Annex A – Objectives / Outputs by SW Level Annex B – Acronyms and Glossary 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Annex A Table A-1 Essentially all plans must be defined and coordinated with each other and cover all these planning objectives ©2017 United Technologies Corporation 4-Apr-2017

Export Classification: No Technical Data
Introduction to DO-178B (Airborne Software) Annex A Table A-3 Verif DO-178B Speak: HLR ~ SRS reqts LLR ~ SDD reqts ============ A-1 Plan A-2 Develop… A-3 to A-7… Most Objectives are to Verify/Test Outputs! 4-Apr-2017 Export Classification: No Technical Data

Introduction to DO-178B (Airborne Software) DO-178C Supplements Supplements customize DO-178C objectives: Model-based Development and Verification (DO-331) Models represent requirements and/or software design description Can be used for development or verification Object-Oriented Technology and Related Techniques (DO-332) Collection of objects incorporate both data and behavior Formal Methods (DO-333) Technology incorporating mathematical techniques to specify, develop, or verify software aspects of systems Tool Qualification concept captured in DO-330 4-Apr-2017 ©2017 United Technologies Corporation

Introduction to DO-178B (Airborne Software) Summary of Introduction and the Annex Tables Gave an overview of the engine certification process We showed relationship of DO-178 to FAA 14CFRs and Systems Safety We provided a history of DO-178 Overviewed the structure of DO-178 Discussed Software Levels A-E Showed how to Read Annex A Tables Reviewed DO-178’s Objectives Key DO-178 software concepts that evolved over DO-178’s history ‘Leveled’ Objectives (with and without independence) Traceability – between reqts and test cases to reqts TCA (Test Cov.) = RCA (Reqts Cov.) + SCA (Struct. Cov.) Configuration Controlled Evidence (lifecycle data under CC1/2) Concepts migrating into Systems (ARP4754A) and Electronic hardware (DO-254) from DO-178B/C 4-Apr-2017 ©2017 United Technologies Corporation

History of Aerospace Software and Standards

Similar presentations

Presentation on theme: "History of Aerospace Software and Standards"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

History of Aerospace Software and Standards

Similar presentations

Presentation on theme: "History of Aerospace Software and Standards"— Presentation transcript:

Similar presentations

About project

Feedback