pith. sign in

arxiv: 2604.22576 · v1 · submitted 2026-04-24 · 💻 cs.SE

A Comparison of ROS 2 and AUTOSAR Adaptive Platform Against Industry-Elicited Automotive Middleware Requirements

Lucas Hegerath , David Philipp Kl\"uner , Philipp Pelcz , Viswanatha Reddy Batchu , Marius Molz , Julius Kahle , Thomas Schulik , Stefan Kowalewski
show 1 more author
Alexandru Kampmann
This is my paper

Pith reviewed 2026-05-08 11:20 UTC · model grok-4.3

classification 💻 cs.SE
keywords ROS 2AUTOSAR Adaptiveautomotive middlewaresoftware-defined vehiclesrequirements elicitationmiddleware comparisonindustrial requirements
0
0 comments X

The pith

Requirements from ZF engineers reveal specific gaps in both ROS 2 Jazzy and AUTOSAR Adaptive Platform for automotive middleware

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper compares ROS 2 Jazzy and AUTOSAR Adaptive Platform R24-11 against a list of requirements collected directly from software engineers at ZF Group. It evaluates how well each framework supports communication, integration, and coordination of software components in software-defined vehicles. A reader would care because automotive systems demand reliable middleware that meets real industrial priorities, and such direct industry input is uncommon in published evaluations. The work aims to clarify where each platform succeeds or falls short so that developers can set better priorities when choosing or improving middleware.

Core claim

Eliciting practical requirements from automotive software engineers at ZF Group and applying those requirements as an evaluation benchmark shows how ROS 2 Jazzy and AUTOSAR Adaptive Platform R24-11 each meet or miss the needs of software-defined vehicle development.

What carries the argument

The ZF-elicited requirements list, which functions as the shared benchmark for scoring the two middleware frameworks on automotive suitability.

If this is right

  • Automotive teams can use the identified gaps to decide between ROS 2 and AUTOSAR or to request targeted extensions from either platform.
  • Middleware developers receive concrete feedback on which features matter most in vehicle contexts.
  • The elicitation method itself can be reused to evaluate future middleware versions or additional frameworks.
  • Priorities for safety-critical communication and integration become clearer for the automotive software community.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same requirement set could be applied to measure real-time performance or security properties not explicitly listed by the ZF engineers.
  • Repeating the exercise with data from multiple suppliers would test whether the ZF list generalizes.
  • Vehicle manufacturers might run controlled integration tests based on the unmet requirements to confirm practical impact.

Load-bearing premise

The requirements gathered from ZF Group engineers stand in for the wider automotive industry and the scoring method treats both frameworks without favoring one over the other.

What would settle it

A follow-up study that collects requirements from engineers at additional major suppliers and produces a materially different priority list or shows one framework satisfying every criterion.

Figures

Figures reproduced from arXiv: 2604.22576 by Alexandru Kampmann, David Philipp Kl\"uner, Julius Kahle, Lucas Hegerath, Marius Molz, Philipp Pelcz, Stefan Kowalewski, Thomas Schulik, Viswanatha Reddy Batchu.

Figure 1
Figure 1. Figure 1: Illustration of current automotive software stacks and our nomenclature view at source ↗
Figure 2
Figure 2. Figure 2: Illustration of the interaction of our terms. Automotive software view at source ↗
read the original abstract

In software-defined vehicles, automotive middleware plays a fundamental role in enabling efficient communication, integration, and coordination among software components. This paper examines how well two of the currently most popular middleware frameworks, ROS 2 Jazzy and AUTOSAR Adaptive Platform R24-11, meet practical requirements elicited from automotive software engineers at one of the major automotive supplier companies, ZF Group. Our objective is to provide insight into an otherwise difficult-to-obtain industrial perspective and support a clearer understanding of priorities in the development and evaluation of middleware for automotive applications.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript presents a comparative analysis of ROS 2 Jazzy and AUTOSAR Adaptive Platform R24-11 against a set of middleware requirements elicited from automotive software engineers at ZF Group. The objective is to supply a concrete industrial perspective on priorities for middleware in software-defined vehicles.

Significance. If the elicitation and evaluation procedures are described with sufficient transparency and rigor, the work supplies a valuable, hard-to-obtain industry-grounded viewpoint that can inform middleware selection and development in automotive contexts. It bridges academic and practitioner concerns without claiming universal representativeness.

