A profile and tool for modelling safety information with design information in SysML

Transcription

1 Journal of Software and Systems Modeling manuscript No. (will be inserted by the editor) A profile and tool for modelling safety information with design information in SysML Geoffrey Biggs Takeshi Sakamoto Tetsuo Kotoku Received: date / Accepted: date Abstract Communication both between development teams and between individual developers is a common source of safety-related faults in safety-critical system design. Communication between experts in different fields can be particularly challenging due to gaps in assumed knowledge, vocabulary and understanding. Faults caused by communication failures must be removed once found, which can be expensive if they are found late in the development process. Aiding communication earlier in development can reduce faults and costs. Modelling languages for design have been shown through practical experience to improve communication through better information presentation and increased information consistency. In this paper, we describe a SysML profile designed for modelling the safety-related concerns of a system. The profile models common safety concepts from safety standards and safety analysis techniques integrated with system design information. We demonstrate that the profile is capable of modelling the concepts through examples. We also show the use of supporting tools to aid the application of the profile through analysis of the model and generation of reports presenting safety information in formats appropriate to the target reader. Through increased traceability and integration, the profile allows for greater consistency between safety information and system design information and can aid in communicating that information to stakeholders. Keywords S ysml, UML/SysML profile, safety analysis, system design 1 Introduction The development of safety-critical systems often involves communication amongst various members of a development team. The client communicates their desires Geoffrey Biggs and Tetsuo Kotoku Intelligent Systems Research Institute, National Institute of Advanced Industrial Science and Technology, Japan Takeshi Sakamoto Global Assist, Inc., Japan

2 2 Geoffrey Biggs et al. to requirements engineers, requirements engineers communicate requirements to system designers, safety engineers analyse requirements for hazards and communicate these to system designers, and hardware engineers communicate interface specifications to software developers, to name just a few of the communications that may occur during development. Communication both between development teams and between individual developers is known to be a source of safety-related faults in critical system design [38, 16]. For example, communication between the client and the developer is often fraught with ambiguities, and defects in the information communicated between the requirements engineer and the test engineer can lead to defects in testing. Communication between experts in different fields can be particularly challenging due to gaps in assumed knowledge, understanding and information integration. One study of NASA spacecraft development found that communication failures between the hardware team and the software team, such as inadequately specified interfaces, was a major source of faults [38]. A similarly important cause was failures in communicating the requirements. A later NASA study found that the same problems still exist [16]. Moving from security analysis to design is also known to be difficult and error-prone [14]. Communications failures may lead to faults in the system that must be corrected before deployment. Although faults can be caught by various means, including design reviews and testing, the later in the development process a fault is corrected, the more expensive that corrective action becomes. It is cheaper to catch and remove or prevent faults as early in the development process as possible. For faults caused by communication failures, reduction of faults through improvements in communication (and therefore reduction of communication failures) is therefore an important tactic. In addition, design decisions relating to safety-critical aspects must be validated as early as possible by all involved parties [7]. This requires that all involved understand the information. Communication can be improved through information clarity, specificity and integration. For example, making the relationship between a system s known risks and its design clear and easy to understand can aid in communication between the safety engineer and the system developer. Clearer communication regarding safety supports critical system development [53]. 1. It supports developers by helping them to understand which risks are relevant to the system and to its component parts. 2. It supports safety engineers by helping them to understand what risks the system deals with, and how it deals with them. 3. It supports certification authorities by clearly specifying the risks that have been considered, the measures taken to counter them, and their relationship to the system design, aiding the certifier in making judgements about whether the system is sufficiently safe in its functionality and features. The use of modelling languages such as UML and SysML has been shown through practical, real-world experience to improve development communication and information management in system development [2], such as traceability from requirements to design and avoiding defects in test cases. Additionally, specialised modelling languages working on the same model to provide different views can be more useful than a general-purpose modelling language in specific situations [3].

3 A SysML profile for safety information 3 In this paper, we follow the above literature in utilising a modelling language designed to express safety-related concerns and working in the same model as the system design in order to improve the integration of related information, to improve the consistency of that information (through improved traceability), and to aid communication between development teams and between development team members working on safety-critical systems [11]. The current approach of isolating safety analyses and system models from each other creates inconsistencies and duplicates effort, while an integrated model can benefit model consistency, traceability and automation possibilities due to integrated knowledge with greater consistency [39]. We present a profile of the SysML systems modelling language [46], itself a profile of UML. The profile, named SafeML, is able to model the risks of a system and how it manages those risks, and integrate that information with a model of the system s design. This paper presents the SafeML profile. Tool support is a benefit to the usability of a modelling language, including storing the model, providing an interface for creating and maintaining the model, and processing the model to provide alternative views of the contained information. In keeping with this, this paper presents related tools supporting the profile s use. The profile s ability to represent safety information and the use of tools to aid in presenting that information (for example, report generation) are demonstrated through examples. The following section provides background on previous modelling languages that have been used for safety, security, reliability and related aspects of critical system design. Following that, Section 3 describes the profile. To demonstrate the profile s capability to model the concepts, an example of applying it to a system model is presented in Section 4. Tools that have been designed to support use of the profile are described in Section 5. Discussion is given in Section 6. 2 Modelling System Properties The use of modelling languages such as UML for specifying non-functional system properties is a common theme in the literature. System properties including safety, reliability, security and Quality of Service (QoS) have all been targets of specialised modelling languages or language extensions. The existing work can be divided into those approaches that aim for formality to allow automatic analysis, and those approaches that do not specifically require formality (although they may feature it), instead aiming to store and present information. 2.1 Automatic Analysis Generation Automatic generation of various analyses from modelled information is the most common goal in the existing work Safety and reliability analysis Because of the blurred line between safety analysis and reliability analysis in the literature, we have placed these in the same section. These two properties are the most common targets for modelling and automatic analysis generation.

4 4 Geoffrey Biggs et al. One approach is to model a software system in UML, specify the desired safety aspects in the same UML model, and generate analysis results, such as FMEA/FMECA and FTA, directly from that model. de Miguel et al. describe one such UML profile for safety of software systems [39]. Proposing that software and safety engineers should work with the same model, they provide stereotypes for specifying concepts including safety-aware components and mitigation means. Their goal is to allow the safety and software engineers to work on a single UMLbased model, from which an FMECA and an FTA can be generated using model transforms. Pai and Dugan use UML models with reliability analysis information embedded to generate Dynamic Fault Trees [47]. The statistical information needed for analysis is embedded using stereotypes, such as a spare stereotype to mark a component as a hot spare, and stereotypes for error propagation. The CHESS project [40] is an effort to create a complete modelling tool chain for dependable systems. It uses a set of modelling languages and model transforms to aid in analysing a system design. The system model, developed using a UML profile, includes a broad range of aspects, from what faults can affect a component and how errors are transmitted between components to how and by whom faults are detected (including a false alarm ratio) and the maintenance schedules of components. An Intermediate Dependability Model (IDM) is used as a bridge between the system model (with dependability information) and formal analyses, such as FMECA and Fault Propagation and Transformation Calculus [41]. Model transforms are used to transform the system model into the IDM, and then the IDM into a suitable model for the desired analysis method. The tools in this project are primarily oriented towards designing fault-tolerant systems. The HIDE project is a precursor to the CHESS project [7], implemented as a UML profile and aimed at software systems. It aimed to allow early validation of system design with formal techniques, based on model transforms to analysis tools such as Petri nets. A relatively unique innovation was the ability to transform the results of analyses back into the UML software model to assist subsequent design choices. The Dependability Analysis Model for Real-Time Systems (DAMRTS) is a profile for specifying stochastic and probabilistic information about malfunctions [1]. The profile focuses on adding formal semantics and probabilities to UML 1.x state chart diagrams, allowing formal analyses to be performed on them. The Society of Automotive Engineers (SAE) has produced the Architecture Analysis and Design Language (AADL) [10]. This modelling language, which has both textual and graphical versions, is designed for modelling the electrical systems of cars. It supports analysis of a system s architecture with respect to performancecritical properties. Reliability models of components can be defined, which are then used for Markovian analysis or Fault Tree Analysis of the architecture Quality of Service analysis The modelling and analysis of Quality of Service properties, such as timing, scheduling and fairness, is useful in real-time embedded systems as an aid to correct system design. The Component QoS Modeling Language (CQML) is one such QoS modelling language [17,51]. The goal of this language is for a developer of a component-based

