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.
Communication.hpp
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)
TypedCommunication.hpp
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.
The Middleware coordinates the communication with the DDS domain of the vehicle, LCC and further participants with the HLC. It is responsible for sending timed pre-aggregated vehicle information to the HLC. These can be interpreted as a start signal for starting the computation using this data. It sends the commands generated by the HLC as a reaction to this start signal to the vehicles. Any timing task is performed by the Middleware, so period and offset for the interaction with the HLC are set here (and can be set when starting the application using command line parameters). The HLC is informed about the current time, in case that is necessary for its own computations.
Figure: Communication from other participants to the HLC filtered by the Middleware
Figure: Communication from the HLC to other participants
The middleware also manages further internal timing according to the current simulated and real time, propagates the LLC's start and stop signals and waits for the HLC to finish its computation in the simulated case. It is also responsible for logging communication or timing errors.
The HLC only needs to integrate and configure a reader and a writer to listen to the Middleware and send commands. Thus, as long as the programming language is supported by RTI DDS, the programmer does not need to know the implementation details of the communication.
Functionality
- Logging
- Waiting for the HLC to join the domain & send a ready message
- Periodically calling the HLC to request commands for the vehicle
- Forwarding vehicle state information to the HLC periodically (always the newest information is sent) + timing information s.t. the HLC does not need to care about getting the right timestamps itself
- Forwarding commands sent by the HLC to the vehicle
- Forwarding stop signals to the HLC
- Receiving (some) parameters from the parameter server
Overview
Content Tools