Page History

Main.cpp

In the main file, all important parameters are initialized. This includes the IDs of the vehicles the software is supposed to listen to, or the length of a computation period. Most of these parameters can be set in the command line. Also, the timer from the cpm library and the communication class are set up.

In the following, the Middleware waits for all connected HLCs (set using the vehicle IDs) to communicate a ReadySignal, denoting that they have finished their part of the initialization. The ReadySignal messages are sent by the HLCs and have the ID "hlc_" + vehicle_id, where the latter is the ID of the vehicle the HLC is responsible for. After that, the timer is started and the Middleware starts to periodically perform its tasks.

In each step, first the most recent vehicle states and observations are taken from the communication class, put into a DDS message and sent to the HLC(s), together with the current timestamp. These messages function as start signals for the HLCs. Then, the last response times of all connected HLCs are checked. In the real-time case, if they haven't sent any vehicle commands before or if the last message is older than one period, an error is logged to make clear that a period was missed. In the simulated time case, the Middleware waits for all connected HLCs  to send a vehicle command before progressing to the next period.

This behavior is repeated until the Middleware is stopped.

...

This class is responsible for separating all tasks related to the communication, including the initialization of RTI DDS participants, from the main file. Apart from initialization, it:

• collects the last response times of the HLCs regarding vehicle command messages of all command types (these messages are received an propagated using the typed communication class)
• can be used to send the vehicle + time information message to the HLC
• can be used to obtain the most recent vehicle state and observation messages
• passes SystemTrigger messages sent by the LCC to the HLC
• includes a function to wait for all ReadySignal messages sent by the connected HLCs (as described above)

...

The methods and objects to receive and pass through vehicle commands from the HLCs to the vehicles as well as to get the last response times of the HLCs are the same for all command types. This class provides a template to set up this functionality without redundant code and is used in the typed communication class.

XML Configuration File

The middleware uses the XML file QOS_LOCAL_COMMUNICATION.xml to configure the DDS participants. It must be in the same directory as the executable to work properly. Furthermore, the TEMPLATE_IP String in the file needs to be replaced with the current IP of the user's system - this is done automatically in the build task, so, if you wish to move the executable to another folder, be sure to move the XML file that was put in the build folder as well, and do not forget the library .so files from the same folder.

IDL File - VehicleStateList

The middleware has its own IDL file for communicating with the HLC. It is not part of the cpm library because it is not required for any other application. It is used for sending current aggregated data for the vehicles as well as timing information from the middleware to the HLC(s).

Middleware Workflow

Shared or common functionality for the communication via DDS is bundled in the cpm library (cpm_lib). This library is written in C++ and is used by the vehicle, the LCC and the Middleware. The HLC, on the other hand, is supposed to be more or less independent from the implementation language of the library. Programmers of the HLC programs should not be troubled with its implementation details. Thus, it was decided to create a Middleware which performs most of the communication tasks that otherwise would have to be implemented in some form in the HLC, which might not be able to use a C++ library.

...