Software Defined Vehicles- A Perspective from Tata Elxsi

Background

Automotive architectures have seen rapid evolution since 2020. Let us examine the factors playing out in this evolution:

• Traditional functional domains like Body, Chassis, Powertrain, Engine, etc. are seeing a remarkable increase in software (SW). Simple ECUs that were required to control these domains are no longer sufficient. Increased complexity in these domains have led to higher SW compute power requirements.
• As technology in cars has evolved, we have seen newer domains like AD, advanced ADAS functionalities, V2X, and EV. Each of these domains has significant SW components with minimal sensor and HW. This adds to the overall SW compute requirements from the previous point.
• Newer domains interacting with each other leads to an exponential increase in integration complexity at both the HW and SW levels. At the HW level, the conventional approach leads to several ECUs and interconnects. At the SW level, the conventional approach leads to real-time interactions at a massive scale.
• Increase in SW and complexity inevitably leads to potential bugs in production SW. This will mean that SW in production cars will continuously need to be updated. This requires a FOTA/SOTA approach. Legacy architectures would require significant recalls to fix and flash new SW updates.
• OEMs are tending to move to a subscription model for enabling features. This would mean that a feature can be activated and deactivated, remotely and over the air, upon subscription or cancellation. This cannot be done with a traditional architectural approach. In legacy architectures, automobiles once sold, would not get any feature updates.
• Emergence of the Cloud as a compute location. Legacy architectures would only focus on realizing features in the embedded computing space of the car. The total compute power on the vehicle is limited to the sum of the ECUs already installed and is almost never shared across functional domains.

Vectors of Evolution

Vehicle Architectures had to evolve to mitigate the challenges identified in the previous section. There is evidence of an evolutionary approach by incumbent OEMs and a revolutionary approach with new-age OEMs. However, both approaches seem to use the following principles to define a Software Defined Vehicle (SDV).

Consolidation of Compute

The first key principle seen is the consolidation of compute resources. In legacy architectures, there are 50-100 separate ECUs used to realize the functionalities of the Vehicle. This leads to incredibly complex HW designs, long and buggy integration cycles, and maintenance of specific SW for each of these 50-100 ECUs. Consolidation of compute is a natural outcome of the desire to simplify the ECU-heavy legacy architectures. The levels of consolidation vary depending on the design philosophies of the OEM. However, the clear trend across OEMs is a reduction of ECUs and not an increase. ECUs are consolidated into larger compute processors. The 3-tier architecture in the subsequent section:

Frameworks to enable Reuse

Consolidation of Compute alone does not provide the necessary foundations for simplification. In legacy architectures, each ECU could host just one functional workload. The safety and criticality of the workload are ensured typically by using a Classic AutoSAR approach. However, upon consolidation, the new compute resource will now need to host multiple functional workloads of varying criticality. To make sure safety and performance criticality is ensured, Adaptive AutoSAR is the way forward. It will be very normal to expect the presence of a Hypervisor enabling multiple independent workloads. Classic AutoSAR implementations would be seen as highly critical functional workloads. A combination of Classic AutoSAR, Adaptive AutoSAR, and Linux-based environments along with a Hypervisor enables the framework for the reuse of functional workloads across families and model years.

Updates to Innovate

Over-the-Air updates are becoming a mandatory feature of evolving architectures across all domains. This is true for the Automotive sector as well. Given the significant increase in SW content in the car, bugs are bound to be present, and addressing these bugs and providing patches in a timely and regular manner will become extremely important. A robust FOTA/SOTA ecosystem (server + client) will need to be part of a new-gen SDV architecture.

Subscriptions to Enrich

OEMs are keen to activate recurring revenue channels post-sales. These are not from service and spare parts, but from newer features that can be developed, tested, and deployed post-sale of the vehicle. Subscriptions could be one-off, like an enhanced performance mode for a road trip, or recurring, like preferential and discounted access to charging facilities. To enable the subscription model, the FOTA/SOTA feature above is a mandatory foundational feature. In addition, there needs to be additional cloud-based infrastructure to manage customer preferences and subscriptions. Thus, the new-gen SDV architecture will require a significant cloud/digital implementation.

