The automotive & mobility industry is going through a change not seen for the past 100 years. And in the recent past we have seen the impact the CASE – Connected, Autonomous, Shared and Electric trend has had brought to the industry. As technology evolves and the software content in a vehicle increases dramatically the new trend of Software Defined Vehicles (SDV) is here

An SDV is envisioned as a vehicle that will be continuously connected to its environment enabling real time data exchange. This will enable feature and App enhancement in real time. Drivers will download and install the features as per their choice and requirements and the new features will be readily available to the users. For vehicle manufacturers this software defined approach means a change in the entire architecture of the vehicle for OEMs. This in turn means the development of an end-to-end scalable, updatable & modular architecture. Traditional distributed architectures with separate Electronic Control Units (ECUs) for each function are transitioning to more complex Central Computing Architectures

This article discusses how deploying Service Oriented Architecture (SOA) concept for Autonomous Driving (AD) development in the Central Computing Architecture environment for SDV proves is the right choice. Especially since many components like Fusion, Situation Analysis, Path planning etc. are reused across applications.

We will discuss 6 key aspects of deploying SOA for AD development in a Software Defined Vehicle environment/ program i.e.

• What challenges must be overcome for AD System development in SDV?
• Why SOA is the natural choice for AD development in SDV?
• What is SOA architecture?
• What are the benefits of deploying SOA for AD development in SDV?
• How to transform classic software to SOA?
• How to execute verification in SOA?

Let us look at each aspect in detail.

What challenges must we overcome for AD System development in SDV?

• Customer Needs: AD features required by the consumer will be based on operational needs and affordability. Thus, in the SDV environment vehicle manufacturers (OEMs) will have to provide features on-demand to be competitive
• Safe and Reliable Systems : In existing distributed architecture of AD development, the sensor and ECU network is very complex and enhanced features in the SDV for e.g. over the air updates (OTA) will require inputs from multiple ECUs thus increasing complexity of the safety and reliability of the system.
• System maintenance : The AD system would require continuous updates based on new innovations, findings, standards, and policies. It would be a challenge for OEMs to keep consumers updated with the latest Software.

Why SOA is the natural choice for AD development in SDV?

The primary goal of SDV is to be configurable without impacting safety, security, and performance of the system. The Non-SDV AD system architecture was simple & decentralized which means the below challenges must be overcome in the SVD environment:

• Disabling/enabling individual ECUs in the distributed system would have lot of operational challenges such as startup time, power consumption, zonal complexity etc.
• Using common SW components between ECU’s would require high data bandwidth, else redundant SW modules will take up more computational power.
• Updating or modifying a single feature may have to be done across many ECUs in the distributed system. The ECU hardware may need to be changed if it requires Higher CPU/Memory configuration.

Figure 1: Complex Resource Sharing in Distributed Architecture

Deploying SOA with centralized architecture becomes a natural choice to ensure smooth functioning of the AD features and compliance to various Functional safety and Cybersecurity standards like ISO 26262, ISO 21434, SAE-J3061.

SOA is a software designed approach emphasizing on building applications which can be independently deployed and can communicate with each other through well-defined APIs. Architecture and the benefits are discussed in further sections.

What is SOA architecture?

The basic SOA architecture consists of:

• Registry : Keeps tab of all the services available. Provide this information to services when requested.
• Provider Services : Services which provide certain functionality to the consumer services.
• Consumer Services : Services which asks and uses functionality from the provider services.

Classification of Services are based on their functionality and accessibility. E.g., Method call which are initiated by other services, Events which are time synchronized or asynchronized , etc. There are different ways in which the services interact with each other such as Subscribe/Publish, Request/Respond, Fire & forget etc. Below Diagram is an example of Registry based service discovery with Request-Respond interface.

Figure 2: SOA Architecture

What are the benefits of deploying SOA for AD development in SDV?

• Configurability : Individual or multiple functions can be selected as per the need of Driver or OEM. This enables OEMs to enhance the customization capabilities at software level. E.g., Driver selects Auto Park feature & Traffic Jam assist and deselects Highway Assist if he primarily driving in Urban conditions. He may also subscribe to Highway Assist for a short period when he requires so.
• Modularity and Reusability : SOA allows for the development of AD-ADAS features as independent, reusable services, which makes it easier to develop, test, and deploy new features, as well as integrate with other systems. E.g., Common services such as Object Fusion, EGO path prediction etc., which many features such as AEB, ACC, Auto Park, etc. are using.
• Scalability : The modular design of SOA enables AD-ADAS systems to be scaled up or down as needed, allowing for the deployment of new features and increased functionality as technology evolves. E.g., Initially a Classical ACC can be provided which may later be added with functionalities such as Stop & Go. Auto-Park can be scaled up to Valet Parking etc.
• Flexibility : SOA enables AD-ADAS systems to be flexible and adaptable, allowing for changes and updates to be made without affecting the entire system. E.g. System configuration can be of vast different combinations based on various factors such as different geographies, different applications (commercial / passenger), different vehicle programs etc.
• Ease of Maintenance : The modular design of SOA makes it easier to identify and fix bugs and make other updates, reducing maintenance costs and improving system stability. E.g. The customer need not go to the Service station for updating and upgrading the system.
• Interoperability : SOA provides a standardized way for services to communicate with each other, enabling AD-ADAS systems to be integrated with other systems and reducing development time and costs. E.g., Integrating the same system with different Vendor products for concept as well as production with minimal effort.
• High Resource Availability : System will be able to utilize a larger resource pool for computation, memory requirements and bandwidth requirements as all features won’t be active at once. E.g., Highway pilot and Auto Park features are only required in different non overlapping scenarios. Thus, they will individually get complete resources when they are operational.