5 A SysML profile for safety information 5 system to build the system from pre-defined components, then analyse the QoS contracts of those components, such as how reliably they can provide their services or the required availability of services they consume, to determine if the system as a whole is feasible. A similar approach is taken by QML, a text-based QoS modelling language with a UML profile [13], and by the UML profiles presented by Ritter et al. ([50]) and Biffl et al. ([6]). The latter is used to model the QoS requirements of data links. AVATAR ( Automated Verification of real Time software ) is a SysML-based toolkit designed for specification and formal analysis of real-time embedded systems. 1 It reuses much, but not all, of the SysML profile. It adds the ability to perform a formal verification of each test case specified for a modelled system through a transformation of the model into UPPAAL. The information necessary to make this transformation possible is provided in the model by annotating, for example, state machine transitions. Standard SysML guards are complimented with temporal guards to allow for analysis Security Security is another target of modelling. UMLsec is a UML profile for security [28]. Its goals include allowing formal analysis of the security properties of a software system from its UML model. It can manage security properties mainly including confidentiality, and can also deal with the structural aspects that impact on these properties, such as using an insecure sub-component in a component meant to be secure. For example, it has been used to verify the confidentiality properties of a variant of the TLS secure protocol [29]. Code generation is also possible, with a UMLsec model used to generate a secure software implementation of the design. UMLsec has been used successfully in German industrial projects, including an analysis of a telecommunications network [29, 30], where it was used to analyse the structure of the communications infrastructure for problems regarding confidentiality Component compatibility The compatibility between components (i.e. interface matching) is an important system property for ensuring correct design [35]. Some models for analysis attempt to show that interfaces match. Hause and Thom provide guidelines for using UML and SysML in safety-critical system design [15]. To assist in ensuring that a component s dependencies are compatible with the safety requirements of that component, they provide stereotypes for the Safety Integrity Level (SIL) concept from ISO If a component is marked as SIL2, then it is possible to examine the model to confirm that its dependencies are also marked as SIL2 or higher. Iwu et al. use safety contracts to specify what a component expects of its environment and what it commits to achieve [26]. This is used as a formal specification of subsystems derived safety requirements. They combine this model with tool for analysing the safety contracts of subsystems to ensure they are satisfiable by the other subsystems. 1

6 6 Geoffrey Biggs et al. Following a similar theme, Mustafiz et al. target the external interfaces of a system for improving safety [43]. They describe a method for analysing use cases using probabilistic state charts. Based on the analysis results, a use case can be refined by adding detection and recovery measures to ensure dependable system interaction. 2.2 Information presentation Presenting information (most commonly, as an aid to communication) is the other category of approaches in the literature. It is not as common as performing automatic analyses. It has different requirements on how information is modelled, in that it does not necessarily require a formal specification. Zoughbi et al. aim to improve communication between safety engineers and software engineers through the use of a UML profile that allows software engineers to model safety-related concepts and properties in UML [53]. They have created a profile that specifically models the safety concepts of the RTCA DO-178B standard for Software Considerations in Airborne Systems and Equipment Certification. Douglass describes a UML profile designed specifically for modelling FTA fault trees, assisting the developer in specifying safety requirements [9]. The events in the fault tree can be linked to elements of the UML model, such as the UML element that manifests a fault, improving traceability. The profile can also represent elements that detect faults and element that correct faults using detect and extenuate relationships from the elements to the fault tree. Most prominent amongst models for system properties of real-time and embedded systems is a standardised profile for UML from the Object Management Group (OMG). 2 The OMG UML Profile for Modeling and Analysis of Real-Time Embedded Systems (MARTE) provides support for modelling real-time embedded systems [44]. Stereotypes are provided for annotating models with the information necessary to perform model-based analysis and Verification & Validation (V&V). MARTE enables modelling of both hardware and software in a single, unified model, improving communication between hardware and software engineers. Bernardi et al. have developed an extension for MARTE 3 that adds dependability analysis and monitoring [5]. It allows the modeller to specify concepts such as faults and maintenance, and to derive formal models such as Stochastic Petri Nets from the system model. It is mainly focused on dependability issues caused by internal system faults and is oriented towards fault tolerant systems. The OMG UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics (QFTP) is a UML profile for QoS with a broader scope [45]. It models not just the quality characteristics of components and their required quality contracts, but can also model aspects of QoS such as risk, unwanted incidents and treatments. SecureUML is a UML profile for communicating the security concerns of a software system [4,3]. It is used to model Role-Based Access Control for the purposes of documenting the access privelages of users and entities in a system (relevant to confidentiality and integrity properties). Stereotypes allow the modelling of roles, 2 The OMG is also responsible for the UML and SysML standards. 3 MARTE, like UML, is designed to be easy to extend.

7 A SysML profile for safety information 7 resources, actions that can be performed on those resources, and authorisation constraints (modelled using logical predicates). Questions can be asked of a SecureUML model, such as all the actions that a role can perform, or whether there are redundancies between roles. Taking a significantly different approach from other models, [48] describes building UML profiles of the concepts found in international standards on safety. The goal of this work is to use modelling techniques to ensure that sufficient correct evidence has been collected to satisfy the relevant standards for certifying a system, and thus improve the certification process. They have used this concept to create a model of the evidence required by the IEC standard, which can be used to verify that the necessary evidence has been gathered for certification [49]. 2.3 Summary Two goals are common in the literature. The first is automating analysis of a system property based on augmenting a system model with the necessary information. The second is effectively the opposite approach: assuming that relevant analyses have already been performed, add these to an existing model of the system with the goal of presenting the information, for example to stakeholders in the system or to certification authorities [18]. This latter goal is less common than the former. Given our goal of integrating safety information and system design information for the purpose of traceability, information consistency and information presentation, this second type is of more interest to us than allowing automated analyses. In the surveyed literature, it is considerably more common to modify or extend an existing modelling language than to create a new language. This is possibly because using an existing language is simpler than creating a complete modelling language from scratch. It also has the benefit of producing an integrated model, rather than separate models, which benefits traceability and information consistency. In the reviewed works, UML is the most commonly-used base language. The disadvantage of this is that UML is software-oriented; representing other aspects of systems (particularly hardware) is more difficult than in a system-oriented language such as AADL or SysML. The need to consider the entire system, not just its software-related aspects, is recognised in international safety standards such as IEC (a generally-applicable standard for functional safety) [21] and in the literature [36]. Most of the language and profiles, such as the OMG s MARTE, target reliability of system components rather than safety of a system, or model the reliability aspects of safety features of a system. Although reliability is important for achieving safety, reliable systems are not necessarily safe; threats to safety are not limited to failing components [35]. These approaches are therefore useful for modelling properties such as performance, possible faults, and maintenance, but they do not provide for important safety information such as hazards (other than faults) and potential harm. The benefits of using an integrated model of the system and its safety/dependability properties are often mentioned in the above works. They include: 1. improved communication amongst developers and development teams; 2. improved traceability of the dependability aspects; and

8 8 Geoffrey Biggs et al. 3. ability to view the same information in different ways for increased understanding or easier focus. Zoughbi et al. list several advantages of using a UML profile for modelling safety, including improving communication between safety and software engineers, improving the documentation of safety-related properties, improving the participation of software engineers in safety assessments, enabling the reuse of safety assessment results, and emphasising a develop in safety culture [53]. These benefits can be extended to modelling of the entire system, given a suitable profile of SysML for modelling safety information with the complete system design. We discuss such a profile in the next section. 3 SysML Profile for Safety SafeML is a SysML profile for integrating safety information with system design information, as an aid to information consistency and communication between development teams and between members of a team. It can be used for: 1. tracing from hazards through the safety measures used to the verification steps taken to test those measures; and 2. documenting the analysed hazards and their safety measures to certification authorities. 3. communicating from safety engineers to system engineers the hazards that must be considered while designing to meet requirements, as identified through hazard and safety analysis processes; 4. communicating from system engineers to safety engineers the hazards that the system is designed to manage, including the safety measures used; SafeML, as a profile of SysML, is targeted at safety-critical systems that are built from both hardware, and software designed to control that hardware. The goal of SafeML is to allow the intuitive documentation of hazard and safety analyses results and safety measures in the system model. This can improve consistency between multiple analyses and aid in communicating the results of analyses [52]. SafeML focuses on making this information visible in the system design. SafeML is designed to be used in conjunction with SysML. SysML provides the diagrams and element types necessary for design modelling, while SafeML provides the element types used to add safety information to the model. This concept is illustrated in Figure 1. SafeML is usable as part of any development process that involves modelbased specification and design. For example, safety analyses may be performed immediately after acquiring system requirements, as is common in a Waterfall development model [8]. In this case, the requirements can be modelled in SysML and the safety analyses results added using SafeML elements, followed by modelling design using SysML and including safety features using SafeML. Another option is an agile approach, where prototype architectures are produced to aid in analyses. The prototype architectures can be modelled using SysML, with SafeML used to model the considered safety features.

