AN ONTOLOGICAL APPROACH TO SAFETY ANALYSIS …1163903/FULLTEXT03.pdf · These considerations motivate us to formulate the following general research question: Howcansafetyanalysis,withinthecontextofsafety

Mälardalen University Doctoral Dissertation 251

AN ONTOLOGICAL APPROACH TO SAFETY ANALYSIS OF SAFETY-CRITICAL SYSTEMS

Jiale Zhou

Jiale

Zho

u AN

ON

TOLO

GIC

AL A

PP

RO

AC

H TO

SAFETY A

NA

LYSIS OF SA

FETY-CR

ITICA

L SYSTEMS

2017

ISBN 978-91-7485-371-1ISSN 1651-4238

Address: P.O. Box 883, SE-721 23 Västerås. SwedenAddress: P.O. Box 325, SE-631 05 Eskilstuna. SwedenE-mail: [email protected] Web: www.mdh.se

Mälardalen University Press DissertationsNo. 251

AN ONTOLOGICAL APPROACH TO SAFETYANALYSIS OF SAFETY-CRITICAL SYSTEMS

Jiale Zhou

2017

School of Innovation, Design and Engineering

Copyright © Jiale Zhou, 2017ISBN 978-91-7485-371-1ISSN 1651-4238Printed by E-Print AB, Stockholm, Sweden

Mälardalen University Press DissertationsNo. 251

AN ONTOLOGICAL APPROACH TO SAFETYANALYSIS OF SAFETY-CRITICAL SYSTEMS

Jiale Zhou

Akademisk avhandling

som för avläggande av teknologie doktorsexamen i datavetenskap vidAkademin för innovation, design och teknik kommer att offentligen försvarasfredagen den 12 januari 2018, 13.00 i Delta, Mälardalens högskola, Västerås.

Fakultetsopponent: Lecturer Ibrahim Habli, University of York

Akademin för innovation, design och teknik

AbstractSafety-critical systems (SCSs) have become an intrinsic part of human dailylife in multiple domains,such as automotive, avionics, and rail industries. Suchsystems are not only required to implement thefunctionality they should provide, but also have to satisfy a set of safety requirements in order to ensurethemitigation of hazardous consequences.

It is fundamental that safety requirements are defined based on the resultsissued from safety analysis.Various studies have asserted that most significant flaws in the safety requirements are related tothe omission of hazards andcauses associated with the identified hazards in early stages of SCSsdevelopment. The main drawbacks of the current practice applied in safety analysis,lie in that:

• due to the lack of a common understanding of the hazard concept,the hazards and their causes aretypically identified in accordance to theintuition and experience of the analysts and,

• analysts are inclined to identify generic causes for a certain hazarddescription, for example, “Designflaw, Coding error, and Human error”and,

• there is an essential need to formalize the experience of the analystsin a structured way, in order tosave effort and,

• since traditional safety analysis techniques are usually based on wellknown system behaviorsrepresented by models, such as automata andsequence diagrams, a new approach is needed when suchbehavioralmodels are not available.

These considerations motivate us to formulate the following general researchquestion: How can safetyanalysis, within the context of safety-critical systems, be conducted to reduce the omission of potential hazards andtheir causes inearly stages of the system development life-cycle?

In this thesis, we propose an ontological approach to safety analysis forsafety-critical systems, whichmainly consists of four pieces of work:

• we propose an ontological interpretation of the hazard concept, calledthe Hazard Ontology (HO), todefine an explicit representation of theknowledge of hazards and their relations with the system underanalysisand existing environment and,

• we propose an approach to identify hazards in early stages of thesafety-critical systems development,based on the HO and,

• we propose an approach to identify the causes associated with a certain hazard description for safety-critical systems, based on the HO and,

• we propose a heuristic approach to safety requirements elicitation,based on the HO.

ISBN 978-91-7485-371-1 ISSN 1651-4238

Abstract

Safety-critical systems (SCSs) have become an intrinsic part of human dailylife in multiple domains, such as automotive, avionics, and rail industries. Suchsystems are not only required to implement the functionality they should pro-vide, but also have to satisfy a set of safety requirements in order to ensure themitigation of hazardous consequences.

It is fundamental that safety requirements are defined based on the resultsissued from safety analysis. Various studies have asserted that most signifi-cant flaws in the safety requirements are related to the omission of hazards andcauses associated with the identified hazards in early stages of SCSs develop-ment. The main drawbacks of current practice applied in safety analysis, lie inthat:

• Due to the lack of a common understanding of the hazard concept, haz-ards and their causes are typically identified in accordance to the intu-ition and experience of analysts and,

• Analysts are inclined to identify generic causes for a certain hazard de-scription, for example, “Design flaw, Coding error, and Human error”and,

• There is an essential need to formalize the experience of analysts in astructured way, in order to save effort and,

• Since traditional safety analysis techniques are usually based on well-known system behaviors represented by models, such as automata andsequence diagrams, a new approach is needed when such behavioralmodels are not available.

These considerations motivate us to formulate the following general researchquestion: How can safety analysis, within the context of safety-critical systems,

i

ii

be conducted to reduce the omission of potential hazards and their causes inearly stages of the system development life-cycle?

In this thesis, we propose an ontological approach to safety analysis forsafety-critical systems, which mainly consists of four pieces of work:

• We propose an ontological interpretation of the hazard concept, calledthe Hazard Ontology (HO), to define an explicit representation of theknowledge of hazards and their relations with the system under analysisand existing environment and,

• We propose an approach to identify hazards in early stages of the safety-critical systems development, based on the HO and,

• We propose an approach to identify the causes associated with a certainhazard description for safety-critical systems, based on the HO and,

• We propose a heuristic approach to safety requirements elicitation, basedon the HO.

Summary

Safety-critical systems (SCSs) are such systems that can result in great losseswhen they are involved in hazardous situations. In modern society, SCSs arebecoming pervasive and an indispensable part of our daily life. They playan essential role in various human activities, such as medical treatment, dailytransportation, space exploration, and operation of nuclear power plants. Toavoid the occurrence of accidents, it is of significant importance to providesafety mechanisms for these systems. The safety mechanisms will preventthese systems from being involved in hazardous situations, i.e., hazards. Toachieve this goal, system analysts need to identify potential hazards in whichthe system under analysis can be involved during its life-cycle. In addition, itis also important to analyze the causes of how and why the system is involvedin the hazardous situation. As an old saying goes, “A good beginning is halfthe battle”. The earlier the system analysts can have a complete picture of po-tential hazards, the more and better design choices can be made to avoid acci-dents. However, it is not a trivial task to accomplish this goal. One big problemis that different analysts may have distinct understanding of what a hazard is,i.e., what components a hazard consists of. Therefore, the description of haz-ards identified by one analyst is at a risk of missing some components and cancause ambiguities for others. To improve this situation, we propose a definitionof hazard in our research. In this definition, we have defined what componentsa hazard consists of, the relations between the components and how the com-ponents together can lead to an accident. This definition will help analystsachieve a consistent view of hazards. Moreover, based on this definition, anapproach to identify hazards and their causes is proposed. According to theidentified hazards and causes, safety mechanisms will be defined to prevent thesystems from encountering accidents.

iii

SwedishSummary/Sammanfattning

Sakerhetskritiska system (SCS) ar sadana system som kan leda till storaforluster nar de ar inblandade i farliga situationer. I det moderna samhalletar SCSs en oumbarlig del av vart dagliga liv och spelar en viktig roll i olikaaktiviteter sasom medicinsk behandling, daglig transport, rymdutforskning ochdrift av karnkraftverk. For att undvika olyckshandelser ar det viktigt att tillhan-dahalla sakerhetsmekanismer for dessa system. Sadana mekanismer forhindraratt systemen hamnar i farliga situationer. For att uppna detta mal maste system-analytiker identifiera potentiella risker for system under dess livscykel. Dessu-tom ar det viktigt att analysera orsakerna till hur systemet ar involverat i risk-fyllda situationer. Enligt ett gammalt ordsprak sags “Med en bra borjan arhalva jobbet gjort”, dvs ju tidigare systemanalytikerna kan fa en helhetsbildav potentiella faror, desto fler designmojligheter har de for att kunna undvikaolyckor. Det ar dock inte en trivial uppgift. Ett problem ar att olika analytikerkan paverkas av sin egen forstaelse for vad en fara ar, dvs vilka komponenteren fara bestar av. Darfor kan risker som identifierats av en analytiker saknakomponenter och orsaka tvetydigheter for andra. For att forbattra denna sit-uation foreslar vi i denna avhandling en definition av fara. Vi har definieratvilka komponenter en fara bestar av, relationerna mellan komponenterna ochhur komponenterna tillsammans kan leda till en olycka. Definitionen kommeratt hjalpa analytiker att uppna en konsekvent uppfattning om faror. Dessutomanvands definitionen for att identifiera bade faror och orsaker till faror. Baseratpa de identifierade farorna och orsakerna sakerstalls sakerhetsmekanismer foratt forhindra att systemen stoter pa olyckor.

iv

Acknowledgments

During the past years, my life went up and down, which makes me better un-derstand the importance of support. I am greatly indebted to lots of people.Without their support and expert guidance, the work presented in this doctoralthesis would not have been possible. Here, I would like to express my grati-tude, appreciation, and many thanks to them.

First of all, I would like to extend my sincere gratitude to my supervisorsProf. Kristina Lundqvist, Dr. Kaj Hanninen, Dr. Luciana Provenzano and Dr.Yue Lu for their support, encouragement and intensive guidance throughoutmy research work. It has been nothing but a great pleasure to work with you.

High tribute shall be paid to Prof. Lars Asplund for his encouraging me tobecome a Ph.D. student; and Prof. Kristina Forsberg for her industrial experi-ence brought to my work and friendly invitation to her family activities. Myspecial thanks should go to: my office-mates over the years, Andreas Johnsen,Adnan Causevic, Huseyin Aysan, and Abhilash Thekkilakattil, for all the helpand great office hours; Goran Bertheau and Kristian Wiklund, for their interestin my work and helpful suggestions; my Chinese colleagues, Yin Hang, KanYu, and Meng Liu, for their sharing work life and research experience.

My genuine thanks must be given to Damir Isovic, Hans Hansson, ThomasNolte, Sasikumar Punnekkat, Ivica Crnkovic, Radu Dobrin, Mikael Sjodin,Frank Luders, Jan Carlson, Bo Liwang, et al., for all the guidance, help, inspi-ration and interesting discussions. I would also like to thank the administrativestaff, Malin Rosqvist, Carola Ryttersson, Gunnar Widforss, Susanne Fronna,Jenny Hgglund, et. al., for making many things easier.

I would like to jointly thank all the people at the IDT department,Malardalen University. I have truly not seen a more friendly, encouraging,inspiring and open-minded environment to work in.

Here, I should have to mention a list of my friends outside of work: HangYin, Meng Liu, Jing Yue, Kan Yu, Bohan Guo, Lu Zhou, Tian Qiu, Yankai

vi

vii

Shao, Shiliang Tong, Qin Svantesson, Guanting Liu, Yixiao Wang, JinsongYang, Lifei Tang, et al., for making my life vivid and much easier.

Finally, I would like to express my deepest gratitude to my beloved family.My deepest gratitude goes to my parents for loving considerations and greatconfidence in me all through these years. Many thanks go to my girlfriend Ms.Teng Wu for being always supportive in all these rough and tough days andbringing endless love and happiness to my life.

Jiale ZhouVasteras, December 2017

List of Publications

Papers Included in the Doctoral Thesis1

Paper A An Ontological Interpretation of the Hazard Concept for Safety-Critical Systems. Jiale Zhou, Kaj Hanninen, Kristina Lundqvist, andLuciana Provenzano. Proceedings of the 27th European Safety and Re-liability Conference (ESREL’17), Portoroz, Slovenia, June 2017.

Paper B A Hazard Modeling Language for Safety-Critical Systems Basedon the Hazard Ontology. Jiale Zhou, Kaj Hanninen, and KristinaLundqvist. Proceedings of the 43th Euromicro Conference on SoftwareEngineering and Advanced Applications (SEAA’17), Vienna, Austria,August 2017.

Paper C An Ontological Approach to Hazard Identification for Safety-CriticalSystems. Jiale Zhou, Kaj Hanninen, Kristina Lundqvist, and LucianaProvenzano. Proceedings of the 2nd International Conference on Relia-bility Systems Engineering (ICRSE’17), Beijing, China, July 2017.

