AUTOMOTIVE SOA
FOR SOFTWARE-DEFINED VEHICLES

Download The WhitePaper

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.

Drivers are looking for a different experience. They are looking for freedom to customize their driving experience with downloadable software from app stores. They are begging for the smartphonization of the driving experience.

But this is not possible with today’s coupled vehicle SW and HW architecture. Today’s automotive software development processes yield monolithic blocks of code that are built, tested and then flashed into the ECUs on the production line. Changing any functionality results in a tedious and costly process of re-integration, re-testing and re-flashing for which today’s development cycle and production lines are not built.

Automotive SOA (Service-Oriented Architecture) revolutionizes how vehicle SW is built. It incorporates a group of components to act as middleware between applications that represent services and the OS (operating system). This middleware decouples the individual software components (SWCs) from the underlying HW – enabling SW portability inside a vehicle’s architecture. The adoption of a Secure SOA Framework will simplify the vehicle’s development process from concept through development all the way to deployment and maintenance.

Automotive Development with Automotive SOA

Perspectives by audience

  • Software Architecture
  • Supply Chain
  • User Experience

Software architecture and processes are key challenges for the development and deployment of advanced customizable automotive software today. With the current complex distributed system comprising more than 100 Electronic Control Units (ECUs) per vehicle, the vehicle software system forms a monolithic block of code that is very complicated to maintain and modify.

Currently, there is no support for the standard computing environments that would allow the automaker, and later an owner or driver to easily install apps to the vehicle. Even if this support would exist, including a library of available apps, the current security mechanisms in the automotive software would not allow for sufficient isolation of these apps to prevent them from being used as stepping stones to penetrate safety-critical systems of the vehicle.

Growth of functionalities, with the goal of fully autonomous vehicles, will only make the problem worse.

In a Service-Oriented Architecture, communication among services occurs through a level of SW with well-defined interfaces, known as middleware. Middleware supports the abstraction from the specific HW environment and greatly simplifies SW development and testing. It provides the basis for a truly distributed development environment that can and will involve third parties.

Automotive SOA takes the fundamental SOA concept of service providers and service consumers and translates them to the automotive software environment. Every ECU uses layers of abstraction to hide the complexities of network topology, communication, and implementation. Interactions between software components are therefore no longer hard-coded. Every new service is represented in a directory from where its functions can be offered and where it can find the services that it needs to use. Binding between services is not fixed and can be changed dynamically.

Multiple different operating systems can run in parallel on each ECU, supported by a hypervisor: popular OSs like Windows, MacOS, iOS, Android, etc. can be supported to enable the installation of standard applications and 3rd party apps.

While downloading malicious or buggy apps to a smartphone may impact the function of the smartphone or the privacy of the user, downloading such inappropriate apps into a car can impact driving safety and have fatal consequences.

Therefore, communication between services is restricted to mandatory interactions. Everything else is blocked. Highly secure OTA download and deployment of SWCs prevents any malicious or accidental attack vectors from impacting the safety of the car.

Automotive SW development is a complex work-split between the OEM and a large number of suppliers, with each player providing ECUs with their specific SW or Firmware (FW) implementations. This entire set of HW and SW needs to be integrated and tested to build the overall vehicle system. The lack of modularity makes any modifications to the SW system a complex and slow task which requires re-building and re-testing, resulting in today’s lengthy time to market.
Automotive SOA enables an unprecedented degree of modularity where services can be independently implemented and tested already during the development stage.

This complexity reduction will lead to significantly decreased development costs and much quicker integration cycles. Fewer errors will be created and according to industry estimates, the number of testers will decrease from several hundreds to less than 100. This will result in a significant acceleration of correction cycles, reducing them from several months to just a few weeks.

Automotive SOA is based on well-defined abstract interfaces between all the services. This makes the implementation independent of any particular computing platform and allows the creation of a simulation environment that supports SW integrating and testing instead of the target platform.

The SW configuration of each car is dynamically created at startup of the system. Therefore, for any car model, all available services are stored in a repository and published in the directory. The binding of the services is dynamic and can change according to local HW and SW modifications. The services themselves can be modified on the fly during the manufacturing process on the production line or even after the car has left the factory.

The work-split between OEM and suppliers will be redefined: the main responsibility of the OEM remains defining the architecture, and the creation of the framework by extension, while the service implementations can be performed by any suitable party.

3rd party application developers, who may not be part of the classical automotive ecosystem, can create new services for the vehicle without in-depth knowledge of the HW configuration. Opening the app market to new entrants will increase competition and improve capabilities and expand applications supply instead of relying on a limited number of OEM or pre-defined developers. Consumers will be able to enjoy an experience in their vehicle similar to their smartphone with this broadened developer market.

Today’s drivers can instantly and independently customize their computers, smartphones and tablets to their needs. They are starting to expect the same from their cars and this is leading to the trend of vehicle smartphonization. Drivers want the ability to add new functions (i.e. ADAS functions, games, videoconferencing SW). While the physical infrastructure to provide greater interactivity and communication are available in any modern car, the SW architecture of today’s vehicles usually cannot support much beyond specific predefined use cases decided by the OEM or Tier 1.

