Re-posting the relevant info from
this post that was moved for reference. I'm on "moderation" after
my last post (which admittedly was a bit snippy), so not sure when/if this will actually show up here, but I feel this info should remain in this thread and not be lost.
---
"Safety" is pretty broad. For example, I would consider a battery exploding/catching fire/etc without an external cause (like tampering, external fire, accident, etc) to be a safety issue. I wouldn't consider the car being or otherwise becoming unusable to be a safety issue. (Others have said that a car dying unexpectedly would be a safety issue, but I don't subscribe to that line of thought, considering cars break down all the time.) I wouldn't consider limited power or limited charging a safety issue. Etc.
With that in mind, to the best of my knowledge, no to both questions.
Open for debate.
The warranty explicitly disclaims capacity loss not related to a failure. Nothing has in fact failed, so I'd say by the letter of the warranty and relevant laws I'm aware of.... probably not. I'm also not a lawyer.
A better question would be, is Tesla allowed to avoid a warranty issue at the expense of the customer's ownership experience? Dunno. Don't think there's any good examples of this in the past, since Tesla's OTA setup is somewhat unique.
Mitigates a potential failure mode of the high voltage battery.
---
I could have, from a technical perspective, defended my original statements at the time pretty well. (Edit: Keep in mind that the info below is based almost entirely on independent reverse engineering of the software and hardware.)
It was quite obvious from the software that Tesla was testing proactive functions that searched for, predicted, and attempted to prevent a particular potential failure mode (catastrophic and unsafe) (X) in the fleet, and also clearly obvious from analysis of that code that it was definitely not expected to actually be found in the fleet at all.
Instead what they got were loads of false positives from a previously unknown and unrelated condition (one not inherently unsafe) (we'll later define this as Z, but the developers didn't appear to be aware of a distinction just yet). (<<--- This is about the time I initially tweeted. If this test were indeed finding loads of cases of condition X, which it appeared to be doing based on the reports of range loss, then yes, this would have been a problem and a real safety issue. I was still reviewing reverse engineering of code from updates that had been pushed since then at this time, but had not made it past this point just yet.)
That code was updated hastily to implement temporary mitigation that would prevent both X+Z from being failure modes, at the expense of significant range loss (presumable temporary... it was pretty clear that at this point whoever was writing this code was aware there was no way these were all condition X).
The code was again updated to implement separate detection for Z. At this point, both paths led to being mitigated the same way with the temporary function. (<<--- This is about when I posted about the separate conditions.)
Detection for X was updated to also check for Z (since checking for X finds X+Z, but checking for Z only finds Z).
If X found and no Z, the vehicle would be immediately disabled with an error along the lines of "High voltage battery error. Vehicle will shutdown. Contact Tesla Service." (This is not the exact error message. I've seen zero reports of the specific error being noted by anyone, further confirming information from an insider that no cases of condition X, which would be unsafe, exist in the wild).
If Z detected, then mitigation for Z put in place.
Later updates tweaked mitigation for Z to lose significantly less usable capacity.
I had expected this trend to continue, but development seems to have halted/paused shortly after the initial tweaking and small rebound on capacity. I believe there's additional room for improvement, but doesn't seem to be a priority based on limited changes to the relevant functions.
Edit: Also, I've fallen behind on my reverse engineering of the most recent firmwares... so there could be changes I'm unaware of. It takes a significant amount of time to analyze and annotate changes, determine functions, etc. I've even written custom tools to streamline some of this with various modules on the Model S, but it still involves a lot of human brain power to get anything useful. Unfortunately the time I have to set aside for this sort of stuff has been limited lately.
That's as far into this as I'm getting.