Paper D An Ontological Approach to Identify the Causes of Hazards forSafety-Critical Systems. Jiale Zhou, Kaj Hanninen, Kristina Lundqvist,and Luciana Provenzano. Proceedings of the 2nd International Confer-ence on System Reliability and Safety (ICSRS’17), Milan, Italy, Decem-ber 2017.

Paper E An Ontological Approach to Elicit Safety Requirements. LucianaProvenzano, Kaj Hanninen, Jiale Zhou, and Kristina Lundqvist. Pro-ceedings of the 24th Asia-Pacific Software Engineering Conference(APSEC’17), Nanjing, China, December 2017.

1The included articles have been reformatted to comply with the thesis layout.

ix

x

Related Publication not Included in the DoctoralThesis• Formal Execution Semantics for Asynchronous Constructs of AADL.

Jiale Zhou, Andreas Johnsen, and Kristina Lundqvist. Proceedingsof the 5th International Workshop on Model Based Architecting andConstruction of Embedded Systems (ACES-MB’12), Innsbruck, Aus-tria, October 2012.

• A Context-based Information Retrieval Technique for Recovering Use-Case-to-Source-Code Trace Links in Embedded Software Systems. JialeZhou, Yue Lu, and Kristina Lundqvist. Proceedings of the 39th Eu-romicro Conference on Software Engineering and Advanced Applica-tions (SEAA’13), Santander, Spain, September 2013.

• A TASM-based Requirements Validation Approach for Safety-criticalEmbedded Systems. Jiale Zhou, Yue Lu and Kristina Lundqvist. Pro-ceedings of the 19th Ada-Europe International Conference on ReliableSoftware Technologies (Ada-Europe’14), Paris, France, June 2014.

• Towards Feature-Oriented Requirements Validation for Automotive Sys-tems. Jiale Zhou, Yue Lu, Kristina Lundqvist, Henrik Lonn, DanielKarlsson, and Bo Liwang. Proceedings of the 22nd IEEE InternationalRequirements Engineering Conference (RE’14), Karlskrona, Sweden,August 2014.

• The Observer-based Technique for Requirements Validation in Embed-ded Real-time Systems. Jiale Zhou, Yue Lu, and Kristina Lundqvist.Proceedings of the 1st International Workshop on Requirements Engi-neering and Testing (RET’14), Karlskrona, Sweden, August 2014.

• An Observer-Based Technique with Trace Links for Requirements Vali-dation in Embedded Real-Time Systems. Jiale Zhou. Licentiate thesis,Malardalen University, 2014.

• An Environment-Driven Ontological Approach to Requirements Elicita-tion for Safety-Critical Systems. Jiale Zhou, Kaj Hanninen, KristinaLundqvist, Yue Lu, Luciana Provenzano, and Kristina Forsberg. Pro-ceedings of the 23nd IEEE International Requirements Engineering Con-ference (RE’15), Ottawa, Canada, August 2015.

Contents

I Thesis 1

1 Introduction 31.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Overview of Contributions . . . . . . . . . . . . . . . . . . . 81.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Background and Related work 112.1 Unified Foundational Ontology . . . . . . . . . . . . . . . . . 112.2 Hazard Triangle Model . . . . . . . . . . . . . . . . . . . . . 142.3 Hazard Analysis Techniques . . . . . . . . . . . . . . . . . . 162.4 Safety Requirements Elicitation . . . . . . . . . . . . . . . . 18

3 An Ontological Approach to Safety Analysis 213.1 Description of the Robotic Strolling System . . . . . . . . . . 213.2 The Hazard Ontology . . . . . . . . . . . . . . . . . . . . . . 233.3 A Hazard Modeling Language . . . . . . . . . . . . . . . . . 243.4 The Ontological Approach to Hazard and Causes Identification 27

3.4.1 Step 3.4.1: System Description Formalization . . . . . 273.4.2 Step 3.4.2: Mishap Victim Identification . . . . . . . . 283.4.3 Step 3.4.3: Hazard Population . . . . . . . . . . . . . 293.4.4 Step 3.4.4: Causes Exploration . . . . . . . . . . . . . 30

3.5 Safety Requirements Elicitation for Hazard Elimination . . . . 323.5.1 SARE-ACT1: Overcome an object’s weakness . . . . 323.5.2 SARE-ACT2: Change, add or remove an object’s role 333.5.3 SARE-ACT3: Cut off existing relations . . . . . . . . 333.5.4 Illustration for safety requirements elicitation . . . . . 34

3.6 Discussion of Evaluation . . . . . . . . . . . . . . . . . . . . 34

xi

xii Contents

3.6.1 Summary of evaluation results . . . . . . . . . . . . . 353.6.2 Thoughts about evaluation . . . . . . . . . . . . . . . 36

4 Research Overview 374.1 Questions, Challenges and Contributions . . . . . . . . . . . . 37

4.1.1 Research Question One (RQ1) . . . . . . . . . . . . . 374.1.2 Research Question Two (RQ2) . . . . . . . . . . . . . 394.1.3 Research Question Three (RQ3) . . . . . . . . . . . . 404.1.4 Research Question Four (RQ4) . . . . . . . . . . . . . 41

4.2 Research Methodology . . . . . . . . . . . . . . . . . . . . . 41

5 Conclusion and Future Work 455.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Bibliography 49

II Included Papers 55

6 Paper A:An Ontological Interpretation of the Hazard Concept for Safety-Critical Systems 576.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

6.2.1 The Unified Foundational Ontology - UFO . . . . . . 36.2.2 An informal interpretation of hazard . . . . . . . . . . 6

6.3 The Hazard Ontology . . . . . . . . . . . . . . . . . . . . . . 86.3.1 The Methodology to Engineering the HO . . . . . . . 86.3.2 The Concepts and Relations in the Hazard Ontology . 10

6.4 Practical Implications . . . . . . . . . . . . . . . . . . . . . . 126.4.1 The Categorization of Hazard Descriptions . . . . . . 126.4.2 Findings . . . . . . . . . . . . . . . . . . . . . . . . 14

6.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 156.6 Conclusion and Future Work . . . . . . . . . . . . . . . . . . 59Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Contents xiii

7 Paper B:A Hazard Modeling Language for Safety-Critical Systems Basedon the Hazard Ontology 657.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 677.2 The Hazard Ontology . . . . . . . . . . . . . . . . . . . . . . 687.3 The Hazard Modeling Language . . . . . . . . . . . . . . . . 707.4 An Approach to Transform from NL Hazard Descriptions into

the HML Specifications . . . . . . . . . . . . . . . . . . . . . 717.4.1 Hazard Description Analysis . . . . . . . . . . . . . . 727.4.2 Hazard Description Formalization . . . . . . . . . . . 737.4.3 Hazard Specification Population . . . . . . . . . . . . 74


8 Paper C:An Ontological Approach to Hazard Identification for Safety-Critical Systems 818.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 838.2 The Hazard Ontology . . . . . . . . . . . . . . . . . . . . . . 848.3 The Ontological Approach to Hazard Identification - OHI . . . 87

8.3.1 Description of the Robotic Strolling System . . . . . . 878.3.2 OHI-Step 1: System Description Formalization . . . . 888.3.3 OHI-Step 2: Mishap Victim Identification . . . . . . . 908.3.4 OHI-Step 3: Hazard Population . . . . . . . . . . . . 91

8.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 938.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 948.6 Conclusion and Future Work . . . . . . . . . . . . . . . . . . 96Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

9 Paper D:An Ontological Approach to Identify the Causes of Hazards forSafety-Critical Systems 999.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 1019.2 The Hazard Ontology . . . . . . . . . . . . . . . . . . . . . . 1039.3 The Ontological Approach to Identify the Causes of Hazards -

OCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1059.3.1 Description of Application Scenario . . . . . . . . . . 1069.3.2 OCH-Step 1: Hazard Description Categorization . . . 107

xiv Contents

9.3.3 OCH-Step 2: Hazard Description Expansion . . . . . 1089.3.4 OCH-Step 3: Causes Exploration . . . . . . . . . . . 110

9.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1139.4.1 Comparison Analysis . . . . . . . . . . . . . . . . . . 1149.4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . 115


10 Paper E:An Ontological Approach to Elicit Safety Requirements 12310.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 12510.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 12610.3 The Ontological Approach to Elicit Safety Requirements . . . 127

10.3.1 Description of the application scenario . . . . . . . . . 12710.3.2 From hazard’s components to safety requirements . . . 12710.3.3 The heuristic Safety Requirements Elicitation (SARE)

approach . . . . . . . . . . . . . . . . . . . . . . . . 12910.3.4 SARE-ACT1: overcome an object’s weakness . . . . . 12910.3.5 SARE-ACT2: change, add or remove an object’s role . 13110.3.6 SARE-ACT3: cut off existing relations . . . . . . . . 13310.3.7 The SARE approach applied to the PB lamp control . 134

10.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 13610.4.1 Safety requirements elicitation and specification based

on safety analysis . . . . . . . . . . . . . . . . . . . . 13610.4.2 Requirements elicitation based on ontologies . . . . . 137

10.5 Conclusion and Future Work . . . . . . . . . . . . . . . . . . 138Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

I

Thesis

1

Chapter 1

Introduction

Safety-critical systems (SCSs) are such systems that can result in great losseswhen they are involved in hazardous situations1, i.e., hazards. In modern soci-ety, SCSs are becoming pervasive and an indispensable part of our daily life.They play an essential role in various human activities, such as medical treat-ment [1], daily transportation [2], space exploration [3], and operation of nu-clear power plants [4]. Nevertheless, while they implement certain functionsto offer conveniences, the operation of such systems is inevitably at a risk ofan involvement of serious hazardous situations that can lead to accidents, forinstance, the Yongwen railway accident2 [5], Space Shuttle Challenger disas-ter3 [6], poison gas leakage accident in Bhopal4 [7], etc. These accidents couldhave an enormous negative impact on people’s life, natural environment, and/orour society in general. Accordingly, SCSs are not only required to implementcertain functionality, but also to integrate safety considerations into the systemsdevelopment life-cycle [8].

Safety represents the state of being safe. It is an emergent property of aSCS. As an emergent property, it indicates that even if every component of the

1The involvement includes two aspects: 1) the system under construction can cause a hazard,such as brake failure can cause a car collision or; 2) the system is exposed to a hazard, such as astrong magnetic field that interferes with the control system

2On July 23, 2011, two high-speed trains traveling on the Yongwen railway line collided witheach other on a viaduct in Zhejiang province, China.

3On January 28, 1986, the tenth flight of NASA Space Shuttle Challenger broke apart 73 sec-onds into its flight, killing all seven crew members.

4During the night of December 2-3, 1984, a storage tank containing methyl isocyanate leakedgas into the densely populated city of Bhopal, India. Killing an estimated 3,000 to 6,000 people.

3

4 Chapter 1. Introduction

system can separately be proper-functioning, the operation of the system is stillat the risk of encountering serious mishaps [9]. In safety engineering, the termsystem typically refers to the combination of the system under constructionas well as the environment where it operates. The system under constructionmust be defined in terms of its functions, boundaries, and interfaces, the as-sumptions about the environment and the environmental properties should beexplicitly identified to enable various analysis and further elicitation of safetyrequirements [8]. For instance, a system for rail service commuting betweentwo cities could consist of drivers, passengers, freight trains, different types ofsignaling and electrification sub-systems, tracks, platforms, tunnels, weatherconditions, etc., as shown in Figure 1.1.

Figure 1.1: A system for rail service commuting between two cities.

Often safety is deemed as being expensive both from economical and tech-nical perspectives, since it usually results in increased system complexity, re-duced operating performance, or extra development cost [10]. However, theroot cause of this situation is not due to any intrinsic property of safety it-self. On the contrary, it is mainly because when major architectural designdecisions are made, a common choice is to add expensive redundancy or ex-cessive design margins to guarantee safety [11]. One possible way to makebetter safety-related decision is to integrate safety-concerned activities into thesystem development life-cycle from very initial stages. Doing so safety con-siderations can have an impact on system architectural design as early as pos-sible. The main contribution of this thesis is to propose an approach to performsafety-concerned activities in the initial stages of SCS development life-cycle.

1.1 MotivationThe development life-cycle of a SCS consists of several stages, including sys-tem conception, architecture design, component development, production, op-eration, maintenance, retirement and disposal. During the development of the

1.1 Motivation 5

