Macan EV Poll: Type and frequency of software-related issues you have had with your vehicle?

[Paris92]

Trying to get a general idea about how prevalent, and how serious (in your own opinion), the software-related issues have been for Macan EV owners here on the forums.

Please choose (1) how many issues you have had, and (2) the delivery window for your particular vehicle.

Poll is set up so you only have two (2) selections.

Sponsored

 

[FirstEV]

Trying to get a general idea about how prevalent, and how serious (in your own opinion), the software-related issues have been for Macan EV owners here on the forums.

Please choose (1) how many issues you have had, and (2) the delivery window for your particular vehicle.

Poll is set up so you only have two (2) selections.

Keep in mind that the main reason people are saying it is software related is due to Porsche claiming it without any evidences. Many suggestions including my issues of the car that they claim to be software related is connected to hardware. If it really is software related they would be able to reproduce it on every single car that has the same software, which would be all cars produced to date.

 

[TurboSpain]

Keep in mind that the main reason people are saying it is software related is due to Porsche claiming it without any evidences. Many suggestions including my issues of the car that they claim to be software related is connected to hardware. If it really is software related they would be able to reproduce it on every single car that has the same software, which would be all cars produced to date.

I completely agree. If these were software glitches, we'd all suffer the same problems, given that we share the same code. In my particular case, 10,000 km and 0 errors (except for one time when a warning appeared about assistance functions being restricted due to a dirty sensor). It's highly unlikely that these types of problems will be fixed with a new firmware; they likely require changes or adjustments to physical parts.

 

[ColdCase]

Good point. You could argue that the software is not robust enough to compensate for out of tolerance hardware, or provide the owner/tech with meaningful diagnostics that point to the hardware issues quickly and efficiently.

My previous life as a hardware/software integrator taught me that unexpected things can happen at the edge of envelopes and its damn near impossible to cover all the bases and get a product to market.

 

[Nshan]

My car has been privacy mode for 2 months now with no solution in sight. Even writing to Porsche UK top management hasn't helped. They are supposedly waiting for this all-curing software upgrade which will resolve issues, so I am being told

 

[PrudentOcean]

My biggest issue has been a CarPlay connection problem that I resolved by deleting my driver profile and recreating it. I’ve also seen a speed sign recognition failure warning once or twice, but those went away during the next drive cycle.

 

[kEV]

My biggest issue has been a CarPlay connection problem that I resolved by deleting my driver profile and recreating it. I’ve also seen a speed sign recognition failure warning once or twice, but those went away during the next drive cycle.

Next time I get the CarPlay issue I will try the profile route. I decided to reboot the car by disconnecting the battery and that fixed the CarPlay issue too.

 

[robrain]

For those of you saying "it's not a software problem, since everyone would have it" - have you never debugged an "illogical" issue where you can't replicate it?

Software should be deterministic, but when you blend it with real-time sensors and real-world, messy data it definitely can behave "erratically" - at least as far as the end-user is concerned. And badly written software can also behave differently today to how it did yesterday (stale caches, accumulated state etc.).

Most likely the issues some people have are to do with the interaction of software and hardware, perhaps with out-of-tolerance sensors on their vehicles or "impossible inputs" that turn out to be possible as ColdCase suggests.

 

[TurboSpain]

For those of you saying "it's not a software problem, since everyone would have it" - have you never debugged an "illogical" issue where you can't replicate it?

Software should be deterministic, but when you blend it with real-time sensors and real-world, messy data it definitely can behave "erratically" - at least as far as the end-user is concerned. And badly written software can also behave differently today to how it did yesterday (stale caches, accumulated state etc.).

Most likely the issues some people have are to do with the interaction of software and hardware, perhaps with out-of-tolerance sensors on their vehicles or "impossible inputs" that turn out to be possible as ColdCase suggests.

Software is absolutely deterministic; the same inputs produce the same outputs.
I agree that, after iterating for a certain amount of time, there are different system states that can cause errors or unexpected results. However, a complete reboot (for example, disconnecting the 12V battery for a while) would be enough to restore everything to working without errors.
If errors persist after a reboot, it's clear that there's something beyond the software, such as faulty communication buses or other hardware components, causing the problem.

 

[robrain]

If "software is absolutely deterministic" then that time I spent learning Functional Programming was probably wasted

I hope there aren't any multi-threaded systems in the car-facing bit of the Macan, but if there are then there's a million ways to get non-deterministic results. Simplest would be a race condition between threads. I can definitely see that possibility on the UI side but I really hope the car systems are single-threaded or use something sturdy like Erlang.

The same inconsistency can also be achieved between separate ECUs competing for single resources. Or assuming erroneously that a piece of data has been updated by a second ECU.

