Development of Implantable Medical Devices

offbeatnothingΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

66 εμφανίσεις

State of the Practice:

Development of Implantable Medical Devices

Software in Safety Critical Systems Meeting

Software in Safety Critical Systems Meeting







2/27/01

System Context


Implantable Defibrillator / Pacemaker


Monitors heart rhythms


Controls pacing or shock therapy


Collects patient and device diagnostics


Leads


Connects sensors


Delivers therapy


PC based Programmer


Main user interface


Configures defibrillator / pacemaker


Retrieves and displays data



Software in Safety Critical Systems Meeting







2/27/01

Defibrillator / Pacemaker Context


Constraints



Size


24 cc total


7 cc battery, 6 cc output capacitor


11 cc control electronics and connectors


Power


1500 mAH battery, 7 year longevity


28
µa average current drain


System metrics


2,783,000 custom transistors


33,000,000 OTS transistors


30 KLOC full function


3 KLOC limited function safety core

Software in Safety Critical Systems Meeting







2/27/01

Regulatory Context


World wide


FDA in USA


CE Mark in Europe


Various country dependent agencies (example, Japan)


Standards


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

Software in Safety Critical Systems Meeting







2/27/01

Development Methodology


Modified Waterfall development methodology


Concept


Requirements


Design


Implementation


Validation


Modified with feedback loops

Software in Safety Critical Systems Meeting







2/27/01

Safety Advocate


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

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

Software in Safety Critical Systems Meeting







2/27/01

Partition Between

Firmware

Hardware

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

Software in Safety Critical Systems Meeting







2/27/01

Requirements Phase


PG system models


System Requirements Model


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.


Architecture view


Functional and structural decomposition


Captures


interfaces and hierarchy


Intent and rationale


Non
-
behavioral requirements


In
-
house tools


Merge DOME and Statemate information to produce
document views

Software in Safety Critical Systems Meeting







2/27/01

System Safety Requirements


Pervades model


Dedicated architecture activities


Safety core


Output monitors


Interface protocols


“Arm, fire, and disarm” sequences


Behavioral


Deadline timers


Non
-
functional


Interaction constraints (TBD: behavioral?)


Software in Safety Critical Systems Meeting







2/27/01

Architecture Goals


Get a handle on complexity


Identify interdependencies


Contain 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 system


Safety and Fault Tolerance


Testability

Software in Safety Critical Systems Meeting







2/27/01

Safety Activity Map

Development
Phase

Safety Activity

Concept


Preliminary Hazard Analysis (new features)

Requirements


Functional Failure Analysis (FFA)


Fault Tree Analysis (FTA)


Safety Case


Requirement reviews / Walkthroughs

Design


Hazards and Operability analysis (HAZOPS)

Implementation


Code reviews / Walkthroughs

Validation


Update Safety Case
-

tracing to evidence


Update Fault Tree Analysis


tracing to
requirements and validation

Software in Safety Critical Systems Meeting







2/27/01

Functional Failure Analysis (FFA)


Some 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

Software in Safety Critical Systems Meeting







2/27/01

Feedback Loop to system model


Fault Tree Analysis



Inputs


Development feedback


Lessons Learned Database


Problems discovered during development of other related
products


Reliability feedback


Field data collected from returned product and customer
complaints


Historical hazards database


Functional failure analysis


Outputs


Identify causes


Assign risk levels


Develop mitigations


Feedback into model


Software in Safety Critical Systems Meeting







2/27/01

Peer Reviews / Walkthroughs


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)


Contains 18 questions aimed at uncovering the
two most common causes of
safety
-
related

errors:


Inadequate interface requirements


Discrepancies between the documented
requirements and the actual requirements



Software in Safety Critical Systems Meeting







2/27/01

Design Phase


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


Corresponding state charts capture the behavior
each activity

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 words


Examples:
omission, commission, early, late,
value, none, part of


Also provides review for completeness of
requirements


Software in Safety Critical Systems Meeting







2/27/01

Tools


Relex


Supports FMECA and FTA


SAM 2000


Supports FFA, Event tree, FMECA, FTA and
HAZOPS

Software in Safety Critical Systems Meeting







2/27/01

Implementation Phase


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

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 core


Class 2: System reset each time fault occurs


Class 3: No system reset

Software in Safety Critical Systems Meeting







2/27/01

Rationale for resets as a response


Resets can be accomplished in 2
-
3 second time
frame


System unavailability for this time is acceptable


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)

Software in Safety Critical Systems Meeting







2/27/01

Use of Monitors


Safety Monitors


Excessive shocks


High voltage leakage


High rate pacing


Low rate pacing


Memory errors (SEU)


Wellness 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

Software in Safety Critical Systems Meeting







2/27/01

Fault Tolerant Techniques used


Data redundancy


Time redundancy


Safety Kernel


Timing Deadlines

Software in Safety Critical Systems Meeting







2/27/01

Safety Core


Strategy:


Very limited functionality


Reduce potential exposure to faults


Current products use ROM based
µP
control


Working toward hardware based control


Pacemaker


Mostly hardware based, no programmability


Defibrillator


Uses common output hardware; limited
programmability

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
.

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 argument



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.

Software in Safety Critical Systems Meeting







2/27/01

GSN Example

G1
System is Safe
S1
Argument by
addressing all
identified
hazards
S2
Argument of
compliance
with standards
& regulations
C1
See hazard
dictionary
C2
All applicable
standards listed
in DOP5097
G2
Hazard X has
been eliminated
G3
Probability of
Hazard Y
occurring is
< 1x10**-6
G1
System
developed to
Integrety level 4
C3
Limit for
catastrophic
hazards is
1x10**-6
Sn1
Fault tree
analysis
Sn2
Formal
Verification
Sn3
Process
Evidence
Software in Safety Critical Systems Meeting







2/27/01

Q & A


?