[Script Info] Title: [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:00.00,0:00:14.52,Default,,0000,0000,0000,,{\i1}preroll music{\i0} Dialogue: 0,0:00:14.52,0:00:18.57,Default,,0000,0000,0000,,Camille Gay: Hello, everyone. My name is Camille. I am\Na researcher at Toyota Motor Corporation, Dialogue: 0,0:00:18.57,0:00:21.91,Default,,0000,0000,0000,,and this is a presentation about RAMN, a\Nplatform that we developed to make Dialogue: 0,0:00:21.91,0:00:27.65,Default,,0000,0000,0000,,education and research in the automotive\Nsystems more accessible. The automotive Dialogue: 0,0:00:27.65,0:00:31.92,Default,,0000,0000,0000,,industry can be inaccessible to many\Npeople because automotive projects involve Dialogue: 0,0:00:31.92,0:00:37.55,Default,,0000,0000,0000,,prohibitive costs and be tied to NDAs that\Neverybody is going to sign. What we want Dialogue: 0,0:00:37.55,0:00:41.53,Default,,0000,0000,0000,,to propose with this project is an\Ninexpensive test bed to study and research Dialogue: 0,0:00:41.53,0:00:45.65,Default,,0000,0000,0000,,automotive systems, which is both open\Nsource and developed with open source Dialogue: 0,0:00:45.65,0:00:50.10,Default,,0000,0000,0000,,tools so that at least anyone can get\Naccess to a good alternative for education Dialogue: 0,0:00:50.10,0:00:55.16,Default,,0000,0000,0000,,and research. The main focus of this test\Nbed is security, but you will see that the Dialogue: 0,0:00:55.16,0:00:59.54,Default,,0000,0000,0000,,usage of the test bed is not limited to\Nsecurity, and I will keep the security Dialogue: 0,0:00:59.54,0:01:06.39,Default,,0000,0000,0000,,talk mostly for the end of the\Npresentation. I will start by giving a Dialogue: 0,0:01:06.39,0:01:10.86,Default,,0000,0000,0000,,short introduction about automotive\Nsystems. Then I will present the design Dialogue: 0,0:01:10.86,0:01:15.18,Default,,0000,0000,0000,,details of the test bed besides\Ndemonstrations and concrete details about Dialogue: 0,0:01:15.18,0:01:20.91,Default,,0000,0000,0000,,its hardware and software. As an example\Nof how the test bed can be used, I will Dialogue: 0,0:01:20.91,0:01:25.01,Default,,0000,0000,0000,,spend some time experimenting with cruise\Ncontrol and by that I mean I will go Dialogue: 0,0:01:25.01,0:01:28.77,Default,,0000,0000,0000,,through the whole development process,\Nstarting from evaluating the differential Dialogue: 0,0:01:28.77,0:01:33.67,Default,,0000,0000,0000,,equations of a simple mechanical model. I\Nwill experiment with various control Dialogue: 0,0:01:33.67,0:01:38.60,Default,,0000,0000,0000,,strategies, implement them in C and make\Nmeasurements in a driving simulator using Dialogue: 0,0:01:38.60,0:01:46.00,Default,,0000,0000,0000,,only data from the CAN bus. And I will do\Nall that using only open source tools. Dialogue: 0,0:01:46.00,0:01:49.41,Default,,0000,0000,0000,,This is to demonstrate how the test bed\Ncan be used, but also to have a concrete Dialogue: 0,0:01:49.41,0:01:53.78,Default,,0000,0000,0000,,project that I can use as a reference to\Nexplain after what concretely would have Dialogue: 0,0:01:53.78,0:01:58.29,Default,,0000,0000,0000,,been different if we were experimenting\Nwith a real electronic control unit. I Dialogue: 0,0:01:58.29,0:02:02.77,Default,,0000,0000,0000,,will also explain how we can get close to\Nautomotive hardware and software without Dialogue: 0,0:02:02.77,0:02:07.11,Default,,0000,0000,0000,,signing NDAs. So the second part of the\Ntalk is mainly here to give you more Dialogue: 0,0:02:07.11,0:02:11.13,Default,,0000,0000,0000,,information about the automotive industry\Nin case you are not familiar with it. Dialogue: 0,0:02:11.13,0:02:15.86,Default,,0000,0000,0000,,Before I start, let me just clarify that\Nthis is not an advertisement. We are not Dialogue: 0,0:02:15.86,0:02:20.34,Default,,0000,0000,0000,,selling anything we present here and do\Nnot profit financially from it. We're Dialogue: 0,0:02:20.34,0:02:23.70,Default,,0000,0000,0000,,simply showing design files whithout\Npermising licenses and without Dialogue: 0,0:02:23.70,0:02:29.87,Default,,0000,0000,0000,,royalties. OK, so first, let me give you a\Nvery quick introduction about automotive Dialogue: 0,0:02:29.87,0:02:34.85,Default,,0000,0000,0000,,systems. You can see your car as a\Ncollection of systems divided in four Dialogue: 0,0:02:34.85,0:02:38.23,Default,,0000,0000,0000,,different domains, the powertrain domain,\Nwhich includes the engine and the Dialogue: 0,0:02:38.23,0:02:41.74,Default,,0000,0000,0000,,transmission. The chassis domain, which\Nincludes the steering column and Dialogue: 0,0:02:41.74,0:02:45.71,Default,,0000,0000,0000,,suspensions. The body domain, which\Nincludes the lights, the doors and Dialogue: 0,0:02:45.71,0:02:50.11,Default,,0000,0000,0000,,heating, and the infotainment domain,\Nwhich includes navigation and Dialogue: 0,0:02:50.11,0:02:56.67,Default,,0000,0000,0000,,connectivity. Many of the different\Nsystems that can be found in the car are Dialogue: 0,0:02:56.67,0:03:01.64,Default,,0000,0000,0000,,controlled by electronic control units or\NECUs for short. There are many kinds of Dialogue: 0,0:03:01.64,0:03:05.71,Default,,0000,0000,0000,,ECUs in the car. Sometimes hundreds of\Nthem. And usually it's a lot hard to Dialogue: 0,0:03:05.71,0:03:09.58,Default,,0000,0000,0000,,understand. They have a limited number of\Ninputs, generally data from sensors and Dialogue: 0,0:03:09.58,0:03:15.93,Default,,0000,0000,0000,,actuators. And they have a limited number\Nof outputs generally to control actuators. Dialogue: 0,0:03:15.93,0:03:21.08,Default,,0000,0000,0000,,So, for example, an airbag ECU may use an\Naccelerometer as its input and an airbag Dialogue: 0,0:03:21.08,0:03:25.09,Default,,0000,0000,0000,,trigger as its output. The role of the ECU\Nwould be to use data from the Dialogue: 0,0:03:25.09,0:03:32.15,Default,,0000,0000,0000,,accelerometer to detect a shock and output\Na signal as actuator to detonate an airbag Dialogue: 0,0:03:32.15,0:03:38.93,Default,,0000,0000,0000,,when the shock is detected. It is very\Ncommon for ECUs to read data from other Dialogue: 0,0:03:38.93,0:03:44.31,Default,,0000,0000,0000,,ECUs. Most of the time ECUs will need to\Nshare data with other ECUs on the same Dialogue: 0,0:03:44.31,0:03:48.80,Default,,0000,0000,0000,,domain. In the case of [{\i1}unclear{\i0}],\Nfor example the transmission control unit Dialogue: 0,0:03:48.80,0:03:53.61,Default,,0000,0000,0000,,gets input from the engine ECU to\Ndetermine the correct gear. If the data is Dialogue: 0,0:03:53.61,0:03:58.60,Default,,0000,0000,0000,,critical that connection may even be\Nredundant. ECUs may also need to Dialogue: 0,0:03:58.60,0:04:02.85,Default,,0000,0000,0000,,communicate with ECUs on a different\Ndomain. For example the brake system, Dialogue: 0,0:04:02.85,0:04:06.90,Default,,0000,0000,0000,,usually in the chassis domain, willl need to\Ncommunicate its data to store them, usually Dialogue: 0,0:04:06.90,0:04:11.38,Default,,0000,0000,0000,,in the body domain. Most of the time the\Ntechnology that is used for communication Dialogue: 0,0:04:11.38,0:04:16.72,Default,,0000,0000,0000,,is CAN. And CAN technology uses a bus\Ntopology, which means a CAN message will Dialogue: 0,0:04:16.72,0:04:21.31,Default,,0000,0000,0000,,be received by all ECUs on the same CAN\Nbus, there is no authentication or Dialogue: 0,0:04:21.31,0:04:26.03,Default,,0000,0000,0000,,encryption at the link layer. So any\Nmessage can be sent by any ECU. And Dialogue: 0,0:04:26.03,0:04:32.28,Default,,0000,0000,0000,,security features need to be implemented\Nat higher layers. A standard CAN frame Dialogue: 0,0:04:32.28,0:04:38.33,Default,,0000,0000,0000,,consist mainly of an arbitration ID of 11\Nbits and a payload of 8 bytes. CAN-FD is a Dialogue: 0,0:04:38.33,0:04:46.71,Default,,0000,0000,0000,,recent evolution of CAN where the payload\Nsize may be extended up to 64 bytes. For Dialogue: 0,0:04:46.71,0:04:51.21,Default,,0000,0000,0000,,an ECU network manufacturers will assign a\Nmeaning to each arbitration ID and each Dialogue: 0,0:04:51.21,0:04:54.96,Default,,0000,0000,0000,,bit in the payload, so the file that\Ndetermines the traffic on the CAN bus is Dialogue: 0,0:04:54.96,0:05:01.02,Default,,0000,0000,0000,,often referred to as a DBC file. For\Nexample, assuming a lamp controller and Dialogue: 0,0:05:01.02,0:05:06.75,Default,,0000,0000,0000,,two lamps on the CAN bus. The manufacturer\Nmay decide that ID 123 is used by the lamp Dialogue: 0,0:05:06.75,0:05:12.18,Default,,0000,0000,0000,,controller to communicate the command of\Nboth lamps, that ID 124 is used by the Dialogue: 0,0:05:12.18,0:05:17.68,Default,,0000,0000,0000,,left lamp to give feedback about the\Nstatus and that ID 125 is used by the Dialogue: 0,0:05:17.68,0:05:23.05,Default,,0000,0000,0000,,right lamp to give feedback about its\Nstatus. Each of those messages will be Dialogue: 0,0:05:23.05,0:05:27.83,Default,,0000,0000,0000,,broadcasted periodically by the assigned\NECU on the CAN bus and will serve as a Dialogue: 0,0:05:27.83,0:05:36.05,Default,,0000,0000,0000,,basis for most data exchange between ECUs.\NSo that's it for the introduction, there Dialogue: 0,0:05:36.05,0:05:40.24,Default,,0000,0000,0000,,are many reasons why people would be\Ninterested in automotive systems and ECU Dialogue: 0,0:05:40.24,0:05:44.43,Default,,0000,0000,0000,,networks. The opportunity that gets by far\Nmost attention from the media is Dialogue: 0,0:05:44.43,0:05:49.55,Default,,0000,0000,0000,,vulnerability research. But there are also\Nother reasons. For example, owners: They Dialogue: 0,0:05:49.55,0:05:53.79,Default,,0000,0000,0000,,want to check their car's compliance with\Nregulations such as emissions regulations Dialogue: 0,0:05:53.79,0:06:01.09,Default,,0000,0000,0000,,and privacy regulations. For example,\NGDPR. Other owners may want to exercise Dialogue: 0,0:06:01.09,0:06:04.94,Default,,0000,0000,0000,,their rights to repair as they are\Nguaranteed by the country they live in. Dialogue: 0,0:06:04.94,0:06:09.11,Default,,0000,0000,0000,,And finally, some owners may want to\Nexperiment and innovative DIY features or Dialogue: 0,0:06:09.11,0:06:14.74,Default,,0000,0000,0000,,simply satisfy their curiosity and educate\Nothers. And while those may be valid Dialogue: 0,0:06:14.74,0:06:18.63,Default,,0000,0000,0000,,reasons to experiment with the car,\Nmanufacturers are typically against people Dialogue: 0,0:06:18.63,0:06:22.35,Default,,0000,0000,0000,,tinkering with a car because they may be\Nworried about their intellectual property Dialogue: 0,0:06:22.35,0:06:27.30,Default,,0000,0000,0000,,being stolen, about vulnerabilities being\Nexploited or people hurting themselves and Dialogue: 0,0:06:27.30,0:06:33.09,Default,,0000,0000,0000,,others while tinkering. And what probably\Nsuffers the most from this delicate Dialogue: 0,0:06:33.09,0:06:37.34,Default,,0000,0000,0000,,situation is education and research in\Nautomotive security, because people can Dialogue: 0,0:06:37.34,0:06:41.90,Default,,0000,0000,0000,,not easily get access to safe equipment or\Naccess the information that they would Dialogue: 0,0:06:41.90,0:06:46.89,Default,,0000,0000,0000,,need. In the long term, this may mean that\Nmanufacturers will have less security Dialogue: 0,0:06:46.89,0:06:50.41,Default,,0000,0000,0000,,technologies to choose from to secure\Ntheir cars and that less talents would be Dialogue: 0,0:06:50.41,0:06:55.44,Default,,0000,0000,0000,,available to develop and evaluate them. As\Nthe development, of course, involves many Dialogue: 0,0:06:55.44,0:06:59.30,Default,,0000,0000,0000,,people from many companies, so it is\Nimportant to make sure that everyone Dialogue: 0,0:06:59.30,0:07:05.55,Default,,0000,0000,0000,,involved is competent in automotive\Nsecurity. And some people are pushing for Dialogue: 0,0:07:05.55,0:07:10.60,Default,,0000,0000,0000,,more open sourcing cars and who knows,\Nmaybe one day the car will be 100% Dialogue: 0,0:07:10.60,0:07:17.00,Default,,0000,0000,0000,,open source, but if it happens, it is\Ngoing to take a long time. And Dialogue: 0,0:07:17.00,0:07:20.26,Default,,0000,0000,0000,,manufacturers themselves do not have\Naccess to a hundred percent of the source Dialogue: 0,0:07:20.26,0:07:25.48,Default,,0000,0000,0000,,code of the cars they make because ECUs\Ncontain intellectual property from other Dialogue: 0,0:07:25.48,0:07:29.75,Default,,0000,0000,0000,,companies. So this is mostly a political\Ntopic. So there is not much we can Dialogue: 0,0:07:29.75,0:07:34.79,Default,,0000,0000,0000,,contribute to as researchers. However what\Nwe can contribute technically right now is Dialogue: 0,0:07:34.79,0:07:38.97,Default,,0000,0000,0000,,to try the other way around and use what\Nis publicly available to make it Dialogue: 0,0:07:38.97,0:07:46.66,Default,,0000,0000,0000,,accessible, to learn and research\Nautomotive systems. And this is what we Dialogue: 0,0:07:46.66,0:07:51.67,Default,,0000,0000,0000,,try to do with RAMN, which is the topic of\Nthis presentation. The objective is to Dialogue: 0,0:07:51.67,0:07:56.37,Default,,0000,0000,0000,,provide a platform for research that is:\NOpen, and by that we mean it should be Dialogue: 0,0:07:56.37,0:08:01.35,Default,,0000,0000,0000,,easy to modify the source code, and\Nreprogram the ECUs; Accessible, and by Dialogue: 0,0:08:01.35,0:08:06.40,Default,,0000,0000,0000,,that we mean inexpensive, small and\Nrequiring no prior skills in automotive Dialogue: 0,0:08:06.40,0:08:11.77,Default,,0000,0000,0000,,systems; Safe - with no risk of accidents or\Nlegal repercussions; and motivating, Dialogue: 0,0:08:11.77,0:08:15.48,Default,,0000,0000,0000,,something that you can interact with so\Nthat you get the same kind of experience Dialogue: 0,0:08:15.48,0:08:20.22,Default,,0000,0000,0000,,as you do when you experiment with a real\Ncar. So already some solutions are Dialogue: 0,0:08:20.22,0:08:23.71,Default,,0000,0000,0000,,available if you want to experiment with\Nan ECU network. Besides, of course, a real Dialogue: 0,0:08:23.71,0:08:29.44,Default,,0000,0000,0000,,car, the first one is making your own test\Nbed from real ECUs so we can see many Dialogue: 0,0:08:29.44,0:08:33.47,Default,,0000,0000,0000,,hackers sharing the test bed at security\Nconferences. And usually if you see Dialogue: 0,0:08:33.47,0:08:37.39,Default,,0000,0000,0000,,something like this, you stop and you\Nimmediately get interested. So it is a Dialogue: 0,0:08:37.39,0:08:41.69,Default,,0000,0000,0000,,nice way to motivate people to learn.\NUnfortunately, those are not easy to Dialogue: 0,0:08:41.69,0:08:45.29,Default,,0000,0000,0000,,reprogram because manufacturers do not\Nshare information about the ECUs and they Dialogue: 0,0:08:45.29,0:08:52.85,Default,,0000,0000,0000,,require a lot of skills to build. So it's\Nnot accessible to everyone. Another option Dialogue: 0,0:08:52.85,0:08:57.69,Default,,0000,0000,0000,,is to use development boards such as\NArduino, and that is what you can see Dialogue: 0,0:08:57.69,0:09:02.25,Default,,0000,0000,0000,,mostly on academic papers. They have the\Nadvantage of being reproducible and you Dialogue: 0,0:09:02.25,0:09:06.68,Default,,0000,0000,0000,,can modify the source code as you want. So\Nthey can be used in many cases for Dialogue: 0,0:09:06.68,0:09:12.00,Default,,0000,0000,0000,,research. But they lack many safety\Nfeatures offered on an actual ECU hardware Dialogue: 0,0:09:12.00,0:09:18.87,Default,,0000,0000,0000,,and software. Even if you are able to\Nsimulate a CAN bus, you don't get the same Dialogue: 0,0:09:18.87,0:09:23.52,Default,,0000,0000,0000,,level of interaction as you do with a real\Ncar. So it's not something that motivates Dialogue: 0,0:09:23.52,0:09:31.24,Default,,0000,0000,0000,,people and makes them want to learn more.\NAnd the third option is to use a Dialogue: 0,0:09:31.24,0:09:35.34,Default,,0000,0000,0000,,professional test bed such as Pasta -\Nanother work from our team. This is a good Dialogue: 0,0:09:35.34,0:09:38.68,Default,,0000,0000,0000,,option because you get access to the\Nsource code and you can reprogram the ECUs Dialogue: 0,0:09:38.68,0:09:42.67,Default,,0000,0000,0000,,and the CAN bus network is already\Nsimulating a full car. So the groundwork Dialogue: 0,0:09:42.67,0:09:47.30,Default,,0000,0000,0000,,is already done. So major drawback are\Nthat it is very expensive. So it is not Dialogue: 0,0:09:47.30,0:09:52.46,Default,,0000,0000,0000,,accessible to everyone. So there are some\Noptions to study and research automotive Dialogue: 0,0:09:52.46,0:09:56.60,Default,,0000,0000,0000,,systems, but none of them seem to be both\Naccessible and motivating at the same Dialogue: 0,0:09:56.60,0:10:00.54,Default,,0000,0000,0000,,time. So many people don't even think of\Nrunning automotive systems because it Dialogue: 0,0:10:00.54,0:10:04.96,Default,,0000,0000,0000,,never occurred to them that they could\Nlike it. And in comparison with other Dialogue: 0,0:10:04.96,0:10:08.66,Default,,0000,0000,0000,,industries, you have so many ways to get\Nstarted, if you want to learn about Linux, Dialogue: 0,0:10:08.66,0:10:12.18,Default,,0000,0000,0000,,you can start with a Raspberry Pi. If you\Nwant to learn about electronics you can Dialogue: 0,0:10:12.18,0:10:17.19,Default,,0000,0000,0000,,start with an Arduino and so on. So we\Nwanted something that would give a similar Dialogue: 0,0:10:17.19,0:10:26.86,Default,,0000,0000,0000,,experience, but for automotive systems. So\Nwe noticed that most of the test beds that Dialogue: 0,0:10:26.86,0:10:31.85,Default,,0000,0000,0000,,people are using to experiment with ECUs\Nare made of 4 ECUs. So the ECUs are often Dialogue: 0,0:10:31.85,0:10:38.86,Default,,0000,0000,0000,,communicating with each other using a CAN\Nbus. So we tried to fit all that in a PCB Dialogue: 0,0:10:38.86,0:10:43.73,Default,,0000,0000,0000,,the size of a credit card. And we named\Nthat PCB RAMN. It features four ECUs Dialogue: 0,0:10:43.73,0:10:50.37,Default,,0000,0000,0000,,connected over a common CAN bus or CAN-FD\Nbus, which is accessible from outside by a Dialogue: 0,0:10:50.37,0:10:58.11,Default,,0000,0000,0000,,terminal block. One of the ECUs is also\Nconnected to USB, which is also the power Dialogue: 0,0:10:58.11,0:11:02.39,Default,,0000,0000,0000,,supply. PIN-sockets can be used to\Nconnect sensors, actuators and additional Dialogue: 0,0:11:02.39,0:11:07.17,Default,,0000,0000,0000,,hardware and the board features many\Nprobes to easily access important electric Dialogue: 0,0:11:07.17,0:11:16.95,Default,,0000,0000,0000,,signals. The 4 ECUs simulate a CAN network\Nwith messages identical to Pasta. The name Dialogue: 0,0:11:16.95,0:11:21.43,Default,,0000,0000,0000,,RAMN is obviously a reference to Pasta as\Nthis is a cheap alternative, mostly aimed Dialogue: 0,0:11:21.43,0:11:26.88,Default,,0000,0000,0000,,at students. In real cars CAN messages\Ntypically have different payload sizes, Dialogue: 0,0:11:26.88,0:11:30.57,Default,,0000,0000,0000,,but by default we operate with maximum\Npayload size, to demonstrate heavy Dialogue: 0,0:11:30.57,0:11:35.74,Default,,0000,0000,0000,,traffic, so the basic format is like this:\NArbitration ID, 2 bytes for the data, Dialogue: 0,0:11:35.74,0:11:40.32,Default,,0000,0000,0000,,2 bytes for a counter and 4 bytes of\Nadditional data, random data used as a Dialogue: 0,0:11:40.32,0:11:47.22,Default,,0000,0000,0000,,placeholder for additional data such as\Nchecksum or MAC. You can easily modify the Dialogue: 0,0:11:47.22,0:11:51.35,Default,,0000,0000,0000,,CAN bus's arbitration ID end format. And\Nhere we are assuming a full by-wire Dialogue: 0,0:11:51.35,0:11:55.51,Default,,0000,0000,0000,,vehicle, which means all physical\Nfunctions of a car are accessible to the Dialogue: 0,0:11:55.51,0:12:02.29,Default,,0000,0000,0000,,CAN bus, which is usually not the case on\Ncurrent cars. The block diagram of RAMN Dialogue: 0,0:12:02.29,0:12:06.48,Default,,0000,0000,0000,,looks like this. And as I explained\Nearlier, all ECUs are periodically Dialogue: 0,0:12:06.48,0:12:10.77,Default,,0000,0000,0000,,exchanging messages on the CAN bus. If you\Nconnect a CAN adapter and have a look at Dialogue: 0,0:12:10.77,0:12:22.74,Default,,0000,0000,0000,,the traffic, it will typically look like\Nthis. So the board itself is enough to Dialogue: 0,0:12:22.74,0:12:27.28,Default,,0000,0000,0000,,simulate an ECU network, but it does not\Nlook very motivating. What we wanted on Dialogue: 0,0:12:27.28,0:12:33.57,Default,,0000,0000,0000,,top of this was some sensors and actuators\Nto make it more interactive. So we created Dialogue: 0,0:12:33.57,0:12:37.96,Default,,0000,0000,0000,,4 expansion boards for sensors and\Nactuators. To simulate the infotainment Dialogue: 0,0:12:37.96,0:12:43.21,Default,,0000,0000,0000,,domain, we simply use a screen. For the\Nbody domain, we use an engine key and some Dialogue: 0,0:12:43.21,0:12:52.29,Default,,0000,0000,0000,,LEDs. For the chassis domain we mainly use\Na slide switch to simulate a side brake Dialogue: 0,0:12:52.29,0:12:57.17,Default,,0000,0000,0000,,and a rotating potentiometer to simulate\Nthe steering wheel. And for the power Dialogue: 0,0:12:57.17,0:13:00.81,Default,,0000,0000,0000,,train domain we use slide potentiometers\Nfor the brake and accelerator and a Dialogue: 0,0:13:00.81,0:13:09.05,Default,,0000,0000,0000,,joystick for the shift lever. The EC\Nconnected to USB implements a standard CAN Dialogue: 0,0:13:09.05,0:13:14.02,Default,,0000,0000,0000,,or CAN-FD interface, either of a standard\Nserial port using Slcan or over a native Dialogue: 0,0:13:14.02,0:13:17.99,Default,,0000,0000,0000,,interface on Linux thanks to the\Ncounterlight firmware projects. If you Dialogue: 0,0:13:17.99,0:13:22.12,Default,,0000,0000,0000,,connect the board to a USB port on the\Ncomputer, it should be recognized as a USB Dialogue: 0,0:13:22.12,0:13:26.16,Default,,0000,0000,0000,,to CAN adapter. So it is not necessary to\Nown an external CAN adapter to get Dialogue: 0,0:13:26.16,0:13:33.06,Default,,0000,0000,0000,,started. This is a demo of what it looks\Nlike to use RAMN. Just connect it over Dialogue: 0,0:13:33.06,0:13:39.20,Default,,0000,0000,0000,,USB, if you use Linux, you can get it to be\Nrecognized as a standard CAN network Dialogue: 0,0:13:39.20,0:13:44.54,Default,,0000,0000,0000,,interface. So it will show up in ifconfig.\NThen you can use various tools available Dialogue: 0,0:13:44.54,0:13:48.38,Default,,0000,0000,0000,,on Linux to observe the traffic, for\Nexample CAN sniffer. Here you can see the Dialogue: 0,0:13:48.38,0:13:58.52,Default,,0000,0000,0000,,traffic explained earlier, the CAN IDs on\Nthe left and the payload on the right. So Dialogue: 0,0:13:58.52,0:14:02.97,Default,,0000,0000,0000,,with this, we can simulate a ECU network\Nwith sensors and actuators, which is Dialogue: 0,0:14:02.97,0:14:06.64,Default,,0000,0000,0000,,enough for basic interactions. But it\Nstill doesn't feel like you are actually Dialogue: 0,0:14:06.64,0:14:11.70,Default,,0000,0000,0000,,experimenting with a car. Ideally the ECUs\Nshould be performing realistic ECU Dialogue: 0,0:14:11.70,0:14:16.99,Default,,0000,0000,0000,,functions, not just lighting up LEDs based\Non some switches and potentiometers. And Dialogue: 0,0:14:16.99,0:14:20.32,Default,,0000,0000,0000,,for this we thought of a connection in a\Nclosed loop with an open source driving Dialogue: 0,0:14:20.32,0:14:28.15,Default,,0000,0000,0000,,simulator which is an affordable and safe solution. \NTo feel like you are driving the ECU network. Dialogue: 0,0:14:28.15,0:14:32.84,Default,,0000,0000,0000,,Fortunately, there is a great open source\Ndriving simulator for autonomous driving Dialogue: 0,0:14:32.84,0:14:36.81,Default,,0000,0000,0000,,research. It is called CARLA. It features\Na Python API. So it is very easy to Dialogue: 0,0:14:36.81,0:14:42.08,Default,,0000,0000,0000,,interact with it and it also comes with an\Nexample self-driving algorithm. So you can Dialogue: 0,0:14:42.08,0:14:48.67,Default,,0000,0000,0000,,immediately start experimenting with your\Nvirtual self-driving car. So we wrote some Dialogue: 0,0:14:48.67,0:14:53.77,Default,,0000,0000,0000,,scripts so that most sensors values for\Nexample speed and altitude would be Dialogue: 0,0:14:53.77,0:14:58.57,Default,,0000,0000,0000,,simulated on the computer running CARLA.\NThen broadcasted on the CAN bus. On the Dialogue: 0,0:14:58.57,0:15:02.54,Default,,0000,0000,0000,,other side we made it so that all controls\Nof CARLA such as throttle, steering and Dialogue: 0,0:15:02.54,0:15:07.83,Default,,0000,0000,0000,,brakes will be decided by the ECU network.\NAnd this is what you could refer to as Dialogue: 0,0:15:07.83,0:15:12.38,Default,,0000,0000,0000,,HILs or Hardware-In-The-Loop simulation in\Nthe automotive industry, RAMN is not as Dialogue: 0,0:15:12.38,0:15:30.21,Default,,0000,0000,0000,,advanced as professional tools, but at\Nleast it is accessible. So to achieve Dialogue: 0,0:15:30.21,0:15:33.95,Default,,0000,0000,0000,,manual control, it is not complicated with\NCARLA. On the manual control example Dialogue: 0,0:15:33.95,0:15:38.33,Default,,0000,0000,0000,,provided with the API there is a while\Ntrue game loop that with events of the Dialogue: 0,0:15:38.33,0:15:44.73,Default,,0000,0000,0000,,keyboard, applies controls, then updates\Nthe physics simulation. So CARLA does not Dialogue: 0,0:15:44.73,0:15:48.83,Default,,0000,0000,0000,,simulate the CAN bus by default so we\Ncreated a Python class to easily interact Dialogue: 0,0:15:48.83,0:15:52.84,Default,,0000,0000,0000,,with the CAN bus using the CAN message\Nspecifications of RAMN. To integrate it Dialogue: 0,0:15:52.84,0:15:56.71,Default,,0000,0000,0000,,with CARLA we just need to replace\Nkeyboard controls with actuator control Dialogue: 0,0:15:56.71,0:16:02.39,Default,,0000,0000,0000,,data read from the CAN bus. To close the\Nloop we broadcast sensor data using CAN Dialogue: 0,0:16:02.39,0:16:08.45,Default,,0000,0000,0000,,messages based on data retrieved from the\NPython API of the physics simulator. And Dialogue: 0,0:16:08.45,0:16:14.97,Default,,0000,0000,0000,,with this we are able to control the car\Nmanually, the potentiometers on the board. Dialogue: 0,0:16:14.97,0:16:19.32,Default,,0000,0000,0000,,Here I gently press accelerator, release\Nthe handbrake, and I can control the car Dialogue: 0,0:16:19.32,0:16:39.54,Default,,0000,0000,0000,,using the steering wheel \Non the expansion board. Dialogue: 0,0:16:39.54,0:17:03.50,Default,,0000,0000,0000,,{\i1}Video stops{\i0} Dialogue: 0,0:17:03.50,0:17:05.25,Default,,0000,0000,0000,,So manual control is nice, but Dialogue: 0,0:17:05.25,0:17:09.52,Default,,0000,0000,0000,,automatic control is better because\Nultimately we want to focus on working on Dialogue: 0,0:17:09.52,0:17:14.00,Default,,0000,0000,0000,,the CAN bus. So on the original CARLA\Nproject, there was also an example script Dialogue: 0,0:17:14.00,0:17:18.90,Default,,0000,0000,0000,,for automatic control. Again there is a\Nwhile true loop where the code basically Dialogue: 0,0:17:18.90,0:17:22.79,Default,,0000,0000,0000,,simulates the physics, lets the self-\Ndriving AI make a decision, then applies Dialogue: 0,0:17:22.79,0:17:30.68,Default,,0000,0000,0000,,the controls to the physics simulation. To\Nintegrate RAMN in this certain algorithm, Dialogue: 0,0:17:30.68,0:17:34.20,Default,,0000,0000,0000,,again, we need to replace the apply\Ncontrol part with the controls from the Dialogue: 0,0:17:34.20,0:17:38.98,Default,,0000,0000,0000,,ECU network. We also need to send CAN\Nmessages with sensor data retrieved from Dialogue: 0,0:17:38.98,0:17:44.07,Default,,0000,0000,0000,,the Python API of the physics simulation.\NThat is identical to having manual Dialogue: 0,0:17:44.07,0:17:50.42,Default,,0000,0000,0000,,control. What we need to do more is also\Nsend a message to broadcast the status of Dialogue: 0,0:17:50.42,0:17:57.18,Default,,0000,0000,0000,,the AI to the ECU Network, so that the ECU\Nnetwork knows what controls the AI Dialogue: 0,0:17:57.18,0:18:05.86,Default,,0000,0000,0000,,algorithm is requesting. So periodically\Nthe AI would broadcast its status by Dialogue: 0,0:18:05.86,0:18:10.18,Default,,0000,0000,0000,,sending messages over USB, which are\Nconverted into CAN messages by the ECU Dialogue: 0,0:18:10.18,0:18:15.95,Default,,0000,0000,0000,,input to USB. All ECUs on the network will\Nreceive those messages and will decide the Dialogue: 0,0:18:15.95,0:18:22.41,Default,,0000,0000,0000,,actual controls of the car based on their\Nown algorithm. For example, the power Dialogue: 0,0:18:22.41,0:18:26.80,Default,,0000,0000,0000,,train ECU may decide to apply brakes\Ndepending on the highest value between the Dialogue: 0,0:18:26.80,0:18:33.26,Default,,0000,0000,0000,,AI brakes and the brake potentiometer. All\NECUs will receive the CAN message and Dialogue: 0,0:18:33.26,0:18:38.52,Default,,0000,0000,0000,,apply the control, some ECUs may filter\Nthat message if they do not need it. Some Dialogue: 0,0:18:38.52,0:18:44.19,Default,,0000,0000,0000,,ECUs like the body ECU may process it and\Ntake action. For example, if the brakes Dialogue: 0,0:18:44.19,0:18:49.79,Default,,0000,0000,0000,,are engaged, the body ECU will light up\Nthe stop lamp on the expansion board. Dialogue: 0,0:18:49.79,0:18:55.24,Default,,0000,0000,0000,,Finally, the ECU connected to USB will\Nforward the brake controls to the Dialogue: 0,0:18:55.24,0:19:02.35,Default,,0000,0000,0000,,simulator that will apply the brakes in\Nthe physics simulation. So this is what it Dialogue: 0,0:19:02.35,0:19:06.87,Default,,0000,0000,0000,,actually looks like, all I need to do\Nagain is release the handbrake and the car Dialogue: 0,0:19:06.87,0:19:12.67,Default,,0000,0000,0000,,will drive itself. The car is controlled\Nby the ECU network, so when the car stops Dialogue: 0,0:19:12.67,0:19:15.76,Default,,0000,0000,0000,,in the simulation, it is because the\Ncontrols were applied by the power train Dialogue: 0,0:19:15.76,0:19:21.45,Default,,0000,0000,0000,,ECU. You can see that the stop lamp lights\Nup because the body ECU also received and Dialogue: 0,0:19:21.45,0:19:31.44,Default,,0000,0000,0000,,processed the break CAN message. Since the\NECU is in charge of the controls, I can Dialogue: 0,0:19:31.44,0:19:45.04,Default,,0000,0000,0000,,force the car to stop any time by forcing\Nbrakes on the power train ECU potentiometer. Dialogue: 0,0:19:45.04,0:19:47.93,Default,,0000,0000,0000,,So if you connect an external \NCAN adapter to the CAN bus, Dialogue: 0,0:19:47.93,0:19:52.62,Default,,0000,0000,0000,,you'll be able to send and receive\Nmessages. So using RAMN you can experiment Dialogue: 0,0:19:52.62,0:20:03.15,Default,,0000,0000,0000,,with the CAN bus of the self-driving\Nvirtual car. When you want to reprogram an Dialogue: 0,0:20:03.15,0:20:07.29,Default,,0000,0000,0000,,ECU in the real world, you have two\Noptions. Either you interact with the Dialogue: 0,0:20:07.29,0:20:10.75,Default,,0000,0000,0000,,hardware bootloader of the ECUs\Nmicrocontroller, which depends on the Dialogue: 0,0:20:10.75,0:20:14.48,Default,,0000,0000,0000,,microcontrollers model and manufacturer,\Nor you interact with diagnostics and Dialogue: 0,0:20:14.48,0:20:19.46,Default,,0000,0000,0000,,calibration software, which depends on the\Ncar model and manufacturer. Diagnostic and Dialogue: 0,0:20:19.46,0:20:24.33,Default,,0000,0000,0000,,calibration are often done on the CAN bus,\Nbut other options may be available. Dialogue: 0,0:20:24.33,0:20:30.29,Default,,0000,0000,0000,,Protocols are defined by standard\Ndocuments. You often hear about UDS and Dialogue: 0,0:20:30.29,0:20:34.92,Default,,0000,0000,0000,,OBD-II which both rely on the same\Ntransport layer ISO-TP. But there are also Dialogue: 0,0:20:34.92,0:20:43.05,Default,,0000,0000,0000,,other protocols, such as Keyword Protocol\N2000 or XCP. All those protocols can often Dialogue: 0,0:20:43.05,0:20:49.52,Default,,0000,0000,0000,,also be implemented over other layers. For\Nthe hardware bootloaders it depends on the Dialogue: 0,0:20:49.52,0:20:54.12,Default,,0000,0000,0000,,microcontroller manufacturer. For example\Nfor an STM 32 microcontroller you can Dialogue: 0,0:20:54.12,0:20:58.77,Default,,0000,0000,0000,,reprogram the firmware by interacting over\NCAN according to the application note Dialogue: 0,0:20:58.77,0:21:04.77,Default,,0000,0000,0000,,3154, over USB according to the\Napplication note 3156. Or using other Dialogue: 0,0:21:04.77,0:21:11.60,Default,,0000,0000,0000,,protocols defined in other application\Nnotes. In the case of RAMN, we use the Dialogue: 0,0:21:11.60,0:21:16.16,Default,,0000,0000,0000,,hardware bootloader to reprogram the ECUs\Nand you can also use a UDS protocol over Dialogue: 0,0:21:16.16,0:21:24.24,Default,,0000,0000,0000,,CAN. And in the future we may consider\Nadding XCP and KWD 2000. How to reprogram Dialogue: 0,0:21:24.24,0:21:28.24,Default,,0000,0000,0000,,an ECU using calibration and diagnostic\Nsoftware is a topic that is already Dialogue: 0,0:21:28.24,0:21:32.57,Default,,0000,0000,0000,,heavily discussed at automotive security\Ntalks, I will not spend time on this Dialogue: 0,0:21:32.57,0:21:37.55,Default,,0000,0000,0000,,topic. You can find the definition of the\Nstandards online. Usually you need to pay Dialogue: 0,0:21:37.55,0:21:43.57,Default,,0000,0000,0000,,for them. But you can also find summaries\Nfor free on some websites. For example, Dialogue: 0,0:21:43.57,0:21:51.72,Default,,0000,0000,0000,,Wikipedia. What is more interesting to\Ndiscuss here is the hardware bootloader. Dialogue: 0,0:21:51.72,0:21:54.95,Default,,0000,0000,0000,,The various ways to force a microcontroller \Ninto bootloader mode are Dialogue: 0,0:21:54.95,0:22:01.65,Default,,0000,0000,0000,,described in the application note 2606.\NThe format of CAN messages we need to send Dialogue: 0,0:22:01.65,0:22:06.65,Default,,0000,0000,0000,,to interact with the bootloader is defined\Nin the application note 3154. And it's not Dialogue: 0,0:22:06.65,0:22:11.77,Default,,0000,0000,0000,,complicated. The format is simply common\Nbyte plus argument. All that within the Dialogue: 0,0:22:11.77,0:22:18.85,Default,,0000,0000,0000,,same CAN message payload. So we wrote some\Nscript to make it easier to interact with Dialogue: 0,0:22:18.85,0:22:27.90,Default,,0000,0000,0000,,the bootloader. So here I am showing the\Nscript that we use to interact with the Dialogue: 0,0:22:27.90,0:22:32.26,Default,,0000,0000,0000,,bootloader. First thing I do is retrieve\Nall information from the bootloader, Dialogue: 0,0:22:32.26,0:22:38.03,Default,,0000,0000,0000,,including the version, the supported\Ncommands and the Chip ID. I then use a Dialogue: 0,0:22:38.03,0:22:44.41,Default,,0000,0000,0000,,read memory command to dump all known\Nsections of memories. This includes the Dialogue: 0,0:22:44.41,0:22:48.89,Default,,0000,0000,0000,,ECU firmware. So it can be a good start to\Nstart experimenting with reverse Dialogue: 0,0:22:48.89,0:23:03.58,Default,,0000,0000,0000,,engineering. We can also activate memory\Nwithout protection and see what happens Dialogue: 0,0:23:03.58,0:23:18.90,Default,,0000,0000,0000,,when you try to dump the memory again. And\Nin this case is not allowing memory dumps Dialogue: 0,0:23:18.90,0:23:22.12,Default,,0000,0000,0000,,anymore. You can remove the memory\Nprotection, which will wipe out the Dialogue: 0,0:23:22.12,0:23:46.90,Default,,0000,0000,0000,,memory, and after you do that, you can use\Nthe bootloader to reprogram the ECUs. For Dialogue: 0,0:23:46.90,0:23:50.73,Default,,0000,0000,0000,,the hardware we also designed additional\Nexpansion boards with various features. Dialogue: 0,0:23:50.73,0:23:56.07,Default,,0000,0000,0000,,First one is an expansion to connect a\NJTAG debugger. Second one is about to add Dialogue: 0,0:23:56.07,0:24:02.00,Default,,0000,0000,0000,,extra QuadSPI Memories, which is why you\Nsee packages such as EEPROM, FRAM, NAND, Dialogue: 0,0:24:02.00,0:24:09.53,Default,,0000,0000,0000,,SRAM and so on. The third one is a board\Nto add a trusted platform module. And the Dialogue: 0,0:24:09.53,0:24:22.65,Default,,0000,0000,0000,,last one is an interface to easily connect\Na chip whisperer. All those expansions are Dialogue: 0,0:24:22.65,0:24:26.98,Default,,0000,0000,0000,,compatible with each other, so you can\Nstack them and create a very advanced ECU Dialogue: 0,0:24:26.98,0:24:33.87,Default,,0000,0000,0000,,network with all ECUs between a TPM and\None gigabit of memory. And it looks better Dialogue: 0,0:24:33.87,0:24:40.56,Default,,0000,0000,0000,,when the expansions are stacked on top of\Neach other. Since we would like to use Dialogue: 0,0:24:40.56,0:24:45.19,Default,,0000,0000,0000,,RAMN for education, we try to vary the\Ntype of electrical signals using the Dialogue: 0,0:24:45.19,0:25:04.54,Default,,0000,0000,0000,,expansions. And we added many external\Nprobes to easily connect external tools. You Dialogue: 0,0:25:04.54,0:25:08.55,Default,,0000,0000,0000,,can use one of the many excellent probes\Nto connect an oscilloscope and have a look Dialogue: 0,0:25:08.55,0:25:18.07,Default,,0000,0000,0000,,at analog signals. For example, here's the\Nbrake potentiometer. Or connect a logic Dialogue: 0,0:25:18.07,0:25:23.70,Default,,0000,0000,0000,,analyzer and have a look at digital\Nsignals, for example, to analyze SPI Dialogue: 0,0:25:23.70,0:25:34.22,Default,,0000,0000,0000,,communication between the ECU and the\Nscreen. For the hardware design we kept it Dialogue: 0,0:25:34.22,0:25:38.77,Default,,0000,0000,0000,,simple using only two layers and keeping\Nall components on the same side. We Dialogue: 0,0:25:38.77,0:25:41.76,Default,,0000,0000,0000,,designed the hardware with flash\Ntolerances which should be easy to produce Dialogue: 0,0:25:41.76,0:25:47.54,Default,,0000,0000,0000,,with most PCB fabrication services. We use\Ncomponents with large size. So if you have Dialogue: 0,0:25:47.54,0:26:00.27,Default,,0000,0000,0000,,some skills in soldering, you should be\Nable to solder one yourself. We designed Dialogue: 0,0:26:00.27,0:26:04.57,Default,,0000,0000,0000,,the hardware using KiCAD, which is an open\Nsource tool for designing hardware. You Dialogue: 0,0:26:04.57,0:26:13.36,Default,,0000,0000,0000,,can easily modify the schematics, layout\Nand even generate nice 3D views. So Dialogue: 0,0:26:13.36,0:26:18.55,Default,,0000,0000,0000,,firmware is designed using STM32CubeIDE,\Nit is accessible to beginners, and you can Dialogue: 0,0:26:18.55,0:26:23.30,Default,,0000,0000,0000,,easily reconfigure peripherals and clocks\Nfrom the graphical interface. You will Dialogue: 0,0:26:23.30,0:26:27.95,Default,,0000,0000,0000,,even get some statistics, such as the\Nestimated power consumption. But of Dialogue: 0,0:26:27.95,0:26:31.50,Default,,0000,0000,0000,,course, you do not need to use the\Ngraphical interface and libraries if you Dialogue: 0,0:26:31.50,0:26:38.09,Default,,0000,0000,0000,,would rather program everything yourself\Nby interacting directly with registers. We Dialogue: 0,0:26:38.09,0:26:42.90,Default,,0000,0000,0000,,use free RTOS as a Real-Time operating\Nsystem. The basic software of ECUs has Dialogue: 0,0:26:42.90,0:26:46.97,Default,,0000,0000,0000,,several tasks running in parallel, one for\Nreceiving CAN messages, one for sending Dialogue: 0,0:26:46.97,0:26:52.54,Default,,0000,0000,0000,,CAN messages and several periodic tasks to\Ntake care of the ECU control loops. Those Dialogue: 0,0:26:52.54,0:26:57.95,Default,,0000,0000,0000,,tasks receive data from different\Ninterrupt services within, using queues and Dialogue: 0,0:26:57.95,0:27:03.74,Default,,0000,0000,0000,,DMA memory overwrites. The tasks can also\Nexchange data between each other using Dialogue: 0,0:27:03.74,0:27:11.62,Default,,0000,0000,0000,,queues or memory overwrites. Again, to\Nkeep the project accessible to beginners, Dialogue: 0,0:27:11.62,0:27:15.24,Default,,0000,0000,0000,,we did the OS configuration using the\Ngraphical interface where you can see all Dialogue: 0,0:27:15.24,0:27:19.62,Default,,0000,0000,0000,,tasks and their configuration, for example\Nthe priority. You can add or remove Dialogue: 0,0:27:19.62,0:27:23.61,Default,,0000,0000,0000,,interrupts. And you can also configure the\Nvarious queues in memory. There is still a Dialogue: 0,0:27:23.61,0:27:31.26,Default,,0000,0000,0000,,lot of memory left even though the memory\Ncontroller is less performant. So you can Dialogue: 0,0:27:31.26,0:27:41.05,Default,,0000,0000,0000,,easily add your own application on top of\Nthis. That's all for the hardware and Dialogue: 0,0:27:41.05,0:27:45.15,Default,,0000,0000,0000,,software section, you can find more\Ndetails on GitHub. I would like to move to Dialogue: 0,0:27:45.15,0:27:50.11,Default,,0000,0000,0000,,the next section and show you a usage\Nexample. There are usually two budgets for Dialogue: 0,0:27:50.11,0:27:54.19,Default,,0000,0000,0000,,people working in automotive security\NEither they are automotive engineers who Dialogue: 0,0:27:54.19,0:27:58.64,Default,,0000,0000,0000,,learn about security or they are security\Nengineers who wrote about automotive Dialogue: 0,0:27:58.64,0:28:03.05,Default,,0000,0000,0000,,systems. Since this is a security\Nconference and I assume most people do not Dialogue: 0,0:28:03.05,0:28:07.31,Default,,0000,0000,0000,,need me to explain how the platform can be\Nused to study and research basic security Dialogue: 0,0:28:07.31,0:28:15.15,Default,,0000,0000,0000,,topics, I will focus on the automotive\Nside. So diagnostics and calibration topic Dialogue: 0,0:28:15.15,0:28:25.07,Default,,0000,0000,0000,,is already covered by many security \Ntalks. I will not spend time on this. So Dialogue: 0,0:28:25.07,0:28:29.89,Default,,0000,0000,0000,,I will spend time on something\Nthat is not often mentioned at security Dialogue: 0,0:28:29.89,0:28:37.00,Default,,0000,0000,0000,,conferences: Control algorithms and safety\Ncritical hardware and software. And for Dialogue: 0,0:28:37.00,0:28:39.96,Default,,0000,0000,0000,,this, I would like to demonstrate the\Ndesign of a PID controller for cruise Dialogue: 0,0:28:39.96,0:28:43.79,Default,,0000,0000,0000,,control as an example. I will show you how\Nbeing knowledgeable in control systems may Dialogue: 0,0:28:43.79,0:28:49.49,Default,,0000,0000,0000,,be relevant to security engineers, and how\Nmany of the activities that are done by Dialogue: 0,0:28:49.49,0:28:54.86,Default,,0000,0000,0000,,engineers in the automotive industry can\Nalso be simulated using open source tools, Dialogue: 0,0:28:54.86,0:29:01.38,Default,,0000,0000,0000,,including RAMN. Once we have an\Nimplementation in C that works, I would Dialogue: 0,0:29:01.38,0:29:04.92,Default,,0000,0000,0000,,then use it as a reference to talk about\Nsafety critical systems and the Dialogue: 0,0:29:04.92,0:29:14.22,Default,,0000,0000,0000,,differences with real ECU hardware and\Nsoftware. So let's get started. Cruise Dialogue: 0,0:29:14.22,0:29:17.89,Default,,0000,0000,0000,,control is very simple: When a human is\Ncontrolling the throttle with the Dialogue: 0,0:29:17.89,0:29:24.82,Default,,0000,0000,0000,,accelerator pedal depending on the skill\Nthe car may have an uneven speed. What we Dialogue: 0,0:29:24.82,0:29:28.82,Default,,0000,0000,0000,,want is an ECU that optimizes the control\Nof the throttle so that we can maintain a Dialogue: 0,0:29:28.82,0:29:37.31,Default,,0000,0000,0000,,steady speed. An automatic car can be very\Neasy to model. If you press the Dialogue: 0,0:29:37.31,0:29:41.35,Default,,0000,0000,0000,,accelerator pedal, which opens the\Nthrottle, you will get speed out of your Dialogue: 0,0:29:41.35,0:29:45.59,Default,,0000,0000,0000,,car. But the relationship between speed\Nand throttle is not as simple as a Dialogue: 0,0:29:45.59,0:29:50.48,Default,,0000,0000,0000,,multiplication. No, we have to follow the\Nlaws of dynamics. In this case that's the Dialogue: 0,0:29:50.48,0:29:56.76,Default,,0000,0000,0000,,sum of forces on the car is equal to its\Nmass times its acceleration. We can Dialogue: 0,0:29:56.76,0:30:00.64,Default,,0000,0000,0000,,consider that there is a force pushing the\Ncar that is proportional to the throttle, Dialogue: 0,0:30:00.64,0:30:06.14,Default,,0000,0000,0000,,and that there is an opposing force\Nproportional to the speed due to friction. Dialogue: 0,0:30:06.14,0:30:12.11,Default,,0000,0000,0000,,When we solve this diversal equation, what we\Nexpect to see is that the speed follows an Dialogue: 0,0:30:12.11,0:30:17.99,Default,,0000,0000,0000,,exponential curve. And a simple way to\Ncontrol the speed that may come to your Dialogue: 0,0:30:17.99,0:30:22.24,Default,,0000,0000,0000,,mind is open loop control. You make some\Nmeasurements on the flat road of the Dialogue: 0,0:30:22.24,0:30:26.86,Default,,0000,0000,0000,,relationship between throttle and maximum\Nspeed, and you keep in a lookup table. Dialogue: 0,0:30:26.86,0:30:31.38,Default,,0000,0000,0000,,When the user asks the ECU to reach a\Ncertain speed, the ECU can use the lookup Dialogue: 0,0:30:31.38,0:30:38.25,Default,,0000,0000,0000,,table to find what throttle controls\Nshould be applied based on past Dialogue: 0,0:30:38.25,0:30:43.33,Default,,0000,0000,0000,,measurements. And this may work in some\Nsituations, but according to the laws of Dialogue: 0,0:30:43.33,0:30:51.17,Default,,0000,0000,0000,,dynamics, as soon as we reach an upward\Nslope, the car will lose speed because of Dialogue: 0,0:30:51.17,0:30:56.42,Default,,0000,0000,0000,,gravity. So at least that is what we\Nexpect, but we should verify that on the Dialogue: 0,0:30:56.42,0:31:02.23,Default,,0000,0000,0000,,CAN bus. This is something we can use RAMN\Nfor. Here again, using an external CAN Dialogue: 0,0:31:02.23,0:31:07.98,Default,,0000,0000,0000,,adapter connected to a second PC. On that\NPC I simply receive data from the physical Dialogue: 0,0:31:07.98,0:31:13.14,Default,,0000,0000,0000,,CAN bus. For the rest of the section I\Nwill only be modifying the firmware on the Dialogue: 0,0:31:13.14,0:31:25.56,Default,,0000,0000,0000,,power train ECU. I will not change the\Nsimulator, I will not even reboot it. Dialogue: 0,0:31:25.56,0:31:30.61,Default,,0000,0000,0000,,So in the simulator, I drove around the city\Nto try to find a nice place to experiment. Dialogue: 0,0:31:30.61,0:31:40.28,Default,,0000,0000,0000,,More precisely, I looked for a place with\Nflat road followed by an upward slope. Dialogue: 0,0:31:40.28,0:31:44.07,Default,,0000,0000,0000,,Then I programmed the power train ECU to a\Napply a constant throttle, which is only Dialogue: 0,0:31:44.07,0:31:49.22,Default,,0000,0000,0000,,one line of code. And after reprogramming\Nthe ECU I let the car drive straight and I Dialogue: 0,0:31:49.22,0:32:08.22,Default,,0000,0000,0000,,recorded data from the CAN bus. I used an\Nopen source tool for CAN bus analysis Dialogue: 0,0:32:08.22,0:32:14.04,Default,,0000,0000,0000,,called Bus Master. Bus Master allows you\Nto load DBC files or to input manually the Dialogue: 0,0:32:14.04,0:32:18.77,Default,,0000,0000,0000,,format of your CAN frames. Here I simply\Ntold Bus Master what were the CAN Dialogue: 0,0:32:18.77,0:32:24.01,Default,,0000,0000,0000,,arbitration IDs of the throttle control\Nmessage and the speed sensor message. And Dialogue: 0,0:32:24.01,0:32:30.11,Default,,0000,0000,0000,,what was the format of the payload. Once I\Ndo that, I can plot the evolution of the Dialogue: 0,0:32:30.11,0:32:36.19,Default,,0000,0000,0000,,throttle and speed over time. And the\Nresults we get are exactly what we Dialogue: 0,0:32:36.19,0:32:40.81,Default,,0000,0000,0000,,expected from our differential equations.\NThe speed of the vehicle is following an Dialogue: 0,0:32:40.81,0:32:44.38,Default,,0000,0000,0000,,exponential curve and as soon as we reach\Nthe upward slope, we start loosing speed Dialogue: 0,0:32:44.38,0:32:49.22,Default,,0000,0000,0000,,because the throttle is constant. There\Nare some noise and non-linearities at low Dialogue: 0,0:32:49.22,0:32:54.27,Default,,0000,0000,0000,,speed but overall it seems our model of\Nthe car is correct. We are approaching the Dialogue: 0,0:32:54.27,0:33:01.32,Default,,0000,0000,0000,,problem correctly. What we can see here is\Nthat it takes about 40 seconds for one Dialogue: 0,0:33:01.32,0:33:06.40,Default,,0000,0000,0000,,test-drive. And 40 seconds is already too\Nlong. So before testing the ECU in the Dialogue: 0,0:33:06.40,0:33:09.89,Default,,0000,0000,0000,,driving simulator, we want to use the\Nsoftware that can simulate differential Dialogue: 0,0:33:09.89,0:33:13.79,Default,,0000,0000,0000,,equations so that we can see the impact of\Nthe cruise control algorithm directly, Dialogue: 0,0:33:13.79,0:33:18.96,Default,,0000,0000,0000,,without having to wait for 40 seconds.\NMost of the time this is done using a Dialogue: 0,0:33:18.96,0:33:25.33,Default,,0000,0000,0000,,professional tool such as Matlab and\NSimulink. But here we will use open source Dialogue: 0,0:33:25.33,0:33:30.46,Default,,0000,0000,0000,,tool Scilab. It has a graphical interface\Nwhere we can connect inputs and outputs Dialogue: 0,0:33:30.46,0:33:37.23,Default,,0000,0000,0000,,from a block diagram. Differential\Nequations are a bit hard to deal with Dialogue: 0,0:33:37.23,0:33:41.12,Default,,0000,0000,0000,,because the relationship between inputs\Nand outputs is complicated. What you Dialogue: 0,0:33:41.12,0:33:45.64,Default,,0000,0000,0000,,typically do in control theory is use a\NLaplace transform, which will change the Dialogue: 0,0:33:45.64,0:33:50.59,Default,,0000,0000,0000,,variable called t to a complex number\Ncalled s. This may be complicated with a Dialogue: 0,0:33:50.59,0:33:53.98,Default,,0000,0000,0000,,contradictory background, but you just\Nneed to know that a differentiation is Dialogue: 0,0:33:53.98,0:33:58.68,Default,,0000,0000,0000,,equivalent to a multiplication by s and\Nthat integration is equivalent to division Dialogue: 0,0:33:58.68,0:34:05.30,Default,,0000,0000,0000,,by s. In our system it is easier to model\Nthe Laplace transform because we now have Dialogue: 0,0:34:05.30,0:34:09.73,Default,,0000,0000,0000,,a simple relationship between throttle and\Nspeed. Speed equals transfer function of Dialogue: 0,0:34:09.73,0:34:18.20,Default,,0000,0000,0000,,car times throttle. And based on the\Nmeasurements from the CAN bus, we can Dialogue: 0,0:34:18.20,0:34:25.76,Default,,0000,0000,0000,,evaluate the transfer function of the car\Nto be equal to approximately 1 / (1 + 4s). Dialogue: 0,0:34:25.76,0:34:30.30,Default,,0000,0000,0000,,We can simulate the car in Scilab by\Nusing a block function which has the exact Dialogue: 0,0:34:30.30,0:34:36.96,Default,,0000,0000,0000,,same transfer function. Using Scilab, we\Ncan now test various scenarios and get the Dialogue: 0,0:34:36.96,0:34:41.39,Default,,0000,0000,0000,,results immediately. Here I am testing the\Nscenario in which we start from zero Dialogue: 0,0:34:41.39,0:34:46.76,Default,,0000,0000,0000,,speed, apply a constant throttle and after\N20 seconds, we add a new force - gravity - Dialogue: 0,0:34:46.76,0:34:52.95,Default,,0000,0000,0000,,which corresponds to the slope. And this\Nis what we call here the disturbance. And Dialogue: 0,0:34:52.95,0:34:57.49,Default,,0000,0000,0000,,with Scilab simulation we can verify we\Nget waveforms similar to our measurements Dialogue: 0,0:34:57.49,0:35:01.52,Default,,0000,0000,0000,,on the CAN bus. With a constant throttle,\Nthe speed follows an exponential curve Dialogue: 0,0:35:01.52,0:35:07.99,Default,,0000,0000,0000,,that is close to maximum speed after\Naround 14 seconds. And as soon as there is Dialogue: 0,0:35:07.99,0:35:11.84,Default,,0000,0000,0000,,a disturbance: the gravity here, showing\Ngreen, we can check that the car looses Dialogue: 0,0:35:11.84,0:35:18.39,Default,,0000,0000,0000,,speed because there is no reaction from\Nthe throttle. So to fix that the solution Dialogue: 0,0:35:18.39,0:35:24.74,Default,,0000,0000,0000,,is obvious: The ECUs need to have\Nfeedback. We need the ECU to make use of Dialogue: 0,0:35:24.74,0:35:29.67,Default,,0000,0000,0000,,the speed sensor data that it can find on\Nthe CAN bus so that it can adapt the Dialogue: 0,0:35:29.67,0:35:35.48,Default,,0000,0000,0000,,throttle to the actual speed of the\Nvehicle. So first solution that may come Dialogue: 0,0:35:35.48,0:35:40.16,Default,,0000,0000,0000,,to mind to software engineers is Bang-Bang\NControl. Bang-Bang Control is quite Dialogue: 0,0:35:40.16,0:35:45.46,Default,,0000,0000,0000,,simple. You measure the speed and if it is\Nabove a certain threshold, you stop Dialogue: 0,0:35:45.46,0:35:49.73,Default,,0000,0000,0000,,applying the throttle. If it goes below a\Ncertain threshold, you apply the throttle Dialogue: 0,0:35:49.73,0:35:58.62,Default,,0000,0000,0000,,again. This is extremely easy to implement\Nin C on the ECU. And once we reprogram the Dialogue: 0,0:35:58.62,0:36:03.01,Default,,0000,0000,0000,,ECU on RAMN, we can make measurements on\Nthe CAN bus and verify that this time we Dialogue: 0,0:36:03.01,0:36:09.05,Default,,0000,0000,0000,,are not loosing speed anymore when we\Nreach a slope. But as you can see, there Dialogue: 0,0:36:09.05,0:36:13.80,Default,,0000,0000,0000,,are some oscillations. And as you can\Nimagine, the oscillations are not Dialogue: 0,0:36:13.80,0:36:18.43,Default,,0000,0000,0000,,something very nice for passengers.\NApparently people driving like this is the Dialogue: 0,0:36:18.43,0:36:22.89,Default,,0000,0000,0000,,reason cruise control was invented. I do\Nnot know if that story is true, but I can Dialogue: 0,0:36:22.89,0:36:27.71,Default,,0000,0000,0000,,believe it. So Bang-Bang Control made a\Ngood start, but it is not good enough for Dialogue: 0,0:36:27.71,0:36:35.66,Default,,0000,0000,0000,,cruise control. And the most famous\Nalgorithm used in control theory is the Dialogue: 0,0:36:35.66,0:36:40.28,Default,,0000,0000,0000,,PID controller. You can find a lot of\Nresources online. The PID controller is Dialogue: 0,0:36:40.28,0:36:44.83,Default,,0000,0000,0000,,one of the control mechanism used in\Nsoftware of the self-driving AI of CARLA. Dialogue: 0,0:36:44.83,0:36:48.96,Default,,0000,0000,0000,,In the PID controller you measure the\Ndifference between the target speed and Dialogue: 0,0:36:48.96,0:36:54.85,Default,,0000,0000,0000,,the current speed. You call that different\Nerror and you can control the throttle Dialogue: 0,0:36:54.85,0:36:59.80,Default,,0000,0000,0000,,using the sum of 3 control blocks. The\Nerror multiplied by Kₚ. The integral of Dialogue: 0,0:36:59.80,0:37:05.74,Default,,0000,0000,0000,,the error multiplied by Kᵢ and the\Nderivative of the error multiplied by Kd. Dialogue: 0,0:37:05.74,0:37:17.10,Default,,0000,0000,0000,,Kₚ, Kᵢ and Kd are constant called gains.\NAnd you need to have a very fine tuning of Dialogue: 0,0:37:17.10,0:37:22.14,Default,,0000,0000,0000,,those gains to achieve optimal control.\NHere I can simulate the PID controller Dialogue: 0,0:37:22.14,0:37:27.29,Default,,0000,0000,0000,,using Scilab with different blocks.\NRemember that the division by s is an Dialogue: 0,0:37:27.29,0:37:32.87,Default,,0000,0000,0000,,integration, and the multiplication by s\Nis a derivation. Thanks to the simulation Dialogue: 0,0:37:32.87,0:37:37.55,Default,,0000,0000,0000,,I am able to try many values without\Nhaving to actually drive the car. And when Dialogue: 0,0:37:37.55,0:37:47.75,Default,,0000,0000,0000,,we are able to find correct values for the\NPID controller, we get this. The ECU is Dialogue: 0,0:37:47.75,0:37:51.24,Default,,0000,0000,0000,,able to reach a target quite quickly\Nwithout oscillations and without Dialogue: 0,0:37:51.24,0:37:57.56,Default,,0000,0000,0000,,overshooting the maximum speed. And when\Nthere is a disturbance so gravity, it will Dialogue: 0,0:37:57.56,0:38:02.00,Default,,0000,0000,0000,,dynamically adapt the controls of the\Nthrottle so that the target speed is Dialogue: 0,0:38:02.00,0:38:07.83,Default,,0000,0000,0000,,maintained. So this is good, because this\Nis what we want for cruise control. But is Dialogue: 0,0:38:07.83,0:38:13.04,Default,,0000,0000,0000,,a gain of only one control block is\Ncorrect, the speed of the vehicle may look Dialogue: 0,0:38:13.04,0:38:16.54,Default,,0000,0000,0000,,like something totally different,\Npotentially dangerous. And this is why the Dialogue: 0,0:38:16.54,0:38:21.19,Default,,0000,0000,0000,,integrity of calibration data is important\Nnot only from a safety point of view, but Dialogue: 0,0:38:21.19,0:38:25.23,Default,,0000,0000,0000,,also from a security point of view.\NBecause an attacker should not be able to Dialogue: 0,0:38:25.23,0:38:37.11,Default,,0000,0000,0000,,make an ECU have a dangerous behavior with\Nonly one small change. The last thing I Dialogue: 0,0:38:37.11,0:38:41.12,Default,,0000,0000,0000,,need to explain is how to implement these\Nalgorithms in C, and this is not obvious Dialogue: 0,0:38:41.12,0:38:45.47,Default,,0000,0000,0000,,because we're dealing with integration and\Nderivations, which are not possible for Dialogue: 0,0:38:45.47,0:38:51.19,Default,,0000,0000,0000,,digital functions. So there are many ways\Nto implement this in a digital PID Dialogue: 0,0:38:51.19,0:38:58.11,Default,,0000,0000,0000,,controller in C. I will just explain two\Napproaches. The first approach is to stay Dialogue: 0,0:38:58.11,0:39:02.32,Default,,0000,0000,0000,,in the time domain and approximate the\Nderivation by the difference between two Dialogue: 0,0:39:02.32,0:39:07.40,Default,,0000,0000,0000,,successive errors divided by the sampling\Ntime. And we can approximate the integral Dialogue: 0,0:39:07.40,0:39:14.93,Default,,0000,0000,0000,,operation with a Riemann sum which is a\Nrunning sum of errors so far multiplied by Dialogue: 0,0:39:14.93,0:39:20.94,Default,,0000,0000,0000,,the sampling time. This may look a bit\Nintimidating, but when you look at it Dialogue: 0,0:39:20.94,0:39:25.19,Default,,0000,0000,0000,,closely, you can see it is just a\Ncombination of constants and values that Dialogue: 0,0:39:25.19,0:39:33.40,Default,,0000,0000,0000,,can be computed from current and past\Nsensor values from the CAN bus. The actual Dialogue: 0,0:39:33.40,0:39:39.38,Default,,0000,0000,0000,,implementation in C looks like this. We\Nneed to define 2 variables. One to store Dialogue: 0,0:39:39.38,0:39:45.63,Default,,0000,0000,0000,,the running sum of errors and one to store\Nthe error of the previous control loop Dialogue: 0,0:39:45.63,0:39:51.28,Default,,0000,0000,0000,,execution. In the control loop, we define\Nconstant gains for each stage. We compute Dialogue: 0,0:39:51.28,0:40:00.12,Default,,0000,0000,0000,,the current error. We add the error to the\Nsum of all errors. We compute the Dialogue: 0,0:40:00.12,0:40:05.45,Default,,0000,0000,0000,,difference between current errors and\Nprevious error. We then add all those Dialogue: 0,0:40:05.45,0:40:10.42,Default,,0000,0000,0000,,values with the respective gain to the\Noutput variable and then we clamp that Dialogue: 0,0:40:10.42,0:40:16.73,Default,,0000,0000,0000,,output in case it goes out of bound. We\Nthen apply the throttle control and save Dialogue: 0,0:40:16.73,0:40:24.78,Default,,0000,0000,0000,,the current error in the previous error\Nvariable for use in the next iteration. Dialogue: 0,0:40:24.78,0:40:30.85,Default,,0000,0000,0000,,The second approach is to use a Laplace\Ntransform of the PID controller. We first Dialogue: 0,0:40:30.85,0:40:34.93,Default,,0000,0000,0000,,need to convert it to a Z transform, the\Nequivalent of Laplace transform but for Dialogue: 0,0:40:34.93,0:40:38.97,Default,,0000,0000,0000,,digital signals. It looks a bit\Ncomplicated, but there are many tools to Dialogue: 0,0:40:38.97,0:40:44.37,Default,,0000,0000,0000,,do the conversion for you. If you want to\Ndo the conversion by hand, one way is to Dialogue: 0,0:40:44.37,0:40:55.06,Default,,0000,0000,0000,,use the bilinear transformation in which\Nyou replace s by this, to approximate the Z Dialogue: 0,0:40:55.06,0:41:06.53,Default,,0000,0000,0000,,transform of your ECU. And again, this may\Nall look a bit intimidating, but you can Dialogue: 0,0:41:06.53,0:41:10.95,Default,,0000,0000,0000,,actually compute the throttle output by\Nusing the throttle output from 2 Dialogue: 0,0:41:10.95,0:41:16.79,Default,,0000,0000,0000,,iterations ago, the current error, the\Nprevious error and the error before that Dialogue: 0,0:41:16.79,0:41:21.23,Default,,0000,0000,0000,,which can all be computed from sensor\Nvalues on the CAN bus. And while this Dialogue: 0,0:41:21.23,0:41:26.16,Default,,0000,0000,0000,,control algorithm is equivalent to our\Nprevious implementation, it looks totally Dialogue: 0,0:41:26.16,0:41:32.13,Default,,0000,0000,0000,,different. And what I would like to stress\Nhere that identical control algorithms may Dialogue: 0,0:41:32.13,0:41:35.96,Default,,0000,0000,0000,,have very different software\Nimplementations, which may be relevant for Dialogue: 0,0:41:35.96,0:41:47.86,Default,,0000,0000,0000,,reverse engineers. I only show the first\Nimplementation not waste time, but you can Dialogue: 0,0:41:47.86,0:41:52.59,Default,,0000,0000,0000,,see now that the ECU in RAMN is able to\Nmake the car maintain a constant speed and Dialogue: 0,0:41:52.59,0:42:05.27,Default,,0000,0000,0000,,for dynamic control of the throttle. So\Nthat's it for the example. I just wanted Dialogue: 0,0:42:05.27,0:42:08.88,Default,,0000,0000,0000,,to show that RAMN can be used for\Nrealistic activities of the CAN bus and Dialogue: 0,0:42:08.88,0:42:14.43,Default,,0000,0000,0000,,that the ECUs are not just doing some\Nrandom easy work. The control theory part Dialogue: 0,0:42:14.43,0:42:18.46,Default,,0000,0000,0000,,may be complicated and if that was going\Ntoo fast for you at least I hope it proves Dialogue: 0,0:42:18.46,0:42:22.27,Default,,0000,0000,0000,,there is a lot of things to discover and\Nexperiment with. And that all that Dialogue: 0,0:42:22.27,0:42:37.42,Default,,0000,0000,0000,,learning can be done with open source\Ntools. Now I would like to discuss what Dialogue: 0,0:42:37.42,0:42:41.43,Default,,0000,0000,0000,,would have been different with real ECUs\Nbecause, as you can imagine, actual ECU Dialogue: 0,0:42:41.43,0:42:47.28,Default,,0000,0000,0000,,software is not as simple as this. I will\Nalso show you what alternatives we have. Dialogue: 0,0:42:47.28,0:42:53.12,Default,,0000,0000,0000,,Technologies hidden behind NDAs, so that\Nwe can get as close as we can to real Dialogue: 0,0:42:53.12,0:42:59.63,Default,,0000,0000,0000,,ECUs. We showed in RAMN that this cruise\Ncontrol ECU worked, but we only tried it Dialogue: 0,0:42:59.63,0:43:06.03,Default,,0000,0000,0000,,on a single scenario, namely a flat road\Nfollowed by an upward slope. But what Dialogue: 0,0:43:06.03,0:43:09.97,Default,,0000,0000,0000,,about this scenario in which a car in\Nfront is driving slowly? Or what about a Dialogue: 0,0:43:09.97,0:43:14.62,Default,,0000,0000,0000,,scenario in which we are in a downward\Nslope? In this case the ECU will not be Dialogue: 0,0:43:14.62,0:43:18.39,Default,,0000,0000,0000,,able to prevent a car from going too fast\Nbecause it does not have access to the Dialogue: 0,0:43:18.39,0:43:24.75,Default,,0000,0000,0000,,brakes, which could lead to an accident.\NAnd the difficult problem here is not Dialogue: 0,0:43:24.75,0:43:29.11,Default,,0000,0000,0000,,whether you can think of one more\Nscenario. The difficult problem is can you Dialogue: 0,0:43:29.11,0:43:34.43,Default,,0000,0000,0000,,think of them all are you sure? And\Nthinking of all potential scenarios, Dialogue: 0,0:43:34.43,0:43:38.43,Default,,0000,0000,0000,,quantifying the risk and implementing\Ncountermeasures is what makes automotive Dialogue: 0,0:43:38.43,0:43:46.97,Default,,0000,0000,0000,,systems really different. And to prove\Nthat an ECU is reasonably safe, you Dialogue: 0,0:43:46.97,0:43:52.57,Default,,0000,0000,0000,,actually need to follow ISO 26262\Nstandard, which is a standard for Dialogue: 0,0:43:52.57,0:43:58.74,Default,,0000,0000,0000,,functional safety. The standard defines\Ndifferent requirements at many levels. Not Dialogue: 0,0:43:58.74,0:44:03.48,Default,,0000,0000,0000,,all ECUs are equally critical, so safety\Nrelevant issues are assigned and Dialogue: 0,0:44:03.48,0:44:10.35,Default,,0000,0000,0000,,automotive safety integrity level or ASIL\Nfor short. And ASIL A is a less critical Dialogue: 0,0:44:10.35,0:44:17.37,Default,,0000,0000,0000,,level and ASIL D is the most critical\Nlevel. So if you were to design a real Dialogue: 0,0:44:17.37,0:44:21.33,Default,,0000,0000,0000,,cruise control ECU for use in a real car,\Nyou could not just connect some random ECU Dialogue: 0,0:44:21.33,0:44:25.86,Default,,0000,0000,0000,,to the CAN bus and try it on the highway.\NYou will need to go through a lot of Dialogue: 0,0:44:25.86,0:44:32.01,Default,,0000,0000,0000,,analysis, such as HAZOP, HARA, FMEA, STPA\Nand so on. Usually there are so many Dialogue: 0,0:44:32.01,0:44:36.89,Default,,0000,0000,0000,,requirements that they cannot be tracked\Nwith only a human and a sheet of paper. Dialogue: 0,0:44:36.89,0:44:46.25,Default,,0000,0000,0000,,They are managed using dedicated tools\Nsuch as Rational Doors. Now let's discuss Dialogue: 0,0:44:46.25,0:44:50.70,Default,,0000,0000,0000,,how the software would be different. The\Nmain contribution of automotive software Dialogue: 0,0:44:50.70,0:44:55.41,Default,,0000,0000,0000,,is to realize control algorithms safely.\NBut without countermeasures, many things Dialogue: 0,0:44:55.41,0:45:01.12,Default,,0000,0000,0000,,could go wrong. For example there could be\Nbugs in the ECU application code. And then Dialogue: 0,0:45:01.12,0:45:04.59,Default,,0000,0000,0000,,without any bug the software will be\Nrobust enough when there are transient Dialogue: 0,0:45:04.59,0:45:11.76,Default,,0000,0000,0000,,errors in the hardware. There could also\Nbe problems with the toolchains that Dialogue: 0,0:45:11.76,0:45:24.21,Default,,0000,0000,0000,,compile the firmware and problems with the\Nlibraries and RTOS. And when we have a Dialogue: 0,0:45:24.21,0:45:28.36,Default,,0000,0000,0000,,close look at the PID controller\Nimplementation which seemed good enough in Dialogue: 0,0:45:28.36,0:45:32.74,Default,,0000,0000,0000,,our testing, you can see it is actually a\Nterrible implementation. We are mixing Dialogue: 0,0:45:32.74,0:45:37.68,Default,,0000,0000,0000,,integers and unsigned integers and floats\Nwithout proper checks and type casting. We Dialogue: 0,0:45:37.68,0:45:45.41,Default,,0000,0000,0000,,are not checking for overflows and also\Nrandom software issues. And this is not Dialogue: 0,0:45:45.41,0:45:48.67,Default,,0000,0000,0000,,acceptable, both for safety and security.\NAnd in this case, the problems were Dialogue: 0,0:45:48.67,0:45:52.07,Default,,0000,0000,0000,,obvious on purpose, but sometimes it can\Nbe very hard to spot because they stem Dialogue: 0,0:45:52.07,0:45:58.83,Default,,0000,0000,0000,,from very subtle computing issues. And\Nthose issues may lead to system failures. Dialogue: 0,0:45:58.83,0:46:03.44,Default,,0000,0000,0000,,So to avoid such scenarios, the automotive\Nindustry usually mandates the use of a Dialogue: 0,0:46:03.44,0:46:07.94,Default,,0000,0000,0000,,language subset which restricts what\Ndevelopers can do, but makes sure that Dialogue: 0,0:46:07.94,0:46:15.85,Default,,0000,0000,0000,,numerical errors are less likely to\Nhappen. So usually in the automotive Dialogue: 0,0:46:15.85,0:46:22.09,Default,,0000,0000,0000,,industry, the standard that is used is\NMISRA-C and it is very similar to CERT-C, Dialogue: 0,0:46:22.09,0:46:30.60,Default,,0000,0000,0000,,which is popular in the security industry.\NUsing a language subset is only one of the Dialogue: 0,0:46:30.60,0:46:36.12,Default,,0000,0000,0000,,requirements that are dictated by ISO\N26262. There are many other requirements. Dialogue: 0,0:46:36.12,0:46:40.93,Default,,0000,0000,0000,,At a high level they try to enforce a low\Ncomplexity of the software. For example, Dialogue: 0,0:46:40.93,0:46:45.81,Default,,0000,0000,0000,,by restricting the size of components,\Nrestricting the copying between software Dialogue: 0,0:46:45.81,0:46:51.15,Default,,0000,0000,0000,,components and making sure the scheduling\Nis appropriate. And that there are not too Dialogue: 0,0:46:51.15,0:46:55.33,Default,,0000,0000,0000,,many interrupts. But we also have more\Nconcrete requirements, such as restricting Dialogue: 0,0:46:55.33,0:46:59.41,Default,,0000,0000,0000,,functions to 1 entry and 1 exit point,\Nforbid dynamic memory, avoid global Dialogue: 0,0:46:59.41,0:47:07.67,Default,,0000,0000,0000,,variables, limit the use of pointers and\Nso on. The other issues we have to deal Dialogue: 0,0:47:07.67,0:47:11.83,Default,,0000,0000,0000,,with, which is riddled with bugs is\Ntransient errors. In the harsh Dialogue: 0,0:47:11.83,0:47:16.38,Default,,0000,0000,0000,,environment, data is not always reliable.\NThere may be a bit flip occurring outside Dialogue: 0,0:47:16.38,0:47:22.89,Default,,0000,0000,0000,,of memory, for example, because of noise\Nand communication lines, but also may be Dialogue: 0,0:47:22.89,0:47:26.59,Default,,0000,0000,0000,,bit flips occurring inside a microcontrollers\Nmemory. For example, because of cosmic Dialogue: 0,0:47:26.59,0:47:31.95,Default,,0000,0000,0000,,rays. Those issues do not originate from\Nsoftware, they originate from hardware, Dialogue: 0,0:47:31.95,0:47:35.67,Default,,0000,0000,0000,,but they do need to be addressed by\Nsoftware because remember, in the case of Dialogue: 0,0:47:35.67,0:47:41.31,Default,,0000,0000,0000,,the example cruise control ECU, just one\Nbit flip could lead to unwanted behavior of Dialogue: 0,0:47:41.31,0:47:47.40,Default,,0000,0000,0000,,the ECU and the car. So to address those\Nissues, automotive controllers need Dialogue: 0,0:47:47.40,0:47:52.00,Default,,0000,0000,0000,,special countermeasures. For example\Nhaving redundant memory or having Dialogue: 0,0:47:52.00,0:48:00.08,Default,,0000,0000,0000,,redundant CPUs. In ECUs, you will\Ntypically find microcontrollers that have Dialogue: 0,0:48:00.08,0:48:04.29,Default,,0000,0000,0000,,been designed specially for automotive\Nuse. All those microcontrollers require Dialogue: 0,0:48:04.29,0:48:09.24,Default,,0000,0000,0000,,you to sign an NDA so you can not just buy\Nthem and start programming them. So that Dialogue: 0,0:48:09.24,0:48:15.92,Default,,0000,0000,0000,,makes it a bit hard to study an actual ECU\Nmicrocontroller and real automotive Dialogue: 0,0:48:15.92,0:48:23.12,Default,,0000,0000,0000,,software. ISO 26262 is not the only\Nstandard for safety critical systems. ISO Dialogue: 0,0:48:23.12,0:48:29.92,Default,,0000,0000,0000,,26262 is actually derived from IEC 61508,\Nso they are both similar in their Dialogue: 0,0:48:29.92,0:48:35.75,Default,,0000,0000,0000,,concepts. And IEC61508 microcontrollers\Nthey do not require NDAs for most other Dialogue: 0,0:48:35.75,0:48:42.34,Default,,0000,0000,0000,,activities you may be interested in. And\Nmore completely RAMN can be used with Dialogue: 0,0:48:42.34,0:48:47.42,Default,,0000,0000,0000,,STM32L4 or STM32L5 microcontrollers. And\Nfor those microcontrollers, you do not Dialogue: 0,0:48:47.42,0:48:52.65,Default,,0000,0000,0000,,need an NDA to download guidelines on how\Nto implement safe software. For example, Dialogue: 0,0:48:52.65,0:48:56.24,Default,,0000,0000,0000,,you can find a list of features that are\Nrequired for safety applications, and you Dialogue: 0,0:48:56.24,0:49:00.70,Default,,0000,0000,0000,,can request more data that you would need\Nto actually achieve compliance with Dialogue: 0,0:49:00.70,0:49:07.40,Default,,0000,0000,0000,,IEC 61508, such as the FMEA and FMEDA. But to\Nobtain those data, you would need to sign an Dialogue: 0,0:49:07.40,0:49:13.33,Default,,0000,0000,0000,,NDA. No, I personally do not think that\Nthose data are essential for education and Dialogue: 0,0:49:13.33,0:49:19.67,Default,,0000,0000,0000,,research. So using such microcontrollers\Nis a good alternative. But again, let me Dialogue: 0,0:49:19.67,0:49:23.30,Default,,0000,0000,0000,,stress that this is an alternative for\Nlearning and researching, not for actual Dialogue: 0,0:49:23.30,0:49:28.66,Default,,0000,0000,0000,,use in a car. I don't have time to detail\Nall the safety features, let me just talk Dialogue: 0,0:49:28.66,0:49:35.22,Default,,0000,0000,0000,,about memory redundancy, since this one\Nimpacts the code of the application of the Dialogue: 0,0:49:35.22,0:49:42.15,Default,,0000,0000,0000,,example cruise control ECU. So in the\Nexample, we wrote the gain of each stage Dialogue: 0,0:49:42.15,0:49:47.39,Default,,0000,0000,0000,,in code memory defining them as constants.\NFor safer applications, this would not be Dialogue: 0,0:49:47.39,0:49:53.29,Default,,0000,0000,0000,,here. They belong to another section, the\Ndata flash where ECC protection can be Dialogue: 0,0:49:53.29,0:49:57.92,Default,,0000,0000,0000,,activated. If possible, calibration data\Nshould be stored twice with checksums and Dialogue: 0,0:49:57.92,0:50:04.30,Default,,0000,0000,0000,,preferably MACs. If you're not familiar\Nwith ECC memory, it is a kind of memory Dialogue: 0,0:50:04.30,0:50:09.35,Default,,0000,0000,0000,,that can detect bit flips and sometimes\Nautomatically corrects them. Another Dialogue: 0,0:50:09.35,0:50:13.48,Default,,0000,0000,0000,,memory is also available for the RAM, \Nbut not at all addresses. So in the Dialogue: 0,0:50:13.48,0:50:17.24,Default,,0000,0000,0000,,application, we have to ensure that safety\Ncritical variables are placed in a section Dialogue: 0,0:50:17.24,0:50:24.52,Default,,0000,0000,0000,,of RAM in which bit flips can be detected,\Nin this case in section SRAM2. For data in Dialogue: 0,0:50:24.52,0:50:30.82,Default,,0000,0000,0000,,RAM that are actually constants such the\Ngains you may also want to activate write Dialogue: 0,0:50:30.82,0:50:36.58,Default,,0000,0000,0000,,protection, a feature that is only\Navailable in SRAM2. Last slide about Dialogue: 0,0:50:36.58,0:50:44.20,Default,,0000,0000,0000,,software. In the example cruise control,\Nwe are using GCC toolchain in ISO 26262 it Dialogue: 0,0:50:44.20,0:50:48.12,Default,,0000,0000,0000,,is a requirement to have what is called a\Ntool confidence lever to ensure that Dialogue: 0,0:50:48.12,0:50:53.19,Default,,0000,0000,0000,,poor chains will not introduce errors as it\Ncould be the case with some optimizations. Dialogue: 0,0:50:53.19,0:50:57.75,Default,,0000,0000,0000,,So normally you cannot use GCC. Realtime\Noperating systems and libraries may also Dialogue: 0,0:50:57.75,0:51:03.10,Default,,0000,0000,0000,,have problems. That is why they need to be\Ncertified. Both STM32-HAL and FreeRTOS are Dialogue: 0,0:51:03.10,0:51:10.80,Default,,0000,0000,0000,,compliant with MISRA-C which is nice, but\Nthey are not compliant with ISO 26262. Dialogue: 0,0:51:10.80,0:51:16.41,Default,,0000,0000,0000,,However, it looks like ST is bringing\NAzure RTOS into the ecosystem and that one Dialogue: 0,0:51:16.41,0:51:24.70,Default,,0000,0000,0000,,is actually precertified ISO 26262. Maybe\Nin the future it would be an option to Dialogue: 0,0:51:24.70,0:51:30.52,Default,,0000,0000,0000,,experiment with with an actual ISO 26262\Noperating system. So now let's talk a bit Dialogue: 0,0:51:30.52,0:51:33.54,Default,,0000,0000,0000,,about hardware. In case it was not clear\Nto you, you cannot use commercial Dialogue: 0,0:51:33.54,0:51:37.70,Default,,0000,0000,0000,,electronics to implement an ECU.\NSmartphone vendors will often warn you not Dialogue: 0,0:51:37.70,0:51:42.50,Default,,0000,0000,0000,,to let a device in your car because a\Nparked car can reach extreme temperatures Dialogue: 0,0:51:42.50,0:51:47.48,Default,,0000,0000,0000,,that commercial electronics are not\Ndesigned to resist. And if you think that Dialogue: 0,0:51:47.48,0:51:52.27,Default,,0000,0000,0000,,the life inside the cabin is hard, you\Nshould think about an ECU which has to Dialogue: 0,0:51:52.27,0:51:56.100,Default,,0000,0000,0000,,stay in the engine compartment and operate\Nwithout failures. And you would not think Dialogue: 0,0:51:56.100,0:52:03.56,Default,,0000,0000,0000,,of putting a smartphone or an Arduino here\Nand trust your life with it. And extreme Dialogue: 0,0:52:03.56,0:52:06.89,Default,,0000,0000,0000,,temperatures are just one of the many\Nenvironmental factors that make it Dialogue: 0,0:52:06.89,0:52:11.29,Default,,0000,0000,0000,,difficult for an ECU to stay reliable. The\NECU also need to resist high humidity, Dialogue: 0,0:52:11.29,0:52:17.86,Default,,0000,0000,0000,,corrosive gases, vibrations, micro cuts,\Nload dumps, electrostatic discharges, Dialogue: 0,0:52:17.86,0:52:27.03,Default,,0000,0000,0000,,electromagnetic noise and so on. And when\Nsubjected to such a harsh environment, Dialogue: 0,0:52:27.03,0:52:30.43,Default,,0000,0000,0000,,many things could go wrong with\Nelectronics. You probably know about Dialogue: 0,0:52:30.43,0:52:35.09,Default,,0000,0000,0000,,corrosion, but many other physical\Nphenomena are at risk of happening to the Dialogue: 0,0:52:35.09,0:52:39.08,Default,,0000,0000,0000,,components. Solder cracs, intermetallic\Ngrowth, whiskers, dendrites, Dialogue: 0,0:52:39.08,0:52:44.67,Default,,0000,0000,0000,,electromigration, etc. For example,\Nwhiskers are metal growing out of Dialogue: 0,0:52:44.67,0:52:48.35,Default,,0000,0000,0000,,electrical components and dendrites are\Nmetals leaving the plus side towards the Dialogue: 0,0:52:48.35,0:52:53.56,Default,,0000,0000,0000,,minus side. And many other phenomena may\Nresult in a dangerous failure. So Dialogue: 0,0:52:53.56,0:52:58.06,Default,,0000,0000,0000,,obviously, ECUs need to be designed to\Nresist harsh environments and have Dialogue: 0,0:52:58.06,0:53:01.78,Default,,0000,0000,0000,,countermeasures against all those\Npotential failures. ECUs need to pass Dialogue: 0,0:53:01.78,0:53:06.19,Default,,0000,0000,0000,,various tests that simulate harsh\Nenvironments. Those tests are usually Dialogue: 0,0:53:06.19,0:53:11.10,Default,,0000,0000,0000,,defined by manufacturers and the test\Nspecifications are not made public. What Dialogue: 0,0:53:11.10,0:53:14.78,Default,,0000,0000,0000,,is made public, however, is the test\Nspecifications for individual electronic Dialogue: 0,0:53:14.78,0:53:20.20,Default,,0000,0000,0000,,components. And those tests are usually\Ndefined by AEC. So the Automotive Dialogue: 0,0:53:20.20,0:53:28.12,Default,,0000,0000,0000,,Electronic Council, and you can have a\Nlook at them online. For RAMN, we tried to Dialogue: 0,0:53:28.12,0:53:32.05,Default,,0000,0000,0000,,follow design guidelines similar to those\Nof real ECUs. But of course, we cannot Dialogue: 0,0:53:32.05,0:53:37.62,Default,,0000,0000,0000,,follow actual rules as it to be much less\Naccessible. Completely, we selected Dialogue: 0,0:53:37.62,0:53:41.57,Default,,0000,0000,0000,,AEC-Q100 grade zero components for\Neverything except connectors and Dialogue: 0,0:53:41.57,0:53:46.34,Default,,0000,0000,0000,,microcontrollers, because those may\Nrequire NDAs or not be easily accessible. Dialogue: 0,0:53:46.34,0:53:51.27,Default,,0000,0000,0000,,Depending on the part reference, ECU\Nmicrocontrollers may be usable from -40 to Dialogue: 0,0:53:51.27,0:53:56.26,Default,,0000,0000,0000,,125°C. RAMN tried to stay close to\Nautomotive grade, but it is still not Dialogue: 0,0:53:56.26,0:53:59.86,Default,,0000,0000,0000,,automotive grade, especially in the\Nreliability department, so it can not be Dialogue: 0,0:53:59.86,0:54:06.29,Default,,0000,0000,0000,,used as a real ECU. As a result, we try to\Nstay close to automotive hardware is to Dialogue: 0,0:54:06.29,0:54:10.46,Default,,0000,0000,0000,,help researchers evaluate the impact of\Nmanufacturing tolerances and environments Dialogue: 0,0:54:10.46,0:54:16.88,Default,,0000,0000,0000,,because remember, manufacturers are making\Nmillions of cars that need to operate on a Dialogue: 0,0:54:16.88,0:54:20.61,Default,,0000,0000,0000,,large temperature range. So if you are\Ndeveloping, for example, a security Dialogue: 0,0:54:20.61,0:54:25.09,Default,,0000,0000,0000,,technology that relies on hardware\Ncharacteristics such as the clocks of the Dialogue: 0,0:54:25.09,0:54:29.87,Default,,0000,0000,0000,,ECUs, you will need to prove that the\Ntechnology works despite manufacturing Dialogue: 0,0:54:29.87,0:54:35.33,Default,,0000,0000,0000,,tolerances and harsh environments. And\Nwith RAMN it is easy to have a large Dialogue: 0,0:54:35.33,0:54:40.50,Default,,0000,0000,0000,,sample of ECU networks and since they are\Nsmall they can easily fit in various Dialogue: 0,0:54:40.50,0:54:46.81,Default,,0000,0000,0000,,testing equipment. And now let's move on\Nto the last section, security. In the Dialogue: 0,0:54:46.81,0:54:51.70,Default,,0000,0000,0000,,automotive industry, we just can not apply\Nthe same reasoning as you do in many other Dialogue: 0,0:54:51.70,0:54:56.60,Default,,0000,0000,0000,,industries. For example, a credit card, if\Nyou detect the temperature is too cold, it Dialogue: 0,0:54:56.60,0:55:01.14,Default,,0000,0000,0000,,may think that it is a tampering attack\Nand decides to shut down because it is not Dialogue: 0,0:55:01.14,0:55:05.72,Default,,0000,0000,0000,,safety critical. On the other hand, the\Ncar needs to start quickly because the Dialogue: 0,0:55:05.72,0:55:12.21,Default,,0000,0000,0000,,user should not be left out in the cold\Nand also credit cards have an expiration Dialogue: 0,0:55:12.21,0:55:16.57,Default,,0000,0000,0000,,date. So they do not need to guarantee\Nsecurity for more than a few years. But Dialogue: 0,0:55:16.57,0:55:21.55,Default,,0000,0000,0000,,cars do not have an expiration date. If\Nthey are well maintained they may be used Dialogue: 0,0:55:21.55,0:55:26.97,Default,,0000,0000,0000,,for several decades and the security\Ntechnologies should keep on working. So in Dialogue: 0,0:55:26.97,0:55:30.53,Default,,0000,0000,0000,,the end, automotive security technologies\Nhave different requirements. Dialogue: 0,0:55:30.53,0:55:34.76,Default,,0000,0000,0000,,Unfortunately, according to past research,\Na security technology is often less Dialogue: 0,0:55:34.76,0:55:39.34,Default,,0000,0000,0000,,reliable when you extend its operating\Ntemperature range and its lifetime. For Dialogue: 0,0:55:39.34,0:55:45.06,Default,,0000,0000,0000,,example, at low temperatures, they may be\Nliable to cold boot attacks. At high Dialogue: 0,0:55:45.06,0:55:50.25,Default,,0000,0000,0000,,temperatures, it has also been shown that\Nelectronics tend to be less reliable Dialogue: 0,0:55:50.25,0:55:53.82,Default,,0000,0000,0000,,concerning glitching attacks and in those\Npapers high-temperature means something Dialogue: 0,0:55:53.82,0:56:01.04,Default,,0000,0000,0000,,like 60 or 100°C, far from the maximum\Ntemperature required for some ECUs. Also, Dialogue: 0,0:56:01.04,0:56:06.36,Default,,0000,0000,0000,,it has been shown that the higher age for\Nelectronics usually results in different Dialogue: 0,0:56:06.36,0:56:13.15,Default,,0000,0000,0000,,security properties. And you may think\Nthat the safety features of automotive Dialogue: 0,0:56:13.15,0:56:17.25,Default,,0000,0000,0000,,microcontrollers would prevent some\Nattacks such as glitching attacks, but it Dialogue: 0,0:56:17.25,0:56:22.12,Default,,0000,0000,0000,,has been shown that ECC memories are also\Nsusceptible to glitching attacks. And that Dialogue: 0,0:56:22.12,0:56:27.55,Default,,0000,0000,0000,,even ISO 26262 ASIL-D microcontrollers,\Nwhich is the highest level of safety may Dialogue: 0,0:56:27.55,0:56:32.04,Default,,0000,0000,0000,,be susceptible to glitching. So safety\Nfeatures often help, but there aren't Dialogue: 0,0:56:32.04,0:56:38.84,Default,,0000,0000,0000,,really enough to ensure security. What is\Nalso different with automotive is that you Dialogue: 0,0:56:38.84,0:56:42.94,Default,,0000,0000,0000,,need to rethink the strategy in case of\Nsecurity problems, for example, with Dialogue: 0,0:56:42.94,0:56:48.00,Default,,0000,0000,0000,,credit cards, it is not uncommon for\Nauthentication to fail randomly. When the Dialogue: 0,0:56:48.00,0:56:54.06,Default,,0000,0000,0000,,credit card fails to work usually you just\Nneed to try it once more and it will Dialogue: 0,0:56:54.06,0:56:59.59,Default,,0000,0000,0000,,probably work and everything stays again.\NNo life is at risk. But the car cannot Dialogue: 0,0:56:59.59,0:57:06.58,Default,,0000,0000,0000,,have the same strategy. If you add\Nauthentication to the brake CAN message Dialogue: 0,0:57:06.58,0:57:10.74,Default,,0000,0000,0000,,and you start receiving break request that\Nfail authentication what should the car Dialogue: 0,0:57:10.74,0:57:18.21,Default,,0000,0000,0000,,really do. Because it may be a cyber\Nattacks, which you want to avoid, but you Dialogue: 0,0:57:18.21,0:57:22.80,Default,,0000,0000,0000,,should not relay out the possibility of a\Nrandom malfunction or a false positive for Dialogue: 0,0:57:22.80,0:57:27.29,Default,,0000,0000,0000,,an intrusion detection system. And by\Nadding complexity into the system, you Dialogue: 0,0:57:27.29,0:57:33.04,Default,,0000,0000,0000,,always increase the odds of a problem. And\Nwhich one would be worse between breaking Dialogue: 0,0:57:33.04,0:57:40.06,Default,,0000,0000,0000,,because of a cyber attack or not breaking\Nbecause of a malfunction? And there is no Dialogue: 0,0:57:40.06,0:57:43.51,Default,,0000,0000,0000,,easy way to answer that question. But what\NI want to stress here is that many Dialogue: 0,0:57:43.51,0:57:47.45,Default,,0000,0000,0000,,security countermeasures that people\Nsuggest for cars such as encrypting the Dialogue: 0,0:57:47.45,0:57:51.80,Default,,0000,0000,0000,,CAN bus, permanently disabling debug ports\Nor obfuscating the firmware, they may not Dialogue: 0,0:57:51.80,0:57:58.24,Default,,0000,0000,0000,,necessarily be the best ideas, because if\Nyou suspect a malfunction with an ECU, you Dialogue: 0,0:57:58.24,0:58:02.84,Default,,0000,0000,0000,,need to investigate the problem seriously\Nbecause it may harm people. You cannot Dialogue: 0,0:58:02.84,0:58:09.60,Default,,0000,0000,0000,,just replace a car as you would with a\Ncredit card or a smartphone. Dialogue: 0,0:58:09.60,0:58:13.78,Default,,0000,0000,0000,,So technologies that can truly take into\Naccount both automotive requirements and Dialogue: 0,0:58:13.78,0:58:17.39,Default,,0000,0000,0000,,security requirements are better. And we\Nshould make sure that education and Dialogue: 0,0:58:17.39,0:58:22.37,Default,,0000,0000,0000,,research in these areas are accessible to\Nmany researchers without NDAs or Dialogue: 0,0:58:22.37,0:58:28.74,Default,,0000,0000,0000,,prohibitive costs. Now, of course, you can\Nuse RAMN to try out different attacks. The Dialogue: 0,0:58:28.74,0:58:32.86,Default,,0000,0000,0000,,first obvious one is to inject CAN\Nmessages to alter the behavior of the car. Dialogue: 0,0:58:32.86,0:58:55.76,Default,,0000,0000,0000,,Here for example the breaks. Another kind\Nof security that I did not mention in this Dialogue: 0,0:58:55.76,0:58:59.53,Default,,0000,0000,0000,,presentation is physical security for\Nsensors and actuators. Here I am Dialogue: 0,0:58:59.53,0:59:02.84,Default,,0000,0000,0000,,demonstrating what happens when it\Novertake the control of the steering wheel Dialogue: 0,0:59:02.84,0:59:08.79,Default,,0000,0000,0000,,actuator. A human will probably break in\Nthis situation. The self driving algorithm Dialogue: 0,0:59:08.79,0:59:13.11,Default,,0000,0000,0000,,in CARLA here does not realize it has lost\Ncontrol of the steering wheel and is still Dialogue: 0,0:59:13.11,0:59:20.35,Default,,0000,0000,0000,,trying to correct the trajectory when a\Nbetter decision would be to stop the car. Dialogue: 0,0:59:20.35,0:59:25.30,Default,,0000,0000,0000,,So this is the end of the presentation. We\Ndeveloped an inexpensive, safe and Dialogue: 0,0:59:25.30,0:59:30.25,Default,,0000,0000,0000,,interactive platform to study and research\Nautomotive systems. The platform is Dialogue: 0,0:59:30.25,0:59:34.65,Default,,0000,0000,0000,,accessible to beginners. It is not\Nautomotive grade, but is close enough for Dialogue: 0,0:59:34.65,0:59:39.33,Default,,0000,0000,0000,,research and educational purposes. The\Nproject is open source and with permissive Dialogue: 0,0:59:39.33,0:59:44.44,Default,,0000,0000,0000,,licenses. If you have questions or ideas,\Ndo not hesitate to contact us, especially Dialogue: 0,0:59:44.44,0:59:49.34,Default,,0000,0000,0000,,if you are involved with education,\Nresearch, training, CTF, etc. And thank Dialogue: 0,0:59:49.34,0:59:57.89,Default,,0000,0000,0000,,you for watching. Dialogue: 0,0:59:57.89,1:00:02.65,Default,,0000,0000,0000,,Herald: Camille, thanks for this\Ncomprehensive talk, this was amazing. We Dialogue: 0,1:00:02.65,1:00:05.84,Default,,0000,0000,0000,,unfortunately don't have much time for\Nthe questions or answers, but there is Dialogue: 0,1:00:05.84,1:00:11.78,Default,,0000,0000,0000,,one question that popped up, which is\Nabout the hardware and your PCB. How did Dialogue: 0,1:00:11.78,1:00:15.86,Default,,0000,0000,0000,,you design it? How much does it cost\Nactually, how can you get hold of that Dialogue: 0,1:00:15.86,1:00:19.85,Default,,0000,0000,0000,,thing?\NCamille: So I designed everything with Dialogue: 0,1:00:19.85,1:00:25.36,Default,,0000,0000,0000,,KiCAD. And I mean, I think a few years ago\Nit was very hard to design hardware, but Dialogue: 0,1:00:25.36,1:00:31.86,Default,,0000,0000,0000,,now you have footprint libraries available\Nonline. It has become very easy. The board Dialogue: 0,1:00:31.86,1:00:37.34,Default,,0000,0000,0000,,was between 50 to 100€ for a quantity of\None. So microcontrollers are obviously the Dialogue: 0,1:00:37.34,1:00:42.88,Default,,0000,0000,0000,,expensive parts and the PCB assembling\Nparts - it is up to the PCB Fabrication Dialogue: 0,1:00:42.88,1:00:49.75,Default,,0000,0000,0000,,Service. If you have questions just ask me\Non GitHub, I would be happy to answer. Dialogue: 0,1:00:49.75,1:00:59.20,Default,,0000,0000,0000,,{\i1}rC3 postroll music{\i0} Dialogue: 0,1:00:59.20,1:01:29.00,Default,,0000,0000,0000,,Subtitles created by c3subtitles.de\Nin the year 2021. Join, and help us!