Showing posts with label safety envelopes. Show all posts
Showing posts with label safety envelopes. Show all posts

Friday, December 4, 2020

Motion Metrics (Metrics Episode 7)

Approaches to safety metrics for motion ultimately boil down to a combination of Newton’s laws. Implementation in the real world also requires the ability to understand, predict, and measure both the actions of others and the environmental conditions that you’re in.

The general idea of a metric for motion safety is to determine how well a self-driving car is doing at not hitting things. One of the older metrics is called "time-to-collision." In its simplest form, this is how long it will take for two vehicles to collide if nothing changes. For example, if one car is following another and the trailing car is going faster than the leading car, eventually, if nothing changes, they’ll hit. How long that will take depends on the relative closing speed and gives you the time-to-collision. The general idea is that the shorter the time, the higher the risk, because there’s less time for a human driver to react and intervene.

There are more complicated formulations of this concept that, for example, take into account acceleration and braking. But for all the time-to-collisions, the basic idea is: how much reaction time is available to avoid a collision? This metric was originally developed for traffic engineering, and was used predicting some aspects of road safety for human drivers. Time-to-collision gets pretty complicated in a hurry because, in the real world, vehicles accelerate and decelerate, they change lanes, they encounter crossing traffic and so on. So for safe highly automated vehicles we need something more sophisticated than a simple, “Here’s your reaction time for one vehicle following another.”

There are a number of proposals that address this such as Mobileye RSS, NVIDIA Force Fields, and the NHTSA Instantaneous Safety Metric. These ideas and more are at play in the IEEE Draft Standard Working Group P2846. But rather than go into the details of each of these individual approaches, let’s just sketch out some of the high-level characteristics, ideas, and issues.

The first big idea is that this is just physics. No matter how you package it, Newton’s Laws Of Motion come into play. The rest of it is just about how to encode those laws, reason about them, and apply them to everyday traffic. Some of these approaches attempt to provide mathematically proven guarantees of no collisions. And that can work, provided the assumptions behind the guarantees are correct.

While all this seems pretty straightforward in principle, when you try and apply it to real cars in the real world, things get a little bit more complicated. One of the topics that you need to consider is the various geometries and situations. Sure, one car following another in the same lane of traffic is a good starting point. But you have to think about cross traffic at intersections, merging traffic, changing lanes, non-90 degree intersections, and the list goes on. That means you need various different cases to work the math on.

You also have to consider the worst-case actions of other objects. For example, some cars can brake very quickly, some only slowly, some can turn quickly, and some slowly. Characteristics tend to be different for different classes of objects such as trucks, cars, bicycles, and pedestrians. In general, one way or another, you have to consider all the possibilities of one of these objects exercising its maximum turning authority, maximum braking authority, maximum acceleration authority, or some combination, in all types of different physical positions so you can avoid a collision.

Some situations are notoriously difficult to handle. One example is a so-called cutout maneuver. That’s where you’re following another car, and the other car changes lanes, revealing right in front of you a boulder that’s just sitting in the road, slow moving vehicle, or some other surprise. If you look at the math, that’s worse than the car in front of you hitting the brakes, because the boulder’s already at zero. Another difficult case is when you have oncoming traffic, you have to worry whether the oncoming vehicle will swerve into your lane going the wrong way. There’s not a lot of time and not a lot of room to react. Now, in an ideal world, none of these things would happen because everything would be well behaved and boulders wouldn’t appear in roadways. But the real world is messy place and so these types of things have to be considered.

Another thing to consider is environmental factors such as the coefficient of friction of the road surface, whether you’re on hills, and whether you’re on banked turns. The ability of other vehicles to maneuver and your own ability to maneuver is limited by how much friction you can generate against the road surface.