SCS, safety-concerned activities should be integrated into each stage of thedevelopment process. This has been required by safety standards in differentdomains, e.g., ISO13849 [12] and IEC62061 [13] for machines with movingparts, ISO26262 [14] for Automotive, EN50129/EN501289 [15] for Railway,and IEC61508 [16] for generic control systems.

The safety development process incorporate several steps as follows [17]:1) identify system hazards and define safety requirements, 2) determine howthe various components in the system can contribute to these hazards, 3) definederived safety requirements for the components (repeat recursively over thesystem hierarchy as needed), and then 4) develop components to meet thesesafety requirements. The earlier the system developer can have a whole pic-ture of potential hazards, the more and better design choices they can make toaddress the hazards. Therefore, identifying system hazards and defining safetyrequirements at early stages play an essential role in the safety development ofSCSs.

Preliminary hazard analysis (PHA) is an essential safety-concerned activityconducted at early stages. The objective of PHA is to achieve a fully under-standing of potential system hazards in which the SCS can be involved. Basedon the understanding, different levels of safety requirements/mechanisms aredefined to mitigate or address the hazards. Typically, the analysts will performa set of tasks in accordance to their understanding of the concept of hazard,i.e., what is a hazard. The main tasks of a PHA include:

• identify potential system hazards taking system description as input,

• analyze the causes associated with the identified hazards,

• and elicit safety requirements or define safety mechanisms to mitigatesuch hazards.

By following the flow of these tasks, PHA provides stakeholders with a fullyunderstanding of the potential system hazards involving the system under anal-ysis, in terms of hazard descriptions, causes, consequences, mitigations, etc.However, there are some deficiencies lying in current practices of the tasks,which motivate us to provide a holistic approach to address the deficiencies.

We start with a discussion of the understanding of the hazard concept. Theconcept of hazard has been extensively used in the literature and defined inan informal way, which serves as a guidance on identifying potential hazardsduring the development of SCSs. For instance, Leveson [8] defines a hazard as“a system state or set of conditions that, together with a particular set of worst-case environmental conditions, will lead to an accident (loss)”. In the standards


MIL-STD-882 [18] and EN-50129 [15], similar definitions are put forwardas “hazard is any real or potential condition that can cause injury, illness, ordeath to personnel; damage to or loss of a system, equipment, or property; ordamage to the environment” and “hazard is a condition that could lead to anaccident”, respectively. Intuitively, these definitions seem to be consistent andeasy to understand. However, when we take a closer look at them, ambiguitiesmay arise, e.g., whether a hazard is a particular system state, or a combinationof system and environment states. Moreover, these definitions lack precisedefinition of the term “condition” from the perspective of real-world semantics,i.e., the correspondence between the term “condition” and entities (e.g., object,relation, property, event, etc.) in the real world. Last but not least, many termsare used to represent the causal relation between “condition” and “accident”,such as “contribute to”, “cause”, and “lead to”. Although these terms are inline with people’s intuition, there is still a need to add constraints to the causalrelation from the perspective of real-world semantics, e.g., to define what typeof real-world entities can be connected by a causal relation, and to explain howthe real-world entities together make the causal relation true.

A common way to define such semantic constraints is through the defini-tion of an ontology. An ontology can be defined as a reference model about acertain subject or domain that consists of a set of subject-/domain-specific con-cepts, relations, and axioms. Such domain ontology aims to achieve a betterunderstanding of the subject or domain from modelers and model users pointof view [19]. Several domain ontologies, which are related with hazard, havebeen proposed in the literature [20] [21] [22] [23]. Nevertheless, either theyleave the real-world semantics out of consideration, or they provide it in aninformal way. In order to interpret hazard in the real-world semantics, founda-tional concepts (e.g., object, event, relator, universal, etc.) should be explicitlytaken into account. A foundational ontology is a theoretically well-foundedsubject-/domain-independent ontology, which consists of a set of foundationalconcepts and relations. It can be grounded in to provide a sound real-worldsemantics for a subject-/domain-specific ontology. These considerations mo-tivate us to formulate the following research question (RQ1): How can weconceptualize hazards from the real-world semantics perspective to improvethe understanding of the hazard concept, within the context of safety-criticalsystems?

Due to the lack of a common understanding of the hazard concept, hazardsand their causes are typically identified in accordance to the intuition and expe-rience of analysts [24], with the risk of missing environmental assumptions andcausing ambiguities in natural language hazard descriptions. In addition, ana-

1.1 Motivation 7

lysts are inclined to identify generic causes for a certain hazard description, forexample, “Design flaw, Coding error, and Human error” can be listed as pos-sible causes, but this type of generic information is not particularly useful forguiding the safety requirements elicitation [9]. Furthermore, since the identifi-cation of hazards and their causes highly relies on the experience possessed bythe analysts and the lessons learned in previous systems development, there is aneed to formalize these experiences in a structured way which can be reused toidentify a more complete set of hazards and their causes [25]. Lastly, since tra-ditional hazard and causes identification techniques are usually based on well-known system behaviors [26] represented by models, such as automata andsequence diagrams, a new approach is needed when such behavioral modelsare not available at early stages. These considerations motivate us to formu-late the following research questions (RQ2 and RQ3): 1) How can we improvethe identification of potential hazards associated with the safety-critical systemunder analysis, based on an improved understanding of the hazard concept?and, 2) how can we improve the identification of possible causes associatedwith a certain hazard, to make the results of hazard analysis more completeand useful, based on an improved understanding of the hazard concept?

Based on identified hazards and their associated causes, safety constraintscan be developed. The safety constraints are high level safety requirementsthat aim to eliminate or mitigate the identified hazards [8]. Typically, a safetyconstraint can be the negation form of an identified hazard. For instance, ifthe hazard is of the form “a hazardous state occurs”, the safety constraintswill be derived in the form of “a hazardous state should not occur”. However,this kind of simple translation from hazard to safety constraints provides littleguidance for engineers to implement mitigation mechanisms in practice. Forexample, one could list “avoid that a running train misses the red light sig-nal before a crossroad” and “avoid that a train runs over speed” as high levelsafety constraints to mitigate corresponding hazards. Obviously, these kinds ofsafety constraints can only prescribe what not to do, but fail to provide guid-ance on how to satisfy them. An interpretation of the hazard concept couldbe helpful in such situation. Since the interpretation of hazard can reveal howthe constituents of a hazardous state can contribute to the occurrence of ac-cidents, the mitigation mechanisms can be defined either to eliminate one ofthe constituents of the hazardous state, or to impede the way through whichcertain constituents contribute to the accidents. These considerations motivateus to formulate the following research question (RQ4): How can we utilizethe understanding of the hazard concept to facilitate the elicitation of safetyrequirements of safety-critical systems?


1.2 Overview of ContributionsWe propose an ontological approach to safety analysis of safety-critical sys-tems, which mainly consists of five pieces of work. In particular, the technicalcontribution is five-fold:

• In Paper A, we propose an ontological interpretation of the hazard con-cept, called the Hazard Ontology (HO), to define an explicit represen-tation of the knowledge of hazards and their relations with the systemunder analysis and existing environment.

– Personal contribution to Paper A: Jiale was the main author ofPaper A. He has been involved in all parts of the work, in terms ofresearch idea formulation, literature review, ontology construction,ontology evaluation, and paper writing.

• In Paper B, we propose a hazard modeling language to reduce ambigu-ities brought by natural language hazard descriptions, based on the HO.Meanwhile, an approach is presented to transform from natural languagehazard description to the hazard modeling language.

– Personal contribution to Paper B: Jiale was the main author ofPaper B. He has been involved in all parts of the work, in termsof research idea formulation, literature review, language proposal,transformation approach proposal, and paper writing.

• In Paper C, we propose an approach to identify hazards in early stagesof the safety-critical systems development, based on the HO.

– Personal contribution to Paper C: Jiale was the main author ofPaper C. He has been involved in all parts of the work, in terms ofresearch idea formulation, literature review, approach proposal andevaluation, and paper writing.

• In Paper D, we propose an approach to identify the causes associatedwith a certain hazard description of safety-critical systems, based on theHO.

– Personal contribution to Paper D: Jiale was the main author ofPaper D. He has been involved in all parts of the work, in terms ofresearch idea formulation, literature review, approach proposal andevaluation, and paper writing.

1.3 Thesis Outline 9

• In Paper E, we propose a heuristic approach to safety requirements elic-itation, based on the HO.

– Personal contribution to Paper E: Jiale was a co-author of Pa-per E. He has been involved in several parts of the work, in termsof research idea formulation, literature review, solution discussionand evaluation, and paper review.

1.3 Thesis OutlineThe thesis is divided into two parts: Part I includes five chapters. Chapter 1provides an introduction of the thesis where the motivation of our work andan overview of the thesis contributions are presented. In Chapter 2, we de-scribe the background knowledge of the research work underlying the thesis,and related work. In Chapter 3, we give a more detailed introduction on theontological approach to safety analysis. In Chapter 4, a research overview ispresented, including the research questions guiding our work, the challengesassociated with each question, our contributions to each question, and the re-search methodology adopted in this thesis. In Chapter 5, we summarize thethesis work with concluding remarks, and ending with a discussion of the fu-ture work.

Part II incorporates the research papers included in this thesis, which areorganized as follows:

• Chapter 6 Paper A: An Ontological Interpretation of the Hazard Con-cept for Safety-Critical Systems

• Chapter 7 Paper B: A Hazard Modeling Language for Safety-CriticalSystems Based on the Hazard Ontology

• Chapter 8 Paper C: An Ontological Approach to Hazard Identificationfor Safety-Critical Systems

• Chapter 9 Paper D: An Ontological Approach to Identify the Causes ofHazards for Safety-Critical Systems

• Chapter 10 Paper E: An Ontological Approach to Elicit Safety Re-quirements

Chapter 2

Background and Relatedwork

In this chapter, we briefly introduce the background knowledge underlying thethesis and other related work. The Unified Foundational Ontology that is thefoundational ontology used in the thesis is presented in Section 2.1. We intro-duce the Hazard Triangle Model in Section 2.2 and discuss its deficiencies asa hazard conceptualization. A summary of existing hazard analysis techniquesis provided in Section 2.3. Finally, we describe the current practice of safetyrequirements elicitation in Section 2.4.

2.1 Unified Foundational OntologyAn ontology typically stores three kinds of facts of a certain domain, in thesense of 1) concepts that represent entities of importance in a certain domainand, 2) domain-specific relations that are labeled directed connections betweenconcepts of the domain and, 3) axioms that are used to model knowledge thatare always true, e.g., sub-class (which specifies that one concept is a sub-classof another concept). Therefore, a domain ontology can serve as a referencemodel to conceptualize the subject domain with truthfulness, clarity and ex-pressivity, regardless of computational requirements [27]. In this way, a shar-ing understanding of the domain can be achieved by both the ontology design-ers and ontology users. Furthermore, to be able to adequately serve as a refer-ence model, a domain ontology should be constructed using an approach that

11

12 Chapter 2. Background and Related work

explicitly takes foundational concepts or categories1, e.g., object, event, relator,universal, etc, into account [28]. Consequently, the foundational concepts willoffer support for the ontology designers in externalizing the real-world seman-tics of ontology concepts, choosing a particular pattern to represent the domainknowledge, or justifying the choice of a particular pattern over another [29].The use of foundational concepts is becoming ever-more accepted by the onto-logical engineering community, especially for representing complex domains,such as software enterprises [19] and software processes [30].

In this thesis, we employ the Unified Foundational Ontology (UFO) [28] asfoundational ontology. Comparing other existing foundational ontologies, suchas GFO [31], BFO [32], DOCLE [33], etc., UFO provides a more completeset of foundational concepts to cover important aspects of hazards, such asSituation, Disposition, and Kind/Role. Moreover, causal relations are definedbased on these concepts. In the following, we present a fragment of the UFOcontaining the concepts that are germane for the purposes of this paper, asshown in Figure 2.1

Figure 2.1: A fragment of the UML diagrams of UFO. Concepts are repre-sented as rectangles. Typed relations are represented by lines with a readingdirection pointed by “I”, from open end to aggregated end. Cardinality con-straints are labeled on each end of typed relations. Subsumption constraintsare represented by open-headed arrows lines with an open-ended arrow “4”connecting a sub-concept to its subsuming super-concept.

