Enhancing UML by Safety-Related Constructs
Shourong Lu and Wolfgang A. Halang
FernUniversität in HagenFaculty of Electrical and Computer
Engineering 58084 Hagen, Germany
Outline
Safety Concepts Dependability tree Process for safe software IEC 61508 safety lifecycle Safety Integrity Levels
UML Framework for Safety Mechanisms
Applying UML in the safety process UML profile for SILs UML profile for fault-tolerant ... ...
Conclusion
total 22 3
Safety Concepts▪ Dependability tree
Dependability
ThreatsFaultsErrorsFailures
Means
Fault preventionFault tolerance
Procurement
Fault removalFault forecasting
Validation
Attributes
AvailabilityReliabilitySafetyConfidentialityMaintainabilityIntegrity
... fault error failure faultactivation propagation causation
...
Availability is a system property with respect to readiness for usage. Reliability is the probability that a system will be up and running and able to deliver correctly services at any given time.
Safety is a property of a system with respect to the avoidance of catastrophic consequences, it is an extension of reliability.
Confidentiality is the attribute of a system with respect to absence of unauthorised disclosure of data.
Maintainability is the attribute of a system with respect to ability to undergo repairs and modifications.
Integrity is the attribute of a system with respect to absence of improper system state variations.
Fault prevention: how to prevent fault occurrence or introduction.Fault tolerance: how to provide a service complying to the specifi- cations in the presence of faults. Fault removal: how to reduce the presence of faults, both regarding the number and seriousness of faults.
Fault forecasting: how to estimate the creation and the consequences of faults.
▪Fundamental chain of threats to safety
total 22 4
Process for Safe Software IEC 61508 defines the V-model for software safety integrity and
the development life-cycle. The design and development process starts with the software
safety requirements specification, which is part of the overall safety requirement specification for software and hardware of a system, ends with validated software on the software validation testing.
E/E/PES safetyrequirementsspecification
Software safetyrequirementsspecification
Softwarearchitecture
Sofware systemdesign
Moduledesign
CODING
E/E/PESarchitecture
Integration tesing(components, subsystems
and programmableelectronics)
Moduletesting
Integrationtesting(module)
Validationtesting
OutputVerification
Validation Validatedsoftware
total 22 5
IEC 61508 Safety Lifecycle
Safety requirementsallocation
5
Concept1
Overall scopedefinition
2
Hazard and riskanalysis
3
Overall safetyrequirements
4
Overall installationand commissioning12
Overall safetyvalidation13
Overall operation,maintenance and repair14
Overall modificationand retrofit15
Decommissioningor disposal16
Overalloperation andmaintenance
planning
6
Overallsafety
validationplanning
Overallinstallation andcommissioning
planning
7 8
Safety-relatedsystems:E/E/PES
Realisation(see E/E/PES
safetylifecycle)
9
Safety-relatedsystems:
othertechnology
Realisation
10External risk
reductionfacilities
Realisation
11
Back to appropriateoverall safety lifecycle
phase
▪ The safety lifecycle is designed to structure a system‘s production into defined stages and activities. ▪ Lifecycle aims to deal in a systematic manner with all activities needed for a safety integrity level assigned to the system.
Process Activities
▪ Hazard Analysis▪ Risk Analysis▪ Requirements Specification▪ Design and Implementation▪ Verification, Validation and
Test▪ Certification▪ Operation and Maintenance
total 22 6
Safety Integrity Levels (SILs) SIL represents a concepts of classes of safety requirements for
functions, systems, sub-systems or components. Four distinct levels of safety integrity were introduced and assigned in IEC 61508.
Different degrees of safety integrity depend on what kind of risk a safety-related system is tackling, how willing we are to accept that risk, how many measures we have, as well as how effective they are.
The safety requirements of a system should be based on system safety analysis and be specified separately. The most well-known analytical methods are:▪ Failure models and effects analysis (FMEA)
▪ Failure modes, effects and criticality analysis (FMECA)
▪ Hazard and Operability analysis (HAZOP)
▪ Event tree analysis (ETA)
▪ Fault tree analysis (FTA)
▪ Failure Modes (FM)
▪ Preliminary Hazard analysis (PHA)
total 22 7
Applying UML in the Safety Process▪ UML provides means to design safety-related systems
▪ Safety analysis▪ Use cases and context diagrams for HazOp ▪ Sequence diagrams for FMEA , FMECA▪ Class and object diagrams for FTA, FMEA and to identify safety
requirements▪ Capabilities are captured as use cases▪ Detailed requirements are captured as specifications and
scenarios.▪ Detailed requirements include behaviours, constraints, pre- and
post-conditions.▪ Capture safety architecture and design
▪ UML patterns capture general safety solutions.▪ UML class diagrams, state charts capture safety behaviour of
object collaborations.
▪ UML has still some limitations such as:▪ UML does not adequately address the specific modeling needs with
respect to safety, real-time behaviour, and distribution.▪ UML does not support automatic generation of simulations, test
cases, model checks, and code from its specifications.▪ As UML has semi-formal syntax and semantics, system verification
faces certain difficulties.
total 22 8
UML Framework for Safety Mechanisms We are aiming to build a set of UML extensions that support safety analysis, safety architecture design, and meet relevant safety criteria. Here, we build UML profiles oriented at the 4 safe subsets which were defined for the real-time programming language PEARL. To fulfill the requirements of the SILs, these UML profiles must include concepts of fault-tolerance techniques.
UML Framework
Safety mechanisms
Static diagrams
Standard UML
Dynamic diagrams
UML profile for safesubsets of
programming languagebased on SILs
UML profile for fault-tolerance
Safety - criticalsystems
Extenstionmechanisms ... ...
total 22 9
SIL-Related Programming Language Structure Typical programming methods and correspondingly suited language constructs
SIL Language Constructs Typical Programming Method
Criteria and Goal
SIL4 Marking table entries Cause effect table
(Finite automata)
No sequential programs
No transformations
Specification = machine code
Goal: Verification by human consensus
SIL3 Procedure call Function block diagrams with verified libraries
No declarations of variables
No loops
Use of library procedures only
Goal: Match FBD programming
SIL2 Procedure call
Assignment
Case selection
Repetition restricted loop
Language subset enabling formal verification
No usage of pointers
No multitasking
Pre/post-conditions for any procedure
Invariants for any procedure
Goal: Allow formal verification
SIL1 Application oriented ones
Inherently safe ones
Static language with safe constructs
No time-unbounded constructs
No unstructured constructs
Structured synchronisation
Structure handling of all exceptions
Goal: Guarantee schedulability
total 22 10
PEARL subsets for each SIL No SIL SIL1 SIL2 SIL3 SIL4
PEARL HI-PEARL Safe PEARL Verifiable PEARL Table PEARL
<module>::=Module [<var-decl>;]*
[<rule>;]*
MODEND;
<var-decl>::=DCL <name> : <type>;
<rule>::=IF <bool-expression>
THEN
<variable>:=<expression>
FIN
The corresponding subset of Table PEARL
provides just a single executable statement,
which is used to formulate rules constituting
cause-effect tables.
total 22 11
PEARL for each of the SILs SIL SIL1 SIL2 SIL3 SIL4
PEARL HI-PEARL Safe PEARL Verifiable PEARL Table PEARL
<module>::=Module [<var-decl>;]*
[<rule>;]*
MODEND;
<var-decl>::=DCL <name> : <type>;
<rule>::=IF <bool-expression>
THEN
<variable>:=<expression>
FIN
<module>::=MODULE[(<name>)]
[(<problem>)] MODEND
<problem>::= PROBLEM
[<proce-spec>]* [<var-decl>]*[<task-decl >];
<proc-spec>::= SPC<name>: PROC<lst-of-par> <return-type>;
[GLOBAL];
<var-decl>::= DCL <name>: <type>;
<task-decl>::= <name>: Task[GLOBAL];<proc-stmt>+ END
<proc-stmt>::=<proc-name> <lst-of-par>
<list-of-par>::= (<par> [,<par>]*)
<par>::= <const>|<var-name>
*, + denote repetition of the correspondingly marked expression at least zero times or once, respectively
total 22 12
PEARL for each of the SILs SIL SIL1 SIL2 SIL3 SIL4
PEARL HI-PEARL Safe PEARL Verifiable PEARL Table PEARL
<module>::=Module [<var-decl>;]*
[<rule>;]*
MODEND;
<var-decl>::=DCL <name> : <type>;
<rule>::=IF <bool-expression>
THEN
<variable>:=<expression>
FIN
<module>::=MODULE[(<name>)]
[(<problem>)] MODEND
<problem>::= PROBLEM
[<proce-spec>]* [<var-decl>]*[<task-decl >];
<proc-spec>::= SPC<name>: PROC<lst-of-par> <return-type>;
[GLOBAL];
<var-decl>::= DCL <name>: <type>;
<task-decl>::= <name>: Task[GLOBAL];<proc-stmt>+ END
<proc-stmt>::=<proc-name> <lst-of-par>
<list-of-par>::= (<par> [,<par>]*)
<par>::= <const>|<var-name>
*, + denote repetition of the corresponding markded expression at least zero times or once, respectively
The constructs of the textual language Verifiable PEARL allow for parameterpassing and procedure invocation, only.
total 22 13
PEARL for each of the SILs SIL SIL1 SIL2 SIL3 SIL4
PEARL HI-PEARL Safe PEARL Verifiable PEARL Table PEARL
<module>::=Module [<var-decl>;]*
[<rule>;]*
MODEND;
<var-decl>::=DCL <name> : <type>;
<rule>::=IF <bool-expression>
THEN
<variable>:=<expression>
FIN
<module>::=MODULE[(<name>)]
[(<problem>)] MODEND
<problem>::= PROBLEM
[<proce-spec>]* [<var-decl>]*[<task-decl >];
<proc-spec>::= SPC<name>: PROC<lst-of-par> <return-type>;
[GLOBAL];
<var-decl>::= DCL <name>: <type>;
<task-decl>::= <name>: Task[GLOBAL];<proc-stmt>+ END
<proc-stmt>::=<proc-name> <lst-of-par>
<list-of-par>::= (<par> [,<par>]*)
<par>::= <const>|<var-name>
*, + denote repetition of the corresponding markded expression at least zero times or once, respectively
<module>::=MODULE[(<name>)]
[<mod-extension>];
[<interface-spec>]*
[<system-part>]
[<problem-part>]
MODEND;
<mod-extension>::= EXTEND (<name>) [, <name>]+)
<interface-spec>::=INTERFACE (<name>)
<interface-decl>*
<interface-decl>::= <interface-var-decl>
| <interface-proc-del>
<interface-var-decl>::= SPC <name>: <type> READ;
<interface-proc-decl>::= SPC <name>: PROC
<lst-of-par> <return-type>
<system-part>::= SYSTEM;
<name> : <name>;
<problem-part>::= PROBLM;
[<declarations>]+
<declarations>::= <var-decl> | <proc-decl>
<var-decl>::= DCL <name> : <type>;
<proc-decl>::= <name>: PROC
<lst-of-par> <return-type>
<body> END
<lst-of-par>::= (<par-decl>) [,<par-decl>]*)
<proc-decl>::= <name>: type
<body> ::= [<var-decl>]+[<statement-seq>]
<statement-seq>::= [<statement>;]*
<statement>::=(<statement-seq>)
|<assignment-statemet>
|<conditional-statement>
|<while-statement>
<assignment-statement>::=<variable>:=<expression>
<conditional-statement>::= IF<bool-expression>
THEN <statement-seq>
[ELSE <statement-seq>]FIN
<while-satement>::=WHILE <bool-expression>
REPEAT<statement-seq> END
total 22 14
PEARL for each of the SILs SIL SIL1 SIL2 SIL3 SIL4
PEARL HI-PEARL Safe PEARL Verifiable PEARL Table PEARL
<module>::=Module [<var-decl>;]*
[<rule>;]*
MODEND;
<var-decl>::=DCL <name> : <type>;
<rule>::=IF <bool-expression>
THEN
<variable>:=<expression>
FIN
<module>::=MODULE[(<name>)]
[(<problem>)] MODEND
<problem>::= PROBLEM
[<proce-spec>]* [<var-decl>]*[<task-decl >];
<proc-spec>::= SPC<name>: PROC<lst-of-par> <return-type>;
[GLOBAL];
<var-decl>::= DCL <name>: <type>;
<task-decl>::= <name>: Task[GLOBAL];<proc-stmt>+ END
<proc-stmt>::=<proc-name> <lst-of-par>
<list-of-par>::= (<par> [,<par>]*)
<par>::= <const>|<var-name>
*, + denote repetition of the corresponding markded expression at least zero times or once, respectively
<module>::=MODULE[(<name>)]
[<mod-extension>];
[<interface-spec>]*
[<system-part>]
[<problem-part>]
MODEND;
<mod-extension>::= EXTEND (<name>) [, <name>]+)
<interface-spec>::=INTERFACE (<name>)
<interface-decl>*
<interface-decl>::= <interface-var-decl>
| <interface-proc-del>
<interface-var-decl>::= SPC <name>: <type> READ;
<interface-proc-decl>::= SPC <name>: PROC
<lst-of-par> <return-type>
<system-part>::= SYSTEM;
<name> : <name>;
<problem-part>::= PROBLM;
[<declarations>]+
<declarations>::= <var-decl> | <proc-decl>
<var-decl>::= DCL <name> : <type>;
<proc-decl>::= <name>: PROC
<lst-of-par> <return-type>
<body> END
<lst-of-par>::= (<par-decl>) [,<par-decl>]*)
<proc-decl>::= <name>: type
<body> ::= [<var-decl>]+[<statement-seq>]
<statement-seq>::= [<statement>;]*
<statement>::=(<statement-seq>)
|<assignment-statemet>
|<conditional-statement>
|<while-statement>
<assignment-statement>::=<variable>:=<expression>
<conditional-statement>::= IF<bool-expression>
THEN <statement-seq>
[ELSE <statement-seq>]FIN
<while-satement>::=WHILE <bool-expression>
REPEAT<statement-seq> END
Safe PEARL is an inherently safe language subsetrestricted to the executable statements procedurecall, assignment, conditional selection, and loop witha compile-time bounded number of iterations.
total 22 15
PEARL for each of the SILs SIL SIL1 SIL2 SIL3 SIL4
PEARL HI-PEARL Safe PEARL Verifiable PEARL Table PEARL
<module>::=Module [<var-decl>;]*
[<rule>;]*
MODEND;
<var-decl>::=DCL <name> : <type>;
<rule>::=IF <bool-expression>
THEN
<variable>:=<expression>
FIN
<module>::=MODULE[(<name>)]
[(<problem>)] MODEND
<problem>::= PROBLEM
[<proce-spec>]* [<var-decl>]*[<task-decl >];
<proc-spec>::= SPC<name>: PROC<lst-of-par> <return-type>;
[GLOBAL];
<var-decl>::= DCL <name>: <type>;
<task-decl>::= <name>: Task[GLOBAL];<proc-stmt>+ END
<proc-stmt>::=<proc-name> <lst-of-par>
<list-of-par>::= (<par> [,<par>]*)
<par>::= <const>|<var-name>
*, + denote repetition of the corresponding markded expression at least zero times or once, respectively
<module>::=MODULE[(<name>)]
[<mod-extension>];
[<interface-spec>]*
[<system-part>]
[<problem-part>]
MODEND;
<mod-extension>::= EXTEND (<name>) [, <name>]+)
<interface-spec>::=INTERFACE (<name>)
<interface-decl>*
<interface-decl>::= <interface-var-decl>
| <interface-proc-del>
<interface-var-decl>::= SPC <name>: <type> READ;
<interface-proc-decl>::= SPC <name>: PROC
<lst-of-par> <return-type>
<system-part>::= SYSTEM;
<name> : <name>;
<problem-part>::= PROBLM;
[<declarations>]+
<declarations>::= <var-decl> | <proc-decl>
<var-decl>::= DCL <name> : <type>;
<proc-decl>::= <name>: PROC
<lst-of-par> <return-type>
<body> END
<lst-of-par>::= (<par-decl>) [,<par-decl>]*)
<proc-decl>::= <name>: type
<body> ::= [<var-decl>]+[<statement-seq>]
<statement-seq>::= [<statement>;]*
<statement>::=(<statement-seq>)
|<assignment-statemet>
|<conditional-statement>
|<while-statement>
<assignment-statement>::=<variable>:=<expression>
<conditional-statement>::= IF<bool-expression>
THEN <statement-seq>
[ELSE <statement-seq>]FIN
<while-satement>::=WHILE <bool-expression>
REPEAT<statement-seq> END
Programs formulated in the subset HI-PEARL for the lowest SIL1 wasderived from PEARL by eliminatingall unsafe language constructs whichmay lead to undeterministic behaviour.
total 22 16
PEARL subsets for each SIL PEARL were proposed for each of four safety integrity level:
HI-PEARL….SIL1 Safe PEARL….SIL2 Verifiable PEARL….SIL3 Table PEARL……SIL4
The main element dealing with safety issues in the subsets of PEARL is the module which is used to describe software architectures according to the different requirements of the SILs and constructed with ruls, procedures, interfaces, various variables and conditions.
A PEARL program is structured by grouping modules into collections. Collections are either statically distributed or dynamically allocated to system nodes. They form the elements for dynamic reconfiguration.
total 22 17
UML Stereotypes Matching PEARL SubsetsTable PEARL Module for SIL 4:
Context PearlModule inv: self.baseClass = Classifier & self.ownedElement -> forAll ( E | If (boolean -expression) Then expression1 Elseexpression2)
Verifiable PEARL Module for SIL 3:Context PearlModule inv: self.baseClass = Classifier & self.ownedElement -> forAll( E | E = procedure & (exist (p: Parameter | p.name = name, p.type = type, p.value = value) ->size >= 1) & self.hasNoInterfaces() )
PEARL Collection:Context PearlCollection inv: self.baseClass = Component self.ownedElement. IsInstantiable = true self.ownedElement.contents -> forAll (m| m.OclIsKindOf( Module) & m.Port.isKindOf (PearlPort))
Hi-PEARL Module for SIL1Context PearlModule inv: self.baseClass = Classifier & self.ownedElement -> not exit (unsafebehaviors)
Safe PEARL Module for SIL 2:Context PearlModule inv: self.baseClass = Classifier & self.ownedElement -> forAll( E | E = procedure & (exist (p: Parameter | p.name = name, p.type = type, p.value = value)->size >= 1) & self.Interfaces.isKindOf (PearlInterface))
Context PearlPort inv: self.owned. Port () impies (self.required -> size () =1 & (self.provided ->size()=1)
Context PearlInterface inv: self.feature -> forAll (f | (f.parameter -> size >=1)& (f.operation = parameter transportation) )
total 22 18
UML Stereotypes Matching Function Block Diagrams (FBD) for SIL 3
The basic language elements in FBD are instances of function and function blocks. To make the concept of function blocks available in UML, we use the stereotype Component.
context FBInterface inv: (self.feature->size = 1) & (self.feature->forAll( f | (f.name = 'OperationName') & (f.classifier = Operation)& (f.parameter->size = 1)) )
context FBInPort inv: (self.required->size = 0) & (self.provided->size = 1) & (self.provided->forAll(p | (p.classifier = FBInterface)))
context FBOutPort inv: (self.provided->size = 0) & (self.required->size = 1) & (self.required->forAll( r | (r.classifier = FBInterface)))
FB type
Var_StatVar_Temp
Algorithm
Var_Output
Var_Input
Var_InOut
ENOENFB instance
Port
RequiredInterface
ProvidedInterface
<<interface>>
InputVariablesoutputVariablesoperation
<<FB>>
InputPortoutputProt
Interface
FBComponent
Behavioral ports
context FBComponent inv: self.feature->forAll( f | (f.classifier = FBPort) )
total 22 19
Techniques for Software Fault-tolerance
Single-version programming: fault-tolerance is based on the use of redundancy applied to a single version of a piece of software to detect and recover from faults.
This approach includes considerations on program structure and actions, error detection, exception handling, checkpoint and restart, redundant execution platforms, and data diversity.
Multi-version programming: fault-tolerance is based on the use of two or more versions of a piece of software, executed either in sequence or in parallel.
This is used in alternatives (with a separate means of error detection), in pairs (to implement detection by replication checks), or in larger groups (to enable masking through voting).
total 22 20
Fault-tolerance Techniques
The FT-techniques have different architectures, but require some basic concepts:
Fault Detection:
There is a diversity of tools to support fault detection.
Groups: Replication of software elements requires to identify the group of elements that
compose a replication block to provide a common service. Groups of elements have associated fault-tolerance policies and styles that customise fault-tolerance mechanisms according to application characteristics.
Replication Styles: Fault-tolerance architectures use different policies to handle the different types of
replications and recovery information. Some styles define active replications and others define more passive ones.
total 22 21
Fault-tolerance Mechanisms Replication management is responsible to create or remove objects, and for fault-
tolerant property modification.
Fault management concerns the detection of object failures, the creation and notification of fault reports, and fault report analysis.
Recover management is implemented by logging and recovery mechanisms in order to read and write their state.
ReplicationManager
RecoverManager
FaultManager
Recovery
Factor
Log
Plant
Recovery
Factor
Log
Plant
FaultDetector
Sensor
FaultDetector
Sensor
FaultNotifier
FaultNotifier
create / remove object
notification notification
create / remove object
total 22 22
Conclusion
In conjunction with design techniques and UML extension mechanisms, we can extend UML for safety applications with respect to aspects such as safety architecture design, safety analysis.
Using UML syntax, these extensions can be integrated into the standard UML framework, since they are based on the UML meta-model.
The benefit of using UML in modeling a safety mechanism is that UML provides numerous diagrammatic techniques to comfortably describe process models.
The UML framework for safety mechanisms can provide facilities to capture safety requirements of safety-related applications, as well as dependability structures.
In continuation of this work we shall extend this safety mechanism further according to the safety standard IEC 61508.
In conjunction with design techniques and UML extension mechanisms, we can extend UML for safety applications with respect to aspects such as safety architecture design, safety analysis.
Using UML syntax, these extensions can be integrated into the standard UML framework, since they are based on the UML meta-model.
The benefit of using UML in modeling a safety mechanism is that UML provides numerous diagrammatic techniques to comfortably describe process models.
The UML framework for safety mechanisms can provide facilities to capture safety requirements of safety-related applications, as well as dependability structures.
In continuation of this work we shall extend this safety mechanism further according to the safety standard IEC 61508.
Thank you!Thank you!
Top Related