[00:02.400 --> 00:09.960]  Okay, we're live. Thank you, John, for the lead off. And welcome back, everyone, to another
[00:09.960 --> 00:17.560]  Car Hacking 101 talk for DEF CON Safe Mode 2020's Car Hacking Village. My name is Kamal,
[00:17.560 --> 00:22.000]  and in this lecture, I'm going to be talking about in-vehicle networks. I'm also doing a talk
[00:22.000 --> 00:29.440]  for Bluetooth in the same kind of vein of Car Hacking 101 talks. So if you've already seen
[00:29.440 --> 00:34.900]  or heard my introduction, I apologize profusely, but I have to give it again for those of you that
[00:34.900 --> 00:40.920]  might not be interested in Bluetooth or just coming to this one first. So a very short speaker
[00:40.920 --> 00:45.540]  introduction, right? As I mentioned before, my name is Kamal, Kamal Ghali. I'm an automotive
[00:45.540 --> 00:50.820]  cybersecurity technology architect at White Motion. White Motion is a small automotive
[00:50.820 --> 00:56.380]  cybersecurity-focused company. We're a subsidiary of Morelli. It's a much larger Italian automotive
[00:56.380 --> 01:03.800]  tier one supplier. It's actually the combination of the older Magneti Morelli, Italian automotive
[01:03.800 --> 01:11.200]  tier one, and a Japanese tier one called CalSonic Kansei. They actually merged a couple of years
[01:11.200 --> 01:17.420]  ago, and White Motion was at the time owned by CalSonic Kansei, and now we are a full subsidiary
[01:17.420 --> 01:25.040]  of Morelli Corporation. So I myself am based in Tokyo. I'm a trilingual car hacking enthusiast,
[01:25.440 --> 01:29.700]  because for me, this is very much more than just a job. It is more than just a profession. It's
[01:29.700 --> 01:35.540]  something I enjoy, and I enjoy doing a lot of volunteer activities in the industry as well.
[01:35.540 --> 01:40.440]  For example, this Car Hacking 101 talk is not something anyone is paying me for. No one is,
[01:40.440 --> 01:44.160]  you know, my boss didn't tell me to go do this. This is entirely because I enjoy what I do,
[01:44.160 --> 01:47.760]  and I think a lot of people would enjoy doing what I do, and I want to make sure that the
[01:47.760 --> 01:54.140]  knowledge is easily accessible for people that want to join the industry. So along those lines,
[01:54.140 --> 02:00.700]  I am an ex-admin of ASRG Detroit. I got involved in Automotive Security Research Group while I was
[02:00.700 --> 02:05.640]  living in Michigan, helping out with things like working on collaboration between industry
[02:05.640 --> 02:10.540]  and academia, and I'm the founder of the Automotive Security Research Group Japan.
[02:10.540 --> 02:16.360]  For any of you that aren't aware, Automotive Security Research Group is an organization
[02:16.360 --> 02:22.000]  dedicated to sharing information about automotive cybersecurity, making it more readily available,
[02:22.000 --> 02:28.860]  mainly being driven by the community as opposed to, you know, its own industrial entity, right?
[02:28.860 --> 02:33.740]  So it's a pretty open community, and a lot of, you know, freely available talks, etc. are available
[02:33.740 --> 02:38.400]  online for anyone that wants to learn about automotive security. But anyway, I've gone on a
[02:38.400 --> 02:43.920]  bit of a rant there, but I like to consider myself a jack of some trades, a master of none.
[02:43.920 --> 02:48.080]  My recent areas of interest are Bluetooth, USB, radio frequency, digital forensics,
[02:48.080 --> 02:51.240]  and I have some interesting hobbies of mine that I have listed down below.
[02:51.240 --> 02:55.620]  But today we're not talking about any of these technologies, we're going to talk about in-vehicle
[02:55.620 --> 03:02.520]  networks. So what is an in-vehicle network? An in-vehicle network is, as you know, I would hope
[03:02.520 --> 03:08.220]  is obvious, it is a network that's used inside a vehicle, right? So it's a networking technology
[03:08.220 --> 03:14.500]  that's used to allow the ECUs inside a vehicle to efficiently and, you know, safely share information
[03:14.500 --> 03:20.400]  between one another. So these in-vehicle network technologies are designed specifically for use
[03:20.400 --> 03:25.700]  in these closed environments where you have, you know, several ECUs inside a vehicle, they need to
[03:25.700 --> 03:30.880]  share sensor information, you know, the results of calculations, calibration information, vehicle
[03:30.880 --> 03:37.000]  status, so on and so forth, with other distributed processing units throughout the vehicle, right?
[03:37.520 --> 03:41.860]  If you consider, you know, very broadly speaking, a network can be anything. It can be
[03:41.860 --> 03:48.040]  Bluetooth as a network, you know, 4G, 5G, those are networks, DSRC is a network, Wi-Fi is a network.
[03:48.040 --> 03:51.940]  But for the purposes of this talk, I'd like to make it clear that I'm talking about
[03:52.420 --> 03:57.460]  physical networks, I'm talking about guided medium networks, right? For those of you with a background
[03:57.460 --> 04:02.480]  in networking, you might know the difference between a guided and an unguided medium for your
[04:02.480 --> 04:08.820]  network is that guided means it's got copper or fiber in place that actually, well, guides the
[04:08.820 --> 04:14.260]  transmission of information along a specified path, right? It's not radiated like it is in most
[04:14.260 --> 04:19.800]  wireless communications, right? So we're going to be talking about those kind of physical wire
[04:19.800 --> 04:24.380]  communications, be they copper-based or fiber-based, and how they're used in a vehicle. I'm going to go
[04:24.380 --> 04:29.320]  over some of the different types of inter-vehicle networks that are found in the industry today.
[04:29.320 --> 04:32.940]  I'm going to talk a little bit about each one of them, how they're used, what their strengths are,
[04:32.940 --> 04:37.320]  what their weaknesses are, etc, right? Strengths and weaknesses are a big part of inter-vehicle
[04:37.320 --> 04:44.920]  networks because, as you can see, I have listed here, they are selected based on what role they
[04:44.920 --> 04:50.500]  fill for a given application, right? There's no one-size-fits-all, best-in-vehicle-network
[04:50.500 --> 04:54.520]  solution that can do everything. There are different solutions, different technologies
[04:54.520 --> 04:59.440]  available that manufacturers selectively include in their vehicles based on where
[04:59.440 --> 05:03.340]  they're most appropriate, right? You'll see how this works out in just a second.
[05:03.980 --> 05:10.820]  So, in the context, excuse me, I was drinking some pineapple juice and some of it's got stuck
[05:10.820 --> 05:16.220]  in my throat, which is probably not a great way to get ready for giving a recorded talk.
[05:16.240 --> 05:22.780]  But in the context of a self-driving or autonomous vehicle, this is a fairly common, you know,
[05:22.780 --> 05:28.260]  logical setup within a vehicle, right? In this diagram, we have a couple of ECUs alongside a
[05:28.260 --> 05:33.020]  sensor and some actuators, right? The sensor in this case could be, you know, any number of things.
[05:33.020 --> 05:39.420]  It could be a camera, it could be an accelerometer, a CO2 sensor, a LiDAR sensor, user input sensor,
[05:39.420 --> 05:44.540]  radio, you know, it could be almost anything, right? The sensor is, at this point, in this logical
[05:44.540 --> 05:50.920]  diagram, we're just treating this sensor as a source of raw information, right? The data that
[05:50.920 --> 05:56.940]  this device generates needs to be processed. This is, the sensor isn't, is intaking raw information
[05:56.940 --> 06:01.440]  and that information needs to be processed, it needs to be interpreted by a processing unit so
[06:01.440 --> 06:08.300]  that the vehicle as a whole can kind of understand what that raw data means about the vehicle's
[06:08.300 --> 06:13.980]  environment, what it has to do next, so on and so forth, right? So based on what kind of sensor it is,
[06:13.980 --> 06:18.540]  you know, what kind of data it's going to be producing and how much of that data it's producing
[06:18.540 --> 06:23.720]  is going to be different. And a different in-vehicle network technology might be chosen
[06:23.720 --> 06:28.900]  to carry that data from where it's generated to where it gets processed here in the ECU, right?
[06:28.900 --> 06:33.780]  So along this diagram, if we take it, you know, kind of from start to finish, this sensor here is
[06:33.780 --> 06:37.680]  going to generate some raw data, right? This is going to be a camera that's facing, you know,
[06:37.680 --> 06:42.020]  towards the front of the vehicle. It could be, you know, just assume it's a camera, right? And it takes
[06:42.020 --> 06:47.040]  that image data and it sends it to ECU 1 for processing, right? Because the processing power
[06:47.040 --> 06:53.200]  is going to be contained here on the ECU's microcontroller, right? So this line here is
[06:53.200 --> 06:57.700]  meant to represent an in-vehicle network, right? Because something needs to be in place for this
[06:57.700 --> 07:03.180]  sensor to be able to send that data to ECU number 1 over here, right? Once ECU 1 has the raw data,
[07:03.180 --> 07:08.540]  it's going to be able to do some calculations, you know, interpret that data, understand what
[07:08.540 --> 07:13.140]  that data means, right? Is there, you know, a traffic sign, you know, a stop sign in front of us,
[07:13.280 --> 07:18.000]  a red stoplight, you know, how self-driving cars should stop for stoplights, so on and so forth.
[07:18.000 --> 07:21.640]  It's going to make those decisions and, you know, understand the raw data it received,
[07:21.640 --> 07:27.100]  and then it's going to pass the results of those calculations on to another ECU, right? And then
[07:27.100 --> 07:31.800]  maybe this ECU is in charge of something else, right? Here I have, you know, two very broadly
[07:31.800 --> 07:39.900]  defined actuators, right? An actuator in this scenario being any device that upon receiving,
[07:39.900 --> 07:49.000]  you know, an input from a processing unit converts that input into a physical real-world stimulus,
[07:49.000 --> 07:53.880]  right? A thing that happens, right? This is what I mean when I'm talking about an actuator.
[07:56.140 --> 08:00.600]  So each of these lines here is meant to represent an in-vehicle network, and I have them all
[08:00.600 --> 08:04.200]  colored the same way because at this stage, you know, I haven't talked about the different types
[08:04.200 --> 08:08.880]  of in-vehicle networks, but each one of these is likely going to be a different type of in-vehicle
[08:08.880 --> 08:14.300]  network technology because the amount of data being processed from here to here might be
[08:14.300 --> 08:17.640]  different with the amount of data processed between these two, and it might be different
[08:17.640 --> 08:22.520]  from the amount of data processed between, you know, ECU 2 and the actuators, right? So some
[08:22.520 --> 08:26.440]  things to take into consideration when considering which in-vehicle network technology to choose
[08:26.900 --> 08:32.400]  would be things like safety and robustness requirements, distance from the ECU to the
[08:32.400 --> 08:37.120]  actual sensor, right? Bandwidth necessities, how much data is being processed, what kind of data
[08:37.120 --> 08:41.740]  it is, how, you know, how fast it needs to be processed. All of these are metrics you want to
[08:41.740 --> 08:49.080]  take into consideration when picking the appropriate in-vehicle network to use, right? So going on,
[08:49.080 --> 08:53.440]  we're going to talk a little bit about network topologies and how they relate to
[08:53.440 --> 08:57.840]  in-vehicle networks. So I have here, I ripped this image from the internet somewhere. I have
[08:57.840 --> 09:02.220]  the source listed down here. This is a look at a couple of common network topologies, right?
[09:02.220 --> 09:06.320]  You have your mesh network, you have your fully connected network, which is also called a full
[09:06.320 --> 09:12.140]  mesh network, right? You have star topology, ring, and a common bus topology. These might be pretty
[09:12.140 --> 09:18.580]  familiar to you if you've worked as a systems administrator or you have any, you know, experience
[09:18.580 --> 09:25.260]  as an actual networking engineer, right? Some of these would be familiar and how they relate to
[09:25.260 --> 09:34.380]  in-vehicle networks is that we... where am I going with this? Okay, most of the in-vehicle networks
[09:34.380 --> 09:38.400]  that I'm going to talk about today will use a common bus topology, right? But that doesn't
[09:38.400 --> 09:45.040]  mean that there aren't some that use other topologies instead, right? Because in-vehicle
[09:45.040 --> 09:49.960]  networks are designed to be reliable and robust because they are, you know, part of a vehicle
[09:49.960 --> 09:57.280]  ecosystem. A vehicle is a moving object that moves very fast, is very heavy, and has living breathing
[09:57.280 --> 10:04.000]  people inside it. There are a lot of important, you know, safety thresholds that need to be met.
[10:04.000 --> 10:08.980]  There are a lot of standards that, you know, are in place to best guarantee the safety of the
[10:08.980 --> 10:14.780]  passengers and the environment around the vehicle. And so when we talk about things like the networks
[10:14.780 --> 10:18.320]  that we use for transferring this information, it's important to know that they need to be
[10:18.320 --> 10:25.160]  designed with a level of robustness and reliability and safety in mind, right? So with regards to the
[10:25.160 --> 10:31.320]  networks shown here, some of them have strengths and weaknesses that are realized, or I suppose
[10:32.200 --> 10:36.840]  they can be seen in the in-vehicle network technologies that make use of these topologies,
[10:36.840 --> 10:43.400]  right? So say you have a fully connected network. This is a very expensive, very hard to implement
[10:43.400 --> 10:49.300]  type of network, because every single unit in this device is going to have a direct link to
[10:49.300 --> 10:53.920]  every other unit in the network, right? This means you need to have the hardware and infrastructure
[10:53.920 --> 11:02.240]  to connect every unit to every other unit, right? And the positive to this is that, you know,
[11:02.240 --> 11:07.300]  you have incredible redundancy. If any link goes down, it doesn't matter. Every computer has a link
[11:07.300 --> 11:11.760]  to every other computer, or every other processor, right? Every other microcontroller, so on and so
[11:11.760 --> 11:16.440]  forth, whatever it could be, right? So if this ECU here, let's pretend these are ECUs and not
[11:16.440 --> 11:22.360]  desktops, if this ECU wants to communicate with this ECU, but this direct link between them breaks,
[11:22.360 --> 11:27.860]  right? The obvious logical conclusion is then, well, I can still talk to this ECU, but through
[11:27.860 --> 11:32.080]  any number of other paths. I can go from him to him, I can go from him to him, or from him to him,
[11:32.080 --> 11:36.960]  or from him to him. The fully connected network topology offers the most amount of redundancy,
[11:36.960 --> 11:42.360]  right? But the downsides are, like I mentioned earlier, they're expensive, they're sometimes a
[11:42.360 --> 11:48.300]  little bit more complicated to implement, and especially when it comes to cars, the actual
[11:48.300 --> 11:55.000]  physical cable weight is becoming a sort of rising concern for automotive manufacturers, right? The
[11:55.000 --> 12:01.960]  actual weight of the cable harness is not a trivial thing. It's not a trivial part of the vehicle
[12:01.960 --> 12:06.880]  ecosystem, right? The actual designing of a vehicle needs to take into account how much cabling is
[12:06.880 --> 12:11.380]  going to be in there, because you can have, you know, I don't, I'm not, you know, an expert on how
[12:11.380 --> 12:17.400]  much cable goes into cars, but I'd say it can amount to quite a bit of weight, right? A couple,
[12:17.400 --> 12:23.020]  maybe tens of kilograms, I would assume, right? This is just an educated guess, right? But I'm
[12:23.020 --> 12:28.000]  sure someone more familiar with that actual metric would be able to give you a more accurate
[12:28.640 --> 12:33.280]  number there. But those are the pros and cons of something like a full connected,
[12:33.280 --> 12:40.200]  fully connected network topology. A mesh network is kind of like a not full connected network
[12:40.200 --> 12:44.800]  topology. It's kind of like an in-between, right? You'll have different devices here with different
[12:44.800 --> 12:51.780]  connections to some, if not all, of the other processors in the network, right? This is good
[12:51.780 --> 12:56.220]  because you'll have some level of redundancy where if, say, this line goes down, right, then you can
[12:56.220 --> 13:02.500]  still reach this processor here by going, okay, we'll go here, here, and then here, right? So you have
[13:02.500 --> 13:07.640]  different paths that your data can take if you need to send data from one processor to another
[13:07.640 --> 13:13.020]  on the network. A common bus topology, this is where all of the ECUs, in this case, will be
[13:13.020 --> 13:19.120]  connected to a single common bus that they can all send or receive data from at the same time.
[13:19.120 --> 13:24.340]  This is how CAN bus works. I'll talk about that in the next couple of slides, as it's the most
[13:24.340 --> 13:30.820]  common in-vehicle network in the automotive industry currently. But this is a pretty common
[13:32.280 --> 13:36.660]  implementation because of how easy it is, right? All of the nodes are just
[13:36.660 --> 13:41.360]  connected to one network, and there isn't any kind of routing protocol you have to implement,
[13:41.360 --> 13:45.600]  especially when it comes to CAN, right? It's very simple, it's easy to get set up, and it works
[13:45.600 --> 13:49.980]  pretty well. But one of the downsides, and it's cheap, by the way, but one of the downsides is
[13:49.980 --> 13:55.140]  that this common bus then becomes a single point of failure. So maybe, you know, you wouldn't use
[13:55.140 --> 13:59.700]  something like this in a very high, a very critically important system, right? Especially
[13:59.700 --> 14:03.460]  when we're talking about things like government systems or military systems, you're more likely
[14:03.460 --> 14:08.160]  to see something like this because they are prioritizing, you know, in the moment operational
[14:08.160 --> 14:12.560]  stability over everything else, whereas for a mass-produced vehicle, right, this is kind of
[14:12.560 --> 14:17.260]  how you want to go, right? It's because it needs to be mass-produced, it's not feasible to make
[14:17.260 --> 14:24.040]  every single car on the road in this, you know, fancy of an architecture. Moving on, ring topology
[14:24.040 --> 14:28.320]  is pretty rare, but I believe that the most protocol... I'm talking about rare as in within
[14:28.320 --> 14:33.820]  the vehicle or context, right? Within the most protocol, I believe a ring topology is used,
[14:33.820 --> 14:37.500]  although there are different versions of most and some of them might be able to be used in other
[14:37.500 --> 14:42.400]  versions. Most isn't a technology I've personally worked with a lot because it is pretty rare, but
[14:42.400 --> 14:46.620]  I will touch on it briefly in this presentation. And then you have a star network topology. This
[14:46.620 --> 14:53.220]  is one of the more common topologies, and especially when it comes to discussing technologies
[14:53.220 --> 14:58.360]  like automotive ethernet and, you know, trying to run TCP IP inside cars, right? Those are
[14:58.360 --> 15:04.120]  point-to-point protocols, and for that, a star topology makes a lot of sense. It's a very happy
[15:04.120 --> 15:08.260]  medium, you know, it doesn't have an excessive amount of cabling and it doesn't have...
[15:10.080 --> 15:14.260]  if one of these links goes down, then the rest of the network is usually protected,
[15:14.260 --> 15:18.940]  but you do have to rely on something like a switch or something in the middle to handle
[15:18.940 --> 15:23.860]  forwarding of communication between the different ECUs, right? But it's kind of seen as a happy
[15:23.860 --> 15:30.140]  medium network topology, right? But anyway, enough about topologies, let's start talking about
[15:30.140 --> 15:37.180]  individual in-vehicle networks. So CAN bus is kind of the main character of the in-vehicle network
[15:37.180 --> 15:43.020]  technology world, right? CAN stands for controller area network. It is the most commonly used in-vehicle
[15:43.020 --> 15:51.020]  network today by far, right? It is more or less standardized and mandated on most vehicles in the
[15:51.020 --> 15:57.240]  United States and Europe for diagnostic purposes. It was developed by Robert Bosch in 1991,
[15:57.240 --> 16:04.360]  is when the 2.0 standard came out, right? The most common nodes you'll find in the market today are
[16:04.360 --> 16:12.380]  actually 2.0b standard CAN bus nodes, and the 2.0b distinction is that they allow for the
[16:12.380 --> 16:17.260]  use of 29-bit arbitration identifiers. Arbitration is the process by which
[16:17.260 --> 16:24.820]  CAN messages have their priority established, and this is the process by which CAN bus actually
[16:24.820 --> 16:30.300]  handles collisions, right? Collisions are detected and then resolved instantaneously,
[16:30.300 --> 16:35.980]  almost instantaneously, through the use of arbitration IDs. I don't think we're going to
[16:35.980 --> 16:40.180]  talk too much about the actual arbitration process today because that's slightly more in-depth for
[16:40.180 --> 16:47.860]  CAN bus, but this is how CAN bus is addressing, is with arbitration IDs. But I'll just put this
[16:47.860 --> 16:53.560]  out here now. CAN bus runs in a bus architecture, and it's a multi-master serial communication. So
[16:53.560 --> 16:58.880]  anyone can send a message, and the arbitration identifier isn't really meant as a source address
[16:58.880 --> 17:05.180]  or a destination address. It just identifies what kind of data is in this packet, right? So if you
[17:05.180 --> 17:12.260]  slapped a sticker to a car saying, you know, this car has oranges in it, right? That's kind of what that
[17:12.260 --> 17:18.380]  does. Saying this truck has oranges in it doesn't mean, you know, it's specific oranges for one
[17:18.380 --> 17:23.960]  person. There's just oranges, and anyone that wants an orange can stop this truck and get an orange.
[17:23.960 --> 17:29.620]  That's a horrible example, but hopefully that'll get across the idea of
[17:29.620 --> 17:36.020]  what an arbitration ID does in a CAN frame, right? And then, you know, back to the CAN frames
[17:36.020 --> 17:42.320]  themselves. Each CAN bus frame in Classical CAN can hold up to eight bytes of data, right?
[17:43.200 --> 17:49.720]  So there are a couple different kinds of CANs. The main, most common CAN bus is high-speed CAN,
[17:49.720 --> 17:54.920]  also called a dual-wire CAN. And this is important because there's a single-wire CAN that also exists,
[17:54.920 --> 17:59.480]  but dual-wire CAN is the most common one. It uses differential signaling and commonly employs
[17:59.480 --> 18:05.740]  twisted pair cabling to include, to add some EMI resistance to it, right? I mentioned that
[18:05.740 --> 18:10.740]  in-vehicle networks need to be reliable, they need to be robust, and this is because a vehicle is a
[18:10.740 --> 18:15.900]  pretty noisy environment. If you're not familiar with what EMI is, right, this EMI here, it's
[18:15.900 --> 18:21.980]  electromagnetic interference. This is when things like power supplies or radios or microwaves or
[18:21.980 --> 18:28.540]  anything that's giving off, you know, radio waves, those radio waves can have on a physical,
[18:28.540 --> 18:33.720]  you know, physics electronics level, they can actually corrupt some of the data being carried
[18:33.720 --> 18:41.640]  by a guided medium if that guided medium isn't properly shielded, right? So this twisted pair
[18:41.640 --> 18:46.600]  cabling is also there to help that because all... well, the way twisted pair cabling works, I'll
[18:46.600 --> 18:50.980]  explain that in a second. I have a slide where I like to go a little bit more in depth into that.
[18:50.980 --> 18:57.020]  But the differential signaling and the twisted pair cabling work together to help mitigate EMI
[18:57.020 --> 19:01.920]  impact, right? Speeds are theoretically up to one megabit per second, although in practice you're
[19:01.920 --> 19:08.340]  more likely to find 125 kilobits per second, 250 kilobits per second, and 500 kilobits per second
[19:08.340 --> 19:14.960]  speeds in most cars, right? One megabit speeds are heavily restricted by cable length because at a
[19:14.960 --> 19:20.200]  certain length of cable it's no longer practical to transmit that fast, and it's just usually a
[19:20.200 --> 19:25.180]  better idea to stick with 500 kilobits. It's more reliable, right? Just take my word for it.
[19:25.540 --> 19:30.340]  This is a quick look at what a CAN bus actually looks like from the physical perspective.
[19:31.040 --> 19:36.080]  CAN buses are usually terminated with 120 ohms on both ends, right? This is a high-speed CAN bus,
[19:36.080 --> 19:42.140]  by the way. And then on each end, each node will have its own CAN transceiver that is connected
[19:42.140 --> 19:48.420]  to a CAN low line and a CAN high line, right? So CAN bus is technically a dual-wire system when
[19:48.420 --> 19:55.240]  we're talking about high-speed CAN. CAN, right? And these are intertwined like this. This is the
[19:55.240 --> 20:00.480]  twisted pair that I was talking about, right? So you can see that there's a high voltage CAN line
[20:00.480 --> 20:05.460]  and a low voltage CAN line, and the difference between these two CAN lines is what is read when
[20:05.760 --> 20:12.440]  a logic is being registered. That's the differential signaling. Excuse me, pineapple juice is starting
[20:12.440 --> 20:17.260]  to make me burp a little bit. But anyway, back to differential signaling, as I was mentioning.
[20:17.260 --> 20:22.300]  So this is a very easy to understand diagram showing how differential signaling works in CAN,
[20:22.300 --> 20:27.680]  right? Here we have a logic graph and an actual physical voltage graph, right? So in high-speed
[20:27.680 --> 20:34.040]  CAN, CAN high and CAN low both rest at around 2.5 volts. This is their kind of resting state,
[20:34.040 --> 20:39.660]  and this is what is read as a recessive logic or a logic zero, right? As counterintuitive as it
[20:39.660 --> 20:45.760]  might seem, logic one in CAN bus is considered recessive and logic zero is considered dominant,
[20:45.760 --> 20:51.120]  so this shows here how the physical bus would look and the logic bus would look
[20:51.120 --> 20:58.000]  if we were to transmit 101 on a CAN bus, right? We'd have the recessive, both lines here at 2.5
[20:58.000 --> 21:04.660]  volts with a zero volt differential. We have dominant for one bit cycle. During that bit
[21:04.660 --> 21:12.740]  cycle time, the CAN high line gets driven to 3.5 volts and the CAN low line gets driven down
[21:12.740 --> 21:19.200]  to 1.5 volts, right? This two volt differential is what is kind of registered. It's what's
[21:19.200 --> 21:26.420]  recognized as a logic zero, right? And then the bus voltages go back down to 2.5 and another
[21:26.420 --> 21:32.800]  recessive logic one is registered. I'm going to talk a little bit about how the twisted pair
[21:32.800 --> 21:38.940]  cabling actually protects against EMI. Let me pull out my pen and PowerPoint. So twisted pair
[21:38.940 --> 21:44.800]  cabling means that the two bus lines, CAN high and CAN low, are intertwined with each other
[21:44.800 --> 21:51.260]  very tightly, right? They aren't just straight across, you know, from one node to another.
[21:51.260 --> 21:57.300]  You can make them that way, but it's better not to because of EMI, right? So the way that works,
[21:57.300 --> 22:04.400]  because those cables are intertwined so tightly, any electromagnetic interference that hits that
[22:04.400 --> 22:11.760]  bus is very likely to hit both CAN high and CAN low, right? So what happens if that
[22:12.400 --> 22:17.220]  kind of scenario occurs? Well, let's draw it out. Say there's an electromagnetic pulse
[22:17.220 --> 22:22.480]  and it's CAN high and CAN low at the same time. It causes a voltage spike that looks
[22:22.480 --> 22:28.560]  kind of like this, right? And then later down here it also comes up like that, right?
[22:29.320 --> 22:33.760]  So that's the CAN high. I should have switched the colors here. I'm kind of a fool,
[22:33.760 --> 22:39.300]  but I didn't do it, so just forgive me, right? The idea is because they're twisted so tightly,
[22:39.300 --> 22:44.440]  we're likely to see the same exact behavior on CAN low, right? Now I'm doing a really shitty
[22:44.440 --> 22:51.080]  job of actually drawing this exactly the same from one to the other, but let's just pretend
[22:51.080 --> 22:56.860]  that these look exactly the same. And then while the bus is in the recessive state, let's say that
[22:56.860 --> 23:05.180]  that interference continues, right? We'll see the same physical impact on both bus lines, right?
[23:05.180 --> 23:11.120]  Now, why is that important, right? Remember how the differential signaling, the differential part
[23:11.120 --> 23:16.380]  means that we're measuring the voltage not based on the raw voltage values of the lines,
[23:16.380 --> 23:21.180]  but by the difference between the voltages. So here, when we're trying to transmit the zero,
[23:21.180 --> 23:26.240]  even though we have this interference, the difference between this point and this point
[23:26.860 --> 23:33.560]  is still two volts, right? So we'll still read a zero. The difference between this point and this
[23:33.560 --> 23:39.360]  point is still two volts, right? Even if this goes negative, right, and we have the same interference
[23:39.360 --> 23:44.680]  here because those wires are twisted together, the difference between this low point here and
[23:44.680 --> 23:49.920]  this low point here is still two volts, right? So the idea is by combining differential signaling
[23:49.920 --> 23:56.940]  with twisted pair, you have this very robust system where even if you bombard this cable,
[23:56.940 --> 24:02.060]  this cabling with electromagnetic radiation, you're still likely to get your message across
[24:02.060 --> 24:07.120]  because of the way Canvas is set up. I think this is very clever and it's one of my favorite things
[24:07.120 --> 24:13.980]  about Canvas. So it's always good to talk about this and just appreciate the quality of engineering
[24:13.980 --> 24:20.360]  put into this technology. But onto less common types of Canvas, there's single wire CAN.
[24:20.360 --> 24:27.100]  It is designated as Society Automotive Engineers Standard J2411. It's CAN for applications with
[24:27.100 --> 24:33.880]  incredibly low bandwidth requirements and not as much robustness requirements. And as the name
[24:33.880 --> 24:39.900]  would suggest, it uses only one wire as opposed to high-speed CAN's dual wire. But on that note,
[24:39.900 --> 24:46.960]  it uses 33 kilobits per second as its maximum data rate, so quite a bit slower than high-speed
[24:46.960 --> 24:52.460]  CAN. And it does not use differential signaling, so it's not as robust or resilient to EMI.
[24:52.840 --> 24:58.800]  And the way the signaling works in single wire CAN is more of a raw voltage value reading,
[24:58.800 --> 25:04.160]  right? So you have a much larger differential between the recessive value and the dominant
[25:04.160 --> 25:09.420]  value. So in single wire CAN, zero volts is considered recessive and four volts is considered
[25:09.700 --> 25:15.660]  a dominant bit, right? Low-speed fault-tolerant CAN, the importance of introducing single wire
[25:15.660 --> 25:21.860]  CAN is that you understand that low-speed fault-tolerant CAN exists as a way to
[25:24.020 --> 25:28.200]  increase the reliability of high-speed CAN, right? Even if you thought high-speed CAN was
[25:28.200 --> 25:33.740]  incredibly reliable and robust from the description I just gave of it, there's still
[25:33.740 --> 25:37.620]  more that can be done. So the way low-speed fault-tolerant CAN works is it does a couple of
[25:37.620 --> 25:43.640]  things. It actually divides the termination on the bus amongst the nodes, right? So if you remember
[25:43.640 --> 25:49.940]  in the... let's just go back a second to the slide where I showed the high-speed CAN bus, right? You
[25:49.940 --> 25:55.660]  have 120 ohms here and 120 ohms here, right? These two 120 ohm resistors in parallel come out to be
[25:55.660 --> 26:01.060]  60 ohms, right? But these become more or less single points of failure. You remove one of these and
[26:01.060 --> 26:07.120]  your bus doesn't work anymore. But in fault-tolerant CAN, right? Low-speed fault-tolerant CAN, you
[26:07.120 --> 26:14.040]  distribute the resistors along the nodes on the bus to actually give the opportunity for the bus
[26:14.040 --> 26:18.180]  to keep working even if one of these nodes gets removed. Even if one of these resistors gets
[26:18.180 --> 26:25.100]  removed, you still have enough resistance on the bus for CAN bus to work properly, right? It also
[26:25.100 --> 26:33.360]  has higher voltage differentials to keep things from getting too... it's just more robustness
[26:33.360 --> 26:38.560]  just in case there's, you know, an especially large amount of EMI interference, right? CAN high gets
[26:38.560 --> 26:43.900]  driven to 5 volts and CAN low gets driven to zero volts in the event of a dominant bit
[26:43.900 --> 26:50.560]  transmission, right? And then another fault-tolerance feature included is that if a wire is damaged,
[26:50.560 --> 26:57.320]  then LSFT can actually switch over to single-wire CAN operation, right? But at the cost of this is
[26:57.320 --> 27:01.680]  that it's, you know, more expensive to implement and the maximum data rate you can get with this
[27:01.680 --> 27:07.380]  kind of implementation is only 125 kilobits per second. And for those reasons, it's not
[27:07.380 --> 27:12.940]  very commonly seen but it does exist and I figured I'd share, you know, knowledge of its existence
[27:12.940 --> 27:19.060]  with you guys today. So just to summarize, where CAN is used, right? Instrument clusters, component
[27:19.060 --> 27:26.180]  control, HVAC, so your car's, you know, climate control, etc. Headlights, brake lights, window status,
[27:26.180 --> 27:32.240]  GPS, diagnostic information, so much more, right? GPS, I mean, like the CAN bus will carry GPS data
[27:32.240 --> 27:38.340]  to share with other parts of the vehicle. Your CAN bus isn't generating GPS data, you're getting that
[27:38.340 --> 27:43.740]  from a satellite, but you already knew that, right? So the point is CAN bus is truly the main character
[27:43.740 --> 27:48.960]  of in-vehicle network technologies. It has the most applications and it is also, I would say,
[27:48.960 --> 27:53.400]  the easiest in-vehicle network technology to begin to learn how to use because there are lots of
[27:53.400 --> 27:58.720]  open source, freely available software tools that you don't even need any hardware, really, to get
[27:58.720 --> 28:03.460]  started to learn how to use a CAN bus, right? They have visualization software available that you can
[28:03.460 --> 28:09.140]  use if you wanted to get started, but that's not what this talk is about. But it's truly, truly
[28:09.140 --> 28:13.440]  the coolest in-vehicle network, I believe, and I don't think it's ever going to be phased out, no
[28:13.440 --> 28:18.000]  matter what anyone tells you. But moving on, the next one we're going to talk about is LIN. LIN
[28:18.000 --> 28:23.180]  stands for local interconnect network. It's kind of like CAN bus's little brother, right? It was
[28:23.180 --> 28:28.080]  actually created after CAN bus, despite having much lower specs from a technical perspective,
[28:28.080 --> 28:33.260]  and it was made to take the place of CAN bus for low bandwidth applications that didn't require
[28:33.260 --> 28:38.640]  the same grade of reliability and robustness that CAN offered, right? Like CAN is pretty
[28:38.640 --> 28:42.840]  cheap as far as in-vehicle network technologies go, but you can always go cheaper, right? So for
[28:42.840 --> 28:49.140]  things like your, you know, very... I'll say some examples later, but very low speed, very low
[28:49.140 --> 28:54.120]  bandwidth applications, LIN bus will usually do the trick, right? And it's also a uniform standard
[28:54.120 --> 29:01.740]  for improved compatibility across manufacturers. It runs on basic... you can actually program a
[29:01.740 --> 29:07.780]  basic UART transceiver to work with LIN, right? It utilizes a bus topology and it's a broadcast
[29:07.780 --> 29:12.600]  serial network with a master-slave architecture, supports up to 16 nodes, right? So it's much
[29:12.600 --> 29:18.380]  simpler in its design compared to CAN, but like I said, it has its place in the industry because
[29:18.380 --> 29:26.460]  sometimes you don't need any more than those very basic capabilities. So LIN also uses a
[29:26.460 --> 29:31.420]  single wire, similar to single wired CAN, and it only communicates at 20 kilobits per second, so
[29:31.420 --> 29:36.640]  it's even slower than single wired CAN, right? But it has guaranteed latency on its transmissions
[29:36.640 --> 29:41.880]  because it utilizes a scheduling table where the master will periodically pull slave nodes for
[29:41.880 --> 29:50.860]  their data, right? And it includes data checks on error detection for basic error handling,
[29:50.860 --> 29:55.540]  right? As you'd expect of something used in automotive, right? It even has that, you know, bare
[29:55.540 --> 30:01.900]  minimum robustness included into it. And like I mentioned just previously, the transmission is
[30:01.900 --> 30:07.600]  done according to a scheduling table, and here I have a quick diagram showing how a transmission
[30:07.600 --> 30:13.200]  will go. So normally you'll have one device on the bus considered the master device, and that
[30:13.200 --> 30:21.120]  master has a schedule according to which it will send out this master header frame, which kind of
[30:21.120 --> 30:28.140]  includes, you know, it'll essentially say like, hey, I want this data, right? According to this
[30:28.140 --> 30:33.500]  identifier. And then the corresponding slave node that has the data associated with the identifier
[30:33.500 --> 30:38.680]  will then fill in the rest of that data, right? The slave node will then begin to transmit from
[30:38.680 --> 30:43.480]  this point, right, after this response space. And on the bus, the way that messages appear
[30:43.480 --> 30:48.860]  is as one lin message, but it's actually half transmitted by the master and half by the slave,
[30:48.860 --> 30:55.320]  right? So this is all part of a automated sequence where the master header, or the,
[30:55.320 --> 31:01.440]  sorry, the master node will send out these requests periodically for data updates,
[31:01.440 --> 31:06.740]  and the slave nodes will respond in churn as they're pulled, right? So it's pretty simple,
[31:06.740 --> 31:12.720]  but it's pretty effective. You'll actually see Linbus used in things like, if you have
[31:12.720 --> 31:18.180]  powered seats in your car, right? You know, the ability to relax your, you know, your lumbar
[31:18.180 --> 31:25.680]  support, right? Kind of the motorized seat control, right, for comfort. That's usually done
[31:25.680 --> 31:33.500]  in Linbus. Other things of very low importance, I'd say probably moving your mirrors, right, that
[31:33.500 --> 31:39.520]  might be dedicated to Linbus. Anything that you can see as being not incredibly important in a
[31:39.520 --> 31:45.860]  real-time high-speed driving situation, there's a chance it could be dedicated to Linbus. So it's
[31:45.860 --> 31:49.940]  always good to know that Linbus exists, even if it is kind of a small-time player in the automotive
[31:49.940 --> 31:55.860]  sector. So talking about some of the bigger boys, the more newer in-vehicle network technologies,
[31:55.860 --> 32:00.760]  the more recent ones with higher specs, we get to FlexRay. It's high-bandwidth, high-reliability
[32:00.760 --> 32:06.500]  communication, and it's developed for applications where CAN isn't appropriate or fast enough,
[32:06.500 --> 32:11.340]  right? So FlexRay is kind of like a next-gen in-vehicle network. It uses two communication
[32:11.340 --> 32:17.840]  channels between each node, and it uses differential signaling like CAN, but it actually has two
[32:18.440 --> 32:23.640]  channels, an A and a B channel, so you have four wires per connection, right? So it adds
[32:23.640 --> 32:30.460]  redundancy, but it also makes it a pretty expensive protocol to implement, right? But that's kind of
[32:30.460 --> 32:36.540]  how it goes, right? If you want to add more speed, more functionality, you need to make things a
[32:36.540 --> 32:41.940]  little bit more expensive, just because that's how the world works, right? FlexRay payloads support
[32:41.940 --> 32:50.460]  up to 254 bytes in size, and FlexRay is commonly used in X-by-wire systems, right? So because of
[32:50.460 --> 32:55.920]  its high speed, because of its robustness, you know, in a similar vein to that of CAN bus,
[32:55.920 --> 33:01.200]  you're able to use it for things like direct control of throttle, direct control of steering,
[33:01.200 --> 33:06.380]  and direct control of braking, right? The theoretical maximum data rate is about 10
[33:06.380 --> 33:11.060]  megabits per second, so about 10 times as much as CAN's theoretical maximum speed,
[33:11.060 --> 33:16.540]  but since it's a proprietary protocol, it is a little bit more expensive and also a little bit
[33:16.540 --> 33:21.820]  more complicated, especially for the car hacking crowd. It's not as easy to get tools that can work
[33:21.820 --> 33:28.580]  with FlexRay, especially if you're just starting and you don't have a, you know, a wealthy industry
[33:28.580 --> 33:33.680]  supporter providing you with industry-grade tools. It can be hard to get involved with FlexRay just
[33:33.680 --> 33:40.600]  because of how complex it is, right? But moving on, so I'm going to talk about another next-gen
[33:40.600 --> 33:47.160]  vehicle network technology is CAN FD. So CAN FD, the FD stands for flexible data rate. It's the
[33:47.160 --> 33:53.920]  evolution, quote-unquote, of traditional CAN bus, right? It retains many, if not all of the features
[33:53.920 --> 34:01.800]  of classic CAN, right? And this is, it was kept that way because of the success CAN had in the
[34:01.800 --> 34:05.620]  industry, right? It worked really well, we're still using it today even though it's over 30 years old
[34:05.620 --> 34:12.220]  now, I think, yeah, about 30 years old, but it does its job so well there's no real reason to
[34:12.220 --> 34:18.920]  phase it out. But if you wanted to be able to add higher, you know, if you wanted to be able to use
[34:18.920 --> 34:23.660]  CAN in applications where its basic data rate wasn't appropriate, you would need some kind of
[34:23.660 --> 34:31.180]  evolution for that, and CAN FD is the manifestation of that desire, right? So the flexible data rate
[34:31.180 --> 34:36.660]  is achieved by increasing the rate of transfer of the data portion of a CAN message
[34:36.660 --> 34:43.560]  after the message arbitration has been completed, right? And this is just a reality of things, it's
[34:43.560 --> 34:49.720]  due to some issues with classical CAN controllers, some of them will flag CAN FD messages as errors,
[34:49.720 --> 34:56.100]  so it has a bit of backwards compatibility issues. Sorry, I'm trying to talk
[34:56.580 --> 35:02.200]  a little bit faster than I should, I'll slow down a little bit. But CAN FD payloads can
[35:02.200 --> 35:09.240]  range from 8 bytes of data to 64 bytes, which means it transmits 64 bytes in the same time
[35:09.240 --> 35:16.280]  it takes classic CAN to transmit 8 bytes, right? So the theoretical maximum speed of CAN FD is
[35:16.280 --> 35:22.420]  going to be about 8 megabits per second, but in reality, because you only speed up the data
[35:23.060 --> 35:28.680]  field portion of a CAN FD message, the real-time practical throughput is about 6 times that of
[35:28.680 --> 35:34.540]  CAN bus, so about 6, maybe 7 megabits per second at absolute maximum, right? Because you have to
[35:34.540 --> 35:42.180]  keep the overhead and so on the same speed in order to keep cable lengths feasible, cable lengths
[35:42.180 --> 35:46.200]  appropriate, and for, you know, backwards compatibility, especially if you have nodes that
[35:46.200 --> 35:51.240]  are equipped to experience CAN FD messages but aren't really CAN FD nodes themselves, you know,
[35:51.240 --> 35:56.260]  there's kind of like a gray material, gray material, gray zone for that, right? But the
[35:56.840 --> 36:01.560]  maximum data rates, according to estimates, will vary. Some people will say it can go as high as
[36:01.560 --> 36:09.200]  10 megabits, but, you know, more, less optimistic estimates settle around the 5 to 7 megabit marker.
[36:09.680 --> 36:15.880]  So moving on, MOST is the Media Oriented Systems Transport. It's optimized for in-vehicle media
[36:15.880 --> 36:22.540]  systems, so it's very, very high speed, uses a daisy chain topology, the ring topology that I
[36:22.540 --> 36:30.720]  showed earlier, right? And it's, it uses a master device for timing that manages communications,
[36:30.720 --> 36:37.240]  and MOST is one of the first in-vehicle networks to support optical fiber physical layer, making
[36:37.240 --> 36:41.560]  it more or less impervious to electromagnetic interference. MOST has never been used for
[36:41.560 --> 36:46.340]  like critical vehicle control, right? I mentioned that it's optimized for in-vehicle media systems,
[36:46.340 --> 36:52.860]  and that's why it has such a high frequency, right? High frequency, high bandwidth, right? Because you
[36:52.860 --> 36:58.620]  need to be able to process things like video, process things like audio data, process, you know,
[36:58.620 --> 37:02.940]  anything that's going to be used by a media console is probably going to be very high quality data
[37:03.680 --> 37:08.200]  if you want it to be, you know, competitive in the market today, right? I'm kind of a quality
[37:08.200 --> 37:13.700]  buff myself when it comes to watching anything on a screen. But it comes in a couple of flavors,
[37:13.700 --> 37:19.700]  right? MOST 25, 50, and 150, right? Each of these corresponding to the actual speed, and each one of
[37:19.700 --> 37:24.520]  them has shown to be applicable to different physical mediums, right? To the best of my
[37:24.520 --> 37:30.220]  knowledge, MOST 25 was only implemented on fiber, and then 50 and 150 can be used on fiber or
[37:30.920 --> 37:38.700]  optical fiber or copper. And then there was also... it was also a candidate for implementation of
[37:38.700 --> 37:45.680]  Ethernet in automobiles, right? The way MOST was set up. But speaking of Ethernet,
[37:45.680 --> 37:51.640]  automotive Ethernet is kind of like the cool kid on the block, right? The new transfer student that
[37:51.640 --> 37:57.600]  everyone is interested in is automotive Ethernet, right? They're very dynamic, they're
[37:57.600 --> 38:03.220]  very high-powered, and everyone is interested in seeing what they can do, right? It's almost
[38:03.220 --> 38:08.680]  traditional to Ethernet used in computers and traditional network infrastructure, but it uses
[38:08.860 --> 38:13.160]  a different physical, you know, physical layer, right? I believe it only uses two wires as opposed
[38:13.160 --> 38:18.880]  to most traditional Ethernet connections is four wires for data transfer, but don't quote me on
[38:18.880 --> 38:24.480]  that. I wouldn't call myself an automotive Ethernet expert per se, just because it's not actually
[38:24.480 --> 38:29.160]  found in that many cars yet, right? It's hard to do a lot of research on something that's not really
[38:29.160 --> 38:34.100]  in the industry yet. But unlike some of the other networks we talked about today, Ethernet is
[38:34.100 --> 38:39.180]  point-to-point, which makes it a little bit harder to scale to more nodes because you need to add a
[38:39.180 --> 38:44.320]  lot more hardware, right? But it has incredibly high bandwidth potential, which is especially
[38:44.700 --> 38:49.780]  attractive if you're talking about autonomous cars, you know, fusing data from tons of different
[38:49.780 --> 38:55.400]  sensors and processing all of that data for real-time decision-making on the road, right?
[38:55.940 --> 39:00.800]  Some more details about automotive Ethernet. Your traditional RJ45 connector isn't really
[39:00.800 --> 39:06.020]  appropriate for an automotive environment. It's not resistant enough to vibrations to stay
[39:06.020 --> 39:11.160]  connected without deteriorating very quickly. So there are a lot of different physical connectors
[39:11.160 --> 39:15.100]  that have been, you know, made by different vendors, but I wouldn't say there's an industry
[39:15.100 --> 39:19.480]  standard that's been established yet. But some of the more common ones include Broadcom's
[39:20.240 --> 39:26.360]  BroadReach type, right? That's a decently common automotive Ethernet connector type as far as
[39:26.360 --> 39:31.060]  connectors go. But anyway, about, you know, the important thing, the data rates, they can
[39:31.060 --> 39:36.580]  reach as high as 10 gigabits per second. I don't know why I wrote 10G megabits per second here.
[39:36.580 --> 39:43.460]  That doesn't actually mean anything. Typo on my part, but please forgive my ignorance, I suppose.
[39:43.460 --> 39:47.760]  But it is an expensive technology to implement, especially with how new it is.
[39:47.760 --> 39:52.560]  And so there isn't... there's a case to be made that you shouldn't always use Ethernet just because
[39:52.560 --> 39:59.080]  you can. And looking at this chart that shows a comparison of the different data rates, right,
[39:59.080 --> 40:05.780]  Ethernet is quite, you know, easily winning the race, right? This is a logarithmic scale, so you
[40:05.780 --> 40:12.320]  can see we go from 1 to 10 to 100 all the way up to 1 million kilobits per second, right? These other
[40:12.320 --> 40:18.100]  technologies don't even compare to the speed Ethernet can put out. But at the end of the day,
[40:18.100 --> 40:25.060]  do you need this much speed for most of your applications? And the answer is no, right? Like,
[40:25.060 --> 40:28.420]  why don't we just use Ethernet for everything now that we've figured out how to use it? Isn't it
[40:28.420 --> 40:34.120]  just going to save, you know, save in-vehicle networking, right? No more thinking about what
[40:34.120 --> 40:38.980]  technology to use, just use Ethernet. Well, no, right? It's expensive to implement. It's new to
[40:38.980 --> 40:47.540]  the automotive domain, so there's no, like, proven use for it as the only in-vehicle network you need,
[40:47.540 --> 40:51.740]  right? It requires more hardware, thanks to the fact that you might need switching hardware in
[40:51.740 --> 40:58.180]  place to actually do the addressing, you know, at a higher level, especially if you want to implement
[40:58.180 --> 41:06.220]  TCP or IP into your TCP IP in your vehicle, which increases the point of failure relative to,
[41:06.220 --> 41:10.620]  you know, that one switch being a single point of failure for the entire network, so on and so forth,
[41:10.620 --> 41:17.380]  right? And the real important thing here at the end of the day is the cost argument. It's
[41:17.380 --> 41:21.920]  not necessary to have that much bandwidth all the time, right? The old saying, why use a fire hose
[41:21.920 --> 41:29.140]  where a squirt gun will suffice, right? It's truly a case of knowing how much data you need,
[41:29.140 --> 41:35.060]  how fast of a, you know, connection you need between these two ECUs. Is it really worth it
[41:35.060 --> 41:40.360]  to invest in an Ethernet implementation if that means you have to increase the processing power
[41:40.360 --> 41:45.480]  on each of those ECUs as well, right? Because CAN bus, for example, is much simpler to
[41:45.480 --> 41:50.420]  implement than Ethernet and doesn't require as much processing power on the ECUs, so you can use
[41:50.420 --> 41:55.080]  slightly lower grade ECUs for a CAN bus connection than you would for an Ethernet
[41:55.080 --> 42:00.700]  connection, right? There's a lot of reasons to choose a more optimal solution when it comes to
[42:00.700 --> 42:09.440]  lower bandwidth requirement applications, right? So that about wraps up my talk. I don't have any
[42:09.440 --> 42:14.980]  more cute diagrams or clever things to say, so thank you all for listening. I hope you were able
[42:14.980 --> 42:19.520]  to learn something about in-vehicle network technologies and how they're used in the
[42:19.520 --> 42:24.360]  automotive industry. My email address is listed below. You're welcome to send me an email if you
[42:24.360 --> 42:31.080]  have any questions, and yeah, I hope you enjoy the rest of the Car Hacking Village, and I will
[42:31.080 --> 42:33.200]  be signing off now. Thank you very much!