An Ontological Approach to Safety Analysis of Safety-Critical Systems

(1)

Mälardalen University Doctoral Dissertation 251

AN ONTOLOGICAL APPROACH TO SAFETY

ANALYSIS OF SAFETY-CRITICAL SYSTEMS

Jiale Zhou Jia le Zh o u A N O N TO LO G IC A L A P P R O A C H T O S A FE TY A N A LY SI S O F S A FE TY -C R IT IC A L S YS TE M S 20 17 ISBN 978-91-7485-371-1 ISSN 1651-4238

Address: P.O. Box 883, SE-721 23 Västerås. Sweden Address: P.O. Box 325, SE-631 05 Eskilstuna. Sweden E-mail: info@mdh.se Web: www.mdh.se

(2)

Mälardalen University Press Dissertations No. 251

AN ONTOLOGICAL APPROACH TO SAFETY

ANALYSIS OF SAFETY-CRITICAL SYSTEMS

Jiale Zhou

2017

(3)

(4)

Mälardalen University Press Dissertations No. 251

AN ONTOLOGICAL APPROACH TO SAFETY ANALYSIS OF SAFETY-CRITICAL SYSTEMS

Jiale Zhou

Akademisk avhandling

som för avläggande av teknologie doktorsexamen i datavetenskap vid Akademin för innovation, design och teknik kommer att offentligen försvaras

fredagen den 12 januari 2018, 13.00 i Delta, Mälardalens högskola, Västerås. Fakultetsopponent: Lecturer Ibrahim Habli, University of York

(5)

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 provide, 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 significant flaws in the safety requirements are related to the omission of hazards andcauses associated with the identified hazards in early stages of SCSs development. 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 are

typically identified in accordance to theintuition and experience of the analysts and,

• analysts are inclined to identify generic causes for a certain hazarddescription, for example, “Design

flaw, Coding error, and Human error”and,

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

save effort and,

• since traditional safety analysis techniques are usually based on wellknown 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, 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 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

(6)

Abstract

Safety-critical systems (SCSs) have become an intrinsic part of human daily life in multiple domains, such as automotive, avionics, and rail industries. Such systems 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 the mitigation of hazardous consequences.

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

• 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 a structured 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 and sequence diagrams, a new approach is needed when such behavioral models are not available.

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

(7)

ii

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

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

• We propose an ontological interpretation of the hazard concept, called the Hazard Ontology (HO), to define an explicit representation of the knowledge of hazards and their relations with the system under analysis and 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 certain hazard description for safety-critical systems, based on the HO and, • We propose a heuristic approach to safety requirements elicitation, based

(8)

Summary

Safety-critical systems (SCSs) are such systems that can result in great losses when they are involved in hazardous situations. In modern society, SCSs are becoming pervasive and an indispensable part of our daily life. They play an essential role in various human activities, such as medical treatment, daily transportation, space exploration, and operation of nuclear power plants. To avoid the occurrence of accidents, it is of significant importance to provide safety mechanisms for these systems. The safety mechanisms will prevent these systems from being involved in hazardous situations, i.e., hazards. To achieve this goal, system analysts need to identify potential hazards in which the system under analysis can be involved during its life-cycle. In addition, it is also important to analyze the causes of how and why the system is involved in the hazardous situation. As an old saying goes, “A good beginning is half the 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 problem is 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 can cause ambiguities for others. To improve this situation, we propose a definition of hazard in our research. In this definition, we have defined what components a hazard consists of, the relations between the components and how the com-ponents together can lead to an accident. This definition will help analysts achieve a consistent view of hazards. Moreover, based on this definition, an approach to identify hazards and their causes is proposed. According to the identified hazards and causes, safety mechanisms will be defined to prevent the systems from encountering accidents.

(9)

Swedish

Summary/Sammanfattning