With the emergence of autonomous vehicles, requirements for car customization will grow. Their interior will more likely resemble a living room or home office in place of the driving-focused experience we have today. Evolving demands means that audio and video-based entertainment functions, video conferencing and professional workstation features will require support via high-speed wireless external communication.

Nowadays, the majority of cars are shared only amongst family and perhaps friends, but this is already changing with the advent of commercial car sharing. This will become only more popular with autonomous vehicles and shared cars. Cars will need to meet the preferences of any user, whether they will want to be entertained while commuting or work or rest while they travel. Cars will be instantly customized by portable digital identities as soon as a particular user logs their profile into the car.

An unfortunate reality of software development is that software in any computing environment can always contain bugs. The number of residual bugs grows as the size of the SW packages increases. We have grown accustomed to regular software updates to patch fixes and add new functionality in our everyday environments and devices, but not in our cars.
If a bug is severe enough to impact driving or functional safety, automakers have traditionally initiated a very expensive and reputation-impacting recall program to fix the software in an authorized garage – usually only as a last resort.

The standard Over-the-Air (OTA) updates approach used in our smartphones and computers is not available in a vehicle as it could be utilized as an entrance to safety critical functionalities. However, with Automotive SOA, the safety critical applications are securely separated in partitions and a unique framework prevents malicious code from spreading through the vehicle. Secure OTA updates will provide software updates from any location as soon as a new release is available.

Security Partition
Lockdown Core
Lockdown Core
GuardKnox patented Communication Lockdown 3 layer approach
SOA Port
The SOA port is the enabler of the communication between each 2 components, in other words it is the protocol, the agreed-upon language the two components share. The SOA port has a layer for specific implementations for “translations” between the languages (for specific HW, OS, protocols) to the common language.
Security Monitor
The SOA security monitor collects analytics and diagnostics data from other components to ensure the safe and secure operation of the device.
SOA Port
The SOA port is the enabler of the communication between each 2 components, in other words it is the protocol, the agreed-upon language the two components share. The SOA port has a layer for specific implementations for “translations” between the languages (for specific HW, OS, protocols) to the common language.
Crypto
The cryptography module is a security feature provided to the system as a service or application.
SOA Port
The SOA port is the enabler of the communication between each 2 components, in other words it is the protocol, the agreed-upon language the two components share. The SOA port has a layer for specific implementations for “translations” between the languages (for specific HW, OS, protocols) to the common language.
SOA Node Manager
The SOA node manager is the manager of a single partition, offering local management.
MANAGEMENT PARTITION
Health Monitor
The SOA health monitor collects analytics and diagnostics data from other components for ongoing analysis.
SOA Domain Manager
The SOA node manager is the manager of a single partition, offering local management.
SOA Node Manager
The SOA node manager is the manager of a single partition, offering local management.
PARTITION 1
Application SOA Port
The SOA port is the enabler of the communication between each 2 components, in other words it is the protocol, the agreed-upon language the two components share. The SOA port has a layer for specific implementations for “translations” between the languages (for specific HW, OS, protocols) to the common language.
SOA Node Manager
The SOA node manager is the manager of a single partition, offering local management.
OS1
PARTITION 2
Application SOA Port
The SOA port is the enabler of the communication between each 2 components, in other words it is the protocol, the agreed-upon language the two components share. The SOA port has a layer for specific implementations for “translations” between the languages (for specific HW, OS, protocols) to the common language.
Application SOA Port
The SOA port is the enabler of the communication between each 2 components, in other words it is the protocol, the agreed-upon language the two components share. The SOA port has a layer for specific implementations for “translations” between the languages (for specific HW, OS, protocols) to the common language.
SOA Node Manager
The SOA node manager is the manager of a single partition, offering local management.
OS2
Hypervisor
Secure Separation Kernel
Hardware
Component of GuardKnox SOA Framework

Secure SOA Framework

Learn More

The SOA Vision

PERSONALIZATION BY THE NUMBERS

SOA for automotive app store
1983

The year Steve Jobs envisioned the app store

SOA for automotive play store
250

Android apps
for your car

SOA for automotive phone apps
8Million

Phone apps
in 2020

SOA for automotive tesla
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.

CURRENT AUTOMOTIVE SW ARCHITECTURE

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.

AUTOSAR and Automotive SOA

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:

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.

REDUCING THE RISK TO ALL OF US

The software-defined vehicle is here, and it will be the new standard for the future car. Secure by design, that is, incorporating cybersecurity into the design of the car, will allow OEMs to securely provide customized user experiences for diverse drivers and their changing preferences without downtime or visits to the dealership.

  • Redefining Automotive Software Development

  • Read More
  • The Not-so-long Road to Automotive SOA

  • Read More
  • The Brave New World of Automotive SOA

  • Read More

FAQ SECTION

WANT TO HEAR MORE?

Contact us to speak to one of our SW architecture specialists today

Contact Us