September OTA Update Coming

[violuma]

applying it in a manner which can be reverted if some updates fail.

I think Android's implementation of "rolling cold standby" where there are two boot slots and the bootloader will automatically switch to the inactive slot if the active slot fails to launch within a specific time window is pretty cool. Being able to manually switch slots has also saved my personal bacon many times.

It could even be combined with something like OpenWRT's configuration saving system, so the mothership could be informed if a particular vehicle attempted an OTA update and had to roll back, allowing customer service to reach out to the owner proactively.

Sponsored

 

[whitex]

I think Android's implementation of "rolling cold standby" where there are two boot slots and the bootloader will automatically switch to the inactive slot if the active slot fails to launch within a specific time window is pretty cool. Being able to manually switch slots has also saved my personal bacon many times.

It could even be combined with something like OpenWRT's configuration saving system, so the mothership could be informed if a particular vehicle attempted an OTA update and had to roll back, allowing customer service to reach out to the owner proactively.

Dual bootchain type systems are great, though not available on all ECU’s. There are a number of security considerations with such systems (e.g. if you patch a severe security bug, you don’t want to leave the old, vulnerable version bootable). Similar issues with safety, when do you decide to override the old image so the system doesn’t revert itself by accident for example. Then things get significantly more complicated when you have to consider updating multiple ECU’s and they have to be all on the correct versions for safety (since only a particular set of firmware versions working together has been tested). Having spent a few years in OTA, it is a very complex topic. On the flip side, then there is a human problem, engineers who oversimplify things, “just give me raw access to non-volatile memory so I can just write new code whenever”, or “I will just embed the private signing key in my software running on the target device so I can sign OTA images after downloading then so that they can be flashed and boot (for chips which require signed images)”.

Properly designed systems start with proper set of requirements and top level design/vision, which is surprisingly hard to come by in engineering organizations. You also gotta love marketing or some VP level requirements for specific implementations such as “we must support on device encryption” - absolutely meaningless unless you specify what assets are your trying to protect from whom (what type of attacker with what access). Half the time you realize they actually meant authentication, not encryption Ok, enough for now </rant>

 

[violuma]

“we must support on device encryption” - absolutely meaningless unless you specify what assets are your trying to protect from whom (what type of attacker with what access).

That's a great example, because the lock/key metaphor used for encryption is typically spot-on in many ways, the most important and easiest to explain being that "whoever has the keys has access". The sort of "on-device encryption" management envisions is far too often the sort you reference as "I will just embed the private signing key in my software running on the target device".

That's the equivalent of hiding the key to the front door under the flowerpot or welcome mat. If blackhat has physical access to the target device with keys on it, your entire system comes crashing down around you. That's what happened with CSS (the DVD kind, not the web stylesheet kind).

 

[whitex]

That's a great example, because the lock/key metaphor used for encryption is typically spot-on in many ways, the most important and easiest to explain being that "whoever has the keys has access". The sort of "on-device encryption" management envisions is far too often the sort you reference as "I will just embed the private signing key in my software running on the target device".

That's the equivalent of hiding the key to the front door under the flowerpot or welcome mat. If blackhat has physical access to the target device with keys on it, your entire system comes crashing down around you. That's what happened with CSS (the DVD kind, not the web stylesheet kind).

There a lot more intricacies to this. For example there is a perfectly valid scenario where the encryption key stored on the device is fine - if you want to protect data against leakage after "global erase operation" - in that case you can have a symmetric key on the device, the sensitive data encrypted with that key, and every time a user, dealer, or a technician does a "factory reset" you just have to effectively wipe away the key, then generate a new one. That is a valid on-device encryption usecase.

Other aspects to consider, what are you protecting. If for example you are protecting intellectual property (IP), but all devices get the very same IP, it makes no sense to provision each device with a unique key. On the other hand, if the protected information is different on each device, there a unique key provisioning may be worth the cost.

There are many other aspects of security applications, even just about encryption, but that is way beyond the scope of this forum. How you deploy what security measures is highly dependent on what it is that you are trying to accomplish, i.e. what are you trying to protect from whom. The problem is when people asking for security have no idea why they are asking, other than put to a checkmark next to some buzzword like "strong encryption" - check, supported.

 