Säkerhetskritiska system (SCS) är s˚adana system som kan leda till stora förluster när de är inblandade i farliga situationer. I det moderna samhället är SCSs en oumbärlig del av v˚art dagliga liv och spelar en viktig roll i olika aktiviteter s˚asom medicinsk behandling, daglig transport, rymdutforskning och drift av kärnkraftverk. För att undvika olyckshändelser är det viktigt att tillhan-dah˚alla säkerhetsmekanismer för dessa system. S˚adana mekanismer förhindrar att systemen hamnar i farliga situationer. För att uppn˚a detta m˚al m˚aste system-analytiker identifiera potentiella risker för system under dess livscykel. Dessu-tom är det viktigt att analysera orsakerna till hur systemet är involverat i risk-fyllda situationer. Enligt ett gammalt ordspr˚ak sägs “Med en bra början är halva jobbet gjort”, dvs ju tidigare systemanalytikerna kan f˚a en helhetsbild av potentiella faror, desto fler designmöjligheter har de för att kunna undvika olyckor. Det är dock inte en trivial uppgift. Ett problem är att olika analytiker kan p˚averkas av sin egen först˚aelse för vad en fara är, dvs vilka komponenter en fara best˚ar av. Därför kan risker som identifierats av en analytiker sakna komponenter och orsaka tvetydigheter för andra. För att förbättra denna sit-uation föresl˚ar vi i denna avhandling en definition av fara. Vi har definierat vilka komponenter en fara best˚ar av, relationerna mellan komponenterna och hur komponenterna tillsammans kan leda till en olycka. Definitionen kommer att hjälpa analytiker att uppn˚a en konsekvent uppfattning om faror. Dessutom används definitionen för att identifiera b˚ade faror och orsaker till faror. Baserat p˚a de identifierade farorna och orsakerna säkerställs säkerhetsmekanismer för att förhindra att systemen stöter p˚a olyckor.

(10)

(11)

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 doctoral thesis 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 supervisors Prof. Kristina Lundqvist, Dr. Kaj H¨anninen, Dr. Luciana Provenzano and Dr. Yue Lu for their support, encouragement and intensive guidance throughout my 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 to become a Ph.D. student; and Prof. Kristina Forsberg for her industrial experi-ence brought to my work and friendly invitation to her family activities. My special thanks should go to: my office-mates over the years, Andreas Johnsen, Adnan Causevic, H¨useyin Aysan, and Abhilash Thekkilakattil, for all the help and great office hours; G¨oran Bertheau and Kristian Wiklund, for their interest in my work and helpful suggestions; my Chinese colleagues, Yin Hang, Kan Yu, and Meng Liu, for their sharing work life and research experience.

My genuine thanks must be given to Damir Isovic, Hans Hansson, Thomas Nolte, Sasikumar Punnekkat, Ivica Crnkovic, Radu Dobrin, Mikael Sj¨odin, Frank L¨uders, Jan Carlson, Bo Liw˚ang, et al., for all the guidance, help, inspi-ration and interesting discussions. I would also like to thank the administrative staff, Malin Rosqvist, Carola Ryttersson, Gunnar Widforss, Susanne Fronn˚a, Jenny Hgglund, et. al., for making many things easier.

I would like to jointly thank all the people at the IDT department, M¨alardalen 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: Hang Yin, Meng Liu, Jing Yue, Kan Yu, Bohan Guo, Lu Zhou, Tian Qiu, Yankai

(12)

vii

Shao, Shiliang Tong, Qin Svantesson, Guanting Liu, Yixiao Wang, Jinsong Yang, 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 great confidence 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 and bringing endless love and happiness to my life.

Jiale Zhou V¨aster˚as, December 2017

(13)

(14)

List of Publications

Papers Included in the Doctoral Thesis

1

Paper A An Ontological Interpretation of the Hazard Concept for Safety-Critical Systems. Jiale Zhou, Kaj H¨anninen, Kristina Lundqvist, and Luciana 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 Based

on the Hazard Ontology. Jiale Zhou, Kaj H¨anninen, and Kristina Lundqvist. Proceedings of the 43th Euromicro Conference on Software Engineering and Advanced Applications (SEAA’17), Vienna, Austria, August 2017.

Paper C An Ontological Approach to Hazard Identification for Safety-Critical Systems. Jiale Zhou, Kaj H¨anninen, Kristina Lundqvist, and Luciana Provenzano. 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 for

