CARDIAC PACING AND DEFIBRILLATION - Design and Development of Medical Electronic Instrumentation - page 391

Of course, safety is by far the major concern in a medical device. Modern pacemakers
incorporate fault-detection mechanisms such that if a fault condition arises, they will not
cause harm to the patient. In some devices, redundancy is incorporated in the design of the
pacemaker circuitry to ensure the maintenance of pacing therapy in the event of crystal
oscillator, microprocessor, or other failures. When such a safety measure is implemented,
the pacemaker may incorporate a backup pacing controller that runs on independent cir-
cuitry (either a separate microcontroller or dedicated logic) with conservative parameters
that su ce to provide life-sustaining therapy to most patients.

The pacemaker presented in this section does not have redundant pacing capabilities.
By way of example, however, the pacemaker's firmware incorporates some fault-detection

mechanisms. Tripping any of the following fault detectors causes the device's pacing ther-
apy to be deactivated:

fi

• RAM signature. Possible catastrophic RAM failures cause all volatile memory loca-
tions to be written with hex 00 or hex FF. These failures can be detected by initializ-
ing a speci fi c volatile memory location with a test value (a “signature”) and having

firmware check for the presence of this value on every cardiac cycle.
• Parameter shadowing. Programmable devices keep parameters that reside in vari-
ables that should remain invariant at all times except when a programming operation
takes place. For this reason, it is convenient to keep a duplicate copy of the parame-
ter area (parameter “shadow”) and check consistency of the main parameter area with
its shadow on every cardiac cycle.
• Program counter outside program area. Unexpected intrusions of the program counter
into areas outside that used for the device's program can be detected by

the fi

filling any free
program memory with instructions to jump to a known safe program instruction.

fi

SOFTWARE TESTING

Implantable pacemakers and de brillators take care of conditions that could lead to the

patient's death if left untreated. In addition, inappropriately delivered stimuli can cause
dangerous and even lethal tachyarrhythmias. For this reason, testing of implantable car-
diac stimulators has to be planned and performed with utmost care. Verifying that the
hardware of the device works properly is relatively straightforward, since it usually
involves injecting known test signals to the various subcircuits and verifying their opera-
tion. In addition, various kinds of hardware-related faults can be simulated readily using
external hardware.
On the other hand, testing proper operation of the software is more involved and less of
a common area for the uninitiated. Probably the most important tool for software testing
starts with the design of the software itself. The key to simplifying testing is in writing
clean, simple code which is as legible as possible and as close as possible to the formal
language used to describe the operation of the device—in this case using

fi

fi finite-state

machines and timer events.
In the example project presented above, testing would not only involve assessing proper
operation of the various circuits and the ways in which the microprocessor controls them,
but also the operation of the system as a whole, paying special attention to power con-
sumption, operation of the [GetEvent()] routine and tests of the behavior of the device in
the presence of noise. A reasonable approximation could be connecting the sensing input
to a signal generator and verifying that the device enters the noise mode in the presence of
signals sensed with a frequency over 10 Hz. Besides the clock, the device has a single
external signal input, making it relatively easy to probe its behavior in response to di ff erent

signal patterns.