Classic Platform

About

The AUTOSAR Classic Platform architecture distinguishes on the highest abstraction level between three software layers which run on a micro­con­troller: application, runtime environment (RTE) and basic software (BSW).

  • The appli­ca­tion software layer is mostly hardware inde­pen­dent.
  • Com­mu­ni­ca­tion between software com­po­nents and access to BSW via RTE.
  • The RTE rep­re­sents the full interface for appli­ca­tions.
  • The BSW is divided in three major layers and complex drivers:
    • Services, ECU (Elec­tronic Control Unit) abstrac­tion and micro­con­troller abstrac­tion.
  • Services are divided fur­ther­more into func­tional groups rep­re­sent­ing the infra­struc­ture for system, memory and com­mu­ni­ca­tion services.
Important Notice

All files – regardless of the type – are made available for download on this website as released by AUTOSAR for the purpose of INFORMATION ONLY.
Please note the disclaimer in each file for detailed information about copyright/IPR protections and conditions for exploitation.

Terms of Use

If you are interested in exploitation of released AUTOSAR Work, please apply for a AUTOSAR partnership.

Apply for Partnership

Current Release

AUTOSAR Classic Release R24-11

Appli­ca­tion Layer

Runtime Envi­ron­ment

System Services

Memory Services

Crypto Services

Off Board Communca­tion Services

Commu­ni­ca­tion Services

I/O Hardware Abstrac­tion

Complex Drivers

Onboard Device Abstrac­tion

Memory Hardware Abstrac­tion

Crypto Hardware Abstrac­tion

Wireless Commu­ni­ca­tion Hardware Abstrac­tion

Commu­ni­ca­tion Hardware Abstrac­tion

Micro­con­troller Drivers

Memory Drivers

Crypto Drivers

Wireless Commu­ni­ca­tion Drivers

Commu­ni­ca­tion Drivers

I/O Drivers

Micro­con­troller

Descrip­tion

Concept

One essential concept is the virtual functional bus (VFB). This virtual bus decouples the applications from the infrastructure. It communicates via dedicated ports, which means that the communication interfaces of the application software must be mapped to these ports. The VFB handles communication both within the individual ECU and between ECUs. From an application point of view, no detailed knowledge of lower-level technologies or dependencies is required. This supports hardware-independent development and usage of application software.

The AUTOSAR layered architecture is offering all the mechanisms needed for software and hardware independence. It distinguishes between three main software layers which run on a Micro­con­troller (µC): application layer, runtime environment (RTE), and basic software (BSW).

The applications of the different automotive domains interface the basic software by means of the RTE.

In addition to defining architecture and interfaces, AUTOSAR also defines a methodology which enables the configuration of the complete AUTOSAR stack and enhances inter­op­er­ability between different tool chains. On the one hand this is important for the collaboration within development projects and on the other hand this is important to cut down development costs.

Archi­tec­ture

The main concept of the standardized ECU software architecture is the separation of hardware-independent application software and hardware-oriented basic software (BSW) by means of the software abstraction layer RTE (runtime environment). On the upper side of the RTE, this abstraction layer enables the development of OEM-specific and competitive software applications. On the lower side of the RTE, it enables the stan­dard­iza­tion and OEM-independence of basic software. Further char­ac­ter­is­tics of the AUTOSAR software architecture are the scalability of ECU software for several car lines and variants, the possibility to distribute applications (functional software modules) across ECUs, and the ability to integrate software modules from different sources.

The basic software within the AUTOSAR software architecture is further divided into the following layers: services, ECU abstraction, and micro­con­troller abstraction. The separation of the application layer from the basic software, realized by the RTE, includes the control of the data exchange between these layers. This forms the basis for a component-oriented, hardware-independent software structure on application level, with software components (SWCs) as individual units. Because of their hardware independence, it is thus possible to develop SWCs without specific knowledge of the hardware used or planned, as well as to flexibly relocate existing SWCs to ECUs during development.

Method­ol­ogy and Templates

In addition to a software architecture, AUTOSAR introduced a harmonized methodology approach for the development of automotive software. This is mainly driven by the need to improve the collaboration between the different parties involved in today’s automotive projects.  

AUTOSAR provides means to specify all aspects necessary to integrate a software component on an ECU and to integrate different ECUs to the whole network communication over a variety of different bus systems. The methodology defines the dependencies of activities on work products and is foreseen to support activities, descriptions and usage of tools in AUTOSAR.

The descriptions (.arxml) are based on the AUTOSAR Templates which define the formal exchange format (AUTOSAR Schema) and the semantic constraints which go along with the exchange format.  The descriptions are used to hold the information that is produced or consumed in the AUTOSAR methodology. Various generators can utilize the information from the descriptions to support the configuration and generation of the RTE and the AUTOSAR basic software (including the operating system).