Tesla forced an update of my P85D to 2019.16.2

[MXWing]

To my knowledge, the only actual safety issue Tesla has ever fixed OTA was the early Model 3 braking issue... in which case, yeah you probably should take that update. Other than that, the rest of the claims of being a hazard in some way by not taking updates is just hand waving by people who have no idea what they're talking about. (Edit: Sorry, somehow didnt finish that last sentence before hitting post.)

The only actual safety issue that you KNOW about. Patch was publicized because Consumer Reports publicized an issue.

Nothing to see here.

Why are you being so dense? Is it hard to believe that tens of thousands of other fixes slid under "Misc patches/fixes" as small print under HEY LOOK FART MODE WHEEEEEE

Definitely a lot of cover-their-ass BS in the updates, though, which make the car less functional... and I'm definitely not cool with that.

YOU might be fine if Tesla died tomorrow, probably would make you happier. No fascists dictator to push patches to you. The rest of us would not be cool with that.

The addition of nags and other crap also is not an improvement and does not improve safety in the slightest, as proven by the fact that we still have crashes/deaths/etc to "blame" on autopilot even with them. More CYA BS they've forced on us to protect their image, not to protect customers or improve the vehicle.

So you are saying that forcing people to grab the wheel does not improve safety AT ALL? As opposed to zero nagging to where they are free to look down at their phone and NEVER up at the wheel or the road? I hate the nags too, don't get me wrong. But the nags are not for ME - they are for other clowns that puts Tesla in the headlines.

I can't believe you believe what you are saying.

If you want something to be true about Tesla, despite facts, laws, and other information contradicting what you're wanting or claiming... and you still continue to defend that position, that is fanboyism. Is there another word for it? Alternative facts? Just because you want Tesla to be allowed to do whatever they want to other people's vehicles doesn't make it acceptable, permissible, or legal.

I didn't architect patch management for Tesla but I have done it for other companies. It needs to be done period. I would argue this for anyone and everyone.

YOUR Tesla on the road has the ability to destroy mine or others which affects me indirectly.

As ridiculous as that sounds, would love to see actual data on that. Citation needed? I suspect you're actually way off, as this is totally unrelated to anything being discussed here. More hand waving. (IMO: The people who refuse to vaccinate their children are idiots influenced by other idiots and generally have no critical thinking skills whatsoever to separate out FUD from fact.) I don't see how this even remotely relates to improving the user experience of a driver assist feature.

For the record, I have electronic nag defeats on every one of my Tesla vehicles, and have well over 100,000 miles of nag free AP driving under my belt personally, with even more between my vehicles and other drivers. The "orange" (or in my case, electronic defeat device) doesn't lower safety at all, because the unneeded nags never improved safety in the first place. The only nags that were improving the usefulness of the system were the ones originally in v7.0, which appeared only when actually needed (when the car was about to be unsure of the path). The timed nags are completely pointless and do nothing whatsoever to improve safety. It's "safety theater" on Tesla's part.

Of course that data doesn't exist because no one did a study on that. I wish I had the time to carry it out as I also was educated in Economics / Statistics. Would be fun. I'm open to being proved wrong but I suspect I am not.

I'll invent a term for people with that mindset "Toxic Libertarianism". It's all about ME, be damned with the greater good of maintaining Tesla safety through herd inoculation.

In your perfect ideal world, there would be a team of engineers that would cater to your whims and desires and run back every git release to you. No one has the resources for that.

I believe Tesla will roll back the nags as the system gets more sophisticated. Too many idiots and too much control in driver hands that opens up way too many lawsuit possibilities.

Again, are you really believing that other than the Model 3 braking issue, the hundreds of thousands of code commits are not safety related...?

 

[MXWing]

S/N ratio: 0

y=k/x

to describe the relationship between IQ and EQ for some of the folks here.

 

[sublimejackman]

Sorry, gotta pick this one apart!



No they don't stop EU cars from moving around that landmass, but as soon as you're in a new region, the system sees it, and you'll start getting updates for that region. If you're on a version that has new restrictions for a region, those restrictions go into effect immediately. Just like if you drive a US car to Canada, summon used to stop working when you crossed the border because your "use_region" was no longer "US". (And vice-versa, Canadians could summon while in the US)