Safety-Critical Systems. Jiale Zhou, Kaj H¨anninen, 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. Luciana Provenzano, Kaj H¨anninen, Jiale Zhou, and Kristina Lundqvist. Pro-ceedings of the 24th Asia-Pacific Software Engineering Conference (APSEC’17), Nanjing, China, December 2017.

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

(15)

x

Related Publication not Included in the Doctoral

Thesis

• Formal Execution Semantics for Asynchronous Constructs of AADL. Jiale Zhou, Andreas Johnsen, and Kristina Lundqvist. Proceedings of the 5th International Workshop on Model Based Architecting and Construction 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. Jiale Zhou, 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-critical Embedded Systems. Jiale Zhou, Yue Lu and Kristina Lundqvist. Pro-ceedings of the 19th Ada-Europe International Conference on Reliable Software Technologies (Ada-Europe’14), Paris, France, June 2014. • Towards Feature-Oriented Requirements Validation for Automotive

Sys-tems. Jiale Zhou, Yue Lu, Kristina Lundqvist, Henrik L¨onn, Daniel Karlsson, and Bo Liw˚ang. Proceedings of the 22nd IEEE International Requirements 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, M¨alardalen University, 2014.

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

(16)

I

Thesis

(21)

(22)

Chapter 1

Introduction

Safety-critical systems (SCSs) are such systems that can result in great losses when 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 functions to offer conveniences, the operation of such systems is inevitably at a risk of an involvement of serious hazardous situations that can lead to accidents, for instance, the Yongwen railway accident2_{[5], Space Shuttle Challenger} disas-ter3[6], poison gas leakage accident in Bhopal4[7], etc. These accidents could have an enormous negative impact on people’s life, natural environment, and/or our society in general. Accordingly, SCSs are not only required to implement certain functionality, but also to integrate safety considerations into the systems development life-cycle [8].

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

1_{The 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 a strong magnetic field that interferes with the control system

2_{On July 23, 2011, two high-speed trains traveling on the Yongwen railway line collided with}

each other on a viaduct in Zhejiang province, China.

3_{On January 28, 1986, the tenth flight of NASA Space Shuttle Challenger broke apart 73}

sec-onds into its flight, killing all seven crew members.

4_{During the night of December 2-3, 1984, a storage tank containing methyl isocyanate leaked}

gas into the densely populated city of Bhopal, India. Killing an estimated 3,000 to 6,000 people.

(23)

4 Chapter 1. Introduction

system can separately be proper-functioning, the operation of the system is still at the risk of encountering serious mishaps [9]. In safety engineering, the term system typically refers to the combination of the system under construction as well as the environment where it operates. The system under construction must be defined in terms of its functions, boundaries, and interfaces, the as-sumptions about the environment and the environmental properties should be explicitly identified to enable various analysis and further elicitation of safety requirements [8]. For instance, a system for rail service commuting between two cities could consist of drivers, passengers, freight trains, different types of signaling and electrification sub-systems, tracks, platforms, tunnels, weather conditions, 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, the root 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 design decisions are made, a common choice is to add expensive redundancy or ex-cessive design margins to guarantee safety [11]. One possible way to make better safety-related decision is to integrate safety-concerned activities into the system 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 perform safety-concerned activities in the initial stages of SCS development life-cycle.

1.1 Motivation

The 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

(24)

1.1 Motivation 5

SCS, safety-concerned activities should be integrated into each stage of the development process. This has been required by safety standards in different domains, e.g., ISO13849 [12] and IEC62061 [13] for machines with moving parts, 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 how the various components in the system can contribute to these hazards, 3) define derived safety requirements for the components (repeat recursively over the system hierarchy as needed), and then 4) develop components to meet these safety requirements. The earlier the system developer can have a whole pic-ture of potential hazards, the more and better design choices they can make to address the hazards. Therefore, identifying system hazards and defining safety requirements at early stages play an essential role in the safety development of SCSs.

Preliminary hazard analysis (PHA) is an essential safety-concerned activity conducted 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. Based on the understanding, different levels of safety requirements/mechanisms are defined to mitigate or address the hazards. Typically, the analysts will perform a 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 mitigate such hazards.