UFO includes a taxonomy of universals (as shown in the left part of Fig-ure 2.1) and a taxonomy of individuals (as shown in the right part of Fig-

1In this paper, we use the term concept and category interchangeably

2.1 Unified Foundational Ontology 13

ure 2.1). An individual, i.e., an instance of Individual, is an specific entitythat exists in reality possessing a unique identity, while an universal, i.e., aninstance of Universal, represents a pattern of features that are repeatable in anumber of different individuals. For example, John is an individual that instan-tiates the universal Person. Since most distinctions made for universals alsoapply to individuals, which means most sub-concepts of Universal have theirIndividual counterparts (such as endurant, object, event, relator, disposition,situation), we focus on the introduction of individuals in the rest of this section.

An Endurant2 is an entity that exists in time while possessing a uniqueidentity and keeping its identity. An Event, conversely, extends in time whileaccumulating temporal parts. Especially, whenever an event is present, it is notthe case that all its constituent parts are present (e.g., the constituent parts of acar collision event can comprise “cars crash into each other” and “cars bounceoff”, which exist in a chronological order). Moreover, an event existentiallydepends on its participants in order to exist.

Endurant has several sub-concepts of great interest in this work, such asObject, Moment, Disposition, Relator, Situation, etc. An Object is an en-durant whose existence in time is existentially-independent of other endurants(e.g., a car is an object whose existence in time does not depend on others). AMoment, in contrast, is an endurant that inheres in another endurant(s) (e.g.,the kinetic energy of a train is existentially-dependent of a train). Momentsthat are existentially-dependent of one single endurant are instances of Intrin-sic Moment (e.g., the kinetic energy of a train), whereas a Relator, in con-trast, is existentially-dependent of a plurality of other endurants. A relationof mediation is defined between a relator and the endurants it depends on.(e.g., a being-crossing relator can mediate a person and a track). Dispositionis existentially-dependent of one single endurant. A disposition can only bemanifested by the occurrence of event(s) (e.g., the kinetic energy of a traincan only be manifested when a train is moving). The relation between a dispo-sition and the endurant it depends on is referred as characterize. A Situationis constituted by one or more endurants. A situation is considered here to besynonymous to what is named state of affairs, i.e., a portion of reality that canbe comprehended as a whole. Note that 1) a continuous repetitive behavior canbe regarded as a situation, such as “a train is moving” and, 2) if it is describedthat some event is supposed to occur but does not, then such description is re-garded as a generic situation that will not trigger the specific event, such as “thebrake command is not issued”. An exist in relation is defined between a situ-

2We will use “an endurant” or “an Endurant” interchangeably to represent, an instance of theEndurant concept. It also applies for other concepts.


ation and its constituent endurants. For example, in the situation “a passengertrain is approaching a person who is crossing the track”, there exist three ob-jects (i.e., a train, a person, a track), two relators (i.e., being-approaching andbeing-crossing), and the kinetic energy dispositions that characterize a personand a train, respectively.

Two foundational causal relations are defined between events and situa-tions in the UFO, i.e., a situation can trigger events and then an event willbring about another situation. The idea behind the causal relations is:

• The occurrence of an event is the manifestation of a collection of disposi-tions existing in a situation. For instance, then “a train enters a temporaryspeed restriction area” event is the manifestation of the “kinetic energy”disposition of the train and the “boundary” disposition of the temporaryspeed restriction area.

• An event may change reality by changing the state of affairs from one sit-uation to another situation. For example, the “a train enters a temporaryspeed restriction area” event will change the reality from the situation “atrain is running on the track at a high speed” to the situation “a train isrunning on the track where it should slow down”.

Different from other foundational ontologies, UFO defined two concepts todescribe the rigidity of objects. Kind denotes those objects with rigidity, i.e.,a kind object is necessarily a kind object in every possible situation, and non-rigid objects are defined as Role. For instance, a person is necessarily a personduring his/her existence, and a driver is no longer a driver after he/she has leftthe car. Therefore, a person is a kind object and a driver is a role object. Arelation of “play” is defined between a kind object and the role objects theycan instantiate, such as “a person” can play the role “a driver”.

2.2 Hazard Triangle ModelTo perform hazard analysis, two kinds of knowledge are typically required,i.e., design knowledge and hazard knowledge. Design knowledge consists of abasic understanding of the system, system boundaries, interfaces, functionali-ties, and a list of major components. Hazard knowledge incorporates not onlya set of hazard checklists that can practically inspire analysts to identify poten-tial hazards, but also a shared hazard conceptualization that can assist analystsin analyzing and documenting identified hazards. The Hazard Triangle Model

2.2 Hazard Triangle Model 15

(HTM) [24] provides an informal yet typical conceptualization of hazard, asshown in Figure 2.2. It illustrates that a hazard is an entity that is composed of

Figure 2.2: Hazard Triangle Model [24].

three necessary and coupled components: hazard source, initiating mechanism(causes), and target/threat outcome (consequences), each of which forms theside of a triangle. Hazard Source is the rudimentary component of a hazard.It creates the potential hazardous impetus for the hazard to exist, which aregenerally energy sources or safety critical functions, for instance, electricity,fuel, gas, aircraft velocity, etc. Initiating Mechanism represents the initiatorevents that cause transformation of the hazard from a dormant state to an activemishap state, e.g., hardware failure, human errors, etc. Hazard Target/ThreatOutcome is the resulting severity outcome after the hazard is transformed to anactive mishap state, such as injury of people, loss of the system, and damage tothe environment. As claimed in [24], all three sides of the hazard triangle areessential and required in order for a hazard to exist. By removing any one ofthe triangle sides, the hazard will be eliminated because it is no longer able totrigger an accident. Also, by reducing the possibility of any of the componentsof the triangle the mishap possibility is reduced. When all the componentscomprising a hazard are in alignment, the hazard are highly probable to tran-sition from a dormant state to an active mishap state. Since its proposal, theHTM has received considerable attention, and served as a conceptualization intypical hazard analyses to guide the identification of potential hazards.

However, in our experience, this informal interpretation of hazards has sev-eral deficiencies:

• Deficiency 1: It lacks a real-world semantics for the concepts within theHTM, i.e., what are the foundational categories that HTM concepts can


be categorized into? Take the hazard source as an illustration. A haz-ard source can be e.g., electricity, fuel, gas, or aircraft velocity, etc. Thefirst three sources refer to an amount of matter, respectively, whereasthe last one refers to a quality. Apparently, this superfluous inconsis-tency could cause confusions for stakeholders when either performingthe hazard analysis or examining the hazard analysis results throughoutthe development process.

• Deficiency 2: There are no clear definitions on the relations among theseconcepts, without which the interpretation would sacrifice its precisenessand cause ambiguities. For instance, it is not clear whether the hazardsource and threat outcome will participate in the initiating mechanismevent or not.

• Deficiency 3: The HTM is oversimplified to capture various factors thatlead to an accident. For example, “Insufficient fire fighting capability” isa typical hazard description. Taking a closer look at this hazard, it willbe noticed that it can hardly be categorized into 1) initiating mechanism,since it is describing a static situation rather than an event and, 2) hazardsource, since it will do no harm by itself and, 3) threat outcome, sinceit is not necessarily caused by an accident. However, this descriptionis typically regarded as a potential hazard, in that, it is likely to play asignificant role in leading to serious fire accidents.

To solve these deficiencies, we propose an ontological interpretation of thehazard concept, i.e., the Hazard Ontology, in this thesis. It includes a set ofhazard related concepts and takes foundational concepts into account.

2.3 Hazard Analysis TechniquesTo ensure system safety, hazard analysis in accordance with the system devel-opment life-cycle is necessary. Hazard analysis consists of various activitiessuch as hazard identification, causes identification, etc. There have been sev-eral pieces of work that propose techniques to discover potential hazards andtheir associated causes involving the system under analysis in early stages ofthe system development life-cycle [34].

Fault Tree analysis (FTA) [24] has been widely accepted in industry as atechnique for hazard identification in the PHA. In the light of FTA, high levelsystem faults or failures are attributed as the major causes of system accidents,

2.3 Hazard Analysis Techniques 17

and refined into low level sub-system faults or failures to guide the definitionof mitigation mechanism.

Unlike FTA, Failure Modes and Effect Analysis (FMEA) [24] is an induc-tive process that starts with a basic sub-system failure or fault, and then theanalyst reasons about this failure’s effect on the overall system behavior andidentifies the potential hazards. Furthermore, FMEA only considers failures,and hence does not usually consider operating procedures, human factors, andtransient conditions, when it is used for the purpose of hazard analysis.

Hazard and Operational analysis (HAZOP) is a structured and systematictechnique for examining the system under development, with the objective ofidentifying hazards and potential operability problems of the system [35]. Themain idea behind the HAZOP method is to analyze potential deviations fromthe system intents, with the help of a set of selected guide-words. The selectedguide-words could be different among different domains. Nonetheless, all thetechniques mentioned above have assumed that there should exist a basic de-sign, i.e., the design decision of the system architecture and components havebeen made, at the outset of hazard analysis. Different from the aforementionedtechniques, basic design of the system under analysis is not required by ourapproach. Our approach can take various system descriptions as initial inputs,such as functional requirements, use cases, etc.

Systems-Theoretic Early Concept Analysis (STECA) [9] is a recent haz-ard analysis technique that is based on control theory, hierarchy theory, andSystems-Theoretic Accident Model and Processes (STAMP) [8]. STAMP isan extension of traditional causality models, which aims to capture more typesof accident causal factors (such as abnormal interaction between components)than traditional methods (which usually treat hazards as a component failureproblem). The only required input for STECA is the Concept of Operations(ConOps) document that includes a statement of the goals and objectives ofthe system; strategies, tactics, policies, and constraints affecting the system;organizations, activities, and interactions among participants and operators;operational processes for fielding the system [36]. STECA defines the sys-tem operational behaviors using four kinds of elements, in terms of controller,sensor, actuator, and controlled process, and the basic elements are organizedin a hierarchical way. Hazards can be discovered by analyzing either the ab-normal behaviors of the elements or the unsafe interaction between differentelements. The main drawback of STECA lies in that it is difficult for STECAto discover hazards that are not related with behaviors, for example, peopleare exposed to toxic material. Our approach is based on conceptualizations ofhazards and thereby it is not limited to identify hazards that are related with


behaviors.There are also examples of adaptations of the aforementioned hazard analy-

sis techniques for identifying hazards [37] [38]. In [26], Guiochet et al. proposea hazard analysis technique called HAZOP-UML. The HAZOP-UML takesdifferent UML diagrams as input. It pre-defines a list of guide-words. By ap-plying different guide-words on every attribute of each entry in the UML dia-grams, the analysts can identify a set of deviations. Each deviation is regardedas a potential hazard that can lead to a harmful event. Daramola et al. [39]present a framework and tool prototype that facilitates the early identificationof potential system hazards. A HAZOP ontology is defined in the framework,which consists of types of study node, description, guide-words, deviations,causes, consequences, risk level, safeguards, and recommendation. Vargas etal. [21] propose an ontology-based approach to hazard identification within thepreliminary hazard analysis worksheet by utilizing the reasoning capability ofontologies. Their main objectives are to discover potential hazards based on ex-isting PHA results. Wang et al. [40] put forward an adaptation of STPA basedon formalization model, called BFM-STPA, to explore the causes of identifiedhazards. The Ontological Hazard Analysis (OHA) [41] is a refinement-basedapproach that is proposed by Ladkin for the analysis and maintenance of safetyhazard lists.

2.4 Safety Requirements Elicitation

In our work, safety requirements are the safety mechanisms that are defined tomitigate or address potential hazards. Much effort has been devoted into theproblem of safety requirements elicitation. In particular, several publicationsaddress the elicitation problem according to the result of Fault Tree Analysis(FTA). Hansen et al. [42] propose a FTA-based approach to derive safety re-quirements. The safety requirements prescribe what the system is required tosatisfy in order to avoid the occurrence of failure. Martins et al. [43] claimthat merely FTA is not sufficient to specify safety requirements. Therefore, itis necessary to provide more information to derive requirements, such as en-vironmental conditions. They present a protocol to derive functional safetyrequirements from FTA. The main idea is that FTA provides a way to figureout under which environmental condition a system transits to an unsafe state.This knowledge is then used to define how the system should or should notbehave to avoid such unsafe state. Gorski et al. [44] extend the FTA resultsby adding time properties to the events in order to define safety requirements

2.4 Safety Requirements Elicitation 19

suitable for real-time systems. Vyas et al. [45] propose an approach to deriverequirements, consisting of performing FTA, formalising the results of FTA,calculating the minimal cut sets with time analysis, and deriving mitigationrequirements (negation of the minimal cut sets.).

