Tracing tool tracks hidden delays in mixed autonomous-driving software stacks

Autonomous vehicles are often described as computers on wheels, but the phrase understates just how tangled the software inside them has become. A single self-driving stack must ingest torrents of LiDAR point clouds, camera frames and radar returns, fuse them into a coherent model of the road, decide what the vehicle should do next, and translate that decision into steering, braking and acceleration commands — all within deadlines measured in milliseconds. What makes this genuinely difficult is that the software rarely lives on one platform. In industry, the AUTOSAR Adaptive Platform (AUTOSAR AP) has become a de facto standard for production automotive computing, while the open-source Robot Operating System 2 (ROS 2) dominates research laboratories and early-stage prototyping thanks to its vast ecosystem of tools and libraries. As vehicles evolve into software-defined machines, developers increasingly want the best of both worlds, combining AUTOSAR AP’s rigor with ROS 2’s agility inside the same system.

That combination, however, creates a blind spot. When data flows from a ROS 2 node into an AUTOSAR AP application and back again, each platform keeps its own records of what happened. ROS 2 offers tracing hooks that capture communication events, while AUTOSAR AP applications typically rely on ara::log, the platform’s standardized logging facility, which was never designed to serve as a precision timing instrument. Stitching these two heterogeneous record streams into a single, coherent picture of end-to-end latency has been a stubborn engineering problem. Developers prototyping a new perception or planning module can easily discover that something feels slow without being able to say whether the delay arose in sensor reception, in cross-platform message translation, in the detection algorithm itself, or in the final command output.

A research team led by Professor Takuya Azumi of the Graduate School of Science and Engineering at Saitama University, working with Astemo, Ltd., has now pushed a solution to that problem much closer to practical reality. The team had previously developed CART, the Combined AUTOSAR AP and ROS 2 Tracing Framework, which integrates trace information from both platforms into a unified timeline. But the original evaluation of CART was confined to a small-scale application configuration, leaving open a question that matters enormously to anyone building real vehicles: would the framework still deliver useful end-to-end latency analysis when confronted with the component count, data volume and complexity of a genuine autonomous-driving stack? The answer, published on August 6, 2026 in the IEEE Open Journal of the Industrial Electronics Society under the title “Evaluation Platform for Tracing of Autonomous Driving System Combined AUTOSAR AP and ROS 2” (DOI: 10.1109/OJIES.2026.3721135), is a carefully qualified yes.

To reach that answer, the researchers built a cloud-based evaluation platform that assembles four major pieces of software into one instrumented pipeline. The high-fidelity CARLA simulator generates realistic LiDAR point-cloud data for a simulated vehicle. Those point clouds flow into Autoware, the well-known open-source autonomous-driving software stack built on ROS 2, which handles the higher-level driving logic. From Autoware, sensor data pass across the platform boundary into an AUTOSAR AP application responsible for object detection, with detection results routed back to Autoware through protocol bridges so that vehicle-control commands can be generated. CART sits alongside this entire chain, ingesting ROS 2 traces and AUTOSAR AP logs and reconstructing the processing path from the moment simulated sensor data are received to the moment a control command emerges at the other end.

The results of the evaluation speak to both the completeness and the realism of the setup. CART reconstructed the entire expected end-to-end communication topology with 100 percent coverage, meaning that no segment of the processing path across the ROS 2–AUTOSAR AP boundary was lost to the tracing process. Under the evaluated workload, the platform sustained a point-cloud reception callback rate of approximately 33 Hz, a figure that reflects the kind of continuous, high-frequency sensor processing real autonomous-driving software must handle. Crucially, all of this was achieved with low tracing overhead, so the act of measurement did not materially distort the behavior being measured — a perennial hazard in performance analysis.