By following the flow of these tasks, PHA provides stakeholders with a fully understanding 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. The concept of hazard has been extensively used in the literature and defined in an informal way, which serves as a guidance on identifying potential hazards during 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

(25)

MIL-STD-882 [18] and EN-50129 [15], similar definitions are put forward as “hazard is any real or potential condition that can cause injury, illness, or death to personnel; damage to or loss of a system, equipment, or property; or damage to the environment” and “hazard is a condition that could lead to an accident”, respectively. Intuitively, these definitions seem to be consistent and easy to understand. However, when we take a closer look at them, ambiguities may arise, e.g., whether a hazard is a particular system state, or a combination of system and environment states. Moreover, these definitions lack precise 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. Last but not least, many terms are used to represent the causal relation between “condition” and “accident”, such as “contribute to”, “cause”, and “lead to”. Although these terms are in line with people’s intuition, there is still a need to add constraints to the causal relation from the perspective of real-world semantics, e.g., to define what type of real-world entities can be connected by a causal relation, and to explain how the 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 a certain subject or domain that consists of a set of subject-/domain-specific con-cepts, relations, and axioms. Such domain ontology aims to achieve a better understanding of the subject or domain from modelers and model users point of view [19]. Several domain ontologies, which are related with hazard, have been proposed in the literature [20] [21] [22] [23]. Nevertheless, either they leave the real-world semantics out of consideration, or they provide it in an informal way. In order to interpret hazard in the real-world semantics, founda-tional concepts (e.g., object, event, relator, universal, etc.) should be explicitly taken into account. A foundational ontology is a theoretically well-founded subject-/domain-independent ontology, which consists of a set of foundational concepts and relations. It can be grounded in to provide a sound real-world semantics for a subject-/domain-specific ontology. These considerations mo-tivate us to formulate the following research question (RQ1): How can we conceptualize hazards from the real-world semantics perspective to improve the understanding of the hazard concept, within the context of safety-critical systems?

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

(26)

ana-1.1 Motivation 7

lysts are inclined to identify generic causes for a certain hazard description, for example, “Design flaw, Coding error, and Human error” can be listed as pos-sible causes, but this type of generic information is not particularly useful for guiding the safety requirements elicitation [9]. Furthermore, since the identifi-cation of hazards and their causes highly relies on the experience possessed by the analysts and the lessons learned in previous systems development, there is a need to formalize these experiences in a structured way which can be reused to identify 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 and sequence diagrams, a new approach is needed when such behavioral models are not available at early stages. These considerations motivate us to formu-late the following research questions (RQ2 and RQ3): 1) How can we improve the identification of potential hazards associated with the safety-critical system under analysis, based on an improved understanding of the hazard concept? and, 2) how can we improve the identification of possible causes associated with a certain hazard, to make the results of hazard analysis more complete and useful, based on an improved understanding of the hazard concept?

Based on identified hazards and their associated causes, safety constraints can be developed. The safety constraints are high level safety requirements that aim to eliminate or mitigate the identified hazards [8]. Typically, a safety constraint can be the negation form of an identified hazard. For instance, if the hazard is of the form “a hazardous state occurs”, the safety constraints will be derived in the form of “a hazardous state should not occur”. However, this kind of simple translation from hazard to safety constraints provides little guidance for engineers to implement mitigation mechanisms in practice. For example, 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 level safety constraints to mitigate corresponding hazards. Obviously, these kinds of safety 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 could be helpful in such situation. Since the interpretation of hazard can reveal how the constituents of a hazardous state can contribute to the occurrence of ac-cidents, the mitigation mechanisms can be defined either to eliminate one of the constituents of the hazardous state, or to impede the way through which certain constituents contribute to the accidents. These considerations motivate us to formulate the following research question (RQ4): How can we utilize the understanding of the hazard concept to facilitate the elicitation of safety requirements of safety-critical systems?

(27)

1.2 Overview of Contributions

We propose an ontological approach to safety analysis of safety-critical sys-tems, which mainly consists of five pieces of work. In particular, the technical contribution 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 system under analysis and existing environment.

