How Can We Design And Configure Systems Where Adaptive And Classic AUTOSAR Co-Exist?

On 9th November 2020, KPIT, in association with Automotive World (Mobex), organized a webinar on ‘How can we design and configure systems where Adaptive and Classic AUTOSAR co-exist?’.

In this webinar, KPIT’s subject matter expert Anders Kallerdahl explained the design and configuration of systems where Adaptive and Classic AUTOSAR co-exist. Also, he discussed the main differences between them and the use cases for Adaptive AUTOSAR.

To know the discussion points about this webinar in under 5 minutes, read the perspective below.

Speakers:

Anders Kallerdahl, Subject Matter Expert, KPIT

As the need for high computational power for proliferating data-intensive applications in autonomous, electric and connected vehicles mounts, the SoC processor is found wanting. The challenge is to execute applications of different criticalities and ASIL while designing and preserving segregation between apps. This is where Adaptive AUTOSAR comes in. However, safety- and hard real-time critical systems in-vehicle continue to operate on Classic AUTOSAR.

KPIT’s subject matter expert Anders Kallerdahl explains how Adaptive and Classic AUTOSAR can co-exist in a system while tracing the:

Evolution of E/E Architecture

• Traditional Distributed Architecture is based on separate ECUs for specific functions so there is limited functional integration. Characterised by low speed networks given low communication needs, such system design is hardware-centric. One drawback — if the central ECU system goes down, the vehicle follows.
• Cross Domain Centralised Architecture where the gateway ECU is divided into domains – chassis, body, infotainment etc. Increased software complexity mandates increased communication which enables cloud connectivity. The high-speed bus as backend network for enhanced communication and Service Oriented Architecture is mainly focused on Infotainment and Telematics.
• Central Computer-based Zone Architecture centralises functionality into specific high performance ECUs in the middle. Characterised by domain-independent Central Computer, Zone ECUs, Gigabit networks and new tech, the features necessitate deep cloud integration to facilitate OTA updates etc.

Deployment of AUTOSAR in the New Architecture

• Reliable ECU with classic AUTOSAR: Hard Real-time requirement ECUs that communicate with the upstream domain controller comprises the bootloader downloads software from the server and the V2G (Vehicle-to-Grid connection).
• Performance ECUs with Adaptive: Adaptive platform with Hypervisors for software downloads, and high-performance hardware-software to enable Gateway-enhanced communication.
• I/O Concentrator ECU with Lightweight AUTOSAR: Due to the requirements of Diagnostics and SOTA and increased software complexity, a pre-AUTOSAR solution with simple signalling, lightweight AUTOSAR with 250 KB and flash download or secure bootloader is needed.

Differences between Adaptive and Classic AUTOSAR

AUTOSAR which represents the consortium of OEMs and vendors that standardize software architecture for ECUs and releases the standards periodically.

There are 3 layers in AUTOSAR architecture that are common to both platforms — Basic Software (BSW), RTE (Middleware) and Application.

Classic AUTOSAR comprises a specifications to develop embedded software platforms supporting the basic automotive functions. With BSW and RTE abstractions in multi-ECU environments as base, OEMs and vendors can implement basic applications on them. Classic platforms may not interact with components external to the vehicle to configure driving functions.

The Adaptive platform, however, supports basic and advanced cross-domain functions on top of multi-core, multi-ECU and HPC-integrated environments to enable communication between on-board and off-board systems, OTA, remote repair and driving functions etc. What’s key is the Adaptive platform also includes reference implementations of the standard interfaces with focus on specific areas within the standard. It’s expected that the functions of the future with IoT and autonomous driving will be shouldered by the Adaptive standard.

Other differences span the

• use of C++14 in Adaptive platforms in contrast to C in Classic,
• availability of two types of interfaces (services and APIs) in Adaptive versus only services in Classic (through BSW),
• the POSIX OS in Adaptive versus static operating system in Classic
• driver layer in Adaptive is specified by the individual OS vendors while it’s MCAL in Classic.

Operating Systems and Hypervisors

OS is not defined by AUTOSAR. POSIX comes in 4 different compliance classes PSE51 to PSE-54. Adaptive AUTOSAR is to uses PSE51. This is to ensure ease in accessing the file system and move the application.

Research on Hypervisors has its origins in either micro kernel or virtualisation. There are 2 types of Hypervisors
— Type 1 (run on the bare-metal/hardware, focused on Automotive) and Type 2 (run on a host OS – LINUX or Windows, focused on embedded systems). Hypervisors can be native virtualised or para virtualised.

Classic Signalling meets Service Oriented Communication

Since vehicles are increasingly becoming software-heavy, the architecture must be designed for enhanced efficiency. The central-based architecture is more software-focused and offers – Updateable features, External

Communication and Diagnostics. Some examples of SoC are — Bluetooth, DHCP, Bonjour (Apple) etc. KPIT advocates the Scalable Service Oriented Middleware over IP which includes: Serialisation, 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 advocates use of the Adapter to translate from classic signalling to a service oriented communication.
The Mixed Deployed Model is typically one where the Adaptive and Classic AUTOSAR co-exist.

Signal 2 Service

This starts with the ECU extract from where service interfaces can be derived and applications can be done. The same tool will extract signal packing. This enhances IPC.

KPIT’s Adaptive Platform – KSAR

KPIT has developed some use cases for KSAR – its Adaptive platform. This leverages SOME/IP, Software Updates capabilities and Adaptive Diagnostics test frameworks all of which are ready. Many projects are Gateway projects where 20-30 Classic outcomes need to be consolidated into 1 platform and this is under development. KPIT is developing its own Classic AUTOSAR platform along with its own OS. This is characterised by:

• ARA Middleware for Platform Foundation & Services
• Supported on POSIX OS like Yocto Linux and QNX
• QEMU based Virtualization for Parallel Development
• Ready port available on popular SoC platforms such as TI TDAx, Qualcomm, Xilinx Ultrascale
• and Renesas R-CAR to name a few
• C4K Adaptive tooling supported on Windows
• and Linux
• Easy to use C4K Adaptive
• Configuration Editor

click here to watch the webinar