AUTOMOTIVE SOA FOR SOFTWARE-DEFINED VEHICLES

AUTOMOTIVE DEVELOPMENT WITH AUTOMOTIVE SOA

As OEMs, Tier 1s and the automotive industry as a whole shift their focus to the driver experience. Software applications have become key differentiators and epitomize the car’s evolution to a smartphone on wheels.

Actevia Team has Designed SoA architecture and developed prototype for Tier-1s with the aim of transitioning Classic AUTOSAR based application to Adaptive AUTOSAR applications. – Design of Inter-ECU and Intra-ECU Communication model.

  • Design of Inter-ECU and Intra-ECU Communication model.
  • Using FIDL to generate code skeletons
  • Porting non-adaptive applications to Adaptive Application using Publish-Subscribe model with minimal changes in Business Logic of applications.

THE SOA VISION
PERSONALIZATION BY THE NUMBERS

1983

The year Steve Jobs envisioned the app store

250

Android apps for your car

8 Million

Phone apps in 2020

78%

Of Tesla Model 3s configured online in 2018

Hardly any two smartphone configurations resemble each other after two users spend even just a few minutes installing their preferred apps, so why should car configurations be any different? An item as personal and important as a vehicle should lend itself to functioning according to the user’s preferences. For example, while some people may be enthusiastic about voice control, others will be reluctant to talk to their cars and prefer using buttons, knobs and touchscreens.

A car is growing beyond a means to travel between two points to an experiential environment with the flexibility to fit personal preferences of drivers and passengers. In the future, user profiles will allow drivers to customize the services of any car to their preferences. Automotive SOA delivers this key flexibility securely by decoupling the SW-based services from the HW configuration of the car.

The vehicle network though cannot be restricted to internal communication within the car. Cars must communicate autonomously with their environment (V2X). In the future, cars will communicate with the road infrastructure to be informed about driving conditions and possible hazards. They will communicate with other cars (V2V) to determine precedence at intersections or for platooning. They will communicate with Pedestrians (V2P) to protect them from potential human driver error. They will also download software Over The Air for updates and upgrades of the vehicle’s software system.

CURRENT AUTOMOTIVE SW ARCHITECTURE

The complex interconnection of a modern vehicle’s sensors and actuators no longer allows any direct wiring in the vehicle. Instead, ECUs are distributed across the vehicle with functionalities determined by their respective applications. These ECUs are connected to centralized control systems through digital communication media.

This strong coupling of software components has led to monolithic SW systems. Whenever one SWC is changed a complete re-testing of the entire system is required rather than just testing this particular SWC, in order to make sure no unexpected side effects will occur.

SWCs have been written for a particular SW system on a particular computing platform. Therefore, reuse of SWCs and cross-platform support is difficult to achieve and the same function has to be implemented over and over again if required in a different context.

With the increasing complexity of SW systems, the scalability limits of integration and testing have been reached with this legacy approach.

Waterfall of problems in current SW development process

AUTOSAR AND AUTOMOTIVE SOA

Recognizing the fact that the increasing SW complexity requires a service-oriented approach, AUTOSAR published its first version of AUTOSAR Adaptive in 2017. In contrast to the classic approach, the adaptive platform not only provides specifications but also implementations, including the POSIX-based OS and basic applications. Furthermore, the platform contains some SW development tools.

While AUTOSAR adaptive can be considered a step into the right direction a lot remains to be done in order to arrive at a truly Service-Oriented Architecture.

THE PATH TO AUTOMOTIVE SOA ​

A lot of software has already been implemented on the basis of AUTOSAR Adaptive. Any new SW architecture has to incorporate these existing implementations until they can be replaced gradually by newer implementations when needed.

The same is true for HW components. Many cost-optimized simple ECUs will continue to be installed in new vehicles. They have to be supported by a new SW architecture. However, the logical interfaces towards these ECUs will be encapsulated by the Automotive SOA components in order to reap the benefits of the new architecture.

The Automotive Service-Oriented Architecture is part of the evolution towards a Zonal E/E Architecture which comprises the following aspects:

Ethernet Backbone

Moving from the legacy bus architectures to a modern high-speed Ethernet communication network

Wiring Optimization

Consolidation of ECUs together with new topologies for the vehicle networks to reduce the needed cabling length, weight, and cost to a fraction of what it currently is.

Hardware Consolidation

Consolidating multiple functions that are today served by separate ECUs into ECUs that are multi-functional

Software-Driven SOA

Vehicle software architecture is evolving towards modular software for flexibility, security and agility

Four steps can be envisaged for the introduction of SOA into the automotive production processes:

Untangling the vehicle architecture:

The first target for architectural change will be the introduction of universal microprocessor-based ECUs. They have the performance and memory to support sophisticated applications for IVI and other demanding services. Applications or services run in dedicated partitions, on top of standard operating systems, including partitions for AUTOSAR SWCs.

Message router supporting legacy ECUs:

For the support of low-performance legacy ECUs their interfaces have to be adapted and messages routed properly, including those of AUTOSAR. A fast HW router solution with both legacy and Ethernet interfaces can either be integrated into high-performance universal ECUs or form a stand-alone solution.

Domain controller for external communication:

Connected and autonomous vehicles have strong needs for external communication. All this communication has to be highly secure to prevent malicious actors and SW from compromising the vehicle’s safety. A dedicated domain controller, physically separate from other ECUs is introduced to handle the external communication.

Low-cost MCU-based ECUs:

Legacy low-performance ECUs will become technologically obsolete over time. With more and more powerful microcontrollers ECU consolidation will become feasible and, at the same time, allow a consistent implementation of the SOA framework across all ECU types.

GET IN TOUCH

We are eager to customize our engagement models to suit your needs for building more resilient, sustainable and inclusive future. Let us know how can we help you?