major comments (2)
  1. [§3] §3 (Requirements Elicitation): The description of how requirements were gathered from ZF engineers is high-level only; details on participant count, elicitation technique (interviews, workshops, etc.), duration, and conflict-resolution process are absent. These elements are load-bearing for judging whether the resulting requirement list supports the comparative conclusions.
  2. [§4.2] §4.2 (Compliance Assessment): The criteria and scoring rubric used to rate each framework’s compliance with the elicited requirements are not specified (e.g., binary vs. graded compliance, handling of partial support, or resolution of ambiguous feature mappings). Without this, the tabulated comparison results cannot be independently verified or replicated.
minor comments (2)
  1. [Abstract] Abstract: The abstract would benefit from a brief quantitative statement (e.g., “X requirements were evaluated”) to give readers an immediate sense of scope.
  2. [Table 2] Table 2 or equivalent results table: Column headers and footnotes should explicitly define the compliance symbols or scores used so the table is self-contained.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the positive recommendation and the constructive comments, which will help strengthen the methodological transparency of the manuscript. We address the major comments point by point below.

read point-by-point responses

  1. Referee: [§3] §3 (Requirements Elicitation): The description of how requirements were gathered from ZF engineers is high-level only; details on participant count, elicitation technique (interviews, workshops, etc.), duration, and conflict-resolution process are absent. These elements are load-bearing for judging whether the resulting requirement list supports the comparative conclusions.

    Authors: We agree that the current description in §3 is high-level and that additional transparency would aid evaluation of the requirement set. In the revised manuscript we will expand this section to describe the elicitation technique (structured workshops combined with follow-up interviews), the approximate overall duration of the process, and the conflict-resolution approach (iterative group discussions leading to consensus on prioritization). Due to confidentiality agreements with ZF Group, we will provide these details at a generalized level that does not reveal sensitive participant or organizational information while still allowing readers to assess the rigor of the process. revision: partial

  2. Referee: [§4.2] §4.2 (Compliance Assessment): The criteria and scoring rubric used to rate each framework’s compliance with the elicited requirements are not specified (e.g., binary vs. graded compliance, handling of partial support, or resolution of ambiguous feature mappings). Without this, the tabulated comparison results cannot be independently verified or replicated.

    Authors: We acknowledge that the compliance assessment criteria and rubric were not explicitly articulated in the submitted version. In the revision we will insert a concise description of the scoring approach in §4.2, defining a three-level scale (full support, partial support, no support) together with explicit criteria for each level, the basis for classifying partial support, and the procedure used to resolve ambiguous feature-to-requirement mappings (reference to official documentation supplemented by author judgment). This addition will make the tabulated results more verifiable. revision: yes

Circularity Check

0 steps flagged

No significant circularity

full rationale

The paper performs an empirical comparison of ROS 2 Jazzy and AUTOSAR Adaptive Platform R24-11 against requirements elicited from ZF Group engineers. It contains no equations, derivations, fitted parameters, or self-referential definitions. The central claim rests on accurate description of the elicitation process and compliance assessment, which are independent observations rather than reductions to the paper's own inputs or prior self-citations. No load-bearing step reduces by construction to a fit, ansatz, or uniqueness theorem imported from the authors' own work. This is the expected outcome for a non-mathematical empirical study.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is an empirical comparison study with no mathematical derivations, fitted parameters, or postulated entities; it relies only on standard software-engineering practices for requirements gathering and framework analysis.

pith-pipeline@v0.9.0 · 5418 in / 989 out tokens · 48825 ms · 2026-05-08T11:20:16.385110+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

