Release Event 2025

General questions

What are differences use-cases between Classic and Adaptive AUTOSAR?

Regarding the differences between Classic and Adaptive, please refer to our Introduction to AUTOSAR Presentation starting with slide #34.

How is AUTOSAR utilizing AI?

Within the development of the CAPI framework, AUTOSAR will also consider AI-related features, while at the same time respecting existing IP ownership and clearly indicating any open-source code components included in the CAPI project. Please, also refer to our upcoming initiative - AUTOSAR Explorer.

How long do you think Classic AUTOSAR will be relevant in the growing industry?

There are no plans to replace AUTOSAR Classic platform. We are continuously updating and enhancing the AUTOSAR Classic Platform, and we are open to consider necessary changes to be up to date.

Why is there a decrease in partners and contributors compared to last year?

From the presentation by the Chairperson: Numerous companies around the world have suspended or completely abandoned their involvement in the automotive software domain or changed their organization. The current economic conditions are particularly difficult for small companies, which for instance is reflected in a consolidation among our Development Partners.

When several platforms (Yocto Linux, Eclipse Score, Adaptive AUTOSAR) can run high-performance automotive applications, why should an OEM choose Adaptive AUTOSAR?

Adaptive Platform combines the aspects of safety, security and automotive tailored solutions for a POSIX platform. It is designed to combine seamlessly with the classic platform which covers real time and high safety requirements.

I always hear about contributing to the AUTOSAR team, but as an Associate Partner we are not allowed to contribute. How does this fit?

To support the development of the standard, please have a look on the available partnership levels.

Adaptive AUTOSAR and S-CORE appear to provide similar middleware architectures. Are these platforms overlapping in scope, or is this a duplicated concept?

You are right. We share the view that there is currently the perception in the market of parallel activities with overlapping or similar scope. Nonetheless, AUTOSAR has established as the global automative industry software standard. By enhancing the scope to the code development AUTOSAR is bridging both worlds of specification- and code work within one organization.

AUTOSAR is focusing on Adaptive and SDV which (IMHO) affects mostly OEMs as they are developing the HPC. What benefit does AUTOSAR bring to companies not working on SDV/Adaptive?

The Adaptive Platform is widening the scope of AUTOSAR. Still as shown in this Release Event, also the Classic Platform is extended to the current need of the global automotive industry.

In one presentation "AUTOSAR community" was mentioned - who is this community?

We have different defined AUTOSAR partnerships. Partnership levels with the right to cooperate in Working Groups can influence the AUTOSAR Standard accordingly (open-source community way of working baked into AUTOSAR’s DNA).

How can AUTOSAR code be compatible with many varieties of peripherals worldwide?

AUTOSAR is supporting almost all automotive ecosystems available on the market.

As I have an automotive embedded project idea, how do I start visuals step intervention using AUTOSAR?

We think the best approach to get started and to realize your project idea is to get in contact with one of the AUTOSAR stack suppliers.

Is any proof-of-concept code being written and tested while introducing a new stack component?

The AUTOSAR review processes have shown that potential problems are detected upfront before introducing a new feature. Nonetheless, if the community requests a prototypical implementation, it is still possible to do it on top.

Are there implementations already available from the AUTOSAR stack vendors commercially based on R25-11 or based on the release of these specifications would it be further developed or matured?

To answer this question, please get in contact with the AUTOSAR stack vendors.

Is there any changes in 0x29 service?

In the release R25-11 there were no updates on Authentication Service 0x29. But please consider the following limitation: For UDS service 0x29, the Dcm supports only the sub-functions for PKI. Authentication via challenge response is not supported.

AUTOSAR Common Adaptive Platform Implementation (CAPI)

What part of the current Adaptive demonstrator will be brought into CAPI?

We are currently evaluating what parts of the Demonstrator could be reused. It is important that we achieve for CAPI automotive-grade code quality which is certification-ready.

Is CAPI not competing with Adaptive Platform solutions from some stack vendors?

The intention of AUTOSAR is to have a unique common code bases to reduce effort and avoid various interpretation of specifications.

Is CAPI intended to be incorporated into AUTOSAR as a methodology or framework for integrating open-source software (OSS)?

With CAPI AUTOSAR is enabling a framework for a common Adaptive Platform Implementation (CAPI). The implementation provided by partners will be accessible by OSS projects and commercially useable by AUTOSAR.

What is the roadmap of CAPI and when will it be available?

A roadmap is yet not available as AUTOSAR needs time to analyse code contributions - for instance in terms of tracing towards the AUTOSAR specification - especially important for certification aspects.

Have partners already contributed code for CAPI and/or which partners plan to contribute code?

Many companies are currently interested in providing code to the CAPI project. AUTOSAR is currently in discussion with interested companies content wise and in attional also set-up wise (shaping the framework together).

How can CAPI have an advantage over other middlewares introduced nowadays, such as S-CORE?

AUTOSAR provides both the standardization and the code implementation framework under one organizational roof. This makes it much faster to keep both artifacts in sync compared to coordinating across multiple organizations. This advantage is especially important in the context of certification, where close alignment between specification and implementation cannot be emphasized enough.

Is there any plan for AUTOSAR to simplify the application development workflow with CAPI?

CAPI is focused on providing an implementation of the Adaptive Platform. This means its outcome will primarily support workflows for infrastructure software.
For optimizing the application development workflow, other activities are in place—such as CP-EVO and the Workflow Example.

