Skip to content

Co-Simulation

This chapter describes how OTS can be used as part of a co-simulation with another microscopic simulator or a driver simulator. This includes the following features:

  • Vehicles controlled by OTS, the external simulator, or in a hybrid mode (OTS model suggests a path, external simulator controls actual movement).
  • Vehicles spawned by the external simulator, or generated by OTS as background traffic.
  • Large degree of control on model components and parameters used for spawned vehicles.
  • Network, routes and demand defined in OTS XML, or in OpenDRIVE with routes and demand defined in JSON.

The interaction between components in the software architecture is depicted in Figure 8.1. The OTS Transceiver operates based on a number of predefined messages. These messages can be communicated between OTS and the external simulator through different forms of (de)serialization, communication protocol, and communication technology. In the figure this is indicated as Protocol, for which both OTS and the external simulator require an Interface implementation for the translation with the relevant components. For the external simulator this is referred to as Simulator.

Figure 8.1: Co-simulation software architecture.

A standard protocol interface for OTS is provided. This utilizes Sim0MQ with standard (de)serialization and TCP communication over a PAIR socket. Libraries in Java and Python exist for (de)serialization at the side of the external simulator. Another protocol may however be used, necessitating the implementation of a different Interface for OTS. The functionality of the OTS Transceiver only relies on the messages (Java objects) and is independent from the used Protocol.

The following sections describe the available messages and their order, settings and parameters, specific vehicle commands, details on the implementation of the protocol, and specifics on dead-reckoning to deal with message delay.