Next-gen driving: Smarter, software-defined cars that can be upgraded like phones

New-generation driving will include cars that are as much software as they are hardware.

Five years ago, observers in the auto industry heralded the beginning of the Vehicle 2.0 era, marking the first move away from the hardware-driven vehicle, in which software and hardware were basically inextricable, and towards a more decentralised, digital model. We are on the threshold of the age of car 4.0, a fully software-defined car that will provide new possibilities for traditional automakers and original equipment manufacturers.

Western Digital\’s head of automotive and emerging sector marketing, Russ Ruben, compares it to \”the move from a flip phone to a smartphone.\” We\’re transitioning from a \”take it or leave it\” automobile to one that serves as a hardware platform for autonomously upgradable apps through wireless means. Because its software and firmware may be upgraded on an ongoing basis, the automobile you purchase today may retain most of its value for the next decade.

While fully autonomous vehicles may still be a decade away, Vehicle 4.0 is already causing a stir in the automotive industry with its novel architectural changes, dynamic data processing between vehicle, edge, and cloud, and the ability to make continuous software and firmware updates, as well as modularized hardware for serviceability. A preview of the future follows.

Moving from physical to virtual

A car\’s software and hardware used to be tightly intertwined back in the day. Because features were designed and implemented in tandem with the underlying hardware, and because the software acted as a unified whole, changing specific parts of the programme was difficult, if not impossible. since of this, hardware complexity, fragmentation, maintenance, and upgrade costs are all increased since each system has its own unique set of drivers and system services.

A software-defined vehicle represents an entirely new paradigm. apps use hardware-agnostic interfaces like APIs and middleware to communicate with hardware services or other apps. Because of this, original equipment manufacturers (OEMs) may build standalone apps to handle certain tasks or services, and it becomes much simpler to update or add software.

Take ADAS, for instance, which relies heavily on sensors and other devices to do its tasks. However, there is a constant need to enhance how that sensory data is interpreted and acted upon, which can be done via frequent software and algorithm upgrades, making the vehicle safer during its lifetime without changing the hardware.

The hardware fragmentation caused by software incompatibility may be mitigated or even avoided with the use of an abstraction layer that offers services that transfer hardware-specific functions and data to hardware-agonistic ones.

This will result in a reallocation of space in the vehicle, with various bits of hardware and software being given their own \”domains\” at various locations throughout the vehicle\’s brain.

Each sector transmits information and transmits electricity. The software in the domain controller is freed up to concentrate on higher-level computing operations since the I/O for each zone is determined by its physical position; for example, a zone at the front may handle front-facing sensors. As the bandwidth required for in-car networking increases, the ethernet standard will become the electronic/electrical backbone of the system, allowing for scalability while lowering connection cost and cable weight.

OEMs will be able to continuously upgrade safety, connectivity, and efficiency applications like high-def 3D maps and ADAS with over-the-air (OTA) updates, and enable vehicle-to-everything communication (V2X), all of which require on-board data storage. Third-party developers will be able to create new and innovative entertainment apps that run on the infotainment systems.

The Implications for Data Storage

Cars will effectively become mobile data servers over the next decade as we go towards Vehicle 4.0 and ultimately completely automated driving. Some estimates have the storage needed for car functions at 11TB, and that number is expected to grow as original equipment manufacturers (OEMs) include connectivity and sophisticated driver aid systems and artificial intelligence (AI) into their products.

Ruben argues that the promise of the software-defined vehicle can only be realised if all of its systems are working in real time, on board and independent of the cloud, and if they have increased performance and storage capacity that enable data to travel swiftly.

That calls for a whole different approach to data storage. Multiple applications will share a single storage device, therefore it will need to be fast, have enough of space, and support protocols like SR-IOV (storage region inter-processor virtualization) to facilitate the smooth transfer of data between processors. Quality and dependability will become increasingly more important as the vehicle moves towards fully autonomous operation.

Ruben predicts that during the next decade, \”continued advancements in the architecture of the vehicle\” will cause adjustments to be made to the interfaces with the storage devices. \”The driverless car might be a decade away, but storage needs to keep pace with the products, performance, and capacity points required as Vehicle 4.0 evolves.\”

Future-proofing our storage systems

\”Software-defined vehicles pose a challenge for the car manufacturers and tier-one suppliers that are developing new systems,\” Ruben explains. They need a data plan for the foreseeable future, and storage can\’t be an afterthought. When you do that, you open yourself up to problems.

Manufacturers may have a good idea of their storage needs right now, but how much space will they want as time goes on, and what will the workloads look like, with the addition of new software and features? How often a data storage device is written to or read from affects how long it lasts for that purpose.

In a time when automotive innovation is racing ahead, it might be difficult to predict future workloads and capacity requirements. However, Ruben adds that a shift to higher-capacity points or a modular design are two alternatives that might help automakers prepare for future needs.

Ruben proposes increasing capacity by at least a point or two over what is required right now. Incorporating a data storage daughter card into a health monitor\’s modular design improves serviceability. In the event that the card wears out or its storage space fills up, the owner may easily have it replaced at the auto shop, or they can upgrade to a more capacious storage device.

Instead of working alone, hardware and software engineers should coordinate their efforts to ensure a successful product. Obviously, a designer\’s initial thought won\’t be about data storage; rather, it will be about the chipset. However, data storage should be the designer\’s second priority.

Always, \”our message is to make sure you understand your workloads,\” as Ruben puts it. You must have this knowledge up front since it will force you to adjust your approach and modify your system\’s design and capacity requirements. Constantly adapting alongside chipset suppliers, we guarantee our products will work with the protocols and interfaces required by today\’s and tomorrow\’s automobiles.