Where Determinism Meets Data: Daniel Lodu and Fredrik Sande on Building the Full-Stack Medical Device Lifecycle with QNX and RaimaDB

Q1.  How does the QNX OS for Safety microkernel architecture isolate deterministic, safety-critical motor control paths — from a laparoscopic grasper’s continuous force feedback to an orthopedic bone mill’s rigid haptic boundaries — from unpredictable processing spikes caused by an active data layer?

DANIEL LODU: The control loop and the data layer never share the same space. In a well architected system built on QNX, the motor-control code runs in its own protected compartment with a guaranteed share of the processor, so a burst of database or analytics activity cannot slow it down, stall it, or corrupt it. That separation is a design property of the QNX operating system that the application team can take advantage of and does not have to engineer from scratch.

• Spatial isolation (memory). QNX is a true microkernel: applications, drivers, protocol stacks, filesystems, and the data engine each run in their own MMU-protected address space outside the kernel. A fault, memory leak, or runaway allocation in the data layer is physically contained and cannot overwrite the control loop’s memory.
• Temporal isolation (CPU time). Priority-based, preemptive real-time scheduling policies ensure the motor-control threads always preempt lower-priority data work.  Add to that core cluster configuration and the data layer can be isolated so it can never monopolize the CPU.
• Deterministic interrupt response. QNX leaves interrupts enabled and keeps worst-case interrupt and scheduling latency small and bounded, so a force-feedback or haptic-boundary event is serviced within a predictable window regardless of background load.
• Freedom from interference. These same mechanisms provide the “freedom from interference” argument that functional-safety assessors expect between mixed-criticality functions on one device.

During a complex joint replacement, the database engine must store continuous 3D tracking coordinates without introducing latency jitter into the system. How does RaimaDB structure its transactional logging so that high-frequency positional writes never lock or delay the primary control loops managed by QNX?

FREDRIK SANDE: RaimaDB is designed for the kind of continuous sensor data these systems generate: many small writes arriving rapidly, with information that needs to remain reliable and available. QNX provides the real-time execution and isolation mechanisms; RaimaDB complements that foundation by handling the data efficiently. We recommend keeping database commits separate from the motor-control deadline, so the robot can respond while its data is being recorded.

• Efficient writes. RaimaDB adds changes to the end of its storage files using copy-on-write. Those files hold both the data and the information needed for recovery, rather than relying on a conventional separate transaction log.
• Less interference between reads and writes. Snapshot reads let monitoring and analysis use a consistent view while new data continues to arrive. Update transactions still use locks, so we keep them focused and compact.
• A clear division of responsibility. The application should not make its next motor-control action wait for a database commit. QNX isolation and scheduling, configured and validated for the device, protect that timing boundary.

Q2. An endovascular surgical robot navigates delicate, tortuous vascular pathways via intravascular catheters, accumulating highly fluid telemetric datasets. How does QNX use native hypervisor or space-partitioning technologies to ensure that background tasks—like packetizing and queuing this data for the hospital cloud—never impact the active instrument navigation software? 

DANIEL LODU: Navigation and data queuing live in separated domains on the same hardware. Connectivity, cloud queuing, and rich user interfaces can run in a guest OS, while the deterministic navigation software runs in a protected QNX partition that is always given priority. One box, one software bill of materials, but the background workload can never borrow time from the surgeon’s live system interaction.

• Consolidation with separation. The QNX safety-certified Hypervisor for Safety lets a manufacturer host multiple guest operating systems alongside the deterministic QNX RTOS (Real Time Operating System) partition on a single SoC, each in a strongly separated domain.
• Guaranteed CPU for navigation. The hypervisor uses priority-based virtual-CPU scheduling. vCPUs can be pinned to dedicated physical cores for exclusive access.  The vCPU scheduling of a guest core is built upon all the real-time scheduling considerations of QNX OS. This means the navigation partition is guaranteed its processor time even when the cloud-queuing guest is at peak load.
• Controlled device sharing. Shared resources such as Ethernet and storage are exposed to guests through industry-standard VirtIO and controlled pass-through, so a background packetizer draining a network link does not create unbounded contention on the navigation path.
• Independent update and certification. Because each domain is isolated, the connectivity stack can be patched or updated without disturbing — or re-certifying — the navigation partition.

A robotic platform needs to keep clinical logs locally for post-operative audit trails while simultaneously pushing telemetry upstream for machine learning optimization. What specific replication patterns do you recommend within RaimaDB to prevent active wide-area network (WAN) synchronization from competing for bandwidth with local operating room systems?

FREDRIK SANDE: Our recommendation is to record locally first and synchronize upstream separately. A procedure should not depend on the hospital’s connection to the cloud. RaimaDB supports asynchronous replication, which fits naturally with the separation Dan describes: the device captures and stores data locally, while a separate process transfers it when the available resources and clinical workflow allow.

