Other meanings of AUTOSAR
Automotive software standard
AUTOSAR (Automotive Open System Architecture) is an open, partner-developed standard for organizing software in road vehicles. It separates application functions from much of the underlying electronic-control-unit hardware and defines interfaces, descriptions, and development methods intended to improve portability, reuse, integration, and scalability across suppliers and vehicle programs.1
AUTOSAR standardizes the structure and interaction of vehicle software rather than prescribing one vendor’s implementation. The partnership was established in 2003 by major automotive manufacturers and suppliers in response to growing software complexity, and it has since maintained specifications for interfaces, methodology, and exchangeable descriptions.
Its central objective is separation of concerns. Application software expresses vehicle functions, while standardized abstractions reduce direct dependence on a particular microcontroller, operating-system service, or ECU supplier. That separation can support reuse across vehicle lines, although migration still requires configuration, integration, testing, and attention to hardware-specific behavior.
AUTOSAR is a specification family, not a complete software product. Companies provide compliant operating systems, basic-software modules, development tools, generators, and integration services; conformance and interoperability therefore depend on the chosen release, profiles, and implementation.
AUTOSAR’s platforms address different computational environments. The Classic Platform targets deeply embedded, resource-constrained ECUs with comparatively fixed functions and stringent timing requirements; its layered design commonly places application components above the Runtime Environment and Basic Software.
The Adaptive Platform is intended for high-performance computing units and applications that need more dynamic deployment, service-oriented communication, and interaction with a POSIX-based operating-system environment. It is suited to functions such as advanced vehicle computing, connectivity, and automated-driving workloads, while Classic remains common for deterministic control.
A separate Foundation specification defines elements shared by or relevant to multiple platforms. The division is architectural, not a simple ranking: a vehicle can contain both platform types, connected through networks and system-level integration.
AUTOSAR turns software integration into a model- and configuration-heavy workflow. Engineers describe software components, ports, interfaces, data types, ECU resources, and communication mappings in standardized descriptions, often exchanged as ARXML files; tools then generate or configure parts of the Runtime Environment and Basic Software.
That workflow clarifies contracts between vehicle manufacturers, tier-one suppliers, and software vendors. A component can expose its required and provided interfaces without revealing all of its implementation, making distributed development more manageable. Communication abstractions can also let an application be mapped to different ECUs with less source-code change, though generated configuration and integration artifacts remain platform-specific.
The benefits carry costs: specifications are extensive, toolchains can be expensive, and debugging generated layers may require expertise spanning application code, middleware, networks, operating systems, and microcontrollers. AUTOSAR therefore complements, rather than eliminates, conventional embedded-systems engineering.
AUTOSAR does not by itself certify a vehicle as safe or secure. Functional-safety work remains governed by processes and evidence such as those associated with ISO 26262, while vehicle cybersecurity engineering is addressed by standards including ISO/SAE 21434.1 2 An AUTOSAR implementation must be selected, configured, and assessed within those broader engineering frameworks.
The standard also reaches beyond visible application interfaces. It covers diagnostic communication, nonvolatile data, network management, memory services, cryptographic support, operating-system integration, and mechanisms for updating or supervising software. These less conspicuous services are central to production vehicles because they connect development-time descriptions with manufacturing, service, and field operation.
Another subtle distinction is between portability and determinism. Standard interfaces can improve portability, but timing, memory consumption, interrupt behavior, compiler effects, and hardware drivers still require ECU-specific validation. AUTOSAR reduces architectural coupling; it does not make every component interchangeable without engineering work.
AUTOSAR specifications are released in multiple versions and contain implementation-specific requirements; terminology and available features can therefore differ between releases and platform variants.
Help improve the encyclopedia. Reports go straight to the site manager.