2.2.1 Overview of OSI architecture

OSI contains an object-based environment description that uses the message format of the Protocol Buffer library. Google developed and maintains the Protocol Buffer library. 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 OSI version 3.0.0 – the interfaces SensorView, SensorViewConfiguration, and FeatureData.

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

Figure 1. Open Simulation Interface overview

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.

Figure 2. Interface of a 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.

Figure 3. Traffic participant with sensor models, AD function, and dynamic model

The HostVehicleData interface describes the measured internal states of a traffic participant. OSI currently provides only limited support for data structures that describe measured internal states of traffic participants. One example would be the MotionRequest interface that can be used to communicate the results of the behavior planning to the dynamic model.

The StreamingUpdate interface enables partial ground truth updates to modules that favor performance, especially latency, over data completeness/consistency (e.g. visualization applications) or that do not require complete data in the first place (e.g. logging applications).

Figure 4. Interface for partial ground truth updates

OSI uses singular instead of plural for repeated field names.

All fields in an interface are set to optional. required is not used.

This has been done to allow backward-compatible changes in the field. Additionally, this is the default behavior in Protocol Buffer version 3 that no longer has the required type. Setting all fields to optional thus ensures update compatibility. However, this does not mean that it is optional to fill the field. For the purpose of providing a complete interface, all existing fields should be set, unless not setting a field carries a specific meaning, as indicated in the accompanying comment.

All field numbers equal to or greater than 10000 are available for user-specific extensions via custom fields. No future evolution of OSI will therefore use field numbers equal to or greater than 10000.