[Alemany]

I figure a concrete example of this (in a much lower-stakes environment) is the fact that game console OTAs always carry the weird-at-first-glance exhortation not to eject removable media or attach/detach external hard disks.

If you're going to mess around on /dev/sdb3, you don't want it to suddenly become /dev/sda3 partway through because somebody kicked out the DVD that was mounted at /dev/sda.

it depends... / s /

 

[Alemany]

Terrible that we can't talk about Taycan and Porsche without the inevitable ...but...but...but...let me talk about Tesla...but...but...Tesla....have I told you about Tesla?...

Well... let me tell you about Tesla. First and foremost it starts with T......

Taycan is the first Porsche electric, lets then compare it to the VW gas powered beetle bus, now that would make more sense....

 

[Alemany]

I think it is easier for Tesla.
For a start they have no historical components and (maybe) only 1 controller and a couple of specs, so knowing what code to send to what car should be pretty straightforward.

Porsche, for better or worse, have many model variants and within those a vast combination of potentially different car controller and new plus relatively ancient code.

So first the OTA needs to know which model, does it have torque vectoring, active anti-roll bars and rear wheel steering, all of which possible combinations will presumably have to have been tested for bugs.
And that is before checking non-important combinations like electric charge ports, reversing camera combinations HUD, night view etc.

My guess is that what Tesla have to do is check whether the (non)self driving option is in there then send one of 2 updates, whereas Porsche, whether we or they like it or not, potentially have hundreds of possible combinations to comb through before sending.

The way round it would be not to have an options list so every car is the same, then it is much easier.

Note I write this as somebody who wrote software from 1970 until 1986 so maybe very out of date.

We have less Taycan variants than Tesla. The software and electronic function of Taycan are Taycan's. I see no reason why Porsche is not superior to Tesla in this area.

 

[KensingtonPark]

We have less Taycan variants than Tesla. The software and electronic function of Taycan are Taycan's. I see no reason why Porsche is not superior to Tesla in this area.

The primary reason cited by Porsche is that they have historically outsourced a lot of the core programming software functions to suppliers, which therefore requires re-validating all software changes with third parties. Tesla is believed to have significantly less of these issues since they started with their platform intending to OTA update their software. It's a reason, at least.

 

[Jasper4S]

why am I not seeing this update? I also missed the one at the beginning of July. If I search manually for updates through PCM it tells me there no updates available.

 

[snstevens]

why am I not seeing this update? I also missed the one at the beginning of July. If I search manually for updates through PCM it tells me there no updates available.

I think this video from Porsche does a nice job of covering all the bases.

 

[whitex]

I think this video from Porsche does a nice job of covering all the bases.

I might have found the reason why I don’t get these major updates. My car keeps preconditioning on for 5m after I exit the car, and according to the video, preconditioning must not be active.

 

[snstevens]

I might have found the reason why I don’t get these major updates. My car keeps preconditioning on for 5m after I exit the car, and according to the video, preconditioning must not be active.

Ah, interesting. Turn that off and let us know what you see.

 

[Fall7St8nd]

I'm all for OTA updates... but as a software engineer, I've had a few good laughs at the experience so far. I've gotten several dings and info messages that say I have notifications... yet seemingly no notifications. I've gotten several map updates that made me feel the PCM became unstable (phantom error messages that went away after power off/on). I've gotten subsequent map updates that seemed to return PCM stability (no phantom errors in several weeks... phew!). I just got my calendar update (yes! /s). I'm looking forward to what this next OTA update brings... and as long as it doesn't brick my car or require me to bring the car in for service, keep'em coming!

 

[whitex]

Ah, interesting. Turn that off and let us know what you see.

Where do you turn it off? I don’t recall seeing the setting, it’s behaved like this since I picked it up.

Edit: I also don't see the update in notifications, so not at the update ready yet I guess.

 

[snstevens]

Where do you turn it off? I don’t recall seeing the setting, it’s behaved like this since I picked it up.

Edit: I also don't see the update in notifications, so not at the update ready yet I guess.

I believe pre-conditioning is pre-cool/h. and can be found either under the battery settings, or under the air conditioning settings. There is an on off setting.

UPDATE - To my knowledge, no one has received the September OTA Update yet.