DOCSLIB.ORG

Integration Between Requirements Engineering and Safety Analysis: a Systematic Literature Review

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

The Journal of Systems and Software 125 (2017) 68–92 Contents lists available at ScienceDirect The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss Integration between requirements engineering and safety analysis: A systematic literature review ∗ Jéssyka Vilela a, , Jaelson Castro a, Luiz Eduardo G. Martins b, Tony Gorschek c a Centro de Informática, Universidade Federal de Pernambuco, Recife-PE, Brazil b Departamento de Ciência e Tecnologia, Universidade Federal de São Paulo, São José dos Campos, Brazil c Blekinge Institute of Technology (BTH), Sweden a r t i c l e i n f o a b s t r a c t Article history: Context: Safety-Critical Systems (SCS) require more sophisticated requirements engineering (RE) ap- Received 27 June 2016 proaches as inadequate, incomplete or misunderstood requirements have been recognized as a major Revised 18 October 2016 cause in many accidents and safety-related catastrophes. Objective: In order to cope with the complexity Accepted 21 November 2016 of specifying SCS by RE, we investigate the approaches proposed to improve the communication or inte- Available online 22 November 2016 gration between RE and safety engineering in SCS development. We analyze the activities that should be Keywords: performed by RE during safety analysis, the hazard/safety techniques it could use, the relationships be- Safety-critical systems tween safety information that it should specify, the tools to support safety analysis as well as integration Requirements engineering benefits between these areas. Method: We use a Systematic Literature Review (SLR) as the basis for our Safety analysis work. Results: We developed four taxonomies to help RE during specification of SCS that classify: tech- Integration niques used in (1) hazard analysis; (2) safety analysis; (3) safety-related information and (4) a detailed Communication set of information regarding hazards specification. Conclusions: This paper is a step towards developing Systematic literature review a body of knowledge in safety concerns necessary to RE in the specification of SCS that is derived from a large-scale SLR. We believe the results will benefit both researchers and practitioners. ©2016 Elsevier Inc. All rights reserved. 1. Introduction ( Leveson, 2011; Wilikens et al., 1997 ). The system requirements definition corresponds to the activity that focus on what the Safety-critical systems are those systems composed by a set system should do and it may contain elements of design ( Ivarsson of hardware, software, process, data and people ( Du et al., 2014 ) and Gorschek, 2011 ). It is most efficient to consider safety con- whose failure could result in accidents that cause damage to the cerns as early as possible during software development in order to environment, financial losses, injury to people and even the loss of ensure that safety problems do not propagate through subsequent lives ( Leveson, 2011; Hatcliff et al., 2014 ). phases of development ( Saeed et al., 1995; Wilikens et al., 1997 ). The use of software in SCS, in particular in control systems, According to Leveson (2011) , separating safety engineering from has increased to such an extent that failures in the software can the RE process is almost guaranteed to make the effort and re- impair system safety ( Saeed et al., 1995 ). Investigations into the sources expended a poor investment and possibly the development causes of accidents indicate that more rigor is required in set- of a system that is not safe ( Leveson, 2011 ). Safety engineering is ting the requirements and specification of safety-related systems effective when it participates in and provides input to the RE pro- ( Simpson and Stoker, 2002 ) since inadequate or misunderstood re- cess and to the system design, not when it focuses on making ar- quirements ( Ratan et al., 1996 ) have been recognized as the ma- guments about the artifacts created after the major safety-related jor cause (not coding or implementation Guillerm et al., 2010 ) of a decisions have been made. significant proportion of accidents ( Simpson and Stoker, 2002 ) and In the context of SCS development, a tighter integration of safety-related catastrophes ( Leveson, 2002 ). safety engineering concerns into the RE process is desired by Therefore, safety cannot be assured without its al- academia and industry ( Leveson, 2011; Lutz, 20 0 0; Martins and ready being part of the RE process and the system design Gorschek, 2016; Heimdahl, 2007; Sikora et al., 2012; Hatcliff et al., 2014 ). A systematic integration of safety engineering ( Navarro et al., 2006; El Ariss et al., 2011 ) with the requirements engineer- ∗ Corresponding author. ing and a common nomenclature ( Zoughbi et al., 2011 ) are re- E-mail addresses: [email protected] (J. Vilela), [email protected] (J. Castro), quired in order to satisfy system correctness and safety require- [email protected] (L.E.G. Martins), [email protected] (T. Gorschek). http://dx.doi.org/10.1016/j.jss.2016.11.031 0164-1212/© 2016 Elsevier Inc. All rights reserved. J. Vilela et al. / The Journal of Systems and Software 125 (2017) 68–92 69 ments ( Thramboulidis and Scholz, 2010 ) as well as to provide a 2.1. Related work framework for effective cooperation between experts ( Scholz and Thramboulidis, 2013; Zoughbi et al., 2011 ). Catastrophic accidents continue to occur despite advances Catastrophic safety incidents continue to occur despite ad- in the understanding of the underlying causes over the years vances in the understanding of the underlying causes over the ( Mannan et al., 2015 ). This may constitute an evidence that the years ( Mannan et al., 2015 ). Hence, in order to cope with the com- traditional development process of SCS must be changed in or- plexity of performing hazard/safety analysis and specifying SCS, we der to consider the safety concerns early in the RE process. There- are investigating, through a SLR, the approaches proposed to im- fore, the system safety analysis is the first phase to identify soft- prove the requirements communication and integration between ware safety requirements necessary to support the development of RE and Safety Engineering in the development of SCS. the software requirements specification ( Medikonda and Panchu- In this paper, we analyze the activities that should be per- marthy, 2009 ). formed by requirements engineering during safety analysis, the In this context, the integration between RE and safety engineer- hazard/safety techniques they could use, the relationships between ing is well desired by academia and industry. We noticed a ten- safety information that they should specify, the tools that can be dency in RE and safety research in trying to join these two areas used to support safety analysis as well as the benefits of the inte- by different research lines. gration between RE and safety engineering. From the point of view of RE, the model-driven paradigm has The results of this paper are a step towards developing a body been used to some works to reduce the gap between these two of knowledge in safety concerns necessary to be handled to re- areas by the use of shared models that includes safety character- quirements engineers in the specification of SCS that were derived istics ( Leveson, 2002; Murali et al., 2015 ) or system engineering from a large-scale rigorous literature review. As part of our work, best practices ( Guillerm et al., 2010 ). In this context, UML ( Beckers we developed four taxonomies to help the requirements engineers et al., 2013; Briones et al., 2007; Zoughbi et al., 2011 ) or SysML in the specification of SCS that classify (1) the techniques used in ( Scholz and Thramboulidis, 2013; Biggs et al., 2016 ) profiles have the hazard analysis; (2) the techniques used in the safety analysis; been proposed. (3) the safety-related information and (4) a detailed set of infor- From the safety engineering, safety analysis tools ( Ratan et al., mation regarding the specification of hazards. 1996 ), methodologies ( Kelly and Weaver, 2004 ) and metamod- This paper is organized as follows. Section 2 presents back- els ( OMG, 2016; Panesar-Walawege et al., 2010; de la Vara and ground and related work. The research methodology adopted to Panesar-Walawege, 2013; de la Vara et al., 2016 ) for the con- conduct the SLR is presented in Section 3 . The results and the anal- struction of assurance safety cases have been developed. However, ysis related to our research questions are presented in Section 4 . many of these studies are partially or not compliant with safety Our conclusions are presented in Section 5 . standards and it is unclear whether these approaches can cope with the complexity of the large-scale development of software- 2. Background and related work intensive systems, taking inter-departmental and multi-disciplinary aspects into account ( Pernstål et al., 2015 ). Hence, further research Safety-critical systems are those systems whose failure could is necessary to investigate the extent that these approaches inte- result in harm (generally meaning injury or death) ( Hatcliff et al., grate these engineers as well as their compliance with safety stan- 2014 ). Loss may involve human death and injury, but it may also dards. involve other major losses, including mission, equipment, financial, Another research line in the safety area is improving the con- and information losses ( Leveson, 2011 ). struction of assurance safety cases. They should communicate a During the development of SCS, safety engineers typically re- clear, comprehensive and defensible
Recommended publications
  • Hearing Loss Prevention and a Survey of Firefighters

    Hearing Loss Prevention and a Survey of Firefighters

    Update 2017 Vol. 29, Issue 1 The Council for Accreditation in Occupational Hearing Conservation Hearing Loss Prevention and a Survey of Firefighters Submitted by: Natalie Rothbauer, Illinois State University According to the Occupational and Safety Administration (OSHA), Candidates with the following medical conditions shall not be certified as approximately 30 million people are exposed to hazardous noise annually, meeting the medical requirements of this standard: (1) Chronic vertigo which places them at risk for auditory injuries such as noise-induced or impaired balance as demonstrated by the inability to tandem gait hearing loss (NIHL) and tinnitus. Noise-induced hearing loss can be walk. (2) On audiometric testing, average hearing loss in the unaided costly to workers as it can interfere with their daily tasks. It may make it better ear greater than 40 decibels (dB) at 500 Hz, 1000 Hz, and 2000 impossible to hear important warning signals and other important sounds, Hz when the audiometric device is calibrated to ANSI Z24.5. (3) Any possibly resulting in a worker being relieved from duty. Firefighting is ear condition (or hearing impairment) that results in a person not being considered a hearing critical profession because warning signal audibility able to safely perform essential job tasks. - NFPA Standard 1582 (pp. 11) could be the difference between life and death (Hong et al, 2013). Knowledge A literature review did not reveal a consistent sound exposure profile for Survey data indicated that many firefighters were knowledgeable of some career firefighters due to the variable noises and length of work shift. Some of the aspects of hearing loss and approaches to prevention.
  • White Paper on Approaches to Safety Engineering∗

    White Paper on Approaches to Safety Engineering∗

    White Paper on Approaches to Safety Engineering∗ Nancy Leveson April 23, 2003 A life without adventure is likely to be unsatisfying, but a life in which adventure is allowed to take whatever form it will, is likely to be short. — Bertrand Russell This white paper lays out some foundational information about different approaches to safety: how various industries differ in their approaches to safety engineering, and a comparison of three general approaches to safety (system safety, industrial safety engineering, and reliability engineer- ing).An attempt is made to lay out the properties of industries and systems that make one approach more appropriate than another. How do industries differ in their approaches to safety engineering? While the concern about industrial safety dates back to at least the turn of the century (and before in some countries and industries) and individual efforts to design safe products and systems also goes back in time, rigorous and defined approaches to safety engineering mostly arose after World War II, when the AEC (and later the NRC) were engaged in a public debate about the safety of nuclear power; civil aviation was trying to convince a skeptical public to fly; the chemical indus- try was coping with larger plants, increasingly lethal chemicals, and heightened societal concern about pollution; and the DoD was developing ballistic missile systems and increasingly dangerous weapons.Each of these parallel efforts resulted in very different engineering approaches, mostly because the problems they needed to solve were different. Commercial Aircraft The [FAA] administrator was interviewed for a documentary film on the [Paris DC-10] accident.
  • System Safety Engineering: Back to the Future

    System Safety Engineering: Back to the Future

    System Safety Engineering: Back To The Future Nancy G. Leveson Aeronautics and Astronautics Massachusetts Institute of Technology c Copyright by the author June 2002. All rights reserved. Copying without fee is permitted provided that the copies are not made or distributed for direct commercial advantage and provided that credit to the source is given. Abstracting with credit is permitted. i We pretend that technology, our technology, is something of a life force, a will, and a thrust of its own, on which we can blame all, with which we can explain all, and in the end by means of which we can excuse ourselves. — T. Cuyler Young ManinNature DEDICATION: To all the great engineers who taught me system safety engineering, particularly Grady Lee who believed in me, and to C.O. Miller who started us all down this path. Also to Jens Rasmussen, whose pioneering work in Europe on applying systems thinking to engineering for safety, in parallel with the system safety movement in the United States, started a revolution. ACKNOWLEDGEMENT: The research that resulted in this book was partially supported by research grants from the NSF ITR program, the NASA Ames Design For Safety (Engineering for Complex Systems) program, the NASA Human-Centered Computing, and the NASA Langley System Archi- tecture Program (Dave Eckhart). program. Preface I began my adventure in system safety after completing graduate studies in computer science and joining the faculty of a computer science department. In the first week at my new job, I received a call from Marion Moon, a system safety engineer at what was then Ground Systems Division of Hughes Aircraft Company.
  • Manuscript Instructions/Template

    Manuscript Instructions/Template

    INCOSE Working Group Addresses System and Software Interfaces Sarah Sheard, Ph.D. Rita Creel CMU Software Engineering Institute CMU Software Engineering Institute (412) 268-7612 (703) 247-1378 [email protected] [email protected] John Cadigan Joseph Marvin Prime Solutions Group, Inc. Prime Solutions Group, Inc. (623) 853-0829 (623) 853-0829 [email protected] [email protected] Leung Chim Michael E. Pafford Defence Science & Technology Group Johns Hopkins University +61 (0) 8 7389 7908 (301) 935-5280 [email protected] [email protected] Copyright © 2018 by the authors. Published and used by INCOSE with permission. Abstract. In the 21st century, when any sophisticated system has significant software content, it is increasingly critical to articulate and improve the interface between systems engineering and software engineering, i.e., the relationships between systems and software engineering technical and management processes, products, tools, and outcomes. Although systems engineers and software engineers perform similar activities and use similar processes, their primary responsibilities and concerns differ. Systems engineers focus on the global aspects of a system. Their responsibilities span the lifecycle and involve ensuring the various elements of a system—e.g., hardware, software, firmware, engineering environments, and operational environments—work together to deliver capability. Software engineers also have responsibilities that span the lifecycle, but their focus is on activities to ensure the software satisfies software-relevant system requirements and constraints. Software engineers must maintain sufficient knowledge of the non-software elements of the systems that will execute their software, as well as the systems their software must interface with.
  • Infrastructure (Resilience-Oriented) Modelling Language: I®ML

    Infrastructure (Resilience-Oriented) Modelling Language: I®ML

    Infrastructure (Resilience-oriented) Modelling Language: I®ML A proposal for modelling infrastructures and their interconnections Andrés Silva, Roberto Filippini EUR 24727 EN - 2011 The mission of the JRC-IPSC is to provide research results and to support EU policy-makers in their effort towards global security and towards protection of European citizens from accidents, deliberate attacks, fraud and illegal actions against EU policies. European Commission Joint Research Centre Institute for the Protection and Security of the Citizen Contact information Address: TP 210, EC JRC Ispra, Ispra (Va) Italy E-mail: [email protected] Tel.: +39 0332 789936 Fax: http://ipsc.jrc.ec.europa.eu/ http://www.jrc.ec.europa.eu/ Legal Notice Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication. Europe Direct is a service to help you find answers to your questions about the European Union Freephone number (*): 00 800 6 7 8 9 10 11 (*) Certain mobile telephone operators do not allow access to 00 800 numbers or these calls may be billed. A great deal of additional information on the European Union is available on the Internet. It can be accessed through the Europa server http://europa.eu/ JRC 63302 EUR 24727 EN ISBN 978-92-79-19324-8 ISSN 1018-5593 doi:10.2788/54708 Luxembourg: Publications Office of the European Union © European Union, 2011 Reproduction is authorised provided the source is acknowledged Printed in Italy Infrastructure (Resilience-oriented) Modelling Language: I®ML A proposal for modelling infrastructures and their connections Andrés Silva1 Roberto Filippini Universidad Politécnica de Madrid JRC of the European Commission Abstract The modelling of critical infrastructures (CIs) is an important issue that needs to be properly addressed, for several reasons.
  • IS2018 Book of Abstract

    IS2018 Book of Abstract

    th Annual INCOSE 28 international symposium Washington, DC, USA July 7 - 12, 2018 Delivering Systems in the Age of Globalization Status as of May 15 th , 2018 Book of Abstract Table of contents keynotes ............................................................................................................................................................................... p. 7 keynotes#Keynote#2: The Big Shift: Innovation and Systems Engineering ................................................................ p. 7 Papers .................................................................................................................................................................................. p. 8 Papers#107: A Framework for Concept and its Testing on Patents ............................................................................ p. 8 Papers#75: A Framework for Testability Analysis from System Architecture Perspective .......................................... p. 9 Papers#128: A Framework for Understanding Systems Principles and Methods .......................................................p. 10 Papers#31: A fresh look at Systems Engineering - what is it, how should it work? .....................................................p. 11 Papers#35: A Hybrid Liver-Candidate Transportation System to Improve Accessibility and Extend Organ Life in L ..p. 12 Papers#55: A Novel “Resilience Viewpoint” to aid in Engineering Resilience in Systems of Systems (SoS) .............p. 13 Papers#97: A successful use of systems approaches in
  • Process Safety for the 21St Century and Beyond This Initiative

    Process Safety for the 21St Century and Beyond This Initiative

    Process Safety for the 21st Century and Beyond 1 Introduction Process safety has been practiced as a field of research and 1.1 Who was involved in this project? safety management in the oil and chemical industries since the 1960s. Over this period there have been many tragic incidents, This project was led by a steering committee convened to bring which have resulted in fatalities as well as asset, environmental, in academic, industrial, regulatory, and societal perspectives and reputational damage. While standards have improved from around the world and across stakeholders. Trish Kerin, the since then and much work has been done, particularly in director of the IChemE Safety Centre and Dr M Sam Mannan, inherently safer design and management systems, catastrophic the executive director of Mary Kay O’Connor Process Safety incidents are still happening and will continue to do so until Center were the co-chairs of the steering committee. The team we tackle them head on. It appears as if we are not learning members are listed below, and biographical details can be lessons from the past, because the causes of failures for found in Appendix A. current incidents are the same as past incidents, albeit in Team members different environments. We must learn from these incidents. As an industry, our inability to learn from past incidents and ■■ Dr Paul Amyotte demonstrate that process safety is improving has led to this ■■ Dr Ian Cameron project, Process Safety in the 21st Century and Beyond. The aim of this project is to envision better process safety by ■■ Dr Mike Considine outlining efforts that each stakeholder can take.
  • Control of Hazardous Energy by Lock-Out and Tag-Out

    Control of Hazardous Energy by Lock-Out and Tag-Out

    Control of Hazardous Energy By Lock-out and Tag-out Why Lock-Out and Tag-Out? Basics of Lock-Out and Tag-Out Learning From Case Histories What Industry Process Safety Leaders Say Additional Reading February 23, 2005 This Safety Alert can also be found on the CCPS Web site at http://www.aiche.org/ccps/safetyalert Copyright 2005 American Institute of Chemical Engineers Engineers Chemical of Institute Copyright 2005 American CCPS Safety Alert, February 23, 2005 The Center for Chemical Process Safety was established by the American Institute of Chemical Engineers in 1985 to focus on the engineering and management practices to prevent and mitigate major incidents involving the release of hazardous chemicals and hydrocarbons. CCPS is active worldwide through its comprehensive publishing program, annual technical conference, research, and instructional material for undergraduate engineering education. For more information about CCPS, please call 212-591-7319, e-mail [email protected], or visit www.aiche.org/ccps Copyright 2005 American Institute of Chemical Engineers 3 Park Avenue New York, New York 10016 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without the prior permission of the copyright owner. It is sincerely hoped that the information presented in this document will lead to an even more impressive record for the entire industry; however, the American Institute of Chemical Engineers, its consultants, CCPS Subcommittee members, their employers, and their employers’ officers and directors disclaim making or giving any warranties, expressed or implied, including with respect to fitness, intended purpose, use or merchantability and/or correctness or accuracy of the content of the information presented in this document.
  • Towards Safety Assessment Checklist for Safety-Critical Systems P.V

    Towards Safety Assessment Checklist for Safety-Critical Systems P.V

    Article can be accessed online at http://www.publishingindia.com Towards Safety Assessment Checklist for Safety-critical Systems P.V. Srinivas Acharyulu*, P. S. Ramaiah** Abstract 1. Introduction Safety-critical systems are ever increasing in day to Safety-Critical Systems are those systems whose failure day life such as use from microwave oven to robots could result in loss of life, significant property damage, involving computer systems and software. Safety- or damage to environment (Knight, J.C, 2002). Safety in critical systems must consider safety engineering and broad pertains to the whole system, computer hardware, safety management principles in order to be safe when software, other electronic & electrical components and they are put into use. Safety analysis must be done. stake holders. A safety-critical system is such a system Safety assessment of such systems is difficult but not impossible. They must deal with the hazards analysis which has the potential to cause hazard either directly or in order to reduce or prevent risks to environment, indirectly. The emphasis of this paper is on the element property damage and / or loss of life through risk-free of software for such safety critical systems, which can and failure free or fail-safe operations. The existing be referred to as safety critical software. Some of the methods are found to be limited and inadequate safety critical applications include flight control systems, to address the risks associated and for safety medical diagnostic and treatment devices, weapon assessment. This paper proposes a methodology for systems, nuclear power systems, robots and many. Failure safety assessment of safety critical systems based on free and risk free or fail-safe operations may not lead to identifying significant and non-significant aspects of hazards.
  • A Checklist for Inherently Safer Chemical Reaction Process Design and Operation

    A Checklist for Inherently Safer Chemical Reaction Process Design and Operation

    A Checklist for Inherently Safer Chemical Reaction Process Design and Operation Introduction Chemical reaction hazard identification • Reaction process design considerations Ž Where to get more help March 1, 2004 This Safety Alert can also be found on the CCPS Web site at http://www.aiche.org/ccps/safetyalert Copyright 2004 American Institute of Chemical Engineers The Center for Chemical Process Safety was established by the American Institute of Chemical Engineers in 1985 to focus on the engineering and management practices to prevent and mitigate major incidents involving the release of hazardous chemicals and hydrocarbons. CCPS is active worldwide through its comprehensive publishing program, annual technical conference, research, and instructional material for undergraduate engineering education. For more information about CCPS, please call 212-591-7319, e-mail [email protected], or visit www.aiche.org/ccps Copyright 2004 American Institute of Chemical Engineers 3 Park Avenue New York, New York 10016 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise without the prior permission of the copyright owner. It is sincerely hoped that the information presented in this document will lead to an even more impressive record for the entire industry; however, the American Institute of Chemical Engineers, its consultants, CCPS Subcommittee members, their employers, and their employers’ officers and directors disclaim making or giving any warranties, expressed or implied, including with respect to fitness, intended purpose, use or merchantability and/or correctness or accuracy of the content of the information presented in this document.
  • The Status of Fire Safety Engineering in Europe

    The Status of Fire Safety Engineering in Europe

    SFPE European Chapters Coordination Group (ECCG) May 3, 2014 SFPE ECCG: White Paper for Professional Recognition for Fire Safety Engineering Editors: Robert Jönsson and Michael Strömgren Contributors: SFPE European Chapters Coordination Group (ECCG) SFPE Board of Directors SFPE ECCG White Paper for Professional Recognition for Fire Safety Engineering Page 1 FOREWORD This paper has been produced by the SFPE European Chapters Coordination Group (ECCG). The SFPE ECCG is a body comprised of presidents of the European Chapters of SFPE and the elected ECCG president, which has been formed to facilitate collaboration on issues which are common to the chapters. The aims of this document are to present a current snapshot of the state of recognition of fire safety engineering professionals in Europe, and to articulate a set of initiatives intended to help gain a common understanding of qualifications, educational requirements and further advance recognition of fire safety engineering professions within Europe. It is noted that the situation will change with time, and that this White Paper may not completely address the wide breadth of issues which currently exist. The ECCG would like to thank Woodrow, Bisby and Torero who have made a significant contribution to the contents of this white paper [1], particularly in the area of educational needs. The ECCG also recognizes the efforts of Jonsson and Stromgren for their efforts on data collection on the status of fire safety engineering in Europe. The directions outlined in this report align with the strategic directions of the SFPE Board of Directors, which endorses the initiatives outlined in this report. OBJECTIVE This White Paper highlights the need for appropriate qualification of fire safety engineering practitioners in Europe, and identifies initiatives for proceeding toward this objective.
  • Model for Safety Case Modeling and Documentation

    Model for Safety Case Modeling and Documentation

    SAFE – an ITEA2 project D3.1.3 Contract number: ITEA2 – 10039 Safe Automotive soFtware architEcture (SAFE) ITEA Roadmap application domains: Major: Services, Systems & Software Creation Minor: Society ITEA Roadmap technology categories: Major: Systems Engineering & Software Engineering Minor 1: Engineering Process Support WP3 Deliverable D3.1.3: Proposal for extension of Meta- model for safety case modeling and documentation Due date of deliverable: 31/03/2013 Actual submission date: 28/03/2013 Start date of the project: 01/07/2011 Duration: 36 months Project coordinator name: Stefan Voget Organization name of lead contractor for this deliverable: fortiss Editor: Maged Khalil (fortiss GmbH) Contributors: Maged Khalil (fortiss GmbH), Eduard Metzker (Vector Informatik GmbH) Reviewers: Eduard Metzker (Vector Informatik GmbH) 2013 The SAFE Consortium 1 (50) SAFE – an ITEA2 project D3.1.3 Revision chart and history log Version Date Reason 0.1 2012-09-19 Initialization of document 0.2 2012-10-18 Input to Introduction Section 4 0.3 2012-11-07 Input to Overview on ISO Section 5 0.4 2012-11-16 Input to EAST-ADL Overview Section 7 0.5 2012-11-16 Input to Overview on ISO Section 5 0.6 2012-11-23 Input to Methodology Section 6 0.7 2012-11-29 Further Input to Methodology Section 6 0.8 2012-12-20 Editing and Input in various sections 0.9 2013-02-13 Input to SAFE Meta-model Contribution Section 8 0.10 2013-02-15 Introduction of Patterns Section 6.3 0.11 2013-03-08 Editing and Input in various sections 0.12 2013-03-24 First version ready for review 0.13 2013-03-26 Incorporation of first review comments 0.14 2013-03-27 Updated version reviewed.