You also need to consider operational edge cases. For example, if you’re following a truck up a hill, you might do Newtonian physics math that says as long as you’re going slower than the truck, everything’s fine. But that may not work if the truck ahead of you hits ice and actually slides backwards down the hill.  (I've seen that happen -- up close and personal.) It’s actually possible to hit something from behind, even if you’re at a stop, because it’s going backwards into you. Now you can say, “Okay, that’s a special case out of scope.” But those cases will happen, and you need to do the analysis to decide what’s in scope and what’s out of scope for any assurances you’re making.

You’ll also need the ability to predict other system capabilities and decide what assumptions you’re going to make. For example, you might assume that a sprinter is not going to suddenly cross a four lane road in the middle of the block in front of you at 25 miles an hour. That would be faster than you might want to assume a typical human can cross the street. A related assumption is you might assume that the car in front of you is not able to brake faster than at 1g, one times the force of gravity, because if it can, your brakes may not be good enough to stop in time.

Now this one’s kind of interesting because it is about other vehicles, and that might not be controllable. You might say, “Well I’ll assume no one brakes at more than 1g,” or you might actually create regulations saying that when cars are being followed, they’re not allowed to brake at more than 1g. I’m not saying that that’s a regulation that should be passed, but what I am saying though is that limitations on vehicle motion might play a role in cooperatively ensuring that vehicles can move safely. 

Some of the efforts in this area try and prove that you’re unconditionally safe. But you also need to consider what to do when it is not possible to guarantee you’re safe. A simple example is, you’re following another vehicle in the same lane with just enough following distance so that if the one in front panic brakes you can stop in time, and someone else cuts in front of you. Well, you don’t have enough following distance anymore. You can say that’s not your fault, but you shouldn't simply give up and say there is not point trying to minimize the risk of a crash.

The question is, how do you behave when you’ve been placed in a situation that is provably unsafe in the worst case? To address that you probably not only need rules for ensuring you’re perfectly safe given assumptions, but also rules for reasonable behavior to restore safety or minimize the risk if you’re put in an unsafe situation and you have to operate there for a while. 

A bigger related issue is that in an extremely dense environment, you simply may not be able to unconditionally guarantee safety. If you’re going in a dense urban area and there are a bunch of pedestrians standing on the curb ready to cross the street, but you have the green light and you’re going through the intersection, it simply may not be possible to prove that if one of the pedestrians jump off the curve, you won’t hit them. Hopefully the higher levels of autonomy are doing things like assessing the risk that that will happen. But from a pure physics point of view, at some point it’s not possible to mathematically prove you’ll always be able to stop fast enough to avoid a collision, no matter what, if you actually want to navigate in a dense situation. 

This brings us to the idea of the trade-off between permissiveness and safety. Permissiveness is how much freedom of movement you have. You often balance permissiveness against the amount of safety or amount of risk you want to take. Sure, you can be perfectly safe by leaving the car in the garage and never taking it out. But once you go out on the road, there’s always some non-zero risk something bad will happen. The question is: what’s the appropriate trade off in terms of the physics, and how much slack you leave to minimize the risk of collision?

Along these lines, you may come up with trade-offs. I’ll give some hypothetical examples which might or might not be the right thing to do. For example, you might say, “It’s okay if the car in front of me brakes at 1g. But because that almost never happens, I can be a little bit closer so long as I will hit at less than one mile an hour relative closing by the time the car stops.” In other words, a fender bender or a light tap on the bumper might be deemed acceptable if you think it will almost never happen. You might say, “I can get increased road throughput by having the cars a little bit closer together, and really not worrying about the low-velocity impacts that are extremely unlikely to result in injuries or even serious property damage.”

Now, whether you go down this path is a public policy decision, and I’m not saying that this one example is what you want to do. But the idea is that the world isn’t a perfect place and there is a nonzero chance of crashes. So you should think about what types of loss events are generally acceptable as long as they’re infrequent, and which types of loss events you want to absolutely guarantee never happened to the degree it’s at all possible.

Wrapping up, approaches to safety metrics for motion ultimately boil down to a combination of Newton’s laws. Implementation in the real world also requires the ability to understand, predict, and measure both the actions of others and the environmental conditions that you’re in. At some point, both you and other actors will have limits on ability to accelerate, decelerate, and make high speed turns. Those limits can be used in your favor to plan, to minimize, or avoid the risk of collision, but you have to know what they are. Given that, your own planned actions also come into play, and link with planning metrics and scenario coverage metrics, which we’ll talk about another time.

Anytime you’re considering safety on public roads, there will be pressure to increase permissiveness that might justifiably be at the expense of slight amounts of theoretical safety capability. The question is how to make that trade-off, and where to responsibly place the line to make sure you’re as safe as you need to be, but you’re still actually allowed to move around on the roads. For this trade off Newton’s laws provide the framework, but public policy provides the acceptable trade-off points.

Wednesday, February 6, 2019

Edge Cases and Autonomous Vehicle Safety -- SSS 2019 Keynote

Here is my keynote talk for SSS 2019 in Bristol UK.

Edge Cases and Autonomous Vehicle Safety

Making self-driving cars safe will require a combination of techniques. ISO 26262 and the draft SOTIF standards will help with vehicle control and trajectory stages of the autonomy pipeline. Planning might be made safe using a doer/checker architectural pattern that uses  deterministic safety envelope enforcement of non-deterministic planning algorithms. Machine-learning based perception validation will be more problematic. We discuss the issue of perception edge cases, including the potentially heavy-tail distribution of object types and brittleness to slight variations in images. Our Hologram tool injects modest amounts of noise to cause perception failures, identifying brittle aspects of perception algorithms. More importantly, in practice it is able to identify context-dependent perception failures (e.g., false negatives) in unlabeled video.



Friday, June 1, 2018

Can Mobileye Validate ‘True Redundancy’?

I'm quoted in this article by Junko Yoshida on Mobileye's approach to AV safety.

Can Mobileye Validate ‘True Redundancy’?
Intel/Mobileye’s robocars start running in Jerusalem
Junko Yoshida
5/22/2018 02:01 PM EDT

...
Issues include how to achieve “true redundancy” in perception, how to explain objectively what “safe” really means, and how to formulate “a consistent and complete set of safety rules” agreeable to the whole AV industry, according to Phil Koopman, professor of Carnegie Mellon University.
...

Read the story here:
  https://www.eetimes.com/document.asp?doc_id=1333308

Saturday, February 24, 2018

TechAD Talk on Highly Autonomous Vehicle Validation

Here are the slides from my TechAD talk on self driving car safety:


Highly Autonomous Vehicle Validation from Philip Koopman

Highly Autonomous Vehicle Validation: it's more than just road testing!
- Why a billion miles of testing might not be enough to ensure self-driving car safety.
- Why it's important to distinguish testing for requirements validation vs. testing for implementation validation.
- Why machine learning is the hard part of mapping autonomy validation to ISO 26262

(Originally posted on Nov 11, 2017)

SCAV 2017 Keynote: Challenges in Autonomous Vehicle Validation


Challenges in Autonomous Vehicle Testing and Validation from Philip Koopman


Challenges in Autonomous Vehicle Validation
Keynote Presentation Abstract
Philip Koopman
Carnegie Mellon University; Edge Case Research LLC
ECE Dept. HH A-308, 5000 Forbes Ave., Pittsburgh, PA, USA
koopman@cmu.edu

Developers of autonomous systems face distinct challenges in conforming to established methods of validating safety. It is well known that testing alone is insufficient to assure safety, because testing long enough to establish ultra-dependability is generally impractical. That’s why software safety standards emphasize high quality development processes. Testing then validates process execution rather than directly validating dependability.

Two significant challenges arise in applying traditional safety processes to autonomous vehicles. First, simply gathering a complete set of system requirements is difficult because of the sheer number of combinations of possible scenarios and faults. Second, autonomy systems commonly use machine learning (ML) in a way that makes the requirements and design of the system opaque. After training, usually we know what an ML component will do for an input it has seen, but generally not what it will do for at least some other inputs until we try them. Both of these issues make it difficult to trace requirements and designs to testing as is required for executing a safety validation process. In other words, we’re building systems that can’t be validated due to incomplete or even unknown requirements and designs.

Adaptation makes the problem even worse by making the system that must be validated a moving target. In the general case, it is impractical to validate all the possible adaptation states of an autonomy system using traditional safety design processes.

An approach that can help with the requirements, design, and adaptation problems is basing a safety argument not on correctness of the autonomy functionality itself, but rather on conformance to a set of safety envelopes. Each safety envelope describes a boundary within the operational state space of the autonomy system.

A system operating within a “safe” envelope knows that it’s safe and can operate with full autonomy. A system operating within an “unsafe” envelope knows that it’s unsafe, and must invoke a failsafe action. Multiple partial specifications can be used as an envelope set, with the intersection of safe envelopes permitting full autonomy, and the union of unsafe envelopes provoking validated, and potentially complex, failsafe responses.

Envelope mechanisms can be implemented using traditional software engineering techniques, reducing the problems with requirements, design, and adaptation that would otherwise impede safety validation. Rather than attempting to prove that autonomy will always work correctly (which is still a valuable goal to improve availability), the envelope approach measures the behavior of one or more autonomous components to determine if the result is safe. While this is not necessarily an easy thing to do, there is reason to believe that checking autonomy behaviors for safety is easier than implementing perfect, optimized autonomy actions. This envelope approach might be used to detect faults during development and to trigger failsafes in fleet vehicles.

Inevitably there will be tension between simplicity of the envelope definitions and permissiveness, with more permissive envelope definitions likely being more complex. Operating in the gap areas between “safe” and “unsafe” requires human supervision, because the autonomy system can’t be sure it is safe.

One way to look at the progression from partial to full autonomy is that, over time, systems can increase permissiveness by defining and growing “safe” envelopes, shrinking “unsafe” envelopes, and eliminating any gap areas.

ACM Reference format:
P. Koopman, 2017. Challenges in Autonomous Vehicle Validation. In
Proceedings of 1st International Workshop on Safe Control of Connected
and Autonomous Vehicles, Pittsburgh, Pennsylvania, USA, April 2017
(SCAV 2017), 1 page.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is  granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the Owner/Author.
Copyright is held by the owner/author(s).
SCAV'17, April 21-21 2017, Pittsburgh, PA, USA
ACM 978-1-4503-4976-5/17/04.
http://dx.doi.org/10.1145/3055378.3055379

(Originally posted 4/23/2017)