[00:00.000 --> 00:06.880]  Automotive Ethernet. Who uses Automotive Ethernet? Why use Automotive Ethernet? And some technologies
[00:06.880 --> 00:13.740]  to know. Who am I? Xavier D. Johnson, otherwise known as Infinite on Twitter. Born and raised
[00:13.740 --> 00:20.820]  in the Motown. Hacking around since about 12. First mentor for Team 94. Techno J's.
[00:20.820 --> 00:27.060]  Organizer of DC313. Director for MySecDetroit. And I host a show on YouTube called How the
[00:27.060 --> 00:35.260]  Guy Hacked. Enough about me. Let's dig into what exactly is Automotive Ethernet. So electronics
[00:35.260 --> 00:41.180]  in a car. They're split up into these things called domains. Powertrain domain. Body and
[00:41.180 --> 00:47.760]  comfort domain. The human machine interface. Driver assistance. Chassis. These things do
[00:47.760 --> 00:52.600]  anything from control steering and braking all the way to controlling your radios and
[00:52.600 --> 00:59.500]  your windows and your seating. As well as allowing humans to be able to interface with
[00:59.500 --> 01:08.820]  controls via interfaces. Things that actually control the machine. Automotive Ethernet is
[01:08.980 --> 01:15.180]  a physical network that is used to connect components within a car using wires. So why
[01:15.180 --> 01:24.240]  was Ethernet not used in vehicles before now? Well, Ethernet didn't meet the OEM requirements
[01:24.240 --> 01:32.140]  for the automotive market. Basically 100 megabits per second and above Ethernet has too much radio
[01:32.140 --> 01:41.300]  frequency noise. Too much alien noise on the wire from other devices inside of the car. So
[01:41.300 --> 01:49.540]  Ethernet cannot guarantee low latency due to the low microsecond range that is required by
[01:49.540 --> 01:57.400]  vehicles. And this was a hard requirement to replace any communication that needs fast reaction
[01:57.400 --> 02:05.020]  times. Also, there was no way for Ethernet to be able to do time syncing between devices and
[02:05.020 --> 02:12.100]  having multiple devices sample data at the same rate. So what are some of the use cases for
[02:12.100 --> 02:21.340]  automotive Ethernet? Well, the different drivers of automotive Ethernet come from, of course,
[02:21.340 --> 02:29.860]  those domains that we spoke about earlier. The complexity of the components and the wiring
[02:29.860 --> 02:35.480]  harness to a vehicle. The wiring harness is actually the third costliest and third heaviest
[02:35.480 --> 02:41.780]  component in a vehicle. So talking about costs, there's been a joint study between Broadcom and
[02:41.780 --> 02:51.460]  Bosch that estimated using UTP cable to deliver data at a rate of 100 megabits per second along
[02:51.460 --> 02:58.660]  with the smaller and more compact connectors can reduce connectivity costs up to 80% and
[02:58.660 --> 03:08.720]  cabling weight down by 30%. So, you know, when we talk about the data rates via unshielded
[03:08.720 --> 03:14.900]  twisted pair, you know, the electronics in cars are becoming much more complicated, more controllers,
[03:14.900 --> 03:20.020]  more sensors, more interfaces, and all of this stuff requires higher bandwidth. So
[03:21.080 --> 03:26.860]  these are some of the drivers behind the main motivators behind using automotive Ethernet.
[03:26.860 --> 03:32.820]  So technologies that are entering the automotive space include self-driving connected cars,
[03:32.820 --> 03:39.200]  augmented reality, vehicle-to-vehicle communications, and things like self-driving
[03:39.200 --> 03:46.300]  require lasers and radars that can process anything, things much more faster than humans can
[03:46.300 --> 03:53.320]  and more reliably than humans. And we can use these tools and these advancements to be able to do
[03:53.320 --> 04:00.120]  things more efficiently and more effectively on the road doing things like platooning where cars
[04:00.120 --> 04:07.740]  get close to one another so that they can occupy less space on the road and parking very closely
[04:07.740 --> 04:13.920]  in parking spaces. Augmented reality, things like dashboards for the driver to be able to look
[04:13.920 --> 04:18.700]  through the windshield and see things at a distance and be able to understand exactly, you know, what
[04:18.700 --> 04:24.040]  those things are and categorize them and how far exactly they are away, how fast the driver's moving
[04:24.040 --> 04:29.260]  towards it. If there's danger, you know, arrows could appear and let you know exactly how to avoid
[04:29.260 --> 04:37.220]  the danger. And these technologies are considered for passengers as well, right? Connected cars,
[04:37.220 --> 04:42.040]  which we're living through right now with the advancements in cellular and Wi-Fi connectivity,
[04:42.040 --> 04:47.540]  this allows us to be able to communicate and do video streaming as well as remote diagnostics
[04:47.540 --> 04:54.440]  and updating firmware, which usually require access to the internal networks and computers
[04:54.440 --> 05:03.730]  in cars. So vehicle-to-vehicle communications allow cars to be able to speak to one another.
[05:03.960 --> 05:12.630]  The NHTSA estimates that by using VtoV, 79% of target vehicle crashes would be avoided.
[05:12.630 --> 05:19.690]  So we're talking about huge benefits and safety just by allowing us to be able to increase the
[05:19.690 --> 05:24.130]  amount of technology censoring in the vehicles, but we're going to have to have networks that
[05:24.130 --> 05:30.850]  can actually handle that bandwidth and capability. Digging deeper into these technologies, right? So
[05:30.850 --> 05:37.630]  AutoSAR, the Automotive Open System Architecture, One Pair Ethernet, otherwise known as OPEN,
[05:37.630 --> 05:45.530]  Power Over Ethernet or PoE, Energy Efficient Ethernet, EEE, Time Synchronization, as we
[05:45.530 --> 05:51.910]  talked about that being a problem before, AV Bridging, Diagnostics over IP, which is extremely
[05:51.910 --> 05:58.790]  exciting, and Time Triggered Ethernet. So digging into AutoSAR, it's an open,
[05:58.790 --> 06:03.930]  standardized automotive architecture jointly developed by manufacturers and tool developers.
[06:04.490 --> 06:13.190]  TCP, UDP, IP stack that is used in automotive components and is basically the standard that
[06:13.190 --> 06:18.930]  all of the automotive industry came together and decided to agree on versus just
[06:18.930 --> 06:28.130]  fragmenting out and working in silos. Broadcom made a physical chip, a PHY,
[06:28.410 --> 06:34.730]  a standard called Broad R-Reach. This is allowing us to be able to enable longer distance
[06:34.730 --> 06:40.730]  copper Ethernet connectivity at a sustained 100 megabits per second. It's using technology
[06:41.210 --> 06:49.350]  from 1GE copper, including multi-level PAM3 signaling, better encoding, echo cancellers.
[06:49.350 --> 06:56.770]  These allow for bi-directional data flows on a single pair. Due to lower bandwidth,
[06:56.770 --> 07:02.930]  standard met the automotive EMI requirements and Broadcom started marketing this to the automotive
[07:02.930 --> 07:09.290]  world. Power over Ethernet. It's used to further reduce the wiring needed since you can actually
[07:09.290 --> 07:17.990]  power the end devices as well as sending data over that wire at the same time. So you're able to
[07:17.990 --> 07:24.250]  power the device as well as get data over it without the need for having extra wiring to
[07:24.250 --> 07:32.270]  power the device. Energy efficient Ethernet. So when you're dealing with cars, not all of
[07:32.270 --> 07:38.070]  the electrical components turn off when the engine is turned off. So with that being said,
[07:38.070 --> 07:45.110]  you have a drain on the battery and to minimize that, energy efficient Ethernet turns off the
[07:45.110 --> 07:49.950]  network when it's not in use. So the components that don't need to be powered on stay off until
[07:49.950 --> 07:58.150]  the engine turns on. This is to help with minimizing power consumption.
[07:59.370 --> 08:04.350]  And so time synchronization. We talked about this. Time is a must. It needs to be synchronized
[08:04.350 --> 08:15.910]  between all the nodes in the car. So the IEEE 802.1AS, timing and synchronization for time
[08:15.910 --> 08:22.730]  sensitive applications and bridge local area networks is the standard to actually synchronize
[08:22.730 --> 08:29.590]  timing. This uses a profile and introduces simpler, faster methods for choosing a master clock.
[08:30.690 --> 08:36.470]  Time triggered Ethernet. Many controls in the car require communication latency in a single
[08:36.470 --> 08:43.450]  microsecond range. Literally. So controllers can get sensor readings to control functions
[08:43.450 --> 08:47.930]  of vehicles. And if we're talking about self-driving cars, we want to make sure that
[08:47.930 --> 08:53.670]  the sensors have communication latency that is extremely low. So time triggered Ethernet
[08:53.670 --> 08:59.710]  simplifies the design of this, creates fault tolerance and high availability. The safety and
[08:59.710 --> 09:06.670]  redundancy are maintained upstream at the network level without any need for the application to be
[09:06.670 --> 09:15.290]  involved. So for AV bridging, 802.1QAT, also known as stream reservation, is a simple protocol
[09:15.290 --> 09:22.670]  to notify the various network elements in a path to reserve the resources needed to supply a
[09:22.670 --> 09:31.490]  particular stream. And 801.1QAV, the queuing and forwarding for AV bridges, defines rules to ensure
[09:31.490 --> 09:37.930]  that an AV stream will pass through the networks within the delayed specified time in the reservation.
[09:41.010 --> 09:49.370]  ISO 13400 is a standard that is adopted by the automotive industry to both read out diagnostics
[09:49.370 --> 09:56.250]  from the computers in the car and update firmware in a car. So this covers our diagnostics over IP
[09:56.250 --> 10:02.370]  portion. The protocols run over TCP IP and are used both on dedicated diagnostics
[10:02.370 --> 10:06.730]  Ethernet connections as well as over the air system such as GM OnStar.
[10:08.490 --> 10:13.210]  Thank you very much. I hope that you learned a few new things about automotive Ethernet and
[10:13.210 --> 10:17.430]  if you have any questions, please don't hesitate to hit me up on Twitter.
[10:20.270 --> 10:28.870]  All right, Infinite, thank you very much for such a great overview of the automotive Ethernet.
[10:30.350 --> 10:38.450]  Infinite will be available on the Discord channel. There's no real questions for him
[10:38.450 --> 10:44.330]  right now, but if you need to get in touch with him, he will be on the Discord channel, Infinite.
[10:46.050 --> 10:50.330]  So if you do have questions about automotive Ethernet later,
[10:50.330 --> 10:59.670]  please get in touch with him directly. All right, guys, we're getting down to the last talks here
[10:59.670 --> 11:09.790]  and the next talk is going to be about cloud to car communication. And if you guys have ever
[11:09.790 --> 11:17.370]  heard anything about MQTT before, well, don't worry if you haven't because we will talk about
[11:17.370 --> 11:27.470]  it here in about 47 minutes. So the next talk, we're going to be talking about this MQTT standard
[11:27.470 --> 11:33.980]  and how to use it to hack your own car. So looking forward to that with Jamie.
[11:34.760 --> 11:40.960]  All right, so we'll see you back here in about 47 minutes with the next talk.