Transcript Guidant Standard PowerPoint Template

Software in Safety Critical Systems Meeting
State of the Practice:
Development of Implantable Medical Devices
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
User
Parameters
Parameter
Interaction
Rules
Programmer
Requirements
Model
PG
Requirements
Model
System
Requirements
High-Level
Interface
System
Design
Programmer
Design
Prog.
Programmer
SW Design
Programmer
Platform
(Zoom Plus)
Programmer
Software
Implementation
Software in Safety Critical Systems Meeting
PG
PG Design
Communication
Subsystem Design
FW Design
Elect.
Design
FW
Implementation
Elect.
Implementation
Mech.
Design
Mech.
Implementation
2/27/01
PG Model
A
B
AddCommunication
Statecharts
Links
D
C
Activities/Features
Partition
PG Requirements
PGBetween
Design
Reference
Model
Model
Firmware
Architecture
(in
(inDOME)
Statemate)
Hardware
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
Software in Safety Critical Systems Meeting
–
–
–
–
Reed switch
HV capacitor
HV output switches
Memory and register
access
– Oscillator
– Leads
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
Sys te m is Safe
S1
Argum e nt by
addre s s ing all
ide ntifie d
hazards
C1
Se e hazard
dictionary
C3
Lim it for
catas trophic
hazards is
1x10**-6
G3
Probability of
Hazard Y
occurring is
< 1x10**-6
Sn1
Fault tre e
analys is
Software in Safety Critical Systems Meeting
S2
Argum e nt of
com pliance
w ith s tandards
& re gulations
G2
Hazard X has
be e n e lim inate d
Sn2
Form al
Ve rification
C2
All applicable
s tandards lis te d
in DOP5097
G1
Sys te m
de ve lope d to
Inte gre ty le ve l 4
Sn3
Proce s s
Evide nce
2/27/01
Q&A
•?
Software in Safety Critical Systems Meeting
2/27/01