9 A SysML profile for safety information 9 System design SysML elements System model System model with safety information Safety analysis SafeML elements Fig. 1: Concept for using SafeML This section describes SafeML. It specifies the profile that extends SysML, and its relationship to safety analyses. In designing SafeML, we considered both the relevant safety concepts, described in the next section, and the ways in which SysML can be used to provide safety information, described in Section Safety Concepts We begin by describing the safety concepts on which SafeML is built. We base these concepts in part on the definitions given by the following international standards for safety: 1. IEC [22]; 2. ISO [23]; and 3. ISO [25]. These three standards are recent prominent standards for safety, covering two approaches (safety of machinery in the case of ISO 12100, and functional safety in the case of IEC and ISO 26262). A hazard is a potential source of harm in the system. Hazards are everpresent in that the system always contains the potential to cause the related harms, given the correct conditions. Hazards are related to components of the system, aspects of the system s design, or uses of the system. Leveson states that a hazard s description may include the system component where the hazard exists, corrective or preventative measures, operational phases that expose the hazard, and verification methods that demonstrate control over the hazard [32]. Harm is defined generally as physical injury or damage to people, property or the environment by IEC It is defined specifically as being injury to people by other standards. We use the general definition of IEC All definitions of harm agree that the specific harm caused by a hazard depends on the context (sometimes called the operational situation) that leads to it. Common to the above definitions is that a hazard must be defined relative to some occurrence that exposes it; without the correct context, a hazard will not cause harm. The necessary context for a hazard to cause a particular harm is known as a hazardous situation (Leveson is more specific, defining it as an operational

10 10 Geoffrey Biggs et al. phase of the system [33]). The occurrence of a hazardous situation is known as a hazardous event. A hazardous event may result in harm. A harmful event occurs when harm does occur. Safety standards define the concept of a measure to provide safety, although the term used varies. IEC names it safety function, ISO and ISO use the term protective measure, while ISO defines both safety measure and safety mechanism. In all cases, the purpose is to provide some feature of the system that eliminates or mitigates risk (most commonly by moving the system to a known safe state). Safety features must be implemented in the system design. Safety standards require evidence for which safety measures are related to which hazards. Some, but not all, safety standards explicitly define a monitoring concept [23, 24]. Some component of the system detects when a hazardous event has occurred and explicitly activates a safety measure. Many of the above concepts are also found in the results of safety analysis techniques. Some examples are given below. 1. A Preliminary Hazard Analysis identifies the potential hazards of a system based on its requirements, uses, and prototype designs, as well as external information such as hazard checklists [33]. 2. Fault Tree Analysis (FTA) [20, 34] and Event Tree Analysis [34] are both backward searchers to find the hazardous event(s) that allows some undesired event (a harmful event) to occur. 3. Failure Modes and Effects Analysis (FMEA) is a forward search that identifies the possible harm that an undesired event (typically a failure of a component or process) can cause [19, 34]. 4. Cause-Consequence Analysis looks for both the hazardous event that allows an undesired event to occur and the harm that it causes [34]. 5. Interface Analysis and Human Error Analysis techniques look for hazardous situations arising in the interfaces between system components or between the system and users [34]. User interactions are a common source of safety-related failures [27]. A profile for SysML that supports these common concepts will therefore allow the results of safety analysis techniques to be specified in the system model [9]. 3.2 Useful SysML Features This section discusses capabilities of SysML that are useful in the analysis and design of safety-critical systems. SafeML makes use of some of these features, as described in Section 3.3. SysML is a profile of UML. It reuses many diagrams and element types of the UML meta-model, and adds several diagrams and element types of its own. It also has the same level of extensibility found in UML. SysML is used in the design of systems that include software, hardware, people, processes, and other entities. SysML is building on the success of UML, with wide tooling support available. 4 4 A powerful open-source modelling tool is the Papyrus project, which adds modelling capabilities for UML, SysML, and several other languages to the Eclipse Framework. See

11 A SysML profile for safety information 11 SysML has features oriented towards system design and specification not found in UML (which is oriented towards software specification), including the capability to represent requirements and to support trade-off analyses. These capabilities make it more useful than UML for specifying the safety of a system that is not purely software. Much of the information contained in a SysML model of a system can support both the elicitation of and representation of safety information. Some examples are listed below. 1. A Preliminary Hazard Analysis (PHA) examines the system s requirements, design prototypes, and so on to look for potential hazards. A SysML model provides requirements and designs (in the form of Block Definition Diagrams and Internal Block Diagrams). 2. The ways in which a system is used are a common source of hazards and hazardous situations [32]. Both correct and incorrect usage of a system may be dangerous. The use cases in a SysML model can be analysed for hazards, while the activity and sequence diagrams that specify those use cases can be analysed, such as through Human Error Analysis techniques when the user is a human, for the specific user interactions (situations) that expose the hazards. 3. Interfaces between system components can give rise to hazardous situations [32]. SysML Internal Block diagrams and Sequence diagrams that define how system components interact can be analysed to find interface points that may be problematic. Activity and sequence diagrams describing processes and procedures (such as use case procedures) can be analysed to identify the specific hazardous situations. 4. Each safety measure must be verified as correctly managing its hazard. SysML includes element types for specifying tests that verify a requirement, and Activity diagrams can be used to specify the test procedure. 3.3 Profile description As a profile extension of SysML, the SafeML profile draws on existing SysML syntax and semantics. The element types in the SafeML profile represent the safety concepts described in Section 3.1. An illustrative instance of the profile is given in Figure 4, as an aid to understanding. This diagram depicts an instance of each element type and an instance of some of the SysML element types that they can be related to. It shows the various relationships that can occur in a SafeML model, such as the context-defined relationship between a hazard and harm it may cause, and the link from a defence to the SysML requirement it induces in the system model. The SafeML profile includes seven element types. The profile is shown in Figures 2 and 3, (note that role names are only shown where they differ from the class name) summarised in Tables 1 to 7, 5 and described below, including the relationships they have to each other and to SysML elements. The profile is organised in two parts. The first deals with hazards, harms, and the context necessary for 5 Note that the types presented here for the tagged values are an example; see Section 3.4 for details.

12 12 Geoffrey Biggs et al. class SafeML HHH «metaclass» UML::Operation SysML::Block SysML:: system element SysML:: Requirement SafeML::Harm SafeML::Hazard SysML:: SystemContext SafeML:: derivehc +derivedharmcontext safety score :SafeML::SafetyScore 1..* 1 SafeML::HarmContext probability of harm :SafeML::Probability probability of occurrence :SafeML::Probability range :SafeML::Range severity :SafeML::Severity 0..* +derivedhazard 1 SafeML:: derivehzd «metaclass» UML::Activity <<extends>> <<metaclass>> SysML::AssociationBlock «metaclass» UML::UseCase SysML::derive Fig. 2: The SafeML profile elements relating to hazardous events Table 1: SafeML::Hazard specification SafeML::Hazard Description: Represents a potential hazard. Derived from: SysML::Blocks::Block Relationship derivehzd Target and description SysML::Requirements::Requirement, SysML::Blocks::Block, UML4SysML::UseCase Indicates the source of the hazard. SafeML::Harm Indicates the potential result of the hazard and the context that leads to it. Tagged value Type Description harms to occur. The second deals with safety measures, which in SafeML are targeted at preventing the hazardous event necessary for a hazard to lead to harm, or mitigating harm should a hazardous event occur. In a model that includes SafeML elements, SysML elements are used to model aspects of the system, such as requirements (including safety requirements), use cases and components. In the descriptions below, system model refers to the parts of the model specified in SysML.

13 A SysML profile for safety information 13 class SafeML Defenses SafeML:: reqdefence SafeML::Defence probability of success :SafeML::Probability cost :SafeML::Cost SafeML::PassiveDefence SafeML::ActiveDefence 0..* 1 SysML:: derivereqt SysML:: Requirement SafeML:: reqdetection SafeML::DefenceResult probability of harm :SafeML::Probability probability of occurrence :SafeML::Probability range :SafeML::Range severity :SafeML::Severity 1 1..* SafeML::HarmContext probability of harm :SafeML::Probability probability of occurrence :SafeML::Probability range :SafeML::Range severity :SafeML::Severity SysML::Block SafeML::ContextDetector probability of true positive :SafeML::Probability probability of false positive :SafeML::Probability cost :SafeML::Cost 0..* <<extends>> <<metaclass>> SysML:: AssociationBlock <<extends>> SafeML:: detect 1..* <<extends>> «metaclass» UML::Dependency Fig. 3: The SafeML profile elements relating to defences

