EP 263 Evan McMullen on Self-Driving Cars

Howdy.

This is Jim Rutt and this is the Jim Rutt Show. Listeners have asked us to provide pointers to some of the resources we talk about on the show. We now have links to books and articles referenced in recent podcasts that are available on our website. We also offer full transcripts. Go to jimrutshow.com that's jimrutshow.com Today's guest is Evan McMullen. Evan is a Mechtronics engineer at DSpace, a leading provider of hardware and software for simulation tools into the auto industry. And today we're going to be revisiting one of my favorite topics and I just think it's such a good topic, self driving cars. And to remind listeners, in the past we've had three programs substantially focused on self driving cars. The first was EP 94 where we had Shaheen Farshi who was one of the co founders of Zoox, which is now Amazon self driving car. In EP124 we had Jim Hackenon who was at the time the just former CEO of Ford, where we talked about electric cars, self driving cars, et cetera. And then More recently in ep 221 we had on George Hotz of comma AI who has this very interesting open source self driving car kit that will work with like 250 different models the cars. But today we're going to be talking with Evan McMullen. And while we're going to talk a bit more generally about self driving cars, we're going to really focus on the area where Evan has deep expertise, which is in the simulations. Welcome Evan.

Thanks Jim. Great to be here. Really excited to dive into this topic. We'll nerd out about this until you stop me. So wherever you want to pick it up, let's go there.

All right, so when you think about the simulators that are being used in developing self driving cars, what is the purpose of the simulators?

Okay, so in order to answer that question, I'm going to have to give a sort of brief taxonomy of the sorts of simulation that people do in embedded electronics design and automotive controller design specifically. So there's basically four, five levels of simulation that are typically done in designing the control systems for a vehicle. The first one is called MIL or model in the loop simulation or model based testing. There's been a big push over the past decades to do what's called model based design. So this is where you are creating most of the code for these controllers by creating a model and a program usually like simulating for mathwork. So think Like a block diagram, graph lines, connecting nodes, type of model. And so first, the first type of simulation or testing is testing that model against a plant model and perhaps an environment model, all of which is done in simulink or equivalent software before any code is actually generated for the target platform. Second level is software in the loop simulation. So you've generated the code that's going to be used on the target platform, but you're still simulating it on a PC hardware. Basically. Right. With again, a model of the environment and the plant that is in the loop of this next level is basically where you do processor in the loop simulation, where we put the code onto the actual target processor, some sort of development board or in some cases, if that doesn't exist yet, maybe you do an FPGA and you call this processor in the loop simulation. And then the fourth level is hardware. In the loop simulation, you don't just have the processor, you have the target ECU hardware and you have it hooked up to something called a hardware in the loop simulator, or a HIL as we call it in the industry, which consists of a bunch of electronics, FPGAs, processors, DSPs, et cetera, to actually simulate at the physical electrical level the sorts of signals that the sensors would be providing for any given sort of test scenario. I said there's sort of four, five. What I spent a lot of time building up for the companies that I was working for in this industry was basically the ability to do what these companies would relate to as virtual hill simulation. So getting a lot of the advantages of the increased realism of doing the hardware in the loop level of simulation, where you have kind of the full system being tested in certain ways with a very high degree of fidelity. But doing this all on a single very beefy server style PC or in the cloud, do massively paralyzed, basically good enough tests.

Okay, that's a very interesting way to cut the stack. Other ways that I've heard people cut the stack is into perceptual simulators, behavioral decision making simulators, and end to end simulators. Does that resonate with you?

Yeah, that's another way you can look at it. So, for example, at each of those levels of testing, you can do essentially any one of the three types of simulation in the taxonomy you just described. Right. So you can be focused on simulating what the percepts of the system would be. Right. You can be focused on simulating and testing how well the control loops are functioning. You can be testing the entire system in an integrated fashion. So all of These sort of testing philosophies is how I might think of that. Or testing methodologies can be used at most of the layers of the taxonomy that I described.

Gotcha. Now, when I think civilians think about self driving car simulations, they think of the software somehow being embedded in a 3D world. To what degree is that accurate or imprecise?

So that is in fact quite accurate. And the degree of fidelity of the 3D world and how this relates to the software can vary quite a lot. So for example, one of the ways you can do this is the sort of thing that I was mainly working on, which is to have everything is done in software, but we're also running physical simulations of the world, and we're running physical simulations of the sensors where they are in the world and those physical simulations of the sensors. And when I say physical simulations, I mean highly accurate physics simulations implemented in code. That data is then being passed over a simulated virtual bus which can be subjected to electrical failures or physical failures, et cetera, which is then how the data gets into the simulation which is running the production code. So we can do that all virtually. We can also do this in the hardware in the loop case. So for example, we had technology we would provide to auto companies for testing radar systems where they would put their radar unit into a device we provided, which in part contained a radar frequency anechoic chamber. So they would send out their ping and then we would have emitters that could simulate physically whatever return we wanted that sensor to receive. And then that's hooked up to the controller under question as part of its perceptual system. And so you can simulate that for a physical piece of hardware. We can also virtualize the physical hardware and simulate it in the virtual world. And you want to do some amount of both of those kinds of testing when you're developing products like this.

All right, let's double click on something you said which is modeling the world. Now again, naive view of self driving car simulator, to my mind at least has, at whatever level we talk about. It's interesting, this distinction between the various levels of pure software, even coarse grain software, all the way down to the full stack, but. But presumably this world has lots of agents in it that the car doesn't control, right? The other cars, yes, correct. People walking around, pigeons falling out of the air, open manhole covers, construction sites, et cetera.

And also weather.

And we'll get the weather, because weather to my mind is, I think people were quite naive about when they first started on this stuff many years ago in Fact, I, I remember when there was a big self driving car industry here in Pittsburgh, where I am this week. And I said at the time, ah, that's interesting because it's going to be a shitload harder to do a self driving car in Pittsburgh with mostly non orthogonal road layouts and shitty weather a good part of the year than it is to do it in Silicon Valley where the roads are pretty square and the weather is pretty benign. Of course, Waymo took that even a step further, which was initially the easiest possible place, Mesa, Arizona, which is flat orthogonal roads and perfect weather. Damn close to it. But we'll get back to that. So talk a little bit about the elements that are in this simulation and how those are created.

