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.
kevin_thibedeau
Ford did this with the cost reduced version of SYNC 3, merging two modules to form SYNC 2.5. The result is an unstable heap of trash.
dangus
Well, it is Ford. You buy a Ford you should expect it to be trash.
plg94
wow, you made hackernews turn into tumblr. Well done, great explanation.
jdiez17
I ... am a bit speechless ...
I didn't know this was something I could be into so much, and yet here we are.
brundolf
That's what they said
yc-kraln
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.
(I previously worked for Daimler)
mensetmanusman
Would be funny to have a ‘mm Cu / FTE’ scaling law.
westurner
The ohm*meter^3 is the unit of electrical resistance.
Are there yet CNT or TWCNT Twisted Carbon Nanotube substitutes for copper wiring?
westurner
* far less conductive graphite; another form of carbon
FWIU recent developments in graphene semiconductors for example on silicon carbide are undercapitalized.
Can industry undo its unsustainable copper dependency by replacing power wires and data cabling with TWCNT cabling?
throwaway48476
Complexity is a function of the number and depth of suppliers.
gregmac
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").
Animats
> "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.
sdwr
State management is the only difficult problem in computer science
Or something like that
euroderf
Have they never heard of fuzzing.
daghamm
There is a short answer to all 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.
morning-coffee
From the article:
> 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?"
yencabulator
Even leaving aside autopilots and such, automatic breaking and lane keeping are now a hard requirement for new vehicles in many places.
The point is that it might in the future take you from point A to B autonomously.
daghamm
You think that's complex?
A new high-end Audi has around 200 ECUs.
Lvl999Noob
> 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.
Moto7451
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.
moring
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.
edmundsauto
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.
guai888
Standard approach is following ISO 26262 development to deal with risk resulting from failure mode.
Timshel
They though of the failure mode opening doors should be part of the "vehicle access" which get its own ecu.
techdmn
Some days I'm really happy that I kept at least one analog car.
thelastgallon
Rivian can switch to 48V for more gains.
https://www.hackerneue.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.
Those are rookie numbers. Let’s bump it up to 96V while we are at it.
throwaway48476
50V is the generally accepted safe cutoff. There are separate electrical certifications for 'low voltage' <50V.
addaonOP
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.
yencabulator
48 V + charging ends up around 54-58 V, so the 60 V cap is needed for 48 V systems.
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.
maxerickson
60 volts DC is treated as a safety threshold. Human bodies start to conduct better about there.
hulitu(dead)
[flagged]
stephen_g
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.
Vecr
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.
xbmcuser
I recalled I read something similar before so I searched for it. It was Tesla doing something like this in 2019
"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."
grecy
Tesla have taken it to a whole new level on cyber truck.
It is assumed this will continue in their next gen vehicles
theluketaylor
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.
postalrat
Adding one additional voltage doesn't turn something from elegant to a complete mess.
I don't know why you mentioned the traction motor voltage as part of the mess. Do you want hundreds of volts DC running all over the car?
throwaway48476
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.
jvanderbot
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.
trainsarebetter
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
jvanderbot
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).
This is a disruption opportunity wasted.
katzinsky
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.
grecy
As well as 48v they also went to Ethernet for device comma, drastically reducing the amount of wiring
samatman
> 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.
gamblor956
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.
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.
theluketaylor
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.
stephen_g
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.
AlotOfReading
That's why DC/DC converters exist. Only the things that can take 48v (and associated voltage spikes) get exposed to it.
brianwawok
Massively smaller wires and higher powered accessories
OptionOfT
I think having multiple ECUs over time is a cost savings mechanism. You have a module that you can use in all your models because it works.
If Rivian wants to add a new feature that doesn't 'fit' on the AIO ecu, then what? Replace it and re-certify ALL of its functions?
A good example is the ABS controller which is usually just a Bosch COTS ECU.
You wouldn't even want to implement that for yourself.
schobi
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.
indoorcomic
I love this. I hope this more manufactures go this route. I've always felt that having ~100 ECUs in a car is complete overkill.
AlotOfReading
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.
Jtsummers
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.
In the future, please include the actual link. It is 10x more useful.
Ekaros
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?
moring
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.
maxerickson
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.
kevin_thibedeau
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.
londons_explore
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.
moring
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.
daghamm
"four categories get their own ECUs: infotainment, autonomy, vehicle access, drive units, and its battery management system."
Am I reading this wrong, or are these actually five categories?
masklinn
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).
trainsarebetter
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
quanto
quick math check
> 1.6 miles and 44 pounds
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.
spydum
maybe i missed in your estimate, but most circuits need more than one wire?
hn72774
In a vehicle, the chassis is the negative wire in the circuit.
AlotOfReading
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".
caleblloyd
I didn’t completely follow either but I think the n^2 = 400 worked out to 20 ECUs each with 20 wires
_heimdall
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.
lofaszvanitt
3rd generation: no wires from sensors to detectors.
twoWhlsGud
4th generation: wires are back so the car doesn't stop working every time it drives by a source of RF noise...
lofaszvanitt
We'll see...
aaron695(dead)
[dead]
therealdkz
There is nothing like perf improvement that removes sleep() put in earlier…
warkdarrior
Couldn't they just use Wi-Fi? So much wiring..
Jtsummers
"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.
dylan604
> EMI is a real issue
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.
katzinsky
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.
Gibbon1
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.
gruturo
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)
kkfx
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!)
viraptor
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.
stavros
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.
nurettin
> "local exterior attack"
I appreciate the geek, but is this useful in practice? Does it happen to anyone?
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.
PlunderBunny
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.
adrian_b
So that anyone could crash your car with a jammer?
daghamm
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.
Gibbon1
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.
I didn't know this was something I could be into so much, and yet here we are.
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.
(I previously worked for Daimler)
Electrical resistivity and conductivity: https://en.wikipedia.org/wiki/Electrical_resistivity_and_con...
Is there a name for Wh/m or W/m (of Cu or C) of loss? Just % signal loss?
"Copper Mining and Vehicle Electrification" (2024) https://www.ief.org/focus/ief-reports/copper-mining-and-vehi... .. https://www.hackerneue.com/item?id=40542826
There's already conductive graphene 3d printing filament (and far less conductive graphene). Looks like 0.8ohm*cm may be the least resistive graphene filament available: https://www.google.com/search?q=graphene+3d+printer+filament...
Are there yet CNT or TWCNT Twisted Carbon Nanotube substitutes for copper wiring?
FWIU recent developments in graphene semiconductors for example on silicon carbide are undercapitalized.
Can industry undo its unsustainable copper dependency by replacing power wires and data cabling with TWCNT cabling?
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").
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.
Or something like that
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?"
https://en.wikipedia.org/wiki/Automated_emergency_braking_sy...
https://en.wikipedia.org/wiki/Lane_departure_warning_system#...
A new high-end Audi has around 200 ECUs.
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.
The dealer can’t figure out the issue four years in.
(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.
Given some of the chip shortages of recent year, I’m curious how the teams responsible for those trade offs made the balance.
https://www.hackerneue.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.
Discussion: Tesla shares 48V architecture with other automakers: https://www.hackerneue.com/item?id=38557203
https://electrek.co/2019/07/22/tesla-revolutionary-wiring-ar...
"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."
It is assumed this will continue in their next gen vehicles
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.
I don't know why you mentioned the traction motor voltage as part of the mess. Do you want hundreds of volts DC running all over the car?
INB4 the 12V terminals: They are hard to access, have limited amps, and are a separate crappy battery.
But I still agree the option should be there for emergencies
This is a disruption opportunity wasted.
And being able to find replacement parts at the dollar store no matter where you are is really great.
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.
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.
This NHTSA report is pretty damning about Tesla's cavalier attitude towards the design of safe systems.
https://static.nhtsa.gov/odi/inv/2022/INCR-EA22002-14496.pdf
https://www.forbes.com/sites/bradtempleton/2023/04/26/tesla-...
https://www.forbes.com/sites/bradtempleton/2020/10/28/new-te...
https://www.wired.com/story/tesla-autopilot-risky-deaths-cra...
Ok. So in the middle then. Not, in other words, "downright dangerous".
That would be, worse safety outcomes. Rather than insignificantly better.
https://www.wsj.com/business/autos/tesla-autopilot-crash-inv...
Can you name some benefits ? ICs working at 48 V are expensive and hard to find.
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.
If Rivian wants to add a new feature that doesn't 'fit' on the AIO ecu, then what? Replace it and re-certify ALL of its functions?
A good example is the ABS controller which is usually just a Bosch COTS ECU.
You wouldn't even want to implement that for yourself.
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.
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.
EDIT: That's not the only tradeoff, but it is a key one.
In the future, please include the actual link. It is 10x more useful.
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 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.
Am I reading this wrong, or are these actually five categories?
> 1.6 miles and 44 pounds
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.
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.
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?
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.
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)
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!)
I appreciate the geek, but is this useful in practice? Does it happen to anyone?
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.
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.
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.