Software-Defined Vehicles

The attributes of vehicles that make them attractive to buyers have had a clear shift recently, with continued acceleration moving into the future. In the 1980s, product quality was a strong factor in the buying decision, but the differences between the highest and lowest quality new vehicles have now become small enough that this is becoming less important. Fuel economy for combustion engine vehicles is important. For electric vehicles, driving range and battery charge rate, interestingly in units of “miles per hour”, are key. Design and comfort are also important, of course. Most of these factors, especially—quality, fuel economy, design and comfort—are now considered givens in mature car markets such as those in North America, Japan, South Korea, and Europe. They can be considered the price of entry to the marketplace, and consumers are looking beyond them.

“Today, consumers are increasingly looking for features defined by software, such as driver assistance features, infotainment innovations and intelligent connectivity solutions. As driver-assistance features grow into more automated driving and toward fully autonomous driving, the need for more software also grows.” – Aptiv 

These features are a new battleground for product differentiation, and all of them require faster communication than can be provided by many traditional automotive-specific networks, yet they use protocols and technologies that already run on Ethernet-based networks. Since the introduction of over-the-air (OTA) updates in Tesla’s Model S sedan in 2012, most other manufacturers have followed suit and will be introducing their own OTA systems. Given the size of the firmware in a vehicle for these features, transitioning to Ethernet within vehicles is pivotal to bringing these and other future technologies into cars, thereby broadening appeal to the car buyer, as well as integrating vehicles with broader IT functions and communication systems.

Zonal Architecture

Move as much decision making / intelligence out of individual ECUs into the Central Processing / Compute module

• Edge Devices (e.g. Sensor and Actuators) A, B, C controlled by remote commands from the Central Processing unit.

Networking in this model becomes more important

• Numerous lightweight protocols are available to transport commands and responses to the Edge Devices
• Example: ADI’s E2B, TI’s FlexWire