Page History

...

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
• 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

...

The Middleware is usually started by the LCC (with the right parameters, i.e. vehicle IDs) if you deploy it via the LCC. You can also start it manually given the parameters above - 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:

...