• Local continuity. Committed data remains on the device when the WAN is unavailable, subject to the local storage capacity and retention policy.
• Controlled transfers. RaimaDB’s replication API makes database changes available in buffers. The application’s transport layer can batch transfers, limit bandwidth, or pause synchronization during sensitive phases. Asynchronous replication alone does not reserve network capacity.
• Planned recovery. Replication progress can be tracked to support resuming transfers. The design should also account for long outages, retained history, and a replica that has fallen too far behind.

Q3. Autonomous and semi-autonomous features, such as an orthopedic robot actively restricting a bone saw to a pre-planned visual boundary, may escalate systems to IEC 62304 Class C risk levels. How does starting with a pre-certified operating system like QNX flatten the regulatory compliance curve for OEMs trying to add structural data middleware to their software stack?  

DANIEL LODU: The medical device manufacturer is ultimately responsible for the entire solution they build.  However, when the operating system, and the real time database, arrive independently pre-certified to the highest medical software safety class, the manufacturer’s certification efforts can narrow in more closely to its own applications, knowing that the pre-certified components in use are delivered already with safety and quality built in. That means they are enabled to focus on their core documentation and not on the supplied OTS software, leading to fewer unknowns in the submission, and a shorter, more predictable path to approval.  Together this gives the device manufacturer and the regulators greater confidence in the foundation of the system under review.

• Independent pre-certification. QNX OS for Safety is certified by TÜV Rheinland to IEC 62304 Class C, alongside IEC 61508 SIL 3 and ISO 26262 ASIL D from other safety critical industries.  This breadth of certification reflects the depth of safety and security engineering intrinsic to the QNX RTOS.
• FDA-ready artifacts. A complete, regularly updated Software Bill of Materials (SBOM) is provided with QNX OS for Safety which addresses an explicit FDA expectation.  The SBOM is supplied together with safety manuals, safety cases, and hazard/risk analysis information.
• A jointly pre-certified foundation. Adding “structural data middleware” no longer means qualifying it from scratch: pairing QNX with a real-time database that is itself certified to the same medical safety class means both the RTOS and the data layer come pre-certified, narrowing the scope of software the OEM must independently qualify.

When surgical robots rely on embedded databases to store safety-critical calibration maps and tool geometries, safety auditors demand strict traceability. What automated validation suites or design paradigms does Raima build into its software to make it easier for medical device manufacturers to prove data integrity to notified bodies?

FREDRIK SANDE: This is where QNX OS for Safety and RaimaDB Cert make a particularly strong combination. Both bring independently assessed components and supporting safety evidence to the manufacturer’s software foundation. For calibration maps or tool geometries, the value is not just storing the data reliably; it is giving the team a documented basis for showing how the database was developed, verified, and integrated. That helps reduce work at the database layer and keeps more attention on the device’s own safety requirements.

• Evidence that auditors can follow. RaimaDB Cert 16.1 is independently certified for integration into safety-related software up to IEC 62304 Class C. Its Safety Kit includes requirements traceability, design artifacts, certification reports, and test evidence.
• Verification on the actual platform. The package includes 100% MC/DC coverage evidence, MISRA C:2023-aligned code, and a test suite for target verification, including QNX environments.
• Support across the lifecycle. Documented assumptions of use help teams assess integration and later changes. The certified scope applies to RaimaDB Cert; the manufacturer still validates the complete device and assesses the impact of updates.

Q4.  Because newer laparoscopic and endovascular consoles can be highly networked to support remote telesurgery observation and assistance, they present a broader cyber-attack surface. If a secondary component (such as an external video stream) is breached, how do QNX’s native secure sandboxing and access control lists prevent unauthorized software from corrupting the underlying device database files?

DANIEL LODU: A compromise in one component stays in that component. QNX is built so that a breached video stream cannot reach across into the database, because every process runs in its own space with only the permissions it genuinely needs. This design contains the ‘blast radius’ through secure architecture.  And to help maintain safety and performance, a failed or compromised service may be stopped and restarted without destabilizing the rest of the device.

• Small trusted computing base. Because comparatively little code runs in privileged kernel space and every service runs in its own protected memory, the attack surface is smaller and faults are contained — a compromised component can be independently stopped and restarted.
• Least privilege and fine-grained permissions. QNX provides a detailed permission model over files, devices, and memory, so only the database process is granted write access to the database files. A breached video component simply has no permission path to those files.
• Hypervisor-level separation. If the video pipeline runs in its own guest, hypervisor isolation adds a second boundary between it and the safety/data domain.
• Secure-by-design foundation. QNX provides the architectural foundation for defense-in-depth; it complements, but does not replace, the manufacturer’s own security implementation, threat modeling, and post-market monitoring.

Standard medical compliance demands end-to-end data encryption. In an orthopedic or laparoscopic suite where sensor logs are continuously updated, how does Raima balance database cryptographic operations with the strict execution windows required to keep the physical machine responsive to the surgeon’s hands?

FREDRIK SANDE: QNX and RaimaDB contribute different layers of protection. QNX controls access to processes and resources, while RaimaDB can encrypt the stored database. To keep the device responsive, we recommend handling encrypted logging in the data workload, separately from the immediate motion-control task. The engineering team then measures performance on the actual hardware, with the intended data rate and security settings.