14 14 Geoffrey Biggs et al. bdd [Package] SafeML [SafeML Conceptual Model] Use «usecase» Case1 Use case 1 «derivehzd» 0..* «derivehzd» «system element» Block1 0..* «requirement» Requirement1 «Hazard» Hazard1 0..* «derivehzd» 0..* 0..* «activity» Activity 1 «derivehc» «system context» Block2 «derivehc» «HarmContext» HarmContext1 «requirement» Requirement2 «derivehc» «DefenseResult» DefenseResult1 tags probability of harm = X probability of occurrence = X range = X severity = X «Harm» Harm1 tags safety score = X «requirement» Requirement3 1..* «reqdetection» tags probability of harm = X probability of occurrence = X range = X severity = X «detect» «ContextDetector» ContextDetector1 tags 1..* 0..* cost = X probability of false positive = X probability of true positive = X 1..* 1..* «DefenseResult» DefenseResult2 tags probability of harm = X probability of occurrence = X range = X severity = X 0..* 0..* «requirement» Requirement4 «reqdefence» «PassiveDefence» PassiveDefence1 tags cost = X probability of success = X «ActiveDefence» ActiveDefence1 tags cost = X probability of success = X «reqdefence» «requirement» Requirement5 Fig. 4: An illustrative instance of the SafeML profile

15 A SysML profile for safety information 15 Table 2: SafeML::Harm specification SafeML::Harm Description: Represents the potential result of one or more hazards. Derived from: SysML::Blocks::Block Relationship Target and description Tagged value Type Description Safety score SafeML::SafeMLTypes:: SafetyScore Quantifies the overall risk of this harm. See Section 5.4. Table 3: SafeML::HarmContext specification SafeML::HarmContext Description: Represents a context that allows a hazard to cause a specific harm. Derived from: SysML::AssociationBlock Relationship derivehc Target and description UML::Activity, SysML::Blocks::Block, SysML::Requirements::Requirement, UML::Operation Indicates the source of the context in the system. Tagged value Type Description Probability of occurrence Probability of harm Severity Range SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Severity SafeML::SafeMLTypes:: Range Probability the context will occur. Given the context is present, the probability harm will arise. The maximum possible severity of possible harm. The maximum possible range of possible harm. It is not the goal of SafeML to model specific safety measures (such as redundant structuring of components). These can already be modelled using the existing SysML facilities. See the end of Section for more details Hazard The Hazard element represents a potential hazard. Hazards are related to system requirements, system components and system uses. These are represented in the profile by the derivehzd relationship to SysML Requirements, Blocks and Use Cases. These relationships trace the potential hazard to the parts of the requirements or design that introduce it. Given the correct conditions, a hazard may lead to harm being caused. This is indicated by a relationship to the relevant Harm(s). Each link to a Harm is characterised by the context that allows the harm to occur, described using the HarmContext element.

16 16 Geoffrey Biggs et al. Table 4: SafeML::ContextDetector specification SafeML::ContextDetector Description: Represents how a hazardous situation/event is detected. Derived from: SysML::Blocks::Block Relationship detect reqdetection Target and description SafeML::HarmContext Indicates the HarmContext that is monitored for. SysML::Requirements::Requirement Indicates the system requirement created by this detector. Tagged value Type Description Probability of true positive Probability of false positive Cost SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Cost The probability of correctly detecting the presence of a context. The probability of incorrectly detecting the presence of a context. 6 A cost value for using the detector in the system. What this cost means will vary. Table 5: SafeML::PassiveDefence specification SafeML::PassiveDefence Description: Represents defence against one or more contexts that continuously defends. Derived from: SysML::Blocks::Block via SafeML::Defence Relationship reqdefence Target and description SafeML::HarmContext Indicates a context defended against. SysML::Requirements::Requirement Indicates the system requirement created by this defence. Tagged value Type Description Probability of success Cost SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Cost The probability of successfully transforming the hazardous situation/event s characteristics, such as its probability of harm occurring. A cost value for using the defence in the system. What this cost means will vary. A hazard may cause multiple harms or cause the same harm in multiple situations. The multiplicity in the relationship with Harm elements seen in Figure 4 allows this to be represented in SafeML Harm The Harm element represents a harm that may be caused by a hazard in some specific context.

17 A SysML profile for safety information 17 Table 6: SafeML::ActiveDefence specification SafeML::ActiveDefence Description: Represents a defence against one or more contexts that requires activation. Derived from: SysML::Blocks::Block via SafeML::Defence Relationship reqdefence Target and description SafeML::HarmContext Indicates a context defended against. SysML::Requirements::Requirement Indicates the system requirement created by this defence. Tagged value Type Description Probability of success Cost SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Cost The probability of successfully transforming the hazardous situation/event s characteristics, such as its probability of harm occurring. A cost value for using the defence in the system. What this cost means will vary. Table 7: SafeML::DefenceResult specification SafeML::DefenceResult Description: Represents the result of defending against a context. Derived from: SysML::AssociationBlock Relationship Target and description Tagged value Type Description Probability of occurrence Probability of harm Severity Range SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Probability SafeML::SafeMLTypes:: Severity SafeML::SafeMLTypes:: Range New probability the context will occur. Given the context is present, the new probability that harm will arise. The new maximum possible severity of possible harm. The new maximum possible range of possible harm. Harms are not directly related to elements of the system model. The Harm element is only related to the Hazard element. A specific harm may be caused by more than one hazardous event, as represented by the multiplicity on this relationship HarmContext The HarmContext element is used to characterise the relationship between a hazard and a harm it may cause. As described in Section 3.1, a hazard requires the correct context to produce harm. This element represents one specific context that allows a hazard to cause a specific harm.

18 18 Geoffrey Biggs et al. The combination of a Hazard and a HarmContext represents a hazardous situation, or hazardous event if it occurs, which may lead to a specific harm. The combination of this hazardous situation (Hazard and HarmContext) with a specific Harm represents a harmful event. While hazards and harms may be re-used in a SafeML model, each Harm- Context uniquely identifies and characterises a specific harmful event that has the potential to occur. This allows the reuse of Hazard instances, which may cause a range of harms, and Harm instances, which may be caused by a range of hazards, in a model, while still allowing a specific harmful event to be identified by a HarmContext instance. The uniqueness of each HarmContext instance means that the characterisation of a hazardous/harmful event is represented in the HarmContext element rather than the Harm element. For example, the risk presented by a hazardous situation, or the probability of a harmful event occurring. For information on the particular information that could be stored, see Section 3.4. As the target of safety measures in a SafeML model, the HarmContext element is related to the PassiveDefence and ActiveDefense elements, and the ContextDetector element via the detect relationship. Sections 3.1 and 3.2 discussed many sources for hazardous situations. These are represented by the derivehc relationship from a HarmContext to a SysML Block, Requirement, Activity or Operation. The relationship to Activity and Operation elements is the most important. It allows a HarmContext element to be traced to the specific activity in a use case or interaction that gives rise to the hazardous situation. This can be illustrated with a simple example. Assume a system model that has a use case indicating something that an actor does with the system. As part of the system design process, the use case is specified using an Activity Diagram. The use case is also found, through a hazard analysis, to contain a particular potential hazard. The potential hazard leads to a hazardous situation during a particular step of the use case, represented by an Activity element. This activity is the context that allows the hazard to cause harm. This structure in the SafeML model allows tracing from the context to the relevant hazard and to the specific activity that may lead to harm. Tracing the context of a hazard to an activity can be further traced to the use case for that activity, and ultimately to the user role. This identifies any user roles that may need to be targeted for training to reduce risk. The relationship to SysML Block elements is also important, as it indicates the component(s) of the system that are relevant in the hazardous situation ContextDetector As described in Section 3.1, some safety standards explicitly define the concept of monitoring for a hazardous situation/event and activating the relevant safety measures when necessary. The reason for this is that a safety measure may not need to be active at all times. In these cases, the system must have the capability to detect that a particular situation has occurred that requires a particular safety measure to be activated. For example, a train signalling system may monitor for a failure and, upon detecting one, activate a safety measure that brings all trains to a halt. As in [9], SafeML contains this concept. It is represented using the ContextDetector element.

