Exploring Adaptive AUTOSAR

Introduction:

Adaptive Autosar, Vehicle connectivity, High Performance Computer. You may hear these terms repeatedly in the automotive field nowadays. Let's first know why are many technologies are being developed now and in the future.

New functionalities such as environment perception, autonomous driving, vehicle connectivity and Car as a Service (CaaS), many new functionalities and also many complexities have introduced a new set of problems to the electrical/electronic (E/E) architecture. They are different/complex to the ones?ClassicAS?was designed for. These new functionalities are expected to evolve during the vehicle’s lifetime. High complexity leads to high computing power, faster communications and continuous updates is absolutely needed.

In accordance, High Performance Computers have been introduced to keep up with these new technologies which needs huge computational power. In addition, a very flexible and scalable communication protocol was introduced for the same purpose (SOME/IP).

HPC means the joint usage of not one or two, but many cores, processors, GPUs and other processing units. ClassicAS, already struggling with multi-core ambients, cannot define a solid structural model for the new processing needs. Similarly, even though the higher bandwidth provided by ethernet is already in use by ClassicAS, this architecture cannot completely harness its power, and so its true potential in the automotive industry is yet to be discovered. Furthermore, the static nature of ClassicAS makes it inflexible in certain aspects. For example, its scheduling algorithm doesn’t allow it to dynamically assign tasks to cores, meaning the usage at one core could be nearing 100%, while another one is barely used. The dynamicity offered by AdaptiveAS comes to the rescue and expands the solution to the many-cores architecture.

Taking these new aspects into account, ClassicAS is not enough to design software that suits these new inputs.

Motivation:

The motivation behind Adaptive Autosar is to achieve a more flexible, dynamic and expandable system. To better utilize the capabilities of HPC with a different architecture than the one introduced by ClassicAS conserving the "layered architecture" which distinguish the AUTOSAR platform.

Architecture:

The AdaptiveAS architecture is based on Service Oriented Architecture (SOA).

Service Oriented Architecture (SOA) can be defined as a model in which services are made available across a network. The services can reside either on the same ECU or externally in another ECU. Furthermore, the services are self-contained units; the clients (the users of services) are independent from the services. In addition, the coupling between services and clients is dynamic at runtime (in contrast to compile time from ClassicAS). Applications can consume services (i.e. clients) or also offer services to other applications. In other words, SOA is a model in which applications openly present their utilities as services across a network. In this network other applications can request these services in a dynamic and therefore “adaptive” manner.

Let's talk about each layer in details for better understanding.

Adaptive AUTOSAR Applications

At the top layer we can find the new Adaptive Applications (AA). AAs, in contrast to software components (SWCs), are now processes which may be single or multithreaded. Another important characteristic of them is they are now able to be started or stopped at any time. Even though a similar scenario can be done in ClassicAS using partitions, the key aspect lies once again in the static (ClassicAS) vs. dynamic (AdaptiveAS) behavior. AAs can be added (downloaded) on their own, while adding a new partition would require us to reflash the whole software. In addition, AAs are now held together by a familiar, yet completely new entity, the?AUTOSAR Runtime for Adaptive Applications (ARA). This new ARA is made up of application interfaces coming from the building blocks of the next layer, that is, the functional clusters. Moreover, such functional clusters can be either from the Adaptive Platform Foundation or the Adaptive Platform Services. Another key aspect to understanding the ARA is that, in contrast to the?runtime environment (RTE)?and therefore with the ClassicAS, in AdaptiveAS the clients and services are dynamically linked at runtime. However, AdaptiveAS also allows options to limit the dynamic behavior in order to decrease the risk of undesired effects. For instance, some of these options include fair scheduling, dynamic memory allocation only in the startup phase, and even fixed allocation of processes to CPU cores. In other words, AdaptiveAS doesn’t forget its target audience and offers planned dynamics.

Functional Clusters

The software of the?Adaptive Foundation?and?Adaptive Services?is presented in the form of functional clusters. Simply, a functional cluster is a set of requirements grouped by the aspect they refer to. These functional clusters are, in a manner, similar to the concept of the basic software (BSW) in the Classic Platform. Their main purpose is to offer functionalities in the form of services to the application. However, being part of the new Adaptive Platform, and in contrast to the BSW, the new functional clusters are now processes, which can be single threaded and multithreaded. Another key feature is the dynamicity vs. the traditional static nature of the BSW. Just as in the ClassicAS, there are needs for non-volatile storage, communication and diagnostics, to name a few, which are taken care of by?non-volatile memory (NVM), Com,?Diagnostic Communications Manager (DCM)?and?Diagnostic Event Manager (DEM). These needs are catered in the AdaptiveAS through functional clusters, such as Persistency, Communication Management and Diagnostic Management.

