You are absolutely right in that this failure should not have happened, because they should use some other medium to store their logs that is not getting cramped by increasingly bigger firmware versions and that is appropriately sized and engineered to withstand at least a century or two of heavy usage. But since cloud thermostat and media player box vendors also get away with just stuffing some embedded Linux distro on a single chip of the cheapest Flash they can find on the spot market, Tesla probably didn't put much thought into why they shouldn't just do the same. After all, this system is just a media player box mounted in a car, right?
(Except that for some totally absurd reason, the car ceases to function entirely if its media system breaks, which is the next big WTF in this story...)
Who didn't assume this to be the case? Teslas are automotive iPhones, and I've always assumed they would be scrap in 3-5 years rather than 15-20. This is why I don't think it was ever valid to compare the purchase price to a regular car.
This was a no-brainer IMO: Tesla wanted their cars to be superior and time to market was key. Why do handwringing about the cars that might be still on the road in five or ten years when that's beyond the warranty and beyond Tesla's life in business if they don't deliver a Model S with the target specs? They made the right tradeoff. This is probably one of dozens of design weaknesses that Tesla cars have, ones that allowed them to get way ahead of the competition.
Now that we have arrived at five or ten years later there is some nonzero risk to their brand. Do they have unreliable cars? How many Tesla owners still own the original car and how many of these were purchased second-hand? Folks who bought the original car and they encounter this failure mode might think about this expensive out-of-warranty repair when they go car shopping next. If there are a lot of them, Tesla could consider the financial tradeoff between extending the warranty to cover this failure mode and the impact on future sales.
It is strange no one performed back of the envelope calculations on flash life vs logging size.
I've worked in embedded, we had a time series based rolling log. Flash life calculation was done at regular intervals.
IIRC with what we shipped, the flash chip would outlive the battery by 3x or 4x. And that was without wear leveling!
We were smart enough to continue the rolling log at the last point on flash we uploaded from, avoiding the mistake I've seen some products do of starting over from the very "beginning" after every log sync. Do that and you end up with 10% of your flash worn down to nothing and 90% of your flash going unused.
Also, unless needed, please stop using JSON. Use a binary format instead. Protobufs is trivial to get up and running almost anywhere. Other binary encoding formats may serve a product's needs better. JSON is fine if everything is low bandwidth web services talking now and then, or low friction HTTP APIs, but for other use cases... use something else.
Worst I ever saw was XML being used to RPC invoke every single function call, even local ones. All params got packed up in XML, sent over to the destination, who'd then unpack the XML, execute, and package up the return value. A double digit % of the CPU was being used on XML serialization and de-serialization. (If your choice is that or JSON... probably go with JSON!)
Logging flash being same as storage flash is super weird though. Though if their MCU only supports hanging a single flash chip off of it, I could see it happening.
Assuring yourself that under no circumstance is that possible can sometimes be tricky.
Sure, but sensor error reporting frequency should also be documented and calculated somewhere. Embedded requires more planning, this stuff isn't like AWS instances where the worst case is a larger bill.
And from the sound of it just general usage is causing problems.
Reminds me of some people's aversion to auto-killing processes when the OS runs out of memory, as though it could ever be better to lock up completely.
Ultimately Toyota recalled about 7 million cars (some twice). Dealers were installing the wrong floor mats, and these were trapping the accelerator pedal. This problem was well-documented as the cause of "unintended acceleration" incidents, including at least five deaths. Additionally, there was a lack of "brake override" system to idle the engine when the brake and accelerator were both applied (Toyota added one at the government's request), and some pedals manufactured by a supplier were well-documented as "sticky" (they recalled these cars and fixed this).
See the NHTSA report, pages 4-10 (PDF pages 15-21): https://one.nhtsa.gov/staticfiles/nvs/pdf/NHTSA-UA_report.pd...
In summary, there were real "stuck pedal" problems with these cars that led to unintended acceleration and fatalities and, eventually, recalls and fixes. And, yes, some or many incidents were probably related to "pedal misapplication."
This sounds like an illusory problem to me, not because I doubt the facts, but because it's all about framing. I got floor mats for an old car, with anchors to hook to the seat rails, and I couldn't figure out how to fasten them. So I took them to a dealer and asked them to do it. After a while, they came loose and the mat shifted several inches in the direction of the gas pedal. Now, it didn't especially matter, and I didn't crash, and eventually I repositioned it. But this is really about multiplying large numbers by small probabilities. There are probably only a couple hundred cars like mine on the road. If there were millions, perhaps it would be a major problem. But why should we all worry about Toyotas just because the floormat issues are mentally grouped together?
Non-floormat issues are different, but I think I would have to experience it to believe it when it comes to the brakes not being able to override the engine on a typical Toyota.
https://abcnews.go.com/Blotter/toyota-pay-12b-hiding-deadly-...
https://mashable.com/2014/03/19/toyota-lied-aceleration-reca...
https://www.rs-law.com/unintended-acceleration/
And here's an article by one of the experts who reviewed Toyota's code and found the smoking gun: https://embeddedgurus.com/barr-code/2013/10/an-update-on-toy...
I sure hope Tesla has figured this out for 3 and the Y. (It has. According to the FA, this has to do with MCUv1 Tesla Model S and Model X units up to 2018.)