Vehicle Data Protocol (VDP)

There is a significant similarity between VDP and the IDS-PDUs and IdsM operation. Is there a plan to connect the two?

IDS and VDP might have similar parts. But they have different use cases and are optimized for it. Currently there are no plans to connect them.

Is VDP as a component available in Classic or in Adaptive or in both? What is the difference with respect to DLT?

DLT is used for logging and tracing that is a different topic then data collection. Data collection is intended for usage in series cars and much more data points are usually available. The collection can be switched on and off dynamically at runtime.

The VDP is intended to connect the classic platform to the data collection core that us usually running on an HPC based on adaptive. So you need VDP on both sides.

What is the main difference between VDP and RoE? Or is VDP basically RoE but for any signals?

RoE is a part of diagnosis. VDP covers much more, it is possible to connect all kind of data inside the classic platform, not limited to diagnosis.

How is the timestamp added from TSYNC for a data point?

The timestamp for the data points is retrieved from the StbM module.

Is there any relation or relevance between VDP and COVESA VSS?

These are different topics: The VDP provides a communication mechanism for data collection. The data points that are transferred within VDP must be described somehow. One option to do this is COVESA VSS. But also, other possibilities exist for data collection.

Security

W.r.t. context data of security events defined by AUTOSAR: is there a way to define what is mandatory and what could be optional?

AUTOSAR itself is not defining optional context data, but there is an optional callback to modify or tailer the context data. For further updates the IDSM message is versioned to support different versions of the same Security Event in the vehicle.

How does AUTOSAR ensure secure identity and data integrity when vehicles connect to shared cloud platforms?

AUTOSAR provides mechanisms for secure communication of the vehicle with the cloud by e.g. using TCP and TLS or IPsec. The storage of the data inside the cloud is currently out of the scope of AUTOSAR.

What strategies ensure AUTOSAR’s security events prevent cross-tenant attacks when ECUs connect to cloud platforms?

Attacking another ECU from a compromised cloud gateway is typically impeded by IPsec or E2E protected signals, bus separation and similar system level designs further enhance security.

DDS Support on CP

When we have some/IP and when to use DDS, what is the recommendation from AUTOSAR?

Using SOME/IP or DDS mainly depends on the requirements of the OEMs.

How many resources (CPU, memory, etc.) are needed to deploy DDS in a CP system?

DDS might require more resources than SOME/IP. In addition, the resource consumption scales with the amount of participants on the network. For a more detailed answer, please get in contact with the AUTOSAR Stack Supplier of your choice.

At which architecture level is DDS? How does it interact with RTE?

The DDS architecture in CP consists of two modules. The ddsxf module operates similarly to SomeIpXf, which is invoked by the RTE. The protocol logic resides in the Dds module, which interfaces only with PduR.

How does the stateless DDS Transformer improve performance and memory efficiency in Classic ECUs without adding protocol overhead?

The role of the DDS transformer is not to implement a protocol as in the case of SOME/IP. DdsXf is only used to copy the structured data coming from the RTE into the buffer that constitutes the PDU.

How does the DDS Discovery Engine enforce deterministic startup and resource bounds across SPDP/SEDP modes, especially in partially dynamic topologies?

Overall, resources should be allocated for the maximum expected number of participants. At present, start-up handling is restricted because there is no service control interface with BswM. Potential improvements could address this limitation.

Classic AUTOSAR is targeted toward low resource microcontrollers. Available DDS implementations require many megabytes of RAM. Are there plans for DDS implementations with lower RAM requirements to be suitable for microcontrollers?

It is certainly necessary to provide a configuration tailored to the available resources and network needs. In any case, the utilization also strongly depends on the implementation of the module.

Rust in CP Outlook

When will Rust in AUTOSAR CP be available? What is the current status, next steps, and roadmap?

The current prototype of Rust for classic platform is available from the partner gitlab. We are actively reshaping it in our weekly meetings.

How is RUST beneficial in Classic Platform?

Rust's type safety and high-level language features make it easier and more convenient to write correct code. We work hard to make the assembly code as efficient as C with a more high-level design for SWCs.

Will Rust become the preferred tool for CAPI projects in the future, or could it replace C++ as the standard?

Rust and C++ are meant to become fully supported languages for CAPI. There is no preference for Rust as an implementation language, yet.

The Rust in AUTOSAR will only be available for Classic Platform — is there a plan to replace C and C++?

The code for Rust on adaptive platform was released as part of R25-11. We are still working to extend the capabilities of the Rust API to cover all subsystems.

To use Rust in CP, is a change of the RTE generator mandatory?

In theory you can combine the Rust code with any existing RTE generated code, but for a more efficient system C relies on macros which can't be used from Rust. So Rust support in the generator is needed to achieve the same performance as C.

Are there MISRA rules for Rust?

Yes, there is an appendix on Rust in the latest MISRA standard (addendum 6 to MISRA C:2025)

Is it still possible to resolve symbol names using SYMBOL-PROPS when introducing Rust into the system?

Yes, the symbol property will override the short name for the naming of functions.

Classic Platform Workflow Example

The Workflow example shows good interaction between ECU Integrator and SWC Vendor. Still, we see unclarity in projects about the handling of the Exchange of Component API / Contract phase between distributed parties. Can this be added?

Thanks for your input. We try to consider this in our future workflow examples.