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

State of the Practice: State of the Practice: Development of Implantable Medical DevicesDevelopment of Implantable Medical Devices

State of the Practice: State of the Practice: Development of Implantable Medical DevicesDevelopment of Implantable Medical Devices

Software in Safety Critical Systems MeetingSoftware in Safety Critical Systems Meeting

Software in Safety Critical Systems Meeting 2/27/01

System ContextSystem Context

• Implantable Defibrillator / PacemakerImplantable Defibrillator / Pacemaker• Monitors heart rhythms Monitors 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


Defibrillator / Pacemaker ContextDefibrillator / Pacemaker Context

• ConstraintsConstraints– SizeSize

• 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

– PowerPower• 1500 mAH battery, 7 year longevity1500 mAH battery, 7 year longevity• 28 28 µa average current drainµa average current drain

• System metricsSystem metrics– 2,783,000 custom transistors2,783,000 custom transistors– 33,000,000 OTS transistors33,000,000 OTS transistors– 30 KLOC full function30 KLOC full function– 3 KLOC limited function safety core3 KLOC limited function safety core


Regulatory ContextRegulatory Context

• World wide World wide – FDA in USAFDA in USA– CE Mark in EuropeCE Mark in Europe– Various country dependent agencies (example, Japan)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


Development MethodologyDevelopment Methodology

• Modified Waterfall development methodologyModified Waterfall development methodology• ConceptConcept

• RequirementsRequirements

• DesignDesign

• ImplementationImplementation

• ValidationValidation

– Modified with feedback loopsModified with feedback loops


Safety AdvocateSafety Advocate

• Role:Role:– Plan and maintain the safety casePlan and maintain the safety case– Perform or coordinate the various risk Perform or coordinate the various risk

analysesanalyses– Analyze and resolve safety issues through life Analyze and resolve safety issues through life

cyclecycle– Monitor development with safety perspectiveMonitor development with safety perspective– Review field reliability feedbackReview field reliability feedback


Product Development ModelProduct Development Model

ProgrammerRequirements

Model

PGRequirements

Model

SystemRequirements

High-LevelInterfaceSystem

Design

Prog. PG

Communication Subsystem Design

Parameter Interaction

Rules

User Parameters

PG Design

FWImplementation

Elect.Implementation

Mech.Implementation

Elect.Design

Mech.Design

FW Design

ProgrammerSoftware

Implementation

ProgrammerPlatform

(Zoom Plus)

Programmer Design

Programmer SW Design


Partition BetweenPartition Between FirmwareFirmware HardwareHardwarePG Design Model (in DOME)PG Design Model (in DOME)Activities/FeaturesActivities/FeaturesPG Requirements Model (in Statemate)PG Requirements Model (in Statemate)PG Reference ArchitecturePG Reference Architecture

PG ModelPG Model

A B

C D

Communication Links

Add StatechartsAdd Statecharts


Requirements PhaseRequirements Phase

• PG system modelsPG system models– System Requirements ModelSystem Requirements Model

• Statemate Magnum by I-Logix, Inc.Statemate Magnum by I-Logix, Inc.– Event driven behavioral view (Harel Statecharts) Event driven behavioral view (Harel Statecharts) – Hierarchy identical to architecture viewHierarchy identical to architecture view

– System Architecture ModelSystem Architecture Model• DOME (Domain Modeling Environment) by Honeywell, Inc.DOME (Domain Modeling Environment) by Honeywell, Inc.– Architecture viewArchitecture view– Functional and structural decompositionFunctional and structural decomposition– Captures Captures

• interfaces and hierarchyinterfaces and hierarchy• Intent and rationaleIntent and rationale• Non-behavioral requirementsNon-behavioral requirements

– In-house tools In-house tools • Merge DOME and Statemate information to produce Merge DOME and Statemate information to produce

document viewsdocument views


System Safety RequirementsSystem Safety Requirements

• Pervades model Pervades model – Dedicated architecture activitiesDedicated architecture activities• Safety coreSafety core

• Output monitorsOutput monitors

– Interface protocolsInterface protocols• ““Arm, fire, and disarm” sequencesArm, fire, and disarm” sequences

– BehavioralBehavioral• Deadline timersDeadline timers

– Non-functional Non-functional • Interaction constraints (TBD: behavioral?)Interaction constraints (TBD: behavioral?)


Architecture GoalsArchitecture Goals

• Get a handle on complexityGet a handle on complexity– Identify interdependenciesIdentify interdependencies

