Automotive Industry Insights

ASAM Open Simulation Interface (OSI)

Description
To achieve a widespread use of driving simulators for function developers, the connection between the function development framework and the simulation environment has to rely on generic interfaces. ASAM OSI provides easy and straightforward compatibility between automated driving functions and the variety of driving simulation frameworks available. It allows users to connect any sensor, via a standardized interface, to any automated driving function and to any driving simulator tooling. It simplifies integration and thus significantly strengthens the accessibility and usefulness of virtual testing.

ASAM OSI (Open Simulation Interface) started as a generic data exchange interface compliant with the ISO 23150 logic interface for the environmental perception of automated driving functions in virtual scenarios. In tandem with packaging specifications, such as the ASAM OSI Sensor Model Packaging (OSMP) specification, ASAM OSI provides solutions for simulation model data exchange across different implementations.

ASAM OSI contains an object-based environment description using the message format of the protocol buffer library developed and maintained by Google. ASAM OSI defines top-level messages that are used to exchange data between separate models. Top-level messages define the GroundTruth interface, the SensorData interface, and, since ASAM OSI version 3.0.0, the SensorView/Sensor-View configuration interfaces and the FeatureData interface. The GroundTruth interface provides an exact view on the simulated objects in a global coordinate system, the ground truth world coordinate system. The FeatureData interface provides a list of simple features in the reference frame of the respective sensor of a vehicle for environmental perception. It is generated from a GroundTruth message and may serve as input for a sensor model that simulates object detection or feature fusion of multiple sensors.

The following figure shows the interfaces and models involved in modeling a sensor.

OSI also defines interfaces for traffic participant models. The TrafficCommand interface makes it possible to send commands to traffic participant models. The TrafficUpdate interface makes it possible to receive the updated state from traffic participant models. The following figure shows the interfaces of a generic traffic participant.

Traffic participant models may use other OSI interfaces internally, for example to model autonomous vehicles. The following figure shows a more advanced use case for traffic participants.

Status
The ongoing development activity at ASAM aims to further extend ASAM OSI in order to fulfill the requirement of being able to use it as a standardized interface between further simulation entities.

The latest version of OSI, version 3.4.0, was released in November 2021.

Potential implications of OSI for testing
As a standardized interface for models in a test, including sensor models and traffic participant models, OSI provides significant interchangeability and reusability of models across different test techniques such as HIL, MIL, or SIL. This becomes ever more relevant as multiple techniques are employed to satisfy a test goal. As touched on in the discussion around OpenODD, the systems being tested are ever growing in complexity, and it is becoming increasingly important to reduce the complexity of tests for transparency. Maintaining the same model across tests provides one less variable to take into account.

Further details on the interaction of models with a test are discussed in the section on the Functional Mockup Interface (FMI). The strong interplay between OSI and FMI needs to be taken into account through the development of such testing workflows.

Insights into how this standard might evolve
OSI is continually being developed to support further model types in a simulation or test environment, one example being as an interface to a vehicle-in-the-loop. It is possible that further test-specific or testing-technique-specific messages are implemented in OSI, whether as an extension to existing messages to account for test-specific data or as additional interfaces, for example to an ODD or test layer.

Performance is seen as a limiting factor for many applications of OSI. Prior to extending the current OSI standard further it is recommended that its relatively high performance overhead is improved. Similar considerations have been introduced in the current development project, which aims to investigate alternative, more performant formats to Protobuf.

As it is also being developed as an interface between many of the features in the OpenX standards (for example between a scenario engine and a traffic participant or to a traffic signal), any changes made to the other OpenX standards will need to be considered and integrated into OSI. One such change could be extending the TrafficCommand messages to support the exchange of test-specific information with traffic entities.