Okay, so this is going to vary slightly between different levels of simulation. So I'll focus first on the thing that I spent the most time doing, which is this sort of virtual vehicle, virtual hardware in the loop type of testing. So a necessary component of this is a way to execute the exact production code that you're going to be deploying to your target embedded platform in a virtual environment. And you may want to simply compile the code for the processor that you're using. So in this case usually like AMD 64 instruction set, or you may wish to run an emulation of say the target processor. So in the automotive industry, often PowerPC or ARM architectures are used. So you can either compile for the target and run it in an emulator, or you can compile for the native platform that you're testing on and understand that your tests will have slightly less fidelity because of differences in the way compilers for different platforms will translate the same C code into platform specific assembly. I in fact worked with customers to do both of these approaches and they both have their merits. For example, the compiling code to native code for your server that you're testing on, much faster execution. But there's going to be some sorts of weirdness edge cases that you might miss doing that. So generally people will do both. Then building on that, you certainly need some kind of model of the vehicle for that thing to hook up into. You could have this all be just a model, or you can do physics based modeling, electrical simulation of the entire vehicle, bus of the sensors. And this of course becomes much more computationally costly, but in general still cheaper than the equivalent amount of testing time in a test mule vehicle that's instrumented appropriately and has engineers driving it to create these conditions in the real world. And obviously also much safer. So we basically need to create Like I mentioned, so you have a simulated virtual ecu. You then need to decide the level of fidelity that you want for the plant model, which is to say for the model of the vehicle, its electrical systems itself, chassis and body and vehicle dynamics, and engine dynamics and so on. All of these get simulated at varying degrees of precision, including at very, very high degrees of precision for certain types of test cases. And then this vehicle simulation is embedded in a virtual world that, for example, you can, in general, we would do stuff like hook this up to something that is implementing the Unreal engine so you can watch it drive around in a video game type environment if you want to. That's usually less useful for testing. Automating the testing, deploying it at massively parallel in the cloud, and getting many, many, many miles of virtual driving done in a day is sort of the way that this tends to be most useful, rather than having people doing more manual testing where they're driving the vehicle around through a virtual environment trying to create testing scenarios. Again, because with this you can also massively paralyze tests to incremental tweaks of the same code, trying to solve the same problem and get something fairly close to real world data about how this is actually going to perform in highly realistic scenarios.

Talk a little bit about the nature of this top level simulation of the world. You know, again, I've written some simulations and you can go from very coarse grained simple simulations to insanely fine grained simulations where every NPC has full physics dynamics, et cetera, or you can just have them be simple wireframes. What level or other multiple levels where the world simulations are done.

There are multiple levels. So for example, usually you will begin testing in a virtual world that is say, like a simple oval test track with no potholes, no weather, no pedestrians, and no other vehicles. And then when this is working well, then you would move to having, say in some order, depending on what your testing goals are. For this particular set of tests, you might add in weather first, along with road conditions, you know, meaning we want to be able to simulate the way in which the roads get especially treacherous in the first few minutes after it starts to rain on a road, assuming that cars have been driving on it for a while because of the way that that water interacts with the oil before washing it off. You might want to then add in a few other vehicles or pedestrians, certainly traffic signs. And this is especially important when you're testing say, computer vision systems that are part of the self driving system, because we would actually in fact input the specific manufacturer provided parameters of the camera, sensors and lenses such that the simulation environment would take this into account when determining if the vehicle would be able to read a street sign from a certain angle, because maybe there's some lens flare that's occluding the street sign from the perspective of the controller. So arbitrary levels of testing fidelity essentially were possible, and our customers would pick which levels were appropriate for a given testing goal and would in general, try to. The general principle here is you want to front load as many tests as possible into the virtual world rather than the physical world because it is both quicker and cheaper. And so you want to be able to get as much testing done of things like the algorithms of the control code that you're using. Work out any bugs there before you discover them in the real world, because discovering them in the real world often can involve some sort of costly accident, or you might have finalized some aspect of that controller, which you then need to sort of go back to the drawing board about. And if you've already placed a bulk order, this is going to be very problematic. So we really try to front load as much of the stuff as possible into each layer of fidelity and then move forward and really just focus on the stuff that the previous levels of fidelity would have missed, as in general, the process.

Yeah, it's very interesting. It makes a lot of sense. There's just no point in burning more processor in the simulation than what it is you're trying to prove or disprove or validate.

Exactly.

So I assume at the top level, again, I may be wrong, but that there is a big giant world out there, kind of like Grand Theft Auto, but much bigger and more elaborate, that you can do things like nav testing, say, get from point A to point B, et cetera, with all kinds of random shit happening in between. Is that an approximation of the top level models?

This does exist, though. I would say that the simulations, insofar as they are pure simulations, tend to be less of a fully live world than GTA with much more detail. But there's certain techniques that you'll do when running simulations in environments where processor power is constrained, where you will render things with decreasing fidelity the farther away they are from the player character. And so in this context, the player character would be the vehicle under test. And so we don't really need to be modeling all of the detailed electrical dynamics of other vehicles that are more than a few hundred feet away, say, in order to get the sort of simulation we need. And that would take just prohibitive Amounts of processing power. It's sort of like GTA style world with a focal area simulated at very high fidelity and decreasing fidelity the farther you get from the vehicle under test is one way of doing this. Another way of doing this is that's very common is simulation using data replay. So essentially extremely well instrumented test mules being driven around under various conditions, recording and logging all of that data. And then the environments that we use having the ability to replay that data in whatever format is needed for the virtual simulation. So you can see how a vehicle would perform under exact real world scenarios gathered at the sort of limit of what it's reasonable to collect in terms of real world data fidelity.

Ah, very interesting. And you know, that gets me to the different approaches that people are taking with self driving car software and their simulators. And this data acquisition and replay touches on it. And in some sense you can say there's sort of Tesla and everybody else, right?

Yep.

Tesla has got vastly more data. Then also George Hotz's comma also uses this approach that I understand get vastly more data. But best research I could find showed that Tesla uses considerably less software simulators in the loops than the other guys do.

Yes, they also, as a general statement, with very few exceptions, build their testing stack in house in a way that is not considered industry standard, which has both advantages and disadvantages. Many of the other up and coming self driving or robo taxi or self driving fleet vehicle type startups were people that I worked with in this industry never worked with Tesla because they do everything in house and have a very different approach and philosophy to it for sure. So I would say that the classic or legacy auto companies are very focused on the sort of hardware in the loop testing. They want to virtualize as much of that as they responsibly can. But this is difficult. There's some things you just still need to do a lot of physical testing for from their perspective. And they have a lot of expertise with doing this sort of thing. So it sort of plays to their strengths. Also, the data replay thing, obviously like you mentioned, Tesla has just massive amounts of data that they've gathered over the years they can use for this. And so there's a sort of question of is it worth it to go out and collect all this data, which the data collection process is fairly expensive, or is it better to invest in being able to just simulate virtual worlds at a very high degree of fidelity and do less of the data replay kind of thing. So both approaches seem reasonable to me, but I have more experience Personally working in the one where you do the highly detailed simulation as opposed to simply replaying back the collected data.

Interesting. Now it seems like the guy that's furthest ahead today is focused very heavily on that strategy, which I would say is Waymo.

Yeah. They are obviously top tier with a significant first mover advantage in terms of actually self driving cars I would want to be in, let's put it that way.

Yep.

Though I do have to say that I think that in particular the General Motors Super Cruise in terms of the like not full self driving but high level ADAs or driver assistance suites is really best in class.

