Understanding the AUTOSAR standards

The AUTOSAR standards consist of a set of specifications, standards, and guidelines that provide a framework for the development and integration of SWCs in automotive ECUs. The AUTOSAR standards consist of the following components:

Figure 1.5 – AUTOSAR standards

The following list describes these components in detail:

• AUTOSAR platform: AUTOSAR has two main flavors, namely, Classic Platform (CP) and Adaptive Platform (AP). It is a common misconception that adaptive AUTOSAR is replacing classic AUTOSAR. Both adaptive AUTOSAR and classic AUTOSAR are complementary software architectures that address different requirements and use cases in the automotive industry:
  • CP is intended for conventional embedded automotive systems that have a fixed set of functionalities and tightly integrated hardware and software (static). It features a layered architecture and standardized interfaces that facilitate the consistent and efficient development and integration of SWCs. It is also optimized for resource-constrained environments, making it ideal for ECUs with limited processing power and memory.

  It uses an OSEK/VDX-based real-time operating system (RTOS), which is highly deterministic and optimized for real-time performance, thus suitable for safety-critical and hard real-time applications such as powertrain and chassis control.

  Communication is based on static configurations using predefined protocols such as CAN, LIN, FlexRay, and Ethernet, and communication relationships are established at design time.

  • AP is designed for more flexible and dynamic automotive systems, where the hardware and software are decoupled and can be upgraded independently. It provides a modular architecture and supports the use of open source and third-party components, enabling faster innovation and more frequent updates. In contrast to CP, it supports dynamic communication with a service-oriented architecture (SOA) using Ethernet, where services can be discovered and communicated with during runtime. It uses a POSIX-compliant operating system, typically based on Linux, which provides greater flexibility, suitable for handling complex and resource-intensive tasks.

  The two flavors of AUTOSAR reflect the different needs and requirements of the automotive industry, and they are designed to provide a common standard for the development and integration of SWCs in vehicles, regardless of the specific use case or application.

• Foundation: Foundation (FO) in AUTOSAR is designed to ensure interoperability between different AUTOSAR platforms by providing a set of generic artifacts that are shared between both CP and AP. This helps to promote compatibility between different platforms, including those that are not based on AUTOSAR, and ensures that automotive systems and devices can work together seamlessly.

  It contains common requirements and technical specifications, for example, E2E Protocol Specification, V2X Specification, Secure Onboard Communication Protocol, and Specification of Intrusion Detection System Protocol, which are all shared between the AUTOSAR platforms (CP and AP).

Figure 1.6 – FO within AUTOSAR standard

• Acceptance tests (ATs): AUTOSAR ATs are system tests at the bus level as well as the application level to validate the behavior of an AUTOSAR stack with regard to the ASW components as well as the communication bus:

Figure 1.7 – Acceptance test AUTOSAR

The documentation at https://www.AUTOSAR.org/fileadmin/standards/tests/1-2/AUTOSAR_ATS_CommunicationCAN.pdf describes AT specifications of communication on a CAN bus. It describes the test case steps along with the test architecture. In Figure 1.8, taken from the preceding example use case, this diagram illustrates a test setup where a test bench sends test sequences to an embedded SWC within the system under test (SUT) via the CAN bus.

Figure 1.8 – Test architecture description

• Application interfaces (AIs): AUTOSAR has standardized a large set of AIs in terms of syntax and semantics for the different vehicle domains: Body and Comfort; Powertrain; Chassis Control; Occupant and Pedestrian Safety; and HMI, Multimedia and Telematics. For instance, the Chassis Control domain focuses on stability and control, while Powertrain manages propulsion. The Body domain handles comfort and convenience features, autonomous systems enable self-driving capabilities, and in-vehicle infotainment (IVI) ensures entertainment and connectivity. AUTOSAR defines reference interfaces and SWCs across these domains that the systems can communicate effectively and are interoperable, regardless of the specific hardware or software used by different manufacturers. For example, the Powertrain and Chassis Control systems work together for car stability and performance, while the ADAS relies on inputs from various sensors and systems to make real-time driving decisions.

  An example of an application interface in AUTOSAR is the adaptive cruise control (ACC) interface. This interface standardizes how the ACC component communicates with other vehicle systems, such as sensors and actuators. It defines how data such as vehicle speed and distance from the car ahead is processed and exchanged, allowing ACC to maintain a safe distance from other vehicles automatically. By using this standardized interface, different ACC implementations can interact with various sensors and actuators across different vehicle models, guaranteeing consistency and interoperability. This is discussed in further detail here: https://www.autosar.org/fileadmin/standards/R22-11/CP/AUTOSAR_EXP_AIChassis.pdf

AUTOSAR standardizes the interfaces and SWCs across these domains, ensuring that the systems can communicate effectively and are interoperable, regardless of the specific hardware or software used by different manufacturers. For example, the interaction between the Powertrain and Chassis Control systems is crucial for vehicle stability and performance, while the Autonomous domain relies on inputs from various sensors and systems to make real-time driving decisions.