– Personal contribution to Paper A: Jiale was the main author of Paper A. He has been involved in all parts of the work, in terms of research 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 language hazard description to the hazard modeling language.

– Personal contribution to Paper B: Jiale was the main author of Paper B. He has been involved in all parts of the work, in terms of 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 stages of the safety-critical systems development, based on the HO.

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

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

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

(28)

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 terms of research idea formulation, literature review, solution discussion and evaluation, and paper review.

1.3 Thesis Outline

The thesis is divided into two parts: Part I includes five chapters. Chapter 1 provides an introduction of the thesis where the motivation of our work and an 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 the ontological approach to safety analysis. In Chapter 4, a research overview is presented, including the research questions guiding our work, the challenges associated with each question, our contributions to each question, and the re-search methodology adopted in this thesis. In Chapter 5, we summarize the thesis 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 are organized 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-Critical Systems Based on the Hazard Ontology

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

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

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

(29)

(30)

Chapter 2

Background and Related

work

In this chapter, we briefly introduce the background knowledge underlying the thesis and other related work. The Unified Foundational Ontology that is the foundational 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 as a hazard conceptualization. A summary of existing hazard analysis techniques is provided in Section 2.3. Finally, we describe the current practice of safety requirements elicitation in Section 2.4.

2.1 Unified Foundational Ontology

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

(31)

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 will offer support for the ontology designers in externalizing the real-world seman-tics of ontology concepts, choosing a particular pattern to represent the domain knowledge, 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] as foundational ontology. Comparing other existing foundational ontologies, such as GFO [31], BFO [32], DOCLE [33], etc., UFO provides a more complete set of foundational concepts to cover important aspects of hazards, such as Situation, Disposition, and Kind/Role. Moreover, causal relations are defined based on these concepts. In the following, we present a fragment of the UFO containing the concepts that are germane for the purposes of this paper, as shown in Figure 2.1

Figure 2.1: A fragment of the UML diagrams of UFO. Concepts are repre-sented as rectangles. Typed relations are reprerepre-sented by lines with a reading direction pointed by “I”, from open end to aggregated end. Cardinality con-straints are labeled on each end of typed relations. Subsumption concon-straints are 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 ure 2.1) and a taxonomy of individuals (as shown in the right part of

(32)

2.1 Unified Foundational Ontology 13

ure 2.1). An individual, i.e., an instance of Individual, is an specific entity that exists in reality possessing a unique identity, while an universal, i.e., an instance of Universal, represents a pattern of features that are repeatable in a number of different individuals. For example, John is an individual that instan-tiates the universal Person. Since most distinctions made for universals also apply to individuals, which means most sub-concepts of Universal have their Individual 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 unique identity and keeping its identity. An Event, conversely, extends in time while accumulating temporal parts. Especially, whenever an event is present, it is not the case that all its constituent parts are present (e.g., the constituent parts of a car collisionevent can comprise “cars crash into each other” and “cars bounce off”, which exist in a chronological order). Moreover, an event existentially depends on its participants in order to exist.

Endurant has several sub-concepts of great interest in this work, such as Object, Moment, Disposition, Relator, Situation, etc. An Object is an en-durant whose existence in time is existentially-independent of other enen-durants (e.g., a car is an object whose existence in time does not depend on others). A Moment, in contrast, is an endurant that inheres in another endurant(s) (e.g., the kinetic energy of a trainis existentially-dependent of a train). Moments that 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 relation of 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). Disposition is existentially-dependent of one single endurant. A disposition can only be manifested by the occurrence of event(s) (e.g., the kinetic energy of a train can 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 Situation is constituted by one or more endurants. A situation is considered here to be synonymous to what is named state of affairs, i.e., a portion of reality that can be comprehended as a whole. Note that 1) a continuous repetitive behavior can be regarded as a situation, such as “a train is moving” and, 2) if it is described that 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 “the brake command is not issued”. An exist in relation is defined between a

situ-2_{We will use “an endurant” or “an Endurant” interchangeably to represent, an instance of the}

(33)

