Get email delivery of the Cadence blog featured here
Back in about 2001, when I was last working for Cadence, Cadence started bringing in a lot of executives from Intel. We had merged custom IC and digital IC engineering and I was running the merged marketing groups. We had a lot of customer commitments for mixed-signal design environments, and figured the only way to deliver on them was to break the silos and make a single team, at least for a year or two. The two groups historically barely talked to each other. The biggest issue was that the two environments had different databases, and we had a third database, openAccess, that existed but was not really used in either system. We needed to get that foundation sorted out before anything good would happen, otherwise we were building a house on sand.
Around then, an Intel executive came in and took over the whole thing. Like most executives from semiconductor companies, he thought that semiconductor development teams were great, and that software development teams were undisciplined cowboys. He was there to bring semiconductor discipline to EDA development. I pointed out that they were very different types of development. A chip taped out. Of course we released software, but it was never "done" like a chip.
He asked me some differences between IC development and chip development, not philosophical ones, but some real facts. I immediately thought of two big ones:
I remembered all this when I was at the recent Automobil Elektronik Kongress in Ludwigsburg. Johann Jungwirth, Chief Digital Officer for Volkswagen, pointed out that software development for cars is going from the hardware development model to the software development model. He summarized it in the slide above.
SOP is "start of production". The old model was that the software for the ECUs would be developed by the tier-1s rather than the car companies (OEMs) themselves. The car would go into production, and then never be updated again. Of course, if there was a major recall then the engine controller or something else significant might need to get re-flashed, but that was definitely an (expensive) exception. The old model was like SoC development; the new model is like EDA development.
Tesla, in particular, does not operate like other car companies, they are already on the new model. They do over-the-air (OTA) updates and owners might get into their car one morning to find a new option has appeared on their control panel. The most dramatic of these updates was the October 9th, 2014, when Tesla turned on Autopilot. For some time, all Tesla Model S vehicles had shipped with cameras and sensors but without the software to make use of them, since it wasn't yet complete. On that day, owners who had paid the $2,500 extra for the option discovered that their cars could handle some driving, especially on freeways, on their own. They also had increased safety since they could handle some emergency situations largely autonomously. Here is a compilation video of several examples of Tesla accident avoidance.
Volkswagen and other car companies realize that in the future everyone will need to be like Tesla. It is only a slight exaggeration where Johann said that software development starts with SOP. A car lasts for 15-20 years and future cars will be updated over-the-air with new capabilities, bug-fixes, security patches and more. It is almost a cliché to say that future cars are smartphones with wheels, but for sure the user experience is going to be more like our smartphone experience, with updates over the life of the vehicle. The first iPhone was launched 10 years ago (June 29th if you want the precise day). I doubt many of them are still in existence, let alone still in use. But, of course, if they had been cars. most of them would still be on the road, and still require updates to keep them safe.
Several speakers at the Kongress talked about the changes necessary at car companies. To switch from their old style of development to the new is not just a change in project management that can be implemented by junior engineering managers. It requires a cultural change in the company.
Other changes are happening at the same time, requiring further cultural change. I called this The Triple Witching Hour for Automotive, and the above slide shows the same factors. Okay, there are four bullets but #3 and #4 are different aspects of the same thing, that at least some vehicles will be shared and some people will not own their own vehicles.
The results are the three items on the above slide.
In the same area of software development, another big change is software testing: a lot of it will be tested in virtual cars rather than loading flashing a real car and sending it out with a test driver. Apart from the issue of danger in the early days, it is just too expensive. VW has a whole cadre of test drivers but it takes them a long time to rack up a million kilometers in a particular vehicle, whereas automated driving in a simulated virtual environment can rack up several times that every day.
This change is not just a change for the car companies themselves. It is driving a change in the ecosystem of suppliers surrounding the car companies.
Sign up for the weekly Breakfast Bytes email: