Build Safety-Critical Designs with UML-based Fault Tree Analysis - Defining a Profile
A profile is a coherent set of lightweight extensions to the UML, creating a version of the UML specialized for some purpose or problem domain. A profile can contain a number of things, including stereotypes, tags, constraints, new diagram types, iconic representations, and model libraries.
Each stereotype within a profile must extend a metaclass from the UML metamodel, such as Class, Event, or Association. The stereotype is usually elaborated with metadata stored in named tags, constraints on its usage, and graphical iconic depictions.
For example, in the SysML profile, a flow port is a stereotype of port that applies to flows. New types of diagrams may be created that represent collections of these elements for specific purposes.
For example, in the UML Profile for DoDAF and MoDAF (UPDM), and OV-2 product is a diagram based on a UML class diagram that specifically contains stereotyped elements from the UPDM to show operational nodes within an operational architecture and their relations.
In this context, I will use the IBM Rational Rhapsody tool to create a safety analysis profile that adds new stereotyped elements to create fault tree analysis (FTA) diagrams and custom matrix and tabular views to summarize the results of the analysis.
In addition, I will extend the typical definition of FTA elements to support traceable links from the FTA model into both requirements and design elements. However, any UML tool that supports UML profiling mechanisms should work.
|Figure 1: Safety Profile Metamodel|
Before a profile can be created, it is necessary to characterize the concepts contained within the profile and how these concepts relate to each other. This is usually done with a metamodel. A metamodel is a model of the fundamental concepts and their relations for a domain or subject matter.
Figure 1 above shows the metamodel for the Safety Analysis Profile (the metasubtypes of Logical Operator are detailed in Figure 2 below). The attributes of the metaclasses will end up as tags on our defined stereotypes. The colored boxes are the relations between the core metaclasses.
|Figure 2: Metasubtypes of Logical Operators|
The key elements for the metamodel (along with their profile realizations) are:
Hazard - a condition that will lead to an accident or loss. This is usually the top terminal element in an FTA. (Stereotype of Class)
Fault - the non-conformance of an element to its specification or expectation. Faults are further subclassed into Basic Faults and Undeveloped Faults. These are usually the bottom terminal elements in an FTA. (Stereotype of Class)
Resulting Condition - the condition resulting from a combination of faults and conditions, combined with logical operators. (Stereotype of Class)
Required Condition - A condition required for the fault to interact. (Stereotype of Class)
Logical Operator - one of several logic conjunctives, such as AND, NOT, OR, etc. Note that Transfer operator actually has no semantics of its own but is used as a "diagram connector", allowing large FTAs to be broken up across multiple diagrams. (Stereotype of Class)
Logic Flow - the connection of a fault, condition or hazard to a Logical Operator. The logic flow can be an input or an output. For example, in the statement A || B --> C, there is a flow output from A as an input to the || (OR) operator. There is also an output from flow the || operator to the resulting condition C. (Stereotype of Flow).
Fault Source - this is a normal UML element that could manifest a fault, i.e. that could be the source of a fault. (Stereotype of Class)
Safety Measure - this is a normal UML element that could detect or extenuate (i.e. mitigate) a fault. (Stereotype of Class)
Manifest relation - this is a relationship from a Fault to a Fault Source that causes the fault (Stereotype of Dependency)
Detect relation - this is a relation from a Fault or Hazard to a Safety Measure that can detect when the fault has occurred. (Stereotype of Dependency)
Extenuates relation - this is a relation from a Fault or Hazard to a Safety Measure that reduces either the likelihood or severity of the hazard or fault. (Stereotype of Dependency)
Trace To Requirement - this is a relation from a Fault or Hazard to a Requirement. (Stereotype of Dependency)
Faults and Hazards elements have important metadata characterizing them. The important metadata is summarized in Table 1, below.
|Table 1: Safety Metadata|
Currently no items