Other hazard analysis techniques are also used to derive safety require-ments, such as Hazard and Operability Study (HAZOP) and Failure Mode andEffects Analysis (FMEA). Allenby et al. [46] propose a sub-set of HAZOPguide-words, and apply such words on Use Case scenarios to identify the de-viation from design intent and thus identify requirements. Goddard [47] usePetri-nets to model the system and possible failures, and then perform FailureMode Effect Analysis (FMEA) to identify the flaws in safety requirements.

All the aforementioned pieces of work agree upon the insight that safetyanalysis techniques “provide the mechanism for identification of the safety re-lated requirements” [46], since the knowledge about how a system is involvedin a hazard is essential to define countermeasures to prevent or mitigate nega-tive effects. Meanwhile, these pieces of work show that the information pro-vided by hazard identification and causes analysis rather than requirementselicitation methods, is not complete to elicit safety requirements. In addition,the information for these safety requirements elicitation techniques that canbe extracted from safety analysis primarily concerns the identification of fail-ure cases. However, Tiadjo et al. [48] study several common safety analysistechniques for the elicitation of safety requirements for Ambient Assisted Liv-ing (AAL) systems. Their study shows that the most of these techniques cannotsupport requirements specific to these systems, e.g., lack of context-awareness.Another example of information needed for safety requirements but missing inFTA is the relationships among events. From a safety requirements perspec-tive, it is important to know if these events must occur chronologically andtheir durations [44].

Our work shares, with the above cited works, the assumption that safetyrequirements elicitation shall be based on the hazard knowledge that the safetyanalysis techniques provide. However, our approach differs mainly for thereason that it is independent of any particular safety analysis technique. Itrelies on the knowledge of certain hazards which is obtained by applying theHazard Ontology to formalize those hazards.

Chapter 3

An Ontological Approach toSafety Analysis

In this chapter, we summarize the papers collected in the thesis and introduceour main contributions in a unified and consistent way. In Section 3.1, webriefly describe a robotic strolling system that is used as a running example toillustrate our approach. Section 3.2 elaborates the Hazard Ontology that is aninterpretation of the hazard concept. Section 3.3 presents the Hazard ModelingLanguage that can be used to formalize natural language hazard descriptions(NLHDs). In Section 3.4, we introduce the ontological approach to identify po-tential hazards and associated causes. Section 3.5 gives an introduction on theapproach to elicit safety requirements. Section 3.6 summarizes the evaluationof our approach and provide some of our considerations.

3.1 Description of the Robotic Strolling SystemThe robotic strolling system [26] aims to help partially-disabled persons tostand up, stroll and sit down, when medical care staff is not available. The sys-tem consists of a wheeled base and a moving handlebar, as shown in Figure 3.1.The robotic strolling system is also equipped with several sensors to detectphysiological parameters and the posture of patients. When an abnormality oc-curs, it will raise an alarm to inform the medical care staff. It is designed to beable to move autonomously and navigate itself to the patients when it is called.The preliminary design of the robot is described by 11 use cases. We use the

21

22 Chapter 3. An Ontological Approach to Safety Analysis

“Standing up operation” use case, labeled as UC01, to illustrate our approachas a running example. The description of UC01 is shown in Figure 3.2. Note

Figure 3.1: The first prototype of the robotic strolling system [26].

Figure 3.2: UC01: Standing Up Operation [26]

that use case is one form of system functional requirements, and our approachcan also be applied on other types of system functional requirements, such asconcept of operation documents, etc.

3.2 The Hazard Ontology 23

3.2 The Hazard OntologyThe Hazard Ontology (HO) provides the analysts with a UFO-consistent per-spective to explain the hazard-related concepts and relations. Figure 3.3 depictsthe proposed Hazard Ontology (HO) using UML diagrams. Please refer to Pa-per A to find more details.

Figure 3.3: The UML diagrams of the Hazard Ontology. Concepts are repre-sented as rectangles. Proposed concepts are colored in gray, and UFO conceptsare colored in white. Typed relations are represented by lines with a readingdirection pointed by “I”, from open end to aggregated end. Cardinality con-straints are labeled on each end of typed relations. Subsumption constraints arerepresented by lines with an open-ended arrow “4” connecting a sub-conceptto its subsuming super-concept. InstanceOf axiom, labeled as insOf, specifiesthat one concept is an instance of the other concept.

The main idea behind the HO is in line with some widely accepted defini-tions of hazards in the context of SCSs [8] [18], that is, a hazard is supposedto be characterized by two essential features. On one hand, the nature of ahazard is a set of states, which motivates the interpretation that Hazard is atype of Situation. On the other hand, the states are likely to lead to severe con-sequences, which is interpreted into the modeling decision that Hazard cantrigger Mishap. A mishap is an accidental event that will consequently causeinjuries to people, damage to the environment or significant financial losses.


Inspired by the first idea behind the causal relations, the essential constituentparts existing in a hazard consist of mishap victims, harm truthmakers, haz-ard elements, and exposures. Harm TruthMaker represents the harmful orcritical dispositions in a hazard. When such harm truthmakers are manifested,mishaps are likely to occur. Hazard Element denotes the role objects thatbear the harm truthmaker dispositions. These roles can be played by variouskind objects. Mishap Victim is a sub-concept of Hazard Element. A mishapvictim denotes a role object that is not supposed to but have the potential toencounter with damages or injuries. Exposure represents the relations throughwhich victim(s) will be exposed to harms posed by hazard elements.

According to the foundational casual relations “bring about” and “trigger”between events and situations, we define that a hazard can be brought about byat least one initiating event. An initiating event, i.e., an instance of InitiatingEvent, is an undesirable or unexpected event that can bring about a hazard sit-uation. Initiating Condition is defined to capture the knowledge that are ofimportance to understand how the initiating events are triggered. An initiatingcondition, i.e., an instance of Initiating Condition, is a situation that com-prises the necessary constituent parts to trigger initiating events. Furthermore,Initiator Factor and Initiating Role represent the dispositions and roles, re-spectively, which are necessary constituent parts of an initiating condition totrigger initiating events. An environment object, i.e., an instance of Environ-ment Object, is a kind object that can play different roles in a hazard or initi-ating condition. The cause relation implies that a pre-initiating event can bringabout an initiating condition which will trigger another post-initiating event tobring about a hazard.

3.3 A Hazard Modeling Language

A core benefit of understanding the ontological foundation of hazards is that itprovides a basis for designing a hazard modeling language (HML) [49]. TheHML is a textual language. Its syntax and semantics are based on the Haz-ard Ontology. Comparing graphical language such as UML diagrams, textuallanguage provides a concise way to describe hazards, which makes it moreefficient for analysts to document their idea as well as ease the communica-tion between analysts and developers during a brainstorm session. In addi-tion, the HML provides a structured way to describe what elements a hazardconsists of and how different elements contribute to a hazard and subsequentaccidents. All the symbols are clearly defined in accordance to the Hazard On-

3.3 A Hazard Modeling Language 25

tology. Therefore, it can reduce the ambiguities which are caused by differentunderstandings of the hazard concept. Furthermore, a practical transformationapproach is proposed as well. Please refer to Paper B to find more details.

The syntax of the HML is given in Figure 3.4 using Extended-BNF [50]1.

Figure 3.4: The syntax of the proposed hazard modeling language.

We begin with the definition of Hazard (line 1), which consists of a manda-tory part HazardName and three optional parts, as shown in line 1. Hazard-Name is a group of terminals, which assigns the hazard with a unique nameor number. The first optional part defines that there could be more than oneInitiatingEvent that bring about the hazard, and the “bring about” relation isrepresented by the terminal “–>”. Moreover, the second optional part indicatesthat each hazard can be expanded by defining its HazardBody, to be introducedlater. The terminal “=>” in the last optional part represents the “trigger” re-lation defined in the HO. In particular, each hazard can trigger more than oneMishap (line 2), which is composed of MishapName (which is a group ofterminals) and MishapVictim (which will be introduced later). Note that themotivation behind the optional and mandatory definition is two-fold: On onehand, the modeling language is able to provide constructs to fully support thehazard conceptualization defined in the Hazard Ontology. On the other hand, it

1We use “()”to group characters, “?” to represent optional character, “*” to represent empty orrepetitive characters, and “|” to represent alternatives. Nonterminals are in italics, and terminalsare quoted or derived from “...Name” nonterminals.


supports partial specification in practice, which enables the HML specificationbeing developed in an iterative way.

Each InitiatingEvent (line 3) can be represented by an InitiatingEvent-Name, and it has two optional parts that, one of which defines the Initiating-Condition triggering this event and the other defines several EventParticipants.Further, EventParticipant (line 4), wrapped with a pair of “(” and “)”, denotesa role object which participates in the initiating event. An event participantcan be played by a kind object called EnvObj. InitiatingCondition (line 5)defines a group of terminals, labeled as InitiatingConditionName, to specifythe initiating condition that triggers the initiating event. Similar to a hazard,an initiating condition situation can be expanded by defining initiating roles.An InitiatingRole (line 6) is wrapped with a pair of terminals, i.e., “<<” and“>>”. The terminal “:” is defined to represent the “play” relation between arole object and the corresponding kind object, e.g., “<<CollisionParticipant:Car>>” represents a car is playing the role of collision participants. “Initiator-Factor” (line 7) is defined as a group of terminals, i.e., InitiatorFactorName,wrapped with a pair of “<” and “>”. As a disposition, an initiator factor canhave an optional value, for example, “<Toxicity: High>” means the level oftoxicity of a certain material is high.

HazardBody (line 8) consists of two parts. The ExposureRelName de-notes the exposure relation between related ExposureRelRoles. An Exposur-eRelRole (line 09) can be a HazardElement, a MishapVictim, or other roleswhich exist in a hazard. HazardElement (line 10) is comprised of three parts,wrapped with a pair of “(” and “)”. HazardElementName is a group of ter-minals, which labels the hazard element. Similar to InitiatingRole, as a roleconcept, the hazard element role can be played by an EnvObj entity, and canbe characterized by more than one HarmTruthMaker. HarmTruthMaker (line11) is defined as a group of terminals (labeled as HarmTruthMakerName),wrapped with a pair of “<” and “>”. Similarly, as a disposition, a harmtruth-maker can have an optional value. MishapVictim (line 12) is defined as a groupof terminals, labeled as MishapVictimName, and it is wrapped with a pair of“(” and “)”. Meanwhile, a mishap victim role can be played by an EnvObjentity.

An EnvObj (line 13) can be the name of a kind object, a “DEFAULT”terminal, the negation of an EnvObj, the conjunction or union of EnvObjs.Especially, “DEFAULT” implies there are certain kind objects that can playthe corresponding roles, but not known for sure during the hazard modelingstages, e.g., “(HotParts: DEFAULT)” means there are certain environmentobjects are hot parts. The terminals “NOT”, “ ∨”, and “∧” applied to EnvObj

3.4 The Ontological Approach to Hazard and Causes Identification27

are standard set operations.

3.4 The Ontological Approach to Hazard andCauses Identification

In this section, we introduce the ontological approach to identify potential haz-ards and associated causes. Please refer to Paper C and Paper D to find moredetails.

3.4.1 Step 3.4.1: System Description FormalizationThe first step is to formalize a system description from natural language intoHO-style models. In this step, the analysts will identify the objects describedby the system description and clarify the relations between the objects in ac-cordance to the system description and their expertise. The aim of this step isto achieve a clear understanding of the system from a real-world perspective.The formalization can be conducted by going through the following steps:

• SDF-Step 1: Identify the kind and role objects explicitly presented inthe system description.

• SDF-Step 2: For each kind object obtained in SDF-Step 1, identify allthe roles it can play, considering the system description.

• SDF-Step 3: For each role object obtained in SDF-Step 1 and SDF-Step 2, identify the relator that connects this role, and specify all theother roles connected by the identified relator, considering the systemdescription and the analysts’ expertise.

• SDF-Step 4: For each role object obtained in SDF-Step 1, SDF-Step2 and SDF-Step 3, identify all the kind objects that can play the role,considering the system description.

We use the UC01, as illustrated in Section 3.1, to further illustrate this step.We can identify Robot, Robot Handle, Battery, Patient as kind objects accord-ing to the description. The Patient can play two roles BeingSupported andBeingLifted. The Robot Handle can play two roles BalanceSupporter and Ob-jectLifter. The Robot can play the ElectricityConsumer role, and the Batterycan play the ElectricitySource role. The BalanceSupport, LiftUp, and Electric-ityConsumption relators can be further identified. The BalanceSupport relator


