Toulouse, September 2003 Page 1 JOURNEE ALTARICA Airbus ESACS  ISAAC.

Slides:



Advertisements
Similar presentations
Integration of MBSE and Virtual Engineering for Detailed Design
Advertisements

2009 – E. Félix Security DSL Toward model-based security engineering: developing a security analysis DSML Véronique Normand, Edith Félix, Thales Research.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Unit 2. Software Lifecycle
Software Project Management
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Software Processes Coherent sets of activities for specifying, designing, implementing and testing software systems.
Project management Project manager must;
Automated creation of verification models for C-programs Yury Yusupov Saint-Petersburg State Polytechnic University The Second Spring Young Researchers.
Software Engineering 1 Evolutionary Processes Lesson 11.
R. Banach, School of Computer Science, University of Manchester, UK M. Bozzano, Fondazione Bruno Kessler, FBK-IRST, Trento, Italy 1 The Mechanical Generation.
Software Engineering COMP 201
DCS Architecture Bob Krzaczek. Key Design Requirement Distilled from the DCS Mission statement and the results of the Conceptual Design Review (June 1999):
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
1 SWE Introduction to Software Engineering Lecture 5.
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Automation for System Safety Analysis: Executive Briefing Jane T. Malin, Principal Investigator Project: Automated Tool and Method for System Safety Analysis.
Introduction to Computer Technology
Chapter 3 Software Processes.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR ESM'2009, October 26-28, 2009, Holiday Inn Leicester, Leicester, United Kingdom.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
University of Coimbra, DEI-CISUC
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
DCS Overview MCS/DCS Technical Interchange Meeting August, 2000.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Chapter 2: Software Process Omar Meqdadi SE 2730 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1 Software Processes l Coherent sets of activities for specifying, designing,
Research Heaven, West Virginia A Compositional Approach for Validation of Formal Models Bojan Cukic, Dejan Desovski West Virginia University NASA OSMA.
Lecture 3 Software Engineering Models (Cont.)
Framework for the Development and Testing of Dependable and Safety-Critical Systems IKTA 065/ Supported by the Information and Communication.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Summarizing the Content of Large Traces to Facilitate the Understanding of the Behaviour of a Software System Abdelwahab Hamou-Lhadj Timothy Lethbridge.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Model Checking and Model-Based Design Bruce H. Krogh Carnegie Mellon University.
Systems Analysis and Design in a Changing World, Fourth Edition
An Introduction to Software 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.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Lecture 13.  Failure mode: when team understands requirements but is unable to meet them.  To ensure that you are building the right system Continually.
SAFEWARE System Safety and Computers Chap18:Verification of Safety Author : Nancy G. Leveson University of Washington 1995 by Addison-Wesley Publishing.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Software Engineering, 8th edition. Chapter 4 1 Courtesy: ©Ian Sommerville 2006 FEB 13 th, 2009 Lecture # 5 Software Processes.
DEPENDABILITY ANALYSIS (towards Networked Information Systems) Ester Ciancamerla, Michele Minichino ENEA {ciancamerlae, In.
1 SYS366 Week 2 - Lecture Visual Modeling and Process.
1 Process activities. 2 Software specification Software design and implementation Software validation Software evolution.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini II. Software Life Cycle.
PRA: Validation versus Participation in Risk Analysis PRA as a Risk Informed Decision Making Tool Richard T. Banke– SAIC
Definition CASE tools are software systems that are intended to provide automated support for routine activities in the software process such as editing.
CEA LIST Expression of interest: dt-fof
Architecture Concept Documents
Round Table 2 Simulation and Interactive Visualization:
Software Processes.
Recall The Team Skills Analyzing the Problem (with 5 steps)
Chapter 2 – Software Processes
Review and comparison of the modeling approaches and risk analysis methods for complex ship system. Author: Sunil Basnet.
From Use Cases to Implementation
Presentation transcript:

Toulouse, September 2003 Page 1 JOURNEE ALTARICA Airbus ESACS  ISAAC

Toulouse, September 2003 Page 2 SYSTEM DESIGN PROCESS SAFETY PROCESS Design “View” Safety “View” Objective: to identify any potential hazard to remove the causes of the identified hazards to mitigate the effect of the hazards to maintain the hazards probability in the limits imposed by the severity class ESACS SCOPE & OBJECTIVE (REMINDER) ESACS: Enhanced Safety Assessment for Complex Systems

Toulouse, September 2003 Page 3 Applicable at different steps of system development process. Model capturing (SM or FoSaM) FM capturing Extended model (ESM) SR capturing Model analysis verification tool Safety result extraction Safety analysis tools ESACS General Methodology

Toulouse, September 2003 Page 4 Abstraction on the System Model Failure Mode Capturing Safety Requirements Capturing Safety Model Analysis –Fault Tree Generation –Sequence Generation –Model Checking Model using Safety Architecture Patterns (FoSaM) APPLICATION OF THE PRELIMINARY ESACS METHODOLOGY & TOOL-SET

Toulouse, September 2003 Page 5 Unquestionable advantages in term of formal safety modelling and interactive simulation (normal and failure behaviour) Safety assessment based on a unique view of the system improves integration of system design and safety analysis in the early phases of development Improvement of the interaction between design and Safety Engineers through a better exchange of information Both static and dynamic properties can be studied Automatic generation of FTA is a plus Moreover during cycle 2 tests, new features, required at the end of cycle 1 tests, were implemented to allow the user obtaining more useful results from the safety analyses Main advantages of ESACS approach and tools Automatic verification of the system safety requirement (use of FTA, use of safety patterns) improves the effectiveness of the validation and verification process Workload is expected to be decreased in the whole process (including modifications arising later in the system life cycle) The Design Engineers is more involved (significant points expected to be found earlier) Problems can be identified more efficiently Hazards and undesired outputs (timing aspects) are expected to be earlier identified (before simulations and test activities)

Toulouse, September 2003 Page 6 Weak points and expected improvements ESACS methodology relies on new technologies (model checkers, sequence generation). A high level of skills and training is thus required to handle them Model checker of system models using fully “real” parameters may lead to memory overflow and over computation time for complex system models Definition of a common format can be helpful for the integration of new tools, but should not be the sole answer since upgrades of new tools may lead to a loss of their interoperability with the rest of ESACS platform Interoperability between modelling tools need to be further investigated In any case it had to be said that, during cycle 2, in parallel to the activity of development of new facilities, Technology Partners done some job towards integration. Integration of ESACS safety process into a current industrial process will probably take time: –due to ESACS maturity needs for improvements –for the involved engineers to get used to this new common process At the end of cycle 2 application, the main methodological basis for an integrated and automated safety evaluation on complex systems have been built. The main improvements required by the users concern technological aspects (e.g. the optimisation of the computation algorithm and the improvement of integration among the different tools available then of the user interface)  ISAAC project

Toulouse, September 2003 Page 7 Integration of methodology into the safety process inside the industrial development process

Toulouse, September 2003 Page 8 A proposal for a new project was presented to the EC in the FP6-1st Call (March 2003) : ISAAC Improvement of Safety Activities on Aeronautical Complex systems Partners: ESACS Consortium + DASSAULT AVIATION PERSPECTIVE ON THE FUTURE WORK: FP6 “ISAAC” PROPOSAL

Toulouse, September 2003 Page 9 OBJECTIVES: CONSOLIDATION OF ESACS WORK (towards mature technology), including: High Level Representation, UML, Patterns for architecture Timing and Quantitative Analysis ESACS Platform improvement NEW THEMES, including: Human errors Common Cause analysis Mission Analysis System Diagnosability COMMONALITIES, including: Process sharing: Common Points of Methodology & Analysis Integrability: Translators and Algorithms, Libraries PERSPECTIVE ON THE FUTURE WORK: FP6 “ISAAC” PROPOSAL

Toulouse, September 2003 Page 10 DETAILED OBJECTIVES: Common Cause analysis –Interfacing: »system function/failure simulations »with geometrical/topological simulations –Improving: »The safety process: Common Mode Analysis, Zonal Safety Analysis, Particular Risk Analysis »The layout/installation process: layout requirements –Airbus experimentation: »Connecting OCAS and IRIS (topological tool) »Assessing the connection requirements with CATIA »Testing on A380 system case studies PERSPECTIVE ON THE FUTURE WORK: FP6 “ISAAC” PROPOSAL

Toulouse, September 2003 Page 11 In the frame of ISAAC, to go towards a “more mature” tool-set to be applied in the Industrial Process CONCLUSION Standard Involvement