They may exist, but that's not the fundamental difference between Tesla and <enter most all other brands>. The first difference is long-term buyer delight and is clearly shown in the first sentence of the linked article: "Model S is designed to to keep getting better over time." Everyone else's stance? That was last years model - if you want the new UI and/or new features buy the current model year car. There is, most often, zero expectation for car buyers today to expect upgrades or enhancements that are as drastic and as positively interesting as how Tesla approaches it.
The second, and likely more critical differentiator (IMO), is security. Mr. Musk would not accept public shaming of such magnitude like this:
And I only pick on GM here since, well, you work there. When it comes to software in cars Tesla treats it as a true part of the vehicle engineering. Others seems to still treat it as an afterthought - and then the question starts to linger: how good is the software in all of the other vendors "features"? How much QA have they done with regard to lane keep, blind spot, adaptive cruise, etc?
I don't own a Tesla, I really wish I did, but if I had to place a wager on a car manufacturers QA process and ability to build fault tolerant vehicle systems I would pick Tesla to oust the competition handily at this point. While I realize it's a subjective matter, and there's really no good way to compare, the directive of the company seems pointed in a more apt approach than others.
To be clear: I, personally, am really happy there are strong challengers in the car market. Also, I am speaking solely for myself.
The quote: "Model S is designed to keep getting better over time" reminds me of kaizen (1). It is a really awesome concept that not only can the car manufacturing process and technology keep getting better, but the cars can improve as well.
That being said: OTA update is REALLY FUCKING SCARY for cars. What if someone puts the wrong update in the queue accidentally? (2)
The historic attitude to modules in cars is also important. Modules run "code", but it is treated as mechanically as possible. Could you imagine changing out a few pistons while driving? Probably not. This is a failure of imagination that is being addressed now!
It is a truism that Big, Old, Large companies are risk-averse. The downside to doing a bad OTA to a car is unlimited!
WRT to Tesla's QA - I don't know of anything that has been published in this regard. I would hope they are "doing it right". I hope they are successful, and I hope everyone is inspired by their leadership and learns from them.
1: https://en.wikipedia.org/wiki/Kaizen - Article claims it was introduced by American business people, but Japanese companies continuously improved it =D
> That being said: OTA update is REALLY FUCKING SCARY for cars. What if someone puts the wrong update in the queue accidentally? (2)
OTA update is no more or less scary than any other form of software update, or in fact any other form of mechanical update.
Software engineers are generally used to the level of rigour that goes on with their software. If you're a web devloper shipping a commerce application there's an appropriate level of testing and process, because there's only a certian level of reliability you need to hit, and spending more money on that would slow down your development. The way you go about delivering software for medical devices for instance (which we do), is a completely different process with a whole different level of rigour, testing and documentation. Because that's appropriate in that environment.
There's a whole lot more documentation and thought that goes into the beam that stops the top of your house from falling down, than goes into the beam that stops your garden shed from falling down. It's no different than software.
It's not as simple as that. NASA can update software on the mars rover or interplanetary probes, but that's one device at a time, and the amount of effort put into it is staggering.
At the same time, consumer electronics are routinely broken by OTA updates.
Cars fall squarely in the middle, high volume and high price. Additionally, failures carry a high risk. Nobody will die if your webshop goes down, but if your car decides to steer into oncoming traffic, well, bummer.
The support beam analogy is flawed in the sense that the beams are simply made bigger to ensure they're strong enough even with considerable material defects, but this doesn't work for software, where a single little bug can lead to a catastrophic failure.
I am not aware of anything other than cars where such a high number of devices carries such a high risk factor. Certainly doing OTA car updates in a commercial environment is possible, but there is not yet a relatively foolproof way to do it.
Regarding 1: I am a huge proponent of Kaizen and, what you're probably more after is the influence Demming had on Japanese companies. The interesting part is that if you've studied Demming you'll know he pitched his process to every American manufacturer first - and all of them wrote him off, which, as we all know came back in spades from a quality comparison perspective shortly after. Demming: Quality = Results of Work Efforts / Total Costs.
Regarding OTA: It is. But, ignorance is even scarier. Look at any company that embraces CI (continuous improvement). Amazon - how many changes to production do they push a day? Now compare that to a legacy F50 that has process designed to be change averse as they view that as risk in and of itself. This seems to be the viewpoint you're working from through GM and maybe (I'm speculating here) you're influenced by the process internally. Maybe your view is that it's risky because of what you're exposed to? My guess is that given the culture of Telsa - critical software OTA is not taken lightly. Speculation - but they likely have a far more rigorous process for deployment than many others since they've done this from the beginning. If I can suggest reading on this subject I would point you in the direction of Gene Kim's work in this area as he has studied high performing organizations and, in a nutshell, has found that companies that embrace change and do it frequently have less operational problems than those who don't. Risk-averse seems to compound mistakes and, this could very well flow into those hypothesis around practice. The more you do, the better you are and "10k" hours.
While I agree accidents can (and will) happen - again I wouldn't put my money that it happens to Tesla first or with any cadence of frequency. Keep in mind Tesla is riding on quality in software - full stop. If they have a problem there, it could be detrimental to the point of failure. This is a good thing for consumers because they're most likely getting a superior product comparatively. And we already know that non-OTA software that has gone out the door in vehicles has caused death and harm. Is it scary that those bits are note able to benefit from a timely OTA update? There are definitely two sides to this coin.
And finally... While I know that it's been said quite a bit that "we've done that". I'm not truly sure people are grasping the reality of what Tesla is doing. While I understand others have these features, the Jalopnik short sums up what they've accomplished that, in my opinion, others are definitely lagging behind in - if you haven't watched it definitely do:
Again... Even if others are kind-of-sort-of doing this today, the iterations will be across model years. No vendors have the long-term upgradability that Tesla does at this point. Not sure I would trust an American car to change lanes on it's own based on it's situational awareness as shown in the video.
The second, and likely more critical differentiator (IMO), is security. Mr. Musk would not accept public shaming of such magnitude like this:
http://www.wired.com/2015/09/gm-took-5-years-fix-full-takeov...
And I only pick on GM here since, well, you work there. When it comes to software in cars Tesla treats it as a true part of the vehicle engineering. Others seems to still treat it as an afterthought - and then the question starts to linger: how good is the software in all of the other vendors "features"? How much QA have they done with regard to lane keep, blind spot, adaptive cruise, etc?
I don't own a Tesla, I really wish I did, but if I had to place a wager on a car manufacturers QA process and ability to build fault tolerant vehicle systems I would pick Tesla to oust the competition handily at this point. While I realize it's a subjective matter, and there's really no good way to compare, the directive of the company seems pointed in a more apt approach than others.
$0.02.