In the simple bug sphere, it's easy to get a non-deterministic answer by assuming that some list or set of data is ordered (for a list) or unique (for a set).

It's unlikely, but possible, that there are RNGs somewhere in the system, maybe to smooth the canonicalization of data, or even embedded in libraries that maybe have a sneaky randomized quick sort.

All is to say, there's a field of study regarding determinism vs non-determinism in software. And I'm fully aware we're stacking angels on pinheads.

 

[TurboSpain]

If "software is absolutely deterministic" then that time I spent learning Functional Programming was probably wasted

I hope there aren't any multi-threaded systems in the car-facing bit of the Macan, but if there are then there's a million ways to get non-deterministic results. Simplest would be a race condition between threads. I can definitely see that possibility on the UI side but I really hope the car systems are single-threaded or use something sturdy like Erlang.

The same inconsistency can also be achieved between separate ECUs competing for single resources. Or assuming erroneously that a piece of data has been updated by a second ECU.

In the simple bug sphere, it's easy to get a non-deterministic answer by assuming that some list or set of data is ordered (for a list) or unique (for a set).

It's unlikely, but possible, that there are RNGs somewhere in the system, maybe to smooth the canonicalization of data, or even embedded in libraries that maybe have a sneaky randomized quick sort.

All is to say, there's a field of study regarding determinism vs non-determinism in software. And I'm fully aware we're stacking angels on pinheads.

You're right if you're talking about software in general, but we're talking about vehicle safety control systems. This is regulated by law, and statistical or nondeterministic control systems are not permitted. You surely know that all critical systems are governed by RTOS, meaning deterministic and real-time.

 

[robrain]

I defer to your knowledge in the car sphere. Without wanting to say “but another thing”… Something not being permitted or illegal doesn’t mean it doesn’t creep into the system inadvertently. Boeing’s MAX issues provide a recent example of a similar, though not identical issue that shouldn’t be possible as far as law and best practices are concerned.

 

[PrudentOcean]

One factor that complicates the determinism aspect greatly is that I bet no two cars that we own are exactly the same. Many (if not most) of us have configured the cars with optional features, and unless they are purely cosmetic there are additional controllers or at the very least additional code paths in existing controllers to make them work.

Everything talks on an internal network, and the messages being passed around have different priorities. That greatly increases the complexity and breadth of testing. As someone who’s been a code monkey for about four decades I realize that complex systems are never perfect, so I don’t fret over minor issues.

I sympathize with anyone who has experienced major or persistent problems, but my own Macan EV ownership experience has been great.

 

[swakid8]

Picked up a 2024 CPO Macan 4 Ev last week. The only issues so far has been Apple Car Play connectivity. To solve for it, I’ve been using a thick data USB-C cable that has solved my issues….

My wife as a secondary user has been having Apple Car Play issues via Bluetooth.

 

[jwatte]

Every day I see at least one, frequently two, of these software problems:

1. When the car starts up in the morning, it starts up in a "smart lift" zone, but it frequently doesn't actually detect it's in the zone and I have to manually push the lift button.
2. The "compass heading" and "height above ground" displays in the instrument cluster setting (right area, bottom-most section) frequently get wedged into displaying "---" on startup, and never recover.

Sometimes, it does notice it's in the smart lift zone on start. Once, it noticed, but it didn't actually lift the car, so I still scraped the bottom. Then, after driving a hundred yards, it alerted that "the car is unusually low, please stop immediately." Turning it off and back on again cleared that state.

Once in a blue moon, the touch screen will lock up the Android Auto display and not react to any touches. Given that this is the car hardware sending input signals to the phone software, unclear whether it's car or phone, but the other issues are clearly the car.

Given that the air shocks work fine when manually controlled, pretty sure this is software. And given that the in-car navigation works fine even when the compass/elevation values are dashed, I think that's software, too, rather than a GPS failure.

Software nerdiness follows!

For those saying "software is deterministic": I, too, love developing in Haskell! My most productive team ever built with GHC and Warp. Good times! Sadly, not common times.

Unfortunately, these cars have dozens of separate, interacting systems that each have their own boot sequence and timing, and may be dependent on temperature, time of day, weather, satellite coverage, previous state, radio environment, state of charge, and a host of other properties. Also, this car is one of the first to use Ethernet instead of CAN bus for most of the infomatics, and as we know, Ethernet is itself not deterministic. (Neither is the CAN bus, btw! It does timing-dependent address arbitration.)

So, did network packet Q arrive before or after network packet Z, each sent from a different system? Who knows!? Now you have non-determinism in the system, even though each individual OEM component by itself is allegedly deterministic. (Of course, those components are in turn made of smaller components ...)

Sponsored