Manan Dua | Pacemaker & DCM (SFWRENG 3K04)

Overview & Purpose

This project, completed for the SFWRENG 3K04 course, involved the development of a safety-critical Pacemaker system and its accompanying Device Controller-Monitor (DCM). The primary goal was to design a real-time embedded system capable of managing and regulating a patient's heart rate through various pacing modes while ensuring robust safety and reliability.

The system is divided into two main components: the Pacemaker, running on hardware (simulated via Simulink on an FRDM-K64F board), and the DCM, a Python-based desktop application used by clinicians to program parameters and visualize heart activity. Key features include rate-adaptive pacing using accelerometer data, real-time Electrogram (ECG) visualization, and a secure database for patient management.

Team & Collaboration

This project was a comprehensive group effort involving six students: Adam Suljak, Jonathan Hincks, Yat Yin Hui (Heidi), Joshua Guo, Manan Dua, and Mohammad Mustafa. We adopted an Agile-like workflow, breaking down the massive requirements into modular tasks.

The development was split into distinct domains to ensure efficiency:

DCM Team: Focused on the Python GUI using CustomTkinter, implementing the Login, Pacing Modes, and Reports modules, and managing the SQLite database.
Pacemaker Team: Developed the Simulink models for the Bradycardia operating modes (AOO, VOO, AAI, VVI, etc.) and the rate-adaptive algorithms.
Integration: We collaborated closely to establish the UART serial communication protocol, ensuring seamless data transfer between the Python interface and the embedded hardware.

Components & Architecture

The system architecture bridges high-level software with low-level hardware control:

Device Controller-Monitor (DCM): A modular Python application built with CustomTkinter. It features a secure Login module using SQLite for credential and parameter storage, a Pacing Modes interface for configuration, and an ECG plotter using Matplotlib.
Pacemaker Model: Designed in Simulink and deployed on the FRDM-K64F. It implements the Finite State Machines (FSMs) for modes like VOOR and AAIR, handling sensing, pacing, and refractory periods.
Communication: A robust UART protocol running at 115200 baud connects the DCM and Pacemaker. We implemented custom packet structures for sending parameters (Echo) and receiving real-time ECG streams.

Build Process & Milestones

Phase 1: Foundation & Basic Modes

The Task: Establish the core architecture by building the DCM's user management system and implementing the four fundamental pacing modes: AOO, VOO, AAI, and VVI. This involved designing a scalable SQLite database schema to handle multiple users, ensuring that device parameters (like Upper Rate Limit and Pulse Width) were securely stored and retrievable for each specific patient.

Implementation: We built the GUI framework using Tkinter (later upgraded to CustomTkinter for better aesthetics) and defined the Stateflow logic in Simulink to handle basic pacing triggers and refractory periods (ARP/VRP).

Key Challenge: The initial challenge was creating a robust database structure that could link a specific user (clinician) to their patient's saved parameters without data collision, while also ensuring the UI inputs strictly validated numerical ranges before saving.

Phase 2: Rate Adaptivity & Serial Communication

The Task: The system needed to intelligently adjust pacing based on patient activity. We had to implement rate-adaptive modes (AOOR, VOOR, AAIR, VVIR) where the Lower Rate Limit (LRL) increases dynamically based on accelerometer data. Additionally, we needed to visualize live heart activity by plotting real-time ECG data on the DCM.

Implementation: We integrated the on-board accelerometer data into our Simulink model, mapping physical movement thresholds to specific "Response Factors" that drove the target heart rate. Simultaneously, we built the UART Channel module in Python to serialize parameter packets for transmission and deserialize incoming ECG stream data.

Key Challenge: A major hurdle was the UART synchronization with rate adaptivity. We faced issues where the pacemaker's independent functions would run at different clock rates and would interfere with eachother. Since the accelerameter on the pacemaker was required to run at a specific clock rate, it has to be placed in a clocked module inside simulink, however in doing so introduced errors when integrated the UART system. This caused parameter packets sent from the DCM to be occasionally dropped or malformed by the hardware or rate adaptiving not responding.

Phase 3: Safety Assurance & Verification

The Task: As a safety-critical device, "working" isn't enough; it must be proven safe. We were tasked with generating a formal Assurance Case to argue the safety of our system claims (e.g., "The system shall never pace above the Upper Rate Limit").

Implementation: We developed a structured argument tree linking high-level safety goals to specific evidence in our code and test results. We performed rigorous testing, including unit tests for the database and integration tests for the serial communication, to verify that invalid inputs (like negative pulse widths) were rejected at the source.

Key Challenge: The main difficulty was identifying and testing edge cases, such as what happens if the connection drops mid-transmission or if the accelerometer sends noisy data, and ensuring the Pacemaker defaulted to a safe state (nominal pacing) rather than halting.

Results

The final system successfully met all requirements for Deliverable 2.

Functionality: All 8 pacing modes are fully operational. The rate-adaptive logic correctly adjusts the heart rate based on simulated physical activity.
Connectivity: The DCM reliably connects to the Pacemaker via COM ports, with the "Connect/Disconnect" logic handling state changes gracefully.
Visualization: The ECG module plots real-time atrial and ventricular data with adjustable gain and visibility settings, allowing clinicians to analyze heart rhythms effectively.

Reflections & Learnings

This project provided invaluable insight into the lifecycle of safety-critical software. Key takeaways included:

Separation of Concerns: The importance of modular design (e.g., separating the UI logic in parameters.py from the backend logic in uartChannel.py) for maintainability and testing.
Safety First: Learning that reliability isn't an afterthought. Mechanisms like input validation ranges and connection monitoring are foundational to preventing patient harm.
Modern Tools: We leveraged Generative AI (GitHub Copilot) as a "pair programmer" to accelerate boilerplate code generation for the GUI and unit tests, allowing us to focus on complex logic and integration.