...

The Middleware offers an abstraction layer for common HLC tasks and should thus be used in combination with your HLC implementation. More information can be found here (theory). Information on implementation can be found on this page.

...

• node_id: Identification string of the middleware instance in the DDS network
• simulated_time: True if the current setup uses simulated time, else false
• middleware_domain: Domain ID for communication between middleware and HLC via shared memory, default is 1
• wait_for_start: Whether the middleware should wait for the LCC's start signal, should be true (false only for debugging purposes)
  
• vehicle_id: Single ID of a vehicle the middleware is supposed to be responsible for
• vehicle_ids: IDs of the vehicles the HLC(s) that the middleware 'controls' are responsible for (usually just one ID)
  
• vehicle_amount: Set amount of vehicles instead of vehicle ID, sets IDs 1 - vehicle_amount (restricted to 256)
• dds_domain: Domain ID of the domain in which the LCC, vehicle etc. participate
  
• domain_number: Local domain ID of the middleware and the HLC
  
• dds_initial_peer: Should be explained in Lab Control Center (Usage) 
  

Important ParameterServer Parameters

...

• offset_nanoseconds: Set the offset of the communication w.r.t. ~1970 (real time) or 0 (simulated time); should usually not be changed

QOS_LOCAL_COMMUNICATION.xml.template

The communication between Middleware and HLC takes place locally and should not be shared with the other participants in the network. Thus, this DDS QoS file makes sure that messages via both of them are only exchanged locally and that other participants do not get discovered for that. .template is used as the current IP must be used for this to work, build.bash fills in the template and creates the .xml file in the build folder. This file is also relevant for the HLC scripts, which need to use the same QoS settings to communicate with the Middleware.

How Do I Use The Middleware?

The Middleware is usually started by the LCC (with the right parameters, i.e. vehicle IDs) if you deploy it via the LCC. Don't forget that, after you have deployed the Middleware and after it has been initialized and communicated with the HLC script, you also need to send a start signal from within the timer tab.

You can also start it the Middleware manually given the parameters above (a start signal is still required though) - the most important parameters here are:

• vehicle_ids You need to tell the Middleware which vehicles your program is responsible for. It will then forward information about the vehicles to your HLC program, and your HLC program can send planned trajectories for these vehicles to the Middleware, which then sends these to the vehicles themselves.
• middleware_period_ms This parameter is set using the parameter service (theory, usage). It tells the middleware how often it should send your program new vehicle information, which you are supposed to use to start the computation of a new trajectory (and thus as timing signals).

There are some steps involved in using the Middleware after it has been started. They are mentioned below and are further elaborated in the Matlab Tutorial. Even if you use another programming language, you can use that tutorial as an implementation guideline (as DDS communication should not depend on the programming language).

...

After initialization, the Middleware waits for the initialization of the HLC. Afterwards, it tells the LCC that the HLC is ready to operate (i.e. the Middleware appears in the Timer Tab, waiting for a start signal). The Middleware only continues execution (and thus only appears in the Timer Tab) if it receives a ReadyStatus by the HLC. This signal should only be send by your implementation after every possible initialization has taken place, so that, as a next step, you can start with the computation as soon as the HLC tells you to do so.

...

The LCC regularly sends timing information in the network if simulated time is used, or only start or stop signals (to start and stop the simulation) in case of real time. The Middleware takes care of all timing signals for you, and also forwards timing information within the VehicleStateList, which you should use to obtain the current system time. But it is not able to stop the HLC directly in case a stop signal is received. Thus, SystemTrigger messages are forwarded to the HLC as well. Your implementation should only look for stop signals regularly, which are defined here. If such a signal is received, the HLC program must be stopped.

...

You can find out more about it here.

VehicleStateList

These messages are meant as timing signals for your program, but they also include all required information about the current state of all vehicles in the system. You can find out more here:

...