Figure 3 - uploaded by Mitchell Neilsen
Content may be subject to copyright.
Pacemaker (Pulse Generator) [6] 

Pacemaker (Pulse Generator) [6] 

Source publication
Conference Paper
Full-text available
In this paper, we describe a relatively inexpensive framework for the design of an academic dual chamber pacemaker and empirically analyze various existing designs. The goal of this framework is to provide a convenient platform that can be used for research and courses in real-time embedded system design. The framework can also be used to illustrat...

Context in source publication

Context 1
... the resulting system as an academic pacemaker . A group of students from the University of Minnesota accepted the challenge to develop a hardware prototype as their senior design project. Based on their design, the Software Quality Research Laboratory, in the Department of Computing and Software, at McMaster University developed new hardware evaluation boards using the Microchip 18F4520 PIC processor to control the pacing logic. This hardware prototype, shown on the right in Figure 1, is used in our framework as well. However, the focus of this paper is on the software framework used for pacing, device control, and management. A pacemaker is a medical device that delivers electrical impulses to the heart muscles to regulate the beating of the heart. The goal is to maintain a sufficient heart rate to compensate for irregularity or blockage in the patient's heart's electrical conduction system. Current pacemakers can be programmed by a cardiologist to select optimal pacing modes for individual patients. In some cases, a cardiologist may use a combination of pacemaker and defibrillator in a single implantable device and/or multiple electrodes placed on different positions in contact with the heart. For this framework, only a simple pacemaker with up to two electrodes (one for the ventricle and one for the atrium) are considered. For permanent pacing, the electrodes are placed in a chamber or several chambers of the heart. To simulate the heart, we use software to control a relatively low-cost (~$150 for academic use) 12-Bit, 10 kS/s multifunction DAQ from National Instruments, model USB-6008, as shown below in Figure 1. The MicroChip PICkit 2 or PICkit 3 can be used to program and debug the PIC18F4520 chip on the pacemaker board. Both devices can be connected via any available USB ports on any computer. It is very convenient to have the programmer, debugger, data acquisition and signal generation software all conveniently located on a single development system – they are currently all running on a low-end laptop running Windows 7. There are basically three different types of permanent pacemakers based on the number of chambers involved and their basic operation [2]. In a single-chamber pacemaker only one pacing lead is placed into a chamber of the heart, either atrium or ventricle. As shown above in Figure 1, only the ventricle is being paced and sensed in this example setup. However, the system shown above allows both chambers to be paced and sensed. With a dual- chamber pacemaker , electrodes are placed in both heart chambers. This type of pacemaker more closely resembles what happens with the natural pacing of the heart. Finally, a rate-responsive pacemaker has sensors that detect changes in the patient's physical activity and automatically adjust the pacing rate to fulfill the body's metabolic needs. On board the pacemaker shown in Figure 1 is an accelerometer that is used to monitor activity, and enable the development of software that is rate- responsive. The pacemaker generator is hermitically sealed with a power source, usually a lithium battery, a sensing amplifier which processes the electrical manifestation of naturally occurring heart beats as sensed by the heart electrodes, the pacing logic for the pacemaker and the output circuitry which delivers the pacing impulse to the electrodes. These are all embedded in the system shown in Figure 1. Even though the pacemaker will operate on a 9 volt battery, it is more convenient to power it using an external AC adapter. Modern pacemakers usually have multiple functions. The most basic form monitors the heart's native electrical rhythm. When the pacemaker fails to sense a heartbeat within a normal beat-to-beat time period, it will stimulate the ventricle of the heart with a short low voltage pulse. This sensing and stimulating activity continues on a beat by beat basis. The more complex forms include the ability to sense and/or stimulate both chambers of the heart. The basic ventricular "on demand" pacing mode is VVI or with automatic rate adjustment for exercise VVIR, which are suitable when no synchronization with the atrial beat is required. The range of available pacemaker modes is shown in Figure 2. Electronic pacemakers play a vital role in society. Several advancements have been made in pacemaker technology over the last fifty years, making current pacemakers highly sophisticated cardiac rhythm managers with thousands of lines of code. They are capable of correcting a myriad of complex heart abnormalities. They can also be easily reprogrammed to accommodate changes in the state of the heart as it ages. However, mode changes must be carefully applied to not interrupt the current operation of the pacemaker. The primary function of a typical pacemaker is to sense a person’s heartbeat, and pace the heart via electric stimulation when irregularities are detected. This is accomplished in many different ways due the variances found in heart conditions. Figure 3 shows a typical example of a pacemaker (pulse generator) implanted in the heart. The original hardware sensing circuit was reported to have high noise immunity with the ability to sense down to 37uV [6]. This was achieved by providing a variable gain and reference level for the circuit, under the control of a microprocessor. The pacing circuit is able to provide nearly continuous selectable voltage amplitudes ranging from 1.2 to 7 volts, and the pulse width is only limited by the maximum frequency of the clock. The lead impedance measurement circuit has the ability to provide an accurate impedance measurement with less than 1% error. Section 2 describes a simple and extensible software framework that can be used to design and analyze academic rate-responsive, dual-chamber pacemakers. Section 3 provides a simple analysis and plans for future analysis, and Section 4 concludes the paper. The main functions of an academic pacemaker can be divided into two categories: pace generation which must run in disconnected mode on the pacemaker, and device control and management which are components used to monitor and program the pacemaker. The majority of the device controller-monitor (DCM) runs on the PC and communicates with the pacemaker via a serial link. The controller passes pacemaker parameters from the PC to the pacemaker. These parameters are also logged in a database as they are changed. In this way, the controller client runs on the PC and the server runs on the pacemaker. In contract, data on electrical pulses that are sensed or pulsed on the pacemaker may need to be monitored. Although an external monitor, such as an electrocardiogram (EKG), could be used to monitor the heart, the monitor here can be used to observe the pacemaker activity directly. This information can also be logged by the DCM. To model an electrocardiogram, a data acquisition (DAQ) card can be used. In our framework, signals sensed by the pacemaker are generated by the DAQ, and on the flip-side, pace signals generated by the pacemaker, ranging from 1.2 to 7.0 volts, can be sensed and logged by the DAQ. The DAQ that we are using can sense 10,000 signals per second, but can only generate signals at a rate of 150 Hz. With our limited testing, this has not been a problem. It is important to have the capability to sense a large number of signals per second so that the paced signals are not lost even with a very narrow pulse width. As shown in Figure 4, National Instrument's Signal Express software can be used to simulate a heart by generating a square pulse of 69 mV at 1 Hz (generated in the top graph, sensed in the bottom graph). Signals can also be generated by an open- source tool called PDAQtools. More accurate representations of the ventricular and atrial signals can be generated. It is very easy to change the amplitude and rate of each signal generated. Also, the signals can be easily logged for more careful analysis as shown below in Figure 5. In this case, the square wave signal representing a heart beat has it's amplitude reduced from 69 mV to 59 mV. Then, as the output log shows, some of the signals are not sensed as heart beats, causing the pacemaker to generate a pacing signal with an amplitude of 3.5 volts. With an amplitude of 69 mV, all signals are sensed as shown in the DCM output shown in Figure 6. The overall system architecture consists of two major components, the Device-Controller Monitor and the Pulse Generator. The Device- Controller Monitor (DCM) has a graphical user interface with three tabs: Patient Information to specify a patient and retrieve historical data from a database, the current pacemaker configuration is automatically populated in the second tab when a patient's data is loaded. If the patient is new, then system default values are loaded. The Pacemaker Configuration tab allows a cardiologist to select a mode (from those shown in Figure 2). Depending on the mode, a set of configuration parameters can be specified and sent to the pacemaker to reprogram the pacemaker. Once a user connects to a given pacemaker and optionally reprograms the parameters, then real-time EKG data is transmitted periodically from a monitor on the pacemaker board back to the DCM. The parameters are also recorded in an EEPROM on the pacemaker board so that it can continue to operate in disconnected mode without intervention from the DCM. The Pulse Generator (PG) on the pacemaker board is responsible for sensing and generating pulsing signals as needed to keep the patient's heart beating. To facilitate automated generation of PG code, we have divided the code running on the pacemaker into two different categories: hardware- dependent and hardware-independent. The Hardware Abstraction Layer (HAL) provides the majority of the code which is not dependent on the particular hardware with a clean interface to the hardware dependent code which consists of device drivers, timers, etc. In this way, we hope to facilitate the ...

