In the previous blog, we looked at how scenario-based verification has become mainstream in the ADAS/AD V&V.

In this blog, we will look at a real-world scenario and how we can use OSC 2.0 to model concrete and abstract scenarios of the same for validation of the AV.

OSC 2.0 is an aspect-oriented programming language that allows us to define actors like vehicles, and pedestrians, the actions performed by them, and the test environment. Recently there was a major accident between an Autonomous Vehicle(AV) and a traffic vehicle in San Francisco, where the AV was making a left turn in the junction with the other vehicle approaching the junction and then the AV decided to stop in between the intersection upon sensing the other vehicle which led to the mishap.

Check it out here.

Ideally, the AV should have sensed the oncoming vehicle and not entered the junction. The situation could be avoided if the AV was exposed to such a situation during the verification and validation of the system and this fault was rectified at an earlier stage. This is where scenario-based verification could be useful in identifying and rectifying such unknown cases in the AV system.

We will look at how we can use Openscenario 2.0 to model this accident case as a scenario. The idea is to not only model this concrete accident scenario but to bring in more abstractness to it which might help in finding out more unknowns to the AV system.

The below diagram depicts the scenario:

scenario sut.left_turn_in_junction:

    map: map

    traffic_vehicle: vehicle

    sut_speed: speed

    keep(sut_speed == 30kph)

    traffic_vehicle_speed: speed

    keep(traffic_vehicle_speed == 40kph)

    road_junction: junction

    junction_road_1:  road

    junction_road_2:  road

    junction_road_3:  road

    junction_road_4:  road

    sut_route: map.roads_follow_in_junction(junction: road_junction, in_road: junction_road_1, out_road: junction_road_2, direction: left)

    traffic_vehicle_route: map.roads_follow_in_junction(junction: road_junction, in_road: junction_road_3, out_road: junction_road_4, direction: straight)

do parallel(overlap: equal, duration: 20s):

        sut.vehicle.drive() with:

            speed(sut_speed)

            along(r1.resulting_route)

       traffic_vehicle.drive() with:

            speed(traffic_vehicle_speed)

            along(r2.resulting_route)

We have modeled this scenario by defining the actors (traffic_vehicle), road elements (junction and the roads meeting at the junction i.e.junction_road_*, the drive attributes (sut_speed and traffic_vehicle_speed), and the map element for specifying the road network of the scenario drive.

We then build the route for the drive using the roads_follow_in_junction() modifier which connects the four roads with the junction. Since AV takes a left turn and the traffic_vehicle drives go straight in the junction, we parameterize the direction to left for the sut_route and straight for the traffic_vehicle_route.

This is followed by describing the scenario actions by adding a drive() for both vehicles in parallel. The speed() and along() modifiers specify the speed of the vehicles during the drive and the path along which they should drive.

In this way, we can model scenarios, simulate them and analyze the AV’s behavior to see if it is safe to drive on the roads. We can come up with a scenario for several edge cases we can think of which the AV could come across during its drive, thereby increasing the cases covered during validation.

Previously, we wrote a literal to-the-point scenario restricted by specific constraints and did not take into account the various possibilities and combinations of the scenario. 

Tomorrow there could be a situation where the AV could be driving straight and the other vehicle could be making a left turn, or the other vehicle could be approaching the junction at a very high speed, and so on and so on. The way we defined the scenario is a tedious approach as we will be writing a new scenario for each of the situations the AV could come across. This process is time-consuming and also restricts our validation scope. And the possibilities being infinite we can miss out on describing some of these scenarios. Hence our AV would not be validated enough and might lead to mishaps.

Then how do we overcome this? The answer to this is “Abstract scenarios”. Write a high-level definition of the scenario that takes into account the various possibilities and combinations of the scenario. This will generate ‘n’ concrete scenarios which could be used to validate the AV.

We will write an abstract scenario for the previous concrete scenario and look at its advantages over concrete scenarios.