19 A SysML profile for safety information 19 A ContextDetector indicates that the system must provide some means of detecting the HarmContext it is related to. In other words, the system must provide the capability to monitor for a hazardous situation/event. The ContextDetector therefore induces one or more new safety requirements in the system s requirements. The relevant requirements are represented using SysML Requirement elements. These are related to the ContextDetector element by the reqdetection relationship. This relationship is necessary for traceability: It ensures that the ContextDetector is linked to a requirement, which is in turn linked to SysML Block elements for implementation and SysML TestCase elements for verification. The ContextDetector element also has the detect relationship described in Section A ContextDetector may detect multiple contexts Defences Safety measures in SafeML target hazardous/harmful situations/events, either to prevent their occurrence or to mitigate the potential for or severity of harm should one occur. Safety measures are represented using Defence elements. SafeML uses two element types for defences. The first, PassiveDefence, specifies a safety measure that does not require explicit activation. The second, ActiveDefence, specifies a safety measure that must be explicitly activated to protect against a HarmContext. The term passive is not related to the concept of inherent safety; it does not mean that the defence does not do anything actively, such as a switch cover. It refers to the idea that the defence does not need explicit activation to improve the safety of the system, but instead provides safety constantly: It is continuously working, where what working means depends on the safety measure the aforementioned switch cover is working merely by existing. A safety measure that must be continually active to maintain the system in a safe state is a passive defence. A safety measure that only activates when a hazardous event is detected is an active defence. Although there are no technical differences between the PassiveDefence and ActiveDefence elements, they can be used by tools to guide the developer. For example, an ActiveDefence instance may place a requirement on the model that its related HarmContexts each have at least one ContextDetector. The concept is that a ContextDetector will, upon detecting a HarmContext, activate each active defence connected to that HarmContext; ActiveDefense instances connected to other HarmContext instances that use the same context detector will not be activated. In both the active and passive case, a defence is related to its relevant hazardous event (HarmContext) by a relationship characterised by the DefenceResult element. A defence may be related to multiple HarmContext instances, indicating that it is capable of defending against multiple hazardous situations. As with the ContextDetector element, PassiveDefence instances and ActiveDefence instances indicate that the system must have some means of providing those safety measures. This is represented by the reqdefence relationship to a SysML Requirement. This ensures traceability from a safety measure to the

20 20 Geoffrey Biggs et al. SysML Block elements that implement it and the SysML TestCase elements that verify it. Additionally, traceability from the originating hazard to the implementation and verification of safety measures used is supported. This is achieved by a path from the requirement, use case or system component in which the hazard originates, through the Hazard itself, the relevant HarmContext, through the Defence that counters it, through the related Requirements, and finally to the system components that implement those requirements and the test cases that verify those requirements. Figures 4 and 12 give examples of complete traces. The design of a defence can be represented using the existing SysML capabilities. The Defence elements specialise the SysML Block element, which means that they have all the capabilities of a Block, including being decomposed into sub-components specified using SysML Block elements, and having behaviour specified through activity and sequence diagrams. 7 However, it is possibly preferable, given the use of a defence to add a safety requirement to the model (as seen in Figure 4 and Section 4) to add additional blocks that satisfy the safety requirement and so implement the defence in that way. For example, an existing implementation of a system capability may need to be made redundant, according to a PassiveDefence and its related safety requirement. This can be specified in its design using SysML Block elements that duplicate functionality, behaviour diagrams for the handling of switching, and so on. Traces from the PassiveDefence through its safety requirement to the Block elements implementing the redundancy ensure that the reason for the redundancy is knowable DefenceResult When a safety measure acts against a hazardous event, it may affect the event s chance of occurring, the chance of harm arising if the hazardous event occurs, and the range and severity of any harm that does arise. For example, a safety measure may prevent the system entering the situation necessary for harm to occur. Alternatively, it may have no effect on the chance of harm occurring, but limit the severity of that harm. The specific effect of a safety measure is specified by the DefenceResult element, which characterises the relationship between each pair of a single Defence instance 8 and a HarmContext instance. The DefenceResult element is characterised by the same values as the HarmContext. These can be used by tools to evaluate the result of a safety measure on the risk presented by a hazardous situation or event. The developer will specify the values that change and support tools will assume the remainder are the same as the original values from the related HarmContext. See Section 3.4 for the information stored. 3.4 Tagged values A SysML element may have a number of tagged values. A profile specifies tagged values that may appear in its elements and gives them semantic meaning. 7 Defence elements should not be decomposed into further Defence elements; this has no semantic meaning in SafeML. 8 SafeML treats defences as independent.

21 A SysML profile for safety information 21 bdd [Package] SafeML [SafeML Types] «modellibrary» SysML::PrimitiveValueTypes «modellibrary» SafeML::SafeMLTypes «import» «ValueType» Real «ValueType» Probability «ValueType» Range «ValueType» Severity «ValueType» SafetyScore «ValueType» Cost Fig. 5: The types used for tagged values in the SafeML elements The SafeML profile specifies tagged values for a number of its elements. They are described in Tables 1 to 7. Although specified by the profile, the tagged values made available by SafeML are relatively independent of the profile structure (the available elements and their relationships). While the element structure defines safety concepts and how they relate to each other, the tagged values are mainly defined by what tools wish to do with a model. The tagged values used in this paper are defined in part to support the tools described in Section 5. For example, a tool to calculate risk as a product of probability of harm and severity would rely on these values. As in [53], the acceptable values that tagged values may use (such as numbers or specific text) are defined by the tool support. In the tool presented in this paper, the values of all tagged values are specified using textual values that are referenced to enumerations provided by the developer. For example, the developer can specify that all probabilities are specified as one of low, medium, or high. Alternatively, they may prefer numerical values for the probability, such as a value between zero and one. As the type of probability usable in safety varies considerably by field, it is important to allow the tool support to define the acceptable tagged values. An example of using a model library of types for the tagged values is shown in Figure 5; these types are also used in the profile as presented in this section. However, we stress that, in this respect, SafeML should be treated as a Platform Independent Model (a model that is independent of any particular implementation), with the version used by a tool, with its chosen specific types, a Platform Specific Model (the Platform Independent Model after it has been adapted for a specific implementation platform, which in the case of SafeML is a project s and tool s needs). The Platform Specific Model will choose appropriate types and values for the tagged values according to the needs of a project, such as those dictated by relevant safety standards and the support tool used.

22 22 Geoffrey Biggs et al. See Section 5.1 for more details on tool support using specific types for the tagged values (in the case of this paper s tool, SysML enumerations). 3.5 Supporting documentation A SysML model can link external documents into the model, such as a textbased list of system requirements. As a SysML profile, SafeML gains this ability. It is recommended for use in linking external risk analysis documentation into the system model to support the addition of SafeML elements. For example, a Preliminary Hazard Analysis document that supports adding some hazards to the model, or the Fault Tree that identifies a context, can be linked in. 3.6 Development process SafeML is a modelling language extension. It places few requirements on the methodology and processes used for system development. These limited requirements are: 1. that safety information relating to the system design is available from safety analyses, international standards, and other relevant sources; 2. that system design information is available and can be modelled using SysML; and 3. that the system design can be revised based on the safety information. SafeML fits into any methodology providing this information. SafeML should be utilised when at least some part of the system design is available and safety analyses have been performed. It is used as part of the design steps that evaluate the relationship between the safety analyses results, and design safety measures. As with SysML, SafeML fits into an iterative methodology as well, with additional revisions of the system design (modelled using SysML), safety analyses, and the modelled safety information (modelled using SafeML). The information modelled in SafeML can be used at any time when the safety information about a design must be presented to stakeholders or other developers. A particularly important issue is maintaining the consistency of information when process steps repeat. For example, revising a risk analysis may have an impact on the safety information contained in the model and its related system design information. Tracing between SafeML and SysML elements helps maintain consistency between safety information and system design information when information sources change. Tool support is necessary to make this task manageable. Many modern SysML modelling tools have support for performing a traceability analysis to find the parts of a model impacted by a change, such as tracing between the requirements contained in the model and their implementations and tests. Tracing to source analyses (i.e. external documents) is a more difficult problem, but tool support for linking model elements to external documents can be an aid. These traces can be used to find all model elements relying on an external document (such as a risk analysis) that has changed. The tool support presented in Section 5 does not address this problem directly, instead relying on the existing capabilities of the Enterprise Architect tool.