Machine

The new term, “Machine,” given by the AdaptiveAS is, in simple terms, the entity where the software runs. It is understood that this Machine can be of virtual nature. The actual hardware can in turn host one or multiple Machines.

Operating System (OS)

The new resources like HPC and SOA also call for new prerequisites. One of them is an operating system (OS) capable of meeting their needs (dynamic environment, mix of computing resources). Therefore, the static nature of AUTOSAR OS and OSEK is not well suited for the job. However, instead of defining a new OS, the solution here is to define an Operative System Interface (OSI). The OS must be Portable Operating System Interface (POSIX) compliant. AAs have been given a more constrained interface – PSE51 (some characteristics include: no use of file system, single process) – while the Foundation and Services are allowed to use full POSIX. One may ask, “Why select PSE51?” The answer is simple: to achieve freedom on interference, and to offer portability for existing POSIX applications.

But what about the so needed real-time organization in embedded systems? After all, predictability is of the essence. Luckily for us, scheduling policies for real-time applications are available in the POSIX standard, analogous to the priority-based scheduling from AUTOSAR OS, SCHED_FIFO, SCHED_RR and SCHED_DEADLINE are present and allowed.

No RTE? then how is the communication done?

In the ClassicAS all communications among SWCs must go through the RTE. This is accomplished using ports and connectors. In a similar manner, the interaction between SWCs and the BSW is also done through the RTE using standardized interfaces with the service flag set. However, the BSW communicates with each other using common C calls.

In the Adaptive Platform both adaptive applications and functional clusters are implemented as processes, albeit as was previously stated, the adaptive applications are bound to only use PSE51, which as part of being a more constrained interface, does not offer Inter Process Communication (IPC). If PSE51 does not include IPC, then how can applications interact with one another?

For this new problem, the Communication Management (CM) has been defined. It provides an SOA-like communication – in fact, service-oriented communication (SOC) – for applications and can be exploited for inter and intra machine interactions in a transparent way realized by SOME/IP protocol. This is, in a manner, similar to how one SWC can connect to another SWC in the same ECU or with a SWC in a different ECU.

Functional clusters, on the other hand, are not bound by PSE51 and can use IPC to interact with each other. What is probably more important to note is, how they interact with AAs. In this case there are two options: one library-based (the interface library linked to AA calls IPC), and the other service-based (the process uses CM).

Does AdaptiveAS replace ClassicAS ?

This is still far from the truth. The current landscape of the E/E automotive systems asks for cooperation rather than competition. Right now, the actual next step looks like a hybrid of AdaptiveAS and ClassicAS working together.

The stringent real-time requirements of certain applications fall perfectly into the deeply embedded ECUs covered by ClassicAS, while the soft real-time and high computing power requirements are AdaptiveAS territory.

Differences Between Classic AUTOSAR and Adaptive AUTOSAR

• Classic AUTOSAR is meant to be run in a single- or multi-core architecture. Adaptive AUTOSAR is intended to run on top of and take advantage of HPC architectures.
• Classic AUTOSAR defines an Operative System. Adaptive AUTOSAR only defines an execution context and an Operating System Interface (POSIX, PSE51)
• Classic AUTOSAR is defined in a signal level. Adaptive AUTOSAR is defined in a service manner.
• Classic AUTOSAR is static in nature. Adaptive AUTOSAR offers “planned dynamics” both in application deployment, as well as communications and resources.
• Classic AUTOSAR is meant for the deeply embedded ECUs. Adaptive AUTOSAR is intended for a new generation of ECUs.

Conclusion

Adaptive AUTOSAR comes to life as new requirements and new resources come into the automotive industry. The new requirements, like autonomous driving, vehicle connectivity and constant updates, and the new resources, like high performance computing and ethernet communications, cannot be perfectly fulfilled by the existing AUTOSAR standard and therefore require a new rule set to guide them and set order in what otherwise would be another chaotic scenario. What the original AUTOSAR was to the deeply embedded ECUs, Adaptive AUTOSAR is to the new generation of vehicle computers.

Resources

https://www.autosar.org/standards/adaptive-platform

https://www.lhpes.com/blog/what-is-adaptive-autosar