connects the BalanceSupporter and BeingSupported roles, played by Robotand Patient respectively. The LiftUp relator connects the ObjectLifter and Be-ingLifted roles, played by Robot Handle and Patient respectively. The Elec-tricityConsumption relator connects the ElectricitySource and ElectricityCon-sumer roles, played by Battery and Robot respectively. After performing theSDF-Step 1 to SDF-Step 4, we shall obtain the formalized description for theUC01, as shown in Figure 3.5.

Figure 3.5: The formalized description for the UC01 “Standing Up Operation”.Kind objects are colored in purple, role objects are colored in gray, and relatorsare in white.

3.4.2 Step 3.4.2: Mishap Victim Identification

Since the occurrence of a mishap event must have more than one mishap victimto participate in the event, this step identifies all the possible mishap victimsfrom the HO-style model obtained in Step 3.4.1. Furthermore, the analystscontinue with brainstorming possible harms that can threaten the victims, in-cluding but not limited to, physical damages, chemical injuries, fatal illness,explosion, etc.

Take the UC01 as an example. The possible mishap victims are BeingLiftedat the risk of physical damage (e.g., falling down on the ground, colliding withother obstacles), BeingSupported at the risk of physical damage (e.g., falling


down on the ground), and ElectricityConsumer at the risk of explosion andelectric shock.

3.4.3 Step 3.4.3: Hazard PopulationThis step brainstorms hazardous situations that are likely to harm the identi-fied mishap victims, in accordance to the concepts and relations defined in theHazard Ontology.

According to the HO, the occurrence of a mishap is the manifestation ofthe harm truthmaker dispositions that characterize the hazard element roles ina hazardous situation. The following steps can be taken to populate the possiblehazardous situations based on the HO-style model from the Step 3.4.1 and theidentified mishap victims together with the possible harms from the Step 3.4.2:

• HP-Step 1: Select one mishap victim from the identified mishap victimsfrom the Step 3.4.2.

• HP-Step 2: Identify the environment object playing the selected mishapvictim, the relator connecting the selected mishap victim and the rolesthat are connected by the identified relator, according to the HO-stylemodel from the Step 3.4.1.

• HP-Step 3: For each role identified in the HP-Step 2, explore the pos-sible dispositions that characterize this role. When such possible dis-positions are manifested, a mishap that can cause harms is likely to betriggered. Furthermore, the role will be identified as Hazard Element,the dispositions as Harm TruthMaker, and the relators connecting thehazard elements as Exposure.

• HP-Step 4: For each hazard element identified in HP-Step 3, explorethe possible kind object that can play the hazard element role. The kindobject will be identified as Environment Object.

• HP-Step 5: If not all of the mishap victims are analyzed, then select anew mishap victim and go back to HP-Step 2.

Continue with the UC01 to illustrate this step. Note that we have identifiedthree mishap victims along with the harms they are likely to encounter. Start-ing with the Being Supported mishap victim, we can identify in HP-Step 2that the possible environment object playing the mishap victim is Patient. Theidentified exposure relator is BalanceSupport. The connected role are Being


Table 3.1: The identified hazards for the UC01 “Standing Up Operation”.

Supported and Balance Supporter. In HP-Step 3 and HP-Step 4, by goingthrough the connected roles, we can identify the possible harm truthmaker dis-positions and environment objects. The identified hazards with respect to theBeing Supported mishap victim are shown by H1 and H2 in Table 3.12. Thehazard descriptions from H3 to H8 show the identified hazards with respect tothe other two mishap victims.

3.4.4 Step 3.4.4: Causes ExplorationThe system description obtained from Step 3.4.1 together with the populatedhazard description obtained from Step 3.4.3 (labeled as SDPHD) provide ananalysis basis for the identification of causes. According to the HO, a situationis brought about by events. So the causes exploration for a hazard is aboutidentifying the possible pre-initiating events. The following steps can be takento explore the pre-initiating events for the SDPHD:

• CE-Step 1: For each hazard element of the SDPHD, explore and identifythe corresponding kind object that can play this role. Then, the pre-initiating event that makes the kind object play the hazard element roleor have the harmtruthmaker disposition can be considered as a candidatefor the causes of the hazard.

2Each row in the table denotes a HML-style hazard. Meanwhile, each HO hazard is interpretedinto natural language as well, shown in the Natural Language Hazard Description column.


• CE-Step 2: For each harm truthmaker of the SDPHD, explore the com-ponents of the corresponding kind object. Such components will enablethe disposition of the kind object. Then, the pre-initiating event that im-pacts the components will be a candidate for the causes of the hazard.

• CE-Step 3: For each exposure of the SDPHD, the pre-initiating eventthat brings about the relator will be a candidate for the causes of thehazard.

Take the hazard H1 as an example, which describes a specific hazardous situa-tion that will trigger a falling accident, i.e., “Unstable physical structure of therobot while supporting the patient”. Figure 3.6 shows the system descriptiontogether with the populated hazard description for H1. Therefore, we need to

Figure 3.6: The system description together with the populated hazard descrip-tion for H1. Environment Object objects are colored in purple, Hazard El-emment roles are colored in gray, Harm Truthmaker dispositions in pink andExposure relators are white.

explore all the possible pre-initiating events that can bring about the specifichazardous situation by going through the hazard element, harmtruthmakers,and exposures, respectively. Note that not all the CE steps can produce rea-sonable causes. The results are shown in Table 3.2. Among the results, thefirst three causes were identified in CE-Step 1, since these causes can make theRobot have the “Unstable physical structure” harmtruthmaker disposition. Thefourth cause was identified in CE-Step 2, since it was related with the inherentcomponents of the Robot.


Table 3.2: The identified causes of the hazard H1.

3.5 Safety Requirements Elicitation for HazardElimination

In accordance to the Hazard Ontology, safety requirements of a hazard shallbe elicited by reasoning on how to: 1) overcome the dispositions of a givenobject that are weaknesses, i.e., harmtruthmakers or initiator factors with re-spect to the hazard; 2) change, add or remove roles, i.e., hazard elements orinitiating roles played by the object with respect to the hazard; 3) cut off exist-ing relations in order to remove the connections among two or more objects,i.e., exposures with respect to the hazard. In the following sections, we brieflyintroduce each step and give an illustration in the end. Please refer to Paper Eto find more details.

3.5.1 SARE-ACT1: Overcome an object’s weakness

An object’s weakness is a disposition or property of the object. The objectis negatively susceptible to the enabling of such property in a certain situation,which implies that the object is likely not to behave as expected under the influ-ence of its weakness. Therefore, overcoming an object’s weakness implies thatwe need to find a way to eliminate the weakness or, if it is not possible, mitigateits negative effects. The way in which the object’s weakness is overcome canbe regarded as a candidate for the safety requirement to be elicited.

In order to perform SARE-ACT1, the analyst needs to know: a) whichis/are the object/s with weakness; b) for each identified object, which is/are itsweaknesses; c) for each identified object, which is its role. Moreover, due to thefact that objects’ properties and roles are strictly dependent on each other, theknowledge about the object’s role is a fundamental information to overcomeits weakness. The Hazard Ontology provides the analyst with these piecesof information through the entities Environment Object, Initiating Role andInitiating Factor, and Hazard Element and Harm TruthMaker.

3.5 Safety Requirements Elicitation for Hazard Elimination 33

3.5.2 SARE-ACT2: Change, add or remove an object’s roleA object’s role can be regarded as a task assigned to the object to accomplisha given function in a certain situation. To be able to act on an object’s role,it is necessary to understand how the object’s role can be hazardous when ac-complishing its task, i.e., why an object does not perform its task as expected.Once the hazardous objects’ roles are identified, the analyst can elicit the can-didate safety requirement/s by: 1) adding a new role for the hazardous object;2) changing the role of the hazardous object; 3) remove the current role of thehazardous object; 4) define a new role for a new or an existing object.

In order to perform SARE-ACT2, the analyst needs to know: 1) whichis/are the object/s whose role can be hazardous; 2) for each identified object,which is/are its weakness. Due to the fact that objects’ properties and roles arestrictly dependent on each other, the knowledge about the object’s weaknessis necessary to reason about roles. The Hazard Ontology provides the ana-lyst with these pieces of information through the entities Environment Ob-ject, Initiating Role and Initiating Factor, and Hazard Element and HarmTruthMaker.

3.5.3 SARE-ACT3: Cut off existing relationsAccording to the Hazard Ontology, two kinds of relations among objects are ofgreat interest for safety requirements elicitation:

• The relation between objects with weaknesses and other objects, i.e., theExposure relation. In fact, this relation describes how an object withweakness becomes a victim in a hazard, and how objects are connectedto trigger mishaps.

• The “bring about” relation between initiating events and hazards. Aninitiating event which happens in a specific situation (i.e., initiating con-dition) is the cause for a hazard to exist.

Removing the exposure relation implies that the hazard cannot triggermishaps to harm anymore the victim. As a consequence, the hazard will beeliminated. On the other hand, cutting off the “bring about” relation meansthat the initiating event does not end up into a hazard, i.e., the hazard willnot exist. The solution that is proposed to remove the above relations can beregarded as a candidate for safety requirements to be elicited.

In case of the exposure relation, the analyst needs to know: 1) which arethe objects that can participate to the exposure relation; 2) for each identi-


fied object, which is its weakness. The Hazard Ontology provides the ana-lyst with these pieces of information through the entities Exposure, HazardElement, Harm TruthMaker and Mishap Victim. In particular, the HarmTruthmaker represents the object’s weakness that makes the object become aharmful element with respect to the hazard.

In case of the “bring about” relation, the initiating events identified duringthe hazard causes identification should be avoided. The analyst needs to know:1) which is the event that ends-up in a hazard; 2) in which situation this eventhappens; 3) which is the hazard. The Hazard Ontology provides the analystwith these pieces of information through the entities Initiating Event, Initiat-ing Condition, Initiating Role, and Initiator Factor. Once the relations andtheir components are identified, the analyst can elicit the appropriate safetyrequirements.

3.5.4 Illustration for safety requirements elicitation

The system description together with the populated hazard description of H1,as shown in Figure 3.6, provides an analysis basis to conduct the proposedsafety requirements elicitation steps. Note that not all the elicitation steps canproduce reasonable safety requirements. For the H1, the safety requirementselicitation can result in the following set of safety requirements:

• To overcome the robot’s weakness “Unstable physical structure”: Req1“The physical structure of the robot shall bear 300kg weight”.

• To cut-off the “bring about relation: Req2 “The robot provides redun-dant power source or the robot will safely stop working when the batterylevel drops below 10%”; Req3 “When the robot is stuck during lifting,it can safely return to the previous state.”; Req4 “Maintenance is per-formed periodically.”; Req5 “Quality inspection shall be required beforecome into the market.”

3.6 Discussion of Evaluation

This thesis mainly consists of five pieces of work, in terms of the Hazard Ontol-ogy in Paper A, a hazard modeling language in Paper B, hazard identificationin Paper C, causes analysis in Paper D, and safety requirements elicitation inPaper E. Each work has been evaluated separately and presented in the cor-

3.6 Discussion of Evaluation 35

responding paper. In this section, we summarize and discuss the evaluationresults.

3.6.1 Summary of evaluation resultsWe used the Hazard Ontology to categorize the hazard analysis results from anindustrial passenger train project in Paper A. The hazard analysis results in-corporated 45 hazard descriptions. We observed several interesting findings: 1)The analysts occasionally regarded a mishap as a hazard. Thus, more informa-tion on how to avoid such mishap was missing in the hazard analysis results.2) The analysts occasionally merely identified harm truthmakers and hazardelements, but missed exposures, victims, and the kind objects that played theidentified roles. These generic hazards provided little information for guidingsafety requirements elicitation. 3) The analysts occasionally merely identifiedinitiating event/condition, but missed hazards. The missing information wouldbe very useful for facilitating the reuse of analysis results. 4) Patterns behinddifferent hazard descriptions were revealed.

As a complement to the Hazard Ontology, a hazard modeling languagewas proposed. Its syntax and semantics are based on the Hazard Ontology. Toevaluate the language, an approach to transform from natural language hazarddescriptions to the hazard modeling language models was proposed in PaperB. Examples were used to illustrate the approach and showed the usefulness ofour approach.

