HankLloydRight
No Roads
Kickstarter requires some sort of working prototype. To truly rip peopl^H^H^H^H^H^Hcollect money like that you need to use indigogo.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Tesla infotainment system upgradeable from MCU1 to MCU2
- Thread starter MurrayJimW
- Start date
bollar
Disgruntled Member
If Tesla does not have automated testing, then that's one of their main issues. Not configurations.
Tests are only meant to catch developer errors. You typically test basic features and measure performance metrics. For each bug report, you usually try to reproduce it with a test too to ensure the same bug doesn't regress back later. There are even good tools for automated UI tests.
The main method of avoiding bugs is writing good code and not grow the services in your code too large or intertwined. Removing code is better than adding.
We developed a rather large IoT webservice written for Windows IIS servers (about 300k lines of C#). We transferred it to Ubuntu 18.04 Linux servers the other day in a Docker image under a different webserver on a completely different hardware/environment. But the code is well written, we changed almost nothing in the code. Nobody writes code tightly coupled to environment, OS or hardware anymore.
We also write code for embedded systems similar to Tesla's MCU running a ton of configurations, with non-programmer service technicians working on thess systems. But the software doesn't care that we have millions of configuration combos, because the code is written as services working independently and these services only care about their part and provide simple API's to other services.
Phone as Key-entry for example is one service. Isolated it's a really simple piece of code: If you have phone-entry capable hardware, the feature is active. If you don't it's not. This service is inaffected by the car having or not having Homelink, or having or not having 5G Wifi.
These few combos are 8 configurations, but you don't need automated integration tests for all these combos. You just need one for each function, and chief programmers that only accepts merges that account for this very simple design principle. I really hate when developers try to overcomplicate code or mix/exposes service internals, only when code like that gets into production you get side-effects because some internals changed causing a certain configuration to fail.
whitex
Well-Known Member
For cars or airplanes people do write software tightly coupled, or you won't be able to safety certify it. Oh, and you do have to re-certify when you change hardware, or OS - this is not web development.
So how does the software determine whether it's a phone-entry capable hardware? Magic ferry code? Or do you think someone will need to go figure out whether the feature works well (judgement call?) with MCU1, MCU2 and retrofited MCU2. MCU2 and retrofited MCU2 both have the same BT software capabilities, just the latter has a less capable antenna. Now repeat every feature time number of possible hardware configurations. And yes you have to retest when you modify the feature, say phone-as-key feature changed tx/rx levels to make it perform better for retrofitted MCU2, what if those new tx/rx level screw up MCU2 experience because it has different antenna? Let the customers find it?
whitex
Well-Known Member
Exactly like it if the fine print says "no guaranteed date, nobody knows when the product will actually be available".
MS85DAnthony
Member
Hey everyone there’s a petition to try to get Tesla to offer a MCU retrofit. This is in no way a guarantee to get a MCU retrofit, but it doesn’t hurt to try.
Sign the Petition
Sign the Petition
dark cloud
Active Member
Up to 1750: Assuming all those who signed are willing to shell out the $3000 that is over 5 million bucks in MCU retrofits!
whitex
Well-Known Member
Now apply the ratio of how many signed up on facebook to storm Area51 last month - over 2 million said online that they are going, another 1.5 million as interested, 4 people actually tried (and got arrested), 150 showed up at the gate, 1500 total showed up to watch. That is how meaningful free online signups are.
Last edited:
ucmndd
Well-Known Member
$3,000 is a hell of an expensive video game console. Y’all are getting desperate.
whitex
Well-Known Member
For perspective, even if there was $5M revenue behind this, that is not even worth a second thought to Tesla. Think how many millions of revenue they let go by eliminating $1,000-$2,000 pano roof option for the sake of not having to design one which lasts and/or production simplicity.
Maybe for certain features of airplanes (eg fly by wire) but I see no reason to for most of the car code. Especially the no driving part of the car. If you write all software in C++ tightly coupled to the hardware just because it happens to be running in a car, then I believe you are making a huge architectural mistake.
This is not difficult or any complex. Why is it so much worse for Tesla than the rest of the industry? We develop embedded systems too with similar problems.
Obviously the BT hardware is abstracted away from the phone-as-key service. The BT hardware has a device driver and the MCU hardware revision identifies on startup that this should create a BT service with NN configuration (tested once according to hardware).
Eg:
Now the bluetooth service exists if the hardware is capable of bluetooth and they all have a common interface. The rest of the firmware now just consumes the service if it's there, and does not care what version MCU the car has or how capable the Bt antenna is.
Eg:
Build all the software isolated and unit-testable like this and number of configurations is a non-issue. Things just work pretty effortlessly, and you never break anything later.
whitex
Well-Known Member
It isn't worse for Tesla than the rest of the industry. The difference Tesla keep on creating new configurations more often, at one point Elon boasting how they change the hardware every 2 weeks, so 26 versions a year, instead of once a year, how the rest of the industry does it. The rest of the industry doesn't try to run their latest software on 7 year old cars either like Tesla. Of course they have to for the most part, because they sold that as a feature, plus the obligation to deliver new features originally sold as vaporware.
I was thinking about the rest of the software industry.
Tesla has much more software complexity than other car manufacturers. Due to other car manufacturers following a "deliver and forget" pattern.
But at the same time the software in a Tesla has lower neccessary complexity than other software firms deliver today. Actual complexity however may be higher if they have a poor architecture.
dark cloud
Active Member
Over 2000 now. And I bet over 500 of those signatures are from those who actually own a Tesla!
Well it now is for Nikolaj.
SC here in GTA, has confirmed to successfully performed the upgrade, and official paid upgrade coming soon. they were not sure about the cost.
MikeBur
ManualPilot
Tesla appears to be much closer to general software practices than regular auto industry, creating more software in-house, running multiple permutations of software configurations, etc and purposeful separation between real-time safety-critical systems and IVI.
The complexity of their visible software is immense, the size of the software team appears smaller than required and the time for quality software process is empirically not fully comprehended already. I could only speculate at size and quality of validation of non-safety critical software. The learnings appear to be happening, and the team appears to be expanding, in China has been mentioned. At some point any active software stops, both to minimize additional permutations and because of organic code rot.
I’ve seen changes that were happening to help optimize mcu1 efforts, and supposedly this still happens in a large part because EM paying it back with long term support to the loyal initial supporters, though some because of unintended consequences of improved performance considerations between 1 and 2.
Mcu1 has a fundamental design flaw with its soldered-down flash memory, due to its overuse because of heavy initial telemetry and caching behaviors. Even with this, I would not expect upgrade path between 1 and 2.
The only way to confirm any of this is to get a job with Tesla on software team. Of course, if you did then your NDA would frustrate and prohibit you from saying more..
dark cloud
Active Member
From a company that can shoot a rocket into space and bring it back and land it on a pad, I think it is doable.
Yes, you see your username? That is what I see when I try it.
Oh, we are going to need more details please
MikeBur
ManualPilot
I’d love to be proven wrong here, though info from SC is as reliable as the TSB they show you...