23 A SysML profile for safety information 23 4 Example Application To demonstrate that the profile is capable of modelling the discussed safety concepts, this section provides an example of applying SafeML to a SysML model of a system. It demonstrates adding safety-related information revealed through a Fault Tree Analysis to the SysML model to produce a system model that includes the relevant safety-related information. This information includes both the hazardous situations and events that the system is vulnerable to and the ways in which the system protects against those situations/events. We only present a part of the complete system in this paper. Parts of this example will be used to illustrate the support tools in Section 5. The example system is an electric kettle; this device was chosen for its simplicity to enable a clear presentation of SafeML. Electric kettles and similar devices are regularly used as teaching aids for UML and SysML. 4.1 Development Process The process used to develop the example system is described below. This is a simple, high-level process that gives one example of how SafeML may be used during development of a safety-critical system. 1. Develop the system requirements and use cases, modelling them in SysML using Requirements diagrams, Use Case diagrams and Activity diagrams as appropriate. 9 Develop a prototype system design and model it in SysML. 2. Perform hazard and safety analyses on the requirements, use cases and design concept. Enter the resulting hazard, harm and hazardous/harmful situation/event information into the model using SafeML elements. 3. Identify safety measures and their effects, and add them to the model using SafeML elements. 4. Connect the safety measures to requirements specified in SysML and added to the system requirements (safety requirements). Connect these to the SysML Blocks in the design that implement them, and specify tests to verify correctness. 5. Iterate as necessary to identify additional hazards added by the safety measures or when refining the system design. 4.2 Example system This section describes the system to be analysed and improved. The example system is an electric kettle. The kettle has only a very simple functionality to begin with: When a switch is turned on, the kettle begins heating water. Heating stops when the switch is turned off. The use cases of the system are shown in Figure 6. The initial system design focuses solely on functionality and is therefore very simple. The scenario for boiling water is given below. 9 It is common practice in SysML to only represent top-level requirements in Requirements diagrams, with the remainder entered in a tabular view of the model.

24 24 Geoffrey Biggs et al. uc [Package] Electric kettle [106 Use cases] Class:ElectricKettle Put water in kettle <<block,external>> WaterTap Boil water <<block,external>> PowerPoint Stop boiling Pour water <<block,external>> WaterDestination Fig. 6: Electric kettle use cases 1. The user opens the lid, fills the kettle s tank with some quantity of water, and closes the lid. 2. The user connects a supply of electricity and turns a switch on. 3. The kettle, as long as electricity is flowing, converts that electricity to heat and applies the heat to the water contained in the tank. 4. The user watches for the water to reach the boiling point and then turns the switch off, cutting off the supply of electricity and halting the boiling process. 5. The user pours the boiled water from the kettle s tank into a target container. The boil water use case is expanded into the activity diagram shown in Figure 7. The Pour water use case is expanded into the activity diagram shown in Figure 8. The logical design of the kettle designed to meet the use cases and requirements is shown in Figure 9. Although the system model contains a number of other diagrams, we omit them here for space reasons. 4.3 System risks A simple hazard analysis finds the following potential hazards and harms. 1. Electricity, which may cause electrocution or an electrical fire. 2. Heat, which may cause heat burns (e.g. by touching a hot object). 3. Steam, which may cause steam burns. 4. Boiling water, which may cause water burns.

25 A SysML profile for safety information 25 act [Package] Electric kettle [108 Boil water] :User :PowerPoint :ElectricKettle :Environment Plug in kettle Activate boiling Begin dispensing electrical energy :Electricity <<continuous>> :Electricity <<continuous>> :Heat Boil water :Boiling status :Steam :Noise <<continuous>> Wait for boiling to finish :Boiling status <<continuous>> <<continuous>> [not finished] [finished] Deactivate boiling Boiling deactivation :Command <<continuous>> Stop boiling Unplug kettle Stop dispensing electrical energy Fig. 7: The SysML Activity diagram for the Boil water use case A Fault Tree Analysis is performed on each harm to identify the possible ways in which it may come about. The fault tree for the water burns harm is shown in Figure 10 (likelihood information is omitted). Analysis of this fault tree finds several minimum cut sets that can lead to water burns, including: 1. the lid leaking while pouring boiling water; 2. the kettle boiling over due to too much water; and 3. the kettle boiling over due to a failure by the user to turn it off. 4.4 Modelling the hazardous events Based on the safety analysis results, the relevant safety-related information can be added to a SysML model of the electric kettle. When modelling the safety-related information, the developer must: 1. specify the relevant hazard, including the aspect(s) of the system (requirement, use case and/or system component) that gives rise to it; 2. specify the possible harm; and

26 26 Geoffrey Biggs et al. act [Package] Electric kettle [110 Pour water] :User :ElectricKettle :WaterDestination Hold spout over destination Tilt kettle towards spout Dispense water <<continuous>> :Water :Water Receive water :Water quantity Wait for sufficient water dispensed [not sufficient] :Water quantity <<continuous>> [sufficient] Return kettle to the level Fig. 8: The SysML Activity diagram for the Pour water use case ibd [Package] Electric kettle [125 Kettle logical connections] :Electrical assembly BoilingControl BoilingControl :Switch ElectricityControl ElectricityControl :Electrical assembly Ein :Electricity Eout :Electricity E :Electricity BoilingStatus BoilingStatus :Boiling status indicator E :Electricity :Water tank E :Electricity WQ :Water quantity WQ: Water quantity Win :Water Wout: ~Water :Spout Win :Water Win: Water Wout :Water Wout :~Water ExcessHeat :Heat Noise :Noise ExcessHeat :Heat N :Noise Fig. 9: The SysML Internal Block diagram for the initial kettle design

27 A SysML profile for safety information 27 Water burns Contact with water Water is hot Water leak from tank Over-boiling Pouring water by tilting kettle Water spills Boiling too long Boiling too much water Pour water guidance Lid leak Lid failure Fig. 10: The fault tree for the water burns harm 3. specify the context that allows harm to be caused, including the aspect(s) of the system (requirement, activity and/or system component) that produces that context. When modelling this information, hazards and harms come from hazard/risk analyses, while contexts come from analyses that identify how accidents may happen, such as FTA, FMEA, etc. For example, to transfer the results of the hazard analysis and Fault Tree Analysis from the previous section into the SysML model of the system, the following steps are necessary. 1. Identify the relevant hazards and the potential harms they may cause. Each hazard must be added to the model using a Hazard element, and each potential harm must be added using a Harm element. 2. Identify the minimum cut sets in the fault tree. Each minimum cut set represents a context that may lead a hazard to cause a particular harm. 3. For each minimum cut set, a HarmContext is added to the model to relate the relevant hazard and harm. For this example, we shall concentrate on the boiling water hazard, the water burns harm, and the lid leak and over-boiling contexts. These are shown in their SafeML form in Figure 11. In Figure 11a, the activity Tilt kettle towards spout indicates an action that may lead to harm, while the block Lid indicates a system component relevant to the potential for harm during that activity (in this case, a component whose failure during the activity could lead to harm). Note that the two diagrams in Figure 11 could be combined into one. However, we split the information into separate diagrams to improve clarity. 10 We will now describe the displayed model elements. 10 The ability to alter how information is presented without altering the underlying structure of the model is a benefit of describing safety information in a model.

28 28 Geoffrey Biggs et al. bdd [Package] Electric kettle illustrative diagrams [Lid leak] «requirement» Make water available «derivehzd» «Hazard» Boiling water «HarmContext» «Harm» Water burns «derivehzd» «usecase» Pour water «activity» Tilt kettle towards spout «derivehc» «HarmContext» Lid leak while pouring «derivehc» «block» Lid (a) The lid-leak hazardous event bdd [Package] Electric kettle illustrative diagrams [Over-boiling] «requirement» Boil water «derivehzd» «Hazard» Boiling water «HarmContext» «Harm» Water burns «derivehzd» «usecase» Boil water «activity» Boil water «derivehc» «HarmContext» Over-boiling due to failure by user to deactivate «derivehc» «activity» Wait for boiling to finish (b) The over-boiling hazardous event Fig. 11: Two hazardous events modelled using SafeML The Boiling water element is an instance of the Hazard element type (Section 3.3.1). It is derived from the requirements and use cases that lead to its presence. In each of the two diagrams shown here, we have shown only the relevant requirement and use case. The Water burns element is an instance of the Harm element type (Section 3.3.2). Note that, as with the Boiling water hazard element, the same element is present in both diagrams; there is only one Harm instance called Water burns in the model. In both diagrams, the harm is connected to the source hazard by a context that can bring it about. In Figure 11a, this context is the lid of the kettle leaking water. As the diagram shows, this context arises in the system due to the user extracting water by tilting the kettle combined with the presence of a lid. 11 The hazardous event is characterised in the HarmContext element as having a high probability of context occurrence and a medium probability of harm occurrence (not shown on the diagram and based on the kettle having a simple plastic lid). In Figure 11b, the context that allows harm to arise is over-boiling of the water due to the user not deactivating the kettle once boiling is complete (recall from Section 4.2 that this kettle does not deactivate automatically). This context arises from the Boil water activity of the kettle and the Wait for boiling to finish activity of the user. 11 If the kettle did not have a lid covering the water tank, we might find a context for water burns due to the ease of spilling water out of an uncovered tank while pouring.

