By Onn Haran

In the last years, OEMs are investing huge efforts, and even changing their organization structure, to transform their vehicles into a smartphone-like product. That Software Defined Vehicle (SDV) holds the promise to update the vehicle operation, before and after the vehicle is on the road, using an app store concept. The OEMs aim to enhance safety and comfort for vehicle occupants throughout the vehicle’s lifetime. In return, the OEMs expect to shorten and simplify the development cycle while gaining the ability to charge the car owner for the new features.

The new vehicle architecture impacts all components, and V2X is no different. Today, V2X is considered part of the connectivity domain. This was the most logical decision since V2X is a wireless element used for alerts without impacting core safety functions. Now, a transformation is needed.

SDV is all about connectivity. The SDV software architecture is divided into 3 main layers: The lower layer contains all the real-time and safety elements, applying up to ASIL D functional safety. Above that, the on-board environment runs non-real-time operating system. This layer may include an ASIL B functional safety island for some safety functions, but its essence is not safety. The SDV transformation lies with that layer, which also interacts with the third layer – cloud off-board services.

The general preference is pushing functions up “north”. In other words, implementing functions as non-real-time in the on-board environment instead of the real-time domain. However, V2X is going the opposite direction – “south”. V2X is a safety sensor, with strict real-time constraints to assure data freshness, and a need to apply functional safety to be used to brake the vehicle in emergency situations.

The open on-board environment contains isolation schemes, like hypervisors. Still, the risk of having safety functionality be impacted by non-safety functionality limits the safety content in the on-board environment. Specifically, isolating and preventing common resources between connectivity-related and safety functions.

So, what is the impact on V2X?

• V2X should be isolated from the connectivity domain. It may physically be located in a Telematics Control Unit (TCU), but even then, it should be logically isolated. Only a standalone V2X chip, as offered by Autotalks, can fulfil this requirement.
• Cloud data should not be used to control the vehicle – Only direct communication V2X should control the vehicle. Cloud data can be used for displaying warnings, and configuring setting for controlling the vehicle, but controlling the car would imply a major change in the software architecture, which contradicts the essence of SDV.
• The value of V2X can be continuously enhanced using SDV. SDV’s ability to add and update functionality can be leveraged to V2X. For example, a new accident scenario can be added, once the development and testing are completed. An existing scenario can be improved if drivers wish to get an earlier alert.

SDV will create safer and smarter cars. V2X will create safer roads for all road users. The combination of both is essential, yet requiring careful consideration and planning.