In our previous blogs on Adaptive AUTOSAR (Blog1 and Blog2), we largely addressed its advantages and highlighted the difference between Adaptive AUTOSAR and its Classic counterpart. We also mentioned that both variants of AUTOSAR can co-exist and work together to support faster and more dynamic automotive applications.
The million-dollar question that arises here is, “How will this co-existence be achieved?” The runtimes are different, even the programming language to code classic and adaptive AUTOSAR applications are different, i.e., C and C++ respectively. Our latest blog in the AUTOSAR series attempts to answer this question.
So before, we plunge into the intricacies of achieving this co-existence, let’s refresh our memories on the basic differences between Classic and Adaptive AUTOSAR.
A Comparison Between Classic and Adaptive AUTOSAR
| Classic AUTOSAR | Adaptive AUTOSAR |
| Classic AUTOSAR follows a signal-based communication approach which is achieved by the communication BUS network such as CAN, LIN, etc. | Makes use of Ethernet and SOME/IP as physical medium for service-based communication |
| Ideal for implementation of deeply embedded functionalities | Ideal for implementation of computation-intensive and faster applications |
| Examples include Engine Control, Braking systems, Airbag Control Unit, etc. | Examples include Over-The-Air updates (OTA), Sensor fusion Data processing, Persistence, Dynamic choosing of application packages over run-time of vehicle, etc. |
| Software update at run time is not feasible as communication between the software components are hard-wired | Over-The-Air update is possible as Adaptive AUTOSAR RTE is independent of the applications |
| Replacement of the entire ECU code is necessary for software update in Classic AUTOSAR environment | Adaptive platforms allows removal/update of individual applications in an ECU |
Right in the beginning of the comparison, a term called service-based communication is introduced. This concept of service-oriented architecture (SOA) forms the crux of this blog. Let’s start with this very concept.
What is Service Oriented Architecture?
SOA is a software architecture wherein the applications are designed as both service providers and consumers. This means that each application can produce, capture, process and communicate data. These applications consist of many such services that are essentially functionalities developed to get a particular job done. These services while acting as a provider make their functionalities available to consumers and vice versa. Every service plays a double role!
The idea behind having multiple services is to create a distributed system where the logic is divided into various small services. In order to extract highly complex functions, these simple services are made to interact with each other and utilize their individual functionalities. You see what the design architects did there?!
By combining multiple simple functions in various ways, they can be re-used for various purposes, many of which are not even conceived while designing the applications. In other words, there is no tight coupling between different software and hardware components which promotes flexibility and dynamism.
These services interact with each other using service interfaces. If these services are able to portray dynamism in terms of communicating with other services, it is because of the service interface. The interfaces are defined at an abstract level. The beauty of this abstraction is that it focusses only on the functionality and not on the underlying technology that will be used to implement the communication.
The communication path is defined at runtime. To enable this, a middleware is deployed. The most common example of middleware that is used in the adoption of AUTOSAR adaptive is SOME/IP. This middleware along with Automotive Ethernet makes Adaptive AUTOSAR a dynamic software architecture. We will briefly discuss the collusion of these three components in brief in the subsequent sections.
Terms to Remember:
Service: An abstract description of software functionality that can be made available to a client on request. It’s a self-contained functionality that can be updated and modified.
Service Instance: It makes the functionality of a service interface available on AUTOSAR adaptive platform
Service Interfaces: Describes the capabilities of a service; the services communicate with each
How SOA acts as a Bridge between Classic and Adaptive Platforms
Modern vehicle architecture believes in combining both the AUTOSAR platforms so that their benefits can be tapped efficiently. Adaptive AUTOSAR is mostly opted for applications that are bandwidth intensive such as automated driving or connected vehicle applications. Whereas, Classic AUTOSAR is still the preferred choice for safety-related applications.
When these two AUTOSAR platforms combine, the need for a bridge is felt due to some obvious reasons such as difference in runtime environment and coupling of sensors and actuators. Service-oriented architecture acts as one.
An adaptive AUTOSAR platform is responsible for establishing connection with both the Classic AUTOSAR ECUs as well as the back-end services (connected car application). The diagram below shows a system architecture where Classic and Adaptive AUTOSAR work in tandem.
Whether a software component is implemented as Classic AUTOSAR or Adaptive depends solely on the vehicle architecture. Based on this consideration, the functions are distributed to the control units. For a software component (SWC) implemented as Adaptive, a service interface is assigned to it. In a scenario, where a service from Classic AUTOSAR wishes to interact with a service from Adaptive platform, a middleware such as SOME/IP resolves the incompatibility. Remember the dynamism we have been constantly talking about?!
Another element related to SOA and Adaptive AUTOSAR platform is the introduction of a new ECU communication protocol, Ethernet. Essentially, Adaptive AUTOSAR was conceived to enable a software to be installed during runtime in order to facilitate dynamic software update. As these requirements emanate mostly from applications that require high data speed, Ethernet was introduced for faster inter-ECU communication.
Conclusion
Service-oriented architecture is at the core of making automotive software future-proof in real terms. The dependence between the services, kind of data they exchange, and how they communicate are all defined in a very abstract manner.
From the point of view of the design architect, it is easier to understand the entire system from early stages without worrying about the underlying communication technology or the hardware platform. One ECU interacting with the other does not have to bother about whether it communicates over CAN, LIN or FlexRay. Middleware like SOME/IP handles such issues.
Going by the trends, both Classic and Adaptive AUTOSAR are here to stay, and service-oriented architecture will make sure they do by acting as the bridge.