29 A SysML profile for safety information Improving the system The developer s next step is to design counter-measures. SafeML diagrams showing the relationships between the hazardous situations/events and aspects of the system allow the developer to target the sources of hazardous situations/events in the same way as a minimum cut set from a Fault Tree Analysis does. SafeML assists the developer by presenting this information close to the system design information. In our example system, there are several hazardous situations and events that need to be dealt with. We will deal with the two discussed in the previous section. The diagrams for these are shown in Figure 12. These two views both show the hazard documentation for a specific harmful event. This includes the potential hazard, the related system requirements and uses, the hazardous event, the safety measures used, and the verification methods Lid leak We shall first deal with the simpler context of the lid leak. As Figure 12a shows, we have chosen to prevent lid leaks by adding a seal to the lid. This is modelled in SafeML using an instance of the PassiveDefence element type. Note that, due to its passive nature, the defence is constantly functioning, and no ContextDetector elements are necessary. The relationship between the defence and the context is characterised by a DefenceResult instance that specifies the effect of the defence. In this case (not shown on the diagram), it reduces the probability of the context occurring from high to low. It does not alter the chance of harm should the context occur, as it is assumed that a lid leak allowing water to escape will have the same probability of burning the user whether or not the lid has a seal. As Figure 12a shows, the newly-added defence has led to changes in the system design. It introduces a new requirement, to add a watertight lid seal, which leads to a Seal component being added to the Lid component, in addition to a verification test that confirms the seal protects against lid leaks. As with any SysML model, the testcase element instance can contain a detailed description of how to perform the test. This diagram illustrates the benefit of using SafeML to connect hazardous situations/events with system features. It is possible to trace from the source hazard and possible harm, through the context where harm may arise, through the defence concept, and to the specific system features that protect against the situation/event and the tests that must be done to assure those features are sufficient. Although the elements such as blocks and requirements also appear on other diagrams in the model, placing the related elements together on a single diagram like this communicates a single hazardous situation or event and defence concept clearly.

30 30 Geoffrey Biggs et al. bdd [Package] Electric kettle illustrative diagrams [Lid leak defence] «requirement» Make water available «activity» Tilt kettle towards spout «block» Lid «block» Seal «usecase» Pour water «derivehzd» «derivehzd» «Hazard» Boiling water «derivehc» «derivehc» «satisfy» «requirement» Watertight lid seal «reqdefence» «verify» «testcase» Seal is watertight «HarmContext» «HarmContext» Lid leak while pouring «DefenceResult» «PassiveDefence» Sealed lid «Harm» Water burns «DefenceResult» Sealed lid result (a) The defence against lid leaks bdd [Package] Electric kettle illustrative diagrams [Over-boiling defence] «requirement» Boil water «derivehzd» «Hazard» Boiling water «activity» Boil water «usecase» Boil water «derivehzd» «HarmContext» «derivehc» «HarmContext» Over-boiling due to failure by user to deactivate «DefenceResult» «ActiveDefence» Auto cut-off «detect» «Harm» Water burns «ContextDetector» Water status sensor «DefenceResult» Auto cut-off result «reqdefence» «reqdetection» «requirement» Detect water status «derivereqt» «requirement» Automatic cut-off «verify» «testcase» Sensor correctly detects water status «satisfy» «block» Water status sensor «derivereqt» «requirement» Automatic switch control «verify» «testcase» Sensor correctly detects water status «satisfy» «block» Water status sensor (b) The defence against over-boiling Fig. 12: Two defences modelled using SafeML Over-boiling The case of over-boiling requires a more complex defence. 12 We have chosen to defend against over-boiling by adding the auto-cut-off system shown in Figure 12b. 12 Although it could be possible to deal with it by placing a prominent warning on the kettle about watching the boiling process constantly, we are assuming for this example that such a defence will not provide sufficient safety.

31 A SysML profile for safety information 31 act [Package] Electric kettle [108 Boil water] :User :PowerPoint :ElectricKettle :Environment Plug in kettle Activate boiling Begin dispensing electrical energy :Electricity <<continuous>> :Electricity <<continuous>> :Heat Boil water :Boiling status :Steam :Noise <<continuous>> Wait for boiling to finish :Boiling status <<continuous>> <<continuous>> [not finished] Unplug kettle [finished] Stop dispensing electrical energy Note changed activity: auto-shut-off eliminates the user's required kettle deactivation step. Fig. 13: The improved SysML activity diagram for the Boil water use case In this case, the defence is active, indicated by it being an instance of the ActiveDefence element type. This implies the need for a feature in the system to activate the defence. We have chosen a water status sensor, indicated in the diagram by an element of the ContextDetector type. As with the lid seal defence, Figure 12b shows how the detector and the defence are implemented and tested in the system via the new requirements they induce. The addition of this defence is more complex than a simple lid seal, so it has consequences for other parts of the system model. First, the activity diagram for the Boil water use case must be updated to reflect the new method of interacting with the system: the user is no longer required to manually deactivate the kettle. The revised activity diagram is shown in Figure 13. As the original diagram in Figure 7 shows, the user is responsible for monitoring the kettle and deactivating boiling at the appropriate moment. This leads to a relatively complex user interaction and the hazardous event of over-boiling, as discovered by the safety analysis. User interactions are a common source of safety-related failures [27]. This defence has reduced the complexity of the interaction, improving safety. The automatic cut-off system also requires changes to the connections between components, such as a connection from the new water status sensor to the switch trigger. The improved system structure is given in the revised Internal Block diagram, shown in Figure 14. In order to improve presentation of the safety information further, UML comments are used in the revised diagrams to explain changes made to improve safety. During design review meetings, the old and new versions of diagrams should be used to explain design changes made in response to safety analysis results. These

32 32 Geoffrey Biggs et al. ibd [Package] Electric kettle [125 Kettle logical connections] :Electrical assembly BoilingControl BoilingControl :Switch ElectricityControl ElectricityControl :Electrical assembly Ein :Electricity Eout :Electricity E :Electricity InternalBoilingControl BoilingStatus :Boiling status indicator BoilingStatus E :Electricity :Water tank E :Electricity InternalBoilingControl Win :Water Win: Water Wout: ~Water :Spout Win :Water Wout :Water Wout :~Water WQ :Water quantity WQ: Water quantity ExcessHeat :Heat :Heat insulation EHin :~Heat EHout :Heat ExcessHeat :Heat S :Steam :Steam vent Sin :~Steam Sout :Steam S :Steam Noise :Noise N :Noise Fig. 14: The SysML Internal Block diagram for the improved kettle design diagrams, with their embedded explanatory notes, can be used along with the SafeML diagrams for this purpose. At this point, the developer has completed revising the system in response to safety analysis results. The next step depends on the development process in use. For example, additional safety analyses and design iteration may occur. 4.6 Laser Pointer A second, small example demonstrates that, as well as the new safety feature modelling described above, SafeML can also model constraints derived from hazardous situations and events. The system is a laser pointer. The risk with such a system is that the user may look directly into the laser, causing damage to their eyesight; this hazardous event originates in the system with the requirement to produce a laser and the presence of a laser diode. The defence is to limit the laser s output power to a safe level. This limit forms a safety constraint on the laser diode, illustrated in Fig. 15.

33 A SysML profile for safety information 33 bdd [Package] Laser pointer [Laser hazard] «requirement» Produce a laser beam for pointing at things «block» Laser pointer «testcase» Seal is watertight «verify» «derivehzd» «satisfy» «Hazard» Laser «block» Laser diode «satisfy» «requirement» The laser power shall be limited to 1mW «reqdefence» «HarmContext» «HarmContext» Person looks directly at laser «DefenceResult» «PassiveDefence» Limit laser power «Harm» Damage to eyesight «DefenceResult» Laser power limit result Fig. 15: Defending against a laser s output power 4.7 Defence failures SafeML is capable of representing three aspects of defence failure. The first aspect is the case of a complete defence failure. This is modelled through the information contained in the HarmContext element. If the defence completely fails to mitigate the risk, then the probability of a harmful event, the severity of the harm caused, and so on are assumed to be at their original levels as specified in the HarmContext element. In other words, a defence failure is equivalent to that defence not existing. 13 The second aspect is a partial failure. In this case, the defence may still have some mitigation. This can be modelled in two ways. 1. Modelling the defence s possible mitigation as being the partially-failed mitigation, with a lower chance of failure (in other words, declaring a partial failure to be a form of success). A failure of a defence modelled in this way will mean zero mitigation, or a complete failure rather than only a partial failure. 2. Modelling the defence using two defence elements. The first models the successful defence, while the second models the partially-failed defence. Both would be related to the same requirements, blocks, etc. as appropriate. The third aspect is the impact of a failed defence. This can be modelled through an explicit modelling of the hazardous event of the defence failure. This can be used, for example, if a defence failure produces a different harmful event than a mere lack of defence, or to provide a more explicit depiction of defence fault tolerance. The example from the previous section can be extended as shown in 13 A system may have multiple defences in place in case one fails.

