Enhancing UML by Safety-Related Constructs

Shourong Lu and Wolfgang A. Halang

FernUniversität in HagenFaculty of Electrical and Computer

Engineering 58084 Hagen, Germany

Shourong.Lu@fernuni-hagen.de

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!