Inspiration
Hospital ICUs generate hundreds of alarms per patient per day, and studies show the vast majority are false or non-actionable. A big cause is brittle alarm logic running on general-purpose operating systems that cannot guarantee when alarm evaluation happens. I wanted to show that a deterministic real-time design on QNX 8.0 can make vitals alarms both fast and trustworthy.
What it does
VitalsGuard-RT is a deterministic patient-vitals alarm engine running on the QNX 8.0 microkernel. A resource manager serves vitals waveforms (ECG, SpO2, respiration) through /dev/vitals. A 100 Hz SCHED_FIFO analyzer thread evaluates heart rate, SpO2 and respiratory rate against clinical thresholds and raises pulse-driven alarms to a dedicated alarm daemon. A fail-safe watchdog trips an audible alert if any real-time thread misses its deadline. A live web dashboard shows waveforms, alarm state and measured scheduling latency. It runs entirely on the free QNX 8.0 SDP under QEMU - no hardware required.
How I built it
Everything is C and POSIX, cross-compiled with qcc against the QNX 8.0 SDP and run on the QEMU x86_64 target of the free QNX 8.0 Quick Start Target Image:
- A resource manager exposes /dev/vitals/waveform and /dev/vitals/scenario for streaming vitals and switching patient scenarios.
- The analyzer runs SCHED_FIFO at fixed priority, woken every 10 ms by a QNX pulse timer. A sliding-window QRS detector measures heart rate.
- Alarms travel as QNX pulses over priority-inheriting channels, never sockets or polling.
- An independent watchdog daemon verifies the analyzer's heartbeat every cycle and forces a fail-safe alarm on a miss.
- Worst-case wake latency is measured with ClockCycles() under a synthetic load hog and shown live on the dashboard.
Challenges I ran into
Getting truly deterministic behavior under QEMU, debugging priority inversion across the pulse channels, and tuning the QRS detector so it stays accurate at very high heart rates on 100 Hz samples. Porting a QNX 6 era timer API to QNX 8 also took some care.
Accomplishments that I'm proud of
The analyzer holds a 10 ms period with worst-case wake latency around 1.5 ms even under full CPU load, alarms raise and clear automatically as the scenario changes, and the whole system reproduces from a README on completely free tooling.
What I learned
How QNX 8.0 scheduling, pulses and resource managers fit together, and how much determinism matters for safety-relevant software like medical alarms.
What's next for VitalsGuard-RT
Multi-patient support, alarm-escalation policies per IEC 60601-1-8, and running on real ARM targets such as a Raspberry Pi 4 with QNX 8.0.
Built With
- c
- medical
- qcc
- qemu
- qnx-8.0
- qnx-neutrino-rtos
- real-time
- rtos
