Okay, we're live. Thank you, John, for the lead off. And welcome back, everyone, to another
Car Hacking 101 talk for DEF CON Safe Mode 2020's Car Hacking Village. My name is Kamal,
and in this lecture, I'm going to be talking about in-vehicle networks. I'm also doing a talk
for Bluetooth in the same kind of vein of Car Hacking 101 talks. So if you've already seen
or heard my introduction, I apologize profusely, but I have to give it again for those of you that
might not be interested in Bluetooth or just coming to this one first. So a very short speaker
introduction, right? As I mentioned before, my name is Kamal, Kamal Ghali. I'm an automotive
cybersecurity technology architect at White Motion. White Motion is a small automotive
cybersecurity-focused company. We're a subsidiary of Morelli. It's a much larger Italian automotive
tier one supplier. It's actually the combination of the older Magneti Morelli, Italian automotive
tier one, and a Japanese tier one called CalSonic Kansei. They actually merged a couple of years
ago, and White Motion was at the time owned by CalSonic Kansei, and now we are a full subsidiary
of Morelli Corporation. So I myself am based in Tokyo. I'm a trilingual car hacking enthusiast,
because for me, this is very much more than just a job. It is more than just a profession. It's
something I enjoy, and I enjoy doing a lot of volunteer activities in the industry as well.
For example, this Car Hacking 101 talk is not something anyone is paying me for. No one is,
you know, my boss didn't tell me to go do this. This is entirely because I enjoy what I do,
and I think a lot of people would enjoy doing what I do, and I want to make sure that the
knowledge is easily accessible for people that want to join the industry. So along those lines,
I am an ex-admin of ASRG Detroit. I got involved in Automotive Security Research Group while I was
living in Michigan, helping out with things like working on collaboration between industry
and academia, and I'm the founder of the Automotive Security Research Group Japan.
For any of you that aren't aware, Automotive Security Research Group is an organization
dedicated to sharing information about automotive cybersecurity, making it more readily available,
mainly being driven by the community as opposed to, you know, its own industrial entity, right?
So it's a pretty open community, and a lot of, you know, freely available talks, etc. are available
online for anyone that wants to learn about automotive security. But anyway, I've gone on a
bit of a rant there, but I like to consider myself a jack of some trades, a master of none.
My recent areas of interest are Bluetooth, USB, radio frequency, digital forensics,
and I have some interesting hobbies of mine that I have listed down below.
But today we're not talking about any of these technologies, we're going to talk about in-vehicle
networks. So what is an in-vehicle network? An in-vehicle network is, as you know, I would hope
is obvious, it is a network that's used inside a vehicle, right? So it's a networking technology
that's used to allow the ECUs inside a vehicle to efficiently and, you know, safely share information
between one another. So these in-vehicle network technologies are designed specifically for use
in these closed environments where you have, you know, several ECUs inside a vehicle, they need to
share sensor information, you know, the results of calculations, calibration information, vehicle
status, so on and so forth, with other distributed processing units throughout the vehicle, right?
If you consider, you know, very broadly speaking, a network can be anything. It can be
Bluetooth as a network, you know, 4G, 5G, those are networks, DSRC is a network, Wi-Fi is a network.
But for the purposes of this talk, I'd like to make it clear that I'm talking about
physical networks, I'm talking about guided medium networks, right? For those of you with a background
in networking, you might know the difference between a guided and an unguided medium for your
network is that guided means it's got copper or fiber in place that actually, well, guides the
transmission of information along a specified path, right? It's not radiated like it is in most
wireless communications, right? So we're going to be talking about those kind of physical wire
communications, be they copper-based or fiber-based, and how they're used in a vehicle. I'm going to go
over some of the different types of inter-vehicle networks that are found in the industry today.
I'm going to talk a little bit about each one of them, how they're used, what their strengths are,
what their weaknesses are, etc, right? Strengths and weaknesses are a big part of inter-vehicle
networks because, as you can see, I have listed here, they are selected based on what role they
fill for a given application, right? There's no one-size-fits-all, best-in-vehicle-network
solution that can do everything. There are different solutions, different technologies
available that manufacturers selectively include in their vehicles based on where
they're most appropriate, right? You'll see how this works out in just a second.
So, in the context, excuse me, I was drinking some pineapple juice and some of it's got stuck
in my throat, which is probably not a great way to get ready for giving a recorded talk.
But in the context of a self-driving or autonomous vehicle, this is a fairly common, you know,
logical setup within a vehicle, right? In this diagram, we have a couple of ECUs alongside a
sensor and some actuators, right? The sensor in this case could be, you know, any number of things.
It could be a camera, it could be an accelerometer, a CO2 sensor, a LiDAR sensor, user input sensor,
radio, you know, it could be almost anything, right? The sensor is, at this point, in this logical
diagram, we're just treating this sensor as a source of raw information, right? The data that
this device generates needs to be processed. This is, the sensor isn't, is intaking raw information
and that information needs to be processed, it needs to be interpreted by a processing unit so
that the vehicle as a whole can kind of understand what that raw data means about the vehicle's
environment, what it has to do next, so on and so forth, right? So based on what kind of sensor it is,
you know, what kind of data it's going to be producing and how much of that data it's producing
is going to be different. And a different in-vehicle network technology might be chosen
to carry that data from where it's generated to where it gets processed here in the ECU, right?
So along this diagram, if we take it, you know, kind of from start to finish, this sensor here is
going to generate some raw data, right? This is going to be a camera that's facing, you know,
towards the front of the vehicle. It could be, you know, just assume it's a camera, right? And it takes
that image data and it sends it to ECU 1 for processing, right? Because the processing power
is going to be contained here on the ECU's microcontroller, right? So this line here is
meant to represent an in-vehicle network, right? Because something needs to be in place for this
sensor to be able to send that data to ECU number 1 over here, right? Once ECU 1 has the raw data,
it's going to be able to do some calculations, you know, interpret that data, understand what
that data means, right? Is there, you know, a traffic sign, you know, a stop sign in front of us,
a red stoplight, you know, how self-driving cars should stop for stoplights, so on and so forth.
It's going to make those decisions and, you know, understand the raw data it received,
and then it's going to pass the results of those calculations on to another ECU, right? And then
maybe this ECU is in charge of something else, right? Here I have, you know, two very broadly
defined actuators, right? An actuator in this scenario being any device that upon receiving,
you know, an input from a processing unit converts that input into a physical real-world stimulus,
right? A thing that happens, right? This is what I mean when I'm talking about an actuator.
So each of these lines here is meant to represent an in-vehicle network, and I have them all
colored the same way because at this stage, you know, I haven't talked about the different types
of in-vehicle networks, but each one of these is likely going to be a different type of in-vehicle
network technology because the amount of data being processed from here to here might be
different with the amount of data processed between these two, and it might be different
from the amount of data processed between, you know, ECU 2 and the actuators, right? So some
things to take into consideration when considering which in-vehicle network technology to choose
would be things like safety and robustness requirements, distance from the ECU to the
actual sensor, right? Bandwidth necessities, how much data is being processed, what kind of data
it is, how, you know, how fast it needs to be processed. All of these are metrics you want to
take into consideration when picking the appropriate in-vehicle network to use, right? So going on,
we're going to talk a little bit about network topologies and how they relate to
in-vehicle networks. So I have here, I ripped this image from the internet somewhere. I have
the source listed down here. This is a look at a couple of common network topologies, right?
You have your mesh network, you have your fully connected network, which is also called a full
mesh network, right? You have star topology, ring, and a common bus topology. These might be pretty
familiar to you if you've worked as a systems administrator or you have any, you know, experience
as an actual networking engineer, right? Some of these would be familiar and how they relate to
in-vehicle networks is that we... where am I going with this? Okay, most of the in-vehicle networks
that I'm going to talk about today will use a common bus topology, right? But that doesn't
mean that there aren't some that use other topologies instead, right? Because in-vehicle
networks are designed to be reliable and robust because they are, you know, part of a vehicle
ecosystem. A vehicle is a moving object that moves very fast, is very heavy, and has living breathing
people inside it. There are a lot of important, you know, safety thresholds that need to be met.
There are a lot of standards that, you know, are in place to best guarantee the safety of the
passengers and the environment around the vehicle. And so when we talk about things like the networks
that we use for transferring this information, it's important to know that they need to be
designed with a level of robustness and reliability and safety in mind, right? So with regards to the
networks shown here, some of them have strengths and weaknesses that are realized, or I suppose
they can be seen in the in-vehicle network technologies that make use of these topologies,
right? So say you have a fully connected network. This is a very expensive, very hard to implement
type of network, because every single unit in this device is going to have a direct link to
every other unit in the network, right? This means you need to have the hardware and infrastructure
to connect every unit to every other unit, right? And the positive to this is that, you know,
you have incredible redundancy. If any link goes down, it doesn't matter. Every computer has a link
to every other computer, or every other processor, right? Every other microcontroller, so on and so
forth, whatever it could be, right? So if this ECU here, let's pretend these are ECUs and not
desktops, if this ECU wants to communicate with this ECU, but this direct link between them breaks,
right? The obvious logical conclusion is then, well, I can still talk to this ECU, but through
any number of other paths. I can go from him to him, I can go from him to him, or from him to him,
or from him to him. The fully connected network topology offers the most amount of redundancy,
right? But the downsides are, like I mentioned earlier, they're expensive, they're sometimes a
little bit more complicated to implement, and especially when it comes to cars, the actual
physical cable weight is becoming a sort of rising concern for automotive manufacturers, right? The
actual weight of the cable harness is not a trivial thing. It's not a trivial part of the vehicle
ecosystem, right? The actual designing of a vehicle needs to take into account how much cabling is
going to be in there, because you can have, you know, I don't, I'm not, you know, an expert on how
much cable goes into cars, but I'd say it can amount to quite a bit of weight, right? A couple,
maybe tens of kilograms, I would assume, right? This is just an educated guess, right? But I'm
sure someone more familiar with that actual metric would be able to give you a more accurate
number there. But those are the pros and cons of something like a full connected,
fully connected network topology. A mesh network is kind of like a not full connected network
topology. It's kind of like an in-between, right? You'll have different devices here with different
connections to some, if not all, of the other processors in the network, right? This is good
because you'll have some level of redundancy where if, say, this line goes down, right, then you can
still reach this processor here by going, okay, we'll go here, here, and then here, right? So you have
different paths that your data can take if you need to send data from one processor to another
on the network. A common bus topology, this is where all of the ECUs, in this case, will be
connected to a single common bus that they can all send or receive data from at the same time.
This is how CAN bus works. I'll talk about that in the next couple of slides, as it's the most
common in-vehicle network in the automotive industry currently. But this is a pretty common
implementation because of how easy it is, right? All of the nodes are just
connected to one network, and there isn't any kind of routing protocol you have to implement,
especially when it comes to CAN, right? It's very simple, it's easy to get set up, and it works
pretty well. But one of the downsides, and it's cheap, by the way, but one of the downsides is
that this common bus then becomes a single point of failure. So maybe, you know, you wouldn't use
something like this in a very high, a very critically important system, right? Especially
when we're talking about things like government systems or military systems, you're more likely
to see something like this because they are prioritizing, you know, in the moment operational
stability over everything else, whereas for a mass-produced vehicle, right, this is kind of
how you want to go, right? It's because it needs to be mass-produced, it's not feasible to make
every single car on the road in this, you know, fancy of an architecture. Moving on, ring topology
is pretty rare, but I believe that the most protocol... I'm talking about rare as in within
the vehicle or context, right? Within the most protocol, I believe a ring topology is used,
although there are different versions of most and some of them might be able to be used in other
versions. Most isn't a technology I've personally worked with a lot because it is pretty rare, but
I will touch on it briefly in this presentation. And then you have a star network topology. This
is one of the more common topologies, and especially when it comes to discussing technologies
like automotive ethernet and, you know, trying to run TCP IP inside cars, right? Those are
point-to-point protocols, and for that, a star topology makes a lot of sense. It's a very happy
medium, you know, it doesn't have an excessive amount of cabling and it doesn't have...
if one of these links goes down, then the rest of the network is usually protected,
but you do have to rely on something like a switch or something in the middle to handle
forwarding of communication between the different ECUs, right? But it's kind of seen as a happy
medium network topology, right? But anyway, enough about topologies, let's start talking about
individual in-vehicle networks. So CAN bus is kind of the main character of the in-vehicle network
technology world, right? CAN stands for controller area network. It is the most commonly used in-vehicle
network today by far, right? It is more or less standardized and mandated on most vehicles in the
United States and Europe for diagnostic purposes. It was developed by Robert Bosch in 1991,
is when the 2.0 standard came out, right? The most common nodes you'll find in the market today are
actually 2.0b standard CAN bus nodes, and the 2.0b distinction is that they allow for the
use of 29-bit arbitration identifiers. Arbitration is the process by which
CAN messages have their priority established, and this is the process by which CAN bus actually
handles collisions, right? Collisions are detected and then resolved instantaneously,
almost instantaneously, through the use of arbitration IDs. I don't think we're going to
talk too much about the actual arbitration process today because that's slightly more in-depth for
CAN bus, but this is how CAN bus is addressing, is with arbitration IDs. But I'll just put this
out here now. CAN bus runs in a bus architecture, and it's a multi-master serial communication. So
anyone can send a message, and the arbitration identifier isn't really meant as a source address
or a destination address. It just identifies what kind of data is in this packet, right? So if you
slapped a sticker to a car saying, you know, this car has oranges in it, right? That's kind of what that
does. Saying this truck has oranges in it doesn't mean, you know, it's specific oranges for one
person. There's just oranges, and anyone that wants an orange can stop this truck and get an orange.
That's a horrible example, but hopefully that'll get across the idea of
what an arbitration ID does in a CAN frame, right? And then, you know, back to the CAN frames
themselves. Each CAN bus frame in Classical CAN can hold up to eight bytes of data, right?
So there are a couple different kinds of CANs. The main, most common CAN bus is high-speed CAN,
also called a dual-wire CAN. And this is important because there's a single-wire CAN that also exists,
but dual-wire CAN is the most common one. It uses differential signaling and commonly employs
twisted pair cabling to include, to add some EMI resistance to it, right? I mentioned that
in-vehicle networks need to be reliable, they need to be robust, and this is because a vehicle is a
pretty noisy environment. If you're not familiar with what EMI is, right, this EMI here, it's
electromagnetic interference. This is when things like power supplies or radios or microwaves or
anything that's giving off, you know, radio waves, those radio waves can have on a physical,
you know, physics electronics level, they can actually corrupt some of the data being carried
by a guided medium if that guided medium isn't properly shielded, right? So this twisted pair
cabling is also there to help that because all... well, the way twisted pair cabling works, I'll
explain that in a second. I have a slide where I like to go a little bit more in depth into that.
But the differential signaling and the twisted pair cabling work together to help mitigate EMI
impact, right? Speeds are theoretically up to one megabit per second, although in practice you're
more likely to find 125 kilobits per second, 250 kilobits per second, and 500 kilobits per second
speeds in most cars, right? One megabit speeds are heavily restricted by cable length because at a
certain length of cable it's no longer practical to transmit that fast, and it's just usually a
better idea to stick with 500 kilobits. It's more reliable, right? Just take my word for it.
This is a quick look at what a CAN bus actually looks like from the physical perspective.
CAN buses are usually terminated with 120 ohms on both ends, right? This is a high-speed CAN bus,
by the way. And then on each end, each node will have its own CAN transceiver that is connected
to a CAN low line and a CAN high line, right? So CAN bus is technically a dual-wire system when
we're talking about high-speed CAN. CAN, right? And these are intertwined like this. This is the
twisted pair that I was talking about, right? So you can see that there's a high voltage CAN line
and a low voltage CAN line, and the difference between these two CAN lines is what is read when
a logic is being registered. That's the differential signaling. Excuse me, pineapple juice is starting
to make me burp a little bit. But anyway, back to differential signaling, as I was mentioning.
So this is a very easy to understand diagram showing how differential signaling works in CAN,
right? Here we have a logic graph and an actual physical voltage graph, right? So in high-speed
CAN, CAN high and CAN low both rest at around 2.5 volts. This is their kind of resting state,
and this is what is read as a recessive logic or a logic zero, right? As counterintuitive as it
might seem, logic one in CAN bus is considered recessive and logic zero is considered dominant,
so this shows here how the physical bus would look and the logic bus would look
if we were to transmit 101 on a CAN bus, right? We'd have the recessive, both lines here at 2.5
volts with a zero volt differential. We have dominant for one bit cycle. During that bit
cycle time, the CAN high line gets driven to 3.5 volts and the CAN low line gets driven down
to 1.5 volts, right? This two volt differential is what is kind of registered. It's what's
recognized as a logic zero, right? And then the bus voltages go back down to 2.5 and another
recessive logic one is registered. I'm going to talk a little bit about how the twisted pair
cabling actually protects against EMI. Let me pull out my pen and PowerPoint. So twisted pair
cabling means that the two bus lines, CAN high and CAN low, are intertwined with each other
very tightly, right? They aren't just straight across, you know, from one node to another.
You can make them that way, but it's better not to because of EMI, right? So the way that works,
because those cables are intertwined so tightly, any electromagnetic interference that hits that
bus is very likely to hit both CAN high and CAN low, right? So what happens if that
kind of scenario occurs? Well, let's draw it out. Say there's an electromagnetic pulse
and it's CAN high and CAN low at the same time. It causes a voltage spike that looks
kind of like this, right? And then later down here it also comes up like that, right?
So that's the CAN high. I should have switched the colors here. I'm kind of a fool,
but I didn't do it, so just forgive me, right? The idea is because they're twisted so tightly,
we're likely to see the same exact behavior on CAN low, right? Now I'm doing a really shitty
job of actually drawing this exactly the same from one to the other, but let's just pretend
that these look exactly the same. And then while the bus is in the recessive state, let's say that
that interference continues, right? We'll see the same physical impact on both bus lines, right?
Now, why is that important, right? Remember how the differential signaling, the differential part
means that we're measuring the voltage not based on the raw voltage values of the lines,
but by the difference between the voltages. So here, when we're trying to transmit the zero,
even though we have this interference, the difference between this point and this point
is still two volts, right? So we'll still read a zero. The difference between this point and this
point is still two volts, right? Even if this goes negative, right, and we have the same interference
here because those wires are twisted together, the difference between this low point here and
this low point here is still two volts, right? So the idea is by combining differential signaling
with twisted pair, you have this very robust system where even if you bombard this cable,
this cabling with electromagnetic radiation, you're still likely to get your message across
because of the way Canvas is set up. I think this is very clever and it's one of my favorite things
about Canvas. So it's always good to talk about this and just appreciate the quality of engineering
put into this technology. But onto less common types of Canvas, there's single wire CAN.
It is designated as Society Automotive Engineers Standard J2411. It's CAN for applications with
incredibly low bandwidth requirements and not as much robustness requirements. And as the name
would suggest, it uses only one wire as opposed to high-speed CAN's dual wire. But on that note,
it uses 33 kilobits per second as its maximum data rate, so quite a bit slower than high-speed
CAN. And it does not use differential signaling, so it's not as robust or resilient to EMI.
And the way the signaling works in single wire CAN is more of a raw voltage value reading,
right? So you have a much larger differential between the recessive value and the dominant
value. So in single wire CAN, zero volts is considered recessive and four volts is considered
a dominant bit, right? Low-speed fault-tolerant CAN, the importance of introducing single wire
CAN is that you understand that low-speed fault-tolerant CAN exists as a way to
increase the reliability of high-speed CAN, right? Even if you thought high-speed CAN was
incredibly reliable and robust from the description I just gave of it, there's still
more that can be done. So the way low-speed fault-tolerant CAN works is it does a couple of
things. It actually divides the termination on the bus amongst the nodes, right? So if you remember
in the... let's just go back a second to the slide where I showed the high-speed CAN bus, right? You
have 120 ohms here and 120 ohms here, right? These two 120 ohm resistors in parallel come out to be
60 ohms, right? But these become more or less single points of failure. You remove one of these and
your bus doesn't work anymore. But in fault-tolerant CAN, right? Low-speed fault-tolerant CAN, you
distribute the resistors along the nodes on the bus to actually give the opportunity for the bus
to keep working even if one of these nodes gets removed. Even if one of these resistors gets
removed, you still have enough resistance on the bus for CAN bus to work properly, right? It also
has higher voltage differentials to keep things from getting too... it's just more robustness
just in case there's, you know, an especially large amount of EMI interference, right? CAN high gets
driven to 5 volts and CAN low gets driven to zero volts in the event of a dominant bit
transmission, right? And then another fault-tolerance feature included is that if a wire is damaged,
then LSFT can actually switch over to single-wire CAN operation, right? But at the cost of this is
that it's, you know, more expensive to implement and the maximum data rate you can get with this
kind of implementation is only 125 kilobits per second. And for those reasons, it's not
very commonly seen but it does exist and I figured I'd share, you know, knowledge of its existence
with you guys today. So just to summarize, where CAN is used, right? Instrument clusters, component
control, HVAC, so your car's, you know, climate control, etc. Headlights, brake lights, window status,
GPS, diagnostic information, so much more, right? GPS, I mean, like the CAN bus will carry GPS data
to share with other parts of the vehicle. Your CAN bus isn't generating GPS data, you're getting that
from a satellite, but you already knew that, right? So the point is CAN bus is truly the main character
of in-vehicle network technologies. It has the most applications and it is also, I would say,
the easiest in-vehicle network technology to begin to learn how to use because there are lots of
open source, freely available software tools that you don't even need any hardware, really, to get
started to learn how to use a CAN bus, right? They have visualization software available that you can
use if you wanted to get started, but that's not what this talk is about. But it's truly, truly
the coolest in-vehicle network, I believe, and I don't think it's ever going to be phased out, no
matter what anyone tells you. But moving on, the next one we're going to talk about is LIN. LIN
stands for local interconnect network. It's kind of like CAN bus's little brother, right? It was
actually created after CAN bus, despite having much lower specs from a technical perspective,
and it was made to take the place of CAN bus for low bandwidth applications that didn't require
the same grade of reliability and robustness that CAN offered, right? Like CAN is pretty
cheap as far as in-vehicle network technologies go, but you can always go cheaper, right? So for
things like your, you know, very... I'll say some examples later, but very low speed, very low
bandwidth applications, LIN bus will usually do the trick, right? And it's also a uniform standard
for improved compatibility across manufacturers. It runs on basic... you can actually program a
basic UART transceiver to work with LIN, right? It utilizes a bus topology and it's a broadcast
serial network with a master-slave architecture, supports up to 16 nodes, right? So it's much
simpler in its design compared to CAN, but like I said, it has its place in the industry because
sometimes you don't need any more than those very basic capabilities. So LIN also uses a
single wire, similar to single wired CAN, and it only communicates at 20 kilobits per second, so
it's even slower than single wired CAN, right? But it has guaranteed latency on its transmissions
because it utilizes a scheduling table where the master will periodically pull slave nodes for
their data, right? And it includes data checks on error detection for basic error handling,
right? As you'd expect of something used in automotive, right? It even has that, you know, bare
minimum robustness included into it. And like I mentioned just previously, the transmission is
done according to a scheduling table, and here I have a quick diagram showing how a transmission
will go. So normally you'll have one device on the bus considered the master device, and that
master has a schedule according to which it will send out this master header frame, which kind of
includes, you know, it'll essentially say like, hey, I want this data, right? According to this
identifier. And then the corresponding slave node that has the data associated with the identifier
will then fill in the rest of that data, right? The slave node will then begin to transmit from
this point, right, after this response space. And on the bus, the way that messages appear
is as one lin message, but it's actually half transmitted by the master and half by the slave,
right? So this is all part of a automated sequence where the master header, or the,
sorry, the master node will send out these requests periodically for data updates,
and the slave nodes will respond in churn as they're pulled, right? So it's pretty simple,
but it's pretty effective. You'll actually see Linbus used in things like, if you have
powered seats in your car, right? You know, the ability to relax your, you know, your lumbar
support, right? Kind of the motorized seat control, right, for comfort. That's usually done
in Linbus. Other things of very low importance, I'd say probably moving your mirrors, right, that
might be dedicated to Linbus. Anything that you can see as being not incredibly important in a
real-time high-speed driving situation, there's a chance it could be dedicated to Linbus. So it's
always good to know that Linbus exists, even if it is kind of a small-time player in the automotive
sector. So talking about some of the bigger boys, the more newer in-vehicle network technologies,
the more recent ones with higher specs, we get to FlexRay. It's high-bandwidth, high-reliability
communication, and it's developed for applications where CAN isn't appropriate or fast enough,
right? So FlexRay is kind of like a next-gen in-vehicle network. It uses two communication
channels between each node, and it uses differential signaling like CAN, but it actually has two
channels, an A and a B channel, so you have four wires per connection, right? So it adds
redundancy, but it also makes it a pretty expensive protocol to implement, right? But that's kind of
how it goes, right? If you want to add more speed, more functionality, you need to make things a
little bit more expensive, just because that's how the world works, right? FlexRay payloads support
up to 254 bytes in size, and FlexRay is commonly used in X-by-wire systems, right? So because of
its high speed, because of its robustness, you know, in a similar vein to that of CAN bus,
you're able to use it for things like direct control of throttle, direct control of steering,
and direct control of braking, right? The theoretical maximum data rate is about 10
megabits per second, so about 10 times as much as CAN's theoretical maximum speed,
but since it's a proprietary protocol, it is a little bit more expensive and also a little bit
more complicated, especially for the car hacking crowd. It's not as easy to get tools that can work
with FlexRay, especially if you're just starting and you don't have a, you know, a wealthy industry
supporter providing you with industry-grade tools. It can be hard to get involved with FlexRay just
because of how complex it is, right? But moving on, so I'm going to talk about another next-gen
vehicle network technology is CAN FD. So CAN FD, the FD stands for flexible data rate. It's the
evolution, quote-unquote, of traditional CAN bus, right? It retains many, if not all of the features
of classic CAN, right? And this is, it was kept that way because of the success CAN had in the
industry, right? It worked really well, we're still using it today even though it's over 30 years old
now, I think, yeah, about 30 years old, but it does its job so well there's no real reason to
phase it out. But if you wanted to be able to add higher, you know, if you wanted to be able to use
CAN in applications where its basic data rate wasn't appropriate, you would need some kind of
evolution for that, and CAN FD is the manifestation of that desire, right? So the flexible data rate
is achieved by increasing the rate of transfer of the data portion of a CAN message
after the message arbitration has been completed, right? And this is just a reality of things, it's
due to some issues with classical CAN controllers, some of them will flag CAN FD messages as errors,
so it has a bit of backwards compatibility issues. Sorry, I'm trying to talk
a little bit faster than I should, I'll slow down a little bit. But CAN FD payloads can
range from 8 bytes of data to 64 bytes, which means it transmits 64 bytes in the same time
it takes classic CAN to transmit 8 bytes, right? So the theoretical maximum speed of CAN FD is
going to be about 8 megabits per second, but in reality, because you only speed up the data
field portion of a CAN FD message, the real-time practical throughput is about 6 times that of
CAN bus, so about 6, maybe 7 megabits per second at absolute maximum, right? Because you have to
keep the overhead and so on the same speed in order to keep cable lengths feasible, cable lengths
appropriate, and for, you know, backwards compatibility, especially if you have nodes that
are equipped to experience CAN FD messages but aren't really CAN FD nodes themselves, you know,
there's kind of like a gray material, gray material, gray zone for that, right? But the
maximum data rates, according to estimates, will vary. Some people will say it can go as high as
10 megabits, but, you know, more, less optimistic estimates settle around the 5 to 7 megabit marker.
So moving on, MOST is the Media Oriented Systems Transport. It's optimized for in-vehicle media
systems, so it's very, very high speed, uses a daisy chain topology, the ring topology that I
showed earlier, right? And it's, it uses a master device for timing that manages communications,
and MOST is one of the first in-vehicle networks to support optical fiber physical layer, making
it more or less impervious to electromagnetic interference. MOST has never been used for
like critical vehicle control, right? I mentioned that it's optimized for in-vehicle media systems,
and that's why it has such a high frequency, right? High frequency, high bandwidth, right? Because you
need to be able to process things like video, process things like audio data, process, you know,
anything that's going to be used by a media console is probably going to be very high quality data
if you want it to be, you know, competitive in the market today, right? I'm kind of a quality
buff myself when it comes to watching anything on a screen. But it comes in a couple of flavors,
right? MOST 25, 50, and 150, right? Each of these corresponding to the actual speed, and each one of
them has shown to be applicable to different physical mediums, right? To the best of my
knowledge, MOST 25 was only implemented on fiber, and then 50 and 150 can be used on fiber or
optical fiber or copper. And then there was also... it was also a candidate for implementation of
Ethernet in automobiles, right? The way MOST was set up. But speaking of Ethernet,
automotive Ethernet is kind of like the cool kid on the block, right? The new transfer student that
everyone is interested in is automotive Ethernet, right? They're very dynamic, they're
very high-powered, and everyone is interested in seeing what they can do, right? It's almost
traditional to Ethernet used in computers and traditional network infrastructure, but it uses
a different physical, you know, physical layer, right? I believe it only uses two wires as opposed
to most traditional Ethernet connections is four wires for data transfer, but don't quote me on
that. I wouldn't call myself an automotive Ethernet expert per se, just because it's not actually
found in that many cars yet, right? It's hard to do a lot of research on something that's not really
in the industry yet. But unlike some of the other networks we talked about today, Ethernet is
point-to-point, which makes it a little bit harder to scale to more nodes because you need to add a
lot more hardware, right? But it has incredibly high bandwidth potential, which is especially
attractive if you're talking about autonomous cars, you know, fusing data from tons of different
sensors and processing all of that data for real-time decision-making on the road, right?
Some more details about automotive Ethernet. Your traditional RJ45 connector isn't really
appropriate for an automotive environment. It's not resistant enough to vibrations to stay
connected without deteriorating very quickly. So there are a lot of different physical connectors
that have been, you know, made by different vendors, but I wouldn't say there's an industry
standard that's been established yet. But some of the more common ones include Broadcom's
BroadReach type, right? That's a decently common automotive Ethernet connector type as far as
connectors go. But anyway, about, you know, the important thing, the data rates, they can
reach as high as 10 gigabits per second. I don't know why I wrote 10G megabits per second here.
That doesn't actually mean anything. Typo on my part, but please forgive my ignorance, I suppose.
But it is an expensive technology to implement, especially with how new it is.
And so there isn't... there's a case to be made that you shouldn't always use Ethernet just because
you can. And looking at this chart that shows a comparison of the different data rates, right,
Ethernet is quite, you know, easily winning the race, right? This is a logarithmic scale, so you
can see we go from 1 to 10 to 100 all the way up to 1 million kilobits per second, right? These other
technologies don't even compare to the speed Ethernet can put out. But at the end of the day,
do you need this much speed for most of your applications? And the answer is no, right? Like,
why don't we just use Ethernet for everything now that we've figured out how to use it? Isn't it
just going to save, you know, save in-vehicle networking, right? No more thinking about what
technology to use, just use Ethernet. Well, no, right? It's expensive to implement. It's new to
the automotive domain, so there's no, like, proven use for it as the only in-vehicle network you need,
right? It requires more hardware, thanks to the fact that you might need switching hardware in
place to actually do the addressing, you know, at a higher level, especially if you want to implement
TCP or IP into your TCP IP in your vehicle, which increases the point of failure relative to,
you know, that one switch being a single point of failure for the entire network, so on and so forth,
right? And the real important thing here at the end of the day is the cost argument. It's
not necessary to have that much bandwidth all the time, right? The old saying, why use a fire hose
where a squirt gun will suffice, right? It's truly a case of knowing how much data you need,
how fast of a, you know, connection you need between these two ECUs. Is it really worth it
to invest in an Ethernet implementation if that means you have to increase the processing power
on each of those ECUs as well, right? Because CAN bus, for example, is much simpler to
implement than Ethernet and doesn't require as much processing power on the ECUs, so you can use
slightly lower grade ECUs for a CAN bus connection than you would for an Ethernet
connection, right? There's a lot of reasons to choose a more optimal solution when it comes to
lower bandwidth requirement applications, right? So that about wraps up my talk. I don't have any
more cute diagrams or clever things to say, so thank you all for listening. I hope you were able
to learn something about in-vehicle network technologies and how they're used in the
automotive industry. My email address is listed below. You're welcome to send me an email if you
have any questions, and yeah, I hope you enjoy the rest of the Car Hacking Village, and I will
be signing off now. Thank you very much!