Applying STPA-based Hazard Analysis to support HBSE for Systems built using MAPs

Transcription

1 Applying STPA-based Hazard Analysis to support HBSE for Systems built using MAPs ISPCE 2015 Chicago, IL, USA Sam Procter, John Hatcliff, Kim Fowler SAnToS Lab Kansas State University Anura Fernando Underwriters Laboratories Sandy Weininger Food and Drug Admin. Support: This work is supported in part by the US National Science Foundation (NSF) (# ), the NSF US Food and Drug Administration Scholarin-Residence Program (# ) and the National Institutes of Health / NIBIB Quantum Program.

2 Health Care Involves A Variety of System Components Sensor Data Displays Clinical Protocols Clinicians Actuators Information Systems Patient! Sensors

3 Motivation n What are the types of things we could do with device integration? n Information forwarding n Automation of clinical workflows n Closed loop control between devices n Unlike personal computing, medical devices are not designed to work together n Integrating medical devices would bring myriad benefits n how can we do so safely?

4 Outline n Background n PCA Interlock Scenario n Medical Application Platforms n AADL n Vision n Language n Tool n Hazard Analysis n Future

5 Status Quo: MDDS Medical Device Data Systems Data only flows from producers to consumers; data must be faithfully re-presented Devices Data Consumers Display Gadgets EMR Databases

6 PCA Interlock Scenario n Patients are commonly given patient-controlled analgesics after surgery n Crucial to care, but numerous issues related to safety n Data for disabling the pump exists now (just a system invariant) -- we just need to integrate it

7 Clinically Supported Motivating Clinical Problem: PCA Overdose n n A particularly attractive feature may be the ability to automatically terminate or reduce PCA (or PCEA) infusions when monitoring technology suggests the presence of opioidinduced respiratory depression. To facilitate such capabilities, we strongly endorse the efforts to develop international standards for device interoperability and device-device communication. It is critical that any monitoring system be linked to a reliable process to summon a competent health care professional to the patient's bedside in a timely manner.

8 PCA Pump Safety Interlock Fully leverage device data streams and the ability to control devices Devices PCA Pump Clinician / Monitoring Capnograph Enable Pump for safe time window Monitoring Data + Alarm Information Enable bolus dose only when ticket present Device Task controller PCA Bolus Enable Ticket Combined PCA Vitals Monitoring Aggregated Monitoring Status Status Display for PCA Monitoring Application Pulse Oximeter Monitoring Data + Alarm Information

9 Medical Application Platforms Devices Displays Clinician Console Apps B u s EMR Databases Computational Platform n A Medical Application Platform is a safety- and securitycritical real-time computing platform for n n Integrating heterogeneous devices, medical IT systems, and information displays via communications infrastructure, and Hosting applications ( apps ) that provide medical utility via the ability to acquire information from and update/control integrated devices, IT systems, and displays

10 Background PCA Pump Interlock Architecture SUI App Display View Display Medical Application Platform Data for Display App Start / Stop Commands Sensor + Alarm Data Data should arrive once per second Clinician (App Administrator) Pulse Oximeter, Capnograph, and Patient Controlled Analgesia Pump PCA PR SPO 2 ETCO 2 RR View Display Configuration, Alarm Clear Patient Attach Sensors

11 Background Architecture Analysis and Description Language (AADL) n n n n n SAE Standard, used in e.g., Avionics Enables model-driven, component-based development of n n n Software Hardware And the bindings between the two Previously applied to a single medical device, what about a system of multiple medical devices? How well can it work on a managed platform? Can we do anything beyond describing an app s architecture with it?

12 Outline n Background n Vision n Analyses n Code generation n Language n Tool n STPA n Hazard Analysis n Future

13 Vision Analyses and Regulatory Artifacts Clinical Use Case / Workflow Description App Developer 3 rd Party Certifiers Assurance Case Requirements 3 rd Party ICE Conformance & Safety Certification Submission Package Hazard Analysis Medical Device Coordination Framework FDA 510K Submission Package Risk Assessment App Deployment FDA Evaluators

14 Vision Code Generation A. The app s architecture is specified in AADL 1. Components as AADL Devices / Processes 2. Connections are specified 3. RT/QoS Parameters are via AADL s propertyspecification mechanism B. The app is programmatically translated to Java and XML C. The app is launched on a compatible MAP C Instantiates as

15 Outline n Background n Vision n Language n Why MDD? n Why (a subset of) AADL? n Constructs n Tool n Hazard Analysis n Future

16 MAP Characteristics MAP constituted device instances are variable the constituents that form the MAP constituted device may different on different invocations of the device. n Same app, and thus same conceptual system MAPs-R-Us Platform PCA Interlock App Bus AnyPCA PCA Pump n n Just one architecture and development framework But, different component instances. ACME Platform PCA Interlock App Bus NellCore Pulse Ox PCA+ PCA Pump Masimo Pulse Ox

17 MAP Characteristics MAP constituted device instances are variable the constituents that form the MAP constituted device may different on different invocations of the device. n Same app, and thus same conceptual system MAPs-R-Us Platform PCA Interlock App Bus AnyPCA PCA Pump n n Just one architecture and development framework But, different component instances. ACME Platform PCA Interlock App Bus NellCore Pulse Ox PCA+ PCA Pump Masimo Pulse Ox

18 Language Why use AADL? n History of successful safety-critical projects n Avionics / Boeing (SAVI): integrate-then-build approach n Previously found that MAPs lend themselves to pub-sub n Device as publisher, apps as subscriber n Natural to model with AADL s port connections n Annexes support a number of regulatory and verification artifacts n Hazard Analysis (EMV2), Interface contracts (BLESS), etc.

19 Language Why subset AADL? n AADL is targeted at co-design, ie: complete systems n MAPs are managed platforms n Semantic mismatches n Processes n Insufficiency of pre-declared properties n Unrealizable communication patterns n No shared-memory access in pub/sub middleware

20 Language Model AADL System Output rate: 1 sec.. 5 sec Device1 Device2 AADL Process: Logic Thread1 Thread3 Thread2 AADL Process: Display Thread1 Thread2 Channel Delay: 50ms Period: 50ms WCET: 5ms

21 Language System Medical Devices Software Components Communication links between components and properties of those links!

22 Language System Medical Devices Software Components Communication links between Components and properties of those links!

23 Language Device Interface Specification Ports Properties of those ports Device API Only -- Presents the app s view of the required device capabilities, not the full device capabilities

24 Language Device Interface Specification Device API Only -- Presents the app s view of the required device capabilities, not the full device capabilities Ports Properties on those ports

25 Language Process Specification External ports Tasks (Threads) Connections between external ports and threads

26 Language Process Specification External ports Tasks (Threads) Connections between external ports and threads

27 Language Thread Specification External ports Properties

28 Language Thread Specification External ports Properties Any necessary architectural annotations can be created!

29 Component Development Automatic code generation AADL Component Architecture Component skeleton generation Behavioral code written by component developer n n n n n Development of component architecture using AADL / OSATE2 Automatic generation of component architecture (skeletons) Automatic generation of component layout and app topology (configuration) Development of core behavioral code (business logic) using IDE of choice Translator can be retargeted to other languages as desired

30 Language Subset AADL Constructs Used AADL Construct System Device Process Thread System-level port connection Process implementation-level port connection Components MAP Concept Layout Medical Device API for App Software Component Task Connections Channel Task-Port Communication

31 Language Translation Target System.cfg.xml Dev2.java Task1 Logic.java Task1 Display.java Dev1.java Task3 Task2 LogicSuperType.java Logic.compsig.xml (QoS/RT) Task2 DisplaySuperType.java Display.compsig.xml (QoS/RT)

32 Outline n Background n Vision n Language n Tool n OSATE2 n Availability n Hazard Analysis n Future

33 Tool OSATE2 n Open-source, Eclipse-based tool n Our work is available as a plugin n Uses the model-traversal built into OSATE2

34 Tool OSATE2

35 Tool OSATE2

36 Outline n Background n Vision n Language n Tool n Hazard Analysis n History n Fundamentals n Control Actions n Future

37 Hazard Analysis Leveraging Semiformal Architectural Descriptions Requirements Clinical Use Case / Workflow Description App Developer Assurance Case 3 rd Party Certifiers 3 rd Party ICE Conformance & Safety Certification Submission Package Hazard Analysis MDCF FDA 510K Submission Package App Deployment FDA Evaluators Risk Assessment

38 Hazard Analysis History: FTA n FTA: Bell Labs, 1962 n Looks for contributory causes to undesired events Too Large of Dose Allowed G1 Bad Physiological Data Received Undetected Error G2 G3 Incorrect Physiological Reading Message Garbled by Network Physiological Data within Max Range Software Encoding or Decoding Error Internal Diagnostics Fail

39 Hazard Analysis History: FMEA n FMEA: US Military, 1949 n Analyses impacts of individual components System: PCA Interlock Scenario Subsystem: Pulse Oximeter Device Mode/Phase: Execution Function Failure Mode Fail Rate Causal Factors Effect System Effect Detected by Current Control Hazard Risk Rec. Action Provide SpO 2 Fails to Provide N/A Network or dev. Failure No SpO 2 data Unknown patient state App Potential OD 3D Default to KVO Provides late N/A Network slowness No SpO 2 data Unknown patient state App Potential OD 3C Default to KVO Provides wrong N/A Device error SpO 2 wrong Wrong patient state None Potential OD 1E Dev. should report data quality Analyst: Sam Procter Date: September 26, 2014 Page 3/14

40 Hazard Analysis History: STPA n STPA: Nancy Leveson / MIT, 2005(ish) n Applies systems theory, focuses on control n Loops n Actions Sensor Controlled Process Controller Control Actions Actuator

41 STPA in AADL The Annotated Control Loop Control Action: App > PCA Pump Control Action: App > Inappropriate PCA Pump Control Action: Inadvertent Pump Normally command Feedback: PulseOx > App Feedback Message: PulseOx > App Inadequate Feedback: Sends bad SpO 2 Controller: App Logic Controller: App Logic Process Model Incorrect: Wrongly believes patient to be healthy Actuator: PCA Pump Actuator: PCA Pump Inadequate Operation: Pumps Normally Sensor: Pulse Oximeter Sensor: Pulse Oximeter Inadequate Operation: SpO 2 value incorrect Controlled Process: Patient

42 STPA: Fundamentals STPA: Background & Fundamentals n Fundamentals n Accident Levels n Accidents n System Boundaries n Hazards n Safety Constraints n Control Actions n Control Structure

43 Hazard Analysis STPA: Fundamentals n Fundamentals n Accident Levels n Accidents n System Boundaries n Hazards n Safety Constraints Example 1. A human is killed or seriously injured. 2. A medical device s services are unavailable n Control Actions n Control Structure Tie into ISO s notions of criticality?

44 Hazard Analysis STPA: Fundamentals n Fundamentals n Accident Levels n Accidents n System Boundaries n Hazards n Safety Constraints Example 1. The patient is killed or seriously injured [DeathOrInjury] 2. The PCA pump stops responding to commands [DenialOfService] n Control Actions n Control Structure

45 Hazard Analysis STPA: Fundamentals n Fundamentals Example n Accident Levels n Accidents n System Boundaries Pulse Oximeter Process Boundary System Boundary App Boundary Patient n Hazards n Safety Constraints Capnography Device App PCA Pump n Control Actions n Control Structure Display Clinician

46 Hazard Analysis STPA: Fundamentals n Fundamentals n Accident Levels n Accidents n System Boundaries n Hazards n Safety Constraints n Control Actions n Control Structure Example 1. An inadvertent Pump Normally command is sent to the pump [PatientHarmed] 2. Commands are sent to the pump too quickly [PCADoS] Benefits: Regulators: Supports strong traceability both in code and in (hypertext) reports

47 Hazard Analysis STPA: Fundamentals n Fundamentals n Accident Levels n Accidents n System Boundaries n Hazards n Safety Constraints Example 1. The app must only instruct the pump to run at a normal rate when the patient can tolerate more analgesic [InadvertentPumpNormally] 2. The app must wait for a designated length of time between sending pump commands [TooManyCommands] n Control Actions n Control Structure

48 STPA in AADL Fundamentals n Fundamentals n Accident Levels n Accidents n System Boundaries n Hazards n Safety Constraints n Control Actions n Control Structure Example App -> Pump: Pump Normally Actuator Benefits: Controller Process Sensor Developers: Hazard Analysis artifacts are automatically in-sync with system architecture

49 Hazard Analysis STPA: Fundamentals n Fundamentals n Accident Levels n Accidents Example Physiological Status Patient n System Boundaries n Hazards n Safety Constraints Pulse Oximeter Capnography Device Physiological Data Device Ok Device Error App Pump Normal Pump KVO Request More PCA Pump Pump Status n Control Actions n Control Structure Display Physiological Data Pump Normal Pump KVO Device Ok Device Error View Patient Status View Device Status Provide Rx Authorize Override Clinician Verify Rx

50 Hazard Analysis STPA: Identifying Hazardous Control Actions n Hazardous Control Action Table n Cross-product of control actions and STPA guidewords Control Action Providing Not Providing Applied too Long Stopped too Soon Early Late App -> Pump: Pump Normally PH Not Hazardous PH Not Hazardous PH Not Hazardous App -> Disp: Patient Ok BID BID BID BID BID BID PulseOx->App: Provide SpO 2 Not Hazardous PH, BID Not Hazardous PH, BID Not Hazardous PH, BID PulseOx->App: Provide Pulse Rate Not Hazardous PH, BID Not Hazardous PH, BID Not Hazardous PH, BID PH = Patient Harmed BID = Bad Info Displayed

51 Hazard Analysis STPA: Hazardous Causes and Compensations Control Action: App -> Pump: Pump Normally n Providing: n Bad Data: n Cause: n Incorrect values are gathered from one of the physiological sensors n Compensation: n n Not Providing: Rely on multiple sensed physiological parameters to provide redundancy n Not hazardous

52 Hazard Analysis STPA: Hazardous Causes and Compensations Control Action: App -> Pump: Pump Normally n Wrong Timing or Order: n Not applicable n Too Long n Network Drop n Cause: n Network drops out, leaving the pump running normally regardless of the patient s health n Compensation: n Commands to pump normally have an associated maximum time, after which the pump returns to KVO

53 STPA in AADL Where should we start? Control Action: App > PCA Pump A control action is provided in an unsafe way Feedback Message: PulseOx > App How would the control action be unsafe? Controller: App What Logic constraint would be violated? What should the occurrence be named? What would cause this to occur? How can this occurrence be compensated for? Actuator: PCA Pump Sensor: Pulse Oximeter Controlled Process: Patient

54 Hazard Analysis Annotating our Architectural Model How would the control action be unsafe? What constraint would be violated? What should the occurrence be named? What would cause this to occur? How can this occurrence be compensated for? We ll come back to this one in a moment

55 Report Generation Development Automatic report generation AADL Component Architecture with Hazard Annotations n n n Development of component architecture using AADL / OSATE2 Addition of Hazard Analysis Annotations Automatic generation of STPA-Styled Hazard Analysis Report Example In Progress Report Online at:

56 STPA s Causality Guidewords Annotated Control Loop Benefits: Managers: Constrains developers so style and architectural assumptions are consistent Developers: Guides analysis so starting from scratch isn t necessary Nancy Leveson. Figure 4.8, Page 93, Engineering A Safer World. MIT Press, 2011

57 AADL EM Fault Types Type Hierarchy Error Library Type STPA Error Type App Error Type Errors with Physiological Monitors LateDelivery DelayedOperation SpO2ValueLate IncorrectValue IncorrectInformation SpO2ValueLow N/A NoInformation NoSpO2Data Errors with App Logic ServiceCommission InnapropriateCtrlAction InadvertentPumpNormally ServiceOmission MissingCtrlAction InadvertentPumpMinimally AADL Standard Error Types STPA Guidewords App Specific Error Types

58 AADL EM Fault Types App Specific Error Library Application independent: Sourced from STPA Application specific: Defined by app risk management process

59 STPA in AADL Using our fault type Control Action: App > PCA Pump Inadvertent Pump Normally Feedback Message: PulseOx > App Controller: App Logic Actuator: PCA Pump Sensor: Pulse Oximeter Controlled Process: Patient

60 Integrated Hazard Analysis Using our fault type What specific fault will result? What can we do with our model + specific fault information?

61 STPA in AADL Where would the bad control action come from? Control Action: App > PCA Pump Feedback Message: PulseOx > App Controller: App Logic Controller: App Logic Process Model Incorrect: Wrongly believes patient to be healthy Propagates error out Actuator: PCA Pump Sensor: Pulse Oximeter Controlled Process: Patient

62 Integrated Hazard Analysis Specification Step 1: Out Propagation SpO2 App Logic PumpCmd Outgoing Port Outgoing Fault

63 STPA in AADL Where would the bad control action come from? Control Action: App > PCA Pump Feedback Message: PulseOx > App Controller: App Logic Controller: App Logic Process Model Incorrect: Wrongly believes patient to be healthy Bad information in Actuator: PCA Pump Sensor: Pulse Oximeter Controlled Process: Patient

64 Integrated Hazard Analysis Specification Step 2: In Propagation SpO2 App Logic PumpCmd Incoming Port Incoming Fault

65 Integrated Hazard Analysis Specification Step 3: Relation between incoming and outgoing SpO2 App Logic PumpCmd Name of flow Type of flow Specific faults Specific Ports

66 STPA in AADL Where should we go now? Control Action: App > PCA Pump Feedback Message: PulseOx > App Controller: App Logic Controller: App Logic Process Model Incorrect: Wrongly believes patient to be healthy Option 2: Look for the impact Actuator: PCA Pump Option 1: Look for the source Sensor: Pulse Oximeter Controlled Process: Patient

67 STPA in AADL Where should we go now? Option 3: Look for other sources / impacts App Logic Display PCA Pump Pulse Oximeter Clinician Patient

68 Integrated Hazard Analysis OSATE Remembers A Neglected Connection App Logic Display Pulse Oximeter

69 Tool Supported Process Interaction between Report and Model Cause > Effect 4. What else could cause this error? 3. Where else could this fault go? 1. Here s an empty cell (STPA Keyword + Control Action) could anything go wrong? 2. Create occurrence and supporting EM annotations Effect > Cause

70 Impacts n Automation n Traditionally, analysts have to mine a system and maintain it without tool support n Architectural integration n Faults can be bound to specific components and ports n Future: n Testing + Fault Injection n If a compensation is claimed, we can autogenerate a test

71 Outline n Background n Vision n Language n Tool n STPA n Future n Next Steps n Tool Extensions

72 Next Steps Compositional Reasoning and Assurance Cases Requirements Clinical Use Case / Workflow Description App Developer Assurance Case 3 rd Party Certifiers 3 rd Party ICE Conformance & Safety Certification Submission Package Hazard Analysis MDCF FDA 510K Submission Package App Deployment FDA Evaluators Risk Assessment

73 Future Tool extensions n Abstraction Depth n Model methods / functions n Data Types n CORBA IDL n MAP Device Drivers n Logging Annotations

74 Further Reading n Source available online at n Installable into OSATE2 via update site: updatesite n Full documentation online at n Publications online at

75 Applying STPA-based Hazard Analysis to support HBSE for Systems built using MAPs ISPCE 2015 Chicago, IL, USA Sam Procter, John Hatcliff, Kim Fowler SAnToS Lab Kansas State University Anura Fernando Underwriters Laboratories Sandy Weininger Food and Drug Admin. Support: This work is supported in part by the US National Science Foundation (NSF) (# ), the NSF US Food and Drug Administration Scholarin-Residence Program (# ) and the National Institutes of Health / NIBIB Quantum Program.