AUTOSAR Adaptive Platform 25-03: Key Changes for Automotive Software Architects

The March 2025 release of AUTOSAR Adaptive Platform introduces significant changes to the service discovery mechanism, tightens cybersecurity integration with ISO/SAE 21434, and clarifies the execution management lifecycle for safety-critical applications.

AUTOSAR AP 25-03: What Changed and Why It Matters

AUTOSAR Adaptive Platform has become the de facto software architecture standard for compute-intensive automotive applications — ADAS, infotainment compute, vehicle compute platforms. The 25-03 release addresses three areas where implementation experience had surfaced significant ambiguities or gaps.

Service Discovery: Clarity on Timing and Determinism

The service-oriented architecture at AUTOSAR AP's core relies on service discovery via SOME/IP. Previous releases left ambiguous how applications should behave during the service discovery phase — specifically, what a service consumer should do if a required service is not yet available at startup.

25-03 specifies: applications must declare their service dependencies in their manifest; execution management is responsible for sequencing application startup to respect declared dependencies; and a defined timeout with configurable behaviour (wait, degrade, fail) must be specified for each dependency. This closes a gap that caused inconsistent startup behaviour across implementations.

Cybersecurity Integration

Previous releases referenced ISO/SAE 21434 but did not provide concrete integration points. 25-03 adds: a mandatory SecOC (Secure Onboard Communication) profile for inter-ECU communication over Ethernet; requirements for authenticated service requests when service endpoints are designated as security-sensitive; and a cybersecurity manifest element that must accompany each application package.

For software architects, this means security-by-design is now structurally embedded in the platform rather than bolted on. Applications cannot be deployed without a cybersecurity manifest; security analysis is no longer optional.

Execution Management Lifecycle

The execution management specification in previous releases was ambiguous about the transition between Running and Terminating states for safety applications — specifically whether a safety application could refuse a termination request and what execution management should do in that case.

25-03 specifies a mandatory watchdog mechanism: safety applications register a heartbeat; execution management monitors it; and a missed heartbeat triggers a health management response rather than a direct termination. This provides a principled way to handle the tension between platform lifecycle management and safety application integrity.