The before/after ECU layout diagram is very instructional.
I like to imagine some kind of engineering “meet cute” whereby, one random day, the headlights engineer and the parking radar engineer happen to be working on the front of the car together. Their eyes meet:
“hey, I’m John — I didn’t know you had an ECU here!”,
“hi, I’m Claire — wow, you have an ECU right up front too? It’s, like, right next to mine and we never knew!”
“I know, crazy right?! Hey this is going to sound really forward and I don’t normally do this but I’m only running at 70% compute capacity. I don’t suppose you need any real-time budget this evening?”
“So funny you should ask, I was just about to run a whole bunch of heavy new wiring to…”
And in a story as old as time they get ECU married and raise their control loops in the same front-of-vehicle ECU together instead of living their separate, lonely, ECU-right-next-to-each-other-and-they-didn’t-know-it lives.
The electrical wiring in cars is Conway's law manifest in copper.
For those unfamiliar with Conway's law, I am arguing that how the car companies have organized themselves--and their budgets--ends up being directly reflected in the number of ECUs as well as how they're connected with each other. I imagine that by measuring the amount of excess copper, you´d have a pretty good measure for the overhead involved in the project management from the manufacturers' side.
It's interesting to think about the failure modes here.
With domain-based ECUs, a failure means your locks OR windows OR windshield wipers stop working.
With zone-based, it could be the entire "west" zone that stops, which means you can't unlock the driver's door, open the windows, adjust the seat, and maybe even the ventilation fans don't work
I actually thought a lot of that was already on the CAN bus anyway, but my knowledge of cars stops there so maybe someone can fill in the gaps. Seeing only three "zones" is actually surprising to me. As I was reading I started forming the idea of a single bus cable that went around the car, with I/O modules anywhere there were physical buttons/lights/etc. There would just have to be a cost+weight balance of where it makes sense to stick a small I/O module vs run individual wires back to a bigger module. My assumption is as technology advances it becomes cheaper to have more small I/O modules with very short wire runs to buttons, but it doesn't seem like this is what they're doing.
I am also making the assumption this is "dumb I/O", and somewhere there is a "door lock" program that handles all locks/buttons. In the main computer you'd run all the domain programs individually/isolated, but there would still be a single program responsible for each domain, eg: all the locks (eg: considering button presses, fob buttons, door state, moving or not, etc, and act on the locks accordingly).
From a pure software point of view, if the east/west/south ECUs are actually doing the logic for their respective parts of the car, that seems like a nightmare to build: the code would end up being all partial and distributed. In the worst case you end up with bizarre bugs like "if you open the passenger door, then open the tailgate, then close the passenger door and press the lock button, the driver's door will lock but the passenger won't until you first unlock then shut everything" (which gets reported as "the locks are unreliable, some will randomly just not work every few days").
> "if you open the passenger door, then open the tailgate, then close the passenger door and press the lock button, the driver's door will lock but the passenger won't until you first unlock then shut everything"
I have a Jeep where the dome light logic has a problem like that. If you open a door, the dome light comes on. When all doors are closed, but the engine is not running, the dome light dims out after a delay.
If the engine is running or is started in the all doors closes, dome light on situation, the dome light goes out. If you open the tailgate, the dome light comes on as well. That's all normal.
But if I open a side door, then close it, and the light times out and dims, then, for some period of time thereafter, opening the tailgate will not turn on the light. I can just see some horrid mess of IF statements written in C behind this.
Distributed systems are hard, more so in a real-time environment. If you can reduce the number of components or the need for them to communicate they will almost always become more robust and also easier to code.
Rivian added some network redundancy and central monitoring to make this design safe, but otherwise the core design principle was basically KISS.
> The system includes an array of 11 internally developed cameras and five radars performing over 250 trillion operations per second, which Rivian says is an industry-leading statistic
I generally like what they are doing with their overall architectural simplifications, but gee-zus; the feeling of complexity I get from that one statement leaves me with the feeling of "it's just a car man... it takes us from point A to point B... is all that really necessary?"
> With zone-based, it could be the entire "west" zone that stops, which means you can't unlock the driver's door, open the windows, adjust the seat, and maybe even the ventilation fans don't work
From my reading, I thought the important parts were on their own dedicated ECUs (7 ECUs, 3 zones). Battery management, driving related stuff, infotainment, door mechanisms, etc have their own ECUs. The three zones are for smaller things that are probably important but not urgently important.
Some cars work this way logically already. If you scan my Audi with a compatible tool it will read various functional modules. If one dies than that modules’ systems go down but other nearby functions work. Child locking is a separate unit from door locking and as a result in my car my driver side rear door will lock in such a way that only the inside manual latch will open the door.
The dealer can’t figure out the issue four years in.
When I read this, my first thought was: Why do these ECUs have any deep logic at all? I would have expected all logic to be centralized at one point (or in a few points, but with each domain localized to one of them), and everything at the edge be dumb(1) port extenders. That's a single point of failure, of course, but as far as I understand the zonal approach has those too -- multiple SPOFs, actually. At least when it's a single SPOF, that problem can be better mitigated.
(1) "dumb" meaning no decision-making logic. It could still mean a lot of decision-less logic, from button debouncing to input signal filtering/processing and outputting compressed audio streams.
Some door locks will trigger the servo every time you hit the heron (older-ish cars) and some have a sensor. Not clear to me if it’s a remote sensor or some sort of smarts in the local mechanism.
Given some of the chip shortages of recent year, I’m curious how the teams responsible for those trade offs made the balance.
https://news.ycombinator.com/item?id=38576612: The move to 48V means much less power is lost (power loss = (IxI)xR ), cables can be much smaller, cables and terminals can be much lighter and much less copper can be used used.
SELV is often capped at 60 V, not 50 V, although this is often treated as “48 V with crappy bounds”. An example that takes advantage of this would be PoE, which allows 44 V - 57 V at the PSE; but most PSEs are, in my experience, in the 54 - 57 V range.
Only for 48 V systems that have a battery, which does not apply to PoE, and does not apply universally to 48 V automotive approaches (although the CyberTruck does use a 48 V battery).
We're talking about the LV rail (nominally 48 V or 12 V) in an electric car. There are two design paths here -- you can have an HV to LV converter capable of supplying the average load, and have an LV battery; or you can have an HV to LV converter capable of supplying the peak load, and save the cost, weight, and failure rate of an LV battery. Tesla chose the former, but it's not the only path here.
Sure, in an EV it's possible to choose not to have that second battery. In an ICE car, it's needed to start the engine. So at least the ICEs are much more likely to settle for 48V than something closer to 60V, to leave room for charging. The manufacturers that make both ICEs and EVs are going to want to share components, so the pure-EV components are likely going to be built for 48V too.
There are massively diminishing returns. 1kW at 12V is 83A, which needs a rather beefy wire that is expensive to buy, annoying to route, difficult to route, and needs careful termination with large tools. 1kW at 48V is ~20A, which can be done with 12 gauge wire, which is not bad at all to work with.
Few microcontrollers even need 5V anymore. But your general concern sounds like something that might have been a problem in the ‘90s, but step down switching regulators are dirt cheap and a lot more efficient now.
Not really, if the converter's switching it should be fine either way. Generally you would want to tune it for the input voltage but in many cases the input range is large.
"In order to facilitate the automation of manipulating cables, Tesla has been reducing the length of wiring harnesses in its vehicles.
Musk said that Model S has about 3 kilometers of wiring harnesses and Tesla brought it down to 1.5 kilometers in length for the Model 3.
But that’s just the beginning. Tesla is working on a whole new wiring architecture for future vehicle platforms and they aim to bring it down to just 100 meters starting with the Model Y."
The legacy car makers have flirted with 48V components for decades but haven't been willing to do the hard work to realize all the benefits it brings. The germans in particular are stuck in limbo. For their PHEV and BEV cars they are shipping 12V for all traditional functions, 48V for advanced functions like active suspension and anti-roll bars, and high voltage systems for the traction motor. Complete mess.
It's frustrating to be a Tesla owner. For every great engineering choice they make like going all in on 48V they make a user hostile choice like removing stalks and selling "full self driving" that is downright dangerous.
The problem is for the whole industry to go 48V costs money and whoever pays will also benefit the competition because everyone has the same suppliers. There needs to be some kind of industry regulation that says by so and so date everything had to be 48V.
The single most frustrating thing Tesla did re: Power was not allowing me to plug an appliance in. We lose power somewhat regularly where I live due to storms, and the tesla has 6-10 days of my household power budget sitting in its banks. Just let me plug in a deep freezer and coffee maker, please.
INB4 the 12V terminals: They are hard to access, have limited amps, and are a separate crappy battery.
For sure, but the economics don’t work out for the earlier Bev battery chemistry’s. The additional cycle where from v2x don’t justify it, getting a power wall just makes more sense in the long run.
But I still agree the option should be there for emergencies
The thing is, Tesla is the only large battery I can put in my house, according to local regulations (I can get solar+battery, but the solar provider terms in my area are garbage, and I can only sell power to local company and get credits for later use. I can't actually store it).
In my homebrew BEV I've started just using AC for most smaller things. It's easier than finding 48v components, the connectors are nicer than 12v (I've really come to hate cigarette lighter plugs) the high voltage means the conductors can be small and the zero crossing means the switches can be much cheaper too.
And being able to find replacement parts at the dollar store no matter where you are is really great.
> selling "full self driving" that is downright dangerous.
Is there evidence of this, at this point?
I haven't looked into it in several years, but back then, Teslas were getting in fewer accidents per driver mile than average. I would think given that there's a faction of the public, and especially of the activist public, who are hostile to Tesla/Musk, that if FSD is in fact more dangerous (which would mean more accidents per driver mile), there would be a good URL you could provide us which makes that case using the available statistics on the subject.
Because it's an entirely empirical question. Anyone can argue from first principles in either direction, but one of two things are the reality: either FSD driver miles are less prone to accident than average, or they're more so. I suppose it could be precisely at 50%, as well.
either FSD driver miles are less prone to accident than average, or they're more so. I suppose it could be precisely at 50%, as well.
This has been proven false by Tesla's own data released to the NHTSA. Teslas have more accidents per vehicle than any other cars with advanced cruise control from every other automaker in the world combined. And that doesn't even include the far worse accident statistics for 2023 and 2024.
There were three Tesla-related fatalities in the past week in the U.S. alone, including one in which the design of the Cybertruck is thought to have contributed directly to the death of its driver. Teslas get into so many accidents that news media don't even bother to report on Tesla-related accidents anymore unless someone dies.
You are confusing a claim - specifically that “Teslas are dangerous” or “FSD is dangerous” with a much broader reality; that all Cars are dangerous.
You assert that 3 people died this week due to Tesla related fatalities in the US alone. That adds up to more than 150 per year! But considering that Tesla’s comprise 5% of the car market, that 150 is a drop in the bucket compared to the 43000 that die in car accidents in the US every single year.
Tesla’s fully autonomous self driving is about as safe as a regular person. Many of it’s “accidents” as shown by the various investigations have shown that “drivers” in the plurality of cases had several(>5) seconds to react but failed to do so.
The curious case of Tesla’s safety record will one day be a case study in every undergraduate business class. The naysayers want to see the company fail, the CEO fail, or the technology fail. But the problem is not the technology, but rather the people using it. It’s been long known that increasing protective equipment in sport decreases minor injury but paradoxically increase the likelihood of severe ones.
Why? Because people are lulled into a false sense of security. Individuals take risks they would not otherwise due to the inhibition of the natural feedback mechanism that would otherwise deter them from continuing to push the bounds. Since they keep getting away with it, they continue to push, only to discover that the failure mode has gone from mild to extreme.
Those small injuries are the warnings that keep you safe and prevent you from taking greater and greater risks.
Technology is like that. Cars are safer now than ever. Seat belts, crumple zones, air bags - and yet looking at the statistics you would never know it. This has led to urban legend like cars in the 1940s being “safer” due to their all steel construction. But this is not true.
What is true is that people drove slower in the 1940s. Most highway traversal occurred at a mere 40 miles per hour. A far cry from the 80 everyone does on the way to work today. As safety increases so too does our tolerance for risk.
Ultimately, that is the problem with self driving cars. They work too well. They unintentionally encourage drivers to take greater and greater risks. And they get away with it. Until suddenly. They don’t.
No, I think you're trying to obfuscate the fact that Teslas are objectively more dangerous than their competitors' cars by claiming that all cars are dangerous, when that is not true, at all.
Teslas get into more accidents than competitors' cars on a per mileage basis, ona per capita basis, and on a per vehicle basis and that's even though Tesla buyers come from the group with the lowest rate of accidents...when driving non-Tesla vehicles.
This cannot be repeated enough. Even though Tesla drivers come from the safest group of drivers when they drive non-Tesla vehicles, these same drivers have far more accidents when driving Teslas. What's more likely, that thousands of people suddenly became dangerous drivers when they bought a Tesla, or that the common vehicle they all bought is dangerous?
> Tesla’s fully autonomous self driving is about as safe as a regular person. Many of it’s “accidents” as shown by the various investigations have shown that “drivers” in the plurality of cases had several(>5) seconds to react but failed to do so.
It's not fully autonomous if the drivers have to react. No idea if it's safer or not but the naming is terrible.
And that’s honestly a fair critique. I think Elon is definitely an optimist in his technological ambitions. The whole naming of the drive assistance features from Tesla is kind of convoluted and confusing. I think Autopilot, Fully-Self Driving, all of them could have been termed better. I think he sold a dream before it’s time. And I think the pivot away from using LiDAR was probably a mistake as well.
The maxim of make it work and then make it work better probably applies. He has repeatedly said that since humans only need 2 eyes to drive, AI should too - but that completely ignores the neurological differences between a camera outputting a flat 2d image and the complex make up of our eyes. There is a lot happening there behind the scenes, abstracted away by our brain, that he discounts.
Anyways, yeah, I agree. My only concern is people turning against self-driving because of implementation failures in the short term. Self-driving is going to save lives. Let’s not throw the baby out with the bath water and discount the work being done by people who aren’t Elon. If you seperate FSD from the politics, the business, the fandom, it is an amazing piece of technology. A computer is now driving as well as a person. Like that’s insane. In a different circumstance we would be applauding it in amazement. That team has done amazing work.
To do proper statistical analysis, you'd need to compare miles driven with FSD to miles driven by humans in similar conditions. That's not the easiest thing to do. Tesla had occasionaly released statistics with their earlier driver assistance technology, but without enough detail to form informative comparisons. Based on past experience, I don't expect Tesla to provide meaningful statistical data or to allow outside access to their raw data (which fwiw, seems like a huge privacy risk to collect), so I don't think we'll have an empirical result unless there's discovery for a lawsuit.
Extensive analysis of Tesla and NHTSA crash reporting (some by NHTSA themselves) shows that autopilot and fsd do not have significantly better safety outcomes than manual drivers or drivers aided by other non-tesla assistance systems.
This NHTSA report is pretty damning about Tesla's cavalier attitude towards the design of safe systems.
> The legacy car makers have flirted with 48V components for decades but haven't been willing to do the hard work to realize all the benefits it brings
Can you name some benefits ? ICs working at 48 V are expensive and hard to find.
Power ICs operating at 48V are common and cheap, because things like telco have been using 48V DC for decades.
In terms of things like digital ICs, well they have never worked at 12V either. You have a step down converter to produce the 3.3 V, 1.8 V etc. rails they need.
The diagrams for the new west south and east zones still show a lot of wires going all across the vehicle. This step might be a good first one to reduce the number of ECUs by combining them, but there is still the same cross-car wiring. You still seem to have a single ECU per function, but merged into a few dedicated boxes for example.
Next step: Each wire only goes to the nearest box. I'm curious how the Tesla unboxed architecture will eventually play out. I understand that eventually, the ECUs will be split up, so you have some aspect of each ECU in each corner of the vehicle. Part of the "lights" function is in front-left, part of it in the back. Wires only go to the nearest box.
A powerful vision, with the potential to further reduce wiring. Complex until you get a distributed brake ECU.
I've been a (somewhat successful) advocate of similar approaches at the automakers I've worked for, but it's not as simple as the article makes it sound. Individual components in each "zone" can have different reliability requirements, for example. They also might be produced by different suppliers, or only be present on certain models / trims.
Rivian is able to do this because they're taking advantage of modern heterogenous processors and they haven't made the mistake of outsourcing almost all of their software capabilities to tier 1,2,3 suppliers. Legacy OEMs find it much more difficult to adopt, especially once the institutional inertia takes over.
See gregmac's comment, it changes the failure modes and makes what could be isolated subsystem failures larger regional failures. However, components are also becoming much more reliable so this is an engineering tradeoff. Cases can be made in both directions.
EDIT: That's not the only tradeoff, but it is a key one.
Replacing word ECU with micro-controller makes number seem less insane. Okay, PCs are having less and less components. But one might ask why do so many components have any logic at all? We got extremely insanely powerful central CPUs with loads of memory and storage space. So why not just do absolutely everything there?
Remove any logic and computing from screens, keyboards, mice, SSDs, HDDs, off load everything from network chips and sounds chips. Just move all of it to CPU?
I think you'd want at least some "dumb" logic moved to the periphery, otherwise everything has to be conected directly to the CPU and you would still end up with tons of wiring. Also, some functions done in the periphery are ideal candidates for parallelization, such as the keyboard scanning the key matrix for pressed keys.
Seems like modularization is going to be beneficial pretty much anytime you can define an interface you think is going to be somewhat stable.
I wonder to what extent Rivian has removed intermediate controllers here, where they used them in the first place to get things done on a tighter timeline.
The value proposition of CAN bus is that peripherals can be scattered around connected by two data lines and a power wire. Dumb peripherals need more wiring.
Can is a great idea... But in practice the hardware to connect to the bus is ~10 cents, whereas the cheapest microcontrollers are ~1 cent. That means if you want thousands of connections for every peripheral, the costs of CAN transceivers really start to add up.
They are deviating from that already, aren't they? If they use one ECU per zone, then the peripherals in that zone can't be connected via CAN bus, otherwise they would need their own controller.
Given the wording of "drive units, and its battery management system" I'd think the BMS is linked to the drive units and under the same ECU. I'd assume the drive units and BMS are tightly integrated, as that's basically the entire high-voltage system and you have to manage the two-ways energy flow between the two (propulsion and braking / regen).
Not really, the FOC software that runs on the inverters is compute heavy and safety critical. It gets its own dedicated controller (they are actually running to cpus in parallel in case one fails) and same with the bms. They talk over can currently in teslas. bms states it’s max charge and discharge current, and everything else listens
pure copper density at 9000 kg/m3, wire diameter assumed at 1mm, length at 3000 m (1.8 mi, approx) gives 21 kg, approximately 46 lb. math checks out.
> the company claims a 20 percent savings in material costs and 15 percent reduction in its carbon footprint between Gen 1 and Gen 2.
surely this is not just due to the reduction of copper. copper is around 10 USD/kg at bulk.
now let's see if we can address the copper length number. can 1.6 mi (< 3000 m) of copper be saved from wiring alone?
The car dimensions are 2m x 5m. That means, in the worst case, two ECUs placed at opposite ends will need 5m of wire (half of perimeter). There were 17 ECUs originally. Call it n = 20, and if we wire dense (in the graph sense), we get n^2 = 400. So, in the absolute worst case, the densest possible graph would have had 5m x 400 = 2000 m of wire. The claimed wire saving is significantly (but not by an order of magnitude) larger than this. I would say this passes the smell test (albeit barely), but original wiring must have been truly inefficient.
The vast majority of automotive buses use differential signaling over multiple conductors for EMI reasons. The only common exception is LIN and maybe SWCAN if we're exceedingly generous with our definition of "common".
I was expecting to see a mention of whether there were any safety concerns related to running fewer ECUs. I'd assume not since they chose to go this route, but the idea of the infotainment system going down and taking other systems offline with it seems like a risk they would have had to consider.
"just use Wi-Fi?", probably not. I don't think you'd want to create so many openings for attackers. Besides, EMI is a real issue and not something you want interfering with your critical systems too much.
To the point they are wanting to eliminate AM radio because they've gotten to the point that the uncontrollable EMI makes AM "unlistenable". So move the goal posts, and make AM radio out-of-fashion and get rid of it rather than solving the EMI issues.
1) I don't think you'll ever be able to make an electric vehicle electrically quiet enough to make AM work nicely and if you somehow did between the shielding and all the balancing currents there's no way it would be efficient. I like AM radio but these two things are probably never going to be compatible.
2) WiFi really isn't as reliable as a cable. There are all kinds of things internal and external that could cause an outage. Why bother with that when you can just run maybe a dollar of copper to the ECU?
Ignoring wifi as a poor use case here(you'd likely use something with much less interference and better latency), RF will still usually have more latency than a wire. It's more prone to interference from other random devices and even other cars. Canbus is typically shielded, which you obviously can't do with something relying on radio.
Then you have physical interference...imagine all your warning lights come on, wipers come on, and radio cuts off because your wife put her Stanley in just the wrong spot.
People don't like your comment but I have a side project that requires controlling 36 lamps in groups of 3. I rolled it over and I'm just going to slap a cheap radio on a PCB's and just daisy chain the power.
Maybe you already completed your project, maybe you already knew about Charlieplexing (https://en.wikipedia.org/wiki/Charlieplexing), maybe it doesn't apply to your case as your controller didn't support tristate output, but, just in case you didn't know about it:
It's a technique for controlling (or reading) large numbers of LEDs, switches, etc, with surprisingly little wiring. Instead of the usual X/Y of multiplexed I/O, the wiring is diagonal. To control 12 outputs (36 in groups of 3) you'd need just 4 pins (if your lamps are not LEDs, though, you probably need to put some diodes in there)
I've built my "smart home" explicitly without wifi [1] to shield against any kind of "local exterior attack" and mere communication issues due to natural phenomenon. Even for light I decide for ShellyPro 4PM to avoid wireless...
Surely without cables it's far easier, but this easiness have a price.
[1] with the exception of the car charger since I wasn't able to find a damn cabled one (it's 230Vac, not CCS eh!)
There's often the "wifi or wired" discussion around here, so I'll just add that those are not the only choices. Zwave for smart devices for example is a local wireless protocol which is completely separate from WiFi and doesn't have the same addressing / access issues.
I built everything in my house with Zigbee and could not be happier. The "everything is just a message queue" approach that Zigbee takes is fantastic for the home, and the fact that I don't have to worry about a whole complicated protocol that can do anything is great.
Aside another aspect is how to make the home impossible to live in case someone illegally occupy it (here, France, but essentially all south Europe is a relatively new but spread thing) while you are on vacation to be quicker than local authorities. Another one is avoiding connecting too much black boxes to their OEM homes.
Another final aspect is mere reliability, as a small anecdote: a neighbor due to some unknown issue have had roller shutters locked down because they have ONLY a wireless remote with a kind of ESP32 inside, all proprietary, no emergency manual opening, no access to the motor to power it directly or detach the break manually on the shutters. My home while "a bit smart" have a far little attack surface in that regard. For instance just to have central/remote lights control I've chosen a set of ShellyPro 4PM (the least expensive option of that kind I was able to find) witch operate remotely (LAN only, via HA or directly logging on the device, extended via wireguard) but i can also operate via classic mechanical switches and internally the Shelly are "dumb classic switch" + extras so if their fw crash from the physical buttons (not the one on the devices, but their normally open contacts) they still operate. For the car charger I'm obliged to go wifi (I find exactly no one domestic charging station with wired connections for control) but it's a dedicated WLAN (a small GL.iNet "stamp" size on the back of the charger, wired to a dedicated port of my homeserver on a completely separated LAN without internet access and the charger itself is MQTT/ModBUS-bridged to its local, internet-less controller/server for p.v. integration.
I can't do nothing for my car and well... Sometimes it's "app-service" to remote control A/C etc get connected to someone else car in another country and yes, I can monitor it and act on it when this happen (few times per years so far). No special hacking needed. No response from the vendor (MG/SAIC)... And for cars some demoed serious remote vulnerabilities able to physically make a car crash while running.
All those might be very rare events, but their seriousness it's relevant enough for me to avoid them as much as possible.
If my experience of trying to tether my laptop to my phone on a moving bus is any indication, I'm thinking that WiFi (as opposed to other wireless technologies) is a non-starter.
OP is heavily downvoted, but yes some ECU are moving to wireless communication although not WiFi.
It started with places where you simply can't have wires, for example tire pressure monitoring. But is now spreading to other simple ECUs. And yes, it can be jammed so obviously it's not for brakes and steering and things like that.
You can image the drivers side door has a module that senses the door switches and operates the drivers window and door locks. And communicates via RF to modules in the other three doors to control the windows and door locks.
Seriously why the heck not?
I've thought in the past what I want for trailer lights is a RF connection between the vehicle and the trailer. It can't be worse than the standard way that always fails.
I like to imagine some kind of engineering “meet cute” whereby, one random day, the headlights engineer and the parking radar engineer happen to be working on the front of the car together. Their eyes meet:
“hey, I’m John — I didn’t know you had an ECU here!”,
“hi, I’m Claire — wow, you have an ECU right up front too? It’s, like, right next to mine and we never knew!”
“I know, crazy right?! Hey this is going to sound really forward and I don’t normally do this but I’m only running at 70% compute capacity. I don’t suppose you need any real-time budget this evening?”
“So funny you should ask, I was just about to run a whole bunch of heavy new wiring to…”
And in a story as old as time they get ECU married and raise their control loops in the same front-of-vehicle ECU together instead of living their separate, lonely, ECU-right-next-to-each-other-and-they-didn’t-know-it lives.