We'll get to that later. Some of the different companies and their approaches. Waymo for its taxi service has, as you said, really gotten a jump in terms of. I start getting videos like one or two a week from friends of mine who've been to San Francisco. Look at this. I'm riding in a driverless car. Holy shit. And I ask them any weirdnesses on it? And they say not really. Other than maybe it's a tad more cautious than your Uber driver, but not that different.

Yeah. And that's a feature, not a bug. In my experience of being in Uber is in the Bay Area, honestly.

Yeah, exactly, exactly. Now let me just do a little sidebar here because it comes up probably more in the Waymo case than in the, you know, level three type cases. And that is, it's well known that Waymo has a number of central office dudes that intervene when the software tells them it's confused. Right. And you hear various stories. I mean some say that they need to intervene every five minutes, others say once an hour, irrespective of how often they have to intervene. When these simulators are built, do you simulate the availability of the human Oracle to intervene at various points?

This is a thing you can do. I would say that the bulk of the tests done in virtual environments that I was working with, this would not be the case because the focus was on massively parallel simulations deployed to the cloud, running in hopefully faster than real time. That's going to be something that's fairly difficult for a human to intervene in. We sometimes would have things that were specified to run at real time. And in this case it is definitely a thing that you can do that people do to provide a virtualized version of the human, get summoned to intervene. And so you have a human with a little Logitech steering controller and pedals and so on that can be hooked up to a device that they can actually adjust a PC that can actually just remote into the car and do that. That's definitely something that can be done there. I'd say it's a relatively small part of the testing because in general, all you need to know is that a human had to intervene. That's a failed test case and you need to figure out what went wrong there. And since we're in a virtual world, no humans are actually harmed in this process. So you'd only be doing this if you were testing the hardware and software that allow the human to connect and intervene in real time. So you do need to be concerned with things like latency and ping and whether the controls loop is working correctly there. But yeah, so it's a relatively small aspect of the virtual testing in my experience.

That's interesting. Yeah. One could imagine building a virtual human. Right. That is at least as fast as the rest of the simulation. And while the virtual human probably wouldn't be quite as good as a human, at least it would be able to simulate this handoff and then hand back, which is, I'm thinking, from a systems perspective, is a very tricky thing to do. When to decide to, irrespective of the actual work done in the two black boxes, for black box A, the onboard computer to say, oops, I'm fucked, let me ask a human to help, and then for the human actor to decide to transfer back to the black box, irrespective of what's happening in the two boxes. Just that transition is a hugely difficult and very substantive question.

Absolutely. And so it is a very fascinating question, and one which I believe in general, the more traditional auto companies that I spent most of my time working with aren't really dealing with that much as a practical matter, since their main intended customer base for these advanced systems are still individuals owning their own vehicles, in which case that's going to be a pretty hard sell. That somebody who works for Ford or GM could like take over my car, that I wouldn't want that car, as opposed to companies like Waymo and some of their competitors who are primarily focused on robot piloted Ubers, basically.

While I was doing my research for the episode, I discovered something that if I known about it in advance and thought about it, probably would have made it been obvious to me, and that's that there's really two classes of problems that different players are trying to solve. One is the truly driverless solution, like Waymo or Zoox or Cruise, if they ever get back into that game. And supposedly Elon's gonna announce his taxi Solution on the 14th of October, we shall see versus the driver aid class of things like the Cruise Super Cruise. Mercedes apparently has a pretty good one in Japan. I think Honda's got a pretty good one. And that's almost by definition to your point. No human helpers behind the scenes, because who the hell would want that? Nor could they afford it, nor could they figure out how to price it, nor would they want the legal liability. And so they have to get to where they're getting without that aid. While the taxi companies or the true self, no driver cars, at least for a while, can cheat, quote unquote, by having the human be able to intervene in a complicated situation that software throws up his hands. Is that a reasonable way to divide the world into two big chunks?

Yes, it is. I would say that Tesla seems to me to be the one that doesn't fit into either discreetly or I should say maybe fits into both. Elon seems to be telling people on Twitter that they will be able to buy a Tesla as their personal vehicle and make money by having it be a robo taxi while they're not using it. And so this is an actually very cool business model if it can be pulled off. And I'll be interested to see how this plays out. Tesla is in some sense the company that has to solve the sets of problems associated with both approaches. But yes, in general that dichotomy makes sense as a way to classify the different sorts of problems that these two kinds of companies are going to be emphasizing.

Yeah, the other dimension and these two things kind of intersect in a non equal way is those systems designed for hyper detailed mapping versus those systems designed to be used anyplace or almost anyplace. Talk about that a little bit.

Yeah, so there's basically going to be in any system and whether it's on the robotaxi side or on the this is my personal vehicle and I want to be able to take a nap on the way to work side. There's going to be situations in which you don't have access to good global positioning data. So almost all of these vehicles can, you know, listen to both GPS and GLONASS satellites and they can do somewhat less accurate cell tower based location triangulation and have some level of essentially inertial navigation capability built in. But any of these data sources may be inaccessible at any time. You have to assume while designing these systems. And so these systems also have to be capable of what's often called SLAM in the industry or simultaneous localization and mapping. So where you are taking your sensor data, your lidar point cloud and your camera streams and your wheel speed sensors and all the other available data. And doing a thing where a model of your environment that contains you and a map of the environment is being built in something like real time and refined in something like real time, which would be necessary when let's say that your inertial navigation system gets somewhat busted and there's some sort of crazy storm system. And so they just had a hurricane in Florida where I'm originally from and like power's out so cell towers aren't going to be alive for. And maybe it's so stormy that you really can't get a good GPS fix. Well like the self driving car still has to be able to navigate in that situation, at least enough to be able to safely pull over in somewhere that's not flooding or whatever. Right. And so all of these systems need some sort of slam capacity as well as a more traditional navigational capacity.

That's interesting. As far as I know, Waymo has been very carefully rolling out its taxi service. Only in places where it has done specialized hyper resolution mapping. Do you know that to be the case?

Yeah. So basically a simple way to put this is you need to know where the dangerous potholes are. And that does not show up on any of the publicly available, you know, street map systems. Whether it's, it's Google, whether it's, I think they go by here or whatever that thing is calling itself these days, OpenStreetMaps. And none of these are gonna have anything like real time, accurate or even to the weak accurate pothole information. Which if you're ever going to try to do self driving in Michigan, you absolutely need. So it's not just for the record Waymo that does this. Even the Detroit Big three also have highly instrumented vehicles that go and collect this sort of data for similar reasons. Because the ground truth of the state of the road and what the actual road configuration is can be quite divergent from Google Maps in any number of ways. And this is very important to get right and not wrong. For example, did a street become one way recently? You really don't want your self driving car turning the wrong way down a busy one way, which it would do if it were just paying attention to the Google or Apple Maps data, say for example, because those often don't get updated for in some cases weeks or months after such changes are made in traffic patterns.

