STAMP/STPA. Assurance Cases. Combining. and. Stefan Wagner Institute of Software Technology. STAMP Workshop 2012 Cambridge, MA 19 April 2012

Transkript

1 Combining STAMP/STPA and Assurance Cases Stefan Wagner Institute of Software Technology STAMP Workshop 2012 Cambridge, MA 19 April 2012

2 Automobiles evolve...

3 to electronic systems Size of software Degree of interconnection

4

5 Fatalities per 100,000,000 miles Crashs with fatalities Fatalities per year in the USA 1, ,

6 ISO 26262: Road vehicles Functional safety Requires safety case Concept phase Management of functional safety Product development: system level Product development: hardware level Product development: software level Production and operation Supporting processes ASIL-oriented and safety-oriented analyses

7 Safety requirements & objectives Safety case Safety argument Safety evidence

8 G1 System is safe C2 Fault Hypothesis S1 Fail-safety ensured for fault hypothesis C1 Fail Safety Characterization S2 Hazard-safety ensured for fail-safety C3 Hazard Identification G2 All relevant faults considered C4 Model of system G3 Faults never lead to failures G4 Hazards always caused by failures C5 Model of environment G5 All relevant hazards considered Sn1 Use of fault pattern libraries Sn2 Testing using fault injection Sn3 Formal verification Sn4 Simulation of model of environment G (Sub-)Goal C Context S Strategy Sn Solution

9 Cruise control case study with MAN

10

11 Shift by wire case study with BMW

12 Emergenz und Hierarchie G1 System is safe Zwiebelform C2 S1 Fail-safety ensured for fault hypothesis Fault Hypothesis G2 C4 Model of system All relevant faults considered Sn1 Use of fault pattern libraries C1 Fail Safety Characterization G3 Faults never lead to failures Hazards always caused by failures Sn2 Testing using fault injection Sn3 Formal verification G4 C3 S2 Hazard-safety ensured for fail-safety C5 Hazard Identification Zellform Model of environment G5 All relevant hazards considered Sn4 Simulation of model of environment Ringform Control Algorithms Set Points, Controller Sensors Controlled Variables Process Inputs Measured Variables Controlled Process Disturbances Safety cases are good for a structured argumentation In einer Regelschleife holt sich ein Regler (Controller) Informationen über d geregelten Prozess (Regelstrecke, Controlled Process) durch das Messen vo mit Hilfe von Sensoren. Dies ist die Rückführung (Feedback) des Prozesses Informationen verwendet der Regler, um zu prüfen, ob sich der Prozess inne seiner Führungsgrößen (den Soll-Werten) bewegt. Falls dies nicht der Fall i die Regelgrößen (Controlled Variables) durch Aktuatoren, um auf den Proze zu nehmen. Eine Regelschleife Actuators Die Systemtheorie geht davon aus, dass jedes System verschiedene Hierarch mit jeweils steigender Komplexität hat. Im Beispiel betrachten wir eine Zwi einer Hierarchieebene betrachten wir die einzelnen Zellen der Zwiebel. Dor wir über die Form von Zellen reden, aber Ringe und die Form der ganzen Z machen auf dieser Ebene keinen Sinn. Wenn wir eine Ebene nach oben gehe können wir plötzlich über Ringe reden, die die Zwiebel ausmachen. Wir wis dass jeder Ring aus einer Unzahl von Zellen besteht (-> steigende Komplex eine Ebene höher setzen wir die Ringe zur ganzen Zwiebel zusammen und k dann über die Form der Zwiebel reden. Die Zwiebelform nennt man dann ei emergente Eigenschaft auf dieser Hierarchieebene. So ist auch Sicherheit ei Eigenschaft, über die nur reden kann, wenn man das Softwaresystem in der betrachtet. Eine isolierte Softwarekomponente ist nie sicher oder unsicher. Diese emergente Eigenschaft Zwiebelform beschränkt jetzt die Hierarchieeb darunter: die Ringe müssen so angeordnet sein, dass diese Form entsteht. Bilder von Like_the Grand_Canyon, tjmwatson und anolobb Process Outputs STAMP/STPA are good for a systematic analysis

13 1

14 Identification pattern G1 No hazards occur Identify all S1 hazards && no identified hazards can occur J1 Identification G2 Identify all hazards STAMP STPA G3 No identified hazards can occur

15 Example hazard identification H-1: Gear for wrong direction H-2: Shift to unsuitable gear for speed S1 Use STPA to identify hazards

16 Example hazard analysis Control Action Shift to gear Display gear Not Given or not Followed Controller does not shift gear to change direction Controller does not send new direction to display Given Incorrectly Controller shifts despite no lever change Shift despite no clutch Shift despite unsuitable speed Sends wrong gear to display Wrong Timing or Order Shift too late so that driver opens clutch Not hazardous Stopped Too Soon S2 Use STPA to identify causes for hazards

17 Example hazard avoidance Speed Shift to gear x Display gear y Speed Actuators Lever change Clutch activation Shift controller (software) Hazard: S3 Check Shift speed despite from unsuitable ICM speed Process: Shift/Gear Shift position x In gear y Clutch open Clutch closed Sensors Gear position Gear display

18 2

19 A final step in STPA is to consider how the designed controls could degrade over time and to build in protection against it. Leveson (2011)

20 Example degradation protection Speed Shift to gear x Display gear y Actuators Shift controller (software) S3 Show Hazard: gear also by Display no gear lever position Shift position x In gear y Clutch open Clutch closed Sensors Speed Lever change Clutch activation Process: Shift/Gear Gear position Gear display

21 3

22 Safety case modules Product safety argument Process safety argument Concept level Level of detail Environment and user Integration level Process Function level Development domain

23 Policy, stds. Manufacturing Management Work Procedures Safety Standards Safety Constraints Standards Test Requirements Safety Reports Manufacturing safety reports audits work logs inspections Project Management Design, Documentation Implementation and assurance Hazard Analyses Progress Reports Test reports Hazard Analyses Review Results Hazard Analyses Documentation Design Rationale Hazard Analyses Maintenance and Evolution Safety Related Changes Progress Reports Operating Assumptions Operating Procedures Revised operating procedures Software revisions Hardware replacements Problem Reports Incidents Change Requests Performance Audits Standards Resources Work Instructions Operations Management Operations Reports Change requests Audit reports Problem reports Operating Process Human Controller(s) Actuator(s) Automated Controller Physical Process Sensor(s) STAMP hierarchical structure Product safety argument Process safety argument Concept level Level of detail Environment and user Integration level Process Safety case modules Function level Development domain

24 Example structure mapping Engineering Development Driver Automated Controller Operations Driving

25 4

26 Process models TransferFunction 1 Normal / during : out=in; [error>=6] Broken/ during : out = 0; [error<=3] 2 1 [error>=8] Untrue/ during: out = randtrans(in,50) Sn1 Inspection in model Sn2 Formal verification

27 1. Hazard identification and avoidance 2. Degradation protection 3. Structure 4. Models

28 STAMP A perfect combination of analysis and argumentation Safety case STPA