What Is Adaptive AUTOSAR?

What Is Adaptive AUTOSAR? A Compelling Overview on Current and Future Trends.

The Key to Adaptive AUTOSAR

“Adaptive AUTomotive Open System ARchictecture (AUTOSAR),” “Classic AUTOSAR,” and “High-Performance Computing (HPC)” are some of the terms many people have heard. But what exactly do they mean? Why do they exist? And what is their impact on the automotive industry?

First and foremost: What is AUTOSAR Classic Platform or ClassicAS? ClassicAS is the same old AUTOSAR we have all come to know and love throughout the years. As such, ClassicAS is a standard that tackles the needs and requirements of embedded engine control units (ECUs). Easy enough, right? Then, the reader may ask, “What is Adaptive Platform AUTOSAR (AdaptiveAS)?” AdaptiveAS is, in the same manner, a software standard for the automotive industry. Sounds oddly familiar, right? Here’s the catch, AdaptiveAS addresses a new set of needs different than the usual embedded ECUs.

The Outlook on Future Needs

New functionalities such as environment perception, autonomous driving, vehicle connectivity, and Car as a Service (CaaS), have introduced a new set of problems to the electrical/electronic (E/E) panorama. These new functionalities differ from the ones ClassicAS was designed for. They no longer simply substitute electromechanical systems. They are, for lack of a better description, deeply autonomous and, dare I say it, Intelligent. As such, they are highly complex and have high processing needs. Furthermore, these new functionalities are expected to evolve during the vehicle’s lifetime, in contrast to the not-so-significant changes that a traditional function could have. High complexity, high computing power, faster communications, and continuous updates are, to name a few, the requirements set into stone by these new trends. The technology which enables the new functionalities is already here: ethernet and HPC.

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.

In simple terms, Adaptive AUTOSAR is a new standard made to cover the new needs and new resources previously mentioned. It does so by offering dynamicity at heart and by using the capabilities provided by high-performance computing.

Architecture

AUTOSAR introduced a layered architecture, so it is only natural that Adaptive AUTOSAR also uses a well-defined one, albeit with not only small differences but also unique characteristics that make it so perfectly suited for the problems and requirements of a new era. The AdaptiveAS architecture is based on key principles, such as C++ as the preferred language, Service Oriented Architecture (SOA), dynamicity, and inherent parallelism.

But what is SOA, anyway? SOA can be defined as a model in which services are made available across a network. The services can reside either in the same ECU or externally in another ECU. Furthermore, the services are self-contained units; the clients (the users of services) are independent of 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., be 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.

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 that may be single or multi-threaded. 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 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 put, 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 to in the AdaptiveAS through functional clusters, such as Persistency, Communication Management, and Diagnostic Management. Although similar in purpose, they differ in nature. For instance, Persistency is based on key-value and stream storages, and Communication Management drops the signal-based approach in favor of a service-oriented strategy.

Machine

The new term, “Machine,” given by 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.

Operative System

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 of 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.

Following the architectural definitions of adaptive applications and functional clusters, one can easily make an analogous comparison to the software components and the basic software of the ClassicAS. A following point to ask would be, “How do they communicate with each other?” 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.

We can use the precedent laid out by the Classic Platform in order to understand how AdaptiveAS will manage the interactions. 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, 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. 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).

What Does This Mean for AUTOSAR Classic Platform?

Although one may think AdaptiveAS sounds like the next step in evolution or that ClassicAS days are now numbered, that 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. After all, the old saying “the right tool for the job” still rings true; you cannot use a screwdriver where a wrench is needed, and you shouldn't use a wrecking ball where a hammer is better suited. Similarly, 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. A useful analogy to understand such couplings is that of the nervous system, which is made up of various neural circuits that cater to different needs. For instance, certain stimuli lead to instantaneous actions known as reflexes (which could be said to be “low processing” and “quick reactions”), while other neural circuits form consciousness and awareness (“high processing” and “slow reaction”). In the same manner, an intelligent automotive vehicle could have a deeply embedded ECU taking care of the anti-lock braking system (ABS) – similar to reflex – while another ECU executing the self-driving functionality commands the brakes to activate – similar to awareness.

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 encased 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.

Following our previous statements and explanations, we can determine that Adaptive AUTOSAR and Classic AUTOSAR are different in the manner that each targets a distinct set of ECUs, with separate needs and resources allocated to them.

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 at 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 deeply embedded ECUs. Adaptive AUTOSAR is intended for a new generation of ECUs.

Lastly, Adaptive AUTOSAR is not meant to replace Classic AUTOSAR; both are meant to co-exist and cooperate in satisfying the needs and challenges presented to the automotive industry. Determining which one to use may not be an easy task, but it can be started by answering the following questions: What kind of computing power do we need? What are our timing requirements? And what degree of dynamicity will be required for our application?

Interested in Learning More About AUTOSAR for Your Organization? Register for Our AUTOSAR Training Today! 

Further reading and references

• What does the foreseeable future of an AUTOSAR engineer look like 
• The Top Five Considerations When Migrating to AUTOSAR-based Software Development