1 WORKSHOP RC 2011 EVI Integração de Sistemas Junho de 2011 Eng. Nelson José Wilmers Júnior
2 Comparison between ARP4754 A Guidelines for Development of Civil Aircraft and Systems (2010) and ARP4754 Certification Considerations for Highly- Integrated or Complex Aircraft Systems (1996)
3 TABLE OF CONTENTS Introduction Why revise ARP 4754? Working group organization Revision Progress
4 Table of Contents (Cont) Major changes summary and comments Document name changed Document organization changed Section 1 - SCOPE Section 2 - REFERENCES Section 3 - DEVELOPMENT PLANNING Section 4 - AIRCRAFT AND SYSTEM DEVELOPMENT PROCESS
5 Table of Contents (Cont.) Section 5 - INTEGRAL PROCESSES Section 6 MODIFICATIONS TO AIRCRAFT OR SYSTEMS Section 7 Notes Appendix A PROCESS OBJECTIVES DATA Appendix B SAFETY PROGRAM PLAN Appendix c FDAL/IDAL PROCESS EXAMPLE
6 Introduction ARP 4754 has been in use by the Aviation industry for 15 years Guide that includes the best practices of many companies. Contains recommended practices and should not be construed to be regulatory requirements. Alternative methods to the processes described or referenced in the document may be used.
7 Why revise ARP 4754? Evolution of the industry practices since 1996 Improvement of the guideline taking into account experience on recent Aircraft Programs Improvement of the Development Assurance Level assignment process. Clarification of relationships with other guidelines (electronic hardware and software). Integration of system & software development increased. Normal SAE review and update cycle for standards. To keep the standard state of the art as required by SAE.
8 Working group organization S-18 committee Aircraft and Sys Dev and Safety Assessment Committee Chairman: Vice Chairman : Secretary: John DALTON (Boeing) Eric PETERSON Bob MATTERN (SAE) Working Group 63 Complex Aircraft Systems Chairman: Alessandro LANDI (Airbus) since October 2010 Charles ZAMORA (Airbus) until October 2010 Secretary: Mark NICHOLSON (Univ. of York)
9 Revision Progress In 2003, industry standards working groups SAE S18 and EUROCAE WG-63 begin to update the standard. Long process due to : Revision A includes more information than original document. Consensus of the committee members, member companies and regulatory agencies + harmonization between SAE/S-18 and EUROCAE/WG-63 was required.
10 Revision Progress (Cont) ED-79A Approved by EUROCAE Council (September 2010) ARP4754A Approved by SAE Council(November 2010). SAE publication of the ARP4754A (December 2010)
11 Major changes summary and comments
12 Document name changed Original name: Certification considerations for highly-integrated or complex aircraft systems New name: Guidelines for development of civil aircraft and systems Comments: Addresses development aspects; not only certification aspects. Highly-integrated or complex systems notion deleted in the title because it is ambiguous
13 Document organization changed SOME SECTIONS WERE INCLUDED, OTHER DELETED AND OTHER MERGED INCLUDED Development of aircraft systems taking into account the overall A/C operating environment and functions Integral processes : Safety Assessment, DAL assignment, Validation, Verification, Configuration Control Compliance to regulations, where applicable Context Part 25 / CS 25 NOT INCLUDED Development of A/C structure MMEL and CDL Software development (DO-178) Electronic hardware development (DO-254) Safety assessments detailed methods (ARP4761) Safety assessments in commercial service detailed methods (ARP5150)
14 Document organization changed (Cont.)
15 Section 1 - Scope The scope of the original document is to discuss the certification aspects of highly-integrated or complex systems installed on aircraft, taking into account the overall aircraft operating environmental and functions. Revision A discusses the development of aircraft systems taking into account the overall aircraft operating environment and functions.
16 Section 1 - Scope (Cont.) ARP4754A does not include specific coverage of detailed software or electronic hardware development, safety assessment processes, in-service safety activities, aircraft structural development nor does it address the development of the Master Minimum Equipment List (MMEL) or Configuration Deviation List (CDL). More detailed coverage of the software aspects of development are found in RTCA document DO-178B, Software Considerations in Airborne Systems and Equipment Certification Coverage of electronic hardware aspects of development are found in RTCA document DO-254, Design Assurance Guidance for Airborne Electronic Hardware. Design guidance and certification considerations for integrated modular avionics are found in appropriate RTCA document DO-297.
17 Section 1 - Scope (Cont) Methodologies for safety assessment processes are outlined in SAE document ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment. Details for in-service safety assessment are found in ARP5150, Safety Assessment of Transport Airplanes In Commercial Service and ARP5151 Safety Assessment of General Aviation Airplanes and Rotorcraft In Commercial Service. Post-certification activities (modification to a certificated product) are covered in section 6 of ARP4754A. The regulations and processes used to develop and approve the MMEL vary throughout the world. Guidance for the development of the MMEL should be sought from the local airworthiness authority.
18 Section 2 - References No comments
19 Section 3 DEVELOPMENT PLANNING The objectives of the development planning process are: To define the activities of the development processes and integral processes of the development life cycle that will address the aircraft/system requirements, functional development assurance level(s) and item development assurance level(s). To define the development life cycle(s), including the inter-relationships between the processes, their sequencing, feedback mechanisms, and transition criteria. To select the life cycle environment, including the methods and tools to be used for the activities of each life cycle process. To define the development standards consistent with the aircraft/system safety objectives for the aircraft/system to be produced. To develop plans that comply with objectives of each integral process (section 5).
20 Section 3 DEVELOPMENT PLANNING (Cont.) Table 1 summarizes the elements that should be included in the planning phase. They should address the design and certification of the respective aircraft, system or item.
21 Section 3 DEVELOPMENT PLANNING (Cont.) Transition Criteria A key component of planning is the establishment of life cycle process checkpoints and reviews, which are aligned with program phases and gates. The plans should clearly define maturity expectations to provide visibility on the progress and integration state for the major elements of design, implementation, and certification. This can be accomplished by clearly identifying the technical and process entrance and exit criteria. Issues left open when transitioning from one stage of development to another should be tracked and managed, as appropriate. Deviations from Plans During development there may be times when it is necessary to deviate from the documented plans. Therefore, during the planning phase it is important to identify a process to address deviatations from the plans. Methods for reporting, gaining approval of, and documenting any deviations should be described in the planning elements.
22 Section 4 AIRCRAFT AND SYSTEM DEVELOPMENT PROCESS This section provides an overview of a generic approach for developing aircraft and aircraft systems from conceptual definition to certification. This section establishes common terminology and expectations associated with development processes and their interrelationships in order to understand the intent and applicability of the substantiating material. It corresponds to ARP4754 Section 3 System Development Appendix A An Overview of a Generic Approach to Aircraft Systems Development
23 Section 4 AIRCRAFT AND SYSTEM DEVELOPMENT PROCESS (Cont.)
24 Section 4 AIRCRAFT AND SYSTEM DEVELOPMENT PROCESS (Cont.) Main topics: Conceptual Aircraft/System Development Process Aircraft Function Development Allocation of Aircraft Functions to Systems Development of System Architecture Allocation of System Requirements to Items System Implementation
25 Section 5 INTEGRAL PROCESSES This section describes fundamental process elements of the aircraft and systems overall development process. These elements are: Safety Assessment Development Assurance Level Assignment Requirements Capture Requirements Validation Inplementation Verification Configuration Management Process Assurance Certification and Regulatory Authority Coordination.
26 Section 5 INTEGRAL PROCESSES (Cont.) Safety Assessment Corresponds to ARP4754 Section 6 Safety Assessment Process The safety assessment process is used by a company to show compliance with certification requirements (e.g. 14CFR/CS Parts 23 and 25, section 1309) and in meeting its own internal safety standards. The process includes specific assessments conducted and updated during system development and includes how it interacts with the other system development processes. The primary safety assessment processes are detailed in ARP 4761
27 5.1 - Safety Assessment (Cont.) The safety assessment activities/ processes are: Functional Hazard Assessment (FHA) Preliminary Aircraft Safety Assessment / Preliminary System Safety Assessment (PASA/PSSA) Aircraft Safety Assessment / System Safety Assessment (ASA/SSA) Common Cause Analysis (CCA) Safety Program Plan
28 5.1 - Safety Assessment (Cont.) Safety Assessment Process Model CCAs Initial CCA Findings To ASA Failure Condition & Effects Functional Interactions Separation Requirements Aircraft Level FHA/ PASA Failure Condition, Effects, Classification, Safety Requirements PSSAs Item Requirements, Safety Objectives, Analyses Required 5.1.1/5.1.2 System-Level FHA Sections Failure Condition, Effects Classification, Safety Objectives Aircraft Functions System Functions Architectural, Safety Requirements Item Requirements System Architecture Aircraft Function Development Allocation of Aircraft Functions to Systems Development of System Architecture Allocation of System Requirements to Items Results From PASA ASA Results SSAs Results Separation & Verification Implementation System Implementation see Figure 4-2 System/Aircraft Level Integration & Verification Paragraph reference shown in lower right corner of process boxes. Development Complete & Ready for Certification Physical System Safety Assessment Process System Development Process
29 5.1 - Safety Assessment Main changes PASA: Preliminary Aircraft Safety Assessment ASA: Aircraft Safety Assessment The PASA/ASA assesses the A/C level FC coming from aircraft level FHA that combine several systems failures and that are not studied at system level. PASA/ASA documents are usually accomplished by the Safety organization. It allows identification of the Development Assurance Level for Aircraft Functions
30 5.1 - Safety Assessment Main changes Safety Case/ Safety Synthesis It communicates a clear, comprehensible and defensible argument that the aircraft and systems are acceptably safe to operate in a particular context. Objectives: All the safety activities have been performed according to the Safety Plan. Safety requirements for the aircraft are satisfied. Safety Validation/Verification process is completed and results accepted. All the activities undertaken from a logical argument supporting the conclusion that the aircraft is safe.
31 5.1 - Safety Assessment Main changes Safety Program Plan (SPP) It is applied at A/C level but it may also be applied at system and item level. Objectives: - Identify the input requirements at the aircraft level. - Identify applicable safety standards. - Identify the project safety organization and define responsibilities. - Describe the safety activities and deliverables. - Define the key project milestones for which reports are required. - Include the principles of the management, validation and verification. - Identify the links with the other appropriate plans. Reason - All the safety activities are summarised in this plan: identification of standards, requirements, deliverables, dates, activities and links to other plans. Appendix B - Safety Program Plan
32 5.1 - Safety Assessment Main changes Other changes that will not be addressed in this presentation referring to safety assessment activities, such as new information required, rework of the text, some information have been deleted because included in other sections or other documents
33 5.2 Development Assurance Level Assignment Corresponds to part of ARP4754 Section 5 Requirements Determination and Assignment of Development Assurance Level. Improvement of the development assurance level assignment process is one of the main features of this revision. The DAL assignment process has been completely reworked and expanded. It is the subject of a dedicated presentation.
34 5.2 Development Assurance Level Assignment (Cont.) Key topics: DAL assignment based on FC severity classification and independence attributes (not based on type of architectures) Two different DALs: FDALs that apply to function requirement development and IDALs that apply to item (Hardware/Software) development Concept of Functional Failure Sets (FFS) New Table 5-2 Development Assurance Level Assignment to Members of a Functional Failure Set with two assignment options FDAL Assignment Taking Credit for External Events
35 5.3 Requirements Capture It corresponds to part of ARP4754 Section 5 Requirements Determination and Assignment of Development Assurance Level. Additional information included: Re-use of Existing Certified Systems and Items (the requirements to which the system or Item was certified should be validated according to the new application and modified as necessary ) Deriving Safety-related Requirements from the Safety Analysis.
36 5.4 Requirements Validation It corresponds to ARP4754 Section 7 Validation of Requirements. Prominent changes: More precise definitions of Correctness and completeness. Questions in correctness and completeness have been reformulated with new questions. New ways for completeness check. Parties involved in the validation process.
37 5.4 Requirements Validation (Cont.) Correctness Old definition: absence of ambiguity or error in its attributes. New definition: Degree to which an individual requirement is unambiguous, verifiable, consistent with other requirements and necessary for the requirement set. Completeness Old definition: no attributes have been omitted and that those stated are essential. New definition: Degree to which a set of correct requirements, when met by a system, satisfy the interests of customers, users, maintainers, certification authorities as well as aircraft, system and item developers under all modes of operation and lifecycle phases for the defined operating environment. Further details about Requirements Validation process should be the subject of a dedicated presentation.
38 5.5 Implementation Verification It corresponds to ARP4754 Section 8 Implementation Verification. Prominent changes: New Activities in the verification plan. Identification of the roles and responsibilities associated with conducting the verification activities and a description of independence between design and verification activities. Identification of key verification activities and sequence of any dependent activities Identification of verification data. Further details about Implementation Verification process need to be the subject of a dedicated presentation.
39 5.6 Configuration Management It corresponds to ARP4754 Section 9 Configuration Management. Prominent changes: New Activities in the configuration management process: Configuration Management Plan. A Configuration Baseline should be Established for configuration items. Data Control Categories assigned to the data. Further details about Requirements Validation process should be the subject of a dedicated presentation.
40 5.6 Configuration Management (Cont.) CONFIGURATION MANAGEMENT PLAN Configuration Management Plan (CMP) is a Description of the configuration management environment including procedures, tools, methods, standards, organizational responsibilities and interfaces. CMP is performed to identify all the objectives and tasks to perform in the configuration management activity.
41 5.6 Configuration Management (Cont.) Configuration Baseline Establishment (CBE) A baseline should be established for configuration items to create and maintain control and traceability of configuration items. This baseline should be archived, protected and subject to change control procedures. Change control activity should be followed when developing a derivative baseline. A derivative baseline should be traceable to the previous baseline.
42 5.6 Configuration Management (Cont.) DATA CONTROL CATEGORIES Appendix A contains Data Control category assigned to each output depending on the DAL assigned. This table should be consulted to agree with configuration management.
43 5.7 Process Assurance It corresponds to ARP4754 Section 10 Process Assurance. This section describes the activities that ensure that the development assurance activities are maintained and followed. Prominent changes: Process assurance should have a level of independence from the development process.
44 5.8 Certification and Regulatory Coordination It corresponds to ARP4754 Section 4 Certification Process and Coordination. The objective of the certification process is to substantiate that the aircraft and its systems comply with applicable requirements. Prominent changes: No prominent changes.
45 Section 6 MODIFICATIONS TO AIRCRAFT OR SYSTEMS It corresponds to ARP4754 Section 11 Modified Aircraft. The objective of this section is to describe how the material in the document could be applied when modifying an item, system or aircraft.
46 Section 6 MODIFICATIONS TO AIRCRAFT OR SYSTEMS (Cont.) Prominent changes: The modification process has been reworked and expanded. Relevant topics: Modification management process Modification impact analysis
47 Section 6 MODIFICATIONS TO AIRCRAFT OR SYSTEMS (Cont.) Modification Management Process Objectives It provides a structured means to control and coordinate activities between stakeholders. It is necessary to manage and control all the process described. Content 1. Description of the proposed modifications to items, systems or the aircraft. 2. Results of an initial modification impact analysis. 3. The proposed modification implementation strategy. 4. Implementation and integration of the modification using a systematic implementation strategy. 5. Results of verification activities on the implemented modification. 6. Results of the final modification impact analysis.
48 Section 6 MODIFICATIONS TO AIRCRAFT OR SYSTEMS (Cont.) Modification Impact Analysis (MIA) MIA evaluates the impact of the modification on the original safety assessments. This impact analyses provides a document that describes all the changes that the modification causes and the procedures and measures to take. Changes related with safety and operational or procedural characteristics should be verified. A confirmatory modification impact analysis should be undertaken once verification activities have been completed: it is an iterative process.
49 APPENDIX A PROCESS OBJECTIVES DATA This appendix outlines the aircraft/system life cycle process objectives and data outputs described in this document. Table A-1 provides the details by function development assurance level, which should be assigned according to the guidelines in section 5.2.
50 APPENDIX A PROCESS OBJECTIVES DATA (Cont.)
51 Appendix B SAFETY PROGRAM PLAN The Safety Program Plan should define the scope and the content of the safety activities that are applicable at the aircraft level. The concepts of a safety plan may also be applied at system level, if so desired. The following provides an overview on topics that might be covered through the Safety Program Plan: Identify the input requirements at the aircraft level for which safety design and analysis responsibility is being taken, Identify applicable safety standards, Identify the project safety organization and define responsibilities within this organization and its relationship with partners and/or suppliers with respect to the safety process, Describe the safety activities and deliverables, Define the key project milestones for which reports are required, Include the principles of the management, validation of the safety requirements and the verification that the design meets those requirements, Identify the links with the other appropriate plans (e.g. certification plan, validation and verification plan, process assurance plan).
52 APPENDIX C FDAL/IDAL ASSIGNMENT PROCESS EXAMPLE This appendix gives a step by step process description for assigning Development assurance levels to functions, (FDAL) and to items (IDAL) with architectural considerations. Development Assurance Level Assignment is addressed in a dedicated presentation.
U.S. Department of Transportation Federal Aviation Administration Advisory Circular Subject: Airborne Software Assurance Date: mm/dd/yyyy Initiated by: AIR-120 AC : 20-115C Change: 1. Purpose of this Advisory
asuresign Aero (NATEP Grant MA005) WP2 Workshop: Identification of Needs for Tool Support in Meeting Aircraft Avionics Systems, Hardware & Software Certification Standards Dr Chris Harper Systems & Safety
U.S. Department of Transportation Federal Aviation Administration Advisory Circular Subject: Airborne Software Assurance Date: 07/19/2013 AC No: 20-115C Initiated by: AIR-120 Change: 1. Purpose of this
EASA NOTIFICATION OF A PROPOSAL TO ISSUE A CERTIFICATION MEMORANDUM EASA Proposed CM No.: EASA CM - SWAEH 002 Issue: 02 Issue Date: 22 nd of October 2013 Issued by: Safety, Software & Airborne Electronic
Parameters for Efficient Software Certification Roland Wolfig, firstname.lastname@example.org Vienna University of Technology, Real-Time Systems Group 1 Abstract Software certification is a common approach
Cognizant 20-20 Insights The Impact of RTCA DO-178C on Software Development By following DO-178C, organizations can implement aeronautical software with clear and consistent ties to existing systems and
SAFE SOFTWARE FOR SPACE APPLICATIONS: BUILDING ON THE DO-178 EXPERIENCE Cheryl A. Dorsey Digital Flight / Solutions email@example.com DIGITAL FLIGHT / SOLUTIONS Presentation Outline DO-178 Overview
12AEAS-0090 Complying with DO-178C and DO-331 using Model-Based Design Bill Potter MathWorks, Inc. Copyright 2012 The MathWorks, Inc. ABSTRACT This paper addresses how recently published revisions of aircraft
AC 20-148 REUSABLE SOFTWARE COMPONENTS December 7, 2004 12/7/04 AC 20-148 CONTENTS Paragraph Title Page 1. Purpose....1 2. Motivation for this Guidance....1 3. Document Overview...1 4. General Guidelines
Safety Analysis and Certification of Open Distributed Systems P. M. Conmy; Department of Computer Science, University of York, York, YO10 5DD U.K. M. Nicholson; Department of Computer Science, University
Meeting DO-178B Software Verification Guidelines with Coverity Integrity Center May, 2009 Thomas Schultz Director of Product Strategy, Coverity, Inc. Executive Summary Development organizations that create
Aircraft Systems Integration from EMBRAER Perspective João Paulo Marques Reginato Systems Integration Manager 31/August/2015 Main Topics - Introduction - Systems Integration evolution on EMBRAER programs
61508-3 ª IEC: 1997 1 Version 12.0 05/12/97 COMMISSION CEI ELECTROTECHNIQUE IEC INTERNATIONALE 61508-3 INTERNATIONAL ELECTROTECHNICAL COMMISSION Functional safety of electrical/electronic/ programmable
Template Applicable to: Transport Projects Quality Management System Status: Division: Approved Transport Projects Version: 5.0 Desksite No.: 3455797_1 Date of issue: 1 July 2014 Effective date: 1 July
1. Overview 1. Overview...1 1.1 Total programme structure...1 1.2 Topics covered in module...2 1.3 Examples of SW eng. practice in some industrial sectors...4 1.3.1 European Space Agency (ESA), software
J. Software Engineering & Applications, 2010, 3, 894-900 doi:10.4236/jsea.2010.39105 Published Online September 2010 (http://www.scirp.org/journal/jsea) Introduction to a Requirements Engineering Framework
Implementation of ANSI/AAMI/IEC 62304 Medical Device Software Lifecycle Processes.. www.pharmout.net Page 1 of 15 Version-02 1. Scope 1.1. Purpose This paper reviews the implementation of the ANSI/AAMI/IEC
1 THE ROLE OF IV&V IN THE SOFTWARE DEVELOPMENT LIFE CYCLE by: The IV&V Group for: ASQ Section 509 Section 509 - NOV 2007 2 2 INTRODUCTION Overview Phase-Related IV&V Activities IV&V Implementation Summary
DO-254 Requirements Traceability Louie De Luna, Aldec - June 04, 2013 DO-254 enforces a strict requirements-driven process for the development of commercial airborne electronic hardware. For DO-254, requirements
PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name
Software Quality Assurance: VI Standards Room E 3.165 Tel. 60-3321 Email: firstname.lastname@example.org Outline I Introduction II Software Life Cycle III Quality Control IV Infrastructure V Management VI Standards VII Conclusion
Certification Authorities Software Team (CAST) Position Paper CAST-15 Merging High-Level and Low-Level Requirements Completed February 2003 NOTE: This position paper has been coordinated among the software
27 RTCA DO-178B/EUROCAE ED-12B Thomas K. Ferrell Ferrell and Associates Consulting Uma D. Ferrell Ferrell and Associates Consulting 27.1 Introduction Comparison with Other Software Standards Document Overview
Integrating System Safety and Software Assurance Systems Certification and Integrity Directorate of Aviation Engineering Directorate General Technical Airworthiness 1 Overview Integration of software assurance
National Aeronautics and Space Administration Unmanned Aircraft Systems (UAS) Integration in the National Airspace System (NAS) Project Presented by: Mr. John Walker on behalf of Mr. Chuck Johnson Manager,
The evolving ARINC 653 standard and it s application to IMA Alex Wilson Senior Program Manager Wind River November 13 th 2007 IMA and ARINC 653 Agenda DO-297 Certification of IMA under DO-297 Conclusions
The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor
Service Support Configuration Management ITIL Configuration Management - 1 Goals of Configuration Management The goals of Configuration Management are to: Account for all the IT assets and configurations
IMPLEMENTATION OF A SOFTWARE PROJECT OFFICE AT HONEYWELL AIR TRANSPORT SYSTEMS by Michael A. Ross Abstract. This paper justifies, defines and describes an organization-level software project management
September 25, 2014 EFFECTIVE METHODS FOR SOFTWARE AND SYSTEMS INTEGRATION P R E S E N T E D B Y: D R. B O Y D L. S U M M E R S 1 Software Engineer (Quality) Defense and Space The Boeing Company - Seattle,
Qualtech Consulting Inc. Who We Are Founded in 1996 Based in Lakewood Ranch, Florida Todd R. White, President Solution Provider Airborne Software Certification Airborne Software Certification Ground-Based
SCADE SUITE SOFTWARE VERIFICATION PLAN FOR DO-78B LEVEL A & B TABLE OF CONTENTS. INTRODUCTION..... PURPOSE..... RELATED DOCUMENTS..... GLOSSARY... 9.. CONVENTIONS..... RELATION WITH OTHER PLANS....6. MODIFICATION
(STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This
U.S. Department of Energy Washington, D.C. NOTICE DOE N 203.1 Approved: Expires: 06-02-01 SUBJECT: SOFTWARE QUALITY ASSURANCE 1. OBJECTIVES. To define requirements and responsibilities for software quality
DOT/FAA/AR-01/116 Office of Aviation Research Washington, D.C. 20591 Software Service History Handbook January 2002 Final Report This document is available to the U.S. public through the National Technical
CAUSAL ANALYSIS AND RESOLUTION SUPPORT (ML5) The purpose of Causal Analysis and Resolution (CAR) is to identify causes of selected outcomes and take action to improve process performance. SG 1 Root causes
I-680 SMART CARPOOL LANE PROJECT SYSTEM ENGINEERING MANAGEMENT PLAN CONFIGURATION MANAGEMENT PLAN GUIDELINE SECTIONS: PLAN GUIDELINES 1. GENERAL 2. ROLES AND RESPONSIBILITIES 3. CONFIGURATION MANAGEMENT
Safety Critical Software Management Practices Linda Westfall Westfall Team, Inc. International Conference on Software Quality ICSQ 2011 Copyright 1999-2010 Westfall Team, Inc. All Rights Reserved. Management
Westinghouse Non-Proprietary Class 3 Advanced Logic System 6002-00002-NP, Rev. 10 Function Author Nuclear Safety Related July 2014 APPROVALS Name and Signature Anthony C. Pagano* Integrated Process Lead,
General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 This document supersedes the draft document, "General Principles of Software Validation,
UNCONTROLLED IF PRINTED AAP 7001.054 Sect 2 Chap 17 SECTION 2 CHAPTER 17 IN-SERVICE MANAGEMENT OF SOFTWARE FOR AIRBORNE AND RELATED SYSTEMS INTRODUCTION 1. The in-service maintenance and development of
Department of Health and Human Services Centers for Medicare & Medicaid Services Office of Information Services CMS Framework Overview Version 1.1 May 18, 2011 Table of Contents 1. Introduction... 1 1.1
DOWNLOADED AND/OR HARD COPY UNCONTROLLED Verify that this is the correct version before use. AUTHORITY DATE Jeffrey Northey (original signature on file) IMS Manager 07/09/2014 Doug Dorrer (original signature
Audit Checklist The following provides a detailed checklist to assist the audit team in reviewing the health of a project. Relevance (at this time) How relevant is this attribute to this project or audit?
Software Engineering for Outsourced & Offshore Development CMMI: Specific Goals and Practices PeterKolb Software Engineering CMMI Process Areas for R&D Projects Slide 2 Content Management in Projects Project
NOT FAA POLICY OR GUIDANCE LIMITED RELEASE DOCUMENT 04 SEPTEMBER 2013 DOT/FAA/AR-xx/xx Federal Aviation Administration William J. Hughes Technical Center Aviation Research Division Atlantic City International
Appendix H Software Development Plan Template Version 2 March 7, 2005 This page is intentionally left blank. Version 2 March 7, 2005 Title Page Document Control Panel Table of Contents List of Acronyms
TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release
Efficient Development of Safe Avionics Software with DO-178B Objectives Using SCADE Suite CONTACTS Legal Contact Esterel Technologies SA Parc Euclide - 8, rue Blaise Pascal 78990 Elancourt FRANCE Phone:
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
IBM Software Rational Aerospace and Defense DO-178B compliance: turn an overhead expense into a competitive advantage 2 DO-178B compliance: turn an overhead expense into a competitive advantage Contents
Leveraging CMMI framework for Engineering Services Regu Ayyaswamy, Mala Murugappan Tata Consultancy Services Ltd. Introduction In response to Global market demand, several OEMs adopt Global Engineering
Example Software Development Process. The example software development process is shown in Figure A. The boxes represent the software development process kernels. The Software Unit Testing, Software Component
Certified Professional in Configuration Management Glossary of terms used in Configuration Management Issue 2007.07 Association of the International Certified Configuration Manager e.v. Copyright 2007,
Merging Safety and Assurance: The Process of Dual Certification for Software Carol Taylor, Jim Alves-Foss, and Bob Rinker Center for Secure and Dependable Systems University of Idaho Track 5 250-B High
Functional Safety Management: As Easy As (SIL) 1, 2, 3 Abstract This paper outlines the need for planning in functional safety management. Recent events such as the Montara blowout and the Deepwater Horizon
2 of 34 Revision Summary Revision Number Date Description of Revisions Initial issue of the document. Table of Contents Item Description Page 1. Introduction and Purpose... 5 2. Project Management Approach...
Intland s Medical Template Traceability Browser Risk Management & FMEA Medical Wiki Supports compliance with IEC 62304, FDA Title 21 CFR Part 11, ISO 14971, IEC 60601 and more INTLAND codebeamer ALM is
Effective Date: 03/08/2011 Page: 1 of 17 Quality Management System Manual Thomas C. West Eric Weagle Stephen Oliver President ISO Management General Manager Representative Effective Date: 03/08/2011 Page:
Department of Health and Human Services Centers for Medicare & Medicaid Services Center for Consumer Information and Insurance Oversight Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews
3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification
DEPARTMENT OF THE AIR FORCE HEADQUARTERS AERONAUTICAL SYSTEMS CENTER (AFMC) WRIGHT-PATTERSON AIR FORCE BASE OHIO BULLETIN AWB 002A 17 May 2011 ((supersedes AWB-002) United States Air Force (USAF) Airworthiness
ISO 9001:2008 QUALITY MANUAL Revision B Because we want you to achieve the highest levels of performance, we connect care Because with leading we want science you to achieve continuously the highest improve,
Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role
& CMMI July, 2007 Why the drive for CMMI? Missed commitments Spiralling costs Late delivery to the market Last minute crunches Inadequate management visibility Too many surprises Quality problems Customer
The online version of this document is controlled. Therefore, all printed versions of this document are unofficial copies. QUALITY MANAGEMENT SYSTEM MANUAL 6901 Charles Street Towson, Maryland 21204 Manual
ARINC IA Project Initiation/Modification (APIM) Name of proposed project APIM #: 05-004 Supplement to ARINC Report 666: Electronic Distribution of Software Suggested Subcommittee assignment Future Concepts
Department of the Interior U.S. Geological Survey USGS EOS SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP) September 2013 Executive Summary This Systems Engineering Management Plan (SEMP) outlines the engineering
PURCHASE ORDER ATTACHMENT Q-201A Software Quality Subcontractor Survey Questionnaire INSTRUCTIONS FOR PURCHASE ORDER ATTACHMENT Q-201 1. A qualified employee shall be selected by the Software Quality Manager
ASSESSMENT OF THE ISO 26262 STANDARD, ROAD VEHICLES FUNCTIONAL SAFETY Dr. Qi Van Eikema Hommes SAE 2012 Government/Industry Meeting January 25, 2012 1 Outline ISO 26262 Overview Scope of the Assessment
WHITEPAPER DO-178C/ED-12C The new software standard for the avionic industry: goals, changes and challenges SVEN NORDHOFF Aerospace Certification / Process Assurance & SPICE Assessor email@example.com
Software Change Impact Analysis An Interactive Video Teletraining Course IVT Course 62823 Self-Study Video Course 25823 Developed and Presented by Leanna Rierson FAA, National Resource Specialist For Aircraft
Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP174 Table of Contents INTRODUCTION... 1 LEVEL-2, REPEATABLE... 3 Requirements Management... 3 Software Project
AS 9100 Rev C Quality Management System Manual B&A Engineering Systems, Inc. 3554 Business Park Drive, Suite A-1 Costa Mesa, CA 92626 Doc. No. AS9100C Rev E Effective Date: 01 JAN 2013 Page 2 of 45 CONTROLLED