We’ve previously discussed our hardware and the software that pairs with that hardware. Now, we’ll be discussing how systems engineering contributes to our safety approach — and this part of the autonomy story is unique. That’s because we define safety in the context of our autonomous driving system and set a high bar for ourselves as we introduce a brand new type of vehicle to public roads.
That’s where systems engineering comes in. Systems engineering is a discipline that follows a principled technical approach to breaking down a complex system — such as our autonomy stack — into layered subsystems and components in terms of form and function. This system architecture also establishes interfaces and quantifies interdependencies between the various parts.
For each system or subsystem, we:
- Define metrics that quantify performance
- Set specifications for and support the development of tools to compute those metrics
- Define and detail tests to measure the metrics through appropriate testing
- Set thresholds for acceptable outcomes in those tests
- Develop machine learning and data science models to derive inferences from testing
This process allows us to set requirements on, quantify, and verify the performance of various parts of the autonomy stack, including end-to-end behavior, as well as our vehicle development.
We use systems analysis to define what “safe” means and how we test and validate to ensure our technology is meeting that definition of safety. We’ll break down what systems engineering is, how it works, and how we’re using this discipline to deploy zero-occupant autonomous vehicles that are safe for communities.
Safety Goals
The first step of systems analysis is defining what our technology actually does in general. We know we want our zero-occupant autonomous vehicle to be able to pick up goods from our partners, drive through communities, and complete goods deliveries. We need our bot to be easy-to-use for customers and partners, and we need it to be able to carry multiple orders within the same compartment.
Once we have a good idea of functional requirements, we can break down each facet of operation in terms of safety. Again, there aren’t federal standards for, say, how quickly the automatic doors of our bot should open so they don’t cause harm if someone’s standing too closely, so we need to determine that metric. This is when we establish principles, standards, and regulations for compliance. For example: the bot shall come to a safe stop if it is unsure how to navigate a situation and the bot shall follow the principles of IEEE P2846, which is a standard for safety for the evaluation of autonomous planning.
We also look at public trust requirements. This is important because communities need to know they can trust autonomous vehicles on community roads, so it’s up to us to define how to compare our performance to human driving. And we need to define what that looks like in various operational design domains, such as snowy mountainous terrain or busy inner-city areas. Finally, we need to look at legal requirements so that our vehicles comply with traffic rules and governmental regulations. When we have goals and requirements set in place, we can start evaluating how to translate those into terms of autonomy.
Developing system requirements
After we’ve defined what is safe, we need to figure out a way to measure it. That is more difficult than it may seem at first glance. To do this, we develop metrics that place upper limits on probabilities of encountering hazards and non-optimal behavior, such as statistical confidence intervals on being a safe participant on roads in all communities. Once we have metrics defined for the system, we need to develop tools that will allow us to compute metrics at scale — and if we can’t find an appropriate tool to measure the metrics for us, we need to build it.
Subsystem requirements
After we have requirements set in place for the robot as a whole, we need to break those requirements down into subsystems such as braking, compute, etc. Each of those subsystems will have their own requirements. We use “the vehicle shall” statements to determine these. For instance, the vehicle shall stop within X meters, the vehicle shall preserve a buffer zone of Y meters around pedestrians, the vehicle shall stop when directed by traffic control devices, the vehicle shall pull over within optimal distance from the curb, etc. As we determine these statements, we err on the side of caution, letting the safest outcome possible be our goal.
Once we have defined subsystem requirements, we need to define metrics for each requirement and, again, determine tooling and develop evaluations to compute those metrics.
Module requirements
The purpose of breaking down requirements into progressively smaller pieces is so that every component of our vehicle has its own standard it must meet to ensure overall safety. We set standards for even the smallest details. During this step, we break down our critical subsystems into modules and define standards for them. For instance, if we’ve said that our vehicle shouldn’t brake hard without a significant reason, we need to deconstruct that statement and define what “hard braking” and “significant reason” means. Then, we’ll look at the performance of every module that contributes to the robot’s ability to stop softly when, as an example, approaching an intersection.
The autonomy team can then tune their models to achieve appropriate false positive vs. negative requirements within regions of relevance. Again, we’ll define metrics for selected modules and develop tooling and evaluation pipelines to compute metrics, then set requirements for the metrics.
Testing
It might seem like quite a bit of effort goes into defining requirements before we get to this step, but if we didn’t know what the goals of our testing were, there would be no point to testing. Our evaluation tests, customized tools, and data analysis of results ensure our safety criteria are met before deployment.
But here is where Nuro differs from other autonomous vehicle companies: since our vehicle doesn’t carry passengers, we need to develop unique methods of testing. We do not start out by testing our real robots in real, public environments to assure safety. So, we come up with quantitative ways to infer performance of real vehicles on real roads as we test in partial vehicle-environment combinations.
We’ll get more into testing later, but for now, here’s a brief breakdown of how we test:
- Using a “simulated robot” on a real road (a passenger vehicle equipped with our autonomy stack)
- Using a real robot on a “simulated road” (a Nuro vehicle on a testing track)
- Simulation using a virtual Nuro vehicle on sensor-collected data gathered from real roads and simulation using a virtual Nuro vehicle in a virtual, synthetic environment
Once we get to the testing phase, we can evaluate all requirements in all three levels (system, subsystem, and modules) across all of these testing modalities. We define test methods, and execute them via road operations and using at scale infrastructure for tooling and data science.
The long road to safety
If the above seems like an arduous road to deployment, that’s because it is. We’re taking a calculated, measurable approach that relies on strict requirements and validated performance. We first determine how we want our vehicles to operate, then we set standards for their safe operation. Then, we set quantifiable measurements for systems, subsystems, and modules so that each component of our vehicle has benchmarks to hit before it can be deployed. And throughout this process, we’re building tools to measure our unique metrics so that, when we test, we can measure our progress, rigorously manage risk, and determine where improvements must be made.
Our strict approach to deployment means that we don’t operate our service until all module, subsystem, system, safety, and product requirements are met. That’s how we ensure our vehicles operate safely in the same communities in which we live and how we plan on delivering a future with safer roads and a higher quality of life.