The ontological approach to hazard identification were evaluated in Pa-per C by applying it on use cases of a robotic strolling system. The re-sults produced by our approach were compared with those by HAZOP-UMLmethod [26]. From the comparison, we noticed that 1) our approach identi-fied more types of hazards than the HAZOP-UML in this case. 2) the haz-ards identified by our approach in this case provided more guidance informa-tion for subsequent risk reduction activities. 3) the hazards identified by ourapproach explicitly considered environmental factors that were important forvarious stakeholders to understand the hazards.

The ontological approach to causes identification were evaluated in PaperD by applying it on the Temporary Speed Restriction application scenario. Wemade a comparison between our results and the results presented in [40]. Weobserved that: 1) the causes identified by our approach were a superset of thosein [40]. 2) our approach could provide more details of causes.

To show the usefulness of our approach in Paper E, the safety requirementselicitation approach were applied on an application scenario of a train control


system (TCS). We explored possible weaknesses of the objects of the TCS,added new roles to the TCS, and cut off relations between the objects of theTCS. As a result, four safety requirements were elicited to eliminate identifiedhazards.

3.6.2 Thoughts about evaluationThe ontological approach to safety analysis is a novel approach to performsafety analysis. By the end of the thesis writing, we have conducted prelimi-nary evaluations of each step of the approach. The evaluations showed promis-ing results, in terms of the usefulness of our approach. However, these stepshave not been fully evaluated as a holistic approach using industrial cases. Themost significant obstacle lessening the industrial strength of our approach isthe lack of a tool that can fully support the ontological approach to safety anal-ysis. The tool will require several functions, including facilitating ontologyconstruction, checking constraints of constructed ontologies, storing patternsof identified hazards and causes, and providing a mechanism of pattern reuse.We are currently working on tool development, and continuing work on anindustrial case consisting of autonomous vehicles to provide evidence of theindustrial strength of our approach.

Chapter 4

Research Overview

In this chapter, we present an overview of our research work in Section 4.1, andintroduce the research methodology employed by this thesis in Section 4.2.

4.1 Questions, Challenges and ContributionsIn this thesis, we answer to the general research question as follow:

• General research question: How can safety analysis, within the contextof safety-critical systems, be conducted to reduce the omission of poten-tial hazards and their causes in early stages of the system developmentlife-cycle?

In particular, since the elicitation of safety requirements is highly dependent ofhazard analysis, the general research question can be further refined into fourspecific research questions which guided our research work. Table 4.1 presentsthe relations between our research questions and papers.

4.1.1 Research Question One (RQ1)How can we conceptualize hazards from the real-world semantics perspec-tive to improve the understanding of the hazard concept, within the contextof safety-critical systems?

• Challenges associated with RQ1 (CH1): The concept of hazard hasbeen extensively used in the literature and defined in an informal way,

37

38 Chapter 4. Research Overview

Table 4.1: Relations between the included papers and research questions.Paper Research Current

Question StatePaper A, B RQ1 Published at ESREL’17

Published at SEAA’17Paper C RQ2 Published at ICRSE’17Paper D RQ3 Published at ICSRS’17Paper E RQ4 Published at APSEC’17

which serves as a guidance on identifying potential hazards during thedevelopment of safety-critical systems. Intuitively, these definitionsseem to be consistent and easy to understand. However, when we takea closer look at them, ambiguities may arise, e.g., whether a hazard isa particular system state, or is a combination of the system and envi-ronment states. Furthermore, these definitions suffer from a lack of theprecise definition of the term “condition” from the perspective of real-world semantics, i.e., the correspondence between the term “condition”and entities (e.g., object, relation, property, event, etc.) in the real world.Therefore, in practice, the identified hazards are usually formulated inan arbitrary way, in the sense of what are presented and how they arepresented. Last but not least, many terms are used to represent the causalrelation between “condition” and “accident”, such as “contribute to”,“cause”, and “lead to”. Although these terms are in line with people’sintuitive idea, there is still a need to add constraints to these relationsfrom the perspective of real-world semantics, i.e., to define what real-world entities can be connected when a causal relation is referred to, andto explain how the real-world entities together make the causal relationtrue.

• Our contribution to RQ1 (OC1): In Paper A, we propose an onto-logical interpretation of the hazard concept, called the Hazard Ontology(HO), to define an explicit representation of the knowledge of hazardsand their relations with the system under analysis and existing environ-ment. We employ the Unified Foundational Ontology (UFO) as the foun-dational ontology to provide the real-world semantics on the conceptsand relations that pertain to the HO. Furthermore, in Paper B, we pro-pose a hazard modeling language (HML) based on the Hazard Ontology

4.1 Questions, Challenges and Contributions 39

and an approach to transform from natural language hazard descriptionto the HML, to reduce ambiguities brought by natural language hazarddescriptions.

• Personal contribution to RQ1 (PC1): Jiale was the main author of Pa-per A and Paper B. He has been involved in all parts of the work, interms of research idea formulation, literature review, ontology construc-tion, ontology evaluation, and paper writing.

4.1.2 Research Question Two (RQ2)How can we improve the identification of potential hazards associated with thesafety-critical system under analysis, based on an improved understanding ofthe hazard concept?

• Challenges associated with RQ2 (CH2): The main drawbacks of cur-rent practices applied in the hazard identification, lie in that: 1) due tothe lack of a common understanding of the hazard concept, the hazardsare typically identified in accordance to the intuition and experience ofthe analysts [24], with the risk of missing environmental assumptionsand causing ambiguities in the recorded hazard descriptions [51] and, 2)since the hazard identification highly relies on the experience possessedby the analysts and the lessons obtained from previous systems develop-ment, there is a need to formalize these experiences in a structured waywhich can be reused to identify a more complete set of hazards [25] and,3) since traditional hazard identification techniques are usually based onwell-known system behaviors [26] represented by models, such as au-tomata and sequence diagrams, a new approach is needed when suchbehavioral models are not available in the early stages.

• Our contribution to RQ2 (OC2): In Paper C, we propose an ontologi-cal approach to identify hazards in early stages of the safety-critical sys-tems development. In general, the hazard identification approach con-sists of three steps: system description formalization that formalizes thesystem descriptions from natural language into the HO-style models and,mishap victim identification that identifies all the possible mishap vic-tims in the HO-style models and then brainstorms possible harms threat-ening the victims and, hazard population that brainstorms to identifyhazardous situations that can lead to the corresponding harms, in accor-dance to the concepts and relations defined in the HO.


• Personal contribution to RQ2 (PC2): Jiale was the main author of Pa-per C. He has been involved in all parts of the work, in terms of researchidea formulation, literature review, approach proposal and evaluation,and paper writing.

4.1.3 Research Question Three (RQ3)

How can we improve the identification of possible causes associated with acertain hazard, to make the results of hazard analysis more complete and useful,based on an improved understanding of the hazard concept?

• Challenges associated with RQ3 (CH3): The main drawbacks of cur-rent practices applied in the hazard causes identification, lie in that: 1)analysts are inclined to identify generic causes for a certain hazard de-scription, for example, “Design flaw, Coding error, and Human error”can be listed as possible hazard causes, but this type of generic informa-tion is not particularly useful for guiding the safety requirements elicita-tion [9] and, 2) since the hazard causes identification highly relies on theexperience possessed by the analysts and the lessons obtained from pre-vious projects/systems, there is a need to formalize these experiences ina proper way which can be reused to identify a more complete set of haz-ard causes as well as to save effort [25] and, 3) due to the lack of precisedefinition on causal relations, the causes of a certain hazard descriptionare typically identified in accordance to the intuition and experience ofthe analysts [24], with the risk of missing the rationale behind the iden-tified causes and the corresponding hazard description.

• Our contribution to RQ3 (OC3): In Paper D, we propose an onto-logical approach to identify the causes associated with a certain hazarddescription for safety-critical systems, aiming to improve the PHA interms of completeness and usefulness. After performing the PHA, a haz-ard description is selected as the initial input to our approach. In general,the causes identification approach consists of three main steps, in termsof Hazard Description Categorization that categorizes the selected haz-ard description in accordance to the Hazard Ontology, Hazard Descrip-tion Expansion that produces an expanded description for the catego-rized hazard description by correlating it with system descriptions, andCauses Exploration that analyzes the expanded description and exploresthe possible causes.

4.2 Research Methodology 41

• Personal contribution to RQ3 (PC3): Jiale was the main author of Pa-per D. He has been involved in all parts of the work, in terms of researchidea formulation, literature review, approach proposal and evaluation,and paper writing.

4.1.4 Research Question Four (RQ4)How can we utilize the understanding of the hazard concept to facilitate theelicitation of safety requirements of safety-critical systems?

• Challenges associated with RQ4 (CH4): Safety requirements are typ-ically identified based on a list of “categorized hazards and associatedsafety risk analysis” [52]. Safety requirements describe measure againstfailures. So the information issued from safety analysis, i.e., the knowl-edge about hazards and their components such as sources, causes andconsequences, is essential to elicit the appropriate safety requirementssince it describes how systems failures happen [53]. However, it is notalways easy to clearly identify the hazard components especially becausehazards could be expressed ambiguously and lack precise descriptions ofthe hazard causes, sources and outcomes. As a result, efforts done by thesafety team “are usually not integrated into the requirements specifica-tions, and this makes it difficult to ensure that the architecture incorpo-rates the appropriate safeguards” [52].

• Our contribution to RQ4 (OC4): We propose an ontological approach,which is independent of the particular safety analysis technique em-ployed, to discover the hazard components within the safety system andits application environment. More precisely, our approach suggests threesteps to be followed in order to elicit the safety requirements based on adeep understanding of the hazard-related concepts.

• Personal contribution to RQ4 (PC4): Jiale was a co-author of PaperE. He has been involved in several parts of the work, in terms of researchidea formulation, literature review, solution discussion and evaluation,and paper review.

4.2 Research MethodologyThe overarching goal of our research is to improve the safety requirements en-gineering, within the context of safety-critical systems. Our approach is based


Figure 4.1: The main research steps followed in this thesis.

on a domain ontology. Thus, our research interests will focus on the theoret-ical knowledge in the areas of domain ontology, hazard analysis, and safetyrequirements elicitation. In order to adequately address the questions listedabove, it is important to adopt an appropriate research methodology, suitablefor such a given setting. The methodology used in our research is based on theresearch steps proposed by Shaw [54], which is summarized in the followingsteps, and shown in Figure 4.1:

1. Formulating our general research question, based on the overarchinggoal of our research.

2. Conducting literature reviews to study the state of the art in the safetyrequirements engineering field.

3. Understanding the current research settings and deriving a specific re-

4.2 Research Methodology 43

search question from the research idea to guide our work.

4. Analyzing the state of the art in the safety requirements engineering fieldbased on the guiding research question.

5. Answering the research question by presenting the proposed solutionsand achieved research results.

6. Validating whether the research results can be applied in the real-worldapplications.

7. Formulating a new research idea through the experience gained fromour previous research, in order to further answer our general researchquestion.

In this work, after the general research question is formulated in Step 1, theplanned steps (2 - 7) are performed iteratively to conduct our research until thedesired results for our general research question are achieved.

Chapter 5

Conclusion and Future Work

5.1 ConclusionsSafety analysis are of paramount importance in the system development life cy-cle, ensuring the successful development of safety-critical systems. We sharethe insight with other pieces of work that early phase safety analysis is theground for safety requirements engineering. In this thesis, we have contributedto several safety analysis activities, in order to improve early phase safety anal-ysis, in terms of hazard conceptualization, hazard identification, hazard causesidentification, and safety requirements elicitation.

In particular, the main idea behind the Hazard Ontology (HO) presented inPaper A is that, a hazard represents a situation which comprises the necessaryentities to trigger mishaps, and further the hazard is brought about by someinitiating events. In addition, the HO takes the foundational categories into ac-count, by dint of being grounded in the Unified Foundational Ontology. In thisway, the HO is able to utilize the benefits offered by the foundational ontol-ogy, such as real-world semantics, ontology design patterns, and pre-definedrelations between foundational categories. Furthermore, a hazard modelinglanguage (HML) has been proposed in Paper B, aiming to provide a struc-tured and unambiguous hazard specification in a concise way. The HML canbe used to describe identified hazards. The semi-formal HML-style hazard de-scriptions can help to highlight information that are of paramount importancefor subsequent risk reduction activities and provide a potential to be recognizedby machines.

In Paper C, we have proposed an ontological approach to hazard identifi-

45

46 Chapter 5. Conclusion and Future Work