• Contain changeContain change– Minimize interdependenciesMinimize interdependencies– Provide extensibility to anticipated changesProvide extensibility to anticipated changes– Isolate platform specificsIsolate platform specifics– Maximize reusability of requirements, tests, Maximize reusability of requirements, tests,

designs, implementations, tooling and other designs, implementations, tooling and other decisionsdecisions

• Establish key qualities of the systemEstablish key qualities of the system– Safety and Fault ToleranceSafety and Fault Tolerance– TestabilityTestability


Safety Activity MapSafety Activity Map

Development Development PhasePhase

Safety ActivitySafety Activity

ConceptConcept •Preliminary Hazard Analysis (new features)Preliminary Hazard Analysis (new features)

RequirementsRequirements •Functional Failure Analysis (FFA)Functional Failure Analysis (FFA)

•Fault Tree Analysis (FTA)Fault Tree Analysis (FTA)

•Safety CaseSafety Case

•Requirement reviews / WalkthroughsRequirement reviews / Walkthroughs

DesignDesign •Hazards and Operability analysis (HAZOPS)Hazards and Operability analysis (HAZOPS)

ImplementationImplementation •Code reviews / WalkthroughsCode reviews / Walkthroughs

ValidationValidation •Update Safety Case - tracing to evidenceUpdate Safety Case - tracing to evidence

•Update Fault Tree Analysis – tracing to Update Fault Tree Analysis – tracing to requirements and validationrequirements and validation


Functional Failure Analysis (FFA)Functional Failure Analysis (FFA)

• Some system / software failure modes Some system / software failure modes – Failing to perform a required functionFailing to perform a required function– Performing an unintended functionPerforming an unintended function– Getting the wrong answerGetting the wrong answer– Issuing the wrong control instructionsIssuing the wrong control instructions– Doing the right thing but under inappropriate Doing the right thing but under inappropriate

conditionsconditions– Performing functions at the wrong time or in Performing functions at the wrong time or in

the wrong orderthe wrong order– Failing to recognize a hazardous condition Failing to recognize a hazardous condition

requiring corrective actionrequiring corrective action– Producing the wrong response to a hazardous Producing the wrong response to a hazardous

conditioncondition


Feedback Loop to system modelFeedback Loop to system model

• Fault Tree AnalysisFault Tree Analysis • Inputs Inputs

– Development feedback Development feedback • Lessons Learned Database Lessons Learned Database • Problems discovered during development of other related Problems discovered during development of other related

productsproducts– Reliability feedbackReliability feedback

• Field data collected from returned product and customer Field data collected from returned product and customer complaintscomplaints

– Historical hazards databaseHistorical hazards database– Functional failure analysisFunctional failure analysis

• OutputsOutputs– Identify causesIdentify causes– Assign risk levelsAssign risk levels– Develop mitigationsDevelop mitigations

• Feedback into modelFeedback into model


Peer Reviews / WalkthroughsPeer Reviews / Walkthroughs

• Peer reviews very effective (Boehm and Basili)Peer reviews very effective (Boehm and Basili)– Undirected reviews catch 60% of defectsUndirected reviews catch 60% of defects– Perspective-based reviews catch 35% more Perspective-based reviews catch 35% more

defects than undirected reviewsdefects than undirected reviews• Check List Targeting Safety (Lutz)Check List Targeting Safety (Lutz)– Contains 18 questions aimed at uncovering the Contains 18 questions aimed at uncovering the

two most common causes of two most common causes of safety-relatedsafety-related errors:errors:• Inadequate interface requirementsInadequate interface requirements

• Discrepancies between the documented Discrepancies between the documented requirements and the actual requirementsrequirements and the actual requirements


Design PhaseDesign Phase

• Architecture model decomposed at the leafs of Architecture model decomposed at the leafs of the hierarchy into software and hardware the hierarchy into software and hardware activitiesactivities

• Corresponding state charts capture the behavior Corresponding state charts capture the behavior each activityeach activity


Hazard and Operability Analysis (HAZOPS)Hazard and Operability Analysis (HAZOPS)

• Peer review of data and control flows using Peer review of data and control flows using checklists and guide wordschecklists and guide words– Examples: Examples: omission, commission, early, late, omission, commission, early, late,

value, none, part ofvalue, none, part of– Also provides review for completeness of Also provides review for completeness of

requirementsrequirements


ToolsTools

• Relex Relex – Supports FMECA and FTASupports FMECA and FTA

• SAM 2000SAM 2000– Supports FFA, Event tree, FMECA, FTA and Supports FFA, Event tree, FMECA, FTA and

HAZOPSHAZOPS


Implementation PhaseImplementation Phase

