- The paper reveals that AUTOSAR Adaptive Platform meets 23 of 33 industry requirements, while ROS 2 meets only 13, underscoring significant gaps in deployment readiness.
- The methodology involves eliciting 33 non-functional automotive middleware requirements from industry experts and conducting a comparative analysis of system capabilities.
- Implications indicate AUTOSAR AP is more aligned with safety-critical, series-production needs, whereas ROS 2 excels in rapid prototyping but lacks robust real-time and deterministic features.
Introduction
This paper presents a rigorous assessment of automotive middleware requirements as elicited from experienced software architects at ZF Group, addressing the gap between academic research and industry practice. It provides both a catalogue of practitioner-defined requirements, and a comparative analysis of two prominent middleware platforms: ROS 2 (Jazzy) and AUTOSAR Adaptive Platform (R24-11), with the aim of clarifying their alignment to industrial priorities. The context is software-defined vehicles and modern E/E architectures, where middleware is critical for abstraction, interoperability, and safety.
Industry-Elicited Requirements
Thirty-three non-functional requirements were identified, grouped into nine categories: communication, data modeling, scheduling, data queues, parameterization, error handling, functional safety, operating modes, allocation, and watchdog supervision. Notable requirements include strong support for explicit C/C++-style runnable initialization, event-driven or periodic execution, robust data validation and typing, fault management, modular error handling, parameter persistence, ASIL-related safety reactions, operational mode handling, fine-grained stack allocation, and real-time supervision.
Requirements reflect both practical needs and established engineering models: explicit lifecycle management, deterministic scheduling, run-time introspection, persistent parameter handling, and various supervision types for error maturation and logical/temporal dependencies.
Comparative Analysis: AUTOSAR AP vs. ROS 2
AUTOSAR AP demonstrates broad coverage, fully meeting 23 requirements and partially fulfilling one. It excels in data typing, service-oriented communication, and reliable execution management. The platform’s modular functional clusters (e.g., EM, PHM, DM) deliver dedicated services for diagnostics, error handling, functional safety, and watchdog supervision. Stack allocation, core affinity, and operational modes are natively supported, aligning with deployment requirements for safety-critical series production.
However, some advanced scheduling requirements (e.g., cyclic runnable priority, execution offsets) are not natively supported and must be implemented via application logic or through OSI integration. Execution determinism is an area of limitation: deterministic scheduling is not fully realized, though extensions (SL LET Timing) and recent proposals [9116430, BELLASSAI2025103390] seek to address this. Communication and execution remain non-deterministic by default, but AUTOSAR AP’s structure provides a foundation for future deterministic integration.
ROS 2
ROS 2 fulfills 13 requirements, partially supports one, and fails to meet 19. It is strong in communication, data typology (via DDS/IDL), and event-driven execution via executor models. Run-time diagnostics, buffered access, timer-triggered callbacks, and service/method interfaces are well-supported. However, it lacks robust deployment-oriented features required for automotive series production: operation modes, persistent parameterization, supervision (alive/deadline/logical), stack and core allocation, and centralized error/fault management are not present. There is no central mechanism for safety reactions (e.g., SWC degradation/inhibition), nor deterministic control of scheduling and execution.
While industrial forks such as Apex.AI improve ROS 2’s applicability, the base package is aligned with prototyping and rapid development, not safety-critical deployment. Real-time capability remains limited [teper_timing-aware_2023, casini_response-time_2019], and requirements for deterministic, analyzable execution are largely unfulfilled. ROS 2’s scheduling and supervision gaps are particularly evident compared to AUTOSAR AP.
Implications for Middleware Architecture
The findings reveal distinct tradeoffs: ROS 2 prioritizes flexibility and fast integration, which is advantageous for research and prototyping but insufficient for automotive series deployments where modular safety, deterministic supervision, and persistent diagnostic capabilities are mandatory. AUTOSAR AP is structured for compliance, safety, and production robustness, but lacks fine-grained scheduling facilities and deterministic guarantees without extensions.
From a theoretical perspective, the limited coverage of scheduling requirements highlights an unresolved challenge in the design of automotive middleware. Future research should focus on extending middleware platforms with formally analyzable, deterministic execution, potentially leveraging SL LET Timing and hybrid scheduling integrations. Practically, the industry demands integrated support for diagnosis, failover, and supervision, necessitating closer alignment of middleware development with operational demands and functional safety standards.
Numerical Results and Contradictory Claims
AUTOSAR AP meets 23 of 33 requirements; ROS 2 meets only 13. The scheduling category displays the largest gap, with neither platform fully supporting cyclic priorities, offsets, and preemptive/non-preemptive scheduling. The paper claims that AUTOSAR AP’s deterministic client was omitted in recent releases, contradicting earlier claims about determinism in AUTOSAR AP. It also emphasizes that industrial middleware requirements diverge considerably from academic focus areas, especially regarding maintainability, integration, and safety supervision.
Speculation on Future AI Developments
The migration to zone-based E/E architectures and software-defined vehicles will increase middleware complexity and demand new abstractions for distributed, mixed-criticality execution environments. Machine learning will drive additional requirements for resource control, real-time guarantees, and dynamic adaptation, necessitating further evolution of middleware standards. Research into deterministic, formally verified scheduling will be critical, as will integration of AI-powered diagnostics and error prediction. Middleware platforms must evolve to support continuous deployment, OTA updates, and resilient supervisory features with hard real-time guarantees.
Conclusion
This paper provides a structured empirical basis for the evaluation of automotive middleware, contrasting ROS 2 and AUTOSAR AP against industry-defined requirements. AUTOSAR AP aligns with series-production needs but requires scheduling extensions; ROS 2 provides flexible prototyping but lacks deployment-oriented robustness. The gap in deterministic execution and supervision highlights a critical research and development area. Broader, multi-company studies are recommended to enhance the generalizability of these findings and guide the evolution of future automotive middleware platforms.
(2604.22576)
