Autonomous Vehicle Testing Guidance for State & City DOTs
Once in a while I'm contacted by a city or state Department of Transportation (DOT) to provide advice on safety for "self-driving" car testing. (Generally that means public road testing of SAE Level 3-5 vehicles that are intended for eventual deployment as automated or autonomous capable vehicles,)
The good news is that industry standards are maturing. Rather than having to create their own guidelines and requirements as they have in the past, DOTs now have the option of primarily relying upon having AV testers conform to industry-created guidelines and consensus standards.
And ... in September 2021 NYC DOT blazed a trail by requiring the self-driving car industry to conform to their own industry consensus testing safety standard (J3018). Kudos to NYC DOT! (check it out here (link); more on that in the details below.
The #1 important thing to keep in mind is that testing safety is not about the automation technology -- it is about the ability of the human safety driver to monitor and intervene when needed to make safety. The technology is going to fail, because the point of testing is to find surprise failures. If a failure of technology causes a fatality, then most likely the testing wasn't being done safely enough. It is essential that human safety drivers be skilled and attentive enough to prevent loss events when such failures inevitably occur.
The short version is that DOTs should:
- Follow the AAMVA road testing guidelines plus some additional key practices.
- Define how safe testing should be when considering the safety driver + vehicle system as a whole.
- Ask testers for conformance to SAE J3018 for road testing.
- Ask testers to have a credible Safety Management System (SMS) approach, including a testing plan.
- Ask testers to provide metrics that show that their testing is safe (not just a promise up front, but also periodic testing safety metrics as they operate). Don't get distracted by measuring the maturity of the technology they are testing -- it's all about the safety driver ability to intervene when something goes wrong.
- If testing takes place with a safety driver in a chase vehicle or remote, ask for conformance to safety standards for the mechanisms required to ensure safety (e.g., per ISO 26262), but otherwise conforming to SAE J3018 for the training and protocols.
- If testing takes place without continuously monitoring safety driver, ask for conformance to industry-consensus safety standards for the autonomous vehicle itself. If there is no person continuously monitoring and capable of assuring safety, then the safety aspects of the technology have to be done. You shouldn't let vehicles without fully mature safety technology operate without a human safety driver.
The AAMVA Guidelines as a starting point:
DOTs should follow applicable AAMVA guidelines with a few additional points.
- Vehicle manufacturer or testing organization should be required to publish a Voluntary Safety Self Assessment (VSSA) report (see AAMVA Guidelines 3.1.5). That VSSA should address all relevant topics in the NHTSA Automated Driving Safety documents (2.0, 3.0, 4.0). A VSSA does not provide all information required for technical evaluation of safety, but complete lack of a VSSA suggests an unwillingness to provide public transparency.
- Require statement of areas of intended operation in a manner that does not compromise any claimed secrets as to detailed specifics of tests being conducted.
- For example, require reporting of zip codes of where testing is to be conducted.
- Report speeds at which testing will be conducted (e.g., 25 mph speed limit street testing is much different than Interstate System highway testing).
- Report other relevant Operational Design Domain factors that will limit testing (e.g., daytime only, in rain, in snow) so that any particularly hazardous environmental testing situations can be considered with regard to public safety.
- Discuss any unique characteristics of the test area to ensure the tester understands what unique challenges might be presented that someone not from the location might find unusual (e.g., The Pittsburgh Left, parking chairs, cable cars, cattle grids, gator crossings).
- Require a tester statement that a defined level of technology quality will be confirmed before it is used for public road testing (along with the definition of what that might be). This should include at least:
- A comprehensive simulation and closed course testing plan should be completed before testing on public roads.
- All software updates should be subjected to confirmatory closed course testing to ensure no new defects have been introduced before being used in road testing.
- Any vehicle feature that does not pass closed course testing should not be active during road testing. (In other words, if a feature fails closed course track testing, it shouldn't be operated on public roads.) Public roads should be used to confirm that the vehicle works as expected, not for debugging of known-faulty features.
- Explanation for why the tester thinks that safety driver training and performance will be sufficient to ensure that test vehicles do not present increased risk to other road users.
Define how safe is safe enough:
DOTs should define the desired safety outcome, but not how to measure it.
SAE J3018 for operational safety:
DOTs should ask testers to conform to the industry standard for road testing safety: SAE J3018.
Safety Management System (SMS)
DOTs should ask testers to have a Safety Management System in place before testing.
DOTs should ask for metrics related to public safety during testing rather than autonomy performance.
- What basis do you have for claiming that your testing will not present increased risk to other road users, including vulnerable road users?
- What metrics to you plan to collect to ensure that your system is in fact not presenting any such increased risk?
- What periodic (e.g., monthly) quantitative report can you give us to show that indeed your testing has not increased the risk to other road users?
- How often does the built-in driver monitor signal a driver attention issue? (It won't be zero, but there should be a defined acceptable threshold set by the AV tester which, if exceeded, should cause a process intervention of some sort.)
- How often does the safety driver make an erroneous intervention, even though there is no crash or other loss event? (In other words, how many near hits are occurring?)
- How does the AV tester track skill degradation to determine when it is time for a shift change or even refresher training for a safety driver?
Testing Without A Driver:
DOTs should ask about safety during communication loss for remote safety driver testing.DOTs should ask testers to conform to industry automotive safety standards if there is no supervising test driver.
- Self-certification that the testing will be safer than a human driver. This is just asking the tester to claim (without producing any proof) that they will test safely. If they're not willing to sign up to that, probably they should not be on public roads.
- Conform to SAE J3018 and AVSC 00001201911. In other words, this is asking them to follow industry standards and practices for their test driver qualification and testing protocols. This involves ONLY the human test driver and does not place constraints on the automation technology being tested. If they're not willing to sign up to have trained safety drivers and safe testing protocols, probably they should not be on public roads.
- Submission of a safety plan. This has nothing to do with the automation technology -- it is all about making sure the safety driver can keep the vehicle safe. If they can't explain to the DOT what their plan is to be safe in testing, probably they should not be on public roads.
- NYC DOT Testing regulations
- SAE J3016 terminology explanation (slides | video)
- SAE J3016 unofficial User Guide
- Metrics podcasts (especially the episodes on Disengagements and Road Testing Safety)
- More in-depth lecture series on AV Safety
Prof. Philip Koopman is an internationally recognized expert on Autonomous Vehicle (AV) safety whose work in that area spans 25 years. He is also actively involved with AV policy and standards as well as more general embedded system design and software quality. His pioneering research work includes software robustness testing and run time monitoring of autonomous systems to identify how they break and how to fix them. He has extensive experience in software safety and software quality across numerous transportation, industrial, and defense application domains including conventional automotive software and hardware systems. He was the principal technical contributor to the UL 4600 standard for autonomous system safety issued in 2020. He is a faculty member of the Carnegie Mellon University ECE department where he teaches software skills for mission-critical systems. In 2018 he was awarded the highly selective IEEE-SSIT Carl Barus Award for outstanding service in the public interest for his work in promoting automotive computer-based system safety.
Any city or state DOT representative addressing this topic is welcome to contact him via: email@example.com
Updated Sept. 12, 2021.