Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cerulion.com/llms.txt

Use this file to discover all available pages before exploring further.

Your autonomous vehicle makes an unexpected lane change. You pull the logs. The replay produces different results. In a non-deterministic runtime, replaying production logs gives you a different execution order, different timing, different outputs. You’re not debugging the incident — you’re debugging a different run that happened to use the same inputs. For safety-critical applications, this isn’t an inconvenience. It’s disqualifying. Same inputs. Same outputs. Provably.

​
Why ROS2 Is Non-Deterministic

ROS2’s execution model introduces non-determinism at multiple levels: Even with identical inputs, ROS2 produces different execution sequences because the runtime doesn’t control scheduling.

OS thread scheduling

ROS2 executors dispatch callbacks across threads managed by the OS. The OS scheduler decides which thread runs next based on system load, other processes, and CPU availability. Two runs of the same graph on the same machine can produce different callback orders.
When multiple messages arrive at similar times, the order in which their callbacks fire depends on thread scheduling. A sensor fusion node that receives camera and LiDAR data may process them in different orders on different runs — producing different fusion results.
ROS2’s wall-clock timers drift under CPU load. A 33 ms periodic timer may fire at 31 ms or 36 ms depending on what else is running. This changes the input data available when nodes execute.

​
How Cerulion Achieves Determinism

Cerulion controls three things that ROS2 leaves to chance:

Deterministic scheduling

The scheduler evaluates triggers based on graph topology and input data, not OS thread scheduling. Given the same inputs, nodes always execute in the same order.

Zero-copy logging

Zero-copy logging captures the exact input sequence without perturbing the system. Recording doesn’t change timing, so logs faithfully represent what happened.

Controlled replay

During resim, the scheduler replays the logged input sequence through the same graph. Because scheduling is deterministic, the same inputs produce the same execution order and the same outputs.

​
Deterministic vs Non-Deterministic Execution

Consider a sensor fusion node that combines camera and LiDAR data: A 2 ms difference in arrival time can cause the fusion node to pair the wrong camera frame with the wrong LiDAR scan — and this pairing changes on every run. Cerulion’s synchronized triggers guarantee consistent pairing.

​
What This Means for Safety

Deterministic resim is the foundation of safety validation. When you can replay a production incident and get the exact same behavior, you can: identify the root cause with certainty, verify that your fix actually prevents the incident, and build regression tests from real-world failures.
Without determinism, each of these becomes probabilistic:
CapabilityNon-Deterministic (ROS2)Deterministic (Cerulion)
🔍 Root cause analysisReplay may show different behaviorReplay reproduces the exact incident
✅ Fix verification”It didn’t happen again” ≠ “it’s fixed”Same inputs, same fix → verified
🧪 Regression testingFlaky — different results on each runReliable — deterministic by construction
📋 Safety certificationCan’t prove reproducibilityDemonstrate identical replay to auditors
Safety teams can’t certify a system whose behavior they can’t reproduce. Non-deterministic middleware is a blocker for safety certification in autonomous systems.
Ready to try Cerulion? Start with the quickstart and have a working camera-to-display pipeline in 5 minutes — or schedule a 15-min call with the team.