• What are the components of the implementation What are the components of the implementation and how do they interact?and how do they interact?– Computational activities: threads, services, hardware, Computational activities: threads, services, hardware,

interrupt service routinesinterrupt service routines– Communication: interrupts, signals, messages, Communication: interrupts, signals, messages,

functions calls, parameters, return values, global functions calls, parameters, return values, global variables, queues variables, queues

– Executive services: scheduling, interrupt mapping, Executive services: scheduling, interrupt mapping, memory management, timeout handling, signal and memory management, timeout handling, signal and message queuesmessage queues

– Resources: memory, semaphores, timers, static dataResources: memory, semaphores, timers, static data


Fault response classesFault response classes

• Class 1: System reset; if fault occurred within 10 Class 1: System reset; if fault occurred within 10 minutes of last system reset, additional response minutes of last system reset, additional response is to transfer operation to safety coreis 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


Rationale for resets as a responseRationale for resets as a response

• Resets can be accomplished in 2-3 second time Resets can be accomplished in 2-3 second time frameframe

• 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 An unexpected set of data has caused a

sequence that enables a design fault or sequence that enables a design fault or component failure.component failure.

– Restart hardware and firmware state machines Restart hardware and firmware state machines from a known state and retry with a new set of from a known state and retry with a new set of data (time redundancy)data (time redundancy)

• If fault is not transient, operation is transferred to If fault is not transient, operation is transferred to safety core (functional redundancy)safety core (functional redundancy)


Use of MonitorsUse of Monitors

• Safety MonitorsSafety Monitors– Excessive shocksExcessive shocks– High voltage leakageHigh voltage leakage– High rate pacingHigh rate pacing– Low rate pacingLow rate pacing– Memory errors (SEU)Memory errors (SEU)

• Wellness MonitorsWellness Monitors– Analog sensing (TBD)Analog sensing (TBD)– Battery / Power supplyBattery / Power supply– Beeper (TBD)Beeper (TBD)– Critical support Critical support

hardwarehardware– Data integrity Data integrity – Deadline timersDeadline timers

– Reed switchReed switch– HV capacitorHV capacitor– HV output switchesHV output switches– Memory and register Memory and register

access access – OscillatorOscillator– LeadsLeads


Fault Tolerant Techniques usedFault Tolerant Techniques used

• Data redundancyData redundancy• Time redundancyTime redundancy• Safety KernelSafety Kernel• Timing Deadlines Timing Deadlines


Safety CoreSafety Core

• Strategy:Strategy:– Very limited functionalityVery limited functionality– Reduce potential exposure to faults Reduce potential exposure to faults – Current products use ROM based Current products use ROM based µP µP controlcontrol– Working toward hardware based controlWorking toward hardware based control

• PacemakerPacemaker• Mostly hardware based, no programmabilityMostly hardware based, no programmability

• DefibrillatorDefibrillator• Uses common output hardware; limited Uses common output hardware; limited

programmabilityprogrammability


Safety CaseSafety Case

• A safety case presents a clear, comprehensive A safety case presents a clear, comprehensive and defensible and defensible argumentargument supported by calculation supported by calculation and procedure that a system is and procedure that a system is acceptablyacceptably safe to safe to operate in a particular operate in a particular contextcontext..


Goal Structuring Notation (GSN)Goal Structuring Notation (GSN)

• Graphical approach to representing the entities Graphical approach to representing the entities and relationships used in a safety argumentand relationships used in a safety argument

• Components:Components:– GoalGoal: a requirement, target, or constraint to be met by the : a requirement, target, or constraint to be met by the

systemsystem

– StrategyStrategy: a rule to be invoked in the solution of goals: a rule to be invoked in the solution of goals

– JustificationJustification: reason or evidence that supports a strategy: reason or evidence that supports a strategy

– ConstraintConstraint: restricts the way in which goals can be solved: restricts the way in which goals can be solved

– ContextContext: bounds the argument: bounds the argument

– SolutionSolution: individual pieces of analysis, evidence, test results, : individual pieces of analysis, evidence, test results, references to design material, etc.references to design material, etc.


GSN ExampleGSN Example

G1System is Safe

S1Argument byaddressing allidentifiedhazards

S2Argument ofcompliancewith standards& regulations

C1

See hazarddictionary

C2All applicablestandards listedin DOP5097

G2Hazard X hasbeen eliminated

G3Probability ofHazard Yoccurring is < 1x10**-6

G1

Systemdeveloped to

Integrety level 4

C3

Limit forcatastrophichazards is1x10**-6

Sn1

Fault treeanalysis

Sn2

FormalVerification

Sn3

ProcessEvidence


Q & AQ & A

• ??

Documents

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