AUTOSAR Classic Platform
Automotive Open System Architecture, in short AUTOSAR was introduced in 2003, to manage complexity. The AUTOSAR Classic has a modular architecture with layers that aim to separate hardware-independent application software from hardware-oriented software.
The upper layer, Application Software Layer (ASW), acts as a host for individual software components (SWC) that provide application functions. It offers a hierarchical structure for creating software components. The packaging of multiple SWCs to implement a subsystem is involved in Composition, which can be further composed. Atomic SWCs can be categorized as Application or Sensor-Actuator. Application software components implement parts of an application and can use AUTOSAR communication mechanisms and services. Sensor-Actuator software components interact with sensor or actuator hardware.
The lower layer, Basic Software (BSW), comprises of low-level software such as services and hardware-specific software. Between these layers lies the Runtime Environment (RTE), which acts as an abstraction layer managing the interface between the upper and lower layers.
More information about the AUTOSAR Classic platform including Interfaces, methodology, templates, the Internal behavior of an Atomic Software can be found under Nabile Khoury’s blog.
The need for a new AUTOSAR Adaptive Platform
Looking towards the future of automotive technology, the so-called “Software Defined Vehicle” requires advanced software. This software must meet integrity and security requirements while also enabling new functions like environment perception, behavior planning, and integration with external systems. This new software can be updated during the vehicles’s life cycle to accommodate evolving systems and improved functionality, unlike control software.
The AUTOSAR Adaptive Platform (AP) is developed alongside the existing AUTOSAR Classic Platform (CP), to address these needs. While the CP meets embedded ECU requirements, the AP provides high-performance computing and communication mechanisms, flexible software configuration, and support for over-the-air updates. Although the AP primarily focuses on these new requirements, it can also integrate CP-specific features, such as access to electrical signals and automotive bus systems, if needed.
Two primary drivers are crucial in this context: Ethernet and processors.
- Ethernet meets the increasing bandwidth requirements for on-vehicle networks, offering higher bandwidth and efficient transfer of long messages and point-to-point communications compared to legacy technologies like CAN. However, current communication processors (CP) face challenges in fully utilizing the capabilities of Ethernet-based communications.
- Growing vehicle intelligence demands more processing power. Multicore processors are already in use, but there is a growing need for multicore processors, GPU, FPGA, and dedicated accelerators due to their superior performance. Pollack’s Rule states that it is physically not possible to increase the processor frequency endlessly. The only way to scale performance is to employ multiple cores and executing them in parallel.
Characteristics of AUTOSAR Adaptive
The landscape of intelligent ECUs and technological drivers has led to the following characteristics of the AUTOSAR Adaptive platform:
- C++ Programming: C++ is the preferred language for developing new algorithms and application software in performance-critical complex applications. It enables faster adaptation of novel algorithms and improves application development productivity.
- Service-Oriented Architecture (SOA): The platform follows a service-oriented architecture (SOA) to support complex applications with flexibility and scalability in processing distribution and compute resource allocations. SOA allows services to use one another, whether they are located on the local ECU or a remote ECU running another instance of the platform.
- Parallel Processing: Distributed computing and SOA enable parallel processing as different applications use different sets of services. The advancements in manycore processors and heterogeneous computing provide opportunities to harness compute power and match the inherent parallelism.
- Safety & Security: The platform combines architectural, functional, and procedural approaches to ensure safety and security. It uses distributed computing based on SOA, making each component independent and free of unintended interferences. Guidelines like C++ coding guideline facilitate safe and secure usage of complex languages like C++.
- Integration with Classic and non-AUTOSAR ECUs: The AUTOSAR Adaptive platform does not replace existing platforms but interacts with them and external backend systems to form an integrated system. For example, it supports protocols like SOME/IP, which are already incorporated in CP.
Architecture of AUTOSAR Adaptive
The AA (Adaptive Applications) operate on top of ARA (AUTOSAR Runtime for Adaptive applications). ARA consists of application interfaces provided by Functional Clusters, which belong to either Adaptive Platform Foundation or Adaptive Platform Services. The Adaptive Platform Foundation provides fundamental functionalities of AP, along with platform standard services known as Adaptive Platform Services. Additionally, any AA can offer Services to other AA, as shown in the figure as non-platform service.
- Application: A software unit, called an Adaptive Application, is deployed to a particular ECU. It consists of several software components, each of which holds less significance compared to the conventional platform. These components solely communicate through the middleware.
- API Clusters: API refers to a C++ standard defined by AUTOSAR. Adaptive applications can directly communicate with the functional clusters of the platform foundation.
- Service: A Service represents dynamic communication established during runtime. It is a C++ API standardized by AUTOSAR, used by both platform service functional clusters and adaptive applications. Services may be offered, withdrawn, or requested. Communication management facilitates the interaction between service providers and requesters, even if they are located on different machines.
AUTOSAR Adaptive – Interfaces
Software components communicate through “Ports.” A Port serves as a gateway for requesting or sending information, with the semantics varying based on the type of data or service being exchanged. Each port must first align with an Interface that defines the information exchange (e.g., requesting/sending specific data). An Interface can be utilized in multiple instances, ensuring consistent data definitions for both provided and required ports. The AUTOSAR Interfaces are:
- The Service Interface (SWS) serves to define the operations or services a software component can provide or utilize. It specifies the operations, data types, and potential errors linked to the service.
- The Parameter Interface (Prm) outlines the parameters and data types used by a service interface. it describes the input and output parameters of a service.
- An Event Interface (Evt) is managed to handle asynchronous communication between software components. it details the events that can be transmitted or received by a software component.
- The Mode Interface (Mode) defines the different modes a software component can enter. It specifies the transitions between modes and the conditions that trigger these changes.
- The Lifecycle Interface (Lifecycle) oversees the initialization and shutdown processes of software components. It specifies the possible states of a software component and the transitions between these states.
- The Port Interface (Port) represents a component’s interface enabling interaction with its environment. It functions as a provided port (offering services) or a required port (demanding services).
- The Timing Interface (Timing) defines the timing traits of a software component. It specifies whether the communication associated with the component is periodic or aperiodic.
The Service Interface, originating from Port Interface, enables a diverse composition of elements, including the integration of VariableDataPrototype in the event role, Field meta-class in the field role, ClientServerOperation in the method role, and Trigger in the trigger role.
Events:
VariableDataPrototype represents the array of events defined within the Service Interface. An event signifies an update to a data piece, with the server controlling when to transmit this update to retain full control over the value. Clients can only access an event’s value by receiving an event update from the server.
Fields:
Unlike events, a field always holds a specific value. Clients may choose to receive notifications about changes in field values. Fields possess attributes like hasGetter, hasSetter, and hasNotifier.
Methods:
A method embodies a function executed within a server’s scope upon request from one or more specifics. A “fire & forget” method is a specialized form dedicated to relaying information from a client to a server, without requiring the method to execute any algorithm beyond accepting incoming data. The semantics of a “fire & forget” method mirror those of an event, but in reverse, conveying data and its occurrence from a client to a server. An event conveys information and its occurrence from a server to a client.
Trigger:
A Trigger represents a distinct type of event (void of data) that prompts the Service Consumer to react in a defined manner upon its occurrence. Triggers are processed in a queued fashion, stored in a queue, and handled on a “first in, first out” basis.
Conclusion
In essence, AUTOSAR Adaptive stands out as a pivotal standard in automotive software architecture, offering a service-oriented framework that enhances modularity and scalability within complex vehicle systems. The advantages it brings include improved interoperability, flexibility, and reusability of software components, addressing the challenges of modern automotive software development. BTC Embedded Systems AG’s tool, BTC EmbeddedPlatform, plays an active role in the ecosystem. It develops cutting-edge tools for comprehensive testing solutions in AUTOSAR Adaptive, ensuring software reliability and safety in compliance with the standard.
