A profile is a coherent set of lightweight extensions to the UML,creating a version of the UML specialized for some purpose or problemdomain. A profile can contain a number of things, includingstereotypes, tags, constraints, new diagram types, iconicrepresentations, and model libraries.
Each stereotype within a profile must extend a metaclass from theUML metamodel, such as Class, Event, or Association. The stereotype isusually elaborated with metadata stored in named tags, constraints onits usage, and graphical iconic depictions.
For example, in the SysML profile, a flow port is a stereotype ofport that applies to flows. New types of diagrams may be created thatrepresent collections of these elements for specific purposes.
For example, in the UML Profile for DoDAFand MoDAF (UPDM) , and OV-2 product is a diagram basedon aUML class diagram that specifically contains stereotyped elements fromthe UPDM to show operational nodes within an operational architectureand their relations.
In this context, I will use the IBM Rational Rhapsody tool tocreate a safety analysis profile that adds new stereotyped elements tocreate fault tree analysis (FTA)diagrams and custom matrix and tabular views to summarize the resultsof the analysis.
In addition, I will extend the typical definition of FTA elements tosupport traceable links from the FTA model into both requirements anddesign elements. However, any UML tool that supports UML profilingmechanisms should work.
|Figure1: Safety Profile Metamodel|
(To view an expanded version ClickHere. )
Before a profile can be created, it is necessary to characterize theconcepts contained within the profile and how these concepts relate toeach other. This is usually done with a metamodel. A metamodel is amodel of the fundamental concepts and their relations for a domain orsubject matter.
Figure 1 above shows the metamodel for the Safety AnalysisProfile (the metasubtypes of LogicalOperator are detailed in Figure2 below ). The attributes of the metaclasses will end up as tags onour defined stereotypes. The colored boxes are the relations betweenthe core metaclasses.
|Figure2: Metasubtypes of Logical Operators|
The key elements for the metamodel (alongwith their profile realizations ) are:
Hazard – a condition that will lead to an accident orloss. This is usually the top terminal element in an FTA. (Stereotypeof Class)
Fault – the non-conformance of an element to itsspecification or expectation. Faults are further subclassed into BasicFaults and Undeveloped Faults. These are usually the bottom terminalelements in an FTA. (Stereotype of Class)
Resulting Condition – the condition resulting from acombination of faults and conditions, combined with logical operators.(Stereotype of Class)
Required Condition – A condition required for thefault to interact. (Stereotype of Class)
Logical Operator – one of several logicconjunctives, such as AND, NOT, OR, etc. Note that Transfer operatoractually has no semantics of its own but is used as a “diagramconnector”, allowing large FTAs to be broken up across multiplediagrams. (Stereotype of Class)
Logic Flow – the connection of a fault, condition orhazard to a Logical Operator. The logic flow can be an input or anoutput. For example, in the statement A || B –> C, there is a flowoutput from A as an input to the || (OR) operator. There is also anoutput from flow the || operator to the resulting condition C.(Stereotype of Flow).
Fault Source – this is a normal UML element thatcould manifest a fault, i.e. that could be the source of a fault.(Stereotype of Class)
Safety Measure – this is a normal UML element thatcould detect or extenuate (i.e. mitigate) a fault. (Stereotype ofClass)
Manifest relation – this is a relationship from aFault to a Fault Source that causes the fault (Stereotype ofDependency)
Detect relation – this is a relation from a Fault orHazard to a Safety Measure that can detect when the fault has occurred.(Stereotype of Dependency)
Extenuates relation – this is a relation from aFault or Hazard to a Safety Measure that reduces either the likelihoodor severity of the hazard or fault. (Stereotype of Dependency)
Trace To Requirement – this is a relation from aFault or Hazard to a Requirement. (Stereotype of Dependency)
Faults and Hazards elements have important metadata characterizingthem. The important metadata is summarized in Table 1, below .
|Table1: Safety Metadata|
Tables, Matrices and Hazard Analyses
In addition to the elements of the profile, new tables and matrices areadded in the profile as well, shown in Table 2 below .
The Hazard analysis is generated as an external file with a helpermacro. This macro scans the entire model and generates thetab-separated value file1 that can be loaded into most spreadsheetprograms.
[ Tab-separated valueformat was used because Excel has defects in its interpretation of themore-common comma-separated value (CSV) file format. ]
The macro generates the name from the current date and time so thatmultiple versions of the hazard analysis can be kept. The output isdivided into three sections.
|Table 2: Tables and Matrix summary views|
The first section lists the hazards and their metadata, includingthe description, fault tolerance time, fault tolerance time units,probability, severity, risk, and safety integrity level.
The second section lists the relations between the faults and thehazards as defined by multiple intervening logical operators and logicflows. Each fault is identified with is name, description and othermetadata.
The third section lists the relations between the faults and the”normal” UML model elements ” requirements and classes related with themanifests, detects, extenuates, and traceToReqs relations.
The hazard analysis provides a summary with enough information totrace from the safety requirements to the model elements realizingthose requirements, as well as from the faults and hazards to therequirements and design.
Creating the Profile
Once the metamodel is understood it can be used as a blueprint for theprofile. Metaclasses in the metamodel become stereotypes.Metaattributes become tags. The result is the creation of an integratedset of stereotypes, tags, and constraints such as shown in Figure 3below.
|Figure 3: Profile Structure|
(To download a PDF of the long version of this truncated profilestructure list, ClickHere. )
Using the Profile
To use the profile in Rhapsody, you can create a new model of the typeSafety Analysis or you can add the profile after the model is created.If you do this, you must select the project in the browser,right-click, and change the type of the model to Safety AnalysisProfile.
Once the model is created, a new diagram type is available on thediagram toolbar ” the FTA diagram. All of the standard UML featuresremain available to you. I recommend that you put the safety analysisin a separate package in your model to separate it from yourrequirements and design elements. Again, if you're using a differenttool to create the profile, the exact mechanisms to install and use theprofile are likely to differ.
Fault Tree Analysis (FTA) is well established as a useful method forunderstanding how normal events, conditions and faults combine tocreate hazardous conditions. The safety analysis profile discussed inthis paper adds the ability to create and report on FTA diagrams into aUML tool.
This includes the specification of safety-related metadata, such ashazard severity, risk, probability and safety integrity level, as wellas fault probability and MTBF.
The profile extends the FTA method by supplying relations from theanalysis to normal UML model elements ” specifically, requirements,source of faults, and elements that can detect or extenuate the faults.These extensions add value by making the relations between the safetyanalysis and the UML model elements explicit and traceable.
This profile supports the safety approach identified in theHarmony/ESW (Embedded Software) process [4,5] from IBM/Rational,developed by the author. Through the use of this profile, developersand safety analysts can use a common language and tool environment,improving their collaboration and quality of work.
“Build safety-critical designs with UML-based fault tree analysis” is a 3-part series:
To read Part 1, go to “The basics”
To read Part 2, go to “Defining a a profile”
To read Part 3, go to “Anesthesia ventilator evaluation”
Bruce has worked as a software developer in real-time systems for over 25 years and is a well-known speaker, author, and consultant in the area of real-time embedded systems. He is on the Advisory Board of the Embedded Systems Conference where he has taught courses in software estimation and scheduling, project management, object-oriented analysis and design, communications protocols, finite state machines, design patterns, and safety-critical systems design. He develops and teaches courses and consults in real-time object-oriented analysis and design and project management and has done so for many years. He is the chief evangelist for Rational/IBM. Bruce worked with various UML partners on the specification of the UM, both versions 1 and 2. He is a former co-chairs of the Object Management Group's Real-Time Analysis and Design Working Group. He is the author of several other books on software, including Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns (Addison-Wesley, 1999), Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems (Addison-Wesley, 2002), Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems (Addison-Wesley, 2004), Real-Time UML Workshop for Embedded Systems (Elsevier Press, 2006) and several others, including a short textbook on table tennis. His latest book on employing agile methods to develop real-time and embedded systems, Real-Time Agiliy, will appear in June, 2009.
 Leveson, Nancy. Safeware:System Safety and Computers Reading, MA: Addison-Wesley, 1995
 Guidance for FDAReviewers and Industry: Guidance for the Content of PremarketSubmissions for Software Contained in Medical Devices Washington, D.C.;FDA, 1998
 IEC 65A/1508: FunctionalSafety: Safety-Related Systems Parts 1-7 IEC 1995
 Douglass, Bruce Powel.Doing Hard Time: Developing Real-Time Systems with UML, Objects,Frameworks and Patterns Reading, MA: Addison-Wesley, 1999
 Douglass, Bruce Powel.Real-Time Agility Reading, MA: Addison-Wesley, 2009.
 Douglass, Bruce Powel.Real-Time Design Patterns: Robust Scalable Architecture for Real-TimeSystems Addison-Wesley, 2002