45 extracted references · 45 canonical work pages

  1. [1]

    Accessed: Dec

    Aptiv,Smart Vehicle Architecture: A Sustainable Ap- proach to Building The Next Generation of Vehicles, White Paper, 2020. Accessed: Dec. 5, 2025. [Online]. Available: https://www.aptiv.com/docs/default-source/ white- papers/2020 aptiv whitepaper sva.pdf?sfvrsn= 18b5c13e 33

    work page 2020

  2. [2]

    AUTOSAR Consortium,Explanation of Adaptive Plat- form Software Architecture, Standard, 2024

    work page 2024

  3. [3]

    AUTOSAR Consortium,Specification of Communica- tion Management, Standard, 2024

    work page 2024

  4. [4]

    AUTOSAR Consortium,Specification of Diagnostics, Standard, 2024

    work page 2024

  5. [5]

    AUTOSAR Consortium,Specification of Execution Management, Standard, 2024

    work page 2024

  6. [6]

    AUTOSAR Consortium,Specification of Operating Sys- tem Interface, Standard, 2024

    work page 2024

  7. [7]

    AUTOSAR Consortium,Specification of Persistency, Standard, 2024

    work page 2024

  8. [8]

    AUTOSAR Consortium,Specification of Platform Health Monitoring, Standard, 2024

    work page 2024

  9. [9]

    AUTOSAR Consortium,Specification of Raw Data Stream, Standard, 2024

    work page 2024

  10. [10]

    AUTOSAR Consortium,Specification of State Manage- ment, Standard, 2024

    work page 2024

  11. [11]

    AUTOSAR Consortium,Specification of Timing Exten- sion for Adaptive Platform, Standard, 2024

    work page 2024

  12. [12]

    AP-LET: Enabling deterministic Pub/Sub communi- cation in AUTOSAR Adaptive,

    D. Bellassai, C. Scordino, D. Casini, and A. Biondi, “AP-LET: Enabling deterministic Pub/Sub communi- cation in AUTOSAR Adaptive,”Journal of Systems Architecture, vol. 162, p. 103 390, 2025

    work page 2025

  13. [13]

    Au- tomotive E/E-architecture enhancements by usage of ethernet TSN,

    S. Brunner, J. Roder, M. Kucera, and T. Waas, “Au- tomotive E/E-architecture enhancements by usage of ethernet TSN,” in2017 13th Workshop on Intelligent Solutions in Embedded Systems (WISES), 2017, pp. 9– 13

    work page 2017

  14. [14]

    Response-Time Analysis of ROS 2 Processing Chains Under Reservation-Based Scheduling,

    D. Casini, T. Blaß, I. L ¨utkebohle, and B. B. Branden- burg, “Response-Time Analysis of ROS 2 Processing Chains Under Reservation-Based Scheduling,”LIPIcs, Volume 133, ECRTS 2019, vol. 133, 6:1–6:23, 2019

    work page 2019

  15. [15]

    PiCAS: New Design of Priority-Driven Chain-Aware Scheduling for ROS2,

    H. Choi, Y . Xiang, and H. Kim, “PiCAS: New Design of Priority-Driven Chain-Aware Scheduling for ROS2,” in 2021 IEEE 27th Real-Time and Embedded Technology and Applications Symposium (RTAS), 2021, pp. 251– 263

    work page 2021

  16. [16]

    Accessed: Dec

    eProsima,Introduction to Client Library, Documenta- tion, 2024. Accessed: Dec. 5, 2025. [Online]. Available: https : / / micro . ros . org / docs / concepts / clientlibrary / introduction/

    work page 2024

  17. [17]

    Architecture platforms for future vehicles: a comparison of ROS2 and Adaptive AUTOSAR,

    J. Henle, M. Stoffel, M. Schindewolf, A.-T. N ¨agele, and E. Sax, “Architecture platforms for future vehicles: a comparison of ROS2 and Adaptive AUTOSAR,” in 2022 IEEE 25th International Conference on Intelligent Transportation Systems (ITSC), 2022, pp. 3095–3102

    work page 2022

  18. [18]

    T. Huck, A. Achtzehn, A. Deberling, E. Goerres, and K. Wehefritz,The next step in E/E architectures, White Paper, 2023. Accessed: Dec. 5, 2025. [Online]. Avail- able: https://www.bosch- mobility.com/media/global/ mobility - topics / connected - mobility / iot - device - on - wheels / e - e - architecture / whitepaper / 230831 - bosch - xc-whitepaper-ee-ar...

    work page 2023

  19. [19]

    Modern middlewares for automated vehicles: A tutorial,

    D. P. Kl ¨uner, M. Molz, A. Kampmann, S. Kowalewski, and B. Alrifaee, “Modern middlewares for automated vehicles: A tutorial,”IEEE Intelligent Transportation Systems Magazine, pp. 2–25, 2026

    work page 2026

  20. [20]

    Kristoferitsch and V

    J. Kristoferitsch and V . Dillmann,Optimizing AU- TOSAR multicore distributions: Practical considera- tions with real-life automotive examples, White Paper,

    work page

  21. [21]

    Accessed: Dec. 5, 2025. [Online]. Available: https : / / www . etas . com / ww / media / a downloads / etas - white - paper - optimizing - autosar - multicore - distributions-en-2025-04-30.pdf

    work page 2025

  22. [22]

    Automotive Service-oriented Architectures: a Systematic Mapping Study,

    N. Kukulicic, D. Samardzic, A. Bucaioni, and S. Mubeen, “Automotive Service-oriented Architectures: a Systematic Mapping Study,” in2022 48th Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 2022, pp. 459–466

    work page 2022

  23. [23]

    Robot Operating System 2: Design, Ar- chitecture, and Uses In The Wild,

    S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot Operating System 2: Design, Ar- chitecture, and Uses In The Wild,”Science Robotics, vol. 7, no. 66, 2022

    work page 2022

  24. [24]

    Middleware Protocols in the Automobile: Service-Oriented, Data-Centric or RESTful?

    A. Mayr and M. Helmling, “Middleware Protocols in the Automobile: Service-Oriented, Data-Centric or RESTful?”Elektronik Automotive, no. 3, 2020. Accessed: Dec. 5, 2025. [Online]. Available: https://cdn. vector.com/cms/content/know-how/ technical-articles/ PREEvision / PREEvision MiddlewareProtocols ElektronikAutomotive 202003 PressArticle EN.pdf

    work page 2020

  25. [25]

    Accessed: Dec

    McKinsey,Outlook on the automotive software and electronics market through 2030. Accessed: Dec. 5,

    work page 2030

  26. [26]

    Available: https://www.mckinsey.de/ industries / automotive - and - assembly / our - insights / mapping - the - automotive - software - and - electronics - landscape-through-2030

    [Online]. Available: https://www.mckinsey.de/ industries / automotive - and - assembly / our - insights / mapping - the - automotive - software - and - electronics - landscape-through-2030

    work page 2030

  27. [27]

    Accessed: Dec

    McKinsey,The case for an end-to-end automotive- software platform. Accessed: Dec. 5, 2025. [Online]. Available: https : / / www . mckinsey . com / industries / automotive- and- assembly/our- insights/the- case- for- an-end-to-end-automotive-software-platform

    work page 2025

  28. [28]

    Achieving Determinism in Adaptive AUTOSAR,

    C. Menard, A. Goens, M. Lohstroh, and J. Castrillon, “Achieving Determinism in Adaptive AUTOSAR,” in DATE ’20: Proceedings of the 23rd Conference on Design, Automation and Test in Europe, 2020, pp. 822– 827

    work page 2020

  29. [29]

    (R)evolution of E/E Architec- tures,

    V . M. Navale, K. Williams, A. Lagospiris, M. Schaffert, and M.-A. Schweiker, “(R)evolution of E/E Architec- tures,”SAE International Journal of Passenger Cars - Electronic and Electrical Systems, vol. 8, no. 2, pp. 282–288, 2015

    work page 2015

  30. [30]

    Accessed: Dec

    Object Management Group,Interface Definition Lan- guage Specification Version 4.2. Accessed: Dec. 5,

    work page

  31. [31]

    Available: https://www.omg.org/spec/ IDL

    [Online]. Available: https://www.omg.org/spec/ IDL

    work page

  32. [32]

    Accessed: Dec

    Open Robotics,Executors — ROS 2 Documentation: Jazzy, Documentation, 2025. Accessed: Dec. 5, 2025. [Online]. Available: https : / / docs . ros . org / en / jazzy / Concepts/Intermediate/About-Executors.html

    work page 2025

  33. [33]

    Accessed: Dec

    Open Robotics,Monitoring for parameter changes (C++) — ROS 2 Documentation: Kilted, Documenta- tion, 2025. Accessed: Dec. 5, 2025. [Online]. Available: https://docs.ros.org/en/kilted/Tutorials/Intermediate/ Monitoring-For-Parameter-Changes-CPP.html

    work page 2025

  34. [34]

    Accessed: Dec

    Open Robotics,Parameters — ROS 2 Documentation: Jazzy, Documentation. Accessed: Dec. 5, 2025. [On- line]. Available: https://docs.ros.org/en/jazzy/Concepts/ Basic/About-Parameters.html

    work page 2025

  35. [35]

    Accessed: Dec

    Open Robotics,Quality of Service settings — ROS 2 Documentation: Jazzy, Documentation, 2025. Accessed: Dec. 5, 2025. [Online]. Available: https://docs.ros.org/ en / kilted / Concepts / Intermediate / About - Quality - of - Service-Settings.html

    work page 2025

  36. [36]

    Accessed: Dec

    Open Robotics,ROS 2 Security — ROS 2 Documen- tation: Jazzy, Documentation, 2025. Accessed: Dec. 5,

    work page 2025

  37. [37]

    Available: https://docs.ros.org/en/kilted/ Concepts/Intermediate/About-Security.html

    [Online]. Available: https://docs.ros.org/en/kilted/ Concepts/Intermediate/About-Security.html

    work page

  38. [38]

    Spencer,How the SOAFEE Architecture Brings A Cloud-Native Approach To Mixed Critical Automotive Systems, White Paper, 2021

    M. Spencer,How the SOAFEE Architecture Brings A Cloud-Native Approach To Mixed Critical Automotive Systems, White Paper, 2021. Accessed: Dec. 5, 2025. [Online]. Available: https://armkeil.blob.core.windows. net/developer/Files/pdf/white-paper/arm-scalable-open- architecture-for-embedded-edge-soafee.pdf

    work page 2021

  39. [39]

    The rclc Ex- ecutor: Domain-specific deterministic scheduling mech- anisms for ROS applications on microcontrollers: Work- in-progress,

    J. Staschulat, I. L ¨utkebohle, and R. Lange, “The rclc Ex- ecutor: Domain-specific deterministic scheduling mech- anisms for ROS applications on microcontrollers: Work- in-progress,” in2020 International Conference on Em- bedded Software (EMSOFT), 2020, pp. 18–19

    work page 2020

  40. [40]

    Timing-Aware ROS 2 Archi- tecture and System Optimization,

    H. Teper, T. Betz, G. V on Der Br ¨uggen, K.-H. Chen, J. Betz, and J.-J. Chen, “Timing-Aware ROS 2 Archi- tecture and System Optimization,” in2023 IEEE 29th International Conference on Embedded and Real-Time Computing Systems and Applications (RTCSA), 2023, pp. 206–215

    work page 2023

  41. [41]

    Ac- cessed: Dec

    VDA Working Group 13,Automotive SPICE Process Assessment / Reference Model, Standard, 2023. Ac- cessed: Dec. 5, 2025. [Online]. Available: https://vda- qmc . de / wp - content / uploads / 2023 / 12 / Automotive - SPICE-PAM-v40.pdf

    work page 2023

  42. [42]

    Development Processes in Au- tomotive Service-oriented Architectures,

    A. Vetter, P. Obergfell, H. Guissouma, D. Grimm, M. Rumez, and E. Sax, “Development Processes in Au- tomotive Service-oriented Architectures,” in2020 9th Mediterranean Conference on Embedded Computing (MECO), 2020, pp. 1–7

    work page 2020

  43. [43]

    Review of Electrical and Electronic Architec- tures for Autonomous Vehicles: Topologies, Networking and Simulators,

    W. Wang, K. Guo, W. Cao, H. Zhu, J. Nan, and L. Yu, “Review of Electrical and Electronic Architec- tures for Autonomous Vehicles: Topologies, Networking and Simulators,”Automotive Innovation, vol. 7, no. 1, pp. 82–101, 2024

    work page 2024

  44. [44]

    Exploring Real-Time Executor on ROS 2,

    Y . Yang and T. Azumi, “Exploring Real-Time Executor on ROS 2,” in2020 IEEE International Conference on Embedded Software and Systems (ICESS), 2020, pp. 1– 8

    work page 2020

  45. [45]

    Requirements-Driven Automotive Electrical/Electronic Architecture: A Survey and Prospective Trends,

    H. Zhu, W. Zhou, Z. Li, L. Li, and T. Huang, “Requirements-Driven Automotive Electrical/Electronic Architecture: A Survey and Prospective Trends,”IEEE Access, vol. 9, 2021

    work page 2021