1. State of the Practice: Development of Implantable Medical Devices Software in Safety Critical Systems Meeting

2. Software in Safety Critical Systems Meeting 2/27/01 System Context Implantable Defibrillator / PacemakerImplantable Defibrillator / Pacemaker Monitors heart rhythmsMonitors heart rhythms Controls pacing or shock therapyControls pacing or shock therapy Collects patient and device diagnosticsCollects patient and device diagnostics LeadsLeads Connects sensorsConnects sensors Delivers therapyDelivers therapy PC based ProgrammerPC based Programmer Main user interfaceMain user interface Configures defibrillator / pacemakerConfigures defibrillator / pacemaker Retrieves and displays dataRetrieves and displays data

3. Software in Safety Critical Systems Meeting 2/27/01 Defibrillator / Pacemaker Context ConstraintsConstraints –Size 24 cc total24 cc total 7 cc battery, 6 cc output capacitor7 cc battery, 6 cc output capacitor 11 cc control electronics and connectors11 cc control electronics and connectors –Power 1500 mAH battery, 7 year longevity1500 mAH battery, 7 year longevity 28 µa average current drain28 µa average current drain System metricsSystem metrics –2,783,000 custom transistors –33,000,000 OTS transistors –30 KLOC full function –3 KLOC limited function safety core

4. Software in Safety Critical Systems Meeting 2/27/01 Regulatory Context World wideWorld wide –FDA in USA –CE Mark in Europe –Various country dependent agencies (example, Japan) StandardsStandards – –EN 1441, Medical Devices - Risk Analysis (ISO/DIS 14971 Risk Management) – –IEC 61508-3, Functional Safety of Electrical / Electronic / Programmable Electronic Safety-Related Systems - Software Requirements – –IEC 60601-1-4, Medical Electrical Equipment – Part 1 General Requirements for Safety, 4 Safety Requirements for Programmable Electronic Medical Systems – –FDA Guidance, Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management – –AAMI HE 48, Human Factors Engineering – –AAMI SW68, Medical device software - Software Life Cycle Processes – –ISO 12207, Information Technology - Software Life Cycle Process – –FDA Draft Guidance, General Principles of Software Validation – –FDA Guidance for Off-the-Shelf Software Use in Medical Devices – –FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

5. Software in Safety Critical Systems Meeting 2/27/01 Development Methodology Modified Waterfall development methodologyModified Waterfall development methodology ConceptConcept RequirementsRequirements DesignDesign ImplementationImplementation ValidationValidation –Modified with feedback loops

6. Software in Safety Critical Systems Meeting 2/27/01 Safety Advocate Role:Role: –Plan and maintain the safety case –Perform or coordinate the various risk analyses –Analyze and resolve safety issues through life cycle –Monitor development with safety perspective –Review field reliability feedback

7. Software in Safety Critical Systems Meeting 2/27/01 Product Development Model Programmer Requirements Model PG Requirements Model System Requirements High-Level Interface System Design Prog. PG Communication Subsystem Design Parameter Interaction Rules User Parameters PG Design FW Implementation Elect. Implementation Mech. Implementation Elect. Design Mech. Design FW Design Programmer Software Implementation Programmer Platform (Zoom Plus) Programmer Design Programmer SW Design

8. Software in Safety Critical Systems Meeting 2/27/01 Partition Between FirmwareHardware PG Design Model (in DOME) Activities/Features PG Requirements Model (in Statemate) PG Reference Architecture PG Model A B C D Communication Links Add Statecharts

9. Software in Safety Critical Systems Meeting 2/27/01 Requirements Phase PG system modelsPG system models –System Requirements Model Statemate Magnum by I-Logix, Inc.Statemate Magnum by I-Logix, Inc. –Event driven behavioral view (Harel Statecharts) –Hierarchy identical to architecture view –System Architecture Model DOME (Domain Modeling Environment) by Honeywell, Inc.DOME (Domain Modeling Environment) by Honeywell, Inc. –Architecture view –Functional and structural decomposition –Captures interfaces and hierarchy interfaces and hierarchy Intent and rationale Intent and rationale Non-behavioral requirements Non-behavioral requirements –In-house tools Merge DOME and Statemate information to produce document viewsMerge DOME and Statemate information to produce document views

