A Blueprint for New ADAS/AD Test Strategies

Scenario-based Testing on Proving Grounds

This section presents scenario-based testing of highly automated vehicle functions in the area of the proving ground. The following user journey demonstrates the high-level view of the workflow. A possible cut-in scenario for the traffic jam chauffeur use case is described in the procedure. The focus of the examples is on the interaction between test cases, scenarios, and test-environment-specific conditions. 

User Journey
In this user journey, the different phases for the validation of ADAS/AD functions in the area of scenario-based testing are shown. Here, the focus is on the testing of highly automated vehicle functions in the area of the proving ground.

Derive Test Case Descriptions from ASAM OpenSCENARIO
Mapping a simulated scenario out of an OpenSCENARIO description requires additional information to cover all the needs of the proving ground. The ISO 22133 metalanguage describes the behavior of individual participants within a scenario on the proving ground. Every participant needs to have an individual scenario description based on this metalanguage. One possible approach is to translate OpenX information into this language. Using the ISO 22133 description language, a scenario is described by a text file that consists of several lines. Each line is defined by a given type:

Object

• Described by an ID and its physical dimensions

Event

• Contains information about a condition whose fulfilment is to be checked
• Phase contains information about a trajectory segment and a list of events which can cause phase transitions during the execution of the trajectory segment. The parametrized OpenDRIVE coordinate is used as the desired position for the given object.

This information must be transformed to the ISO 22133 protocol messages, which are controlling the individual participants.

The device interface description (DIDX) describes the vehicles’ supported ISO 22133 messages and additional information, limitations, and parameters of the test object. The DIDX file is XML based and split into seven main sections. It must implement the DIDX schema as specified in this document.

• Information: This section contains some general information about the file and the test object. All information specified in this document must be included in the DIDX. Vendor-specific information may be added
• Limitations: This section contains the limitations of the test object. The limitations and the corresponding units are specified
• Messages: For each message the test object supports, an entry must be made in the DIDX
• Data types: Special data types are specified in this section and can be referenced by another data type or the content of a message. A data type can be a structure, an enumeration, or a bitfield
• Parameters: This section describes the parameters of the test object, which can be accessed via the control center. Each parameter has a name, a parameter ID, an access type, and the data type
• Error codes: This section defines the error codes from the MONR message
• Protocol tunnel: Defines the ID, name, vendor, and the version of the protocol which is tunneled through the ISO protocol

Requirements concerning Test Specifications

The task of the control center is to control all test objects on the proving ground. To be vendor independent, the OpenSCENARIO standard is used to describe the test scenario. It is mandatory for the control center to be able to parse OpenSCENARIO and OpenDRIVE files as input.

To control test objects such as driving robots and target carriers, ISO 22133 is used. This provides the possibility for using test objects and control centers from different vendors.

In order to perform a lane change the open scenario file needs to be provided. The control center internally parses the file and translates it to ISO 22133 messages to upload the scenario to the test objects. Due to the different dynamics of the test objects, the DIDX is used to pre-check all limits and may make some changes to the scenario in order to perform the test. All test objects send their telemetry data over the network to operate control loops if necessary. Telemetry data is recorded by the control center for postprocessing and evaluation.

A control center may give an initial report if the test was performed correctly.

Conclusion:
The suitability of OpenSCENARIO for the Proving Ground use case seems promising but needs further investigation.

ISO 22133, Road Vehicles – Test Object Monitoring and Control for Active Safety and Automated/Autonomous Vehicle Testing, specifies requirements, functionality, and a protocol to control manufacturer-independent target carrier systems. To provide all the information that is missing in OpenSCENARIO, ISO 22133 contains a device interface description (DIDX) and a scenario description metalanguage.