34 34 Geoffrey Biggs et al. bdd [Package] Laser pointer [Laser limiter breakdown] «Hazard» Laser «derivehzd» «block» Laser diode «satisfy» «requirement» The laser power shall be limited to 1mW «derivehc» «reqdefence» «HarmContext» «HarmContext» Laser limiter failure «PassiveDefence» Limit laser power «Harm» Damage to eyesight Fig. 16: Explicitly modelling the hazardous event of a defence failure Figure 16 to demonstrate explicitly modelling the hazardous event of the laser s power limiter failing, although in this example the consequences are the same as if the defence were not present. This method of explicit modelling is possible because SafeML relies on SysML elements where possible. A defence is actually implemented in the system design by SysML Block and Requirement elements. These can in turn be linked to Hazards and HarmContexts of their own. SafeML does not deal with the non-safety-related consequences of defences, failed or not. 5 Developer Support Tools SafeML is a modelling language extension. As with any modelling language, tool support plays a role in its usefulness. For example, alternative views of modelled information can enable readability of the modelled information by people who do not understand the diagrammatic representation. We have devised a variety of simple tools to both support the developer in working with SafeML models and to make use of the safety information specified in a system model using SafeML. This section describes these tools. Like SafeML itself, the tools described in this section can be used at any appropriate point in a methodology where working with safety information modelled in SafeML is required. The tools in this section have been implemented as a plug-in for Enterprise Architect To support this, the SafeML profile was also implemented for Enterprise Architect

35 A SysML profile for safety information 35 bdd [Package] Electric kettle [105 SafeML tool enumerations] <<enumeration,safeml_enum_severity>> Types::Severity S0 S1 S2 S3 <<enumeration,safeml_enum_severity>> Types::Range Noone One Few Many <<enumeration,safeml_enum_severity>> Types::Cost Cheap Expensive <<enumeration,safeml_enum_severity>> Types::Probability Low Medium High Fig. 17: The enumerations used in the electric kettle model 5.1 Enumerations Before describing the tool support, the values placed in tagged values by the model developer (see Section 3.4) must be described. Rather than insisting on numerical values for probabilities, severity levels, etc., the support tools allow the developer to use values that are appropriate for their application. This is achieved by requiring the developer to provide a set of SysML enumerations defining the allowable values for specific types of tagged value. 1. The allowable severity levels, such as levels specified by a relevant standard. 2. The allowable range levels, such as levels specified by a relevant standard. 3. The allowable values for probabilities, such as a set of likelihood levels based on the reliability of available data. 4. The allowable cost values, based on how cost is measured. The enumerations used in the electric kettle model are displayed in Figure 17. The enumerations are used by the support tools described in this section, such as for performing calculations on probabilities by converting probability levels into normalised numeric values based on the number of levels. 5.2 Alternative model views Although modelling languages are typically displayed using a graphical notation, the information contained in a model can also be presented in textual form (see Section 5.3) and in tabular form. Alternative model views can be useful for isolating an aspect of the system that the developer wishes to focus on. The IBM Rational Harmony for Embedded Real-Time Development tool includes a Safety and Reliability view, which shows structurally redundant elements and their interactions [9]. An extension of that tool, combined with a UML profile for modelling Fault Trees, provides additional views, including a matrix of faults and their sources, and a matrix of faults and detectors for them.

36 36 Geoffrey Biggs et al. A commonly-used alternative view in SysML is a tabular view of requirements. Because the number of requirements is often very large, it is not feasible to display them all graphically. Instead, the majority are entered and viewed in a tabular format similar to other requirements management software. Only requirements where the structuring is of particular interest, such as high-level requirements, are displayed in Requirements diagrams. A similar approach can be used in SafeML when the number of hazards or contexts is very large, with individual diagrams used when a specific hazardous/harmful situation/event and its safety measures are inspected. For example, a tabular list of the HarmContexts present in the model, along with each tagged value in additional columns, can be presented to the developer. New HarmContexts are entered much like entering them in a spreadsheet. Relationships can be specified using a matrix view. The plug-in tool for Enterprise Architect provides several alternative views of the SafeML elements. A table of the hazardous situations and events in the model, along with how they are defended, the probability of occurrence, and so on is used to get an overview of the safety situation. Each harm plus harm context is given its own block, within which each row is for an individual defence. The values for probability, severity, and so on are taken from the DefenceResult of each defence to show the effect of the defence. For comparison purposes, the raw values of the undefended hazardous situations and events are also shown in a separate row. Hazardous events (HarmContexts) without defences are highlighted to make their presence obvious to the developer. This table gives a quick overview of the safetyrelated aspects of the system and assists the developer in choosing which area of safety to work on next: The developer can view the table to find the hazardous situations/events that do not yet have defences (they are highlighted in red), or to target those that have a particularly high severity value, for example. An example of this table for the electric kettle sample (see Section 4) is shown in Figure 18. Note that this table shows information not always presented in graphical views (that is, the tagged values of the elements). A table of the defences used by the system provides a view of the safety features in the system design. It presents each defence along with the context it defends against, context detectors used (if present), and the probabilities involved. A similar table provides a view of the context detectors present in the system; these are the safety features related to sensing dangerous situations. A relationship matrix is a view commonly used in modelling to get an overview of the relationship between elements of two different types. For example, a frequentlyused view for SysML models is a matrix depicting the satisfy relationship between blocks and requirements [12]. Two relationship matrices provided by the plug-in tool give overviews of the relationships between pairs of elements. The first shows harms and the defences related to them. An example of this view is shown in Figure 19. The second shows harm contexts and the defences against them. An example of this view is shown in Figure 20. In both matrices, the cells of the matrix contain the safety score (see Section 5.4) of the defence for that harm or harm context. If no defence is related to the harm/harm context, that column is highlighted to make the absence visible to the system and safety engineers.

37 A SysML profile for safety information 37 Fig. 18: The harms table

38 38 Geoffrey Biggs et al. Fig. 19: The harms defences relationship matrix Fig. 20: The harm contexts defences relationship matrix Some of the alternative views discussed above show possible gaps in the model by highlighting hazardous situations and events that have no related defence. In this way, the tool uses the SafeML-modelled safety information to communicate to the developer the safety of the system design and assist them in adding safetyrelated features. However, it is important to note that the lack of a defence is not necessarily a problem; reviews of the system design and safety information should determine if a hazardous situation or event requires defending against. Risks with sufficiently low probability are frequently ignored (with justification) during safety-critical system development. As mentioned in Section 3.3.5, ActiveDefences should have at least one context detector for each HarmContext they are linked to. The Defences view supports this concept by highlighting active defences that are linked to a Harm- Context which itself does not have any ContextDetector element instances attached. This is an example of the importance of tooling in supporting the system engineer, by helping to ensuring that the system design is correct.

39 A SysML profile for safety information 39 Harms report for:electric kettle[v.1.0] Report generated by:geoffrey Biggs[System engineer] Harms Report Document for 1.Electrical fire Safety score: 0.67 Hazard: Electricity Sources: 1.1.Harm Context: Contact between water and live electrical components Probability of occurrence: High Probability of harm: Medium Range: Many Severity: S3 Sources: - [Block] Electric element Electric kettle 1.0 Model date: Report date: 2013/02/ /02/ Harm Context: Short circuit of live electrical components Probability of occurrence: Low Probability of harm: High Range: Many Severity: S3 Sources: - [Block] Switch - [Block] Electric cable Model author(s): Geoffrey Biggs[System engineer],takeshi Sakamoto[System engineer] Model created: 2012/04/17 Report generated by: Position: Geoffrey Biggs System engineer Signature: 1 Model created: 2012/04/17 Last updated: 2013/02/15 Report generated: 2013/02/15 Fig. 21: A report generated from SafeML information Figures 19 and 20 demonstrate the importance of using the correct view for the task: The former does not show important gaps in the defences of the system (it shows only that all harms are defended against), while the latter does by being more specific and showing the hazardous situations/events that are defended against. 5.3 Report generation A report generator tool generates documentation from a SysML system model with embedded safety information specified using SafeML. It is possible to generate a range of reports from SafeML information, such as: 1. a catalogue of the hazards, contexts and harms that the system presents; 2. a list of the hazardous situations and events involved in using the system with the probability that each type of harm will occur (given the necessary probability information in the model); 3. a report of the defences used by the system, including the effect they have on the hazardous situations and events they target; 4. a list of all hazardous situations and events in the model that have no defence; 5. a list of the tests, with the detailed test methods, that must be performed by a testing centre to ensure the system correctly defends against the hazardous situations and events that its design claims it does; 6. a list of the safety-critical requirements for the system, constructed by finding all requirements that are related to Hazards, HarmContexts, ContextDetectors or Defences; and