We just got back from a driving vacation in eastern Canada where they're trying to cram the construction season in before the snows Come and there was rather complicated, rather dynamic changes to the road going on based on what time of day it was, whether the crews were working or not, whether they had restricted because they were replacing a bunch of bridges, whether they were allowing one lane or two lanes staggered over. And this would change at different times of the day. So trying to keep up on that data is going to be essentially impossible. Presumably that's something that the car has got to figure out.

Right? So you do need the car to be able to figure out what routes are safe regardless of what it thinks is legal is one way of putting this. And to prefer violating traffic laws to hitting a bunch of construction workers and traffic cones that aren't on its map, for example, that seems like a fairly obvious preference you want the control system to have. And then this kind of gets us into some interesting territory where different manufacturers are going to end up making different decisions in basically different sorts of ethical dilemmas related to the trolley problem. And which sort of decisions, which sort of theory of ethics there do you want your car to have is quite important. So for example, many people might prefer their car to avoid a medium probability of serious medical damage to them, even when this increases the probability of serious medical damage to other drivers or pedestrians. For example, a self driving robo taxi company might want to do something closer to some sort of Rawlsian veil of ignorance. Everybody's equally morally weighted kind of utilitarian calculus in a similar decision. So that's something that people are going to end up needing to pay some amount of attention to. Because even among the companies doing current driver assistance systems, the way they make decisions in these sorts of emergencies are actually quite different in terms of how they prioritize the safety of the occupants of the vehicle relative to various other humans.

That is interesting and a bit scary. One could imagine ethics as a service, right? The normal treats all humans as equal, but if you pay an extra hundred dollars a month we'll run over pedestrians before we'll hurt you.

Right? And now I think that's unlikely to be offered because offering that choice seems like it would create a sort of obvious legal liability for the company providing that choice. If it could be shown in a court case, for example, that my wife got ran over by this car and wouldn't have if the company had not offered this. There's an interesting tort involved there.

I agree that no one's going to do it quite so blatantly as that, but they may be able to do it subtly, which of course this actually gets to an interesting Point, which is because auto accidents are often big stakes, plaintiff, lawyer claims, and if they ever get around to class, I'm sure they will. Class actions, there's going to be a scary amount of disclosure that's going to have to go on in this litigation. When you guys are working on this software, are you considering that? Are you documenting your decisions? Do you have an ethicist involved? What do you think is going to happen when the absolute deep dive in a multi billion dollar class action lawsuit against, let's say Tesla occurs? What are they going to find?

So I can't speak to Tesla in particular. Like I mentioned, they are far less integrated into the automotive industry's general sets of tool chains and suppliers and practices than essentially any other manufacturer at their scale. I can speak in general about this to some degree. So I am in some sense just the guy who is helping create and show how to use the sorts of general purpose tools you would use to design and test systems of this sort and customizing them to the needs of any particular manufacturer. That being said, you do get to be a part of some interesting conversations even in that sort of role. And I think a large part of how this is currently and likely to be handled is through demonstrating adherence to various internationally accepted functional safety development process standards. Like the big example here is ISO 26262 is an international standard for functional safety that makes a bunch of, puts into place a bunch of requirements for the ways that you will be thinking about and documenting your decisions that could potentially have an impact on the functional safety of the system that you're creating, both for the user and in terms of creating externalities for third parties. And so in general, it seems like this is probably going to be pretty important in any future litigation because if you can demonstrate that you successfully adhered to the relevant generally accepted international standards organization standards for how to do this sort of thing, then that's going to be a fairly effective thing to say in your defense here, even if you know something happens.

Give me an example, if you can by chance remember it. What is something that is specified in this standard that might actually have some salience in a lawsuit around a crash?

Okay, so it's a pretty gigantic standard basically. But so it covers functional safety aspects of the entire automotive life cycle. Everything from management practices in the company, development practices, production practices, servicing practices, decommissioning practices, etc. And so we're basically looking within ISO 2626 to a keyword here is a safety life cycle. So there's a sort of specified decision loop for how to identify and assess hazards, AKA safety risks and establish specific safety requirements to reduce those risks to acceptable levels. And this includes things like. So for example, one of the reasons why everyone uses Simulink by the MathWorks to generate their code for this is because it is ISO 26262 certified, as in like, there are third party auditing organizations which certified that the code that it generates are going to be compatible with this sort of process. There's also things like Misra which you may have heard of, which is a subset of C of the C programming language, which is designed to basically if your thing is Misra C compliant and you can and these companies do like purchase independently third party certified static analyzers to ensure that their code is in fact Misra compliant. So one of the things is it essentially has to be fully analyzable with a couple edge case exceptions of being fully analyzed by a static analyzer tool. And also a lot of what goes on here is using things which implement some of the more interesting automatic theorem proving technologies like CoQ or Lean in an automotive context to formally prove the correctness of code. So that's one sort of thing that you'll see as a downstream consequence of participating in these kinds of standards. And you see stuff like that throughout the development life cycle, basically.

Wow, that's really interesting. Now I'm putting my plaintiff lawyer's hat and revisit a conversation we had earlier, which is in a world with limited computational resources I.e. any real world, there's constant decisions made on what level of course graining to operate a simulation at.

Right.

One could imagine that being questioned. Mr. McMullen, if we had run the simulation here on the, you know what happens with the ABS system under black glare, ice in the fog. If we had run that at high simulation 20 times more, would that have prevented this accident from occurring? Do you think that how the simulators are built and then actually used in testing systems, is that going to be a reasonable place for plaintiffs lawyers to, to push? Because obviously decisions have to be made all the time that are basically bounded by economics. And we know that if we had infinite computation, we would have done something else.

Yeah, so I mean there's basically I think something like a reasonable affirmative defense to claims like this. If you can demonstrate that you followed the relevant national and international standards here for how to do this kind of risk assessment, how to have a functional safety oriented production process and culture, et cetera. Because it seems somewhat similar to no one ever got fired for buying IBM in that if there's generally recognised best practices and you can demonstrate that you made a good faith effort to follow those generally accepted best practices, then this is going to be a fairly decent shield for most kinds of liability in the relevant circumstance. In terms of the actual practicalities of gaming out a situation like this. As you mentioned, these vehicles collect an enormous amount of data and so does the development process. And some of this is going to be relatively difficult to disclose. In a lot of civil actions because of privacy concerns as well as essentially proprietary corporate secrets concerns, this will get fought quite a bit. But even conditional on getting an order for discovery that does what the plaintiff's lawyer wants it to, it seems like these cases would be extraordinarily expensive to win because in order to go through all that data and claim that something was done wrong there, you're going to end up needing some very expensive and currently and very high demand skill sets in your expert witnesses. And so whether or not this is worth it for the. I mean I can only see a very large scale class action being worth it. And my current understanding of the actual level of serious injuries or fatalities caused by these self driving systems is that they are significantly safer than humans at this point. The best ones are in the environments in which they're allowed to operate in terms of statistical risk profiles. And the kinds of accidents they get into are also less dangerous than the kinds of accidents that humans on average get into. So I don't see there being really a sense of a really juicy reward for the sorts of attorneys that tend to do these kinds of class actions. Although I mean the time will tell, it'll be interesting to see, it'll be.

