Industrial Avionics Working Group 18/04/07 Defining the Safety Case Architecture IAWG Modular Certification.

Slides:



Advertisements
Similar presentations
Operation & Maintenance Engineering Detailed activity description
Advertisements

Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
TALOS Total ATM Life-cycle operational Solution. The Cost equation Life cycle costs are high Life cycle costs are complex Life cycle costs involve all.
Prototyping. Horizontal Prototyping Description of Horizontal Prototyping A Horizontal, or User Interface, Prototype is a model of the outer shell of.
Industrial Avionics Working Group 18/04/07 Modular Certification Basic Concepts.
Industrial Avionics Working Group 18/04/07 Propose Safety Case Architecture.
Industrial Avionics Working Group 19/04/07 Modular Certification Developing Safety Case Modules.
Software Evolution Managing the processes of software system change
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Industrial Avionics Working Group 19/04/07 The Relationship Between the Design and Safety Domains in IAWG Modular Certification What are DGRs and How are.
Industrial Avionics Working Group 18/04/07 Assessing the Safety Case Architecture Optimising the Design Architecture and Safety Case Architecture.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Industrial Avionics Working Group 13/09/06 Incremental Certification Phil Williams – General Dynamics (UK) Ltd Representing the Industrial Avionics Working.
Industrial Avionics Working Group 18/04/07 AL Partitioning (1) – Physical Domain Application Layer P 1 P 2 P 3 P n App P S 1 S 2 S 3 S n App S R 1 R 2.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
1 COSYSMO Workshop - Survey on Intuitive Judgments (Part III) COSYSMO = 1,000 PM Historical data = 1,100 PM COSYSMO = 100 PM Historical data = 110 PM.
IMS5401 Web-based Systems Development Topic 3: Development for the web 3(e) Evaluation and site maintenance.
Software evolution.
Industrial Avionics Working Group 18/04/07 Modular Certification Safety Case Contracts.
1 Introduction Introduction to database systems Database Management Systems (DBMS) Type of Databases Database Design Database Design Considerations.
Design, Implementation and Maintenance
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Marketing Research Aaker, Kumar, Day and Leone Tenth Edition Instructor’s Presentation Slides.
Chapter 9 – Software Evolution and Maintenance
Introduction to Databases Transparencies 1. ©Pearson Education 2009 Objectives Common uses of database systems. Meaning of the term database. Meaning.
MultiPARTES Towards Model-Driven Engineering for Mixed- Criticality Systems: MultiPARTES Approach A. Alonso, C. Jouvray, S. Trujillo, M.A. de Miguel, C.
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
Overview of the Database Development Process
Introduction to Software Quality Assurance (SQA)
Don Von Dollen Senior Program Manager, Data Integration & Communications Grid Interop December 4, 2012 A Utility Standards and Technology Adoption Framework.
CSI315 Web Applications and Technology Overview of Systems Development (342)
Information Systems Security Computer System Life Cycle Security.
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
System Planning- Preliminary investigation
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Software change  Managing the processes of software system change.
18 September Licensing for Next Generation Signalling Buddhadev Dutta Chowdhury 27 th April 2012.
Chapter 3: Software Maintenance Process Omar Meqdadi SE 3860 Lecture 3 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
ASSTAR User Forum #1 Rome 4th April 2006 ASAS-TN2 Second Workshop ASSTAR Safety Approach and Preliminary Issues Dr Giuseppe GRANIERO, SICTA
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
April 9, 2011 Mike Wieszchowski, P.E., PTOE Professional Traffic Operations Engineer Road Use Planning Guidelines to Protect Your Roadways.
©Ian Sommerville 2004 Software Engineering. Chapter 21Slide 1 Chapter 21 Software Evolution.
Risk Assessments: Patient Safety and Innovation Paul Tang, MD Keith Larsen, RPh.
BSBPMG504A Manage Project Costs 7.1 Estimate Costs Adapted from PMBOK 4 th Edition InitiationPlanning ExecutionClose Monitor Control The process of developing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 1.
Software Evolution Program evolution dynamics Software maintenance Complexity and Process metrics Evolution processes 1.
Industrial Controls Engineering Department Proposals for an Improved CERN PXI Support First CERN PXI Users Group meeting - 19 th October H. Reymond.
11 i Upgrade: Is an Assessment Useful for Your Company? By: Bernard Doyle, Applications Software Technology Corp. Marie Klein, Information Resources Inc.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Industrial Avionics Working Group 18/04/07 The Relationship Between the Design and Safety Domains in IAWG Modular Certification Part 2: Completeness of.
Chapter © 2015 Pearson Education, Inc. Publishing as Prentice Hall.
JD Edwards Support & Tools Gillian Boshell Product Service Advisor, Oracle Australia.
Probabilistic Risk Assessment and Conceptual Design Bryan C Fuqua – SAIC Diana DeMott – SAIC
OSCAR Optimised Expert System for Conducting Environmental Assessment of Urban Road Traffic (OSCAR) ( )
Industrial Avionics Working Group 18/04/07 Design for Safety IAWG Modular Certification.
System A system is a set of elements and relationships which are different from relationships of the set or its elements to other elements or sets.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
Copyright  2007 McGraw-Hill Pty Ltd PPTs t/a Marketing Research 2e by Lukas, Hair, Bush and Ortinau Slides prepared by Judy Rex 19-1 Chapter Nineteen.
Founded by Big Five Consulting ex-employees Oracle Gold Partner Focus on PeopleSoft 15 years of PeopleSoft experience Worked in both technical and functional.
 System Requirement Specification and System Planning.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Camera PDR/CD1 Planning 19 September 2008
