Mr H
Active Member
Tesla should allow other cars to charge just as IONITY do, but they should be billed an extortionate price too - No Tesla Sir, that will be £2 per kwh then.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Non Tesla on a supercharger?
- Thread starter Columbo
- Start date
Sean.
Active Member
Drew57
Active ember
This could be as game changer for my next car - may well choose another brand if the supercharger network was freely available because much as I love the cars, I cannot approve of the cavalier way so many customers are treated and the erratic pricing model.
Without one of Teslas' main USPs there won't be such a compelling reason to remain loyal.
Without one of Teslas' main USPs there won't be such a compelling reason to remain loyal.
LukeUK
Member
pdk42
Active Member
Astonishing - just as they're extracting cash from owners on the Premium Connectivity scam.
pdk42
Active Member
I agree. If it weren't for the pathetic state of public fast chargers, I'd certainly be looking at other marques if I were in the market.
bitmanEV
Member
A whole bunch of EVs charging on SC
This is simply a software bug at the moment
Tesla V3 Superchargers Surprisingly Charge Other EVs For Free
This is simply a software bug at the moment
Tesla V3 Superchargers Surprisingly Charge Other EVs For Free
Glan gluaisne
Active Member
Things like this don't do much for Tesla's reputation when it comes to software. Not as if this is a one-off, as we know that there was a software bug that made all Model 3s non-compliant with IEC61851 (the charge point international technical standard) for months, in direct contradiction with the approval certification Tesla claimed to have. I think most of us have probably seen evidence of software updates that have broken things that previously worked OK, too.
The circumstantial evidence suggests that Tesla's software QA is pretty poor, and as a lot of their software is safety-critical, that does leave a bit of a question mark as to how trustworthy any of it is. The "move fast and break things" approach shortens the development time, but if that approach isn't combined with a robust QA system, then it can be prone to letting bugs get out into released code. Some of the software failings we've seen indicate that software is barely given any form of rudimentary testing. Both the Model 3 non-compliance with IEC62851 and the Supercharger bug were very obviously defects that could have been picked up with a rudimentary functional test. Heck, the Model 3 charging bug could be found in 30 seconds by any electrician with the ability to simulate all the control pilot states. Dead easy to do with just the UMC plugged into a 13 A outlet, no test equipment was needed at all.
The circumstantial evidence suggests that Tesla's software QA is pretty poor, and as a lot of their software is safety-critical, that does leave a bit of a question mark as to how trustworthy any of it is. The "move fast and break things" approach shortens the development time, but if that approach isn't combined with a robust QA system, then it can be prone to letting bugs get out into released code. Some of the software failings we've seen indicate that software is barely given any form of rudimentary testing. Both the Model 3 non-compliance with IEC62851 and the Supercharger bug were very obviously defects that could have been picked up with a rudimentary functional test. Heck, the Model 3 charging bug could be found in 30 seconds by any electrician with the ability to simulate all the control pilot states. Dead easy to do with just the UMC plugged into a 13 A outlet, no test equipment was needed at all.
Pagemakers
Active Member
Sean.
Active Member
Editor at Mail on Sunday trying to decide on this weeks headline... “Tesla Free Fall” or “Tesla Free For All” 
ACarneiro
Active Member
Whilst I wholeheartedly agree with your sentiment (and have voiced similar opinions in the past), in all fairness it doesn’t appear that any software update has ever broken any of the safety-of-life systems so it may well be that there is a core software that is subjected to a much more robust QA process.
That would make sense. Breaking charging is inconvenient but not A Huge Deal (never made it to the papers). A software update that would break steering or braking would certainly be all over the press and cause incalculable reputational damage.
Glan gluaisne
Active Member
I hope you're right, although that suggests that Tesla have two separate software QA systems, one for safety critical code and one for non-safety critical code. In turn that also suggests that someone, or some team, has to determine which software QA approach is used for any particular code branch, and that itself isn't a particularly robust approach, IMHO.
I've experience of managing an aircraft procurement a few years ago, where code had been developed, without the team doing the work fully realising that the code they were working on was flight safety critical. It was code for an engine control system, a FADEC, for an engine that had been developed for a wide range of uses. The code had been written in C, and compiled on a popular commercial compiler. When we (as in the UK) wanted to independently verify the code, so that it could be certified as safe to fly, it was discovered that the compiler used wasn't certified. When a certified compiler was used the code didn't behave as expected. A close look at the source code, with a static code walk through, showed that it was inherently unsafe. Caused a bit of a stir with the team in the US that had written the code, but it remains firmly lodged in my memory of the hidden risks that can exist in complex code (not that the code in question was particularly complex).
LongRanger
Active Member
You only have to look at the Boeing Max to understand how reliant we all are on software that just isn’t thought through from the end user perspective. I am trying to find (and struggling to get) product/user experience specialists who have a background in being the end user with an understand of how software engineering should be influenced by the experience that is delivered. It’s not easy, as 99.9% of all software engineers I interview don’t have the tools in the brain to see things differently.
This is different from the SuC issue but it’s all part of “Quality Engineering” which we will see become more and more to the fore of our experience with all electronics.
Even Apple have issues with this btw, it’s not just Tesla.
This is different from the SuC issue but it’s all part of “Quality Engineering” which we will see become more and more to the fore of our experience with all electronics.
Even Apple have issues with this btw, it’s not just Tesla.
Last edited:
Glan gluaisne
Active Member
Years ago, Toyota went to some lengths to reassure early adopters of the first generation Prius that their "drive by wire" systems were safe. They published a small booklet on how they verified safety, and their approach looked robust. They started from the premise that it was impossible, or at least exceptionally difficult, so undertake a 100% test that covered every possible combination of driver input, external conditions and car system behaviour and faults. Their way around this was to take the "there's only one way to eat an elephant, one bite at a time" approach. They divided the systems in the car up into semi-autonomous sub systems, that were simple enough to allow 100% testing of each. They then only had to ensure that all the I/O conditions for each sub-system were very well defined.
It seemed to me to be a robust approach, as it effectively firewalled the various sub-systems from each other, allowed 100% testing and gave owners (who bothered to ask Toyota for the booklet) reassurance that, for example, the steering system and braking system had been tested for every possible combination of I/O.
The major snags with this approach was that it probably didn't scale well, and that it was difficult to update. It did seem robust though, as in 13 years of Prius ownership I never once saw any software glitch.
It seemed to me to be a robust approach, as it effectively firewalled the various sub-systems from each other, allowed 100% testing and gave owners (who bothered to ask Toyota for the booklet) reassurance that, for example, the steering system and braking system had been tested for every possible combination of I/O.
The major snags with this approach was that it probably didn't scale well, and that it was difficult to update. It did seem robust though, as in 13 years of Prius ownership I never once saw any software glitch.
Glan gluaisne
Active Member
True, but they seem to still be way ahead of Microsoft. I recently bought a Macbook Air, and it does indeed just work. Nothing glitches and the only very slight issues have been because I prefer to use Firefox and Thunderbird, and MacOS doesn't seem to play nicely with my customised UserChrome.css file. It's mildly annoying, but nothing like as annoying as trying to get Windows to work as I prefer. As for Android, then all I can say is that it's been a total PITA compared to iOS, and although iOS has its quirks, at least it's consistent, something that doesn't seem to be the case with Android.
ACarneiro
Active Member
Similar threads
- Question
