OEMs don’t want to let other companies define the driving experience.
Over the last few years, the basic architecture of how a vehicle is put together has changed a lot. This has also resulted in a change in how the automotive supply chain is put together, too.
Historically, vehicles have been put together like the picture on the left in the above diagram. Vehicles could have as many as 100+ electronic control units, or ECUs. If you don’t know much about the automotive industry beyond driving your own car, you might assume that the automobile manufacturer (Ford, say) designed and built those ECUs. Automotive has lots of its own terminology, and automobile manufacturers are known as OEMs, for original equipment manufacturers. But that’s not how the industry operates at all. The ECUs were (and are, in vehicles that still use this approach) designed by the next level down in the automotive supply chain hierarchy, knowns as Tier-1s.
Tier-1s are companies like Bosch or Denso who specialize in creating ECUs. There are clearly some possibilities for economies of scale since different OEMs might make use of the same ECU. There is not a lot of differentiation in how intermittent windscreen wipers are implemented so no reason for Ford to use a different ECU than General Motors. Plus, even for the more complex ECUs such as ABS, anti-lock braking system, the most important thing is that they work correctly and not that they work differently. The modern ABS system was actually invented by Fiat (not the first company you would have guessed, I’m sure) who sold the patent to Bosch who named it ABS and sold it to OEMs, starting at the high end (Mercedes, BMW) and gradually taking it mainstream so that most (all?) cars today have ABS. Until recently, Tier-1s like Bosch would not have designed any of their own chips, they would just purchase microcontrollers from the Tier-2s, mostly semiconductor companies such as NXP, Infineon, or Renesas.
That resulted in an industry structure as in the picture above. The OEM (Mercedes, say) would purchase ECUs from a Tier-1 (Bosch, say), who would purchase parts such as microcontrollers from a Tier-2 (such as Infineon). The OEM really just assembled the vehicle and, usually, built their own internal combustion engines, known as ICE for short. For more detail, see my posts Automobil Elektronik Kongress 2018 and Automobil Elektronik Kongress 2022 from which the images in the post originated.
There are a number of problems with this approach. As more and more electronics were added to the vehicle, the number of ECUs got ridiculously large and the wiring harness to connect everything up got ridiculously heavy (over 100 pounds in many cases). But, from the OEM’s point of view, the big issue was that as more and more of the “look and feel” was in the electronics, the OEMs were not in control of the experience drivers and passengers had in their own vehicles. The change towards more electronics in a vehicle was somewhat out of the hands of the OEM itself, driven by the two major trends currently underway in the automotive industry:
In practice, this means that much of the experience of the vehicle moved from all those ECUs into software. When there are 100 ECUs in a vehicle, most of them are idle most of the time (you don’t adjust your seat that often). Of course, for some ECUs, such as the ones controlling the airbags, you are quite happy if they are idle (but active) for the entire lifetime of the vehicle. But if the experience of the vehicle was going to be largely in software (“the software-defined vehicle” was the subtitle for last year’s Automobil Elektronik Kongress, AEK) then the OEMs needed to develop their own software. Or as the CEO of Porsche pointed out at the 2022 AEK:
Most Porsche drivers use iPhones. So the big question is how to make seamless connectivity without handing the experience of the Porsche totally over to Apple.
This also required changing the hardware of the vehicle from hundreds of ECUs to just a few. This is known as zonal architecture and is the right-hand image on the picture above.
Also, ADAS and autonomy, which require processing video, radar, and (if you are not Tesla) lidar, require much more computer power. This is another big change. Historically, automotive semiconductor ICs were built in 10-year-old processes since they were low-performance, often analog, and the biggest requirement was reliability. After all, if your cell phone glitches, you can just reboot it, plus you will probably discard it in three or four years max. A glitch in a car can be life-threatening, and even though you may sell your car after a few years, it will remain on the road for 20 or more years. Obviously, the chips need to last for the lifetime of the vehicle.
As a result, automotive semiconductors, at least for the ADAS/autonomy part of the vehicle, have moved from ancient mature processes to more modern processes such as 16nm, 7nm, and (coming soon) 3nm. These are still “automotive” processes, with extended temperature ranges and extensive qualification data, not the same process as is used for the application processor in your smartphone. But they are advanced processes requiring advanced design methodologies. It is very different to design a reliable SoC in 7nm (with all the functional safety stuff, too), as compared to putting a 65nm standard-product microcontroller onto a little board.
This has resulted in a much different structure of the automobile industry supply chain, cooperating or interfacing with other companies that might not strictly be part of the automobile industry, such as cloud data center companies or smartphone companies (Apple CarPlay and Android Auto). Some companies still cooperate with Tier-1s, and there is tension between the OEMs and the Tier-1s as to who is going to supply the critical components and software. OEMs are also collaborating with the Tier-2s, especially the semiconductor companies. Indeed, some OEMs (Tesla, for one) are designing their own chips, as are some Tier-1s (Bosch, Cruise).
Another big change in the automotive industry, once you have a lot of software, is the requirement to update the software when necessary, just as happens almost seamlessly on your smartphone or your laptop. There are bound to be bugs. Historically, automotive software in the 100 ECUs era was never updated after the vehicle was first shipped (SOP, or start of production). For more on this, see my post Automotive Software Development Used to End with SOP.
But the software-defined car needs to handle software updates, and very preferably not require a trip to the dealer to re-flash some code memory. The standard is over-the-air updates, or OTA (like your smartphone, although we don’t usually use that terminology there). This pretty much requires a zonal architecture with just a few processors (preferably just one). There is no way that it makes sense to re-architect 100 ECUs to be able to handle updates. The most critical updates are ones to address security, safety, and driver experience.
There are two levels of change that we are in the middle of right now:
OEMs (car companies) need to take control of the entire stack of capabilities and not depend on Tier-1 and Tier-2 companies to determine the experience and differentiation of their products.
Leave a Reply