How to transform classic software to SOA?

Transforming the classical SW to an SOA involves a few key challenges viz. SOA framework definition, grouping of functionalities, defining of services etc. The trick lies in understanding the data flow pipeline from a data driven perspective. The services are then tuned such that they work in synch to make the processed data reach its destination. The lifecycle of a service and its structure is defined based on various parameters such as standards and compliance policies. Target System-On-Chips (SOCs) Operating System may also influence the SOA architecture.

 

Below are two diagrams showing Classical and SOA based Lane Departure Warning (LDW)  and Lane Keep Assist  system (LKA)

Figure 3: High-level LDW/LKAS system in Signal based Architecture

Figure 4: High level SOA of LDW & LKAS

The SOA development workflow

• Requirements Analysis: The first step is to understand the requirements for the system and ensure that these requirements are well defined and can be verified.
• Service Design: The services in the system are then designed, considering the requirements and the overall architecture of the system.
• Service Implementation: The services are then implemented, following best practices for software development, such as coding standards and testing procedures.
• Service Integration: The services are then integrated into the system, verifying that they communicate with each other as expected.
• Service Testing: The individual services are then tested, to ensure that they meet their functional requirements and work as intended.
• System Testing: The system as a whole is then tested, to ensure that it meets its overall requirements and works as a cohesive unit.

How to execute verification in SOA?

SOA based verification must have a different approach than traditional verification of AD-ADAS systems. The primary difference is that verification is not just done at application or feature level but also goes deeper to a level where the services interact with other services. Thus, the testing setup must have features which not only give it control access to the services but also has enough information (real time) on the SOA framework status.

SOA-based verification is particularly important for complex systems, such as Advanced Driver The verification process can also help to identify any potential performance bottlenecks and security vulnerabilities, allowing developers to address these issues before the system is deployed. By verifying the system in this way, the overall quality of the system can be improved, and the confidence of the end-users in the system can be increased.

SOA Test Framework:

Conventional Test framework cannot be easily adapted to test the SOA based system for many reasons.  Conventional Test framework do not have flexibility to change their interfaces from signal-based verification to serviced based data driven verification.

The following must be considered whilst building a test framework for SOA based Autonomous system.:

• A typical test setup must be able to provide a framework where all services can be executed without any hardware dependency.
• The framework must be able to verify the system at various levels of granularity such as service level, integration level and system level.
• It should be able to monitor the critical parameters of individual services such as service status, inward and outward requests, CPU and memory utilization etc.
• As part of verification, it is also critical to monitor the various stages in lifecycle of a service from such as registering, publishing/subscribing and terminating the service execution.
• An SOA testing for AD-ADAS would be primarily carried out at SIL/MIL level. It must also be done at HIL/VIL for certain verifications which can only be conducted at ECU/System level.
• As SDV will focus on configurability of individual or group of features, the framework should be able to configure itself for various combinations.

Thus, the SOA Test framework would also be based on an SOA environment.

Further it should have additional capabilities for validation of below parameters:

• Service Functionality : Functional testing of the service with Data driven mechanism. Simulation of other domains (ex: chassis) dependent services will also be required.
• Configuration adaptability : Framework should be able to configure the SUT as per conditions of the test scripts.
• Resource usage : Log and monitor Memory, CPU and Bandwidth usage at individual service level.
• Service Availability : Monitor the demand from various consumer services and verify whether the demand was met or not.
• Service Conflict : Check whether services have unique parameters and do not collide with other services to provide data.

Figure 5: SOA Verification Setup

In summary SOA is the clear and go to option for the advantages and ease it provides for smooth transitioning to SDV. This adaptation requires changes in various processes of development and verification. A robust test framework which can handle data driven services is the only key to successfully validating the AD-ADAS system. As the trend of SDV progresses it will bring up new challenges and solutions, it will be very interesting to see how engineers leverage SOA for the development of AD systems in this environment