We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJayden Pusey
Modified about 1 year ago
1 © 2012 Atego. All Rights Reserved. DO-178C the future of Avionics Certification Martin Beeby, European Manager, Atego HighRely
2 © 2012 Atego. All Rights Reserved. RTCA DO-178: “Software Considerations in Airborne Systems and Equipment Certification” Developed by Industry and Government committees Many compromises to satisfy different goals: “Consensus”: Collective opinion or concord; general agreement or accord [Latin, from consentire, to agree] Not a recipe book or “How To” guide Guidance not prescription Lawyers versus Software Engineers; who wins? What is DO-178
3 © 2012 Atego. All Rights Reserved. DO-178: Evolution History DocYearBasisThemes DO-1781980-82498 & 2167AArtefacts, documents, traceability, testing DO-178A1985DO-178Processes, testing, components, four criticality levels, reviews, waterfall methodology DO-178B1992DO-178AIntegration, transition criteria, diverse development methods, data (not documents), tools DO-178C +Supplements. 2012DO-178BReducing subjectivity; Address MBD,OO, tools, Formal methods, etc.
4 © 2012 Atego. All Rights Reserved. Avionics Safety History: 1946 - 2008
5 © 2012 Atego. All Rights Reserved. Safety: the precursor to DO-178
6 © 2012 Atego. All Rights Reserved. Software DO-178 Hardware DO-254 System Development ARP 4754 Safety Assessment ARP 4761 Architecture Criticality Level SW Rqmts HW Rqmts Tests Safety, System, Software & Hardware
7 © 2012 Atego. All Rights Reserved. Functional Safety The Functional Safety framework surrounding DO-178 similar to: ⁻IEC 61508 – Industrial systems development ⁻ISO 26262 – Automotive systems development ⁻EN 51208 – Railway systems ⁻IEE 7-4.3.2 – Nuclear Power Systems Objective based guidance gives development freedom with compromising the use of new technology.
8 © 2012 Atego. All Rights Reserved. Why change DO-178B Almost 20 years since DO-178B released Software Development landscape has changed... Advancements in: -Tools & automation -Modelling & Simulation -Object Oriented Technology -Formal Methodologies Commercial world has embraced the above; Avionics has slowly followed Alternate Means of Compliance does not provide a consistent mechanism for certification
9 © 2012 Atego. All Rights Reserved. DO-178C Since 2005, committees have met to discuss, and update, DO-178B Like 178B, included Industry & Agencies Unlike 178B, more Tool Vendors Obvious focus on “acceptability” of certain types of tools, particularly “theirs” Predominantly America & Europe, nearly equal; quarterly meetings
10 © 2012 Atego. All Rights Reserved. DO-178C : Seven “Sub-Groups” (SG’s) SG1: Document Integration SG2: Issues & Rationale SG3: Tool Qualification SG4: Model Based Design (MBD) & Verification SG5: Object Oriented (OO) Technology SG6: Formal Methods (FM) SG7: Safety Related Considerations (and ground-based systems)
11 © 2012 Atego. All Rights Reserved. DO-178C Unlike the DO-178A to DO-178B update, the “core” update to 178C is modest Instead, changes are handled via four “Supplements”, which “clarify”: -Tools Supplement -MBD Supplement -OO Supplement -FM Supplement
12 © 2012 Atego. All Rights Reserved. Deliverables DO-178C/ED-12C Software Considerations in Airborne Systems and Equipment Certification DO-248C/ED-94C Supporting Information for DO-178C and DO-278A DO-278A/ED-109A Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems DO-330/ED-215 Software Tool Qualification Considerations DO-331/ED-216 Model-Based Development & Verification DO-332/ED-217 Object-Oriented Technology Supplement DO-333/ED-218 Formal Methods Supplement
13 © 2012 Atego. All Rights Reserved. Software Tool Qualification Considerations (D-330) Tool Qualification Considerations is a stand alone document that is consistent with and follows the structure of DO-178C It recognizes that tools occupy their own domain ⁻They are not airborne software ⁻Tool qualification can apply to hardware and ground-based systems also DO-330 is a stand-alone approach to tool qualification that could be called out by any standard ⁻Domain Specific Guidance in the calling document ⁻Tool qualification guidance from DO-330 based on crteria defined in the domain specific guidance
14 © 2012 Atego. All Rights Reserved. Same Basic Tool Qualification Principles The tool qualification is unchanged from DO-178B: ⁻The purpose of the tool qualification process is to ensure that the tool provides confidence equivalent to that of the process(es) eliminated, reduced, or automated ⁻The higher the risk of a tool error adversely affecting system safety, the higher the rigor required for tool qualification Determining if tool qualification is needed, or unchanged from DO-178B: ⁻“…when processes of this document are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified…”
15 © 2012 Atego. All Rights Reserved. DO-178C Tool Qualification Levels DO-178B Development and Verification Tools terminology is no longer used. DO-178B Definitions: ⁻Development Tools: whose output is part of airborne software and thus can introduce errors ⁻Verification Tools: that cannot introduce errors but may fail to detect them DO-178C identifies 5 Tool Qualification Levels (TQL1-5) based on 3 criteria (see next slide): ⁻For criteria 1 and 3, the basic concept and required objectives are similar to that applied under DO-178B ⁻New criterion 2 introduced to provide increased objectives for certain tool usage scenarios
16 © 2012 Atego. All Rights Reserved. Advantages of Model-Based Development (DO-331) Early animation of requirements Shared language between systems and software engineers Increased responsiveness to requirements changes Ability to use autocode and simulation as a means of verification
17 © 2012 Atego. All Rights Reserved. Model Based Development Supplement (DO-332) Provides additional guidance for Model Based Development Technology and Related Techniques The MBD Supplement provides a set of approaches that can encompass most organisations uses of MBD ⁻A Framework for using MBD is established ⁻Guidance on where certification credit for model simulation is provided ⁻Core techniques of DO-178C are maintained in MBD ⁻ Requirement Levels ⁻ Requirement Based Testing ⁻ Traceability ⁻ Structural Coverage
18 © 2012 Atego. All Rights Reserved. Object-Oriented Supplement (DO-332) Provides additional guidance for Object-Oriented Technology and Related Techniques Much of the DO-178C OOT Supplement is devoted to establishing core terminology, background and interpretation ⁻Few additional objectives or activities are identified Additional OOT objectives: ⁻Verify local type consistency ⁻Verify the use of dynamic memory management is robust
19 © 2012 Atego. All Rights Reserved. Criteria for choosing whether to use OOT Project technical criteria: ⁻Potential benefit from increased expressive power in design/code – encapsulations, class hierarchies and polymorphism ⁻Nothing new here… these were original drivers behind OOT Environmental criteria: ⁻Guidance, Human Resources, Tools ⁻In industry these are all currently available… Summary: ⁻OOT is a viable technique if the software design would benefit from its expressiveness
20 © 2012 Atego. All Rights Reserved. Formal Methods Supplement (DO-333) DO-178B allowed for consideration of formal methods as an alternate method “to improve the specification and verification of software” Included a set criteria to determine the requirements to which formal methods could be applied ⁻Safety related ⁻Definable by discrete mathematics ⁻ Involved complex behavior ⁻ Concurrency ⁻ Distributed processing ⁻ Redundancy management ⁻ Synchronization
21 © 2012 Atego. All Rights Reserved. Formal Methods Supplement The formal methods supplement applies where formal methods analysis is replacing testing evidence in the submission There is no intent to suggest that formal methods adoption is an “all in” decision ⁻Can be a selective adoption/migration for subsets of the system The supplement mimics the core DO-178 document structure Does not preclude traditional software testing even when comprehensive formal methods are applied
22 © 2012 Atego. All Rights Reserved. DO-178C Supplements Summary: Changing the Level of Abstraction There is an underlying synergy between the new DO-178C documents and supplements: ⁻Object Oriented Technology (OOT), Model Based Design and Verification (MBDV), Tools, Formal Methods All are moving in a common direction: ⁻Still enforce the objectives of DO-178C ⁻Enable systematic verification and/or increased level of abstraction ⁻Enabling more powerful development techniques to tackle the issues of increased complexity and limited resources Fundamental approach of DO-178 remains intact
23 © 2012 Atego. All Rights Reserved. DO-178C: The Future DO-178C will be mandated by EASA, FAA, and others at some time in the future. ⁻When? ⁻But it will be mandated! The model of providing Technology Supplements will be applied to future standards ⁻Maintain a core approach ⁻Enable approaches for new technologies to be added ⁻Be able to react more quickly by just adding supplements
24 © 2012 Atego. All Rights Reserved. DO-178C: The Future How will DO-178C affect systems development? How did DO-178B affect systems development? ⁻No specific life-cycle model required ⁻Say what you are going to do ⁻Do it ⁻Show the evidence you did it Analogous to ISO 9001, or CMMI Good Engineering Practice
25 © 2012 Atego. All Rights Reserved. Level 1 Level 2 Level 3 Level 4 Level 5 SEI CMMI Maturity Levels SEI CMMI’s 5 Levels: ⁻Initial ⁻Repeatable (disciplined) ⁻Defined (consistent)) ⁻Managed (predictable) ⁻Optimizing (continuous improvement) Each level is a perfect superset of the preceding level
26 © 2012 Atego. All Rights Reserved. DO-178 Quality/Cost Plans & ProcessesDetailed RqmtsFunctional TestingRobust. TestingUnit Testing Code Reviews 100 % Perfection CO$T Perfection
27 © 2012 Atego. All Rights Reserved. DO-178C: The Future By Enabling new technologies it is possible to reduce the cost of development ⁻Reduced Time of Development ⁻Ability to increase system capabilities ⁻Reduce Obsolescence Fundamental Safety approach is not compromised ⁻Functional Safety Framework remains ⁻Core approaches of DO-178 remain ⁻New technologies have to fit within this framework
1 FRENCH PROPOSAL FOR ESARR6 1 - BACKGROUND - 15/02/00 : Kick-off meeting, Presentation of the CAA/SRG input (SW01), Request from the chairman to comment.
Software Quality Assurance For Software Engineering && Architecture and Design.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
A Practitioner's Guide to DO-178B, Certification and the Emerging DO-178C Standard Shinto Joseph Operations Director, LDRA Technology Pvt. Ltd Bangalore.
Lectures 2 & 3: Software Process Models Neelam Gupta.
CLEANROOM SOFTWARE ENGINEERING. Cleanroom Software Engineering Cleanroom Software Engineering Process Lifecycle Process Lifecycle The Processes.
© 2011 Underwriters Laboratories Inc. All rights reserved. This document may not be reproduced or distributed without authorization. ASSET Safety Management.
MethodGXP The Solution for the Confusion.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
1 Process Engineering A Systems Approach to Process Improvement Jeffrey L. Dutton Jacobs Sverdrup Advanced Systems Group Engineering Performance Improvement.
SE513 Software Quality Assurance Lecture12: Software Reliability and Quality Management Standards.
Technologietag Baugruppentest ISO – Funktionale Sicherheit mit dem TestStand Toolkit Daniel Riedelbauch Marketing Manager CER, National Instruments.
Introduction to Software Engineering LECTURE 2 By Umm-e-Laila 1Compiled by: Umm-e-Laila.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
SE curriculum in CC2001 made by IEEE and ACM: Overview and Ideas for Our Work Katerina Zdravkova Institute of Informatics
Process Scoring 1Ineffective. Basics not in place. Major exposures. 2Tasks defined; Weaknesses identified; plans in place for improvement. 3Process.
Lesson 10,11 - Software Quality Assurance Overview This lesson provides an introduction for software quality assurance (SQA). SQA is the concern of every.
Software Quality Assurance. CS351 - Software Engineering (AY2004)2 Software engineering processes Systems vs. Software –Terms often used interchangeably.
Formal Methods in Software Engineering Adding Formal Methods to a Project Lecture 32 1.
1 Chapter 2 The Process. 2 Process What is it? Who does it? Why is it important? What are the steps? What is the work product? How to ensure.
2Object-Oriented Analysis and Design with the Unified Process Objectives Explain the purpose and various phases of the traditional systems development.
18 September Licensing for Next Generation Signalling Buddhadev Dutta Chowdhury 27 th April 2012.
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
Choosing a Formal Method Mike Weissert COSC 481. Outline Introduction Reasons For Choosing Formality Application Characteristics Criteria For A Successful.
by: Er. Manu Bansal Deptt of IT Software Quality Assurance.
The Software Product Life Cycle. Views of the Software Product Life Cycle Management Software engineering Engineering design Architectural design.
9/7/20151 Compiled by Arthur Alexander Reyes. Introduction to Software Quality Assurance (SQA)
Quality Concepts within CMM and PMI G.C.Reddy
SWE311_Ch02 (071) Software & Software Engineering Slide 11 Chapter 2 Process: A Generic View.
Formal Process of QA and quality related certifications Formal Process of QA and quality related certifications MIM 3 rd year – Sem V Abhishek Mishra –
CENELEC STANDARDS and its Application on Indian Railways for Signalling Alok Katiyar Dir/RDSO.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
DO178C Overview Duncan Brown - Rolls Royce Nick Tudor - QinetiQ.
Requirement Specification SRS document is a contract between the development team and the customer How do we communicate the Requirements to others? Firm.
CPA is a UKAS company Introduction to ISO New and modified requirements.
Software Quality Assurance SE Software Quality Assurance What is “quality”?
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Eng. Mohammed Timraz Electronics & Communication Engineer University of Palestine Faculty of Engineering and Urban planning Software Engineering Department.
MODEL-BASED SOFTWARE ARCHITECTURES. Models of software are used in an increasing number of projects to handle the complexity of application domains.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
ETICS2 All Hands Meeting VEGA GmbH INFSOM-RI Uwe Mueller-Wilm Palermo, Oct ETICS Service Management Framework Business Objectives and “Best.
System Integration Verification and Validation. Remember V-Cycle for all Increments? SW Requirements SW Architecture SW Design SW Coding SW Module Test.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
1 Certification Chapter 14, Storey. 2 Topics What is certification? Various forms of certification The process of system certification (the planning.
1 Security Architecture and Designs Security Architecture Description and benefits Definition of Trusted Computing Base (TCB) System level and Enterprise.
SYSE 802 John D. McGregor Module 6 Session 2 Tailoring Processes.
Software Project Management Lecture # 14. Outline Six Sigma Software Reliability Failure Measures of Reliability & Availability Software Safety Quality.
LIFE CYCLE MODELS FORMAL TRANSFORMATION DONE BY: LaRaine Satchell Carreen Walton.
™ ™ © 2006, KDM Analytics Software Assurance Ecosystem and its Applications Djenana Campara Chief Executive Officer, KDM Analytics Board Director, Object.
© 2017 SlidePlayer.com Inc. All rights reserved.