An interesting moral, legal, ethical question and economic where all those come together. Say for instance, and I believe if it's not now, then soon self driving cars will clearly be safer in the statistical aggregate than the statistical aggregate of humans. I said even when conversations were first started about self driving cars, I said the idea of having a perfect self driving car is really, really hard, but better than a human. Maybe not that hard. But suppose that the humans would have killed A, but the self driving car ends up killing B, right? So even if in the statistical aggregate self driving cars have made the world safer in a particular tort, and keep in mind that the English common law system which America has, it's about specific cases. And so one could imagine the auto industry saying yes, it was B instead of A, and if it had been a driver, probably A would have died rather than B, but from a social Utility perspective, our system in the aggregate does a better job of protecting the populace. Sorry B, you got run over. That was the cost. It'd be very curious to see how the legal, ethical, economic systems deal with an issue of that sort of.

Yeah, my guess is that we get something that sort of weirdly rhymes with section 230. So what I mean by this is this is sort of safe harbor provision for, you know, user generated content on say that has allowed the modern web to exist in the form that it does essentially with things like Reddit and social media and so on, which essentially removes the ability for a injured private party to successfully sue for a specific set of common law torts. Right. That they otherwise would be able to under common law precedent and norms. So I think that this is what I would guess we will get when the regulators and politicians are convinced that the tech is good enough is something like a blanket liability shield for companies which have followed certain types of processes for certain types of tort claims, wherein probably the federal government or state level governments retained the right to go after them in the context of consumer protection suit by their attorney general. But similarly to how I can't sue most places for online content successfully because of 230, I think we get a similar kind of liability shield equilibrium here basically.

And actually from a social utility perspective that makes sense. You know, once you can demonstrate that in the statistical aggregate society is better off with self driving than human driving. Even if plaintiff B would not have been killed with a human driver. It's going to be very interesting to see how that works out in our politics. Because humans are fucking weird and stupid in many cases. Oh yeah, it's not clear that we'll reach that which probably the right social utility. This is actually a perfect transition to my next topic which is to what degree do companies use shared tools, you know, things like Nvidia DriveSim or Carla or what another one I found Apollo DreamView, few others versus develop their own or some of both.

So I would say that the, for lack of a better term, legacy auto industry uses to a very high degree shared tools primarily. So what I mean by this is in the context of working with DSpace, I worked with nearly every legacy automaker as well as just for the record, this sort of testing exists in most mechatronic contests. Also in aerospace, heavy vehicles, power systems, et cetera. All use the same kind of tool chains and often the same vendors of those tool chains to do this sort of testing. And of course there are many notable companies in this. But there's more like three or four notable companies that sell hardware simulation tools like hardware in the loop simulators that can be customized to the needs of specific enterprise scale customers. Same thing. Almost everybody ends up using Simulink by MathWorks or one of a couple smaller competitors for model based design and code generation. Almost everybody ends up using the same couple vendors to do, for example, implement system C models of their physical electronic components and so on and so forth. And so there's a lot of similarity between the sort of building blocks that you build your testing infrastructure from. Companies obviously make individualized decisions about how to build something out of that set of Lego blocks and also do some amount of in house development. And this varies quite a bit by company to sort of keep the vendors honest as well as due to the organizational structures of these gigantic companies, they'll often have a research division that's not really talking that frequently or directly to the division that's actually designing the production vehicles. And that research division might have some in house simulation tools that they have developed for their own purposes. And then the newer companies like say Canoo and Zoox ended up doing something where it seems like, it seems to me like they started out trying to be a bit more Tesla, like in their wanting to do a bunch of stuff in house, ended up becoming customers of the legacy simulation tooling providers relatively quickly because of how tightly integrated those providers are across the supply chain. So for example, it's not just OEMs that use these kinds of tools. I have done projects with tier one and tier two suppliers. So for example, like Ford or Toyota, they don't make electronic power steering units in house, they purchase them from one of a small number of tier one suppliers. The same goes for just about everything that's not the engine block, you know, in the vehicle, transmissions from zf, Rison, et cetera, et cetera. And so all of those sort of parts of the ecosystem also use these hardware and software in the loop simulation tools. And so it's very useful to be able to share simulation infrastructure. If I'm say ZF and I want to sell you my transmission, if I use the same testing infrastructure and compatible data formats, I can provide you with all of my recorded testing data as part of a contract to supply you with transmissions, for example. And this is an advantage as opposed to everybody having their own in house stuff that doesn't know how to talk to to each other.

That's interesting. That network effect makes this even stronger because the issue going from in house tech to third party tech is something that's happened again and again in the history of computing. I'm an old dude, I remember back in the days we used to write our own database engines. I wrote a few database engines back in the early 80s because computers were slow, memory was limited and the commercial databases just were not anywhere near optimal. So to do the kind of things that we needed to do, we had to write our own, right? But now only an idiot would design their own database. I remember even we had some need to increase the capacity on the RS232 serial port on our VAX. And so we wrote some micro code to actually modify the controller on the VAX to improve the throughput on the RS232 controller. I mean today that would be insane. And so there's always this migration away from do it yourself at first because especially the innovators get there earlier and get an advantage. But then the commodity tools get better and better. And then often cases the open source tools then compete with the commodity tools. But in this case I think there's an even stronger one, this network effect between the Tier 1, Tier 2 suppliers and the vendors. And I would add probably soon the regulators. Regulators are either going to have this capacity in house or probably more likely because they're dumb. We'll have third party consultants that are able to operate these tools for being able to validate whether people are in compliance with the standards, et cetera. So it seemed to me, me again not knowing shit about it never stopped me from talking about something before. There's a set of force field dynamics which will essentially force everybody eventually to using third party software as much as they can.

That seems right. And one thing that I experienced at least within my niche in this industry was a much greater level of acceptance of open source components of the tool chains, a much greater need to, to move in that direction for interoperability reasons. And that was exciting to me. I'm an old open source guy myself, insofar as somebody who's 39 can be old and have been very excited by the degree to which. For example, previously when I sort of got into this space, people were for the core OS of the hardware in the loop simulators, usually using either QNX or vms as far as the operating system kernel with a highly customized user land, of course, right? And then by the time by say now these proprietary hardware in the loop simulators are mainly running a highly customized version of a Linux kernel with preempt rt, right? So the real time patches for the Linux kernel and so this Obviously saves a bunch of licensing fees and so on, but also means that it's much more open and extensible and customers can customize things to their needs if they have, you know, experts in real time systems on hand, which they of course do, being embedded hardware COD companies. And so that has been a very encouraging move. Also move to more open data formats for interchange and so on. This has been quite encouraging in the industry to me. And so I think you're right about the sets of incentives and forces which are sort of pushing things in this direction.