Marketing Research Aaker, Kumar, Leone and Day Eleventh Edition
(Additional materials)
Chapter 9 – Software Evolution and Maintenance
05 | Making the Cloud Transition
Chapter 8 Software Evolution.
St Stephen’s Campus Assessment Phase One - Done
System Analysis and Design:
Presentation transcript:

Industrial Avionics Working Group 18/04/07 Defining the Safety Case Architecture IAWG Modular Certification

Industrial Avionics Working Group 18/04/07 Key Considerations Change Scenarios Design for Safety Proposing a Safety Case Architecture Application Layer Partitioning Assessing the Safety Case Architecture Optimisation Proposed SCA for IMS

Industrial Avionics Working Group 18/04/07 Change Scenarios IAWG Modular Certification

Industrial Avionics Working Group 18/04/07 Purpose of Analysing Change –To assess the applicability of the Modular Safety Case methodology for a specific system –To help in the analysis and optimisation when creating a Modular Safety Case for a system –To assess the Modular Safety Case for its ability to cater effectively with system updates and change –To help optimise the design of new systems to cater for change

Industrial Avionics Working Group 18/04/07 Identifying Changes Sources of change: –New and changed functional requirements (from customers, users, regulatory bodies). –Changes in operational usage. –Problem fixes (either outstanding or as yet unknown). –Obsolescence of hardware (in new build and maintenance). –Knock-on effects from other changes - Obsolescence of tools required in producing or maintaining the system, throughput upgrades to support enhancements, adoption of new procedures and standards.

Industrial Avionics Working Group 18/04/07 Gathering and Estimating Change Information Type of change: –Known (e.g. from firm customer requirements) –Predicted (e.g. compiler updates, tentative requirements) –Unknown (need to generate representative sets from statistical and historic data) System effect: –Functional (change to the way the system behaves) –Operational (change to the way in which the system is used) Relationship to safety: –New safety requirement –Changed safety requirement –Associated with safety requirements –No obvious safety relationship –Integrity levels relating to the change

Industrial Avionics Working Group 18/04/07 Preliminary Assessment of Changes The number of possible life time changes is huge with complex combinations. Categorise and and possibly reduce by considering: –Likelihood of change –Size of change –Frequency –Complexity –Their relationship to safety –Required grouping of changes This gives a set of realistic Change Scenarios for a particular system

Industrial Avionics Working Group 18/04/07 Assessment of Changes on the Safety Case The change scenarios can be “applied” to a safety case to: –Identify frequency of change to the safety case modules –Discover the impact of changes in terms of integrity and criticality issues –Compare the size of the change to the impact on the safety case –Assess the modularisation choices and the resulting isolation level of the changes applied –Assess module replacement capabilities and the adequacy of the contracts –Give a defensible basis for recommendations for improvements in either the safety case, system design, or both