Perspective on the new-age development model for SDV

Traditional development lifecycles will also change with the evolution into an era of SDV. The earlier approach of “Model-Year” development cycles will become archaic. While Vehicles will continue to have a “Model-Year” led design cycle, the SW-enabled feature set will no longer be restricted to one “Model-Year”. Features will continue to be developed and deployed into Production vehicles on the road.

Figure 1: Continuous Design, development, Deployment & Monitor Cycle for SDV

This will require SW to change into a Design-Develop-Deploy-Monitor cycle. The Deploy and Monitor aspects are relatively newer paradigms in the Automobile segment. Deploy will require features being developed to be tested on potential vehicles already sold and on the road. This will require extensive testing across several platform and model car configurations. A conservative view will mean testing new features on vehicles that have been on the road for as long as 3 years. This will see increased validation costs for new features, that will have to be offset by subscription models within OEMs.

Upon Deployment, the Monitor phase needs to be continuously active. The key objectives here are to monitor features deployed across vehicles on the road and look for performance inconsistencies. An additional task will be to monitor the fleet for potential Cyber Security breaches, given all SDV-based models will be connected. Upon being alerted on a performance inconsistency or a security threat, the Monitor phase will need to isolate the incident, triage, and provide a fix in a timely fashion. Also given that there will be several vehicles carrying the same version of SW, timely FOTA/SOTA campaigns will need to be scheduled.

Having covered the Deploy and Monitor stages, it is important to point out that the traditional Design stage will also undergo changes. The key changes are to envision a feature implementation across the Vehicle and the Cloud. Earlier, feature realization was restricted to the capabilities of the Vehicle. Now the Cloud can be used as an adjunct to realize a feature. Further, connectivity can be taken as a given. So, the ability to realize a feature can also take advantage of cloud computing.

Perspective on 3-tier Architecture for SDV

We evaluated several approaches for a common approach to SDV. The following is a short description of a 3-tier Architecture proposed by Tata Elxsi. The 3-tier approach has the following components:

Smart Sensors / Actuators Tier

Certain functions involve electro-mechanical aspects that involve Actuators and possible High-Current conversions. Examples are Electronic Power Steering, Rain-sensing Wipers, etc. In these cases, having decision-making at a Zonal or Central level would translate to a subsequent transmission of a High Voltage/Current across longer physical distances. This leads to adverse impacts on EMC and the field leading to significant cross-signal impacts. These situations require decision-making (compute location) and subsequent high Current / Voltage transmissions close to the mechanical aspects.

Figure 2: Compute & Decision Making Tier

Zonal Heterogeneous Tier

We expect that most SDV implementations will evolve to a Zonal paradigm. Zonal compute will include a combination of regular Compute cores, Neural Processing Units (NPUs), and Graphic Processing Units (GPUs) along with associated fast-access memories.

Figure 3: High-Level Zonal heterogeneous Tier Architecture

The Zonal Computes will typically host functions like Body, Chassis controls, regional Video/Camera processing, Infotainment, etc.

Central Homogeneous Tier

For most vehicles, a 2-tier Architecture will suffice. However, for the highest-end segment, a central Homogeneous compute zone is anticipated. This will typically have multiple High-Performance Compute Cores, hosting very similar OS and Memory configurations. This zone is expected to host common functions like Gateway, Telematics, etc.

Figure 4: Central homogeneous Tier Architecture

Advantages and Summary

As we see vehicle architectures evolve to an SDV-centric view, Our approach provides for a scalable path forward. We summarize with the comparison of traditional architecture.

Author: Ashwin Ramachandra

Head, Digital Services Practice – Transportation Business
Tata Elxsi

Ashwin has over 28 Years of industry experience with a Master’s degree in Computer Science from IIT Bombay. He has held Senior positions in product engineering, Technology & Strategy with P&L ownership. Ashwin is passionate about envisioning technology offerings on future vehicle electronics and architecture and how we need to prepare for the paradigm shift where software’s taking center stage in the automotive industry.