You mentioned two of my old favorite operating systems, VMS and qnx. We were quite VMS hackers in the day and I did one very interesting project on qnx and those things worked really good for control systems. But like everything else, standard stuff gets better and better. Computers get faster and faster, so more and more problems just fall into the commodity. So betting against commodity long term is often a losing game. The higher level simulator. Some of the software I found one I specifically asked for open source and a platform called Carla came up. What do you know about Carla?

So I basically only know about Carla's existence. There were some contexts in which people who I dealt with in the industry were sort of considering using it. That being said, this sort of pressures created by commitments to adhere to the sort of international standards that I mentioned require tool chain providers to get certified by third party independent testing companies. And these are the sort of consultants that are very expensive. So there's a sort of strong culture of taking open source tech and integrating it into a paid product that you then are responsible for. And you make a bunch of money from selling licenses to and or selling integration services, you know, support services, workshops, teaching, that kind of stuff. That can be a nice revenue stream. But it's very difficult for an open source project to generate enough revenue per se as an open source project to get the kinds of certifications that the large enterprises here are in some senses going to be required to have.

Yeah, that makes a lot of sense. And particularly back to our previous conversation about potential class action lawsuits. You know, a person making a decision for a major corporation is going to want to push as much liability down as they possibly can. So if their simulator person is, you know, standard compliant, certified, such, et cetera, it's at least a partial safe harbor in the inevitable case of litigation.

And if something goes down, if you bought something from a company, you can sue them for damages. Are you going to sue some random Slovenian hacker that wrote a good portion of a simulation engine that you Downloaded off the Internet. I mean, you can try, but good luck collecting on that. And how much are their assets anyway? So that's another incentive in this direction.

Yeah. It's interesting you mentioned, because when I worked for Thomson, now Thomson Reuters, we found a very interesting acquisition niche, which was to buy companies that had great products but were failing in the marketplace because they weren't big enough to sue. And we particularly found this niche in accounting software for Wall street, where stakes are hugely high and some of the best companies were tiny. And so we buy them, not change a goddamn thing, but say, hey, they're now owned by somebody big enough to sue and their sales would go skyrocketing. It's a very interesting theory that in some economic, legal niches, being owned by somebody big enough to sue is actually a useful attribute, even if you change absolutely nothing else about the product and the company.

Yeah, this acquisition pattern definitely happens in the industry that I sit here. Absolutely.

Now, another one I came up with in my little bit of search is Nvidia's Drive Sim. You know anything about that?

Yeah. So that's a thing that gets integrated into a bunch of these sorts of tool chains. And it's, at least according to my understanding at the time, I could be in correct about this at present. It's the sort of thing like a lot of Nvidia's tech that is in some sense designed to be integrated into other products or other services. And so it's definitely can be a core part of a lot of the tool chains that end up being developed. It's not the only thing of its basic category there that is, you know, available. And I, at least as of the last time I checked, I am not sure that it has anything like market dominance, but it is quite interesting and useful.

What are some of the other players in that category?

The sort of company that I worked for and their competitors are basically in competition with this. So DSpace has an equivalent tool chain, I believe, probably ETAS also does. They're another company with a very similar sort of product portfolio to DSpace and a fairly major competitor, some different specializations, but definitely in the same space. So going up against Nvidia is very tricky. But the network effects, like we mentioned earlier, that already exist, these two were sort of, as far as I could tell, being on site at various development offices of various automakers and suppliers and so on, they'd be filled to the brim with a combination of DSpace and ETAS hardware and software in a way that the Nvidia stuff was Just sort of starting to take off and become available.

Too bad I'm not 45. This would be the perfect rut type business. I did most of my ventures in narrowly focused business to business areas where you could figure out what the customer wanted and the hard part was giving it to them. But the marketing was easy if you could create what they wanted because most companies fail for marketing problems rather than product problems. But anyway, I'm 70 so I ain't gonna do no more fucking cop. Leave it to you guys to go out and make some money. Now another one I did come up with that someone online said was big was called Viress V I R E S V T D. Do you know anything about them?

Yeah, familiar with them, like I said. So not a ton of experience there because I was working for a specific company which had its own stack and products in these areas. So VTD is an open platform. So this is another, another thing that's actually worth talking about in general. Right. So basically when you look at vtd, so when I say open platform, it's going to provide implementations of a bunch of relevant ASAM standards. So I'm not sure if you came across the asam. It's basically a trade group for automotive simulation and modeling. And so a lot of the relevant standards are, are in the area going to be ASAM standards for development of automotive architecture. So really notable one here is called Autosar, which essentially started out as a standard for providing standardized APIs to individual software components in a vehicle ECU so they could be reused across different projects and architectures and even potentially companies. I'm a company that provides a, you know, certain type of like wheel speed sensor or ADC or whatever, you know, that's going to be integrated into a vehicle. And of course you're going to need a driver for that in your controller. And previously I would have had to create some sort of customization for each separate customer that wanted to buy my thing because they're all going to architect their controllers differently. But Autosar provides a standardized set of essentially wrappers C APIs for this thing and also define standards for doing code generation of the glue code between all of these software components and wrappers and how they interact with the operating system and other low level drivers and so on. Autostar standards are fairly important, or ASAM standards, I should say, which autostar is one, are fairly important in this arena in general. And so for example VTD supports open drive, open scenario, et cetera, as far as some examples. And so those are of course going to be standards for doing driving simulation and scenario generation and so on. So this is something that the actual companies doing, the products in this world really are incentivized to support are these Autosar standards which provide for interoperability between different parts of the tool chain that they're developing from different simulation providers.

Though of course I've seen this before in other industries. Everyone wants to cheat around the edges, so it works for them, but disadvantages the other guy. Unless there's a really strong network effect reason not to.

Yeah, so I was one of the Autosar experts in my organization and I spent a lot of time essentially creating some custom scripting tools for various organizations to route around that sort of damage. Basically it's the same crap you saw with web standards, CSS and HTML and JavaScript standards between the big players there. And so you end up having to do as a user of these tools, you do end up having to do some extra data funging work basically to get the entire ability to play right. So we support Autosar 4.7.1 with a little asterisk where we don't support these few different constructs of the schema. And everybody's asterisk says slightly different things. So it's obnoxious, but it's not usually a huge impediment. If you have somebody who's decent at Python around, that's good.

The obvious game theory says that you should in certain circumstances as a vendor, try to landlock your fucking customer by doing shit like that, even though it's damaging to the ecosystem as a whole. It's one of the fundamental problems of late stage financial capitalism that the multipolar trap locks people into doing antisocial things because it makes money when it works. Which is unfortunate, but I'm glad in this case that the workarounds are not too bad.