10. Software in Safety Critical Systems Meeting 2/27/01 System Safety Requirements Pervades modelPervades model –Dedicated architecture activities Safety coreSafety core Output monitorsOutput monitors –Interface protocols Arm, fire, and disarm sequencesArm, fire, and disarm sequences –Behavioral Deadline timersDeadline timers –Non-functional Interaction constraints (TBD: behavioral?)Interaction constraints (TBD: behavioral?)

11. Software in Safety Critical Systems Meeting 2/27/01 Architecture Goals Get a handle on complexityGet a handle on complexity –Identify interdependencies Contain changeContain change –Minimize interdependencies –Provide extensibility to anticipated changes –Isolate platform specifics –Maximize reusability of requirements, tests, designs, implementations, tooling and other decisions Establish key qualities of the systemEstablish key qualities of the system –Safety and Fault Tolerance –Testability

12. Software in Safety Critical Systems Meeting 2/27/01 Safety Activity Map Development Phase Safety Activity Concept Preliminary Hazard Analysis (new features)Preliminary Hazard Analysis (new features) Requirements Functional Failure Analysis (FFA)Functional Failure Analysis (FFA) Fault Tree Analysis (FTA)Fault Tree Analysis (FTA) Safety CaseSafety Case Requirement reviews / WalkthroughsRequirement reviews / Walkthroughs Design Hazards and Operability analysis (HAZOPS)Hazards and Operability analysis (HAZOPS) Implementation Code reviews / WalkthroughsCode reviews / Walkthroughs Validation Update Safety Case - tracing to evidenceUpdate Safety Case - tracing to evidence Update Fault Tree Analysis – tracing to requirements and validationUpdate Fault Tree Analysis – tracing to requirements and validation

13. Software in Safety Critical Systems Meeting 2/27/01 Functional Failure Analysis (FFA) Some system / software failure modesSome system / software failure modes –Failing to perform a required function –Performing an unintended function –Getting the wrong answer –Issuing the wrong control instructions –Doing the right thing but under inappropriate conditions –Performing functions at the wrong time or in the wrong order –Failing to recognize a hazardous condition requiring corrective action –Producing the wrong response to a hazardous condition

14. Software in Safety Critical Systems Meeting 2/27/01 Feedback Loop to system model Fault Tree AnalysisFault Tree Analysis InputsInputs –Development feedback Lessons Learned DatabaseLessons Learned Database Problems discovered during development of other related productsProblems discovered during development of other related products –Reliability feedback Field data collected from returned product and customer complaintsField data collected from returned product and customer complaints –Historical hazards database –Functional failure analysis OutputsOutputs –Identify causes –Assign risk levels –Develop mitigations Feedback into modelFeedback into model

15. Software in Safety Critical Systems Meeting 2/27/01 Peer Reviews / Walkthroughs Peer reviews very effective (Boehm and Basili)Peer reviews very effective (Boehm and Basili) –Undirected reviews catch 60% of defects –Perspective-based reviews catch 35% more defects than undirected reviews Check List Targeting Safety (Lutz)Check List Targeting Safety (Lutz) –Contains 18 questions aimed at uncovering the two most common causes of safety-related errors: Inadequate interface requirementsInadequate interface requirements Discrepancies between the documented requirements and the actual requirementsDiscrepancies between the documented requirements and the actual requirements

16. Software in Safety Critical Systems Meeting 2/27/01 Design Phase Architecture model decomposed at the leafs of the hierarchy into software and hardware activitiesArchitecture model decomposed at the leafs of the hierarchy into software and hardware activities Corresponding state charts capture the behavior each activityCorresponding state charts capture the behavior each activity

