In an earlier post on architecture I presented the concept of two layers as a meaningful pattern for the electronics architecture of future vehicles. I separated between the physical layer and the connected layer. Characteristic for the physical layer is its close coupling with the e.g. mechanical and hydraulic components of the vehicle in question. This close coupling means that over-the-air updates will most likely focus on correcting errors on the physical layer, rather than providing added functionality. The reason being that it does not make sense to load software for functions to the vehicle, for which the physics of its drive system is not suitable.
After presenting this topic recently I was asked, if Tesla’s extension of the functionality of the steering system over-the-air was not contradicting my version of the two-layer concept. And at a first glance it really does seem to be a contradiction. However, I believe that even this case obeys the principle of reducing software updates for the physical layer to the bare minimum. I have two reasons for this assumption:
- At the time of Start of Production (SoP)/sale the existing drive functionality did not exploit the physical capabilities of the vehicle drive system to its limits. The sensors and actuators and other hardware (electronics, mechanics, etc.) necessary for automatic steering was already installed in the vehicle at SoP respective time of sale! Essentially Tesla just activated an already latently available function. If this activation just required switching a few bits or a rather more complex software update does not really matter.
- Nothing is always black or white. There is no fundamental argument against adding new functionality to the physical layer. The close coupling with the vehicles “hardware” does, however lead to the conclusion that the updates that add functionality to the physical layer will at least happen very infrequently.
Based on these arguments I expect that over-the-air updates for the physical layer will mainly be concerned with error corrections.
The steering system update by Tesla is itself a good example of another change, which we predicted in our study Software Drives 2030. We argued that reserves of hardware resources will be installed in new vehicles, and that these reserves will mean that the SoP will not be End-of-Development anymore. This will hold especially for sensors and actuators, but eventually for all electronics components and electronics systems. This initial investment of surplus resources requires a manageable departure from today’s practice of (at most) rightsizing, but it buys the flexibility at the later stage to substantively add new functionality – of a much higher value! This is exactly what the Tesla example shows. If the reason for separating the automatic steering function for later delivery was a marketing ploy to a showcase Tesla’s innovation leadership, or the test of a new business model dealing with online delivery, or insufficient verification and validation of this function at SoP, does not really matter.