An Insight into Software Defined Vehicle

Supriyo has over 25 plus years of experience in product engineering and has led multiple software product, platform & business solutions development for various customers globally across different sectors like ISV, Automotive & Healthcare.

Automotive Industry always goes through a constant transformation cycle adopting New Technologies & comes out with new product variants transforming the industry. We all know how Electric Vehicles are pushing the IC Engines out of Market. Software Defined Vehicle (SDV) is the new Technology trend which is applicable for both IC Engines & EV. In a Software-defined vehicle features and functions are primarily enabled through software, making the car into a Software Driven Electronic device on wheels.

What is a Software Defined Vehicle? How it is different from standard ECU driven architecture? What is the need of SDV? To answer these, let’s look at traditional Automotive Architecture. In a Traditional Architecture, Car will have different modules like Engine, Power Train, Transmission Control, Break Control, Central Control, Central Timing Module, Body Control, Infotainment etc. Each of these modules are operated by Electronic Control Units (ECU) – which is an integrated unit of HW &SW. A typical premium Car will have hundreds of ECUs. The ECUs communicate with each other through their own communication channel & together operates the car.

If new features are added to the car specially related to ADAS, it will also add another ECU with its own power unit, own components, own connectivity, its own processing etc. This increases weight, Cost & Complexity of the Car. Instead, if we have a Centralized Architecture, it will reduce the need of discreet control units. Secondly today Consumers are increasingly looking for more software features in the car like Driver Assistance, Innovative Infotainment & intelligent connectivity. This increases the need for more software applications inside the Car. Also, while for all intelligent devices, software is updated remotely through OTA, however for an Automotive today we still need to go to a dealer for Software upgrade. We still depend on the Dealer to monitoring and tuning of core functional capabilities of the vehicle, such as powertrain and vehicle dynamics.

The idea behind SDV is to simplify vehicle E/E architecture and consolidate hundreds of ECUs into domain/zonal controllers and vehicle computers, have separation of software from hardware, and move all the SW controller logic to vehicle computers, thereby managing the vehicle, rather than managing individual ECUs. It also enables updating vehicle software over-the-air, either feature by feature, domain by domain, or even full-vehicle update.

• Physical connections of sensors to vehicle computers and/or zonal controllers shall be abstracted out, with redundancies by design

• Zonal/domain controllers separates various I/O from the vehicle controllers

• Mechatronics ECU will provide a abstraction layer

• The vehicle computers will have virtualized applications running on them.

The SDV architecture is based on simplified design, centralizes computing power and optimized electrical/electronic content, components, and functionality. In SDV Architecture we have two key components, Domain Controller & Vehicle Compute. The Domain controllers deliver power and data connections to the sensors and other devices, with just a backbone connection to the Vehicle Compute. All peripheral sensors and devices are connected to Domain/Zone controllers. Vehicle Computes are essentially Central Computing Units – they will host Applications & Services (ECU functionalities are converted into containerized Micro-services) & these services provided by multiple Central Computing units communicates among each other & exchange the data using Service Bus Architecture. As the I/O is separated from the compute, the computing resources in a vehicle among various software applications are allocated dynamically, as needed, similar to a cloud computing model. A critical safety feature that requires more processing power will have higher priority over less critical functions such as infotainment. Car new features will be delivered through Software Upgrades through OTA. Software will be able to tune the Car dynamically. This reduces Vehicle Cost of Operation as well as New Features Development Cost & increases the Life Cycle of the Car.

Cloud has a big role to play for the end state of SDV. This includes complete Cloud based Service development and testing & Car Software using the best of DevSecOps practices. Car Software will be first tested on Cloud using simulation before pushing to the Vehicle. A hybrid new secure OTA delivers Software for containerized services to vehicle. Several Services could be offloaded to Edge & Cloud to reduce the load on Vehicle Compute e.g., in Infotainment - Run your Netflix on Cloud & stream to your Car Head Unit. Vehicle services can be managed & monitored from Cloud including Shadow mode testing. SDV will also open new revenue streams for OEMs e.g., Subscription based service enablement. This will increase the vehicle lifetime and a lot of focus will be software development for new software features.

While it is exciting there are challenges too - both from Engineering as well as Organizational Perspectives. From Organization perspective it needs to go through a complete mindset change – need to establish a Car Software Organization – A Software Factory with skills aligned to Cloud to Sensors, SW Product Management Mind set, Culture of Innovation & Growth, Rapid & Iterative Development Cycles, Human Centered Design, Test Driven/Behavior Driven Development, Continuous Integration & Continuous Deployment etc. Changes are required across Model, Mindset, Method & Machinery.

There are few key critical Engineering Challenges –

• Since the compute and memory is constrained in a vehicle, the approach for solving the software problem is very different from a typical cloud environment. For example, use of low footprint orchestration options which can be further optimized to meet automotive requirements.

• Existing automotive grade hypervisors need to be scaled-up to support multiple SoCs seamlessly.

•  While SDV is a connected Car, Cloud ecosystem is designed to be highly available, but vehicle has considerable down-time (and limited battery power).

• SDV needs to meet the expected performance of time-critical vehicle functions as well as meet the expected functional safety goals of vehicle functions.

• SDV needs to manage Lifecycle of entire vehicle functions (full-vehicle updates).

• A strong connected security system will be needed. Developers need to build strong defense against cyber-attack both OTA and the cloud’s edge

Typically, the design cycle for any new vehicle variants for an OEM is typically 2.5 to 3 years and even though most of the base software remains the same, they need anywhere between 250-500 people working only on the software development and deployment for each variant which is a big burden on OEMs spend. Once OEM adopts the software defined vehicle as a framework for software engineering, theoretically they can reuse the software so long as it is relevant for the end-user. The vehicle functions will be broken down into small and reusable piece of code that can be independently development and enhanced. The development to deployment cycle will reduce from years to months, days or even to couple of hours, thanks to proven robust, continuous integration and deployment (CI/CD) methodologies working in the adjacent industries already.

The biggest threat to car manufacturers today is not just the competition or changing technological landscape. It’s the loss of relevance and the difficulty to adapt to the changing relationship with the customer. So, while SDV was limited to select few & that too in premier car segments (e.g., Tesla) most of the Global OEMs & Tier 1s are seriously looking at SDV today for broader adoption. There is no doubt that SDV is a trend that is going to transform traditional automotive companies in the next 10 years.