ation and its constituent endurants. For example, in the situation “a passenger train 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 and being-crossing), and the kinetic energy dispositions that characterize a person and 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 will bring 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 temporary speed restriction area” event is the manifestation of the “kinetic energy” disposition of the train and the “boundary” disposition of the temporary speed restriction area.

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

Different from other foundational ontologies, UFO defined two concepts to describe 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 person during his/her existence, and a driver is no longer a driver after he/she has left the car. Therefore, a person is a kind object and a driver is a role object. A relation of “play” is defined between a kind object and the role objects they can instantiate, such as “a person” can play the role “a driver”.

2.2 Hazard Triangle Model

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

(34)

2.2 Hazard Triangle Model 15

(HTM) [24] provides an informal yet typical conceptualization of hazard, as shown 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 the side of a triangle. Hazard Source is the rudimentary component of a hazard. It creates the potential hazardous impetus for the hazard to exist, which are generally energy sources or safety critical functions, for instance, electricity, fuel, gas, aircraft velocity, etc. Initiating Mechanism represents the initiator events that cause transformation of the hazard from a dormant state to an active mishap state, e.g., hardware failure, human errors, etc. Hazard Target/Threat Outcome is the resulting severity outcome after the hazard is transformed to an active mishap state, such as injury of people, loss of the system, and damage to the environment. As claimed in [24], all three sides of the hazard triangle are essential and required in order for a hazard to exist. By removing any one of the triangle sides, the hazard will be eliminated because it is no longer able to trigger an accident. Also, by reducing the possibility of any of the components of the triangle the mishap possibility is reduced. When all the components comprising 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, the HTM has received considerable attention, and served as a conceptualization in typical 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 the HTM, i.e., what are the foundational categories that HTM concepts can

(35)

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. The first three sources refer to an amount of matter, respectively, whereas the last one refers to a quality. Apparently, this superfluous inconsis-tency could cause confusions for stakeholders when either performing the hazard analysis or examining the hazard analysis results throughout the development process.

• Deficiency 2: There are no clear definitions on the relations among these concepts, without which the interpretation would sacrifice its preciseness and cause ambiguities. For instance, it is not clear whether the hazard source and threat outcome will participate in the initiating mechanism event or not.

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

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

2.3 Hazard Analysis Techniques

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

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

(36)

2.3 Hazard Analysis Techniques 17

and refined into low level sub-system faults or failures to guide the definition of 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 the analyst reasons about this failure’s effect on the overall system behavior and identifies the potential hazards. Furthermore, FMEA only considers failures, and hence does not usually consider operating procedures, human factors, and transient conditions, when it is used for the purpose of hazard analysis.

Hazard and Operational analysis (HAZOP) is a structured and systematic technique for examining the system under development, with the objective of identifying hazards and potential operability problems of the system [35]. The main idea behind the HAZOP method is to analyze potential deviations from the system intents, with the help of a set of selected guide-words. The selected guide-words could be different among different domains. Nonetheless, all the techniques mentioned above have assumed that there should exist a basic de-sign, i.e., the design decision of the system architecture and components have been made, at the outset of hazard analysis. Different from the aforementioned techniques, basic design of the system under analysis is not required by our approach. 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, and Systems-Theoretic Accident Model and Processes (STAMP) [8]. STAMP is an extension of traditional causality models, which aims to capture more types of accident causal factors (such as abnormal interaction between components) than traditional methods (which usually treat hazards as a component failure problem). The only required input for STECA is the Concept of Operations (ConOps) document that includes a statement of the goals and objectives of the 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 organized in a hierarchical way. Hazards can be discovered by analyzing either the ab-normal behaviors of the elements or the unsafe interaction between different elements. The main drawback of STECA lies in that it is difficult for STECA to discover hazards that are not related with behaviors, for example, people are exposed to toxic material. Our approach is based on conceptualizations of hazards and thereby it is not limited to identify hazards that are related with

(37)

behaviors.

