Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Tesla infotainment system upgradeable from MCU1 to MCU2

bollar

Disgruntled Member
May 1, 2013
2,667
878
Southlake, TX
Meh, signing a petition is two clicks and free. I don't think it really shows the interest of people willing to put down >$2k for a retrofit program. Now if someone were to set up a funding site with a $1000 buy in per person (to be paid towards the upgrade or refunded if it never happens), that would speak a lot louder than a change.org petition.
Sure...

Like the people who paid $3-$7K for a future FSD product?
 

ChrML

Member
Feb 6, 2017
700
962
Norway
Fist, Tesla doesn't seem to have much automated testing. Second, you cannot test everything for a car in automated testing. Third, it's not just wifi, there are other differences, line BT. Say someone designs "phone as a key" for S/X with MCU 2 - do think automated software test will catch poor performance on retrofitted cars due to lack of BT antennas in the mirrors? Lastly, you have to make sure repair procedures for technicians include how to service such retrofitted MCU. They are not engineers, they need clear directions on what to plug/unplug, or even what parts to order if things break. All that takes time and money. Elon is learning the hard way, but he is streamlining and limiting number of configurations because he learned how expensive it is to have to maintain them for over a decade. Hence no MCU2 retrofit.
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.
 
  • Informative
Reactions: Scorpyo

whitex

Well-Known Member
Sep 30, 2015
6,551
7,875
Seattle area, WA
Nobody writes code tightly coupled to environment, OS or hardware anymore.
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.

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.
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?
 
  • Love
  • Like
Reactions: MikeBur and MP3Mike

whitex

Well-Known Member
Sep 30, 2015
6,551
7,875
Seattle area, WA
Up to 1750: Assuming all those who signed are willing to shell out the $3000 that is over 5 million bucks in MCU retrofits!
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:

whitex

Well-Known Member
Sep 30, 2015
6,551
7,875
Seattle area, WA
Up to 1750: Assuming all those who signed are willing to shell out the $3000 that is over 5 million bucks in MCU retrofits!
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.
 

ChrML

Member
Feb 6, 2017
700
962
Norway
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.
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.

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?
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:
switch(Environment.HardwareRevision)
{
case HardwareRevision.MCU19:
services.CreateService<IBtService, NewBtService>(options: new {newAntenna: false});
break;

case HardwareRevision.MCU20:
services.CreateService<IBtService, NewBtService>();
break;

case HardwareRevision.MCU10:
services.CreateService<IBtService, OldBtService>();
break;
case
}

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:
IBtService bt = services.GetService<IBtService>();
if (bt != null)
{
Blabla.
}

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
Sep 30, 2015
6,551
7,875
Seattle area, WA
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.
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.
 
  • Like
Reactions: MP3Mike

ChrML

Member
Feb 6, 2017
700
962
Norway
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
Apr 14, 2018
1,981
2,239
BC
Up to 1750: Assuming all those who signed are willing to shell out the $3000 that is over 5 million bucks in MCU retrofits!

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.

Over 2000 now. And I bet over 500 of those signatures are from those who actually own a Tesla!

Wait, it’s not free?

Well it now is for Nikolaj. :)
 

MikeBur

ManualPilot
Dec 8, 2014
1,373
721
Seattle, WA
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.

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.. ;)
 
  • Helpful
Reactions: ChrML

dark cloud

Active Member
Apr 14, 2018
1,981
2,239
BC
I want to see proof that it's near impossible / too hard, and not lazyness

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.

Is it sill forced to be almost full screen only?

Yes, you see your username? That is what I see when I try it.

SC here in GTA, has confirmed to successfully performed the upgrade, and official paid upgrade coming soon. they were not sure about the cost.

Oh, we are going to need more details please :)
 
  • Disagree
Reactions: MP3Mike

About Us

Formed in 2006, Tesla Motors Club (TMC) was the first independent online Tesla community. Today it remains the largest and most dynamic community of Tesla enthusiasts. Learn more.

Do you value your experience at TMC? Consider becoming a Supporting Member of Tesla Motors Club. As a thank you for your contribution, you'll get nearly no ads in the Community and Groups sections. Additional perks are available depending on the level of contribution. Please visit the Account Upgrades page for more details.


SUPPORT TMC
Top