Well, and also these companies, even the ones we considered our competitors because we all have the same customers, we ended up having fairly good working relationships where I could be ingesting some large XML file from a competitor's product and the customer would cause that competitor's engineers to get on a conference call with us so we could figure out how to make this work. So I think people started realizing that they were burning a ton of unbillable engineering hours to support their customers to be able to do things that the marketing copy claimed that the products could do in terms of openness and interchange, such that it actually isn't cheaper to not support the, you know, the economics actually don't work out that well. To try to do this kind of lock in in this case. So it was more cases of genuine. It's kind of hard to get full coverage of the standards. And we have different emphases than it was nefarious intent on the part of other vendors.

Oh, that's great. That's good to hear that. It's all cultural too, where we make the decision together that we're better off making the. You know, it's like prisoner's dilemma that if you cooperate, there's a win for everybody. If you don't, everybody pays the cost. But from a micro self serving perspective, sometimes it seems like doing the wrong thing is the right thing to do. So I'm glad this case did. When I was doing my research, four areas of challenges were called out. In the area of vehicle simulation, which are the reality gap, scalability, edge case generation, and hardware and sensor accuracy. Any of those you want to talk about? Maybe all four of them.

So let's say the hardware accuracy thing. This is definitely interesting. And I mean so. So for one project I worked on, we ended up having requirements to develop a system such that we could do clock cycle accurate emulations of the target processors as well as clock cycle accurate emulations of the analog parts of this as well. So for example, the ADCs and other inputs to this had to be simulated at a physical electrical level, which meant that this thing, even on the very fastest modern hardware, could not run in anything close to real time. However, it's still cheaper than outfitting a vehicle and instrumenting it and paying engineers to drive around. And so you end up doing some amount of this. But there's serious trade offs between accuracy reliability and simulation speed, such that this gets to be expensive fast because you also, for example, want to be able to simulate, and this was one of our specialties, electrical failures at basically any part of the system implementing the control loop. So we want to be able to simulate what if a mouse lives in your car and chews through the insulation on the can bus line, right? Or the automotive ethernet switch becomes a little bit wet and flaky. And so being able to do that kind of failure or fault injection is extremely valuable. And there's of course the simple level of fault injection where you can just tell the system the following fault occurred. And then you can also do the more interesting kind where you are creating the simulation such that the system's own fault detection systems ought to throw a fault and you're testing the fault detection system itself in an interesting way. So both Both levels of testing definitely occur and have very different constraint spaces.

Ah, that's quite interesting. And obviously, you know, again, there'll be economically driven trade offs on just how accurate you can afford to make it. And again, there's then wisdom involved in deciding where to spend money on the very highest resolution and where you can get by with less resolution.

Absolutely. And into the design of these systems themselves, there's also a very similar set of trade offs. For example, you could basically rank automotive bus systems. Say you've got the Len bus, then the can bus, and then now things like various automotive ethernet based standards where in some of the cheaper systems you don't even have message acknowledgments as part of the bus architecture. Right. Which is kind of fine if you're writing a controller that basically is for rolling up and down your windows or something like that. But for anything more safety critical, you want to get some acts and then does it support encryption and if so, what kind? There's a whole set of standards since most vehicles now have built in Internet access. Right. They are their own 4G or 5G modems and receive over the air updates. And so the security concerns here also have to do with, not just the financial concerns, have to do with how these systems get architected and tested. And so one very fun thing to do is to participate in red teaming an Internet connected car and seeing what kind of mischief you can get into.

We're going to not talk about that topic. I had it on my list, but we got lots of other, which is hackability of these things. We could talk for two hours just on that. All right, one other from this list of issues, and it relates to a level I hadn't really thought about, which is what they call edge case generation. I was thinking in terms of the outer world edge case, but you also have the internal edge case failure modes on various devices driving into a strong electric field or something. But I think I'm more interested in discussion of edge case generation for these world simulators. Do you have any thoughts about that?

Yeah. So one way to think about this is the naive way to do this is to basically implement a fuzzer. Right. For this sort of thing. So this is a term from just cybersecurity in general, where you're essentially creating a system that will fuzz the inputs of some other system and it might do so in an essentially random way. You know, some random number generator just sending out stuff in the possibility space of the messaging protocol or stuff outside of the possibility space. Messaging protocol but that would be physically capable of being carried by the physical layer of the network architecture. And so you're essentially trying to figure out how to write an opinionated fuzzer for the system in the virtual world, which is going to hopefully spend relatively little of its time finding boring edge cases and relatively much of its time finding ones that might have some safety critical implications. And so there's been some very interesting work in this area which I can't go too deeply into the specifics of, but which involves using basically some of the more interesting modern neural net architectures to be this sort of generator, be this sort of edge case scenario generator. So you're essentially trained, think of training an adversarial model. Here is one approach that people are taking that's quite fascinating.

Yeah, that would be quite interesting. How do I break it? Right. That's the old classic Gan approach. Let's give your Evan McMullen, smart guy, but not necessarily expert in the particulars, your take on the current self driving for consumers side of things. What do you think of this? Pick three approximately of the ones that you'd like to talk about and tell us the pros and cons of them.

I think that in general the tech is quite good in terms of its capabilities. I see the biggest problem right now with most systems being on the user interface, user experience side of things. So. So for example, some of these systems, and I believe last time I checked that GM Super Cruise does this more or less in the way that I want a thing to work and a couple of the others. I think it's been a while since I've played with it, but I think the Mercedes system can also do this. I do not want to and should not have to look down at a screen behind my steering wheel or above my steering wheel. I should not have to look away from the road to get the most safety critical signal from a driving assistance or self driving software. So for example, lane departure warnings are very common or blind spot detection is very common and in order to see where it's detected something in most systems for most companies I have to look at a screen. This is terrible. The right way to do this that I've seen so far is having a bunch of haptic vibration motors under your ass. And so I'm departing the lane where there's a vehicle coming up in my blind spot behind me, right section of my ass vibrates and same thing with like front left or whatever. Oh, I'm forward collision warning is going off. Well then the front part under my thighs is vibrating like a hornet's nest or whatever, right? And these are very easy to learn. They kind of freak you out for like the first week of owning a car. Then they become second nature to interpret as part of you the driver's world model and really give you that without the critical distractions of having to move your attentional focus from the road and piloting a multi ton hunk of metal to interact with some screen that then pulls in all of our weird associations with screens in the modern world. So I think that we're doing quite well with how well the tech works and how good it is knowing when it should be off as well. So for example, you know, driving back from Burning man recently, you know, getting a notification that all these systems have turned themselves off because. Because it's crazy dust storm and they're not going to work anyway and it would just be bad data. They're pretty good at reflecting on that and making those decisions themselves. But it's how this data gets presented to the user and is that even a net positive like only the ones that do the vibration type stuff will I even turn on. I'm a pretty good driver with good situational awareness and having a bunch of random beeps and shit happening on a screen all the time is going to make me a worse driver. But having the right kind of tactile feedback in a way that fits in with the way we're using our perception while we're driving and essentially takes advantage of unused proprioceptive capacities that we have or you know, like senses like our sense of touch in our body. This seems like obviously the correct way to design these systems and I'm kind of disappointed that more of them don't work that way already. The research has been done and this.