There are also examples of adaptations of the aforementioned hazard analy-sis techniques for identifying hazards [37] [38]. In [26], Guiochet et al. propose a hazard analysis technique called HAZOP-UML. The HAZOP-UML takes different 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 regarded as a potential hazard that can lead to a harmful event. Daramola et al. [39] present a framework and tool prototype that facilitates the early identification of 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 et al. [21] propose an ontology-based approach to hazard identification within the preliminary hazard analysis worksheet by utilizing the reasoning capability of ontologies. Their main objectives are to discover potential hazards based on ex-isting PHA results. Wang et al. [40] put forward an adaptation of STPA based on formalization model, called BFM-STPA, to explore the causes of identified hazards. The Ontological Hazard Analysis (OHA) [41] is a refinement-based approach that is proposed by Ladkin for the analysis and maintenance of safety hazard lists.

2.4 Safety Requirements Elicitation

In our work, safety requirements are the safety mechanisms that are defined to mitigate or address potential hazards. Much effort has been devoted into the problem of safety requirements elicitation. In particular, several publications address 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 to satisfy in order to avoid the occurrence of failure. Martins et al. [43] claim that merely FTA is not sufficient to specify safety requirements. Therefore, it is necessary to provide more information to derive requirements, such as en-vironmental conditions. They present a protocol to derive functional safety requirements from FTA. The main idea is that FTA provides a way to figure out under which environmental condition a system transits to an unsafe state. This knowledge is then used to define how the system should or should not behave to avoid such unsafe state. Gorski et al. [44] extend the FTA results by adding time properties to the events in order to define safety requirements

(38)

2.4 Safety Requirements Elicitation 19