17. Software in Safety Critical Systems Meeting 2/27/01 Hazard and Operability Analysis (HAZOPS) Peer review of data and control flows using checklists and guide wordsPeer review of data and control flows using checklists and guide words –Examples: omission, commission, early, late, value, none, part of –Also provides review for completeness of requirements

18. Software in Safety Critical Systems Meeting 2/27/01 Tools RelexRelex –Supports FMECA and FTA SAM 2000SAM 2000 –Supports FFA, Event tree, FMECA, FTA and HAZOPS

19. Software in Safety Critical Systems Meeting 2/27/01 Implementation Phase What are the components of the implementation and how do they interact?What are the components of the implementation and how do they interact? –Computational activities: threads, services, hardware, interrupt service routines –Communication: interrupts, signals, messages, functions calls, parameters, return values, global variables, queues –Executive services: scheduling, interrupt mapping, memory management, timeout handling, signal and message queues –Resources: memory, semaphores, timers, static data

20. Software in Safety Critical Systems Meeting 2/27/01 Fault response classes Class 1: System reset; if fault occurred within 10 minutes of last system reset, additional response is to transfer operation to safety coreClass 1: System reset; if fault occurred within 10 minutes of last system reset, additional response is to transfer operation to safety core Class 2: System reset each time fault occursClass 2: System reset each time fault occurs Class 3: No system resetClass 3: No system reset

21. Software in Safety Critical Systems Meeting 2/27/01 Rationale for resets as a response Resets can be accomplished in 2-3 second time frameResets can be accomplished in 2-3 second time frame System unavailability for this time is acceptableSystem unavailability for this time is acceptable Assumes transient fault first:Assumes transient fault first: –An unexpected set of data has caused a sequence that enables a design fault or component failure. –Restart hardware and firmware state machines from a known state and retry with a new set of data (time redundancy) If fault is not transient, operation is transferred to safety core (functional redundancy)If fault is not transient, operation is transferred to safety core (functional redundancy)

22. Software in Safety Critical Systems Meeting 2/27/01 Use of Monitors Safety MonitorsSafety Monitors –Excessive shocks –High voltage leakage –High rate pacing –Low rate pacing –Memory errors (SEU) Wellness MonitorsWellness Monitors –Analog sensing (TBD) –Battery / Power supply –Beeper (TBD) –Critical support hardware –Data integrity –Deadline timers –Reed switch –HV capacitor –HV output switches –Memory and register access –Oscillator –Leads

23. Software in Safety Critical Systems Meeting 2/27/01 Fault Tolerant Techniques used Data redundancyData redundancy Time redundancyTime redundancy Safety KernelSafety Kernel Timing DeadlinesTiming Deadlines

24. Software in Safety Critical Systems Meeting 2/27/01 Safety Core Strategy:Strategy: –Very limited functionality –Reduce potential exposure to faults –Current products use ROM based µP control –Working toward hardware based control PacemakerPacemaker Mostly hardware based, no programmabilityMostly hardware based, no programmability DefibrillatorDefibrillator Uses common output hardware; limited programmabilityUses common output hardware; limited programmability

25. Software in Safety Critical Systems Meeting 2/27/01 Safety Case A safety case presents a clear, comprehensive and defensible argument supported by calculation and procedure that a system is acceptably safe to operate in a particular context.A safety case presents a clear, comprehensive and defensible argument supported by calculation and procedure that a system is acceptably safe to operate in a particular context.

26. Software in Safety Critical Systems Meeting 2/27/01 Goal Structuring Notation (GSN) Graphical approach to representing the entities and relationships used in a safety argumentGraphical approach to representing the entities and relationships used in a safety argument Components:Components: –Goal: a requirement, target, or constraint to be met by the system –Strategy: a rule to be invoked in the solution of goals –Justification: reason or evidence that supports a strategy –Constraint: restricts the way in which goals can be solved –Context: bounds the argument –Solution: individual pieces of analysis, evidence, test results, references to design material, etc.

27. Software in Safety Critical Systems Meeting 2/27/01 GSN Example

28. Software in Safety Critical Systems Meeting 2/27/01 Q & A ?