Also, US and EU cars are not the same and are essentially region locked. You can't operate one in another region legally, and Tesla's warranty or MVPA even notes this somewhere (can't recall exactly where at the moment, but clearly recall this).



There have been no changes to AP1... so...



No idea how or if they'll implement this on AP1 cars. There is no app data link via bluetooth to non-Model 3's.



I'm not a lawyer, but I'd venture to guess this is not actually the case. I scanned through the new regulation and didn't see anywhere that stated it had to be implemented on existing vehicles. Tesla went above and beyond by doing so, IMO, but still had no right to force the update on vehicles already "in the wild", per se.

So there should be a baseline split for different models. Like you, guy who bought car 6 years ago; here's software tailored for US P85 MCU 1 without the cold weather package. Then here M3 owner in France, you get special France software. I mean c'mon. Oh and all you EU drivers make sure you install this update, pretty please. All that needs to happen is one dude using AP1 or AP2 in the EU to crash with version 2019.12, for the EU overlords to say "see, told you so, those cars can't be trusted." All while the entire traditional Auto and Aero industries are funneling millions in to regulators' pockets in an effort to kill Tesla and SpaceX. Let's get real life here and put on our big kid pants. In reality, Tesla is not going to take any unnecessary risks. Esp so some people can read curated release notes 24 hours before they do an update (that they're not going to do).

 

[kavyboy]

All it takes is one unfixed bug in the most random of corner cases for someone to die and for Tesla to be in the headlines.
Everything caries opportunity cost. When you are negative cash, you don't divert engineers to work on v8. You just don't.
All hands on deck for v9.
When it's end of quarter push, all those v9 engineers are delivering vehicles.

That's not really how things work in the real world of software development. Bugfix patches are migrated from V9 to V8 when they impact security. There's virtually no drain on V9 development. This is a solved problem in software lifecycles.

As for "one unfixed bug (causing) someone to die", I agree. That's why I want a long-term stable version. That's also why I shake my head at the Easter eggs and fart app and all that. I know one of the games would cause the MCU to lock up, for example. The drawing app suppresses the function/updating of the map, so that's another unintended interaction. It's kind of hard to argue that a safe, known version of the software is too hard and expensive to maintain and regression test when we keep getting new "fun stuff" added.

 

[wk057]

The only actual safety issue that you KNOW about. Patch was publicized because Consumer Reports publicized an issue.

Nothing to see here.

Why are you being so dense? Is it hard to believe that tens of thousands of other fixes slid under "Misc patches/fixes" as small print under HEY LOOK FART MODE WHEEEEEE

YOU might be fine if Tesla died tomorrow, probably would make you happier. No fascists dictator to push patches to you. The rest of us would not be cool with that.

So you are saying that forcing people to grab the wheel does not improve safety AT ALL? As opposed to zero nagging to where they are free to look down at their phone and NEVER up at the wheel or the road? I hate the nags too, don't get me wrong. But the nags are not for ME - they are for other clowns that puts Tesla in the headlines.

I can't believe you believe what you are saying.

I didn't architect patch management for Tesla but I have done it for other companies. It needs to be done period. I would argue this for anyone and everyone.

YOUR Tesla on the road has the ability to destroy mine or others which affects me indirectly.

Of course that data doesn't exist because no one did a study on that. I wish I had the time to carry it out as I also was educated in Economics / Statistics. Would be fun. I'm open to being proved wrong but I suspect I am not.

I'll invent a term for people with that mindset "Toxic Libertarianism". It's all about ME, be damned with the greater good of maintaining Tesla safety through herd inoculation.

In your perfect ideal world, there would be a team of engineers that would cater to your whims and desires and run back every git release to you. No one has the resources for that.

I believe Tesla will roll back the nags as the system gets more sophisticated. Too many idiots and too much control in driver hands that opens up way too many lawsuit possibilities.

Again, are you really believing that other than the Model 3 braking issue, the hundreds of thousands of code commits are not safety related...?

Wow... that was a lot of nothing to parse through. Good grief.

First, I think maybe you've missed my Tesla "street cred" (as it's been put by others) on these matters... perhaps check into some of that before you say I don't know what I'm talking about.

As for Tesla dying, I have no feelings on it either way. They're a company. Sure, they're making a cool product, but as a company they can definitely screw up and fail like any other company. Do I want them to fail? No, of course not... and that's actually why I call them out of their BS, because if the BS continues, they edge towards failure. They can't alienate their most supportive customers. That's bad business all around no matter what the company.

As for grabbing the wheel... um, yeah, that's pretty much exactly what I'm saying. How exactly does "Apply light force" stop me from looking at my phone? It's not "Apply light force and look at the road". All it does is get people in the (bad) habit of just tugging the wheel occasionally to appease the system. Again, this does nothing to improve safety. In fact, there has been no change whatsoever in AP-blamed accidents vs vehicle count over time (last I looked at those numbers) since the implementation of the times nags. In fact, I think those numbers may even be a little higher than the glory days of minimal-nag AP1 versions, per mile. (Not sure how public that data is.)

The argument of "you can affect me" is already handled by laws applicable to vehicles in general. If my vehicle passes inspections, emissions, etc... then I'm allowed to use it on the road. Get over it. If it was built before some new law/regulation could affect it... also, get over it.

And yes, I'm saying that the Model 3 braking issue is the only actual safety issue solved via OTA updates. Have you seen a Tesla firmware "git log" ? No? Oh, um... I have. Now let's move on.

 

[wk057]

So there should be a baseline split for different models. Like you, guy who bought car 6 years ago; here's software tailored for US P85 MCU 1 without the cold weather package. Then here M3 owner in France, you get special France software. I mean c'mon. Oh and all you EU drivers make sure you install this update, pretty please. All that needs to happen is one dude using AP1 or AP2 in the EU to crash with version 2019.12, for the EU overlords to say "see, told you so, those cars can't be trusted." All while the entire traditional Auto and Aero industries are funneling millions in to regulators' pockets in an effort to kill Tesla and SpaceX. Let's get real life here and put on our big kid pants. In reality, Tesla is not going to take any unnecessary risks. Esp so some people can read curated release notes 24 hours before they do an update (that they're not going to do).

I'm actually not sure what you're trying to say here.

I'm saying there already is a split between software for various vehicle types, regions, etc... so I don't understand that particular argument.

Tesla can, and does, assign specific versions to lists of vehicles based on whatever they see fit, and they already do this. Heck, for the Model 3 Canadian cold weather thing, they literally pushed the updates to cars that reported an ambient temperature below some arbitrary amount. So like, cars parked in warm garages didn't get the update immediately, but cars parked outside in the cold Canadian winter got it in wave 1. That's the kind of granularity they have with the fleet and specific firmware per vehicle. It's impressive, honestly.

Determining updates by country/region has been implemented on their side since v5.x... so, really, not sure where this argument is coming from.

 

[sublimejackman]

That's not really how things work in the real world of software development. Bugfix patches are migrated from V9 to V8 when they impact security. There's virtually no drain on V9 development. This is a solved problem in software lifecycles.

As for "one unfixed bug (causing) someone to die", I agree. That's why I want a long-term stable version. That's also why I shake my head at the Easter eggs and fart app and all that. I know one of the games would cause the MCU to lock up, for example. The drawing app suppresses the function/updating of the map, so that's another unintended interaction. It's kind of hard to argue that a safe, known version of the software is too hard and expensive to maintain and regression test when we keep getting new "fun stuff" added.

Yeah. I always found it weird that those apps work while the vehicle is in motion, seems like an unnecessary risk. However, if I understand how the system is designed, autopilot and the main display work on two completely separate systems. Why AP works even when you reset the center display. I could be wrong.

Replicating security and safety patches back to V8 I guess could work for non-AP vehicles. It just seems like an extra step that would cost money and only help a few people who aren't really recent customers (as harsh as that sounds). I just don't see the ROI for Tesla on doing that.

 

[MXWing]

That's not really how things work in the real world of software development. Bugfix patches are migrated from V9 to V8 when they impact security. There's virtually no drain on V9 development. This is a solved problem in software lifecycles.

As for "one unfixed bug (causing) someone to die", I agree. That's why I want a long-term stable version. That's also why I shake my head at the Easter eggs and fart app and all that. I know one of the games would cause the MCU to lock up, for example. The drawing app suppresses the function/updating of the map, so that's another unintended interaction. It's kind of hard to argue that a safe, known version of the software is too hard and expensive to maintain and regression test when we keep getting new "fun stuff" added.

Who is porting the v9 bug fixes to v8?

Who is QA for fixes ported to v8 to ensure there are no unintended consequences?

Resource cost > 0.

Company is already negative cash flow.

Every agile software house on earth sets EoL on their software products.

I’m far less a fan of Easter eggs than most people and prefer Tesla work on core UI and AP functionality.

I would love for Tesla to release a framework to allow customers to set up their own views and widgets which addresses the concerns of many people here.

Those things don’t generate headlines the way that fart mode does.

Replicating security and safety patches back to V8 I guess could work for non-AP vehicles. It just seems like an extra step that would cost money and only help a few people who aren't really recent customers (as harsh as that sounds). I just don't see the ROI for Tesla on doing that.

It’s worse than zero ROI, it’s negative ROI due to forgone opportunity costs.

They are trying to crank out 1000 v9 cars weekly. Porting fixes to the old AP1 cars and older makes zero sense.

 

[sublimejackman]

I'm actually not sure what you're trying to say here.

I'm saying there already is a split between software for various vehicle types, regions, etc... so I don't understand that particular argument.

Tesla can, and does, assign specific versions to lists of vehicles based on whatever they see fit, and they already do this. Heck, for the Model 3 Canadian cold weather thing, they literally pushed the updates to cars that reported an ambient temperature below some arbitrary amount. So like, cars parked in warm garages didn't get the update immediately, but cars parked outside in the cold Canadian winter got it in wave 1. That's the kind of granularity they have with the fleet and specific firmware per vehicle. It's impressive, honestly.

Determining updates by country/region has been implemented on their side since v5.x... so, really, not sure where this argument is coming from.

BASELINE SPLITS! Like specific and separate version of the software for each variation. Right now there is one unified source code for all vehicles. The only was for a P85D non-AP to retain the visual stylings of V8 (while AP cars use V9) but still gets security updates would be to have two seperate sets of code that split from each other.

 

[wk057]

Yeah. I always found it weird that those apps work while the vehicle is in motion, seems like an unnecessary risk. However, if I understand how the system is designed, autopilot and the main display work on two completely separate systems. Why AP works even when you reset the center display. I could be wrong.

Edit: Whoops, not sure how this didn't get posted right the first time:

Correct, the systems are partitioned. The infotainment stuff has nothing to do with core vehicle control... just creature comforts (HVAC, mainly).

Replicating security and safety patches back to V8 I guess could work for non-AP vehicles. It just seems like an extra step that would cost money and only help a few people who aren't really recent customers (as harsh as that sounds). I just don't the ROI for Tesla on doing that.

Who is porting the v9 bug fixes to v8?

Who is QA for fixes ported to v8 to ensure there are no unintended consequences?

Again, no need to do this at all.

First, nothing that is actually a safety patch exists for S/X pre-AP2. So, that's a non-issue.

Next, the only "security" patches done since v8 have been patches to keep owners out of their own cars... not actual patches that affect the actual security/safety of the vehicle whatsoever. There were a couple of actual security issues in late versions of v7.1 and earlier, but those were corrected soon after I reported them.

So, no... this is a non-argument.

 

[wk057]

Right now there is one unified source code for all vehicles. The only was for a P85D non-AP to retain the visual stylings of V8 (while AP cars use V9) but still gets security updates would be to have two seperate sets of code that split from each other.

This is not the case. There are at least a dozen different variants of the software. There are some core endpoints that most end up as: MCU1 S/X, MCU2 S/X, Model 3 ICE, Semi, Roadster2, APE2, APE2.5, APE3... then there are some region specific branches, there are even branches for some taxi fleets (which limit torque and such)... this is all dealt with pretty easily, too, and pretty automated.

Again, see some posts above... there's no need to backport anything anyway, so, non-issue.

 

[sublimejackman]

Again, no need to do this at all.

First, nothing that is actually a safety patch exists for S/X pre-AP2. So, that's a non-issue.

Next, the only "security" patches done since v8 have been patches to keep owners out of their own cars... not actual patches that affect the actual security/safety of the vehicle whatsoever. There were a couple of actual security issues in late versions of v7.1 and earlier, but those were corrected soon after I reported them.

So, no... this is a non-argument.

Well if this is truly the case, (which as someone who has never seen the source, I can't say) then would you be okay with Non-AP Teslas just being EoL with V8? Would it just made more sense for Tesla to say "no more updates." Then how long would the Tesla, Google, AT&T servers continue to support EoL non-AP cars? Any other scenario costs money to implement and this scenario could potentially hamper improvements to the Tesla API. Again, weighing all the facts, I would have made the same choice Tesla did.

 

[sublimejackman]

This is not the case. There are at least a dozen different variants of the software. There are some core endpoints that most end up as: MCU1 S/X, MCU2 S/X, Model 3 ICE, Semi, Roadster2, APE2, APE2.5, APE3... then there are some region specific branches, there are even branches for some taxi fleets (which limit torque and such)... this is all dealt with pretty easily, too, and pretty automated.

Again, see some posts above... there's no need to backport anything anyway, so, non-issue.

So you're saying that all these different models in different countries, getting the same build number; are actually getting different baselines of the software?

 

[wk057]

Well if this is truly the case, (which as someone who has never seen the source, I can't say) then would you be okay with Non-AP Teslas just being EoL with V8? Would it just made more sense for Tesla to say "no more updates." Then how long would the Tesla, Google, AT&T servers continue to support EoL non-AP cars? Any other scenario costs money to implement and this scenario could potent hamper improvements to the Tesla API. Again, weighing all the facts, I would have made the same choice Tesla did.

Good question. I'd say overall, I wouldn't be okay with it since Tesla originally promised that the car would always improve over time. Since they didn't put a specific timeframe on that, I'd say it's a grey area.

At the same time, the non-AP cars and AP1 cars are basically EoL on the software side of things. They're received very little at all outside of changes needed to keep online services, maps, etc working. Easter eggs are neat, but are not improvements, and as argued here the UI has only really gone downhill... so, *shrugs*

I think they should specify at purchase that they'll support the vehicle hardware with software updates for a set period of time, and be required to do so for that long... and after that, if they continue to do so, kudos, if not, oh well.

 

[wk057]

So you're saying that all these different models in different countries, getting the same build number; are actually getting different baselines of the software?

Yes. They're not running the exact same software, despite the build number being the same. That just means the system used that commit as a base for building the specific versions of the firmware needed for the various vehicles, not that it's the exact same software.

Here's an example (just the core variants, none of the other specific branches):

$ sha256sum 2019.12-4229-e255ff0ffe*
f7d914333cee1a9ec0172a08fc3aeb2e0cac023a48c39cc1b7147fc199b6d1d2  2019.12-4229-e255ff0ffe.model3
61d212c6ffc938d673f98f48aa5c1eeb8180d95c93d66cf83ea9ae2e8bb6a8ee  2019.12-4229-e255ff0ffe.model3.ape
c37bbc2edce657f577078315d616037ad937ec143fb8f44ecace270afd676dcf  2019.12-4229-e255ff0ffe.model3.ape3
5f4641d539c7336d05499138bbc644b5c796b2e0bd3e2fdd490743c9f43d1572  2019.12-4229-e255ff0ffe.models
0daa513c749a2da9fbc011d2518a8b3f8739905fe856aa3916ff71086edf321c  2019.12-4229-e255ff0ffe.models.ape
703d384d463207729cbe0c98b299bc202be6330f8f007a0cd3f517a83b02691a  2019.12-4229-e255ff0ffe.models.ape25
909ca1ab73fb00d720e6824ad729bd107bb27306e2909c88c1501321b27950ac  2019.12-4229-e255ff0ffe.models.ape3
cc8759b70f1e29829400a70d3ecc384a35d19949f82221615d8ea8895c186130  2019.12-4229-e255ff0ffe.models_info2

 

[sublimejackman]

Yes. They're not running the exact same software, despite the build number being the same. That just means the system used that commit as a base for building the specific versions of the firmware needed for the various vehicles, not that it's the exact same software.

If that's the case, I stand corrected. I've been doing software development since 2008 and build numbers have always been unique. The whole reason we use them. However, I've never worked on project at the scale of Tesla, so I could be mistaken. Just seems like a weird choice.

 

[sublimejackman]

Yes. They're not running the exact same software, despite the build number being the same. That just means the system used that commit as a base for building the specific versions of the firmware needed for the various vehicles, not that it's the exact same software.

Here's an example (just the core variants, none of the other specific branches):

$ sha256sum 2019.12-4229-e255ff0ffe*
f7d914333cee1a9ec0172a08fc3aeb2e0cac023a48c39cc1b7147fc199b6d1d2  2019.12-4229-e255ff0ffe.model3
61d212c6ffc938d673f98f48aa5c1eeb8180d95c93d66cf83ea9ae2e8bb6a8ee  2019.12-4229-e255ff0ffe.model3.ape
c37bbc2edce657f577078315d616037ad937ec143fb8f44ecace270afd676dcf  2019.12-4229-e255ff0ffe.model3.ape3
5f4641d539c7336d05499138bbc644b5c796b2e0bd3e2fdd490743c9f43d1572  2019.12-4229-e255ff0ffe.models
0daa513c749a2da9fbc011d2518a8b3f8739905fe856aa3916ff71086edf321c  2019.12-4229-e255ff0ffe.models.ape
703d384d463207729cbe0c98b299bc202be6330f8f007a0cd3f517a83b02691a  2019.12-4229-e255ff0ffe.models.ape25
909ca1ab73fb00d720e6824ad729bd107bb27306e2909c88c1501321b27950ac  2019.12-4229-e255ff0ffe.models.ape3
cc8759b70f1e29829400a70d3ecc384a35d19949f82221615d8ea8895c186130  2019.12-4229-e255ff0ffe.models_info2

Well doesn't this just deflate my entire case. I'm not sure why non-AP cars were forced to update then. Without knowing more, I will bow out and say that I was wrong.

 

[wk057]

If that's the case, I stand corrected. I've been doing software development since 2008 and build numbers have always been unique. The whole reason we use them. However, I've never worked on project at the scale of Tesla, so I could be mistaken. Just seems like a weird choice.

It's definitely weird, and kind of hard to explain.

Like, there is a Model 3 base code set... and it uses a lot of a common code set, but changes there won't necessarily affect Model S/X. There are global changes that are handed all the way down, there are list-specific changes, etc. But, when they do a build, that build number is for everything as it falls together at that time, for all variants, etc. For example, I have versions in my collection that are basically identical for some variants across hundreds of builds, but were built as part of a whole build after a change to a particular variant, despite no changes to the others.

 

[sublimejackman]

It's definitely weird, and kind of hard to explain.

Like, there is a Model 3 base code set... and it uses a lot of a common code set, but changes there won't necessarily affect Model S/X. There are global changes that are handed all the way down, there are list-specific changes, etc. But, when they do a build, that build number is for everything as it falls together at that time, for all variants, etc. For example, I have versions in my collection that are basically identical for some variants across hundreds of builds, but were built as part of a whole build after a change to a particular variant, despite no changes to the others.

Thanks for clarifying how their system works. I was looking at it through my experiences. Cheers!

 

[sublimejackman]

@HankLloydRight The way software is handled by Tesla was explained to me by @wk057. With this new information, I do not see why it was necessary for Tesla to blindly force a software update on you. Without any additional information, you were right.