Citations

... These communication links enable informing remote medical staff on the patient's health condition. Besides transceiver units, defibrillators have several sensor devices and the shock-pulse generator as the most important output device [151,191,194]. The main challenge from a system-software perspective is handling the mixed con-Mixed Time & ...
Thesis
Full-text available
The increasing number of embedded systems spawns applications with critical constraints in both execution time and energy consumption. For their reliable operation, these energy-constrained real-time systems require bounds of their tasks' execution time as well as energy consumption in order to guarantee the completion within given resource budgets. While traditional worst-case program-code-analysis tools perform well in determining the worst-case execution time of tasks, they are not directly applicable to the problem of energy consumption: For the determination of energy-consumption bounds, it is insufficient to only consider real-time scheduling priorities, because any task can temporarily activate devices (e.g., transceivers) and thereby contribute to the whole system's power demand. This power demand, in turn, influences the energy consumption of all tasks in the system, irrespective of real-time priorities. Additional to the missing approaches for energy-consumption bounds, static worst-case analyzers, in general, come with the fundamental problem of unknown accuracies in the reported worst-case bounds. Since the actual worst case is not available from any benchmark program, it is impossible to compare the analyzer's reported bound and assess its pessimism, which inherently prevents comprehensive evaluations and validations of analysis techniques. This thesis addresses these problems by first presenting an approach to determining energy-consumption bounds while accounting for temporarily active devices, the fixed-priority real-time scheduling, synchronous task activations, and asynchronous interrupts. Since the analysis approach context-sensitively includes all possible interferences, it eventually determines the worst-case response energy consumption (WCRE) of tasks. The approach initially decomposes the target system under consideration of scheduling- and energy-relevant events. While relying on the decomposed representation, the approach then explores all possible system-wide program paths. Knowledge of these explored paths eventually allows determining WCRE bounds with means of sound problem formulations. To address the problem of the bounds' analysis pessimism, this thesis introduces a novel approach to assessing the accuracy of analyzers based on automatically generated benchmarks. This benchmark-generation algorithm combines small program patterns in a way that the worst case is available together with the woven benchmark. Knowledge of the generated benchmark's actual worst case then serves as a baseline for comprehensive evaluations and validations. The worst-case analysis approaches and their validation are the foundation to enable safe schedules. To complete the necessary components for reliably operating energy-constrained real-time systems, this thesis presents an operating-system kernel that utilizes worst-case resource bounds for time and energy. The kernel's scheduling approach dynamically reacts to scenarios where one resource becomes more critical than the other. This approach is aware of said analysis pessimism and effectively makes use of it while still guaranteeing the execution of critical tasks within statically determined time and energy bounds.