[00:00.600 --> 00:02.840]  Second, about automotive computer networks.
[00:03.780 --> 00:08.700]  And also, in Area C, we had the previous presenter, Jim, with Hacking Now technology.
[00:08.700 --> 00:12.120]  So if you want to stop by and check some of that out after this, he'll probably be there for a while.
[00:12.780 --> 00:15.200]  So right now, NothingFace and Automotive Networks.
[00:15.220 --> 00:15.480]  Thank you.
[00:21.370 --> 00:22.270]  You guys hear me okay?
[00:24.690 --> 00:28.090]  So, I'm NothingFace, and this is the Automotive Networks.
[00:28.290 --> 00:42.390]  I'll give you a little overview of the presentation, just say a few words about myself, give you an idea of my perspective, on the topics that I'm presenting here, talk a little bit about why any of you in the audience would care about any of this stuff,
[00:42.470 --> 00:45.950]  if you're not familiar with it, what it might be applicable to, things that you do.
[00:46.610 --> 00:53.230]  Give a little background on electronics and automobiles, a little bit of the history, where it is now and where it might be going in the future.
[00:54.750 --> 00:58.610]  Talk quite a bit about OBE2, the On Board Diagnostics 2 Standard.
[00:59.170 --> 01:05.790]  It's pretty much a good state of where the Automotive Electronic Network processes are present day.
[01:06.710 --> 01:12.410]  Talk about the common usage of that, physical and data link, diagnostic modes, and some existing products.
[01:12.870 --> 01:26.150]  Try to talk about that with respect to the OSI model of networking, just to frame it in a more of a computer science type of model that is more translatable to things that people might be more familiar with.
[01:26.630 --> 01:32.730]  And then again, present OpenOtto at the end, some software and hardware I've been working on to implement these protocols.
[01:34.470 --> 01:37.710]  So about myself, educated in electrical and computer engineering.
[01:37.990 --> 01:40.230]  I have experience in hardware and software design.
[01:41.170 --> 01:44.670]  So I'm pretty, you know, academic and professionally experienced in that.
[01:44.810 --> 01:48.090]  But as far as automotive goes, I'm sort of a Saturday afternoon mechanic.
[01:48.430 --> 01:51.090]  You know, I'm not afraid of grease and a wrench, but I'm no mechanical engineer.
[01:51.690 --> 01:53.310]  And I'm also concerned about privacy.
[01:55.830 --> 02:00.370]  So why would anyone in the audience care about the network buses on an automobile?
[02:01.670 --> 02:06.410]  Well, for one, there's a bit of a monopoly as far as the maintenance of automobiles goes.
[02:06.970 --> 02:17.610]  You can very easily buy a service manual that tells you all little details about every mechanical part of the vehicle, every bolt, every nut, you know, the size, the specs, how to torque it all with a great deal of accuracy.
[02:17.610 --> 02:19.990]  But there's very limited information about electronics.
[02:20.150 --> 02:22.810]  As far as the schematics goes, very high level.
[02:22.990 --> 02:25.070]  There's very little protocol information.
[02:25.090 --> 02:30.790]  And there's no source code for the controllers and whatnot on site in automobiles.
[02:30.970 --> 02:44.770]  So as more and more functionality goes inside a black box that's running some sort of microcontroller or microprocessor and is running source code, there's more and more that's outside the realm of, you know, an everyday, you know, automobile owners to get access to and to,
[02:44.910 --> 02:48.710]  you know, tinker with their own vehicle and modify it and maintain it as they see fit.
[02:50.050 --> 03:01.610]  This also has privacy implications, you know, because there's, as there's this black box containing more and more functionality that's not observable by the user, they could very well be doing things that the vehicle owner may not agree with.
[03:01.770 --> 03:02.630]  You know, could it be recording?
[03:02.750 --> 03:04.690]  Could it be transmitting information without you knowing?
[03:04.690 --> 03:10.330]  There's no way to figure that out because there's this black box that's not available to you.
[03:11.210 --> 03:14.270]  And it also makes the vehicle more into the control of the manufacturer.
[03:14.450 --> 03:25.870]  They can set in certain parameters, certain limits where the vehicle is controlled in a way that you don't have, not only you don't have knowledge of how it's controlled, but you don't have the ability to change it to remove the controls or change the control to something you see fit.
[03:26.050 --> 03:33.410]  So sort of giving the manufacturers more additional restrictions that, you know, weren't previously possible with the mechanical systems.
[03:34.910 --> 03:37.650]  So the background of automotive, electronics and automobiles.
[03:38.350 --> 03:43.010]  Under the hood, present state, generally, there's a number of different electronic controllers in the vehicle.
[03:43.270 --> 03:47.570]  Early on, it started with fuel injection, the computers that control fuel injection, fuel mixture and whatnot.
[03:48.370 --> 03:50.430]  Those were the early things to be controlled by microcontrollers.
[03:51.790 --> 04:05.810]  Nowadays, things like analog brake controllers, traction control, airbags, all fairly complex systems with a lot of sensors, a lot of outputs to control, and it's controlled, you know, more and more by software systems running on what are called electronic control units,
[04:05.890 --> 04:07.950]  you know, basically microcontrollers inside the vehicle.
[04:08.190 --> 04:10.390]  There's also user visible systems.
[04:10.390 --> 04:22.910]  Again, more and more, this is becoming controlled by electronics, such as the climate control systems, entertainment, navigations, communications, like cell phone or other types of Bluetooth communication and whatnot.
[04:24.490 --> 04:32.250]  Early on, the standard, the first standard for communicating with vehicles was the onboard diagnostics one standard.
[04:32.570 --> 04:41.230]  It was required by the federal EPA in the United States to maintain certain emission standards that were mandated by law.
[04:41.790 --> 04:51.150]  The standard, the federal law didn't require a particular standard implementation, which allowed each manufacturer to go their own route, which they ended up doing.
[04:51.150 --> 05:01.570]  And there's a plethora of different implementations that if you wanted to work with any particular vehicle, you have to sort of start from scratch to understand the protocol and work with it.
[05:01.690 --> 05:02.790]  They're all very individual.
[05:03.530 --> 05:17.130]  The onboard diagnostics two, which is the current day mandate for vehicles made after 1996, again, is the federal laws in the United States is targeting emissions control systems.
[05:17.130 --> 05:19.830]  There's similar laws, like in Europe, there's an EOBD standard.
[05:20.150 --> 05:23.990]  In Japan and East Asia, there's other similar standards that require similar things.
[05:24.690 --> 05:43.090]  The United States standard is written by the SAE, Society of Automotive Engineers, and that specifies what these networks need to do, the standards they need to adhere to as far as interfacing and protocols and whatnot, so that it's easy to make interoperable equipment.
[05:45.210 --> 05:49.190]  So the scope of OBD2, it covers a physical connector.
[05:49.370 --> 05:52.750]  There's a 16-pin connector in the vehicle.
[05:52.890 --> 05:54.690]  It has to be a certain place within the driver's seat.
[05:56.070 --> 05:57.210]  There's a data link layer.
[05:57.330 --> 05:58.190]  There's three options.
[05:58.230 --> 05:59.490]  I'll get to those in a little bit.
[05:59.490 --> 06:00.890]  And there's a network protocol.
[06:01.790 --> 06:07.210]  They're standardized so that one of these three data link layers in the same network protocol has to be implemented in all vehicles.
[06:07.430 --> 06:15.910]  So this is trying to encourage the ability to manufacture interoperable equipment to do diagnostic procedures.
[06:16.310 --> 06:25.810]  The only diagnostics that are required by the federal law are the emissions control systems, which is things like oxygen sensors, fuel mixture ratios, RPM.
[06:26.230 --> 06:32.930]  It's another very basic operating sensors of the vehicle, and that's it.
[06:33.030 --> 06:39.810]  So there's a lot of electronics in the vehicle that's not covered by the federal law for the EPA federal law.
[06:40.010 --> 06:51.050]  So the diagnostic system set up, some of the manufacturers use that for diagnosing other systems that they have in the vehicle, but there's not a requirement for that, so there's not as much of a standardization of that.
[06:53.150 --> 07:00.930]  And, again, so getting back to the SAE standard, it also specifies packet formats and data types for this diagnostic data that is required.
[07:01.270 --> 07:06.970]  And it also specifies a few other features that are not required by federal law but are part of the standard.
[07:07.370 --> 07:13.430]  And some manufacturers use them sort of at their own discretion for however it's useful to their systems to read and write ECU memory.
[07:13.430 --> 07:18.510]  The microcontrollers in the various units have programmable memory, flash memory, basically.
[07:19.210 --> 07:24.770]  And you can basically get firmware updates for your airbag controller, your analog brakes, and whatnot in your vehicle.
[07:24.950 --> 07:33.290]  You can also change calibration parameters and modify the operating characteristics of the vehicle that way as well.
[07:33.550 --> 07:48.250]  And there's also a security feature that is not a very cryptographically secure security feature, but it is a small barrier that is at the manufacturer's discretion to use for preventing access to certain features.
[07:48.630 --> 07:56.730]  For example, a manufacturer may feel that programming the anti-lock brake controller is a safety item that they don't want to be concerned with liability.
[07:56.730 --> 08:07.650]  So they put the security feature on it such that it's another level of difficulty to reprogram that so you don't accidentally do something unsafe and open them up to liability.
[08:09.470 --> 08:16.630]  So one common usage of the OBD2 bus, this is probably by far the most common, is the so-called scan tool.
[08:16.870 --> 08:24.190]  And that's a name that's part of the OBD2 spec that SAE uses to refer to this unit that connects to the vehicle from outside the vehicle.
[08:24.190 --> 08:30.610]  And it's used to communicate with the onboard systems for diagnostics.
[08:30.790 --> 08:46.070]  Basically the way a diagnostic procedure works, one of the onboard vehicle systems would detect a fault condition, perhaps too much mixture too rich in the exhaust or some other type of failure of a sensor, something like that.
[08:46.990 --> 08:50.430]  It would store a diagnostic trouble code, a DTC.
[08:50.930 --> 08:54.950]  That's basically a number that represents the type of error that occurred.
[08:55.110 --> 09:04.730]  And some more detail about it, if it's in a particular oxygen sensor, what failure occurred, was it too lean, too rich, or did the sensor give some value out of bounds that says that it's failing or whatnot.
[09:05.650 --> 09:17.230]  That may, depending on the severity of the error, it may cause the check engine light to illuminate, which illuminates on the dashboard and advises the driver that the vehicle has a problem and needs to be serviced.
[09:18.050 --> 09:20.230]  So the mechanic would plug in the scan tool.
[09:20.430 --> 09:34.010]  It would be able to scan, called scanning this code out, read it out, display it on the unit, have the unit also describe what that code means, four-digit number, and then tell you that this means oxygen sensor in bank A, sensor 2, detected a lean condition,
[09:34.030 --> 09:39.910]  and then they can use that as sort of a start point for their diagnostic and troubleshooting to fix the vehicle.
[09:39.910 --> 09:48.270]  So then once the mechanic fixes the vehicle, you can clear the code, basically erase it, the check engine light shuts off, and the car is back to normal.
[09:49.410 --> 09:52.370]  So that's sort of the diagnostic use of the scan tool.
[09:52.490 --> 10:04.590]  And that's really only, as far as diagnostics of the emissions-related vehicle subsystems, that's all that is required by the federal law, and that's all that is required to be standardized.
[10:04.590 --> 10:15.550]  So there's a lot more available on the vehicle, but it's not standardized, so there's a little bit more difficulty in sort of understanding how that works and figuring out how to interoperate with it.
[10:16.530 --> 10:31.550]  Another common usage that is not standardized, it's not yet required by law, but there's some talk that this might be required by law in the future, is a crash data recorder, which is linked to the airbags, which are required in the United States by federal law to be in vehicles.
[10:33.330 --> 10:38.310]  What a crash data recorder does is it's part of the airbag control module.
[10:38.790 --> 10:43.190]  The airbag control module senses what are considered called deployment and non-deployment events.
[10:43.570 --> 10:56.310]  A deployment event is conditions that cause it to trigger the airbag to inflate, you know, detecting an accident or whatnot, and based on sensor inputs, including accelerometers and wheel speed sensors and whatnot.
[10:56.890 --> 11:03.550]  Or a non-deployment event, which is something close to an accident, but not quite enough, not all the conditions are right for the airbag to inflate.
[11:04.010 --> 11:07.190]  But it's a severe condition in whatever regard, nonetheless.
[11:08.190 --> 11:12.350]  So this control module stores this event and deployment or non-deployment event.
[11:13.630 --> 11:25.330]  And when it stores the event, it can store more than just the sensor inputs, it can also store the vehicle speed, engine speed, throttle position, brake state, driver's seat belt position, whether it's been, you know, engaged or not.
[11:25.330 --> 11:30.070]  Because basically anything, any sensor that's available on the vehicle, it could potentially be storing that.
[11:30.690 --> 11:40.770]  And then that's available for retrieval by anyone, by a mechanic or potentially law enforcement after an accident for forensic analysis of, you know, whose fault the accident was or whatnot.
[11:42.250 --> 11:55.770]  So this may have some privacy implications because, you know, people may not know that their vehicle has this information stored, they may not want their vehicle to narc on them, but they may not be under their control because after an accident, they may be,
[11:55.770 --> 12:00.390]  you know, confused, disoriented and not realize that law enforcement is downloading that information.
[12:00.650 --> 12:14.510]  Or perhaps when the vehicle goes off to be serviced, their mechanic may not have the best intentions in mind or may not care about the individual's privacy and may just, you know, allow the law enforcement to have the information or do whatever they want with it.
[12:14.510 --> 12:18.150]  I mean, mechanics may keep logs themselves sort of as voyeurism or whatnot.
[12:19.570 --> 12:28.350]  And then, so, I don't know, I mean, just whatever, you know, anything could be done with it and there's not a whole lot of control over this information.
[12:29.270 --> 12:36.630]  And then once the vehicle is repaired, the module is either reset, replaced, and basically sort of set back to normal and good to go again.
[12:36.750 --> 12:43.690]  The airbags themselves have to be replaced, so often the airbag modules, the control modules are also replaced.
[12:45.450 --> 12:46.850]  I know this is a hand for a question.
[12:52.130 --> 12:55.190]  Actually, I was going to take some questions at the end, so maybe we can get some discussion about that.
[12:55.430 --> 12:55.490]  Great.
[12:58.050 --> 13:03.790]  So, getting back to the sort of the network stack that the onboard diagnostics 2 specifies.
[13:04.210 --> 13:09.910]  The physical layer, there are three buses that are specified by the onboard diagnostics 2 spec.
[13:11.250 --> 13:14.250]  Basically, one of these three is required to be in by the federal law.
[13:14.250 --> 13:18.970]  There are PWM, pulse width modulation, it's 41.6 kilobits.
[13:19.470 --> 13:22.950]  VPW, variable pulse width modulation, 10.4 kilobits.
[13:23.050 --> 13:33.890]  And the so-called ISO, which is basically standardized by ISO, but SAE references it sort of in consideration for European car manufacturers that tend to use ISO specifications.
[13:34.810 --> 13:38.810]  A bit of SAE for similar type of functionality.
[13:39.570 --> 13:41.450]  And that's an asynchronous protocol.
[13:41.610 --> 13:46.250]  It's very similar to a serial port on a PC, and it's running at 10.4 kilobits.
[13:46.470 --> 13:52.950]  And the fact that it's similar to the serial port on a PC is actually taken advantage of by some of the low-cost interfaces to communicate with the vehicle.
[13:54.210 --> 14:14.370]  And again, some of the major manufacturers tend to gravitate toward one of these buses, but these are not, you know, across-the-board rules, because often, smaller vehicle manufacturers that are bought out by larger ones tend to utilize a bus that's more based on their history than based on the current owner of the company.
[14:15.770 --> 14:30.850]  And some other physical layers that are somewhat significant for onboard vehicles are the CAN controller area network, which is a lot higher speed bus, and that's often used for real-time communication between controllers on a vehicle, where one unit may be sensing a wheel speed,
[14:30.950 --> 14:36.190]  and it may be transmitting that information over the CAN bus to some other unit that would take action on that.
[14:36.270 --> 14:46.990]  Perhaps the sensor sends it to the airbag controller or the, you know, the traction control system that, in real-time for the operation of the vehicle, it uses the bus to communicate between the controllers.
[14:48.510 --> 15:00.230]  And the usage of that is more in the higher-end vehicles that have more complicated control systems, more complicated electronic control systems, but it's increasing in usage and is also being seen more in the lower...
[15:00.230 --> 15:03.850]  sort of gradually down the line of the sort of price points of vehicles.
[15:04.610 --> 15:08.590]  And other buses that are significant, there's a number of the...
[15:08.590 --> 15:16.330]  like I mentioned, OBD1 didn't have a standardized implementation, so there's a number of different proprietary ones that manufacturers had.
[15:16.490 --> 15:22.970]  And then before that, some of the higher-end models from a number of manufacturers had buses on it for their own purposes, even though it was not required by law.
[15:24.930 --> 15:32.730]  The data link layer, as specified by OBD2, is... it uses... there's a...
[15:32.730 --> 15:38.350]  for each of the three physical layers, there's a corresponding three data link layers, one for each.
[15:38.570 --> 15:40.250]  But they have some shared characteristics.
[15:40.270 --> 15:43.090]  They're all half-duplex shared buses, basically.
[15:43.650 --> 15:49.290]  They operate on a carrier sense, multiple-axis type of paradigm, where they have non-destructive collisions.
[15:49.950 --> 15:54.410]  So there's a priority in the packet header that's... there's a system designed into the system.
[15:55.210 --> 16:03.630]  And when two messages are being transmitted simultaneously, the higher-priority message will be sent, and the lower-priority message will detect that a higher-priority message overrode it.
[16:03.790 --> 16:06.190]  So there's no need to retransmit the higher-priority...
[16:06.190 --> 16:17.010]  The higher-priority messages continue to get through in a loaded bus situation, so you don't have a degradation of the bandwidth available when there's a high utilization of the bus.
[16:18.450 --> 16:24.270]  The network layer is a standard network layer for all three of the buses, according to OBD2.
[16:25.090 --> 16:28.830]  There are two addressing modes as far as addressing the controllers.
[16:29.550 --> 16:40.290]  The functional addressing is sort of like an abstract function, as the name says, a function-based addressing that's used for certain diagnostic or calibration procedures.
[16:40.810 --> 16:53.870]  And it allows manufacturers to have flexibility in their implementation, where one manufacturer may choose to implement the emissions diagnostics feature in one unit, where some other would rather distribute it between three or four.
[16:54.230 --> 17:05.950]  And the functional addressing allows an off-board unit to communicate with both of those without having to have any knowledge of whether or not it needs to talk to one or two or more units, anything like that.
[17:06.050 --> 17:18.650]  And then the physical addressing is sort of a more standard type of network addressing, where it talks to a particular unit, and that's used more for things that are very specific to a particular unit, like a programming of memory in it or something like that.
[17:18.730 --> 17:23.130]  And those are used for more of the manufacturer-specific proprietary type of operations.
[17:25.550 --> 17:29.870]  And the packet format has a number of diagnostic modes.
[17:30.090 --> 17:45.050]  And the modes allow you to run tests, query the sensor information, control outputs of it, to basically do troubleshooting and get information from different sensors in a variety of formats to aid in troubleshooting problems with the vehicle.
[17:47.330 --> 17:51.050]  There's a number of data formats for the diagnostic messages.
[17:51.050 --> 17:55.730]  And that allows different quantities to be represented in a compact way.
[17:56.330 --> 18:01.750]  There's two sort of two dimensions of the specification of a data format.
[18:01.990 --> 18:05.290]  The first is the scaling limit offset and table, the slot.
[18:05.630 --> 18:10.590]  And that maps the raw bits and bytes to a meaningful magnitude.
[18:10.590 --> 18:17.210]  For example, an 8-bit value could represent minus 40 to 87.5 with a half, you know, .5 increments.
[18:17.490 --> 18:23.410]  Or an 8-bit value could represent any number of other sets of data, sets of numbers.
[18:23.630 --> 18:29.370]  But the slot specifies how the magnitude is represented into a meaningful real-world quantity.
[18:29.370 --> 18:49.790]  And the PRN, parameter reference number, maps the data to an actual real-world quantity itself, where it references a slot, but it also adds units and a description, so that you can actually, with both the slot and a PRN, take a piece of data and map it to a physical thing on the vehicle,
[18:49.850 --> 18:54.690]  whether it's a wheel speed of a particular wheel or vehicle speed or engine RPM or whatnot.
[18:56.690 --> 19:03.270]  And the diagnostic modes, this is basically the heart of the functionality of the diagnostic features of OBD2.
[19:04.250 --> 19:18.970]  There's the ability to request a sensor, diagnostic data from it, basically getting the, you know, what the current readings of it are, whether it's in or out of its operating conditions, whether it detects a fault with itself, self-testing and whatnot.
[19:19.850 --> 19:36.610]  Has the ability to have freeze frame capability to basically, you can set a trigger where certain conditions are met, then a snapshot of a number of different parameters will be stored, and that can be later read back for trying to diagnose an intermittent problem with the vehicle or whatnot.
[19:37.250 --> 19:52.590]  The freeze frame capability is also tied to some of the diagnostic trouble codes, where, when a certain error occurs, it will also store freeze frame data such that you can determine what the values of particular sensors were, relevant sensors when a particular fault occurred.
[19:53.450 --> 19:58.810]  You can, as I mentioned before, read and clear the DTCs when you have some sort of fault with the vehicle.
[19:59.770 --> 20:16.870]  And you can also do an onboard monitoring diagnostic, which is basically like a real-time drive-around, like a drive test of the vehicle, where you can monitor systems either continuously, where you periodically get feedback from them, or on a polling basis where you probe it when you want its information.
[20:17.090 --> 20:24.550]  But you can drive around the vehicle and monitor stuff sort of in real-time as you're operating it for additional troubleshooting capabilities.
[20:27.070 --> 20:41.130]  And other, some of the other, I don't know, somewhat lesser important diagnostic modes are, you can read the vehicle information, such as the VIN, calibration data, memory checksums, and you can also upload and download memory to the ECUs.
[20:41.770 --> 20:54.530]  The upload and download memory to the ECUs is not one of the things that's not mandated by the federal law, so the ability to do that to particular ECUs may vary depending on how the manufacturer decided to do it.
[20:54.530 --> 20:57.730]  to implement it or implement certain security safeguards and whatnot.
[21:00.370 --> 21:05.190]  So, what type of existing products are there that communicate with these buses and whatnot?
[21:05.450 --> 21:13.390]  And the majority of what I'm talking about here are products that plug into the vehicle, not products that are in the vehicle itself.
[21:14.510 --> 21:20.970]  Like, you buy a vehicle and it has all these controllers in it, and what can you plug into it to communicate with the network on the vehicle.
[21:22.090 --> 21:26.170]  There's proprietary full interface products that are very functional and they're very expensive.
[21:26.170 --> 21:28.110]  They're the ones that the dealers have that do everything.
[21:28.690 --> 21:30.090]  They can program everything.
[21:30.190 --> 21:31.150]  They can calibrate everything.
[21:31.750 --> 21:35.850]  They can tell you every little detail about everything, but they're on the order of tens of thousands of dollars.
[21:37.690 --> 21:47.350]  There's also complete devices that are basically plugged between a laptop and the vehicle, and they do, you know, a little bit... they're a little bit less functional.
[21:47.490 --> 21:51.870]  They generally do the standard diagnostic procedures, and that's about it.
[21:52.050 --> 22:02.270]  There's some free and shareware... there's proprietary and some shareware free software that will communicate with it, but generally that's a lot less functional than the proprietary type systems.
[22:02.270 --> 22:08.070]  And the hardware for those is on the order of hundreds of thousands of dollars.
[22:08.910 --> 22:16.130]  There's also components that implement one or more of the individual buses, and those are, you know, in the order of what small components are, five, ten dollars.
[22:16.950 --> 22:32.950]  And there's actually a couple of the interesting free designs that allow you to, with just a handful of parts of RadioShack, basically communicate... plug a serial port from a laptop into the ISO interface, because the data link layer for the ISO interface is fairly similar,
[22:32.990 --> 22:39.650]  similar enough to a serial port on a computer that you could just, with some physical matching, you can basically plug it right in.
[22:41.310 --> 22:43.790]  So, what type of software products are available?
[22:44.790 --> 22:47.370]  There's a number of commercial and shareware products available.
[22:48.450 --> 22:59.390]  For most of the software products, standalone software products, the required functionality for the federal mandates is the most common support.
[22:59.590 --> 23:11.610]  Some of them have additional functionality for particular manufacturers, but very few of them have the full support for calibrating and communicating with every vehicle, every controller on a vehicle.
[23:11.790 --> 23:17.250]  The things such as calibrating air suspension and traction control and whatnot, those types of features are not available.
[23:17.250 --> 23:25.690]  Sometimes they have the manufacturer-specific diagnostic information, but not necessarily the sort of calibrate and set up features.
[23:27.090 --> 23:30.930]  FreeDiag is a free software implementation of a scan tool, basically.
[23:31.330 --> 23:43.970]  It supports the diagnostic procedures mandated for OB-2, and it also includes a few diagnostic procedures for some vehicles, some proprietary diagnostic features, but that's about it.
[23:43.970 --> 23:48.370]  But there's nothing beyond the diagnostics for that, as the name suggests.
[23:50.830 --> 23:53.910]  So OpenOtto is a project that I've been working on.
[23:54.450 --> 23:59.450]  It's a little bit of hardware and mostly software to implement these protocols.
[24:00.170 --> 24:06.830]  The hardware is another sort of serial port on a PC to the ISO bus interface.
[24:07.190 --> 24:14.390]  It's just a little variation on the designs that are out there, using some more modern components, a little bit more reliable, I think.
[24:15.070 --> 24:16.090]  You know, a little bit cheaper.
[24:17.210 --> 24:28.630]  And I was also working on a repurposed USB serial adapter, where the USB to RS-232 dongle can be reprogrammed.
[24:28.670 --> 24:44.730]  The firmware on it can be reprogrammed to actually do more than just the ISO bus, but actually can do all three of the SAE required buses, so you can communicate with any vehicle with that sort of aftermarket firmware for the serial, or the OpenOtto firmware for the serial device.
[24:46.150 --> 24:48.270]  And the majority of the work has been on the software.
[24:49.110 --> 25:07.050]  I'm trying to implement a standard layer-2 and layer-3 network stack, the data link layer and the network layer, such that the developing applications does not require starting from sort of the ground up to develop talking to the devices all the way up to your user interface.
[25:07.270 --> 25:11.070]  You can sort of start with your generic network interface and move up from there.
[25:11.210 --> 25:12.290]  Very similar to the...
[25:12.290 --> 25:30.410]  Trying to model the API after standard network stacks for TCP/IP and whatnot in modern OSs, so that take advantage of reusing code, reusing the network stacks, because that should be the same through, you know, any type of application, but it tends to be re-implemented because most of the products are commercial proprietary.
[25:31.650 --> 25:42.070]  And also working on some application software, but that's more of a sort of a secondary goal to the creating the library, the sort of the generic library to implement the network stack.
[25:42.210 --> 25:45.770]  And this is all free software and hardware licensed under the GPL.
[25:46.990 --> 25:52.310]  The network stack, it's a common API across all the networks that it supports.
[25:53.570 --> 25:58.870]  Currently, the physical layer just supports the ISO because that's the only hardware I have so far.
[25:59.350 --> 26:04.190]  But I'm working on the USB adapter that will provide the VPW and PWM support.
[26:04.690 --> 26:14.450]  And then CAN is something I'd like to support in the future because that seems to be where the most vehicles are going as far as where the interesting network communications on the vehicle is.
[26:15.130 --> 26:17.850]  The data link layer supports the OBD2 protocol.
[26:18.130 --> 26:23.170]  And the network layer supports the OBD2 protocol and a little bit of some of the manufacturer's extensions.
[26:24.330 --> 26:38.010]  But it's intended that this could be expanded where the physical data link and network layers could support the variety of whatever's out there and continue to support the common API to develop the library separate from the applications.
[26:38.010 --> 26:42.690]  And when the library supports the bus, then the applications would transparently also support that bus.
[26:44.030 --> 26:47.450]  And some of the applications, these are more brainstorming.
[26:47.550 --> 26:49.490]  They haven't been started yet.
[26:49.890 --> 26:58.170]  But their scan tool is sort of like a baseline application that would do the diagnostic features that are required by...
[26:58.170 --> 27:00.950]  mandated by the federal law for OBD2.
[27:02.670 --> 27:04.170]  Network probe and logging tool.
[27:04.450 --> 27:07.390]  I think it's something that would be interesting to apply to a vehicle.
[27:08.470 --> 27:18.090]  Because things like tcpdump to just dump packets and Nmap to scan for addresses and scan for, you know, protocols supported by different nodes and whatnot.
[27:18.750 --> 27:29.050]  It allows you to explore a vehicle and try to identify the, you know, the unknown parts to the network and, you know, reverse engineer the protocols and whatnot to support.
[27:29.590 --> 27:34.090]  And eventually support all of the, you know, all of the features of any vehicle out there.
[27:37.710 --> 27:52.670]  The approach taken by most of the automotive networking tools is tend to be more of a sort of an automotive approach to it where they don't apply the type of networking, network analysis tools that are used in more of the wide area networks and whatnot.
[27:53.190 --> 28:07.670]  And I think that that's sort of the interesting feature that OpenOtto is trying to bring to these automotive networks is that as they're getting more and more complex, they're starting to become more and more like LANDs and WANDs.
[28:07.990 --> 28:11.930]  And I think that the tools that are used there would be very useful also on a vehicle.
[28:13.830 --> 28:39.870]  And then sort of as an additional sort of different direction to take it as some high-level monitoring and control would be available and possible on expanded diagnostics where you could have some sort of inbuilt computer on the vehicle that would continually analyze the sensors and run more advanced analysis on sensor inputs and determine failures long before the sensors would determine that
[28:39.870 --> 28:43.150]  they've failed or before it just completely stops working.
[28:43.830 --> 28:51.650]  You could be able to log whatever's going on in your vehicle for whatever purposes, for diagnostics, troubleshooting, for development, improvement, whatever.
[28:53.450 --> 29:06.910]  And even something as simple as a configurable UI for a detailed dashboard where you can rip out all your gauges and stick in an LCD and have themes for, you know, each driver can have a different skin for how they want their dashboard to look and, you know,
[29:06.950 --> 29:11.950]  have whatever information is available on the diagnostic bus and the vehicle.
[29:14.870 --> 29:19.790]  And so here's just a few of the references that I referred to in the talk.
[29:20.090 --> 29:25.770]  There's the Onboard Diagnostics for Light and Medium Duty Vehicle Standards Manual, the SAE HS3000.
[29:25.770 --> 29:35.190]  that's basically a book of standards for SAE's specifications for all these OBD2 protocols and whatnot.
[29:35.970 --> 29:40.870]  FreeDiag is a free software that implements the scan tool, basically.
[29:41.630 --> 29:53.650]  And then OpenOtto that is an attempt to, you know, have an open network stack and open API for developing a variety of different applications and whatnot to communicate with the vehicle.
[29:56.090 --> 29:58.090]  So I guess that about...
[30:00.010 --> 30:03.590]  Yeah, I'm going to open it up to questions and discussion if anyone has anything.
[30:04.290 --> 30:05.550]  I've got a microphone here.
[30:07.230 --> 30:07.710]  Background.
[30:08.010 --> 30:08.270]  Thank you.
[30:08.870 --> 30:09.350]  Okay.
[30:09.830 --> 30:12.210]  Question on that airbag crash sensor.
[30:12.350 --> 30:17.010]  Is that a one-time event or is there a way to query that or to spoof it?
[30:18.130 --> 30:20.910]  Well, it is a one-time event.
[30:21.470 --> 30:25.750]  The airbag, the crash data recorder will only...
[30:25.750 --> 30:31.930]  I mean, a deployment event can only occur once because once the airbag goes off, you need to be replaced the airbag.
[30:32.050 --> 30:37.450]  So that's sort of a static thing that the crash data recorder needs to be reset after that occurs.
[30:37.450 --> 30:54.810]  The non-deployment event, I don't know, there's not a lot of standards on that, but I believe that they either only record the first sort of non-deployment event or they record the most severe where they continue to replace a single non-deployment event with something that's deemed to be a more severe event.
[30:55.170 --> 31:01.030]  But that also sits in the vehicle and stays there until it's reset or the module is replaced.
[31:01.030 --> 31:07.270]  So is there a way to send it false data, that the car is going zero miles an hour or 100 miles an hour?
[31:07.450 --> 31:07.790]  Oh, yeah.
[31:07.850 --> 31:09.230]  I mean, that's entirely possible.
[31:09.810 --> 31:11.910]  You can... there's a number of ways that can be done.
[31:12.110 --> 31:24.510]  You could potentially put some sort of bridge in between the diagnostic connector and the vehicle so that you don't spoof the crash data recorder, you spoof the person downloading the information from the crash data recorder.
[31:25.150 --> 31:37.830]  And then there's also the, depending on how the vehicle is implemented, where those pieces of information such as the vehicle speed or the driver's seat belt latch sensor or whatnot, however those are communicated.
[31:37.990 --> 31:41.010]  There's a variety of different ways that those can be communicated to the crash data recorder.
[31:41.630 --> 31:45.170]  And depending on, you know, any of those ways could be potentially spoofed.
[31:45.210 --> 31:52.130]  It could be as simple as just cutting a wire and shorting the mechanical read switch sensor that senses that a latch has been pushed.
[31:52.130 --> 31:58.470]  Or, you know, disconnecting your vehicle speed sensor so that your speedometer reads zero and everything else thinks it's going zero miles an hour.
[31:58.650 --> 32:01.230]  And so, that's what gets sent to the crash data recorder.
[32:01.430 --> 32:03.110]  So, there's a variety of ways that that could be addressed.
[32:03.250 --> 32:04.770]  But the implementations would be very different.
[32:04.770 --> 32:07.190]  So, it would be dependent on the vehicle.
[32:09.330 --> 32:09.690]  Okay.
[32:09.790 --> 32:10.130]  Any questions?
[32:10.450 --> 32:16.050]  How much bandwidth is needed for the ECU to talk to the, like, fuel injectors and stuff?
[32:16.170 --> 32:17.910]  Because those are opening and closing really fast.
[32:18.050 --> 32:19.750]  So, they need to be able to talk in, like, real time.
[32:19.750 --> 32:23.310]  And all those standards that you were talking about have, like, really low amounts of bandwidth.
[32:23.530 --> 32:25.550]  Like, 10 kbits per second or something like that.
[32:25.750 --> 32:26.010]  Right.
[32:26.370 --> 32:31.110]  Well, the three OBD2 buses are only for diagnostic purposes.
[32:31.290 --> 32:35.770]  So, they're not actually used for real-time communication of vehicle subsystems.
[32:35.830 --> 32:41.190]  So, for example, the message is to open or close the fuel injectors wouldn't be on that bus.
[32:41.970 --> 32:44.410]  And actually, that is usually not even on the bus.
[32:45.190 --> 32:48.530]  There's an engine unit that controls the fuel injectors.
[32:48.610 --> 32:53.010]  And that basically has wires that go straight to the solenoids to control the fuel injectors.
[32:53.270 --> 33:03.050]  The information, the real-time information that might be communicated is, you know, a sync signal for every timing around the cylinder or around the crankshaft or whatever.
[33:03.050 --> 33:05.370]  And that would synchronize some other parts in the vehicle.
[33:05.610 --> 33:14.350]  Or a speed sensor would be then sent to the engine control every, periodically, you know, 10 times a second or something like that to change how it would do the fuel mixture.
[33:14.490 --> 33:18.710]  But something of that nature is done by just a sync, like, a wire.
[33:18.850 --> 33:20.710]  There's a computer there that talks in the bus.
[33:20.770 --> 33:25.170]  But as far as the timing goes, it just plugs right into the fuel injectors and runs it on a separate wire.
[33:27.530 --> 33:28.330]  Another question?
[33:28.590 --> 33:28.750]  Yeah.
[33:29.290 --> 33:33.170]  Would you be able to run the vehicle using the network stack?
[33:34.210 --> 33:36.690]  Like, accelerating, braking, turning?
[33:37.270 --> 33:39.310]  Depending on the vehicle, you can...
[33:39.770 --> 33:46.330]  Actually, the vehicle I drive, which is a 2003 vehicle, everything except for the steering wheel can be controlled over the...
[33:46.330 --> 33:54.870]  Not necessarily over the diagnostic bus, but over the CAN bus, because the pedal is just a switch and the gear shift is just a switch.
[33:54.870 --> 33:57.990]  So, everything is automatic transmission, obviously.
[33:58.370 --> 34:03.250]  So, yeah, you could potentially control the majority of the vehicle over these buses.
[34:07.700 --> 34:08.260]  Yes?
[34:08.560 --> 34:09.040]  Yeah.
[34:09.180 --> 34:13.200]  What sort of a physical layer or physical protocol is the CAN network working on?
[34:13.860 --> 34:15.540]  The CAN network is...
[34:15.540 --> 34:17.280]  It's a twisted pair.
[34:17.760 --> 34:19.580]  It's 500 kilobits.
[34:21.380 --> 34:23.280]  And, yeah, twisted pair copper.
[34:23.640 --> 34:23.980]  I lied.
[34:24.100 --> 34:24.600]  Topography.
[34:24.860 --> 34:27.540]  What sort of protocols are we talking here?
[34:28.100 --> 34:30.140]  Well, CAN bus also is a shared bus.
[34:30.980 --> 34:36.740]  So, it's sort of a half-duplex bus with a priority scheme in the addressing to prevent collisions.
[34:37.860 --> 34:43.700]  And as far as the topology of the network of the CAN bus, that would really be up to the manufacturers.
[34:44.700 --> 34:49.780]  There's different ways you can use the CAN bus to provide sort of bridges and switches and whatnot.
[34:49.780 --> 34:54.220]  But since that's not standardized, it's really up to the manufacturer to do whatever they see fit.
[34:56.120 --> 35:02.200]  Is there a connection between the OBD2 bus and the CAR's anti-theft system?
[35:03.180 --> 35:20.000]  Yeah, actually, a number of the vehicles have the ability to reprogram or sort of calibrate the any theft system where you can either disable it or you can, if you get a new key and you have to calibrate the new key to the system, you can do that through the diagnostic bus.
[35:20.000 --> 35:25.260]  But again, that's not a... it's not standardized because it's not mandated by the government.
[35:25.440 --> 35:35.100]  So, some manufacturers use these buses for features like that, but they're not required to and they may do it on a CAN bus and they may have their own proprietary way where you need to plug in directly to an ECU or something like that.
[35:36.940 --> 35:45.980]  At one time, I had a Taurus SHO and it had... when you got going fast, the car computer cut the engine off of it and thought you was going too fast.
[35:47.020 --> 35:53.740]  With that software, can you modify the settings on a car computer to where it'll keep on going and not shut the engine down?
[35:54.040 --> 35:54.740]  Yeah, yeah.
[35:54.940 --> 36:00.280]  I mean, that's one of the things, the applications, I think, that would be a great use of this is that...
[36:00.720 --> 36:13.480]  That was probably done by software running on the controller to the engine and it cuts fuel to the fuel injectors when it gets messages that says the speed is over a particular limit.
[36:13.620 --> 36:18.280]  So, if you could rewrite that software, you could change it to whatever you want to not cut out a particular limit.
[36:18.540 --> 36:31.620]  And being able to... that's something that the manufacturers are very tight-lipped about and they're probably not going to make available very easily or without very expensive, you know, licensing agreements and NDAs.
[36:31.680 --> 36:40.140]  So, it's something that's going to probably need to be reverse engineered if one wanted to download a memory dump and figure out, you know, reverse engineer it to be able to change the types of settings like that.
[36:40.260 --> 36:41.080]  But it would be possible.
[36:43.320 --> 36:44.680]  Got a two-part question.
[36:44.900 --> 36:45.040]  Yep.
[36:45.320 --> 36:59.100]  Is it possible to actually download all the code that's stored in that module to a laptop, modify it possibly in binary form, and then re-upload it and have it, you know, be able to run?
[36:59.180 --> 37:00.740]  Is it stored that way on the module?
[37:01.320 --> 37:01.680]  Yeah.
[37:01.820 --> 37:03.740]  On some vehicles, that's not a...
[37:03.740 --> 37:04.280]  Yes.
[37:04.380 --> 37:08.080]  On a number of vehicles... actually a lot of vehicles, that's a very possible thing to do.
[37:08.200 --> 37:13.020]  Sometimes there's checksums and some other security features that you need to sort of jump through.
[37:13.180 --> 37:19.460]  The security feature specified by OBD2 is used by some manufacturers to prevent you from even downloading the memory at all.
[37:19.460 --> 37:26.560]  But once you get through those procedures or whatever they have in the way, then yes, that's definitely possible.
[37:26.880 --> 37:27.020]  Okay.
[37:27.240 --> 37:43.120]  And on that same line, is it possible to modify things such as variables in memory in real time while the car is running, such as adjusting the timing of, you know, when the fuel injectors are going or something like that?
[37:44.220 --> 37:45.080]  I'm not sure.
[37:45.280 --> 38:01.140]  I believe that that would probably be very specific depending on the implementation of the vehicle, whether it used the sort of the program stored in memory to initialize its state and then use its internal state as it was running or if it worked on that in real time.
[38:01.460 --> 38:06.640]  But that's definitely something that would be an interesting thing to explore with the ability to probe these networks.
[38:06.640 --> 38:12.180]  In the scenario you mentioned before, which was essentially drive by wire, i.e.
[38:12.240 --> 38:19.620]  accelerator, etc., controlled by switches rather than mechanical linkage, what kind of fail safes are in place if the CAN bus fails?
[38:21.660 --> 38:22.420]  Not much.
[38:23.200 --> 38:26.680]  It's a... what's it called?
[38:26.820 --> 38:33.500]  It's a differential bus, so there's a little bit of, you know, additional reliability in the bus because of that.
[38:33.500 --> 38:41.060]  But there really isn't a whole lot of... I think there's probably cutouts if certain sensors fail to respond.
[38:41.320 --> 38:51.720]  But there's a number of things people have done when certain parts of it have actually failed in a way that prevents them from shifting their vehicle into drive because it thinks that the brake is applied even though it's not.
[38:51.860 --> 38:54.480]  And the solenoid that prevents the gear shift from moving doesn't move.
[38:54.620 --> 38:57.240]  So if you short a tail light, it allows you to open it.
[38:57.240 --> 39:05.860]  So, I mean, there's not a tremendous amount of, you know, the type of reliability you find on, like, fighter planes or fly-by-wire or anything like that.
[39:09.440 --> 39:21.980]  Yeah, I don't know that there's... I mean, that would certainly be within the reason to be able to detect that and, you know, do something about that, to have some sort of heuristics for fail-safe on that.
[39:22.160 --> 39:32.840]  But I believe the way that the auto manufacturers address that is by making... providing individual components that are basically reliable enough and then hope they don't fail.
[39:33.000 --> 39:36.840]  I mean, some of these control features are not done entirely over the CAN bus.
[39:37.260 --> 39:44.980]  It's not like the accelerator pedal will be plugged into the CAN bus and then the, you know, gear shift will be plugged into the CAN bus and then the controllers would run off that.
[39:45.380 --> 39:51.920]  It's more like there's a, maybe a half-a-dozen controllers and the accelerator runs to the same controller that runs your fuel injectors.
[39:52.080 --> 39:59.580]  So if your accelerator got stuck or if the CAN bus went out, then maybe your anti-lock brakes wouldn't work as effectively as they used to work.
[39:59.700 --> 40:03.500]  But your accelerator would still control your fuel injectors.
[40:03.600 --> 40:07.880]  And if you let up, it would still shut off even if you're anti-lock brakes thought you were going 100 miles an hour.
[40:09.200 --> 40:13.160]  Earlier, there was mention about storing crash data in the controller for the airbag.
[40:13.900 --> 40:20.600]  And we were having a discussion about somebody trying to... courts were trying to use that data to incriminate the driver.
[40:20.960 --> 40:28.240]  Has there been any discussion or decisions on who owns that data and whether, you know, there's sort of like Fifth Amendment implications there?
[40:28.840 --> 40:30.000]  Not that I know of.
[40:30.740 --> 40:33.560]  You can actually... my wife is a lawyer and you might want to talk to her.
[40:33.700 --> 40:37.260]  I'll be with her afterwards if you want to talk about some of the legal implications of that.
[40:37.400 --> 40:48.820]  But some of the investigations I've tried to do as far as the crash data recorder have been met with you can't have that information if you're not a mechanic or if you buy this $5,000 tool or if you're law enforcement.
[40:49.140 --> 40:59.680]  So I don't think that those discussions are... the people that have the equipment to work on these controllers, they would rather not have those discussions, I think.
[40:59.740 --> 41:09.780]  It seems to me that they'd rather have it in there and then pull it out when some, you know, drunk driver hits a baby and say, isn't it great that we had this information to prove that, you know, some real bad guy was really bad.
[41:09.780 --> 41:13.340]  And then, at that point, it's like, oh, these have already been in your cars for 10 years.
[41:13.520 --> 41:15.040]  So, you know, what do you have to complain about?
[41:15.140 --> 41:18.380]  They'd rather not discuss it beforehand when people would actually get upset about it.
[41:18.420 --> 41:19.200]  What's your car?
[41:22.980 --> 41:27.720]  Something like... it's... most people don't know the data is there and you can't get the data if you want to.
[41:27.900 --> 41:30.380]  I mean, you can't feasibly get the data if you want to.
[41:30.520 --> 41:35.360]  You can technically if you paid a lot of money for a... you know, the tool to communicate to it.
[41:35.360 --> 41:45.280]  But it's just somewhat... it's intentionally made impractical for an individual to get that data, to know what the data is, and to be able to control where the data goes.
[41:49.600 --> 41:50.370]  More or less.
[41:53.560 --> 42:06.960]  These last questions, it's making me think that with OnStar, it would make it possible for an onboard computer to immediately transmit through OnStar the fact that you'd had a wreck.
[42:07.150 --> 42:08.710]  I guess they already do that.
[42:08.850 --> 42:09.770]  Yeah, I believe they do that.
[42:09.850 --> 42:11.250]  That's part of the features of OnStar.
[42:11.480 --> 42:19.370]  Right, but more detailed information, such as the fact that you were weaving and going 87 in a 50 and so forth.
[42:19.560 --> 42:20.020]  Absolutely.
[42:20.650 --> 42:24.100]  That wasn't really my... the question I started out with.
[42:24.650 --> 42:27.670]  That was just based on the previous people talking.
[42:27.670 --> 42:33.250]  I wanted to ask if it's possible to turn off features that you don't want.
[42:33.520 --> 42:37.730]  For instance, when I put my... it's a General Motors 2001 car.
[42:38.210 --> 42:42.460]  When I put it in drive from park, the lights come on.
[42:42.580 --> 42:45.460]  The headlights or the daytime running lights, whatever they call it.
[42:45.770 --> 42:49.060]  There are situations where you might not necessarily want that.
[42:49.670 --> 42:55.710]  Like in the movie Fargo, they had to drive in darkness for a few seconds.
[42:55.710 --> 43:02.520]  Also, is there any way to shield the onboard computer?
[43:02.710 --> 43:05.270]  I considered wrapping it in aluminum foil.
[43:05.450 --> 43:06.950]  I really don't know how to do it.
[43:07.120 --> 43:16.310]  To stop the blip blip, you know, that's on your keychain remote that unlocks the doors and pops the trunk and all of that.
[43:16.310 --> 43:23.330]  I want to shield that receiving unit from receiving any radio signals.
[43:23.330 --> 43:27.980]  Because I do not use my remote thing.
[43:28.150 --> 43:29.410]  I locked them in a drawer.
[43:29.540 --> 43:31.500]  I don't... I just... I use a key.
[43:31.950 --> 43:34.310]  Like it's a 1970s car or something.
[43:34.750 --> 43:45.820]  And so, if somebody were to ever have a clone of a radio device that could open my doors, I don't want their radio signal to be able to invade my car.
[43:46.500 --> 43:50.270]  Is that something that you address or is that...
[43:50.270 --> 43:55.460]  Some of those things could be addressed by reprogramming the controllers.
[43:55.460 --> 44:03.340]  You could basically remove the functionality that responded to, you know, message...
[44:03.340 --> 44:08.820]  You know, when it receives a transmission on the antenna for their remote door openers or whatever.
[44:10.210 --> 44:20.560]  As far as actually preventing it from being received in the first place, I think that would be more of a hardware type of solution where you need to find the antenna and disconnect it or ground it.
[44:21.040 --> 44:25.860]  Or just cut the wire or something like that to just completely prevent it from being received.
[44:26.340 --> 44:30.790]  As far as being able to easily reprogram those things, it's...
[44:30.790 --> 44:38.060]  Right now, it's not possible to easily do that for an individual because the information is sort of held under lock and key by the manufacturers.
[44:38.730 --> 44:43.600]  And that's, you know, what I hope to encourage with this is people to be able to reverse engineer the...
[44:44.730 --> 44:56.060]  You know, the software on their vehicles so that they can, you know, release free implementations of a new software for your vehicle that doesn't have this feature and gives you programmability of a couple other features.
[44:57.580 --> 44:59.790]  The state that I'm in, they...
[44:59.790 --> 45:05.020]  As part of your emissions test, they query your OBD computer at the emissions testing station.
[45:05.290 --> 45:10.730]  Is there some way to say to the state, my car is running clean, even though it may not be?
[45:11.400 --> 45:11.920]  Absolutely.
[45:12.340 --> 45:12.860]  That's...
[45:12.860 --> 45:13.800]  If you can...
[45:15.730 --> 45:16.770]  Part of what...
[45:17.540 --> 45:23.580]  What the OpenOtto project is trying to produce is an ability to communicate on these buses.
[45:23.820 --> 45:29.270]  And it's not a diagnostic unit centric type of network stack.
[45:29.460 --> 45:30.820]  It's more of a generic thing.
[45:30.960 --> 45:44.000]  So you could use this to make a small microcontroller based system, put it under your dash, and connect it possibly with a switch or something where you could enable the real bus when you wanted to communicate to, you know, your mechanic.
[45:44.000 --> 45:48.820]  And you can enable some other bus when you wanted other information to come out of your diagnostic connector for whatever purpose.
[45:49.560 --> 45:52.320]  So that's definitely something that could be possible as well.
[45:52.900 --> 45:53.380]  Okay.
[45:53.380 --> 46:02.170]  I'd like to point out, end mapping your CAN bus is all well and good, but your airbag is a large electrically ignited explosive charge pointed at your face.
[46:02.300 --> 46:02.860]  Please be careful.
[46:05.040 --> 46:14.620]  You know, learn the failure modes of these things when you teardrop them and crash them before sitting in the driver's seat.
[46:15.420 --> 46:23.380]  Second off, I'd like to find out, how do things like the OnStar receiver transmitter connect to the rest of the vehicle?
[46:23.520 --> 46:25.960]  Is that over this bus or is that something else?
[46:27.860 --> 46:39.820]  I haven't done any investigation as far as how OnStar works, but I would presume that it would use the CAN bus or something similar, perhaps a CAN bus that's not presented to the connector but is internal to the vehicle.
[46:40.380 --> 46:44.540]  But I'm not sure because I haven't done any research on the OnStar system.
[46:45.560 --> 46:55.540]  I just wanted to follow up on the question before regarding the use of the black box data within criminal proceedings.
[46:55.730 --> 47:09.750]  There actually was a case, I believe it was in Michigan earlier this year, where a guy was found to have been driving something like 105 miles an hour in a 35 and slammed into a parked car, killing, I believe, three people inside of it.
[47:09.860 --> 47:13.820]  I believe they used that data to levy higher charges against him.
[47:19.380 --> 47:20.840]  I'm sure it was just a subpoena.
[47:25.500 --> 47:26.400]  Where to begin?
[47:29.380 --> 47:37.260]  First off, the SRS data, I'm sorry, the airbag data, is that read through, I'm assuming it's a circular buffer?
[47:38.200 --> 47:49.140]  No, there's, they store one non-deployment event, one deployment event that causes the airbag to deploy, and one redeployment event that's basically severity of a deployment event but after the airbag goes off.
[47:49.300 --> 47:54.480]  Airbags can't reinflate, so it's kind of a, redeployment is kind of a misnomer, but that's essentially what it stores.
[47:54.560 --> 47:55.420]  It's just three values.
[47:55.960 --> 48:02.240]  The non-deployment event is replaced by a more severe non-deployment event in some vehicles if that's how it's implemented.
[48:02.240 --> 48:02.860]  Okay.
[48:03.480 --> 48:11.560]  Are you aware of any clearinghouses for the data that a prosecutor or lawyer would use that says, these are the cars that this black box data is available from?
[48:11.800 --> 48:14.960]  How does a prosecutor know that he might have this avenue available to him?
[48:15.180 --> 48:21.180]  As far as I know, there's only one manufacturer called Vetronix that makes a device that can read this information.
[48:21.460 --> 48:26.520]  And on their website, they list all the vehicles that their tool is compatible with.
[48:26.680 --> 48:30.500]  So I don't know if that's a comprehensive list of all the vehicles that have that information.
[48:30.840 --> 48:36.960]  But as far as I know, that's the only list of vehicles that there are devices available that you can get that will get the information out.
[48:37.100 --> 48:39.700]  So practically, those are the only vehicles that it applies to.
[48:39.880 --> 48:40.160]  Okay.
[48:40.260 --> 48:40.500]  Sorry.
[48:40.620 --> 48:41.140]  Last question.
[48:41.580 --> 48:46.720]  You said the OBD2 systems, they can potentially store the vehicle identification number?
[48:47.040 --> 48:47.600]  Yes, they do.
[48:47.920 --> 48:49.260]  And they definitely do?
[48:49.460 --> 48:50.240]  You're pretty sure?
[48:50.500 --> 48:54.700]  Oh, it's definitely part of the spec and that's required by federal law as far as the...
[48:54.700 --> 48:56.280]  Federal law is part of the specification.
[48:56.600 --> 48:56.720]  Right.
[48:56.720 --> 49:06.160]  So if you're being clever and trying to get around emissions and you have your buddy plug his car into the state-run vehicle emissions program, they're going to find out.
[49:06.600 --> 49:10.400]  Assuming that they log the VIN through that method, yes.
[49:10.540 --> 49:11.200]  Potentially, though.
[49:11.240 --> 49:11.340]  Yeah.
[49:11.560 --> 49:11.720]  Okay.
[49:16.020 --> 49:25.920]  This would be potentially really great for small-time mechanics to get around having to spend a thousand dollars for these large units to do all this stuff.
[49:26.420 --> 49:38.560]  Do you know if there's patents that these car manufacturers have to stop a small-time fabricator from making units on the cheap?
[49:39.020 --> 49:42.700]  As far as I know, I'm not aware of any patents.
[49:42.920 --> 49:57.580]  And I believe the majority of the interesting information is probably protected by trade secrets because they would rather no one knows at all than a patent where they could prevent you from using it, but it would be available on the USPTO's website where you could get access to it.
[49:57.660 --> 50:03.360]  I think they're more interested in preventing access to it than protecting a revenue stream that it may generate or whatever else.
[50:03.360 --> 50:04.240]  Okay.
[50:04.460 --> 50:10.060]  Now, as it being a trade secret, do you foresee this OpenOtto having problems with the DMCA?
[50:11.840 --> 50:14.520]  There could be some potential liability there.
[50:14.780 --> 50:21.780]  But again, my wife can probably feel those questions better that she's a lawyer and she's here to help me out to keep me on the right side of the law.
[50:22.100 --> 50:24.760]  And she can perhaps answer some of your more questions about that.
[50:28.660 --> 50:35.600]  All the stuff that you're talking about here, is it any of this real-world information that you've done or is this all conceptual?
[50:36.380 --> 50:46.560]  No, the network stack I have implemented and the simple sort of network interface I have also implemented, they're available for download on the website.
[50:47.440 --> 50:54.540]  The more advanced sort of protocols and applications and whatnot have not been implemented.
[50:54.680 --> 50:55.960]  Yeah, those are just in planning stages.
[50:56.160 --> 50:59.160]  So with all the questions that have been asked, all that's conceptual, right?
[50:59.400 --> 51:00.480]  Yes, yes.
[51:00.660 --> 51:03.300]  Because the state the OpenOtto is at is an API.
[51:03.540 --> 51:04.080]  It's a programmer.
[51:04.260 --> 51:07.500]  There's no there's no user useful applications yet.
[51:07.640 --> 51:11.700]  It's an API that you can use in a library to use to develop these applications.
[51:11.980 --> 51:16.840]  So it's more of a develop... it's more interesting to developers, you know, practically at this moment.
[51:21.980 --> 51:25.900]  Have you done any work with aftermarket ECUs and everything like that?
[51:26.480 --> 51:31.140]  As far as getting past log codes and just replacing the entire ECU with like an E-Manage?
[51:31.700 --> 51:32.540]  No, I haven't.
[51:32.640 --> 51:38.240]  I haven't had... unfortunately, I don't have the ability to get access to a lot of these ECUs.
[51:38.600 --> 51:41.940]  Don't really have the money to go buy a whole lot of them and whatnot.
[51:42.120 --> 51:44.260]  So basically, I just have my own vehicle to experiment with.
[51:47.200 --> 51:47.520]  Okay.
[51:47.800 --> 51:49.200]  I think this will be our last question then.
[51:51.640 --> 51:56.880]  For the diagnostics, it would seem the next logical step for the connector would be some sort of wireless implementation.
[51:57.380 --> 52:01.420]  Are you aware of any work on this by automotive manufacturers or the SAE?
[52:01.420 --> 52:13.380]  There's actually... there's discussion about... there's been... I've seen a lot of discussion about the most concrete I've seen as far as the onboard diagnostics three or whatever would sort of supersede the onboard diagnostics two.
[52:13.960 --> 52:26.220]  There's actually statements on the California Air Resource Board website, which is basically the... they kind of instigate the EPA to make federal standards that have these environmental regulations.
[52:26.540 --> 52:49.160]  They have actually made statements to the effect of having a convenience feature where only the vehicles that are malfunctioning are required for inspections with some sort of wireless snooping of the vehicles that have... you know, make sure your sensors are always working up to spec and only the vehicles that don't have that are... get letters in the mail or whatever to come in for inspection.
[52:49.420 --> 52:56.900]  So there's definitely very real and very real being discussed by the California Air Resource Board, which basically inspires the EPA to make federal laws.
[52:56.900 --> 52:56.920]  the EPA to make federal laws.
[52:59.380 --> 53:00.460]  So I guess that's it.
[53:01.420 --> 53:02.020]  That's a lot.