Is obvious, interesting, but you say the Cruze, the GM Super Cruise is the one that does it the best as.

Far as you know, of the ones that I have personal experience driving relatively recently it was, I believe it was this one that did the butt vibration thing in a way I found really elegant and like this is the obvious solution to this problem. Duh. Why didn't everybody do it this way? And then I was, you know, as a counterexample, rented a car here in the bay and it was all stuff on a screen and beeps and it was horrifically distracting and I did not want it on.

Interesting. Now something in between a little different would be doing. Is it a heads up display? You know, more and more cars offer heads up displays where the data or messages are projected into the left corner of the windshield. What's your thoughts on that as a possible UX as opposed to a screen? I would never use a screen that just makes me want to vomit. But a heads up display might be tolerable.

So a HUD is good for displaying certain kinds of data that is relatively unlikely to change at certain rates. So for example, people are doing GPS navigation that should absolutely be on a semi transparent hud. And same thing with the. Since apparently we're just doing digital displays for things like your tachometer and your speedometer and so on and what the speed limit is. Cool, all that stuff. Definitely it's visual, it wants to be on the hud. It also doesn't change abruptly. There's usually not step functioning changes to where you are in the world or to your speed or to, you know, I guess engine rpms change a bit more, but given the prevalence of automatics, nobody really cares about those anyway. Again, for the stuff that can change on a dime that is safety critical. I really think that, you know, vibrational tactile feedback is the way to go. I want to see stuff like, you know, the really excellent R and D with vibration motors and linear actuators that say, for example, have gone into Apple products where they can do quite subtle variations in tactile feedback. I think that this is the way to present fast changing, safety critical information to users in the way that's least likely to distract them and cause them to get into an action. Especially because research has shown that when we're driving a car or when we're using a pen, we relate to these tools as extensions of ourselves. We extend our proprioceptive sense of where our body is in space to encompass the thing that we're driving, which is how we can do if one is fairly good at parallel parking. It feels like you're moving a big ass body into space rather than that there's a thing separate from you that is this car that you're. You're not paying attention to what are my hands doing? You're paying attention to how am I moving. And so integrating that sort of tactile feedback I think is natural since we're extending our body maps to these vehicles already when we're driving. And it's a natural way to integrate that information into our model of what we're doing in the least disruptive way possible.

I really like that. That makes a whole lot of sense. From a cognitive science perspective and a cognitive neuroscience perspective. We do know we have quite a bit of learning and plasticity available where you can repurpose parts of the brain. So you train your ass neurons to process the signals in your self driving car. Now the downside will be that we'd have to get some industry convergence for that to make a lot of sense. Because I don't want to have to train my ass one way then retrain my ass four years from now when I buy a new car. That could be quite annoying. Might lead to constipation, diarrhea or both.

Yeah, I mean this is the sort of thing where I think that basically NHTSA and ISO standards are going to be the way to establish the shelling point that we want here for this.

One last thing, because I can't resist. I know this is outside your area of expertise, but I'm just going to ask for blatant speculation. I personally have no use for self driving car tech as it exists today. Because I don't want to sit there and hold the wheel, look out the window. Fuck that. If I want to do that, I'm going to drive. I enjoy driving. I'm looking for where I can read a book. Maybe I have to sit in the seat, but I can be reading a book legally. I know people do it all the time. You read about people getting their heads cut off on Teslas and what have you because they're reading a book and run right back into the back of a truck. But what's your sense of when we'll get. Was that level 3.5 or something where you can be reading a book, not paying attention, not holding onto the steering wheel? What's your guess on when that's going to happen and who might get there first?

So I would say we've already got that in certain environments. There are certain environments in which I would not feel like I was taking a significant physical risk if I were in a Tesla reading a book. Same thing. Obviously I don't feel like I'm taking a risk by getting into a Waymo in SF and reading a book while it drives around. These are all strongly geofenced and I think that it's an interesting question and we basically have the technology. Is my sense such that it will be a shame if this is not a fairly commonly accepted practice as a thing that you can with a brand new car within five years. I don't think this will actually be the case, but I think the major hurdles are regulatory rather than do we have the technology?

Yeah, I did do a bit of a search this morning and found that as far as I could Tell there is no such self driving tech that is legally licensed in the United States to be used that way. So if somebody is reading a book while driving a Tesla, even in the most Geo fenced area and they have an accident, they still could be held liable.

Correct? Now I believe that this is not the case with the Waymo taxis, but that this is because that Google accepts the liability. And I think that this is actually a great market mechanism for figuring out how to do this sort of thing. If a company is selling you the claim that a vehicle you buy from them can drive itself, then they should also be willing to take liability for accidents that are incurred by that self driving system. And that's whether or not they feel comfortable doing that is a great way to get Bayesian evidence about the extent to which they believe their self driving system is actually good enough, enough. And so I will buy a self driving car from a company that does that and I won't buy one from one that doesn't.

Now it's a funny semester because I actually looked into this with a guy who's an expert in car insurance years ago when they first started talking about self driving cars, which was the theory that auto companies ought to issue their own driving insurance which they can calibrate to the quality of their self driving tech in their car. And of course they're not in the business of doing it. So our business thesis was we'd have white label car insurance that General Motors could issue, Volkswagen can issue, et cetera, and they could carefully calibrate not just with the driving record of the driver, but which car they're driving. Right. And oh by the way, they're getting a tremendous amount of telemetry on the person's driving so they can rate them once a year based on their actual feedback driving the car. As far as I know, nobody's actually doing that. So that was a multi billion dollar opportunity that never seemed to have happened happen.

Some of the car insurance companies are in fact doing this wherein they offer you a device that you can plug into the can bus of your car that will do telemetry logging and then they adjust your insurance rate up and down based on this and they claim that on average their customers save X percentage a month as opposed to their customers that don't allow for such telemetry and logging. I do think that especially that like GM and like the legacy auto companies are in some sense specialized banks that happen to make automobiles. Right. When you look at their actual profits, so much of it comes from their financing departments interesting.

That's been a very interesting conversation. I really want to thank Evan McMullen for a deep dive into the current state of play of self driving cars centered on an analysis and thinking about the simulators in the loop. This was truly an interesting conversation.

Yeah, it was great talking to you about this, Jim. I'm so happy to nerd out about this anytime, and I hope that people found the information useful and learned some new ways to think about this sort of thing. So I appreciate you having me on.

It sharpened my thinking about this. This is a topic I've been following, so really been a wonderful conversation. Audio production and editing by Andrew Blevins Productions Music by tom muller@modernspacemusic.com.