Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18–20, 2026.
For the ELISA Project community, the event was an important opportunity to continue the conversation around safety-critical software, open source safety standards, regulatory compliance, requirements traceability, verification, software supply chains, and safety engineering.
The Safety-Critical Software Track highlighted practical work across several domains, including aerospace, embedded systems, medical devices, robotics, avionics, automotive, and industrial systems. Sessions explored how open source communities are addressing the technical, process, and compliance needs of safety-critical systems.
Over the next few weeks, we will highlight selected session recordings from the track and share key takeaways with the community.
This week, we highlight “Standardizing Deterministic Interoperability and Resource-Intelligent Design in Medical Robotics,” presented by Lilinoe Harbottle, San Jose State University.
The Challenge of Closed Medical Robotics Platforms
Medical robots support surgeons by translating software instructions into precise physical actions. This makes the point where software crosses into real-world movement an important part of the safety pipeline.
Lilinoe explained that many medical robotics systems are built as vertically integrated, proprietary platforms. Their safety logic is often tightly coupled to closed hardware, firmware, sensing, and control systems. This can increase costs, limit interoperability, and make it difficult to replace components or adapt systems to different clinical environments.
These limitations can also affect access to medical technology. Rural communities and resource-constrained regions may be unable to deploy or maintain expensive, vendor-locked platforms, contributing to what Lilinoe described as medical deserts.
The session explored how an open and auditable architecture could help separate safety verification from proprietary hardware and support more accessible medical robotics.
Introducing the Prism Framework
Lilinoe introduced Prism, an architectural framework designed to decouple high-precision kinematic verification from the underlying hardware binaries. The framework shifts part of the safety burden from non-transparent firmware into open, auditable user-space software logic.
Rather than relying only on the robot’s internal controller and sensor feedback, Prism introduces an independent software layer that verifies the physical state of the system.
The aim is to support deterministic interoperability while allowing hardware components to remain modular and vendor-neutral.
Separating the Actor and the Auditor
A key idea in the presentation was the separation between the system performing an action and the system verifying it.
Lilinoe compared this model to multi-factor authentication. The robot controller acts, while an independent observer checks that the physical result matches the expected state.
In a tightly integrated control loop, the target command, actuators, encoders, and positional feedback may all depend on the same system. If encoder drift, mechanical lag, a calculation error, or another failure occurs, the controller may continue to report success because it is effectively evaluating its own output.
Prism introduces an independent observer through a decoupled telemetry path.
Raw sensor data is sent directly to a kinematic twin engine in the middleware layer. This engine performs its own verification rather than depending entirely on the position reported by the main controller.
Deterministic Kinematic Verification
The observer uses coordinate-frame mapping, forward kinematics, matrices, and mathematical verification to evaluate the robot’s physical state. The framework compares the expected position with the measured physical position.
For example, the robot controller may report that an instrument is following the planned path, while the observer detects that the instrument has drifted by several millimeters.
When this occurs, the observer can flag the discrepancy before the robot continues moving.
Lilinoe described this as trusting the downstream gate rather than attempting to control every upstream subsystem perfectly.
A medical robot may include imaging systems, user interfaces, telemetry, localization, controllers, actuators, and encoders. Network jitter, sensor drift, mechanical lag, and software faults can occur across these layers.
The independent observer provides a separate point of validation for the final physical state.
Resource-Intelligent Design
The session also explored how the observer can remain available when the main controller is under heavy load or experiences a failure.
Lilinoe described placing the independent observer process on an isolated CPU core.
This provides resource isolation between the safety observer and the primary control loop. If the proprietary controller experiences a CPU spike, deadlock, or unhandled exception, the observer can continue operating independently.
This approach reflects the resource-intelligent design described in the session. Instead of depending only on expensive hardware to improve precision, the architecture uses software isolation and independent verification to support the safety function.
Safety-Operated Envelopes
The independent observer can also enforce a software-operated safety envelope. When the observer detects physical drift, an unsafe command, or another condition outside the permitted threshold, it changes the system from an active state to a non-active state.
Lilinoe described this as a circuit breaker. A multiprocessing event flag can intercept the coordinate stream, reduce actuator velocities to zero, and force the robot into a halt state.
In the example presented, the response occurred in less than one millisecond.
The purpose is to prevent the robot from continuing to move when the verified physical state no longer matches the expected safe state.
Using Telemetry as a Safety Record
The presentation also examined how telemetry can support accountability and validation.
Rather than treating telemetry as unused data, the framework uses it to create an auditable record of physical movement. For each movement, the middleware can capture the raw vector state, hardware identifier, and clock synchronization information. This data can be combined into a signed packet that records what the system detected during the movement.
Lilinoe described this as a safety receipt.
These records can support debugging, post-event analysis, reproducible research, and clinical validation. They also provide a transparent record of how the robot behaved and how the safety system responded.
Supporting Vendor-Neutral Medical Robotics
Separating the safety layer from a specific hardware platform can allow components to be replaced or updated without rebuilding the entire architecture. This can reduce dependence on a single vendor or hardware generation and may extend the useful life of medical equipment.
Lilinoe explained that vendor-neutral middleware could also lower barriers for local manufacturing and regional engineering teams. Open or modular components could connect to an established safety architecture with auditable verification and validation mechanisms.
The broader goal is to move from closed, vertically integrated platforms toward an open ecosystem built around architectural transparency, interoperability, and hardware autonomy.
A More Accessible and Sustainable Model
The session presented open source software as a way to support hardware independence in medical robotics.
By combining deterministic kinematic verification, an independent observer, isolated processing resources, safety-operated envelopes, and auditable telemetry, the Prism framework aims to make medical robotics more transparent and adaptable.
Lilinoe emphasized that this work involves several fields, including robotics, software architecture, applied mathematics, control systems, hardware engineering, clinical validation, and safety analysis.
The session outlined a research direction for reducing vendor lock-in, supporting longer system lifecycles, enabling reproducible research, and lowering barriers to the development and deployment of medical robotics.
Watch the session recording here.
Stay tuned for more Safety-Critical Software Track session highlights from Open Source Summit North America 2026. Check the playlist here.