Safety Driven Design with UML and STPA M. Rejzek, S. Krauss, Ch. Hilbes. Fourth STAMP Workshop, March 23-26, 2015, MIT Boston

Transcription

1 Safety Driven Design with UML and STPA M. Rejzek, S. Krauss, Ch. Hilbes

2 System and Safety Engineering A typical situation: Safety Engineer System Engineer / Developer Safety Case Product 2

3 System and Safety Engineering The challenges with this situation: Product development and safety management separated Different terminology, methods, mindset Individual processes System and System Requirements Definition Validation Hazard Identification System Architecture Design Integration and Testing? Risk Assessment Subsystem Design Integration and Testing Risk Evaluation Implementation Risk Reduction 3

4 System and Safety Engineering The challenges with this situation: Even more challenging with sub-contractors System and System Requirements Definition Validation Hazard Identification System Architecture Design Integration and Testing Risk Assessment Subsystem Design Implementation Integration and Testing? Risk Evaluation Sub-Contractor 1 Risk Reduction Sub-Contractor 2 4

5 Processes V-Model Zoo: Risk Management Processes: 5

6 System and Safety Engineering Safety Engineer System Engineer / Developer FTA, FMEA, HAZOP, Dedicated Tools Model based development with UML UML Case Tools Automated Code Generation 6

7 System and Safety Engineering A typical situation in smaller companies: Safety Case System Engineer = Developer = Safety Engineer Product Problem: Developer has to take care of everything Solution: Empower developer to incorporate Safety into system development 7

8 Model Based Design with UML 2.3 Structural: Class Diagram Object Diagram Package Diagram Component Diagram Composite Structure Diagram Deployment Diagram Behavioral: UseCase Diagram Sequence Diagram Activity Diagram StateMachine Diagram Interaction (Overview) Diagram Communication Diagram Timing Diagram Diagrams Model Repository 8

9 Example Illustration adapted from Y.S. Weng, et al., Design of Traffic Safety Control Systems for Railroads and Roadways Using Timed Petri Nets 9

10 Example System Definition Model system requirements as UML UseCase diagram 10

11 Example System Architecture Conception Initial architecture concept as SysML Block diagram Suitable for a systematic safety analysis? No 11

12 Example STPA Hierarchical Control Structure We propose: Hierarchical Control Structure 12

13 Example STPA Hierarchical Control Structure: Multiple Levels of Detail 13

14 Block Diagram vs. Hierarchical Control Structure Block diagram Focus on components emphasizes component failures Was not designed as a basis for systematic safety analysis Hierarchical Control Structure: Is designed as basis for safety analysis with STPA Step 1 Step 1 questions correspond to questions developer would naturally ask Developer not forced to change scope/mindset Critical Challenge: Perform Step 1 in UML case tool Create an UML diagram type for STPA Step 1 14

15 STPA Step 1 Proposal for STPA Step 1 diagram: Keyword Control Action Logical operator Unwanted Process Reaction/State Hazard Safety Constraint 15

16 System Development and Traceability Progress with system development: Standard UML diagrams to model detailed implementation New diagram types to model functional architecture and safety analysis Model Repository 16

17 System Development and Traceability Traceability between elements: From design model to STPA From Control Action to System Level Losses Among every level of detail System Level Definitions Step 1 Hierarchical Control Structure 17

18 Graph Visualization Analysis results visualized as graph allows: Seeing the big picture Doing an impact analysis Controller System Level Loss 18

19 STPA Step 2 Methods Methods to identify accident scenarios: For simple actuators, sensors, data transmission: FTA, FMEA, For complex actuators, sensors: dedicated subsystem STPA For process model: Annotation of Behavioral diagrams Controller Process Model Scenario XX Actuator Sensor Scenario QQ Scenario YY Process Scenario ZZ Scenario RR 19

20 STPA Step 2 Structured Organization Organization of accident scenarios with generic fault tree: Structured documentation / interface to other tools In principal: allows quantification of accident scenarios Actuator Controller Process Model Process Sensor Guide phrases mapped to fault tree Control input/external information: wrong Missing Process model: inconsistent incomplete incorrect Inadequate/missing feedback Inadequate sensor operation Incorrect/no information provided Measurement inaccuracies Feedback delays Unidentified/out-of-range disturbance Inadequate Control Algorithm: in creation process changes incorrect modification/adaptation Control action: inappropriate ineffective missing Conflicting control actions Delayed operation Process input wrong/missing Component failures Changes over time Wrong input to sensor from process Problem with process itself Unwanted Process State Wrong input to process Wrong output from Conflicting control actuator action on process Wrong input to Conflicting control Problem with actuator (from action on actuator actuator controller) Communication Wrong output from problem controller (between controller and actuator) Generation of Unsafe Control Action (UCA) Wrong input to Problem with process Problem with controller model controller Wrong input to Wrong output from controller (from sensor higher hierarchical level) Problem with sensor Communication Communication Problem with sensor problem (between problem (between itself actuator and process sensor and controller) Top Event: Unwanted Process State Problem with process Communication Inadequate process Unidentified or out of Problem with process problem (between input range disturbance itself process and sensor 20

21 Conclusion and Outlook (1/2) Illustrated a way to integrate system and safety engineering Create STPA diagrams in UML case tool Hierarchical Control Structure STPA Step 1 diagrams Realize and maintain traceability Augment (behavioral) diagrams with accident scenarios STPA Step 2 Organize accident scenarios with generic fault tree Method allows quantification 21

22 Conclusion and Outlook (2/2) Project in collaboration with Curtiss Wright Drive Technology funded by Swiss Commission of Technology and Information Tool Development: Expected to be presented at European STAMP Workshop

23 Contact: Martin Rejzek Sven Stefan Krauss Christian Hilbes