How about "We at Tesla eliminate the "stupid" no one else was willing to" Ok, that's harsh. Try again. "We at Tesla design for the future" Ok, maybe that's a bit better.
Minor clarifications: The Ether part means it will be a different industry standard than CAN, not a complete invention reinvention of the network layers. They will probably be using IP4, to have open source components work right away. The local area network in private homes are typically a star or a tree, but that is not failure tolerant. Any component can be offline with a single point of failure. The Loop-part of the name is a reference that it is a loop-architecture, not a bus. That means if you cut the network, the packages will take the other way around the network. Like TokenRing. It is a fault tolerant network. Each zonal controller will effectively have a small router. It will be interesting to see which OSI layer they create the “loop” in: actual loop, or virtual, but loop-like.
Probably they won't be using IP for time sensitive / safety critical parts like brakes. But there are related ethernet standards for that, see "Time Sensitive Networking" which is about making ethernet usable for real-time workloads. I suppose it might be possible to run less critical workloads like entertainment over IP using the same wires as the real-time stuff, just at a lower priority.
I'm pretty sure they have said it's ethernet physically but it does not communicate with IP and you do not need IPv4 for that, IP is layer 3 and you only really need layer 2 to have communication.
Etherloop sounds like an industrial network protocol like EtherCAT, Profinet, or Ethernet/IP. There are many chips out there that support these industrial protocols. All are time-sliced for reliability and consistency.
Etherloop seems to be a great idea. Imagine using 20 times less wires with that new design. Thanks for the visual explanations. Great work, your speculation is probably right.
They may have taken inspiration from Ethercat, which involves each device adding its data into a 'frame' that gets sent around the loop at regular intervals (~4KHz) rather than individual devices messaging one another
Sounds like they just took modern computer networking and stuck it in a car. Computer networking already supports all the functionality you described including delivery of power at 48v to endpoints.
I enjoy your videos. I've been involved with engineering Ethernet on aircraft (an expert). I strongly suspect some of your assumptions don't apply to Etherloop. I didn't read your video's comments but I'm guessing others have set things right. Particularly are these key points: 1) Tesla called it Etherloop because the system would be implemented as a loop so the system redundant. 2) testa uses dual end points with separate processors in the headend. 3) Tesla used a modified spanning bridge protocol to avoid packet storms 4) testa uses non-blocking cross-point Ethernet switches and possibly multiple endpoint speeds to implement deterministic package delivery. 5) testa uses both multicast and points to point IP addressing. Respond if you want more info.
1: I think they just like the word loop. 3:why spanning bridge over normal switching in this environment? Modern implementations can certainly cope with the traffic and a vanilla implementation should do. 5: what would be the use case for multicast in a car? Nothing really practical comes to mind.
Multicast would be a very logical application. It’s essentially how every E2E architecture works today and for good reason. For example anything related to vehicle dynamics (speed, collision warning, braking, steering, …) is usually multi-consumer. Another one is extensibility. Want some additional signal for a new feature? Just get it from the bus (multicast). No need to change any configuration or firmware of the existing network.
@m0rish what is the benefit of using an unreliable transmission like multicast? Tcp ack/nack eror detection/ correction, etc seems more applicable. Unless things are drastically different, systems have had a single consumer of signals, the computer. Don't believe the senders talk to each other. Seems best that a system like a car have central control and coordination. Else things get complicated and unpredictable quick
@@criticality2056 Consider multicast for transmitting an identical file to 1000 boxes on an aircraft. Each box performs a checksum on each megabyte and requests multicast retransmission of that block after the whole file is sent. Almost a thousand times faster than tcp/ip
Presumably this is going to be in everything Tesla produces in the future. I imagine the need for this in the Unboxed production process, is that you need a simple way to connect each of the pre-wired regions together without having to install a loom after the parts have been assembled. I suppose the controllers could be identical for each corner of the vehicle, and for every vehicle that Tesla makes. There's a huge economy of scale using that approach.
So there doubling the number of connectors in a moving object with a lot of vibration and environmental factors that’s going to cause teething problems
Etherloop with Dual TX (Transmit) and Dual RX (Recieve) in full duplex should act the exact opposite. twice the data means even if one path fails you have complete redundancy thru the other path between Controller and all of the vehicle's sensors. Etherloop should eliminate similar Haywire situations most folks experienced in their lifetime using current CANBUS technologies. and give enough time to diagnose the single point of failure and find i.e. disconnect in wiring on the other path OR bad sensor failing it's healthcheck , etc.... and there are many off the shelf ethernet tools which should make finding problem area using time-domain reflectometer (TDR) tools a breaze
Really happy to hear it! I saw a lot of people covering it, but there was so much missing information that it didn't make sense for me either. So, I made the video that I wanted to see 😁
Ohh but what's the under the hood of the etherloop (transport layer, think tcp/ip), that's the most interesting question! Since they have point to point connections the network layer is very simple, and transport my guess would be a modified UDP with some kind of priority information (like CAN ID). Man that would be very simple and very fast... I think they would simplify and merge OSI layers as they don't care about many features there. Jealous of those engineers.
The range of things you can make me understand is amazing. Your explanations are so clear and are presented in a sequence that builds on each previous step. The latter should be a no-brainer for any exposition but is too frequently not attained. I'm sure that takes a lot of work.
Ha! You just described exactly my philosophy when I'm writing. Sequencing! Yeah, I find so much information out there is put together in a sloppy way. It's aggravating. But, maybe I'm just a bit too much on the spectrum, lol
It would be a rather safe bet to think that "Etherloop" actually is "Single Pair Ethernet". Which would be compliant with any of these standards. IEEE 802.3cg 10BASE-T1L if you like low cost, low energy (110mW), long length (1000m), and 10Mbit/s is enough (still between 80 and 10 times faster then CAN-bus). IEEE 802.3bw 100BASE-T1 if you think that a compromise between speed, energy consumption (220mW), and distance is great (800 to 100 times faster then CAN-bus). IEEE 802.3bp 1000BASE-T1 if you opt for the highest speed possible (max 15 meters) (within a car length 8000 to 1000 times faster than CAN-bus). It has been designed for usage in cars. It is a great standard that makes a lot of sense. Tesla may call it Etherloop as it actually is a bus, so it will pass through all units. In reality, be closer to the 1990 RG-58 COAX 10BASE-2 bus Ethernet but on a single twisted pair instead and full duplex instead of half-duplex. It will still have bus collision as an efficiency limiting factor, but with enough lanes used, it is not an issue. I have been waiting for the first car to use that standard for about 6 years now...
Apart from the copper advantages, I dod suspect, the use Power-over-Ethernet (PoE) specifications to distribute power over the Etherloop. The spec's for PoE provide at least 44V and Up-To 50W of power / Ethernet-cable. This is a great advantage 1 standaard Etnernet cable can power every controller and everything else from the separate 48V power system. Also eliminates (reduces) cross-wire interference due to voltage similarity.
Thank you for making this video which is like a professional quality training material. One aspect you did not cover is the risk of making everything software-based. A failure or defect could have more far reaching consequences for safety.
9:00 Using 48V will not help thermal management because same wattage for the chips will still generate same amount of heat load no matter what voltage you use.
Note that EtherCAT has existed for well over a decade at this point, and is used in safety critical parts of simulators today. It is also used for CNC control. This has extremely defined latency, and solves the problems of traditional Ethernet. However, the whole master controller thing may not be what Tesla wants. I'd also like to address the whole part about random backoff times mentioned at around 16:50. That's only a concern when multiple devices are plugged into a single wire, and is almost never the case in modern infrastructure. Decades ago we used "network hubs" which just tied the wires together in a fancy box with a repeater. Today we use "network switches", which operate in point to point mode with other computers. This centralized network switch is known as a "star topology". Another fun thing you may be interested in is POE (Power Over Ethernet). Since Ethernet is a differential signaling protocol, it can be thought of as AC. Well, we can apply a DC bias and power something with that. Here's the interesting part. That DC bias used for POE happens to be 48V. It is a common voltage, so may be coincidence, but could reduce the wire count even further.
Are you sure? Cbus is an RS-485 based serial protocol, essentially similar to Dynalite, KNX and also similar to many other building automation protocols.
CAN and ethernet both need firewalls for security. You don't want hacks to the cabin entertainment system to put brakes and steering at risk. So, there are separate networks. For safety and security. Also, any network wires that extend outside the locked envelope need to be firewalled because they are at risk of hacking. For other vehicles (not tesla), that included blind spot radar mounted in the rear fender well. That may not apply to teslas.
There's no such thing as a CANBIS firewall, because CAN doesn't have device IDs or any concept of addressing. It's a terribly insecure protocol. Like not even insecure, but non-secure. The concept of security doesn't exist in CANBUS itself, it can only be layered on top.
With etherloop, they will have to likely build a new protocol to run, but now with advances in frequencies on a single wire, they can send multiple signals over a single wire too. So send your high speed critical signals on a priority frequency and send all other data points as a lower frequency. Think of how DOCSIS works.
it seems that Etherloop is a variation from the industrial motion protocol called Ethercat. This protocol runs data bus cycles in less than 1ms. Ideal for high precision industrial applications such as robot synch In a production line, or when precise synch is needed for reading/writing IO block nodes. Perfect for a vehicle application.
This was my first thought too, but I would be concerned about message priority. With video devices and the payload size, these should be lower priority to command controls. With robo taxi etc. perhaps they are critical priority. To my knowledge Ethercat is like a train with the information making stops at each node and gathering information adding to the “train” of information. Mixing a control command behind video or other high bandwidth item may prove an issue but the high speed of the protocol might compensate. All I know is having video on the same network as your factory is a big no no for industrial automation. Having an intelligent switch that can determine priority at the beginning of the frame would be an important consideration IMO. The other consideration that will be of import is encryption. Industrial protocols are now working on encryption/authentication standards. I would be quite interested in understanding how this protocol works as I think believe it is ground breaking.
etherloop is great for personal automobiles, but it will be a GAME CHANGER for over-4 wheel vehicles (tesla trucks), trailer engineering, and commercial delivery fleets
Mybe this was brought up and maybe the unboxing revealed info about this, but i have been phantasizing about endpoints that ‘speak’ etherloop. So a breaklight consists of, say 20LEDs, those LEDs are driven by a simple microcontroller (think arduino kind of thing) the microcontroller received its instructions from what is called a controller in the video, but over the etherloop, not via cross car wiring. The microcontrolles can also be fairly generic and the controllers can be simple or complex and software defined, as you like. But the need for cross car wiring is eliminated. You only need at each endpoint a power rail and an etherloop connection.
Ethernet hast some benefits not mentioned here. The connectors are standardized which makes devices cheaper to connect. There is a standard for power over ethernet PoE. This could be used to not only replace CAN, but in many cases also an extra power supply connection. Maybe the hubs would need direct power supply because of their provision to the connected devices. Maybe planes, subway trains, trains and trams are also using some of the devices which would reduce the cost per device because of production scaling effects.
Its looking more like the Cybertruck is a testbed for new tech they will be using in later Tesla models. If you're going to throw out many standards and introduce modern ones like Steer by wire, 48V LV system, etherloop modules & rear steering, a low volume product is the best place to test it. Curious if that means Tesla will release a Y/3 style pickup truck in the future and when this tech will trickle down to the Y/3/S/X.
Industrial automation has been using sensors directly connected to a network for quite a while. really saves a lot on wiring and maintenance, especially grounds management.
Iirc the ieee have specified a new ethernet standard for deterministic ethernet so that time critical messages can be utilised. There is already a method of tagging quality of service on ethernet so that time/flow critical applications such as VOIP and video can be used. However both these applications it is more important to ensure no jitter or flow interruption than ensure immediate delivery. The new standard is supposed to deal with time critical operations such as braking, steering etc.
higher voltage doesn't change much signal lines, as they are limited by cost of fabrication and ruggedness. Plus, every logical junction must dissipate more. There might be an advantage for noise immunity ...
Do you know what protocol do the individual devices communicate to the controller with? SPI? If Tesla has to make custom modifications to the ethernet protocol stack, it seems like instead they could have developed a new protcol from scratch that is much simpler than TCP/IP and could be implemented on even the most basic microcontrollers allowing each device to connect directly to the etherloop and get rid of the need for the regional controllers.
Oh man! That's beyond me, but it makes sense. This video was a stretch for me. I know there are more level/layers to this and I'm just scratching the surface. Hopefully someone else can respond intelligently when I publish it.
Modern microcontrollers are plenty powerful for TCP/IP, it's not that heavy of a protocol. We're far past the 8 bit chips now. That said, 'EtherLoop' sounds a bit like EtherCAT - which would be great for this kind of thing, they may well be basing it on that, or something similar. It's a rugged Ethernet style protocol, with custom chips that handle the comms on the slave side, allowing for Realtime communication, and even certified safety over the ethernet line. I suggest looking up 'EtherCAT' and 'Safety over EtherCAT'
Why would they use TCP/IP? Ethernet frames should be more than plenty (with a convention of resending info often or in certain cases using ack frames).
Definitely not TCP/IP. Doesn't make sense to use an ancient protocol when you control the entire ecosystem. And I wouldn't sit in a car that uses TCP/IP for braking. You need a system that's extremely reliable and has a guaranteed maximum latency well under a millisecond. This involves the hardware as much as the software. I would go with some kind of token ring architecture, which is older then ethernet. The wires form a loop, and the data goes around until it finds the destination. Could be bi-directional for free redundancy. It's like a train going on a looped track, and each station can add or remove cars as needed. The control logic is trivially simple, you receive the data, use what you need, and pass on the rest to the next node in the loop. You know when you are allowed to send and how much spare capacity left, so there's no collision or packet loss. And prioritization is easy too. If there's no more room for your message, just replace a lower priority one. Or if you don't find one, delay or drop yours depending on the type. Can have multiple "trains" in each direction to further reduce latency. The weakness of this system is that it's vulnerable to faulty or malicious nodes, but here neither should be an issue.
A lot of the features are implemented in the dedicated Ethernet switches in hardware. The en- and decapusaltion of data can be done in the controller .
To compete, other car manufacturers should go to the increased level of software modularity which Tesla exploited to reduce # of controllers and wiring. Instead of selling a >physical thing< requiring its own controller and wiring, 3rd party suppliers should be moving to selling software modules instead.
Excellent video. I'm writing a report on that topic and 100% agree with everything said. I know some Chinese OEMs are also deploying zonal architecture, but I'm not sure if those are interconnected via an Ethernet backbone. By the way, you forgot to mention "TSN" (Time Sensitive Networking), a key technology to make Automotive ethernet deterministic and suitable for safety-critical applications
Tesla still needs to implement some redundancy in the wiring due to shorts or open circuits in the Etherloop cables. But I get it! It all comes down to configuration management or the software features, variant handling, and fall-back/promotion of features to control I/O on another ECU remotely...
Good information. This is a real game changer, not only for vehicles but for anything complex. It's a bit like when hardrives were SCSI, mouse/keyboard were wired and had different plugs than printers. I'm not sure that this Tesla architecture if it becomes a standard can make any licensing fees for Tesla. Likely it's too generic. (Tesla might be able to sell 48v components, because no one is making these. Cars were 6v until the 1950s, then 12v. Since about the 1960s they could've gone to 24v and then 48v which would've save billions in copper. What's happened is all OEMs (except) Tesla use off the shelf components: lights, sensors, wiper motors, etc... which are now all 12v. They're so used to going through catalogues and making phone calls that it would be like starting from scratch for most OEMS. This is why when Sandy Munro looked into the Ford Mach E and the VW EV he found triple the number of hoses and wiring as in a Tesla, and much less efficient use of space. The VW has no frunk, but also almost nothing behind the dash where it would've been out of the way. This increased complexity also increases failure & recalls. ) For boats there's the NMEA 2000 network. It's a 12v CanBus system and is compaatible. You could stick a windvane on your car and plug it into CanBus. NMEA 2000 has a few features that must also be common for CanBus: A backbone that runs the length of the vehicle (boat or car) and drops to the various sensors.The backbone is powered by a 12v connection(through one of the drops dedicated for this) but this 12v only powers the bus-- each instrument requires a separate power line. Drops can be no longer than 6m (20'). My sailboat has a 63' mast and instruments at the top. The workaround is the Backbone runs to the front sensors near the bow, and then doubles back and goes up the mast. The Drops then for the wind direction, speed, any cameras, maybe a radar on a spreader are very short. (I think the Backbone can be 170m long -- some very big length.) There has to be terminators at each end of the Backbone. On my boat these will be in the binnacle (in the cockpit at the wheel, where the new chartplotter is and my old Autopilot - which has never had a single issue in 20 years.) Third the NMEA 2000 network is infinitely adaptable. It plugs (and waterproof screw attachments) and modular. Right now it's in my binnacle down to above my engine. Later it'll run forward to the new depth sensor, and if I replace everything on top of the mast, I'll unscrew the terminator add more backbone to go up the mast... It's like Legos. Wnat the data that flows into the backbone must be doing is identify the instrument source and the quantity. Signals for operation that flow back along the backbone must be understandable by the unit, lights, camera (to turn on, move, etc..) NMEA 2000 has a couple of features. First all manufacturers agreed to a set of standards -so everything that uses it is cross compatible. Second it refreshes up to 2000x/second. The previous 0813 (SeaTalk in RayMarine) refreshes at a much lower rate. My boat has both. There are translators sold that allow connecting the older 0813 instruments to the NMEA 2000 network, but I haven't tried them yet. I'm waiting to find verifiable real world cases where this is working. Otherwise I'll just buy new sensors. Just a download... if anyone is nerdy enough to be interested. And of course as I was bending my brain to learn all this last month and then buying the gear.... of course I had the thought: As soon as I get this all hooked up, newer and better wireless gear is going to replace it. (There are wireless mast top instruments but so far these have a reliability issue.)
The 48V and Ethernet (or loop) are not necessarily codependent and shouldn't be thought of as such. Many automotive systems (CAM sensors, crank sensors) actually use 5V. They are internally regulating the 12V down in the ECU for example. The car could move to a 48V system and do the same thing. It could still be CAN buss but save significantly on wire.
This is called "zonal architecture" and virtually all OEMs are doing it now. Btw it's independent from the bus type, can be done with CAN too. Ethernet does not work that way. All automotive ethernet versions are collision-free. 100BASE-T1 (BroadR-Reach) and 1000BASE-T1 (RTPGE) are point-to-point with switches. 10BASE-T1s uses bus topology (just like CAN), but it also implements a token scheme to avoid collisions. And finally, there are MANY networks in cars. Multiple CAN, LIN, FlexRay, Ethernet and other channels for different purposes.
The diagram at 16:08 might be a bit "wrong" because it adheres to bus topology. Etherloop would, as the name suggests, likely use a ring bus instead, which the cable at 9:26 also suggests. Ring networks aren't as prone to collisions as a bus network (as the next node can simply queue up the incoming data to send after its own data - or before it if it has a high priority), especially when using a "token ring" in which a "token" is passed along and without token, you're not allowed to talk (although this comes with an obvious latency penalty). However, payloads likely don't need to be that big so the latency probably shouldn't be *too* big (sub-1us for an entire "rotation" would still be achievable just fine).
OEMs have been using Flexiray and Ethernet in their cars for years now! The issue with the common "corner controllers" architecture is that it makes an FMEA extremely complex, because all systems are inter-related at a H/W and S/W level. I mean, call me old fashioned but it's rather not find out that my airbags didn't fire because i was at 25degC on the HVAC and had the interior light on at the moment of impact, or that my car did an OTA update last night to fix a bug with the satnav, but actually borked the ABS system...... I'll happily carry an extra 10kg of wire to get systems that are designed, developed, validated then LEFT ALONE for the life of that model. It will be very interesting to see how far they go with this, ever diminishing gains imo. For example, an ABS controller has all the critical systems directly on one PCB, mounted directly (with non soldered push fit contacts) to the ABS modulator (the mechanical bit with the pump and solenoids) precisely because any failure to drive those solenoids in precisely the right manner can lead to a LoC (Loss of Control) and that, as Toyota found out, gets expensive, very quickly (The $2.1 BILLION Toyota was fined in 2014 would have bought a LOT of wire...) Now it's absolutely possible to run a safe vehicle on a distributed control and co-ordinated network, the issue is if the risk is worth the reward, and if the (significant) extra validation forced upon you is worth the effort as you now have to do it for ANY change whatso ever......
one note, increasing the data rate does wonders for reducing latency. if you compare the highest speed canbus (0.05 - 1Mb/s) with gigabit ethernet, you have 1000x-20,000x the bandwidth. At some point, this increased speed means that even the retry oriented nature of normal ethernet will get the message through faster than the canbus would
ETER LOOP is a nifty name change for something that already has been going on in auto mfr for about or more than 25 year (by wire throttle controls GM 98’) this is an expansion on that if I understand you right. At about that time it was announced that in 3-4 yrs things at Ford would be shifting to single wire 36-42 volt systems, which fizzled. But from the perspective of “electric drive”. any voltage would be feasible/doable, and the higher the voltage always means -the less wire, -the end goal, and the separate controllers will get it there no doubt. I would imagine that NTSB will have a “say so” on by-wire (Ethernet) control of subsystems like brakes, steering, exterior lighting, and is most likely why crossbody wiring on braking will remain. Your comments on the impossibility of CAN on subassemblies is not so however because in cases like that a bulkhead or “Cannonplugs” are. And have been utilized in just such situations since that very issue arose on high volume assembly lines for offplant subassemblies in aircraft at the beginning of WWII. Each sub assembly comes pre-wired with a multi pinned connector. A bulkhead connector. And at some point, if not already Tesla will do the same thing just with 42 volt instead of 12.
Power over Ethernet (PoE) is a common standard all over the world, providing 48V power to desk phones, access points, and some computers in every enterprise network for the past 30 years. I wonder if they've redesigned everything to use standard PoE, and that's why they chose 48V architecture.
On a munro video tesla stated that the etherloop was more like a token ring in that time on the network was sliced, each controller had its own unique time slice, that means no message collisions and no resends (unlike ethernet). Thus the new name. With this strategy you can saturate the bus to 100% traffic with no lost data as opposed to ethetnet where data can be lost at around 70% saturation.
I don’t believe your statement regarding controllers being redesigned completely to accommodate 48v supply is correct. Micros typically run on 3/3.3/5V and these are provided by the onboard power supply stages. Tesla isn’t replacing STMicro or Infineon or NXP or TI chips.
So the same way clusterinf can have a single peuce of software running across a cluster of computers, these mini controllers that are multi use is just four computers. Then the Software will cluster to all conputers ro comptrol all breKs as a single unit. Thats a great way to go about it!! It will make any vehicle troubleshooting std across all manufacturers and make it easy!!!!
While the application is novel, the technology really isn't. EtherCat is very similar and has been around for some time. It is found in many industrial automation environments. Even that is an evolution of ARCnet, which was developed in the 70s and is still used today.
fun thing about this? the result of all of this is that you are left with a couple similar general purpose computers that each do multiple things and talk over ethernet. So you have everything in software and see more and more bugs popping up. Suddenly breaking not available or left brakes engaging without right ones? yeah, typical sw-bug! And this is exactly what's happening in the wild. Yay!
I like this video, but you should select some other parts than brakes, like air suspension. Cybertruck has normal hydraulic brakes, and brake controller for all wheels is near electric brake booster, so your description is bit silly to anyone who knows basic of car mechanics. Yeah, there are wheel speed sensors and other sensors, and parking brake, (e-brake for USA) is likely servo operated and those can have controller setup like in the video.
If these sensors use software, theoretically, the CPU could be eliminated. The octopus, they say, has neurons in its arms that helps with thinking. It could eventually evolve to the point where the brain could reduce to the point of merely connecting the thinking neurons in the arms.
The information about Ethernet network collisions at the 16min mark is not accurate. Modern Ethernet is a switched network and does not have collisions. It hasn't worked that way since the 1990s.
I really do not see how CAN stops you from having general controllers the same as any other network. With the right software + controllers/models, you could replace the network standard from CAN to Ethernet and back without changing the wiring apart from speed. And if you are going to use cat type cable, aren't you going to use 8 wires instead of 2? I think the change might have a lot more to do with making the parts proprietary and probably patented so you are forced to buy all the parts from Tesla at a high price without any competition.
Then there's Rivian that just abandoned ethernet they were using instead of can bus due to the vampire drain. I'm curious about this because they weren't able to shut down modules on the ethernet bus.
How is replacing wire with a small computer cost or weight effective. This goes against the kiss rule and the best part is no part. How about reducing the number of stuff needs to b wired
So the architecture is basically like Beckhoff's EtherCAT only less redundant. In Tesla's architecture every controller itself is a critical failure point.
Judging by their track record of fatal & catastrophic incidents, caused by flaws, bugs or overlooking parts of the software, this is a disaster waiting to happen. Probably not going to see the product in a lot of markets. I would never want the most critical parts of a vehicle relying solely on lines of code executing properly in a general controller. There's a reason specialised equipment with redundancies are used
Seems to me developing the 48v standard was a fairly big part of Cyber truck being so delayed. For one thing, designing 48v controllers in-house & making the hardware to make them can't have been easy. Ditto for the rest of the 48v system. The time used up isn't just attributable to CT but to Tesla's shift to 48v eventually being in all their cars.
Your depiction of Ethernet is based on very old implementations. Back in the days of 10/100mb Ethernet half-duplex was a popular option to allow you to put multiple devices on two wires. You needed to implement the collision detection and avoidance protocols to minimize/eliminate collisions. This introduced an unpredictable jitter that was often unacceptable in hard realtime systems such as controllers. More modern Ethernet is full-duplex and each endpoint is directly connected to a network switch. This eliminates the collision issue and most of the jitter. Now when two signals arrive at the switch at the same time one will be sent out ahead of the other. There are protocols that you alluded to make simultaneous messages more deterministic.
For low bandwidth 10Mbit/s there is a standard defined which enables also bus topologies. It's called 10BaseT1 in different variants . Used in automotive and industrial control systems
This is the difference - in the switched scenario they won't have collisions and retransmissions even at high levels of utilization (at a cost of store and forward on a switch which used to be expensive but is now dirt cheap!) but every node has to be wired to the switch. That is what they are trying to avoid. Lots of long wires (even if small.) They are using a bus/token setup so they can guarantee delivery of the necessary data at high speed and low latency but also avoid all the wires.
@@oxptaube I did a lot of work on thin net. But you have to terminate the bus. I'd rather have a loop of full duplex ethernet switches and spanning tree protocol for redundancy to prevent logical loops and provide redundancy in case one segment of the loop is broken.
To be clear, a "48 volt controller" means it's POWERED by 48 volts, the data / signalling is a much lower voltage. Probably carries power POE style at 48 volts throughout the loop.
Decided to fact-check. According to wikipedia (Ethernet over twisted pair): "1000BASE-T uses all four pairs bi-directionally using hybrid circuits and cancellers.[16] Data is encoded using 4D-PAM5; four dimensions using pulse-amplitude modulation (PAM) with five voltages, −2 V, −1 V, 0 V, +1 V, and +2 V.[17] While +2 V to −2 V may appear at the pins of the line driver, the voltage on the cable is nominally +1 V, +0.5 V, 0 V, −0.5 V and −1 V.[18]"
@@jamesphillips2285 Now look up 5GBase-T and 10GBase-T ;) They do basically the same thing but at 1.25 Mbps and 2.5 Mbps per pair respectively. Some network cards can even lose a pair or 2 and still operate (but at a lower speed), though this is not spec and is rare to actually find. For all of these the signalling is differential - if 1 wire of the pair goes to +1 V then the other goes to -1 V. This means you can add a DC offset (such as 48 V) and the data communications will not be affected.
The physical signal voltages on the cables are "differential" types ie not measured to a constant zero level, each cable has a input or output transformer in the switch to convert to normal "single ended" voltage levels to be used in the equipment.
For what I've seen, CANBUS runs on two wires and isn't connecting all devices onto a single bus. It can branch, so a group of devices are on one segment, the other group on the other segment. There's possibility that one segment may be faulty (shorted, open etc) but the car can still move, it just generates bunch of codes and MIL goes on. 48V may be good idea for reducing currents and wire sizes but it also can do more damage in all the plugs and sockets (electrolysis, arcing). It is also high enough voltage that may give electric shock. Shorts between sensitive signal lines and power lines probably get more destructive.
Great explanation. I did a presentation at the Automotive Ethernet Congress last year about unraveling the 10BASE-T1S wiring harness, so this fits into the main area I am working on 👍😅 I wasn’t familiar with the latest Tesla architecture. Many OEMs are still struggling with zonal architecture. Keep up the good work and greeting from Bavaria.
Awesome! Glad you enjoyed the video 🤠✊🏼 And thanks for the comment! It's always good to hear from people in the industry to let me know if saying stupid things, lol
@@thelimitingfactor No all good. For the aggregated links between the zonal controllers 10G is ready and 25G is on its way. We tested also with 50G is possible over 5 m in case anybody needs it and glass fiber may be an option in future. I am im RnD try to keep an eye on trends and what may be of use in future. Tesla is quicker than the rest of the market.
I wanted to add that Ethernet collisions were mitigated over 40 yrs ago in commercial networks. Software defined routers and switches are mature and can be added to any of those generic car controllers. Growing up with Ethernet speed increases, lots of people do not realize that protocol stack bugs show up as speed increases. The CANBUS being so slow, I am sure there will be many failures nobody ever dreamed of when bus speeds are increased. Point is that Ethernet has been through the gauntlet for over 50 yrs and there is just nothing close to its robustness. Ethernet wiring EMI is very well understood since it is just about anywhere. One can also run multiple networks on the same wire e.g. one encrypted and another not encrypted. I am just touching on the tip of the iceberg on Ethernet's benefits over any other communication protocol.
Used to live and always loved Rheinland-Pfalz and Bavaria .. and the seasons' changes there. You should arrange for a visit to the Giga-Berlin plant to tour and talk with some of their auto-electric engineers. I bet you would enjoy that and could make it part of your next paper at AEC!
Totally agree. They're talking about t1s instead of can, but the major controllers still use 100/1G-base-t1. What i expect they dropped is autosar. That's sh*t's stupidity incarnate.
Maybe they were inspired by Avionics Full-Duplex Switched Ethernet from Airbus or EtherCAT ? You can prioritise frames and loose some cable in the loop.
A loop type networking was used years before the current style of ethernet networking came out. It was called Token Ring. If there was an 'end' to the loop that was not connected back to the loop a 'terminator' was needed on the end of the loop (basically a specific small resistor to keep down 'ringing' similar to water hammer absorbers). The loop protocol required a token be passed between each device to say whos turn it was to talk next, everyone being allowed a 'slot'. If the token got lost the 'controller' would restart the token on the wire. Ethernet designed for everyone to listen and talk whenever someone else wasn't talking if needed, was a overall speed improvement on a 'quiet' network, but was slower on a network with a lot of traffic, assuming each ran at the same frequencies. Yep, loops have been around a long time, and they can also be great for redundancy (traffic can flow either way around loops, not just one direction), so if it is cut somewhere, the loop can detect that and even where, but still keep functioning, of course depending on the equipment sophistication. So endeth todays history lesson from an old grey haired geek.
Ethernet also needed terminators… as did SCSI and does PCI. It is an electric thing to dampen reflected waves. Token Ring originally depended on a ring for passing around the token that allowed a station to transmit. The wires didn’t go all around the ring but were station-to-station. There was a method for detecting token loss, duplicated tokens, and for regenerating a single token if necessary but it was a bit slow.
what you are describing is not a ring archtecture (two endpoints per wire), but a traditional bus with many endpoints using the same wire. The "token ring" is just a popular system for determining whose endpoint's turn it is to speak next.
The "Token Ring" is architecturally more similar to CANBus than to a ring. (shard wire across all devices to transmit data) The Term Token Ring is just the "sofware part" to decide who can speak. basically a Token is passed around on a bus, and whoever currently has the token can talk, everyone else listens. the ring is because it is passed around, it does not refer to how the devices are connected.
I suppose you never work in the aviation or train industry and never heard of EtherCat (for automation) and Avionics Full-Duplex Switched Ethernet (for airplane and train) which were specified over 20 years ago and used since then in airplanes and trains manufacturing and testing and is the extract same concept of etherloop but fully open and generic and accessible to everybody The primary difference maybe the connector and the Power Over Ethernet specification used which is specific to Tesla I presume (they were open with the NACS connector so maybe they do the same), but those concepts exist since more than 20 years, and the revolution is to apply them to the car industry, things that cars manufacturers were lazy to do for the past 20 years when it has been applied to airplanes and trains already Finally the name etherloop refer to an « Ethernet » + loop, and the hardest part is to address the high availability and situations of closed loop which can cause packets to loop « forever » but there is already Spanning Tree Protocol (including Rapid STP ) but convergence is at 5 to 10 seconds actually depending to the settings on a generic network (like at home or datacenter/IT environment) so the hard part is to have failure detection and recovery really fast, thing which can be truly revolutionary on an Ethernet network A great link with some explanations www.militaryaerospace.com/commercial-aerospace/article/14230980/ethernet-commercial-airlines Including the usage of ARINC reference (airplane standard) fiber even (when power distribution is not necessary)
Wikipedia definition of etherloop "etherloop" have been developed, including use for automotive intra-vehicle communication in the 2020s, where a gigabit Ethernet physical network has been used with a proprietary time-sliced, network protocol for near real-time, redundant control and feedback of motor vehicle subsystems."
It expect to see that, or something very close. The lateness of Cybertruck and the long wait for the 25K car seems to be partly attributable to Tesla reinventing how a vehicle is wired and thus manufactured. It's not about two vehicles, it's about transforming how any vehicle is made.
@@donjones4719I keep thinking it’s also the difficulties they have run into on the 4680 battery. They really advertised the plan to get vehicle cost out through internal manufacturing and a 60% (~) reduction in cost from that (as I recall the battery presentation)
It's another "Industrial Ethernet", the "Loop" reminds me of EtherCat which - from what I've heard - is state of the art. They could have adopted TSN (time sensitive networking) and try to push it but seems like tesla tries avoiding industrial standards whenever possible. A really risky move, if this architecture has just a minor design flaw this could lead to many controller/networking failures and thus crashes.
19:35 "Universal controller design". . This has more implications beyond the "front end" supply chain. Parts inventory. It's a huge reduction in parts warehouse inventory/storage (ask Farzad!). Also, Service. Speaking as a Field Service Rep in another industry, vehicle space is limited. Any time I can carry 1 common part for multiple devices it's a win. . Then there's faultfinding. If you have that "odd" intermittent, elusive fault, or simply don't have a replacement to hand, you could swap 2 controllers and see if the fault moves with one of the units.
It’s also a big cluster risk. Anything not available and nothing gets produced. Any undiscovered systematic defect: have fun RMAing that one. There’s a reason high-reliability safety systems are designed pretty much the same across industries. Want to do market segmentation and have a low-end and high-end trim: congrats you now have to equip the high-end ECU on every car. Yeah you can try and upsell this with subscriptions and what not but going low-end is _hard_. And doing that on a single model is harder. It’s good but it’s not as one sided as it might look like at first.
"Any endpoint to any other endpoint" and "maximally software defined" does sound like a security nightmare if you're asking me... Potentially getting access to critical systems such as the brakes by hacking into the internet-connected infotainment system suddenly sounds like a very real thread.
Tesla's CAN systems actually already use location-defined general purpose controllers to an extent. It's part of what they've been doing since the beginning.
Excellent educational session, thank you. One of the images shows a highly significant change essential to Ethernet is replacing legacy individual wires with ribbon cables. 48V from 12V makes this significant improvement possible. While ribbon cables are not new, their use in automotive is. Improvements include, automated manufacturing, Electromagnetic Compatibility/Immunity (EMC/EMI), wire-to-wire coupling. Providing total control of which wire is next to which wire, eliminating splices, twisting wires, the list goes on and on. Not to mention sharing controllers between vehicle models, without having to engineer new connectors, simply cut longer or shorter ribbon cables. Thanks
I have been waiting for someone to expound on the implications of the ether loop. I set up one of the first industrial Ethernet networks in Canada in the early 80’s. Glad to see someone like Musk push this technology to its logical conclusion in autos.
The real issue is that lots of those cross car systems are safety critical. Braking system, lights, around car sensor packages for the various levels of self-driving and so on. Having a single approved and well tested system handling each one that you can pretty much get off the shelf is very convenient. Ensuring something like the ABS system under emergency braking is acting in a coordinated way at the millisecond timescales required on all 4 corners of the car is much easier with a single module handling it all.
That's where the EtherCAT standard helps. Each device modifies the Ethernet packet as it travels both ways around a ring. The result is a high bandwidth low latency communications with redundancy.
ABS master control will still be a single module, but it will source and send data to each brake over the network in its time slice. If/when they switch to the Brembo Sensify system this network can eliminate the hydraulic system completely (or partially, there's options there too.)
It will be interesting to see whether Tesla tries to put everything on one bus, and whether regulators let them. You can build priority schemes that give you realtime-ish performance when everything is working, but if your headlights malfunction and start spewing garbage onto the bus they're still going to take out your brakes.
CAN devices do not all have to be on the same bus. There can be multiple bus with a controller bridging communication. In general, only those devices that need to talk to each other will be on the same bus. You don't want a shorted bus taking out everything. Also, traditional vehicles do not have a pile of different controllers in different locations. They use a few large controllers with lots and lots of thick gauge wires going from those controllers to the various different devices / sensors. But this has more to do with fusing then with the communication bus. Remember, traditional vehicles have mechanical fuses mostly located in one place. Reductions in wiring will require distribution of fuses which in turn requires use of eFuses (electronic fuse) in place of regular fuses. These eFuses will each require a controller and all controllers will have to be connected together via a communication bus. But this allows you to replace a large number of cables with a single 48V power line. So great, but it has nothing to do with the communication bus used. It does require a lot of work on the user interface to allow for the management of the eFuses. No more going to the fuse box when something stops working. The UI has to report the error, reset the fuse either manually or automatically, etc. Lots of design work required but the hardware is actually reasonably simple.
One thing overlooked is that CANbus has well documented reliability and behaviour. It is an industry wide and ratified format that is extensively tested and used, and interoperable between many manufacturers. So the hardware is reliable, the software is reliable, the parts are cheap, the functionality mature, the knowledge is wide. Things you absolutely need for something dangerous hurtling down the road. So Tesla are dumping that for one that they made up themselves to save some wires. At the very least this should be concerning since it makes parts harder and more expensive to find but it could be worse than that depending on safety and failure is handled.
Convention and interoperability is great for all the reasons you mentioned, but conventions eventually become outdated and industrial ecosystems can become so entrenched in those conventions that it is assumed that there isn't a better way. Yeah, it's more expensive when you have to replace something that is custom and hard for the aftermarket to replicate. But change is necessary and the bandaid must be ripped off eventually.
There are special Ethernet standards that using a single twisted pair for collision free networking with multidrop. They are designed to replace the likes of CANbus in exactly this use case. This is what Tesla will be using. The advantage is that every software engineer and his dog is familiar with Ethernet. CANbus not so much. Basically Ethernet is taking over all network protocols get used to it.
Yea, except this is terrible because it's basically token ring with serial device sharing; if this were ethernet with host voting, it'd be fine. It's going to be dangerous
i don't see many more issues. you mean mechanics with a wrench of hackers? because you need latter nowadays anyway. can is not much of a better. it's still network. controllers are still closed
This is cool and all until your are paying triple the price for what was once just a head light controller that now is also also for your windshield turning signal abs tcs
I was very interested on the Tesla 48V system and how they 'solved the CAN-Bus'. It came as a total surprise having such an explanation from you as I did not expect. A good starter for a very important subject. Going down to all details will require much more time and explanations. Up to now there is very little.
😁 Yes, I didn't expect it either, lol. I'm sure there are people better positioned to explain it, but I wasn't satisfied with any of the video I saw. And totally! There's a lot more to it than I showed here.
Good video, but they wouldn't pass uncompressed video from even a single camera over Etherloop as even a basic 2MP camera generates over 1.4Gbps at just 30fps. Now they could be using Ethernet cameras (which perform H.264/5 compression at the camera), but that introduces at least 2 frames of latency which wouldn't be acceptable for self driving, so my guess is that they'll continue to use something like GMSL for the video feed to the FSD computer and then perhaps forward a compressed stream of the rear and sideview cameras over the Etherloop bus so that it can be consumed by services such as the primary display.
Currently automotive cameras use "serdes" , like FPD-link or GMSL . Automotive Ethernet is currently being standardized to support also speeds up to 25Gbit/s. And in future even more .Currently video data is not compressed because lossless compression does not work well with certain safety measures. Typical speeds are currently 3-8 GBit/s .
Thank you. I knew it sounded familiar. Like several of the phrases Elon likes to use, he didn't come up with them, he's quoting phrases long used by engineers, e.g. "the best part is no part." He doesn't claim originality but his high profile introduces the phrases to non-engineers.
While I like this idea, I can't help but think this will make repairs even more hostile to perform. Fender bending a Tesla is already a 10K price tag; at some point insurance is going to straight up say it costs too much and won't insure them.
Both the medical and insurance fields need to be thrown away and overhauled anyways. Both are scams, and Both are money rackets designed to steal from their customers.
@@thelimitingfactoreasier for the Tesla tech with proprietary software to access the information and program the module. Already demonstrated by Kyle boostedboiz, rich rebuilds, and John Deere’s right to repair lawsuits. Every manufacturer has this to an extent already like fords ids requiring $600 subscription plus the $1,000 gateway module.
This does seem to reduce the amount of redundant systems and simplify the complexity. You could probably get on the network with a diagnostic device and ping all the components to figure out what's wrong....
20:45 -> This should be Tesla's slogan. "Making the impossible merely late" xD
🤣🎯
It's essentially Musk's slogan and doesn't apply only to Tesla.
@@celeron55 Project management triangle, "Time, Quality, Cost - pick two". Elon is trading time for better quality and reduce cost.
How about "We at Tesla eliminate the "stupid" no one else was willing to" Ok, that's harsh. Try again. "We at Tesla design for the future" Ok, maybe that's a bit better.
I prefer “your requirements are stupid”.
Ethernet is a great foundation for real-time deterministic traffic. Didn't know they used it but glad to hear they used it. Thanks for sharing.
Minor clarifications: The Ether part means it will be a different industry standard than CAN, not a complete invention reinvention of the network layers. They will probably be using IP4, to have open source components work right away. The local area network in private homes are typically a star or a tree, but that is not failure tolerant. Any component can be offline with a single point of failure. The Loop-part of the name is a reference that it is a loop-architecture, not a bus. That means if you cut the network, the packages will take the other way around the network. Like TokenRing. It is a fault tolerant network. Each zonal controller will effectively have a small router. It will be interesting to see which OSI layer they create the “loop” in: actual loop, or virtual, but loop-like.
Probably they won't be using IP for time sensitive / safety critical parts like brakes. But there are related ethernet standards for that, see "Time Sensitive Networking" which is about making ethernet usable for real-time workloads.
I suppose it might be possible to run less critical workloads like entertainment over IP using the same wires as the real-time stuff, just at a lower priority.
Is there a MTU size published somewhere?
I'm pretty sure they have said it's ethernet physically but it does not communicate with IP and you do not need IPv4 for that, IP is layer 3 and you only really need layer 2 to have communication.
Ethernet must be loop-free. Though modern switches can detect loops and deactivate those ports.
Aren't all the issues around packet collision introducing latency addressed by QOS tagging?
Etherloop sounds like an industrial network protocol like EtherCAT, Profinet, or Ethernet/IP. There are many chips out there that support these industrial protocols. All are time-sliced for reliability and consistency.
Etherloop seems to be a great idea. Imagine using 20 times less wires with that new design. Thanks for the visual explanations. Great work, your speculation is probably right.
Sure thing! 🤠🙌🏼
They may have taken inspiration from Ethercat, which involves each device adding its data into a 'frame' that gets sent around the loop at regular intervals (~4KHz) rather than individual devices messaging one another
Sounds like they just took modern computer networking and stuck it in a car. Computer networking already supports all the functionality you described including delivery of power at 48v to endpoints.
I enjoy your videos. I've been involved with engineering Ethernet on aircraft (an expert). I strongly suspect some of your assumptions don't apply to Etherloop. I didn't read your video's comments but I'm guessing others have set things right.
Particularly are these key points:
1) Tesla called it Etherloop because the system would be implemented as a loop so the system redundant.
2) testa uses dual end points with separate processors in the headend.
3) Tesla used a modified spanning bridge protocol to avoid packet storms
4) testa uses non-blocking cross-point Ethernet switches and possibly multiple endpoint speeds to implement deterministic package delivery.
5) testa uses both multicast and points to point IP addressing.
Respond if you want more info.
1: I think they just like the word loop.
3:why spanning bridge over normal switching in this environment? Modern implementations can certainly cope with the traffic and a vanilla implementation should do.
5: what would be the use case for multicast in a car? Nothing really practical comes to mind.
Multicast would be a very logical application. It’s essentially how every E2E architecture works today and for good reason.
For example anything related to vehicle dynamics (speed, collision warning, braking, steering, …) is usually multi-consumer. Another one is extensibility. Want some additional signal for a new feature? Just get it from the bus (multicast). No need to change any configuration or firmware of the existing network.
@m0rish what is the benefit of using an unreliable transmission like multicast? Tcp ack/nack eror detection/ correction, etc seems more applicable. Unless things are drastically different, systems have had a single consumer of signals, the computer. Don't believe the senders talk to each other. Seems best that a system like a car have central control and coordination. Else things get complicated and unpredictable quick
@@criticality2056
Consider multicast for transmitting an identical file to 1000 boxes on an aircraft. Each box performs a checksum on each megabyte and requests multicast retransmission of that block after the whole file is sent. Almost a thousand times faster than tcp/ip
@@criticality2056
Spanning tree is needed to heal a loop of 100 switches with only two ports on the loop
Presumably this is going to be in everything Tesla produces in the future. I imagine the need for this in the Unboxed production process, is that you need a simple way to connect each of the pre-wired regions together without having to install a loom after the parts have been assembled.
I suppose the controllers could be identical for each corner of the vehicle, and for every vehicle that Tesla makes. There's a huge economy of scale using that approach.
So there doubling the number of connectors in a moving object with a lot of vibration and environmental factors that’s going to cause teething problems
Etherloop with Dual TX (Transmit) and Dual RX (Recieve) in full duplex should act the exact opposite. twice the data means even if one path fails you have complete redundancy thru the other path between Controller and all of the vehicle's sensors. Etherloop should eliminate similar Haywire situations most folks experienced in their lifetime using current CANBUS technologies. and give enough time to diagnose the single point of failure and find i.e. disconnect in wiring on the other path OR bad sensor failing it's healthcheck , etc.... and there are many off the shelf ethernet tools which should make finding problem area using time-domain reflectometer (TDR) tools a breaze
Fantastic vid Jordan!! I never could really wrap my head around Tesla’s ideas here, now I understand much more of it
Really happy to hear it! I saw a lot of people covering it, but there was so much missing information that it didn't make sense for me either. So, I made the video that I wanted to see 😁
Ohh but what's the under the hood of the etherloop (transport layer, think tcp/ip), that's the most interesting question! Since they have point to point connections the network layer is very simple, and transport my guess would be a modified UDP with some kind of priority information (like CAN ID). Man that would be very simple and very fast... I think they would simplify and merge OSI layers as they don't care about many features there. Jealous of those engineers.
You can have a look at standards like the ones used for TSN and 1722 for encapsulation of frames , a lot of Layer2 stuff 😊
The range of things you can make me understand is amazing. Your explanations are so clear and are presented in a sequence that builds on each previous step. The latter should be a no-brainer for any exposition but is too frequently not attained. I'm sure that takes a lot of work.
Ha! You just described exactly my philosophy when I'm writing. Sequencing! Yeah, I find so much information out there is put together in a sloppy way. It's aggravating. But, maybe I'm just a bit too much on the spectrum, lol
@@thelimitingfactor I think you're in just the right spectrum sweet spot. Well, for this at least. Some other things aren't so easy for us folks.
It would be a rather safe bet to think that "Etherloop" actually is "Single Pair Ethernet". Which would be compliant with any of these standards.
IEEE 802.3cg 10BASE-T1L if you like low cost, low energy (110mW), long length (1000m), and 10Mbit/s is enough (still between 80 and 10 times faster then CAN-bus).
IEEE 802.3bw 100BASE-T1 if you think that a compromise between speed, energy consumption (220mW), and distance is great (800 to 100 times faster then CAN-bus).
IEEE 802.3bp 1000BASE-T1 if you opt for the highest speed possible (max 15 meters) (within a car length 8000 to 1000 times faster than CAN-bus).
It has been designed for usage in cars. It is a great standard that makes a lot of sense.
Tesla may call it Etherloop as it actually is a bus, so it will pass through all units. In reality, be closer to the 1990 RG-58 COAX 10BASE-2 bus Ethernet but on a single twisted pair instead and full duplex instead of half-duplex. It will still have bus collision as an efficiency limiting factor, but with enough lanes used, it is not an issue.
I have been waiting for the first car to use that standard for about 6 years now...
Apart from the copper advantages, I dod suspect, the use Power-over-Ethernet (PoE) specifications to distribute power over the Etherloop. The spec's for PoE provide at least 44V and Up-To 50W of power / Ethernet-cable. This is a great advantage 1 standaard Etnernet cable can power every controller and everything else from the separate 48V power system. Also eliminates (reduces) cross-wire interference due to voltage similarity.
Thank you for making this video which is like a professional quality training material.
One aspect you did not cover is the risk of making everything software-based. A failure or defect could have more far reaching consequences for safety.
9:00 Using 48V will not help thermal management because same wattage for the chips will still generate same amount of heat load no matter what voltage you use.
Note that EtherCAT has existed for well over a decade at this point, and is used in safety critical parts of simulators today. It is also used for CNC control. This has extremely defined latency, and solves the problems of traditional Ethernet. However, the whole master controller thing may not be what Tesla wants.
I'd also like to address the whole part about random backoff times mentioned at around 16:50. That's only a concern when multiple devices are plugged into a single wire, and is almost never the case in modern infrastructure. Decades ago we used "network hubs" which just tied the wires together in a fancy box with a repeater. Today we use "network switches", which operate in point to point mode with other computers. This centralized network switch is known as a "star topology".
Another fun thing you may be interested in is POE (Power Over Ethernet). Since Ethernet is a differential signaling protocol, it can be thought of as AC. Well, we can apply a DC bias and power something with that. Here's the interesting part. That DC bias used for POE happens to be 48V. It is a common voltage, so may be coincidence, but could reduce the wire count even further.
Etherloop is no new technology, Clipsal C-Bus smart home system invented 20 years ago by Australia Clipsal which later sold to Schneider Electric.
Are you sure? Cbus is an RS-485 based serial protocol, essentially similar to Dynalite, KNX and also similar to many other building automation protocols.
I hesitated to watch this video due to its length, but turns out it's a great video!
CAN and ethernet both need firewalls for security. You don't want hacks to the cabin entertainment system to put brakes and steering at risk. So, there are separate networks. For safety and security. Also, any network wires that extend outside the locked envelope need to be firewalled because they are at risk of hacking. For other vehicles (not tesla), that included blind spot radar mounted in the rear fender well. That may not apply to teslas.
There's no such thing as a CANBIS firewall, because CAN doesn't have device IDs or any concept of addressing. It's a terribly insecure protocol. Like not even insecure, but non-secure. The concept of security doesn't exist in CANBUS itself, it can only be layered on top.
With etherloop, they will have to likely build a new protocol to run, but now with advances in frequencies on a single wire, they can send multiple signals over a single wire too. So send your high speed critical signals on a priority frequency and send all other data points as a lower frequency. Think of how DOCSIS works.
it seems that Etherloop is a variation from the industrial motion protocol called Ethercat. This protocol runs data bus cycles in less than 1ms. Ideal for high precision industrial applications such as robot synch In a production line, or when precise synch is needed for reading/writing IO block nodes. Perfect for a vehicle application.
This was my first thought too, but I would be concerned about message priority. With video devices and the payload size, these should be lower priority to command controls. With robo taxi etc. perhaps they are critical priority. To my knowledge Ethercat is like a train with the information making stops at each node and gathering information adding to the “train” of information. Mixing a control command behind video or other high bandwidth item may prove an issue but the high speed of the protocol might compensate. All I know is having video on the same network as your factory is a big no no for industrial automation. Having an intelligent switch that can determine priority at the beginning of the frame would be an important consideration IMO. The other consideration that will be of import is encryption. Industrial protocols are now working on encryption/authentication standards. I would be quite interested in understanding how this protocol works as I think believe it is ground breaking.
etherloop is great for personal automobiles, but it will be a GAME CHANGER for over-4 wheel vehicles (tesla trucks), trailer engineering, and commercial delivery fleets
As someone who understands a thing or two about this video, you are bang on target.
That's great to hear! I've had some very mixed responses. 😁
Mybe this was brought up and maybe the unboxing revealed info about this, but i have been phantasizing about endpoints that ‘speak’ etherloop. So a breaklight consists of, say 20LEDs, those LEDs are driven by a simple microcontroller (think arduino kind of thing) the microcontroller received its instructions from what is called a controller in the video, but over the etherloop, not via cross car wiring. The microcontrolles can also be fairly generic and the controllers can be simple or complex and software defined, as you like. But the need for cross car wiring is eliminated. You only need at each endpoint a power rail and an etherloop connection.
Ethernet hast some benefits not mentioned here. The connectors are standardized which makes devices cheaper to connect.
There is a standard for power over ethernet PoE. This could be used to not only replace CAN, but in many cases also an extra power supply connection. Maybe the hubs would need direct power supply because of their provision to the connected devices.
Maybe planes, subway trains, trains and trams are also using some of the devices which would reduce the cost per device because of production scaling effects.
Its looking more like the Cybertruck is a testbed for new tech they will be using in later Tesla models. If you're going to throw out many standards and introduce modern ones like Steer by wire, 48V LV system, etherloop modules & rear steering, a low volume product is the best place to test it. Curious if that means Tesla will release a Y/3 style pickup truck in the future and when this tech will trickle down to the Y/3/S/X.
Industrial automation has been using sensors directly connected to a network for quite a while. really saves a lot on wiring and maintenance, especially grounds management.
Iirc the ieee have specified a new ethernet standard for deterministic ethernet so that time critical messages can be utilised.
There is already a method of tagging quality of service on ethernet so that time/flow critical applications such as VOIP and video can be used. However both these applications it is more important to ensure no jitter or flow interruption than ensure immediate delivery.
The new standard is supposed to deal with time critical operations such as braking, steering etc.
higher voltage doesn't change much signal lines, as they are limited by cost of fabrication and ruggedness. Plus, every logical junction must dissipate more. There might be an advantage for noise immunity ...
Do you know what protocol do the individual devices communicate to the controller with? SPI? If Tesla has to make custom modifications to the ethernet protocol stack, it seems like instead they could have developed a new protcol from scratch that is much simpler than TCP/IP and could be implemented on even the most basic microcontrollers allowing each device to connect directly to the etherloop and get rid of the need for the regional controllers.
Oh man! That's beyond me, but it makes sense. This video was a stretch for me. I know there are more level/layers to this and I'm just scratching the surface.
Hopefully someone else can respond intelligently when I publish it.
Modern microcontrollers are plenty powerful for TCP/IP, it's not that heavy of a protocol. We're far past the 8 bit chips now. That said, 'EtherLoop' sounds a bit like EtherCAT - which would be great for this kind of thing, they may well be basing it on that, or something similar. It's a rugged Ethernet style protocol, with custom chips that handle the comms on the slave side, allowing for Realtime communication, and even certified safety over the ethernet line. I suggest looking up 'EtherCAT' and 'Safety over EtherCAT'
Why would they use TCP/IP? Ethernet frames should be more than plenty (with a convention of resending info often or in certain cases using ack frames).
Definitely not TCP/IP. Doesn't make sense to use an ancient protocol when you control the entire ecosystem. And I wouldn't sit in a car that uses TCP/IP for braking.
You need a system that's extremely reliable and has a guaranteed maximum latency well under a millisecond. This involves the hardware as much as the software.
I would go with some kind of token ring architecture, which is older then ethernet. The wires form a loop, and the data goes around until it finds the destination. Could be bi-directional for free redundancy. It's like a train going on a looped track, and each station can add or remove cars as needed. The control logic is trivially simple, you receive the data, use what you need, and pass on the rest to the next node in the loop. You know when you are allowed to send and how much spare capacity left, so there's no collision or packet loss. And prioritization is easy too. If there's no more room for your message, just replace a lower priority one. Or if you don't find one, delay or drop yours depending on the type.
Can have multiple "trains" in each direction to further reduce latency.
The weakness of this system is that it's vulnerable to faulty or malicious nodes, but here neither should be an issue.
A lot of the features are implemented in the dedicated Ethernet switches in hardware. The en- and decapusaltion of data can be done in the controller .
To compete, other car manufacturers should go to the increased level of software modularity which Tesla exploited to reduce # of controllers and wiring. Instead of selling a >physical thing< requiring its own controller and wiring, 3rd party suppliers should be moving to selling software modules instead.
Excellent video. I'm writing a report on that topic and 100% agree with everything said. I know some Chinese OEMs are also deploying zonal architecture, but I'm not sure if those are interconnected via an Ethernet backbone. By the way, you forgot to mention "TSN" (Time Sensitive Networking), a key technology to make Automotive ethernet deterministic and suitable for safety-critical applications
Tesla still needs to implement some redundancy in the wiring due to shorts or open circuits in the Etherloop cables. But I get it! It all comes down to configuration management or the software features, variant handling, and fall-back/promotion of features to control I/O on another ECU remotely...
Good information. This is a real game changer, not only for vehicles but for anything complex. It's a bit like when hardrives were SCSI, mouse/keyboard were wired and had different plugs than printers. I'm not sure that this Tesla architecture if it becomes a standard can make any licensing fees for Tesla. Likely it's too generic. (Tesla might be able to sell 48v components, because no one is making these. Cars were 6v until the 1950s, then 12v. Since about the 1960s they could've gone to 24v and then 48v which would've save billions in copper. What's happened is all OEMs (except) Tesla use off the shelf components: lights, sensors, wiper motors, etc... which are now all 12v. They're so used to going through catalogues and making phone calls that it would be like starting from scratch for most OEMS. This is why when Sandy Munro looked into the Ford Mach E and the VW EV he found triple the number of hoses and wiring as in a Tesla, and much less efficient use of space. The VW has no frunk, but also almost nothing behind the dash where it would've been out of the way. This increased complexity also increases failure & recalls. )
For boats there's the NMEA 2000 network. It's a 12v CanBus system and is compaatible. You could stick a windvane on your car and plug it into CanBus. NMEA 2000 has a few features that must also be common for CanBus: A backbone that runs the length of the vehicle (boat or car) and drops to the various sensors.The backbone is powered by a 12v connection(through one of the drops dedicated for this) but this 12v only powers the bus-- each instrument requires a separate power line. Drops can be no longer than 6m (20'). My sailboat has a 63' mast and instruments at the top. The workaround is the Backbone runs to the front sensors near the bow, and then doubles back and goes up the mast. The Drops then for the wind direction, speed, any cameras, maybe a radar on a spreader are very short. (I think the Backbone can be 170m long -- some very big length.) There has to be terminators at each end of the Backbone. On my boat these will be in the binnacle (in the cockpit at the wheel, where the new chartplotter is and my old Autopilot - which has never had a single issue in 20 years.) Third the NMEA 2000 network is infinitely adaptable. It plugs (and waterproof screw attachments) and modular. Right now it's in my binnacle down to above my engine. Later it'll run forward to the new depth sensor, and if I replace everything on top of the mast, I'll unscrew the terminator add more backbone to go up the mast... It's like Legos.
Wnat the data that flows into the backbone must be doing is identify the instrument source and the quantity. Signals for operation that flow back along the backbone must be understandable by the unit, lights, camera (to turn on, move, etc..)
NMEA 2000 has a couple of features. First all manufacturers agreed to a set of standards -so everything that uses it is cross compatible. Second it refreshes up to 2000x/second. The previous 0813 (SeaTalk in RayMarine) refreshes at a much lower rate. My boat has both. There are translators sold that allow connecting the older 0813 instruments to the NMEA 2000 network, but I haven't tried them yet. I'm waiting to find verifiable real world cases where this is working. Otherwise I'll just buy new sensors.
Just a download... if anyone is nerdy enough to be interested. And of course as I was bending my brain to learn all this last month and then buying the gear.... of course I had the thought: As soon as I get this all hooked up, newer and better wireless gear is going to replace it. (There are wireless mast top instruments but so far these have a reliability issue.)
Another brilliant presentation, thanks
The 48V and Ethernet (or loop) are not necessarily codependent and shouldn't be thought of as such. Many automotive systems (CAM sensors, crank sensors) actually use 5V. They are internally regulating the 12V down in the ECU for example. The car could move to a 48V system and do the same thing. It could still be CAN buss but save significantly on wire.
This is called "zonal architecture" and virtually all OEMs are doing it now. Btw it's independent from the bus type, can be done with CAN too. Ethernet does not work that way. All automotive ethernet versions are collision-free. 100BASE-T1 (BroadR-Reach) and 1000BASE-T1 (RTPGE) are point-to-point with switches. 10BASE-T1s uses bus topology (just like CAN), but it also implements a token scheme to avoid collisions. And finally, there are MANY networks in cars. Multiple CAN, LIN, FlexRay, Ethernet and other channels for different purposes.
The diagram at 16:08 might be a bit "wrong" because it adheres to bus topology.
Etherloop would, as the name suggests, likely use a ring bus instead, which the cable at 9:26 also suggests.
Ring networks aren't as prone to collisions as a bus network (as the next node can simply queue up the incoming data to send after its own data - or before it if it has a high priority), especially when using a "token ring" in which a "token" is passed along and without token, you're not allowed to talk (although this comes with an obvious latency penalty).
However, payloads likely don't need to be that big so the latency probably shouldn't be *too* big (sub-1us for an entire "rotation" would still be achievable just fine).
OEMs have been using Flexiray and Ethernet in their cars for years now!
The issue with the common "corner controllers" architecture is that it makes an FMEA extremely complex, because all systems are inter-related at a H/W and S/W level. I mean, call me old fashioned but it's rather not find out that my airbags didn't fire because i was at 25degC on the HVAC and had the interior light on at the moment of impact, or that my car did an OTA update last night to fix a bug with the satnav, but actually borked the ABS system......
I'll happily carry an extra 10kg of wire to get systems that are designed, developed, validated then LEFT ALONE for the life of that model.
It will be very interesting to see how far they go with this, ever diminishing gains imo. For example, an ABS controller has all the critical systems directly on one PCB, mounted directly (with non soldered push fit contacts) to the ABS modulator (the mechanical bit with the pump and solenoids) precisely because any failure to drive those solenoids in precisely the right manner can lead to a LoC (Loss of Control) and that, as Toyota found out, gets expensive, very quickly (The $2.1 BILLION Toyota was fined in 2014 would have bought a LOT of wire...)
Now it's absolutely possible to run a safe vehicle on a distributed control and co-ordinated network, the issue is if the risk is worth the reward, and if the (significant) extra validation forced upon you is worth the effort as you now have to do it for ANY change whatso ever......
one note, increasing the data rate does wonders for reducing latency.
if you compare the highest speed canbus (0.05 - 1Mb/s) with gigabit ethernet, you have 1000x-20,000x the bandwidth. At some point, this increased speed means that even the retry oriented nature of normal ethernet will get the message through faster than the canbus would
ETER LOOP is a nifty name change for something that already has been going on in auto mfr for about or more than 25 year (by wire throttle controls GM 98’) this is an expansion on that if I understand you right.
At about that time it was announced that in 3-4 yrs things at Ford would be shifting to single wire 36-42 volt systems, which fizzled. But from the perspective of “electric drive”. any voltage would be feasible/doable, and the higher the voltage always means -the less wire, -the end goal, and the separate controllers will get it there no doubt.
I would imagine that NTSB will have a “say so” on by-wire (Ethernet) control of subsystems like brakes, steering, exterior lighting, and is most likely why crossbody wiring on braking will remain.
Your comments on the impossibility of CAN on subassemblies is not so however because in cases like that a bulkhead or “Cannonplugs” are. And have been utilized in just such situations since that very issue arose on high volume assembly lines for offplant subassemblies in aircraft at the beginning of WWII.
Each sub assembly comes pre-wired with a multi pinned connector. A bulkhead connector. And at some point, if not already
Tesla will do the same thing just with 42 volt instead of 12.
Power over Ethernet (PoE) is a common standard all over the world, providing 48V power to desk phones, access points, and some computers in every enterprise network for the past 30 years. I wonder if they've redesigned everything to use standard PoE, and that's why they chose 48V architecture.
On a munro video tesla stated that the etherloop was more like a token ring in that time on the network was sliced, each controller had its own unique time slice, that means no message collisions and no resends (unlike ethernet). Thus the new name. With this strategy you can saturate the bus to 100% traffic with no lost data as opposed to ethetnet where data can be lost at around 70% saturation.
I have wondered why they haven’t used Ethernet with POE..
relay with extra power if needed
One of the other reasons to move to 48v would be prep for moving to ethernet, as they can then easily use POE to deliver power to the controllers.
CAN does not mean only a single bus and wire. Many vehicles have multiple CAN
For different systems yes
But that doesn't solve the cross car wire problem
Now dying from ping became a real thing
I don’t believe your statement regarding controllers being redesigned completely to accommodate 48v supply is correct. Micros typically run on 3/3.3/5V and these are provided by the onboard power supply stages. Tesla isn’t replacing STMicro or Infineon or NXP or TI chips.
Its just industrial ethernet applied to the automotive sector.
Just shows how conservative the industry is...
So the same way clusterinf can have a single peuce of software running across a cluster of computers, these mini controllers that are multi use is just four computers. Then the Software will cluster to all conputers ro comptrol all breKs as a single unit. Thats a great way to go about it!! It will make any vehicle troubleshooting std across all manufacturers and make it easy!!!!
How did the CAN Bus standard evolved?
While the application is novel, the technology really isn't. EtherCat is very similar and has been around for some time. It is found in many industrial automation environments. Even that is an evolution of ARCnet, which was developed in the 70s and is still used today.
Tesla. Remarkable.
Aug 8 will be very interesting.
fun thing about this? the result of all of this is that you are left with a couple similar general purpose computers that each do multiple things and talk over ethernet. So you have everything in software and see more and more bugs popping up. Suddenly breaking not available or left brakes engaging without right ones? yeah, typical sw-bug! And this is exactly what's happening in the wild. Yay!
I like this video, but you should select some other parts than brakes, like air suspension. Cybertruck has normal hydraulic brakes, and brake controller for all wheels is near electric brake booster, so your description is bit silly to anyone who knows basic of car mechanics. Yeah, there are wheel speed sensors and other sensors, and parking brake, (e-brake for USA) is likely servo operated and those can have controller setup like in the video.
If these sensors use software, theoretically, the CPU could be eliminated. The octopus, they say, has neurons in its arms that helps with thinking. It could eventually evolve to the point where the brain could reduce to the point of merely connecting the thinking neurons in the arms.
Look similar to the wiring design choices Airbus introduced with the 380 close to 20 years ago
The information about Ethernet network collisions at the 16min mark is not accurate. Modern Ethernet is a switched network and does not have collisions. It hasn't worked that way since the 1990s.
Great video!! Brilliant Tesla!
Not totally. By law all cars have to have ODB-port for external diagnosis connections. And that is on top of CAN bus, still.
To me Etherloop is EtherCat which is used mostly in the industry.
Or AFDX from avionic ?
They should do wifi controllers, who need wires
I can't wait to see a harrware freeze with rhe brake system, like it happens sometimes when the screen or audio level becomes unresponsive.
I really do not see how CAN stops you from having general controllers the same as any other network. With the right software + controllers/models, you could replace the network standard from CAN to Ethernet and back without changing the wiring apart from speed.
And if you are going to use cat type cable, aren't you going to use 8 wires instead of 2?
I think the change might have a lot more to do with making the parts proprietary and probably patented so you are forced to buy all the parts from Tesla at a high price without any competition.
Then there's Rivian that just abandoned ethernet they were using instead of can bus due to the vampire drain. I'm curious about this because they weren't able to shut down modules on the ethernet bus.
They should share cables with power and data, perhaps.
How is replacing wire with a small computer cost or weight effective. This goes against the kiss rule and the best part is no part. How about reducing the number of stuff needs to b wired
So the architecture is basically like Beckhoff's EtherCAT only less redundant.
In Tesla's architecture every controller itself is a critical failure point.
5:00 Little mistake on the weight order
Judging by their track record of fatal & catastrophic incidents, caused by flaws, bugs or overlooking parts of the software, this is a disaster waiting to happen. Probably not going to see the product in a lot of markets.
I would never want the most critical parts of a vehicle relying solely on lines of code executing properly in a general controller. There's a reason specialised equipment with redundancies are used
Seems to me developing the 48v standard was a fairly big part of Cyber truck being so delayed. For one thing, designing 48v controllers in-house & making the hardware to make them can't have been easy. Ditto for the rest of the 48v system. The time used up isn't just attributable to CT but to Tesla's shift to 48v eventually being in all their cars.
Yes! It's a worthwhile investment for all future cars.
Is Tesla going to open-source Etherloop?
Your depiction of Ethernet is based on very old implementations. Back in the days of 10/100mb Ethernet half-duplex was a popular option to allow you to put multiple devices on two wires. You needed to implement the collision detection and avoidance protocols to minimize/eliminate collisions. This introduced an unpredictable jitter that was often unacceptable in hard realtime systems such as controllers.
More modern Ethernet is full-duplex and each endpoint is directly connected to a network switch. This eliminates the collision issue and most of the jitter. Now when two signals arrive at the switch at the same time one will be sent out ahead of the other. There are protocols that you alluded to make simultaneous messages more deterministic.
Good point! A few other people have made the same comment
For low bandwidth 10Mbit/s there is a standard defined which enables also bus topologies. It's called 10BaseT1 in different variants . Used in automotive and industrial control systems
This is the difference - in the switched scenario they won't have collisions and retransmissions even at high levels of utilization (at a cost of store and forward on a switch which used to be expensive but is now dirt cheap!) but every node has to be wired to the switch. That is what they are trying to avoid. Lots of long wires (even if small.) They are using a bus/token setup so they can guarantee delivery of the necessary data at high speed and low latency but also avoid all the wires.
Yep.
@@oxptaube I did a lot of work on thin net. But you have to terminate the bus. I'd rather have a loop of full duplex ethernet switches and spanning tree protocol for redundancy to prevent logical loops and provide redundancy in case one segment of the loop is broken.
To be clear, a "48 volt controller" means it's POWERED by 48 volts, the data / signalling is a much lower voltage. Probably carries power POE style at 48 volts throughout the loop.
Exactly 👍
Decided to fact-check. According to wikipedia (Ethernet over twisted pair):
"1000BASE-T uses all four pairs bi-directionally using hybrid circuits and cancellers.[16] Data is encoded using 4D-PAM5; four dimensions using pulse-amplitude modulation (PAM) with five voltages, −2 V, −1 V, 0 V, +1 V, and +2 V.[17] While +2 V to −2 V may appear at the pins of the line driver, the voltage on the cable is nominally +1 V, +0.5 V, 0 V, −0.5 V and −1 V.[18]"
@@jamesphillips2285 Now look up 5GBase-T and 10GBase-T ;) They do basically the same thing but at 1.25 Mbps and 2.5 Mbps per pair respectively. Some network cards can even lose a pair or 2 and still operate (but at a lower speed), though this is not spec and is rare to actually find.
For all of these the signalling is differential - if 1 wire of the pair goes to +1 V then the other goes to -1 V. This means you can add a DC offset (such as 48 V) and the data communications will not be affected.
The physical signal voltages on the cables are "differential" types ie not measured to a constant zero level, each cable has a input or output transformer in the switch to convert to normal "single ended" voltage levels to be used in the equipment.
Great explanation of CANBUS vs EtherLoop. Citing and including the visualization of both was quite helpful too. Thanks!
You're most welcome man!
For what I've seen, CANBUS runs on two wires and isn't connecting all devices onto a single bus. It can branch, so a group of devices are on one segment, the other group on the other segment. There's possibility that one segment may be faulty (shorted, open etc) but the car can still move, it just generates bunch of codes and MIL goes on.
48V may be good idea for reducing currents and wire sizes but it also can do more damage in all the plugs and sockets (electrolysis, arcing). It is also high enough voltage that may give electric shock. Shorts between sensitive signal lines and power lines probably get more destructive.
Great explanation. I did a presentation at the Automotive Ethernet Congress last year about unraveling the 10BASE-T1S wiring harness, so this fits into the main area I am working on 👍😅 I wasn’t familiar with the latest Tesla architecture. Many OEMs are still struggling with zonal architecture. Keep up the good work and greeting from Bavaria.
Awesome! Glad you enjoyed the video 🤠✊🏼
And thanks for the comment! It's always good to hear from people in the industry to let me know if saying stupid things, lol
@@thelimitingfactor No all good. For the aggregated links between the zonal controllers 10G is ready and 25G is on its way. We tested also with 50G is possible over 5 m in case anybody needs it and glass fiber may be an option in future. I am im RnD try to keep an eye on trends and what may be of use in future. Tesla is quicker than the rest of the market.
I wanted to add that Ethernet collisions were mitigated over 40 yrs ago in commercial networks. Software defined routers and switches are mature and can be added to any of those generic car controllers. Growing up with Ethernet speed increases, lots of people do not realize that protocol stack bugs show up as speed increases. The CANBUS being so slow, I am sure there will be many failures nobody ever dreamed of when bus speeds are increased. Point is that Ethernet has been through the gauntlet for over 50 yrs and there is just nothing close to its robustness. Ethernet wiring EMI is very well understood since it is just about anywhere. One can also run multiple networks on the same wire e.g. one encrypted and another not encrypted. I am just touching on the tip of the iceberg on Ethernet's benefits over any other communication protocol.
Used to live and always loved Rheinland-Pfalz and Bavaria .. and the seasons' changes there. You should arrange for a visit to the Giga-Berlin plant to tour and talk with some of their auto-electric engineers. I bet you would enjoy that and could make it part of your next paper at AEC!
Totally agree. They're talking about t1s instead of can, but the major controllers still use 100/1G-base-t1. What i expect they dropped is autosar. That's sh*t's stupidity incarnate.
Maybe they were inspired by Avionics Full-Duplex Switched Ethernet from Airbus or EtherCAT ? You can prioritise frames and loose some cable in the loop.
And they probably use the same "flyby" packet modification and the name "loop" implies they are using the same redundant ring design.
EtherCat was the first thing that came to my mind, funny how it sort of replaced CAN in industrial automation, but not in vehicules
A loop type networking was used years before the current style of ethernet networking came out. It was called Token Ring. If there was an 'end' to the loop that was not connected back to the loop a 'terminator' was needed on the end of the loop (basically a specific small resistor to keep down 'ringing' similar to water hammer absorbers). The loop protocol required a token be passed between each device to say whos turn it was to talk next, everyone being allowed a 'slot'. If the token got lost the 'controller' would restart the token on the wire. Ethernet designed for everyone to listen and talk whenever someone else wasn't talking if needed, was a overall speed improvement on a 'quiet' network, but was slower on a network with a lot of traffic, assuming each ran at the same frequencies. Yep, loops have been around a long time, and they can also be great for redundancy (traffic can flow either way around loops, not just one direction), so if it is cut somewhere, the loop can detect that and even where, but still keep functioning, of course depending on the equipment sophistication. So endeth todays history lesson from an old grey haired geek.
Ethernet also needed terminators… as did SCSI and does PCI. It is an electric thing to dampen reflected waves. Token Ring originally depended on a ring for passing around the token that allowed a station to transmit. The wires didn’t go all around the ring but were station-to-station. There was a method for detecting token loss, duplicated tokens, and for regenerating a single token if necessary but it was a bit slow.
Those were the days!! 👍
(Old gits of the world unite!!)
I love insights like this! Thanks for the comments!
what you are describing is not a ring archtecture (two endpoints per wire), but a traditional bus with many endpoints using the same wire. The "token ring" is just a popular system for determining whose endpoint's turn it is to speak next.
The "Token Ring" is architecturally more similar to CANBus than to a ring. (shard wire across all devices to transmit data)
The Term Token Ring is just the "sofware part" to decide who can speak. basically a Token is passed around on a bus, and whoever currently has the token can talk, everyone else listens. the ring is because it is passed around, it does not refer to how the devices are connected.
I suppose you never work in the aviation or train industry and never heard of EtherCat (for automation) and Avionics Full-Duplex Switched Ethernet (for airplane and train) which were specified over 20 years ago and used since then in airplanes and trains manufacturing and testing and is the extract same concept of etherloop but fully open and generic and accessible to everybody
The primary difference maybe the connector and the Power Over Ethernet specification used which is specific to Tesla I presume (they were open with the NACS connector so maybe they do the same), but those concepts exist since more than 20 years, and the revolution is to apply them to the car industry, things that cars manufacturers were lazy to do for the past 20 years when it has been applied to airplanes and trains already
Finally the name etherloop refer to an « Ethernet » + loop, and the hardest part is to address the high availability and situations of closed loop which can cause packets to loop « forever » but there is already Spanning Tree Protocol (including Rapid STP ) but convergence is at 5 to 10 seconds actually depending to the settings on a generic network (like at home or datacenter/IT environment) so the hard part is to have failure detection and recovery really fast, thing which can be truly revolutionary on an Ethernet network
A great link with some explanations www.militaryaerospace.com/commercial-aerospace/article/14230980/ethernet-commercial-airlines
Including the usage of ARINC reference (airplane standard) fiber even (when power distribution is not necessary)
Wikipedia definition of etherloop
"etherloop" have been developed, including use for automotive intra-vehicle communication in the 2020s, where a gigabit Ethernet physical network has been used with a proprietary time-sliced, network protocol for near real-time, redundant control and feedback of motor vehicle subsystems."
I want to see Giga Mexico being built to manufacture unboxed $25k EV boxes with all the latest and greatest Tesla tech.
It expect to see that, or something very close. The lateness of Cybertruck and the long wait for the 25K car seems to be partly attributable to Tesla reinventing how a vehicle is wired and thus manufactured. It's not about two vehicles, it's about transforming how any vehicle is made.
@@donjones4719I keep thinking it’s also the difficulties they have run into on the 4680 battery. They really advertised the plan to get vehicle cost out through internal manufacturing and a 60% (~) reduction in cost from that (as I recall the battery presentation)
It's another "Industrial Ethernet", the "Loop" reminds me of EtherCat which - from what I've heard - is state of the art. They could have adopted TSN (time sensitive networking) and try to push it but seems like tesla tries avoiding industrial standards whenever possible. A really risky move, if this architecture has just a minor design flaw this could lead to many controller/networking failures and thus crashes.
19:35
"Universal controller design".
.
This has more implications beyond the "front end" supply chain.
Parts inventory.
It's a huge reduction in parts warehouse inventory/storage (ask Farzad!).
Also, Service.
Speaking as a Field Service Rep in another industry, vehicle space is limited.
Any time I can carry 1 common part for multiple devices it's a win.
.
Then there's faultfinding.
If you have that "odd" intermittent, elusive fault, or simply don't have a replacement to hand, you could swap 2 controllers and see if the fault moves with one of the units.
Amen!!!
It’s also a big cluster risk. Anything not available and nothing gets produced. Any undiscovered systematic defect: have fun RMAing that one.
There’s a reason high-reliability safety systems are designed pretty much the same across industries.
Want to do market segmentation and have a low-end and high-end trim: congrats you now have to equip the high-end ECU on every car. Yeah you can try and upsell this with subscriptions and what not but going low-end is _hard_. And doing that on a single model is harder.
It’s good but it’s not as one sided as it might look like at first.
"Any endpoint to any other endpoint" and "maximally software defined" does sound like a security nightmare if you're asking me... Potentially getting access to critical systems such as the brakes by hacking into the internet-connected infotainment system suddenly sounds like a very real thread.
that's a cybertruck, and needs to be like in cyberpunk. In Cyberpunk 2077 you can hack cars.
@@Gameplayer55055And while it’s a great game to play, I’d like to remain in control of my real car at all times…
@@underlyingglitch926 I bet they won't stop on cars and will make internet connected toasters, vacuums, toilets...
It's really a security nightmare
Now I'm starting to understand what Elon meant with: "don't follow meaningless standards!"
Oddly, this is all based on a 2020 standard, sponsored by Ford and Audi
Stockton Rush said the same thing.
@@Dularr maybe bad marketing from Ford and Audi kkkk
@@marceloniendicker8335 more likely they are slow and unwilling to change
Isn't that what The Ocean gate guy said to
Tesla's CAN systems actually already use location-defined general purpose controllers to an extent. It's part of what they've been doing since the beginning.
Excellent educational session, thank you. One of the images shows a highly significant change essential to Ethernet is replacing legacy individual wires with ribbon cables. 48V from 12V makes this significant improvement possible. While ribbon cables are not new, their use in automotive is. Improvements include, automated manufacturing, Electromagnetic Compatibility/Immunity (EMC/EMI), wire-to-wire coupling. Providing total control of which wire is next to which wire, eliminating splices, twisting wires, the list goes on and on. Not to mention sharing controllers between vehicle models, without having to engineer new connectors, simply cut longer or shorter ribbon cables. Thanks
Thanks for the comment and the insight! Much appreciated!
Isn't noise cancelling an issue without twisted pair going on like in Ethernet cables?
Power to motors would still have to carry lots of current.
@@UA-cam_username. The way PATA and SCSI handled it was grounding every second wire and limiting cable length.
I have been waiting for someone to expound on the implications of the ether loop. I set up one of the first industrial Ethernet networks in Canada in the early 80’s. Glad to see someone like Musk push this technology to its logical conclusion in autos.
The real issue is that lots of those cross car systems are safety critical. Braking system, lights, around car sensor packages for the various levels of self-driving and so on. Having a single approved and well tested system handling each one that you can pretty much get off the shelf is very convenient.
Ensuring something like the ABS system under emergency braking is acting in a coordinated way at the millisecond timescales required on all 4 corners of the car is much easier with a single module handling it all.
That's where the EtherCAT standard helps. Each device modifies the Ethernet packet as it travels both ways around a ring. The result is a high bandwidth low latency communications with redundancy.
Convenient or complacent? This is why traditional OEMs are failing behind.
@@GregHassler They really aren't.
ABS master control will still be a single module, but it will source and send data to each brake over the network in its time slice. If/when they switch to the Brembo Sensify system this network can eliminate the hydraulic system completely (or partially, there's options there too.)
It will be interesting to see whether Tesla tries to put everything on one bus, and whether regulators let them. You can build priority schemes that give you realtime-ish performance when everything is working, but if your headlights malfunction and start spewing garbage onto the bus they're still going to take out your brakes.
CAN devices do not all have to be on the same bus. There can be multiple bus with a controller bridging communication. In general, only those devices that need to talk to each other will be on the same bus. You don't want a shorted bus taking out everything. Also, traditional vehicles do not have a pile of different controllers in different locations. They use a few large controllers with lots and lots of thick gauge wires going from those controllers to the various different devices / sensors. But this has more to do with fusing then with the communication bus. Remember, traditional vehicles have mechanical fuses mostly located in one place. Reductions in wiring will require distribution of fuses which in turn requires use of eFuses (electronic fuse) in place of regular fuses. These eFuses will each require a controller and all controllers will have to be connected together via a communication bus. But this allows you to replace a large number of cables with a single 48V power line. So great, but it has nothing to do with the communication bus used. It does require a lot of work on the user interface to allow for the management of the eFuses. No more going to the fuse box when something stops working. The UI has to report the error, reset the fuse either manually or automatically, etc. Lots of design work required but the hardware is actually reasonably simple.
One thing overlooked is that CANbus has well documented reliability and behaviour. It is an industry wide and ratified format that is extensively tested and used, and interoperable between many manufacturers. So the hardware is reliable, the software is reliable, the parts are cheap, the functionality mature, the knowledge is wide. Things you absolutely need for something dangerous hurtling down the road. So Tesla are dumping that for one that they made up themselves to save some wires. At the very least this should be concerning since it makes parts harder and more expensive to find but it could be worse than that depending on safety and failure is handled.
eah, no one uses Gigabit Ethernnet, especially not in industrial applications.../s
Convention and interoperability is great for all the reasons you mentioned, but conventions eventually become outdated and industrial ecosystems can become so entrenched in those conventions that it is assumed that there isn't a better way. Yeah, it's more expensive when you have to replace something that is custom and hard for the aftermarket to replicate. But change is necessary and the bandaid must be ripped off eventually.
There are special Ethernet standards that using a single twisted pair for collision free networking with multidrop. They are designed to replace the likes of CANbus in exactly this use case. This is what Tesla will be using. The advantage is that every software engineer and his dog is familiar with Ethernet. CANbus not so much. Basically Ethernet is taking over all network protocols get used to it.
Yea, except this is terrible because it's basically token ring with serial device sharing; if this were ethernet with host voting, it'd be fine. It's going to be dangerous
Kiss goodbye to DIY repairs and independent mechanics! 😢
That is the point, and unfortunately all manufacturers prefer this so they can milk you for more $$$
i don't see many more issues. you mean mechanics with a wrench of hackers? because you need latter nowadays anyway. can is not much of a better. it's still network. controllers are still closed
One controller failure, all systems failure in that corner, no thanks.
@@estebanamador7601 Unlikely, probably have multiple backups
This is cool and all until your are paying triple the price for what was once just a head light controller that now is also also for your windshield turning signal abs tcs
I was very interested on the Tesla 48V system and how they 'solved the CAN-Bus'. It came as a total surprise having such an explanation from you as I did not expect. A good starter for a very important subject. Going down to all details will require much more time and explanations. Up to now there is very little.
😁 Yes, I didn't expect it either, lol. I'm sure there are people better positioned to explain it, but I wasn't satisfied with any of the video I saw. And totally! There's a lot more to it than I showed here.
For anyone that's worked on networks it's a "Welcome to the 21st century" moment.
Good video, but they wouldn't pass uncompressed video from even a single camera over Etherloop as even a basic 2MP camera generates over 1.4Gbps at just 30fps. Now they could be using Ethernet cameras (which perform H.264/5 compression at the camera), but that introduces at least 2 frames of latency which wouldn't be acceptable for self driving, so my guess is that they'll continue to use something like GMSL for the video feed to the FSD computer and then perhaps forward a compressed stream of the rear and sideview cameras over the Etherloop bus so that it can be consumed by services such as the primary display.
God I love these comments. Super smart bunch today. Lots of great insights
Currently automotive cameras use "serdes" , like FPD-link or GMSL . Automotive Ethernet is currently being standardized to support also speeds up to 25Gbit/s. And in future even more .Currently video data is not compressed because lossless compression does not work well with certain safety measures. Typical speeds are currently 3-8 GBit/s .
Slogan of the Navy CB’s “The difficult we do immediately, the impossible a little longer.”
Thank you. I knew it sounded familiar. Like several of the phrases Elon likes to use, he didn't come up with them, he's quoting phrases long used by engineers, e.g. "the best part is no part." He doesn't claim originality but his high profile introduces the phrases to non-engineers.
this is also the lyrics to Billie Holiday's 'Crazy He Calls Me' "The difficult I'll do right now, The impossible will take a little while"
While I like this idea, I can't help but think this will make repairs even more hostile to perform. Fender bending a Tesla is already a 10K price tag; at some point insurance is going to straight up say it costs too much and won't insure them.
Both the medical and insurance fields need to be thrown away and overhauled anyways. Both are scams, and Both are money rackets designed to steal from their customers.
it will also make cars impossible to service by third parties or owner....
It's actually easier to service than an ICE vehicle
@@thelimitingfactoreasier for the Tesla tech with proprietary software to access the information and program the module. Already demonstrated by Kyle boostedboiz, rich rebuilds, and John Deere’s right to repair lawsuits. Every manufacturer has this to an extent already like fords ids requiring $600 subscription plus the $1,000 gateway module.
Bs
As someone who actually does diagnosis on these systems. In my opinion, its easier.
This does seem to reduce the amount of redundant systems and simplify the complexity. You could probably get on the network with a diagnostic device and ping all the components to figure out what's wrong....
Please remember that Tesla is just another car manufacturer. Ignore any and all information that suggests otherwise.
🤣💯