Inspiration
Industrial networks need local detection that keeps working under load, outages, and UI failures. SentinelRT was inspired by that requirement and by QNX’s strengths: real-time execution, process isolation, and fault containment.
## What it does
SentinelRT replays real X-IIoTID traffic as a live event stream, classifies each record locally, and logs the result for operators in real time. It provides a compact dashboard for current state, recent events, and assistant-driven incident summaries. The architecture is split so the detector can keep running even if the viewer is restarted.
## How we built it
We built SentinelRT as a QNX-oriented C++17 system using portable POSIX components. The core runtime handles dataset replay, local model inference, event logging, and service state tracking. A separate viewer reads the log stream and serves the operator UI. We also added a Gemini-backed assistant path for incident explanation and summarization.
## Challenges we ran into
The biggest challenges were making the project QNX-friendly, keeping the UI minimal without losing useful operational detail, and separating the detection path from the display path so the demo could prove fault isolation. Another challenge was making the data flow believable for a hackathon demo while still staying true to the real dataset.
## Accomplishments that we're proud of
We got a real QNX-style split working between a headless daemon and a separate viewer. The system can continue detection when the interface is killed and restored. We also built a live timeline, service controls, JSONL logging, and operator assistant responses that turn raw detections into readable incident reports.
## What we learned
We learned that the strongest embedded AI demo is not just “running ML on a device.” It is showing the system behavior around the ML: isolation, restartability, deterministic updates, and clear operator feedback. We also learned that a good QNX demo should emphasize architecture, not just prediction accuracy.
## What's next for SentinelRT
Next we would make the QNX service split even more explicit with separate processes for capture, inference, logging, and viewing. We would replace the current baseline model with a more production-like deployable model path, and add stronger IPC between services. We would also finish tightening the Gemini assistant so it produces polished incident reports directly from the log window.
Log in or sign up for Devpost to join the conversation.