cation in early stages of the safety-critical systems development process. Themain idea is to use the HO to provide a consistent way to formalize the sys-tem descriptions and analysts’ expertise of hazards. The formalized HO-stylemodels can provide a basis for the identification of hazards. The approach con-sists of three steps, in terms of system description formalization to understandthe system and its environment, mishap victim identification to find possiblemishap victims, and hazard population to identify potential hazardous situa-tions.

Based on results from early phase hazard analysis technique, we have pro-posed an ontological approach to identify the causes of hazard in Paper D.The approach is to use the HO to provide a consistent way to formalize thesystem descriptions and analysts’ expertise of hazards. The formalized modelscan provide a basis for the identification of the causes associated with identi-fied hazards. The approach consists of three steps, in terms of hazard descrip-tions categorization to achieve a common understanding of the selected hazarddescription, hazard description expansion to formalize the knowledge of thesystem and analysts, and causes exploration to explore the possible causes ac-cording to the casual relations defined in the HO.

In Paper E, we have also described a heuristic approach to elicit safetyrequirements which assumes that the information needed to discover safetyrequirements must be searched among the hazard components and their rela-tionships, as suggested in the Hazard Ontology. The approach proposes a wayof reasoning that can be applied to elicit the safety requirements based on theidentified hazard descriptions.

5.2 Future Work

In our viewpoint, this thesis work has provided a framework to perform safetyanalysis in early stages of the safety-critical systems development life-cycle.Although this approach has not been fully evaluated, it provides a theoreticfoundation to formally understand the concept of hazard. In the subsequentresearch work of our project, one interesting work is to employ our approachto identify hazards and their causes, and then to elicit safety requirements fora construction plant consisting of a mix of both autonomous and manuallyoperated vehicles.

Currently, this thesis work mainly addresses the question on what is a haz-ard and how to identify hazards and their causes. Risk is also a very importanttopic of safety analysis. Based on this work, we can see a possibility that the

5.2 Future Work 47

analysts can assess the probability of a certain hazard by estimating either theprobability of the existence of its various components or the probability of theoccurrence of its initiating events. In accordance to the calculation of probabil-ity of various hazards, risk prioritization would be another piece of future workof great interest.

Furthermore, in order to facilitate the use of our safety analysis technique,tooling support is considered as an essential part of future work as well. Thetoolset can provide a graphical editor for users to analyze the components of acertain hazard. A repository can be built to store the results produced by safetyanalysis. By searching in the repository, the tool will give suggestions aboutpotential hazards and their causes of a safety-critical system.

Artificial Intelligence (AI) is becoming ever-more popular in recent years.How to combine AI techniques and safety analysis will be a very interestingtopic in the future. One possible direction is to apply AI techniques to rec-ognize objects and relations between the objects. The recognized objects andrelations are used as input to perform pattern matching in a repository of safetyanalysis results.

Bibliography

[1] ISO14971, Medical devices - Application of risk management to medicaldevices. International Standard Organisation, 2006.

[2] Engineering Safety Management: Yellow Book. Fundamentals and Guid-ance, issue 4. Railtrack PLC, 2007.

[3] DO160G, DO160G - Environmental Conditions and Test Procedures forAirborne Equipment. Radio Technical Commission for Aeronautics,2014.

[4] IEC61513, IEC 61513:2001 Nuclear power plants Instrumentation andcontrol for systems important to safety General requirements for systems.International Electrotechnical Commission, 2001.

[5] L. Chen, Y. Zhao, and T. Zhao, An AcciMap Analysis on the China-Yongwen Railway Accident. Springer International Publishing, 2015.

[6] R. M. Boisjoly, “Ethical Decisions Morton Thiokol and the Space ShuttleChallenger Disaster,” American Society of Mechanical Engineers AnnualMeeting, 1987.

[7] BBC, “Bhopal trial: Eight convicted over India gas disaster,” June 2010.

[8] N. G. Leveson, Engineering a Safer World: Systems Thinking Applied toSafety. The MIT Press, 2011.

[9] C. Fleming, Safety-driven Early Concept Analysis and Development.PhD thesis, 2015.

[10] I. Habli, “Model-Based Assurance of Safety-Critical Product Lines,” Uni-versity of York, 2009.

49

50 Bibliography

[11] N. G. Leveson, “Software Challenges In Achieving Space Safety,” Jour-nal of the British Interplanetary Society, vol. 62, 2009.

[12] ISO13849, “Safety of machinery - Safety-related parts of control sys-tems,” 2013.

[13] IEC62061, “Safety of machinery: Functional safety of electrical, elec-tronic and programmable electronic control systems,” 2012.

[14] “ISO/DIS 26262-1 - Road vehicles - Functional safety - Part 1 Glossary,”tech. rep., July 2009.

[15] EN-50129, “Railway applications. Communication, signalling and pro-cessing systems. Safety related electronic systems for signalling,” 2003.

[16] IEC61508, “Functional safety of electrical/electronic/programmableelectronic safety-related systems,” 2010.

[17] M. P. E. Heimdahl, “Safety and Software Intensive Systems: ChallengesOld and New,” in Proceedings of FOSE’07, pp. 137–152, May 2007.

[18] MIL-STD-882, DoD Standard Practice for System Safety, version D.2000.

[19] M. Perini Barcellos and R. de Almeida Falbo, “Using a Foundational On-tology for Reengineering a Software Enterprise Ontology,” in Proceed-ings of ER’09 Workshops, pp. 179–188, 2009.

[20] R. Winther and W. Marsh, “Hazards, accidents and events - a land of con-fusing terms,” in Safety, Reliability and Risk Analysis Beyond the Hori-zon, pp. 2545–2553, 2013.

[21] A. P. Vargas and R. Bloomfield, “Using Ontologies to Support Model-based Exploration of the Dependencies between Causes and Conse-quences of Hazards,” in Proceedings of KEOD’15,, pp. 316–327, 2015.

[22] A. Lawrynowicz and I. Lawniczak, “The Hazardous Situation OntologyDesign Pattern,” in Proceedings of WOP’15, 2015.

[23] M. A. Cheatham, H. Ferguson, C. Vardeman, and C. Shimizu, “A Modifi-cation to the Hazardous Situtation ODP to Support Risk Assessment andMitigation,” in Proceedings of WOP’16, 2016.

Bibliography 51

[24] C. A. Ericson, Hazard Analysis Techniques for System Safety. Wiley,2005.

[25] S. P. Smith and M. D. Harrison, “Measuring Reuse in Hazard Analysis,”Journal of Reliability Engineering & System Safety, vol. 89, no. 1, pp. 93–104, 2005.

[26] J. Guiochet, Q. A. D. Hoang, M. Kaaniche, and D. Powell, “Model-BasedSafety Analysis of Human-Robot Interactions: The MIRAS Walking As-sistance Robot,” in Proceedings of ICORR’13, pp. 1–7, June 2013.

[27] S. Farfeleder, T. Moser, and A. Krall, “Ontology-Driven Guidance for Re-quirements Elicitation,” in Proceedings of ESWC’11, pp. 212–226, 2011.

[28] G. Guizzardi, Ontological Foundations for Structural Conceptual Model.PhD thesis, 2005.

[29] R. Falbo, F. Baiao, M. Lopes, and G. Guizzardi, “The Role of Founda-tional Ontologies for Domain Ontology Engineering: An Industrial CaseStudy in the Domain of Oil and Gas Exploration and Production,” In-ternational Journal of Information System Modeling and Design, vol. 1,pp. 1–22, Apr. 2010.

[30] A. C. de Oliveira Bringuente, R. de Almeida Falbo, and G. Guizzardi,“Using a Foundational Ontology for Reengineering a Software ProcessOntology,” Journal of JIDM, vol. 2, no. 3, pp. 511–526, 2011.

[31] H. Herre, B. Heller, P. Burek, R. Hoehndorf, F. Loebe, and H. Michalek,“General Formal Ontology (GFO): A Foundational Ontology IntegratingObjects and Processes. Part I: Basic Principles (Version 1.0),” Pure Col-lection, pp. 297 – 345, 2006.

[32] R. Arp, B. Smith, and A. Spear, Building Ontologies with Basic FormalOntology. MIT Press, 2015.

[33] C. Masolo, S. Borgo, A. Gangemi, N. Guarino, and A. Oltramari, “On-tology Library,” in WonderWeb Deliv. D18, 2003.

[34] T. Stalhane and G. Sindre, “A Comparison of Two Approaches to SafetyAnalysis Based on Use Cases,” Proceedings of ER’07, pp. 423–437,2007.

52 Bibliography

[35] F. Crawley, M. Preston, and B. Tyler, HAZOP: Guide to Best Practice: Guidelines to Best Practice for the Process and Chemical Industries.2000.

[36] S. J. Kapurch, NASA Systems Engineering Handbook. DIANE Publish-ing, 2010.

[37] R. Mader, G. Griessnig, A. Leitner, C. Kreiner, Q. Bourrouilh, E. Armen-gaud, C. Steger, and R. Weiss, “A Computer-Aided Approach to Prelim-inary Hazard Analysis for Automotive Embedded Systems,” in Proceed-ings of ECBS’11, pp. 169–178, 2011.

[38] J. Hwang and H. Jo, “Hazard Identificaiton of Railway Signaling SystemUsing PHA and HAZOP Methods,” Journal of Automation and PowerEngineering, vol. 2, no. 2, pp. 32–39, 2013.

[39] O. Daramola, T. Stalhane, G. Sindre, and I. Omoronyia, “Enabling Haz-ard Identification from Requirements and Reuse-Oriented HAZOP Anal-ysis,” in Proceedings of MARK’11, pp. 3–11, 2011.

[40] R. Wang, W. Zheng, C. Liang, and T. Tang, “An Integrated Hazard Iden-tification Method based on the Hierarchical Colored Petri Net,” SafetyScience, vol. 88, pp. 166–179, 2016.

[41] P. B. Ladkin, “Ontological hazard analysis of a communications bus,”2010.

[42] K. M. Hansen, P. R. Anders, and V. Stavridou, “From Safety Analysis toSoftware Requirements,” IEEE Transactions on Software Engineering,vol. 24, no. 7, pp. 573–584, 1998.

[43] L. E. G. Martins and T. D. Oliveira, “A case study using a protocol toderive safety functional requirements from Fault Tree Analysis,” in Pro-ceedings of RE’14, pp. 412–419, 2014.

[44] J. Gorski and A. Wardzinski, “Deriving real-time requirements for soft-ware from safety analysis,” in Proceedings of RTS’96, pp. 9–14, 1996.

[45] P. Vyas and R. K. Mittal, “Eliciting additional safety requirements fromuse cases using SFTA,” in Proceedings of RAIT’12, pp. 163 – 169, 2012.

[46] K. Allenby and T. Kelly, “Deriving safety requirements using scenarios,”in Proceedings of RE’01, pp. 228 – 235, 2001.

[47] P. L. Goddard, “A combined analysis approach to assessing requirementsfor safety critical real-time control systems,” in Proceedings of RAMS’96,pp. 110–115, 1996.

[48] A. M. Tiadjio and K. Jamboti, “Requirements and Evaluation of SafetyAnalysis Techniques for Ambient Assisted Living Systems,” in Proceed-ings of ISSRE’12, pp. 319–324, 2012.

[49] R. S. S. Guizzardi, F. Li, A. Borgida, G. Guizzardi, J. Horkoff, andJ. Mylopoulos, “An Ontological Interpretation of Non-Functional Re-quirements,” in Proceedings of FOIS’14, pp. 344–357, 2014.

[50] ISO/IEC14977:1996(E), Information technology - Syntactic metalan-guage - Extended BNF. 1996.

[51] J. Zhou, K. Hanninen, Y. Lu, K. Lundqvist, and L. Provenzano, “An On-tological Interpretation of Hazard for Safety-Critical Systems,” Proceed-ings of ESREL’17, 2017.

[52] D. Firesmith, “A Taxonomy of Safety-Related Requirements,” SystemsWorkshop IEEE Computer Society, pp. 720–721, 2010.

[53] R. Riehle, Failure-driven software safety. ACM, 2007.

[54] M. Shaw, “The Coming-of-Age of Software Architecture Research,” inProceedings of ICSE’01, (Washington, DC, USA), pp. 656–664a, IEEEComputer Society, 2001.

Documents

AN ONTOLOGICAL APPROACH TO SAFETY ANALYSIS …1163903/FULLTEXT03.pdf · These considerations motivate us to formulate the following general research question: Howcansafetyanalysis,withinthecontextofsafety