suitable for real-time systems. Vyas et al. [45] propose an approach to derive requirements, consisting of performing FTA, formalising the results of FTA, calculating the minimal cut sets with time analysis, and deriving mitigation requirements (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 and Effects Analysis (FMEA). Allenby et al. [46] propose a sub-set of HAZOP guiwords, and apply such words on Use Case scenarios to identify the de-viation from design intent and thus identify requirements. Goddard [47] use Petri-nets to model the system and possible failures, and then perform Failure Mode Effect Analysis (FMEA) to identify the flaws in safety requirements.

All the aforementioned pieces of work agree upon the insight that safety analysis techniques “provide the mechanism for identification of the safety re-lated requirements” [46], since the knowledge about how a system is involved in 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 requirements elicitation methods, is not complete to elicit safety requirements. In addition, the information for these safety requirements elicitation techniques that can be extracted from safety analysis primarily concerns the identification of fail-ure cases. However, Tiadjo et al. [48] study several common safety analysis techniques for the elicitation of safety requirements for Ambient Assisted Liv-ing (AAL) systems. Their study shows that the most of these techniques cannot support requirements specific to these systems, e.g., lack of context-awareness. Another example of information needed for safety requirements but missing in FTA is the relationships among events. From a safety requirements perspec-tive, it is important to know if these events must occur chronologically and their durations [44].

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

(39)

(40)

Chapter 3

An Ontological Approach to

Safety Analysis

In this chapter, we summarize the papers collected in the thesis and introduce our main contributions in a unified and consistent way. In Section 3.1, we briefly describe a robotic strolling system that is used as a running example to illustrate our approach. Section 3.2 elaborates the Hazard Ontology that is an interpretation of the hazard concept. Section 3.3 presents the Hazard Modeling Language 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 the approach to elicit safety requirements. Section 3.6 summarizes the evaluation of our approach and provide some of our considerations.

3.1 Description of the Robotic Strolling System

The robotic strolling system [26] aims to help partially-disabled persons to stand 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 detect physiological 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 be able 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

(41)

22 Chapter 3. An Ontological Approach to Safety Analysis

“Standing up operation” use case, labeled as UC01, to illustrate our approach as 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 approach can also be applied on other types of system functional requirements, such as concept of operation documents, etc.

(42)

3.2 The Hazard Ontology 23

3.2 The Hazard Ontology

The Hazard Ontology (HO) provides the analysts with a UFO-consistent per-spective to explain the hazard-related concepts and relations. Figure 3.3 depicts the 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 concepts are colored in white. Typed relations are represented by lines with a reading direction pointed by “I”, from open end to aggregated end. Cardinality con-straints are labeled on each end of typed relations. Subsumption concon-straints are represented by lines with an open-ended arrow “4” connecting a sub-concept to its subsuming super-concept. InstanceOf axiom, labeled as insOf, specifies that 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 supposed to be characterized by two essential features. On one hand, the nature of a hazard is a set of states, which motivates the interpretation that Hazard is a type 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 can trigger Mishap. A mishap is an accidental event that will consequently cause injuries to people, damage to the environment or significant financial losses.

(43)

Inspired by the first idea behind the causal relations, the essential constituent parts existing in a hazard consist of mishap victims, harm truthmakers, haz-ard elements, and exposures. Harm TruthMaker represents the harmful or critical dispositions in a hazard. When such harm truthmakers are manifested, mishaps are likely to occur. Hazard Element denotes the role objects that bear the harm truthmaker dispositions. These roles can be played by various kindobjects. Mishap Victim is a sub-concept of Hazard Element. A mishap victim denotes a role object that is not supposed to but have the potential to encounter with damages or injuries. Exposure represents the relations through which 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 by at least one initiating event. An initiating event, i.e., an instance of Initiating Event, is an undesirable or unexpected event that can bring about a hazard sit-uation. Initiating Condition is defined to capture the knowledge that are of importance to understand how the initiating events are triggered. An initiating condition, 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 to trigger 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-initiiniti-ating event can bring about an initiating condition which will trigger another post-initiating event to bring about a hazard.

3.3 A Hazard Modeling Language

A core benefit of understanding the ontological foundation of hazards is that it provides a basis for designing a hazard modeling language (HML) [49]. The HML is a textual language. Its syntax and semantics are based on the Haz-ard Ontology. Comparing graphical language such as UML diagrams, textual language provides a concise way to describe hazards, which makes it more efficient 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 hazard consists of and how different elements contribute to a hazard and subsequent accidents. All the symbols are clearly defined in accordance to the Hazard

(44)

On-3.3 A Hazard Modeling Language 25

tology. Therefore, it can reduce the ambiguities which are caused by different understandings of the hazard concept. Furthermore, a practical transformation approach 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 name or number. The first optional part defines that there could be more than one InitiatingEvent that bring about the hazard, and the “bring about” relation is represented by the terminal “–>”. Moreover, the second optional part indicates that each hazard can be expanded by defining its HazardBody, to be introduced later. The terminal “=>” in the last optional part represents the “trigger” re-lation defined in the HO. In particular, each hazard can trigger more than one Mishap (line 2), which is composed of MishapName (which is a group of terminals) and MishapVictim (which will be introduced later). Note that the motivation behind the optional and mandatory definition is two-fold: On one hand, the modeling language is able to provide constructs to fully support the hazard conceptualization defined in the Hazard Ontology. On the other hand, it

1_{We use “()”to group characters, “?” to represent optional character, “*” to represent empty or}

repetitive characters, and “|” to represent alternatives. Nonterminals are in italics, and terminals are quoted or derived from “...Name” nonterminals.

(45)

supports partial specification in practice, which enables the HML specification being 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 “)”, denotes a role object which participates in the initiating event. An event participant can be played by a kind object called EnvObj. InitiatingCondition (line 5) defines a group of terminals, labeled as InitiatingConditionName, to specify the 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 a roleobject 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 can have an optional value, for example, “<Toxicity: High>” means the level of toxicity 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 roles which 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 role concept, the hazard element role can be played by an EnvObj entity, and can be characterized by more than one HarmTruthMaker. HarmTruthMaker (line 11) is defined as a group of terminals (labeled as HarmTruthMakerName), wrapped with a pair of “<” and “>”. Similarly, as a disposition, a harmtruth-makercan have an optional value. MishapVictim (line 12) is defined as a group of terminals, labeled as MishapVictimName, and it is wrapped with a pair of “(” and “)”. Meanwhile, a mishap victim role can be played by an EnvObj entity.

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 play the corresponding roles, but not known for sure during the hazard modeling stages, e.g., “(HotParts: DEFAULT)” means there are certain environment objects are hot parts. The terminals “NOT”, “ ∨”, and “∧” applied to EnvObj