Earlier this month, I joined the Board of Foretellix, a company whose mission is to make ADAS and autonomous systems safe. It is no small undertaking, but I am convinced Foretellix is very well positioned to achieve this goal. I wanted to share some of my thoughts and tell you why I decided to join Foretellix on this journey.

The Team:

Foretellix founders have built a verification and validation platform for autonomous systems like ADAS and AVs. They did this in part by adapting methodologies and tools that they invented and successfully commercialized in the semiconductor industry twenty years ago. They changed that industry and will do the same for autonomy. They have assembled a super strong team of experts with hundreds of years of experience in V&V, automotive, robotics, and machine learning.

The Customers:

Foretellix is already working with dozens of the world’s top OEMs and Tier 1s, including Volvo Group, DENSO Corporation, Valeo, NVIDIA, and many others that I cannot yet name; stay tuned…

The Market:

Autonomy is happening now and is disrupting multi-billion dollar industries and their business models. While many look up to a future of Robotaxis (that is taking longer to mature), the advance in autonomous systems is changing the automotive industry and other industries that rely on vehicles for their production processes and supply chain on land, water, and on-air.

We see that progress in automotive ADAS (L2/L3) systems that are commercially deployed in vehicles sold today and in advanced testing of L4 systems like Robotaxi and pavement delivery bots. We’re also seeing initial commercial deployments of fully autonomous systems in mines, ports, constructions, industrial, logistics centers, long haul trucking, as well as homeland security, marine and aviation.

The Big Problem:

The common denominator for all these systems that operate in different ODDs is that autonomy is complex and has taken longer than most expected. It is important to note that autonomy is probably one of humanity’s most ambitious technological undertakings. An autonomous system is a machine of machines combining millions of lines of software code, complex hardware, and cutting-edge technologies such as machine learning.

However, packaging all of that technology into one system is only half the story. This system is expected to navigate safely and efficiently in an almost infinite number of scenarios (different driving maneuvers on different roads, ODDs and their users, weather conditions, road conditions, etc.).

This is a level of complexity that very few industries have faced, and to meet this challenge, new tools and methodologies have to be used to handle both this complexity and the massive scale of testing needed to ensure the safe and efficient operation of autonomous systems.

The Solution and the Standard:

This is where Foretellix stands out. Drawing from their experience in solving another big problem – the verification of computer chips – Foretellix founders have adapted proven methodologies to verify complex digital products and adapted them to the challenges of autonomy. Foretellix developed a language to describe driving scenarios (that is now in the final stages of becoming an industry-standard – (ASAM OpenSCNENARIO 2) and advanced automation and analytics software tools to create and run the massive scale of testing required to identify bugs, expose edge cases and unknowns.

I am genuinely excited to join this maverick team and work together to achieve our mission of a better, safer autonomous future.

About Alexander Hitzinger

Mr. Hitzinger has over two decades of experience in senior leadership roles in the automotive industry. He started his automotive career as a development engineer at Toyota Motorsport before working in Formula 1 at Cosworth and Red Bull Technology. Hitzinger then joined Porsche as Technical Director and Chief Engineer of Porsche 919, which won the 24 Hours of Le Mans in 2015.

He spent three years at Apple as Head of Product Design for Project Titan. Most recently, Hitzinger served as Senior Vice President of Autonomous Driving at VW Group and Member of the Executive Board VWN, where he was involved in developing the ID Buzz. He currently serves Board Member and Advisor to various technology companies in the US and Israel.

Foretellix and NVIDIA Deliver End-to-End Solution for ADAS/AV Development, Verification, and Validation. Pairing NVIDIA’s simulation tools with the Foretellix validation platform creates a best-in-class solution that reduces development costs and helps AV makers get to market faster, and improve the safety of ADAS and AV.

‘’Foretify™ is an industry-leading tool for validation and verification. NVIDIA DRIVE Sim™ is a scalable, physically-based platform for AV simulation. By combining the two, developers can have access to the most advanced toolchain to accelerate the development and deployment of autonomous vehicles”, says Zvi Greenstein, General Manager at NVIDIA.

The traditional approach to automotive testing, involving real-world driving of pre-production test vehicles, is a capital and time-intensive process which does not scale. With the increasing complexity of ADAS and AV systems, it is practically impossible to encounter the rare and dangerous scenarios needed for comprehensive autonomous vehicle validation & verification. However, this is precisely where the combined power of NVIDIA’s DRIVE Sim™, a virtual simulator, and Foretellix’s Foretify™ verification and validation platform can deliver a scalable and effective solution that can expose bugs, edge cases, and unknowns more efficiently and faster.

The combined solution is based on Foretify™’s ability to generate and orchestrate a massive number of meaningful tests. The tests are then propelled into DRIVE Sim™, where a physically realistic simulation of the test is conducted and challenges the instructions that the ADAS/AV stack provides to meet the situation in the tests. Foretify™ orchestrates the tests and is able to dynamically control them to ensure that the test is conducted as planned. The results of the tests, including KPIs, are sent back to Foretify™ for analysis and optimization, allowing development teams to run these tests regressions again until a safe, successful result is achieved.

NVIDIA DRIVE Sim™ provides an end-to-end simulation platform architected from the ground up to run large-scale, physically-based multi-sensor simulation. It’s open, scalable, modular, and supports AV development and validation from concept to deployment, improving developer productivity and accelerating time to market.

Foretellix’s verification platform Foretify™ uses proven coverage-driven methodologies to conduct the verification of ADAS and AV. Foretify™ is able to generate the myriad of tests required to cover all the relevant scenarios that automated driving systems may encounter in the real world. Scenarios are defined using ASAM OpenSCENARIO 2.0, a human-readable scenario description language adopted recently as an industry standard. Foretellix also provides off-the-shelf test and verification packages, called V-Suites for ADAS functions, L3 ALKS regulation, L4 Highway driving, and Mining that help our customers to get their testing program up and running in no time. A unified safety and productivity dashboard based on big data analytics provide a coverage-driven view of the progress of their testing program.

Whether you are working on ADAS and about to move up to more advanced autonomous functions or working on the long tail of L4 autonomy, one thing is for sure: you are about to face exponential growth in the number of scenarios you need to test in order to get your autonomous product out. In a recent session on Reddit, Waymo’s CTO, Drago Anguelov, described the “long tail” the industry has seen in going from effective Autonomous Vehicle prototypes to working products. Despite the many declarations of expected releases of working products in the near future, it’s clear that the AV industry isn’t close to where it should be. The industry is starting to sober up to the fact that in order to release working products there is a need to dramatically increase the number of scenarios tested.

Whether you are working on ADAS and about to move up to more advanced autonomous functions, or working on the long tail of L4 autonomy, one thing is for sure: you are about to face exponential growth in the number of scenarios you need to test in order to get your autonomous product out.

One of the major weaknesses with the existing mainstream approach to AV development is the over-reliance on physical road driving and their recordings. Obviously physical testing is needed, but is it enough? Should this be the primary focus? In these hectic times, the Autonomous Vehicle and ADAS industry has an opportunity for a paradigm shift. With most test driving of autonomous driving stalled due to Covid-19, it is time to take a step back and see how verification programs can be modified to make a leap forward in safety, efficiency and cost. See for example CEO of Voyage, Oliver Cameron.

After a long career in Verification of complex systems, I can state unequivocally that subscribing almost exclusively to a single verification method is both inefficient and counterproductive. Anyone who has worked in the fields of Verification and Validation can tell you that each set of tools has its own combination of advantages and blind spots. The goal of any verification program is to find the right combination of tools and methods to overcome the inherent gaps and utilize the advantages of each.

Physical and recorded driving are essential components of testing autonomous vehicles, but while these approaches have many benefits, they, unfortunately, have inherent gaps. To complement the gaps, I contend that simulation of model-based generated scenarios is required. In this article, I will discuss some of the gaps in physical driving, key advantages to generated scenarios and why I believe that relying solely on physical recordings is the wrong approach.

Gaps in physical & recorded driving

• There are a limited amount of times and ways to check dangerous scenarios
• In physical and recorded tests, it is difficult to create new scenarios by manipulating factors beyond weather, lighting conditions and limited changes to additional actors
• Using recordings, actors cannot respond to various changes in the EGO’s behavior
• Prohibitively high cost of physical driving & recordings
• Rare events may not really be as rare as projected
• Some errors, however rare they may be, are inexcusable and need to be tested

Before delving deeper into the advantages of model-based automated scenario generation, let’s define the term in reference to the testing of autonomous vehicles. When I discuss model-based automated scenario generation, I am referring to Coverage Driven Constrained Random Verification; the ability to capture a scenario in a high-level language and let a random generator choose places on a map, generate multiple scenario parameters and create a massive number of valid scenario variations within the constraints provided. The model is able to both randomize abstract scenarios and mix them with other scenarios. In addition, the model is able to track simulations to see that they met all the KPIs and covered all required scenarios to prove the safety case.

Exploring the relative advantages of Automated Virtual Testing

Controllable and Safe

Simulation is completely controllable and safe. In real physical driving, there are limited ways to check dangerous scenarios. In contrast, model-based scenario generation facilitates taking an abstract scenario to generate thousands to millions of valid variations. For example, a pedestrian crossing a highway is rare in physical driving, thus the number of instances of this scenario recorded by chance, during road-driving, is limited. In a test-track this scenario will have very few variations if any;
In the model-based approach, this simple scenario can be varied for multiple parameters (height, clothing, distance, speed, direction, weather, occluded areas…) and can appear in different parts of the map. It can also be mixed with other scenarios. Obviously, this critical scenario, however rare it may be, is best tested comprehensively — which is only possible using model-based scenario generation.
Even if the accuracy of sensor simulations is suspect, you can still use “sensor bypass” to test many other variations.

Flexibility

Physical tests are an invaluable resource for accurately depicting the input from the sensors, but simulations are far more flexible. In recorded drives, while it is possible to manipulate some factors such as weather, lighting conditions and adding additional actors (as long as these actors do not really interact with the scenario), it is difficult to change the responses of either the EGO or the other actors. If the EGO behavior or trajectory changes due to changes in the algorithm, other actors still react as they did in the recording, making the rest of the simulation irrelevant. So, if the algorithm changed and the EGO modified its behavior, recorded tests cannot check that the new behavior will result in a safe maneuver. In model-based scenario generation, each change can be regressed thoroughly and the actors will respond to changes in the EGO’s behavior to help prove the changes have corrected the problem, while not introducing new problems.

Unknows & Rare events

There are two problems with deeming an event too rare to test or to solve. The first is events may look rare because of inaccurate analysis of the root cause of the problem. One may conclude that specific accidents happen statistically only 10^-9 miles and are rare enough to not require fixing and focused testing, while the real source of the issue is something that happens 10^-6 miles and must be fixed. Model-based scenario generation you will inevitably find many instances of the problem quickly and be able to identify the true underlying root-cause before it causes accidents. Moreover, leveraging the nature of constrained random combinations and their ability to cover far more interesting events per mile, simulations will uncover risk areas that were previously unknown. The other issue is inexcusable accidents. A baby falling from a car in an intersection may be a 10^-10 event, but an algorithm that was not sufficiently sensitive to this extremely rare case would be unforgivable.

In a model-based simulation, creating specific scenarios, such as the case above, can be streamlined and by leveraging cloud or on-premise compute-farms, a project can run millions of scenarios.

Efficiency

An active AV development project requires a massive regression that can be run every time there is a change to the software or algorithm, be it a bug fix or a new feature. The regression needs to complete quickly to provide developers immediate feedback enabling modern development practices such as Continuous Integration. The regression requires an abundance of scenarios and variations to see that the model continues to meet the safety requirements. For example, if there was a correction to a specific scenario of merging into a highway with heavy snow, the test suite may have only a limited number of such scenarios recorded in the database and the changes in the driving of the actors is beyond the capability of recording manipulation. To test it thoroughly and release the new software requires orders of magnitude greater variation. If the project relies solely on recordings, the project would need to send the fleet to harvest this situation — after a month of focused driving; the project would be lucky to have a fraction of scenarios required. Corner cases of this (such the same scenario at higher speeds) would require infinitely more time to procure. Using model-based test generation, allows the project to get the full suite of target tests with minimal effort. Moreover, the random simulations can utilize the tests to pack ‘drama’ into many of the simulations, resulting in a far more efficient and thorough proof of the safety case.

Cost

This is simple. Driving real vehicles is costly. Simulation is cheap. With model-based scenario generation, you get more for less.

The cost of a single physical test vehicle including the HW, personnel (drivers, maintenance team, data analysis) is estimated in the hundreds of thousands of US dollars. While in simulation, each processor core can run a “virtual vehicle”. The cost of a virtual vehicle is at least an order of magnitude lower than that of a physical one.

Further to the raw cost, one needs to look at scenario density — how many interesting scenario variations do we encounter per day. The number of interesting scenarios a physical test vehicle will encounter in a typical day is between 10–100. While the number of interesting scenarios a virtual test vehicle can encounter per day using an intelligent model-based simulation can easily reach 1000–10000. a 100X advantage. If we use Meaningful Scenario per Dollar ratio, model-based virtual testing is at least 1000X cheaper than physical testing. Again this does not mean that one should abandon physical testing. But it does mean that the testing budget is better applied using the best techniques for where they are most effective.

Summary

Model-based Automated Virtual Testing is not a panacea. My company, Foretellix, has created a complete solution that enables developers to do Intelligent Automated testing with both virtual and physical execution platforms. The solution consists of an open language called M-SDL (Measurable Scenario Description Language) that facilitates the capture of abstract scenarios (the model). We provide Foretify, a software tool that takes these abstract M-SDL scenarios, automatically generates a massive number of random valid scenario variants and collects scenario coverage to efficiently prove the safety case for both autonomous vehicles and advanced ADAS systems.

Physical testing of AVs is a must, but it’s only part of the solution. Automated Virtual Testing using constraint-driven random methods in the verification program allows us to fill in the gaps from physical and recorded driving. At a time when physical testing is halted, it’s a good opportunity for developers to take a step back and consider a cheaper, faster, safer and more comprehensive approach to both raise quality and shorten time to ADAS and AV development convergence.

Increasingly, thought leaders and executives within the automotive industry have shared their concerns about the validity of miles and disengagements as metrics for safe deployment of autonomous vehicles, and some have started proposing alternative metrics. Early in my career, I worked on a very interesting project at Intel, the project group designed the Pentium-pro microprocessor. At the time, this was the most complicated design ever attempted by Intel, and most likely anywhere else. To ensure the quality of this complex beast, we had to develop a new methodology and make sure we got it right. Choosing to measure the number of programs executed or bug rate would have made measuring ‘easy’, but not very meaningful. Instead, we came up with novel meaningful metrics that measured the functionality tested and the complex interactions of events.

Last week, the California Department of Motor Vehicles released the 2019 disengagement report, containing information reported by companies piloting self-driving vehicles in the state.

The Autonomous industry is struggling for effective metrics for safe deployment of AVs. The ‘easiest’ metrics available to the AV industry are the number of miles driven by the AV and the number of disengagements. However, these indicators, while ‘easy’ to measure, are not sufficient as a measure for AV safety.

The recent release of the state of California’s Disengagement report

Increasingly, thought leaders and executives within the automotive industry have shared their concerns about the validity of miles and disengagements as metrics for safe deployment of autonomous vehicles, and some have started proposing alternative metrics.

Kyle Vogt of Cruise writes in an article titled “The Disengagement Myth” that it is frequently unclear if a disengagement reflects real safety issues or more of the disengagement policy of the AV developer. He asserts that the number of disengagements per mile alone does not reflect the readiness of the vehicle for fully autonomous driving.

Oliver Cameron of Voyage is speaking about the lack of standardization of what constitutes a disengagement and is proposing an alternative Driver Readiness Score as a new way for companies to publicly share their progress. This proposed score includes the percentage of scenarios passing in simulation.

Chris Urmson of Aurora asks in a recent article “If we drive 100 million miles in a flat, dry area where there are no other vehicles or people, and few intersections, is our “disengagement rate” really comparable to driving 100 miles in a busy and complex city like Pittsburgh?”. Urmson points out that just measuring the number of miles driven can be a deceptive indication of progress.

I would put it more bluntly: many of these miles are “dumb miles” — miles that add nothing new to the testing. For example how many of these were just driving on a straight empty highway? How many times did the AV encounter a cut-in from the right side? Did the AV encounter a cut-in on a curved highway in light rain?

So what are effective metrics the AV industry can be using?

Effective metrics are needed for tracking how close we are to achieving our safety goals, and where we should focus additional effort. The metrics should answer in an objective, quantifiable way: Do we know what scenarios and parameters were encountered during the testing? Were the safety requirements met? Were key performance indicators (KPIs) met? How many miles were driven using the latest release of the software and not using older irrelevant versions?

Disengagements and miles driven, while showing general progress, are insufficient at proving the safety goals. To fill in the gaps, it’s essential to look inside the miles — make sure we successfully exercise the scenarios critical for AV safety and provide the required metrics to prove it.

How can we do that?

An alternative approach for both creating and tracking effective metrics of AV safety is the Coverage Driven Verification (CDV) approach.

CDV originated in the semiconductor industry, where it has been widely used for many years. In recent years, we adapted the approach for safety-verification of AVs. It provides a methodical way to specify scenarios and mixed scenarios required for achieving an objective metric for the completeness of safety requirements.

In utilizing our approach, first, high-level requirements including the operational design domain (ODD) are defined. A comprehensive list of risk dimensions is written based on the requirements. Using the risk dimensions, a comprehensive verification plan is created. The plan includes quantifiable, measurable goals down to the parameter level including both coverage metrics and KPIs. The next step is to define the high-level abstract scenarios and their parameters using a scenario description language. The combinations of the parameters in an abstract scenario create a plethora of concrete scenarios to be tested.

The concrete scenarios are run across different testing platforms, including simulators, hardware-in-the-loop, test tracks, and street driving, and produce meaningful metrics which are aggregated into a comprehensive coverage and KPI report. Analysis of the report drives the verification effort to hone in on non-covered areas, while intense constraints-based random test generation is used to complete the coverage holes and to explore areas beyond the known scenarios to assure the highest level of safety.

Example of defined coverage

For example two of the risk dimensions defined could be vehicle maneuvers and weather. A vehicle maneuver abstract scenario can be a cut-in scenario, the coverage defined includes various parameters such as speed of the EGO, distance at start of cut-in, side of cut-in. KPIs recorded can be TTC (time to collision), deceleration rate etc. The cut-in scenarios can be mixed for weather scenarios from sunny weather, through drizzle to heavy rain and along with any other weather condition defined in the AV’s ODD.

The Disengagement report and surrounding discussions highlight the AV industry’s need for meaningful metrics which are objective, quantifiable and encompass the safety requirements of AVs. The Coverage Driven Verification approach provides a clear framework and method to define and track meaningful metrics. It is my belief that adoption of this systematic approach will help the industry achieve safe deployment of AVs sooner.