VxWorks A-Stack: A Deterministic Real-Time Alternative to ROS
The gap between simulation and physical deployment remains one of the most difficult challenges in robotics and autonomous vehicle development. At the Simulation-Based Engineering Lab (SBEL) at the University of Wisconsin–Madison, the ART autonomous scale vehicle provides a practical platform for studying this problem.
The ART platform traditionally relies on ROS for inter-node communication. ROS offers excellent modularity and rapid prototyping capabilities, but conventional event-driven middleware does not inherently provide the hard real-time guarantees required by safety-critical control loops.
To investigate a more deterministic approach, the lab has begun evaluating VxWorks, Wind River’s real-time operating system used across demanding embedded and aerospace applications. The resulting proof of concept, known as the A-Stack, is a lightweight, time-driven architecture designed to evaluate determinism, performance, and suitability for ART-class autonomous vehicles.
⚙️ Why Explore VxWorks Beyond ROS? #
ROS has become a dominant framework for robotics because it makes it easy to connect sensors, controllers, simulators, and other software components. Its event-driven communication model is particularly useful during research and rapid prototyping.
However, sim-to-real experimentation introduces another requirement: predictable timing.
The same control software may need to operate in several environments:
- Physical vehicles with real sensors and actuators
- High-fidelity physics simulations
- Simulations running slower than real time
- Accelerated simulations running faster than real time
In these scenarios, deterministic execution becomes important. A control algorithm should execute according to a known schedule rather than simply reacting whenever data arrives.
VxWorks provides a natural platform for evaluating this approach because its architecture emphasizes deterministic scheduling, bounded latency, and predictable resource usage.
The A-Stack therefore asks a straightforward engineering question: Can a lightweight VxWorks-based architecture provide the timing predictability required for autonomous control without sacrificing practical development and deployment?
🧩 A Minimal Time-Driven Architecture #
The initial A-Stack consists of three primary worker tasks and a supervisory manager:
- IMU Loader — Periodically samples inertial measurement data.
- GPS Loader — Periodically samples positioning data.
- Control — Combines the most recent sensor measurements, executes the control algorithm, and generates actuator commands.
- Manager / Steward — Starts the workers and monitors their execution timing.
Each worker operates according to its own period. The IMU, GPS, and control tasks therefore have independent timing parameters such as t₁, t₂, and t₃.
Rather than triggering the control loop whenever a sensor event occurs, the architecture remains strictly time-driven.
Sensor tasks place their latest measurements into message queues. When the control task begins its next execution period, it consumes the newest available information.
This approach avoids some of the cascading latency that can occur in event-driven processing pipelines.
Supporting Multiple Simulation Modes #
The A-Stack is designed around three operating environments:
- L0 — Real hardware with physical sensors and actuators.
- L1 — Simulation operating slower than real time.
- L2 — Accelerated simulation operating faster than real time.
Task periods can be scaled according to the selected environment while preserving the fundamental scheduling model.
Each task must complete its work within a predefined time capsule. If execution exceeds the permitted interval, the system detects the violation.
In the current proof of concept, a missed capsule causes the system to abort. Future versions are intended to introduce a dedicated recovery mechanism.
⏱️ Design Choices for Deterministic Execution #
The A-Stack deliberately makes several architectural choices that differ from a conventional ROS node graph.
Real-Time Processes Instead of Kernel Modules #
The A-Stack runs as a VxWorks Real-Time Process (RTP) rather than directly as a kernel module.
This provides memory protection and a cleaner boundary between application code and the operating system. A failure within the application can therefore be isolated more effectively than if the entire application were executing inside kernel space.
Although an RTP can introduce some overhead compared with kernel-level execution, the additional protection and recoverability are valuable for the current research platform.
Message Queues for Task Communication #
Message queues provide the primary mechanism for communication between the worker tasks.
They offer:
- Built-in synchronization
- Multiple-producer and multiple-consumer support
- Controlled data exchange
- Reduced reliance on manually protected shared memory
- A simpler model for reasoning about task interactions
The control task does not need to wait for a new sensor event. Instead, it retrieves the most recent available measurement when its scheduled execution begins.
A Steward Task for Deadline Monitoring #
Rather than using a semaphore-driven deadline architecture, each worker records its start and completion timestamps and reports them to a dedicated Steward task.
The Steward compares the measured execution time against the worker’s permitted time capsule.
A separate timeout prevents the Steward from becoming stuck while waiting for worker information.
This design keeps deadline monitoring explicit and centralized, making timing behavior easier to observe during experimentation.
Explicit Period Management #
VxWorks does not provide a single built-in abstraction that directly represents every periodic-task requirement of this architecture.
The A-Stack therefore uses a lightweight manager to enforce task periods.
The manager sleeps for the required interval and then resumes the appropriate worker. After completing its work and reporting timing information, the worker suspends itself until the manager releases it again.
This external timing mechanism ensures that task activation follows a predictable schedule.
💻 VxWorks Deployment Architecture #
The current A-Stack target is an Intel NUC running a customized VxWorks image.
The software stack follows the conventional VxWorks development hierarchy:
VxWorks Source Build #
The VSB (VxWorks Source Build) contains the kernel libraries and Board Support Package configuration.
The current platform uses an itl_generic / Alder Lake BSP configuration suitable for the Intel NUC hardware.
VxWorks Image Project #
The VIP (VxWorks Image Project) creates the operating-system image.
The configured image includes the components required by the A-Stack, including:
- RTP support
- Console services
- Standalone shell functionality
- Hardware-specific platform support
A-Stack RTP Application #
The A-Stack itself is built as an RTP application.
The application can be packaged into a ROMFS image, simplifying deployment alongside the VxWorks system image.
UEFI Boot #
The NUC uses a UEFI bootloader, with BOOTX64.EFI providing the entry point for booting the VxWorks environment from USB media.
Once VxWorks has started, the A-Stack can be launched from the target shell with:
rtpSp
This provides a relatively simple deployment workflow while keeping the application separated from the underlying kernel image.
🔬 Measuring the Sim-to-Real Gap #
One of the most important aspects of the A-Stack is that timing becomes an explicit experimental variable.
A conventional event-driven architecture can make it difficult to distinguish algorithmic behavior from scheduling and communication delays. The time-driven A-Stack instead defines when each component should execute and establishes a measurable execution budget.
This makes it possible to investigate:
- Task execution latency
- Scheduling jitter
- Sensor-to-controller delay
- Control-loop execution time
- CPU utilization
- Deadline violations
- Differences between physical and simulated execution
- Behavior under accelerated simulation
The same control architecture can therefore be evaluated under L0, L1, and L2 conditions while retaining the same fundamental timing model.
🚀 Future Development #
The current A-Stack is intentionally minimal and should be viewed as a proof of concept rather than a complete autonomous-vehicle software platform.
Future development can expand the architecture in several directions.
Deadline Recovery #
The current response to a missed time capsule is a system abort. A production-oriented implementation could instead introduce controlled recovery mechanisms.
Potential strategies include restarting failed tasks, entering a degraded control mode, switching to backup controllers, or notifying a higher-level safety manager.
Expanded Sensor and Actuator Support #
Additional interfaces can be introduced for:
- Cameras
- LiDAR
- Wheel encoders
- Motor controllers
- Vehicle-state estimators
- Additional navigation sensors
The challenge will be integrating these data sources without compromising the deterministic scheduling model.
Quantitative Performance Analysis #
Future experiments can provide more detailed measurements of:
- Worst-case execution time
- Average and maximum latency
- Scheduling jitter
- CPU utilization
- Queue latency
- Sensor-to-actuator delay
- Deadline-miss frequency
Such measurements would help establish when a deterministic RTOS architecture provides a meaningful advantage over conventional middleware.
Integration with Existing Robotics Ecosystems #
The long-term objective does not necessarily require replacing ROS entirely.
Instead, the A-Stack can serve as a hard real-time foundation underneath higher-level robotics software. Non-critical functions could remain within a conventional robotics framework while safety-critical control loops execute within deterministic VxWorks tasks.
This type of partitioned architecture could preserve the productivity benefits of modern robotics middleware while providing stronger timing guarantees where they matter most.
🎯 Conclusion #
The VxWorks A-Stack represents an interesting approach to studying deterministic software architectures for autonomous vehicles and robotics.
Rather than treating computation as a collection of asynchronous events, the architecture makes time a first-class design constraint. Periodic sensor acquisition, control execution, deadline monitoring, and task management are all organized around explicit timing requirements.
Its use of VxWorks RTPs, message queues, a dedicated Steward task, and explicit period management provides a compact foundation for investigating deterministic sim-to-real execution.
The project is still in its early stages, but it establishes a useful experimental framework. By running the same control architecture against physical hardware, slower-than-real-time simulation, and accelerated simulation, researchers can measure exactly how timing behavior changes across environments.
The ultimate goal is not necessarily to replace ROS, but to determine where hard real-time guarantees are genuinely necessary and how those guarantees can coexist with the flexible robotics ecosystems engineers already use.
For autonomous systems where timing, repeatability, and predictable execution are critical, the A-Stack provides a promising foundation for exploring what a deterministic robotics software stack can look like.