The framework also demonstrated an ability that fixed communication diagrams cannot provide: following dynamic control behavior. In the evaluated scenarios, CART distinguished between processing paths in which object detection triggered a stop command and paths in which no actuation command was issued at all. That distinction matters because autonomous-driving logic is not a static pipeline; it branches depending on what the sensors perceive. A tracing tool that can only follow fixed routes would miss precisely the situations developers care most about — the moments when the vehicle’s software decides to change what it is doing. By capturing those transitions, CART showed it can trace changes in control logic as well as ordinary data flow.

Overhead, the quiet killer of any tracing scheme, was quantified in two separate tests. In a small-scale test, adding ara::log-based instrumentation introduced little CPU load and roughly 0.03 MiB of memory usage, numbers small enough to be negligible for most development purposes. In a separate offline benchmark, converting logs representing one million send/receive pairs into trace data took approximately one second, suggesting that the framework can scale to the volume of logging that a full autonomous-driving stack generates without becoming an analysis bottleneck in itself. The authors assessed the platform at Technology Readiness Level 6, based on its demonstration in a relevant simulation environment, while noting that validation on real hardware remains future work.

“This study is important because autonomous-driving software is becoming increasingly complex, with different software platforms working together within the same system,” said Shunsuke Ito, a master’s student at Saitama University’s Graduate School of Science and Engineering and the corresponding author of the study. “By integrating trace information from AUTOSAR AP and ROS 2, our platform makes it possible to follow the processing path from sensor input to the generation of a control command as a single end-to-end sequence. This allows developers to see more clearly where latency occurs across platform boundaries.” The point is not merely academic. Latency budgets in autonomous driving are unforgiving: a perception-to-control chain that overshoots its deadline can degrade the freshness of the vehicle’s world model, and the difference between a safe response and a dangerous one can hinge on tens of milliseconds.

Ito emphasized that the leap from small test applications to realistic workloads was the heart of the contribution. “It is not enough to confirm that a tracing method works with a small test application,” he explained. “Autonomous-driving systems process large amounts of sensor data through many interconnected software components. By combining CARLA, Autoware, AUTOSAR AP, and ROS 2 in a cloud environment, we were able to test CART under more realistic conditions and show that detailed latency analysis remains possible without imposing a large additional processing burden.” For engineering teams practicing rapid prototyping, that means performance bottlenecks can now be identified during the design-and-test cycle, before software is transferred to physical vehicle hardware — when fixes are cheapest and iteration is fastest.

The implications extend to the broader industry shift toward Software-Defined Vehicles, in which functionality is increasingly delivered and updated through software rather than hardware. By providing a unified view of processing across heterogeneous platforms, unified tracing could shorten development and validation cycles and make complex vehicle software systematically evaluable. The team is candid about the road ahead: practical deployment will require validation with real electronic control units or hardware-in-the-loop systems, clock synchronization across multiple computing systems, larger-scale testing, and further automation of cross-platform message correlation. Looking forward, the researchers plan to extend the platform to lighter-weight simulation environments, incorporate OpenSCENARIO-based systematic testing, automate message linking using standard SOME/IP identifiers, and ultimately evaluate CART on real hardware. “If developers can trace the behavior of those systems across different platforms and identify performance problems earlier, they may be able to shorten development and validation cycles while making complex vehicle software easier to evaluate systematically,” Ito said. “In the future, we hope to extend CART from cloud-based simulation to real ECUs and further automate the tracing process. If these capabilities can be incorporated into practical vehicle-development workflows, unified tracing could become a useful tool for developing autonomous-driving and software-defined vehicle functions more efficiently and reliably.”

Subject of Research: End-to-end latency tracing across mixed ROS 2 and AUTOSAR AP autonomous-driving software platforms

Article Title: New tracing platform pinpoints delays across complex autonomous-driving software

Article References: New tracing platform pinpoints delays across complex autonomous-driving software. (n.d.). Original publication

Image Credits: AI Generated

DOI: Not provided

Keywords: autonomous driving, CART, AUTOSAR AP, ROS 2, Autoware, CARLA simulator, latency tracing, software-defined vehicles, Saitama University, ara::log, cloud evaluation platform, IEEE Open Journal of the Industrial Electronics Society