CLASSIC AUTOSAR TO ADAPTIVE AUTOSAR

APPROACH FOR MIGRATION AND CO-EXISTENCE

CLASSIC AUTOSAR FOR ADAPTIVE AUTOSAR:
APPROACH TO MIGRATION AND COEXISTENCE

The approach to be taken is by and large influenced by :

Architecture of Classic AUTOSAR Code
- A well-structured Classic AUTOSAR code simplifies the conversion process significantly
- Achieving modularity, which is the essence of AUTOSAR, becomes easily realizable
- Redesigning Services to POSIX based APIs and Services
- Since the legacy code is structured using C language, which need to be converted to C++ code aligned to service oriented architecture. A careful decision will be taken in consultation with all the relevant stake-holders as to how much of the existing code has to be retained
Level of compliance required for the respective product
- The level of compliance and modularity can also lead to various migration scenarios
Tools
- The migration requires tool support on both system and ECU architecture level. Though AUTOSAR provides formats for standardized Adaptive AUTOSAR data exchange for the seamless interoperability of different tools, the capability of the existing tools to support Adaptive AUTOSAR, is also an important factor

Figure 2: Classic AUTOSAR to Adaptive AUTOSAR : Approach for Migration and Coexistence

Adaptive AUTOSAR

Classic AUTOSAR

CLASSIC AUTOSAR TO ADAPTIVE AUTOSAR:
ANALYSIS APPROACH

Various possible scenarios for migration were analyzed and for evaluating the feasible legacy to AUTOSAR migration scenario, the following steps were performed for each of the identified scenario

Capture the advantages in each of the scenarios
Analyze the re-usability considering
- How to define which ECUs will utilize Classic AUTOSAR and which will use Adaptive AUTOSAR
- How to design and configure a system where Adaptive and Classic AUTOSAR co-exists
- Using C++ 14, 17 contrast to C in Classic AUTOSAR
- Using APIs and Services contrast to only services in Classic AUTOSAR
- Using POSIX OS contrast to static OS in Classic AUTOSAR
- Driver layer specified by the individual OS vendors contrast to MCAL in Classic AUTOSAR
- Operating system and hypervisors
- System Design
- Classic Signaling meets Service Oriented Communication
- Signal to service communication

Migration to Adaptive Autosar from a Classic AUTOSAR architecture could have better performance for ROM, RAM and CPU utilization while substantially increasing in reusability and similar reliability across multi-core ECUs/products.

CLASSIC AUTOSAR TO ADAPTIVE AUTOSAR :
A SCENARIO

ADVANTAGES

Adaptive AUTOSAR establish how a new way of working enabled seamless software updates through service-oriented architecture (SOA).
Classic AUTOSAR is a self-contained firmware platform, whilst Adaptive AUTOSAR is not trying to be complete in the sense to create a full SOA. An SOA is a software platform where Services is central. A service is provided by a Service Provider and consumed by a Service Consumer. The connection between a Service Provider and a Service Consumer is set up by a Service Broker dynamically in run-time. The Service Consumer does not necessarily know where the Service Provider is located. And hence, the software platform is dynamic and can be partially updated without affecting the system.
An Adaptive AUTOSAR application is interfacing an Operating System that provides with the PSE51 API subset of the POSIX standard. This does not mean that the OS can only be PSE51, it means that the Adaptive AUTOSAR application can only use this API. The OS can still be a full PSE54 OS. The benefit of this approach is that all POSIX compliant applications and libraries can be modeled. And hence, reused and deployed in any Adaptive AUTOSAR software platform.

Figure 4: Classic to Adaptive AUTOSAR

CLASSIC AUTOSAR TO ADAPTIVE AUTOSAR: A SCENARIO FOR MULTI-CORE ARCHITECTURE FOR CO-EXISTENCE (1)

Figure 5: Scenario 1

CLASSIC AUTOSAR TO ADAPTIVE AUTOSAR: A SCENARIO FOR MULTI-CORE ARCHITECTURE WITH CO-EXISTENCE (2)

Adaptive AUTOSAR establish how a new way of working enabled seamless software updates through service-oriented architecture (SOA).
Interfacing Signal based architecture of Classic AUTOSAR with Adaptive AUTOSAR’S Service Oriented Communication
- Vehicles are increasingly becoming software - heavy and complexities are continuously increasing. The architecture must be designed for better efficiency. The central gateway and backbone-based architecture is more software-focused and offers – Updateable features, External communication and Diagnostics. Some examples of SoC are: DHCP, Bluetooth, Bonjour etc..
- LTTS propose the Scalable Service Oriented Middleware over IP which includes: Serialization, Remote Procedure Call, Service Directory, Publish/Subscribe and Segmentation of UDP Messages. This supports both IPC and External Communication.
System Design
- The Mixed Unallocated Logical Design speaks use of the Adapter to translate from classic signaling to a service-oriented communication.
- The Mixed Deployed Model is typically one where the Adaptive and Classic AUTOSAR co-exist.
Signal 2 Service (S2S)
- This starts with the ECU extract from where service interfaces can be derived, and applications can be defined. The same will extract signal packing which enhances IPC.

CLASSIC AUTOSAR TO ADAPTIVE AUTOSAR:

A SCENARIO FOR MULTI-CORE ARCHITECTURE WITH CO-EXISTENCE(3)

ADVANTAGES

Classic AUTOSAR is a self-contained firmware platform, whilst Adaptive AUTOSAR is not trying to be complete in the sense to create a full SOA. An SOA is a software platform where Services is central. A service is provided by a Service Provider and consumed by a Service Consumer. The connection between a Service Provider and a Service Consumer is set up by a Service Broker dynamically in run-time. The Service Consumer does not necessarily know where the Service Provider is located. And hence, the software platform is dynamic and can be partially updated without affecting the system.
POSIX comes in different compliances from PSE51 to PSE-54. Here, OS is not defined by AUTOSAR. Adaptive AUTOSAR use PSE51. This is to ensure ease in accessing the file system and move the application.
Various research shows - Hypervisors has its origins in either micro kernel or virtualization.
Here 2 types of Hypervisors can be defined:
- Type-1: Which runs on the bare-metal/hardware, focused on Automotive
- Type 2: Which runs on a host OS – LINUX or Windows, focused on embedded systems. Here, Hypervisors can be para virtualized or native virtualized
An Adaptive AUTOSAR application is interfacing an Operating System that provides with the PSE51 API subset of the POSIX standard. This does not mean that the OS can only be PSE51, it means that the Adaptive AUTOSAR application can only use this API. The OS can still be a full PSE54 OS. The benefit of this approach is that all POSIX compliant applications and libraries can be modeled. And hence, reused and deployed in any Adaptive AUTOSAR software platform.