1 / 23

Enhancing UML by Safety-Related Constructs

Enhancing UML by Safety-Related Constructs. Shourong Lu and Wolfgang A. Halang FernUniversität in Hagen Faculty of Electrical and Computer Engineering 58084 Hagen, Germany Shourong.Lu@fernuni-hagen.de. Outline. Safety Concepts Dependability tree Process for safe software

elia
Download Presentation

Enhancing UML by Safety-Related Constructs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enhancing UML by Safety-Related Constructs Shourong Lu and Wolfgang A. Halang FernUniversität in Hagen Faculty of Electrical and Computer Engineering 58084 Hagen, Germany Shourong.Lu@fernuni-hagen.de

  2. 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

  3. Safety Concepts 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. • Dependability tree 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. total 22

  5. IEC 61508 Safety Lifecycle 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 supportsafety analysis, safety architecture design, and meetrelevant 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. total 22

  9. SIL-Related Programming Language Structure Typical programming methods and correspondingly suited language constructs total 22

  10. PEARL subsets for each SIL <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 <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 <module>::=Module [<var-decl>;]* [<rule>;]* MODEND; <var-decl>::=DCL <name> : <type>; <rule>::=IF <bool-expression> THEN <variable>:=<expression> FIN total 22

  12. PEARL for each of the SILs <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 [<var-decl>;]* [<rule>;]* MODEND; <var-decl>::=DCL <name> : <type>; <rule>::=IF <bool-expression> THEN <variable>:=<expression> FIN The constructs of the textual language Verifiable PEARL allow for parameter passing and procedure invocation, only. total 22

  13. PEARL for each of the SILs <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 <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 [<var-decl>;]* [<rule>;]* MODEND; <var-decl>::=DCL <name> : <type>; <rule>::=IF <bool-expression> THEN <variable>:=<expression> FIN total 22

  14. PEARL for each of the SILs <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 <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 [<var-decl>;]* [<rule>;]* MODEND; <var-decl>::=DCL <name> : <type>; <rule>::=IF <bool-expression> THEN <variable>:=<expression> FIN Safe PEARL is an inherently safe language subset restricted to the executable statements procedure call, assignment, conditional selection, and loop with a compile-time bounded number of iterations. total 22

  15. PEARL for each of the SILs <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 <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 [<var-decl>;]* [<rule>;]* MODEND; <var-decl>::=DCL <name> : <type>; <rule>::=IF <bool-expression> THEN <variable>:=<expression> FIN Programs formulated in the subset HI-PEARL for the lowest SIL1 was derived from PEARL by eliminating all unsafe language constructs which may 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, variousvariables 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 Subsets 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. 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. 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. total 22

  23. Thank you!

More Related