• Protect stored data. RaimaDB supports AES-128, AES-192, and AES-256 in packages with strong encryption support. The selected product configuration and key management must fit the device’s security requirements.
• Protect the complete data path. Database encryption is one part of the design. Network transport, access permissions, and key handling also need appropriate protection; database encryption alone is not a complete end-to-end security solution.
• Validate responsiveness. Transaction size, processor capacity, and storage performance affect encryption overhead. QNX resource isolation and scheduling help separate the workloads, while testing establishes the timing the complete device can meet.

Q5.  Modern surgical setups must seamlessly cross-reference high-frequency physical telemetry (e.g., motor strain, tool torque, catheter pressure) with structured, administrative patient profiles (e.g., HL7 or FHIR pre-op records). What is the optimal architectural bridge between QNX’s native file-system layer and RAIMA’s storage schemas to aggregate these contrasting data profiles without degrading machine performance?

DANIEL LODU: The bridge is standards-based, so two different data profiles can meet without slowing the machine. QNX supports POSIX filesystem interfaces on which RaimaDB runs as the embedded engine.  Fast-moving sensor data and slower administrative records are handled in the partitions best suited to each and joined through the database rather than in the real-time control path.

• Standard, portable interfaces. QNX support for POSIX offers safety-capable filesystem services; RaimaDB layers on top with standard SQL and REST interfaces, eliminating custom tooling and speeding integration.
• Right data in the right partition. High-frequency telemetry is ingested in the real-time domain (well suited to RaimaDB’s hybrid in-memory / on-disk design), while structured HL7/FHIR records can be handled by a connectivity or application partition with no impact on real time performance.
• Deterministic hand-off. QNX message-passing IPC provides controlled, low-latency communication between partitions, so aggregating the two data profiles does not inject jitter into sensor-to-actuation timing.

FREDRIK SANDE: The practical bridge is a data service built on RaimaDB’s APIs and a schema that connects each measurement to the right procedure and patient context. QNX supplies the underlying operating environment; RaimaDB organizes the data so applications can use it together. We would keep incoming sensor records compact, then use stable identifiers and timestamps to connect them with clinical records when needed. That makes the information useful for monitoring and review without putting complex queries into the motion-control path.

• Keep sensor capture efficient. Small, timestamped records suit the high-write workload. RaimaDB’s append-oriented storage and compact data encoding support efficient capture.
• Connect clinical context. An application adapter can validate and map HL7/FHIR data into the fields the device needs. This is an integration responsibility, rather than a claim that RaimaDB is a native HL7/FHIR server.
• Use supported access paths. Applications access the database through RaimaDB APIs, not by editing its storage files. Snapshot reads let downstream applications work with a consistent view while acquisition continues.

Q6. One of the next evolutionary leaps in medtech involves using edge AI for real-time anatomical feature tracking—such as identifying critical arteries during a laparoscopic procedure. As high-bandwidth inferencing models are pushed directly onto the hardware, how are QNX and RAIMA co-optimizing their combined software stack to feed these local AI engines with the necessary data streams without compromising system safety or adding mechanical lag?

DANIEL LODU: AI perception and the safety-critical real-time control loop can run on the same device without competing. QNX gives the AI workload its own isolated, budgeted partition so inference can be added and updated without destabilizing the required underlying determinism, while RaimaDB feeds the model with local data at low latency. Innovation goes into the AI partition; safety stays protected in the real-time domain.

• Isolated, budgeted inference. Inference can run in its own partition (or hypervisor guest) with a guaranteed CPU budget, so a heavy model cannot starve the control loop which preserves deterministic behavior and the safety case.
• Low-latency local data feed. RaimaDB’s high-throughput, low-latency ingestion supplies the local data streams the edge model consumes, keeping the AI pipeline fed without pulling data through the real-time control path.

FREDRIK SANDE: RaimaDB’s role is to make local data useful to the AI application: structured sensor observations, recent history, model metadata, and recorded inference results. QNX provides the mechanisms to isolate and schedule the AI workload alongside the rest of the system. Together, this gives manufacturers an architecture for adding local intelligence while preserving a clear boundary around safety-critical control. The stored history can also support investigation and evaluation as the device evolves.

• Make relevant context available. Snapshot reads allow preprocessing or inference to use a consistent view of recorded data while acquisition continues.
• Choose the right path for each stream. Raw video may be better served by a direct path to the inference engine, with RaimaDB retaining the associated structured data and results. The recommendation is architectural; it does not depend on a proprietary joint AI interface.
• Keep safety decisions explicit. If an AI result can influence motion or treatment, it must pass through the manufacturer’s validated safety architecture. Model updates and changes to the data pipeline also need their impact assessed.

………………………………………………………………………………………………………………………………………………………….

Fredrik Sande is Marketing Manager at Raima, with 10 years of experience in the database industry and 15 years in the technology sector. His background spans marketing, business development, and entrepreneurship. At Raima, he focuses on helping companies understand how embedded database technology supports reliable, high-performance products and addresses practical business needs.

Sponsored by Raima.