Changing the Location Aggregation Rate

The following describes how location aggregation works in SmartSpace and when you might want to change the location aggregation rate.

Location aggregation is used by:

• Object placement in SmartSpace Config

• Location logging in Reporting

• Web maps in SmartSpace Web

• Getting the locations of path points in Paths and queues

How Location Aggregation Works

Location Aggregation is used when combining location events from location cells to give a representation of the current positions across the whole site. To see why this can be a problem, we should look at a typical example.

Consider a tag updating its location at a rate of 1 Hz. You may have dozens of these tags in a location cell. These tags are probably associated with, and driving, a product or other SmartSpace object. You may also have tools with tool tags that update at 8 Hz. If you have 50 objects and 100 tools in a location cell, that cell will be receiving 50 x 2 x 1 + 100 x 2 x 8 = 1700 location events every second. With many location cells across a site, aggregating these location events at this rate, and sending them to all clients to display, would very quickly become impossible, using up network, CPU, battery, etc.

To provide a useful display of object locations at the site level, such as on the web map or in SmartSpace Config, all that is really required is that the position shown for an object will eventually, within some bounded time interval, be updated to the most recent position. Intermediate location events can be dropped if necessary. Mostly these will be small movements and not significant enough to be worth updating a display at that rate.

To reduce this load and still present up-to-date displays, we have aggregation. The goal of aggregation is to share a maximum location event rate fairly across all objects that are getting location updates.

In effect aggregation works by sampling locations. All locations are delivered to a location cell. For each location cell there is a corresponding location aggregation service which consumes locations from the location cell at a default rate of 50 events per second (an aggregation frequency of 50 Hz). Higher level services or clients consume locations from the aggregation service rather than directly from the location cells. In practice, the web map consumes locations from a site-level aggregation service which in turn consumes locations from a geometry-cell level aggregation service, which itself gets locations from the location cell.

Within the location aggregation service a pair of queues is maintained. One holds a list of objects to process (P), and the other a list of objects whose location is updated (U). The lists are ordered by object type and object ID. The service works through P at the specified rate (50 Hz by default) and adds the current location of each object to its schema. Meanwhile as cell locations of objects are updated or removed, those objects are added to U if they are not already present. So U contains all objects that may have moved since they were last aggregated. When the end of P is reached, U is copied to P, U is cleared, and the cycle repeats. If objects are updated faster than they are processed, any locations that arrive between the times at which an object is processed are simply skipped.

Why Change the Location Aggregation Rate?

The web map and OBJECT PLACEMENT in SmartSpace Config get their object locations from the site-level aggregation service. If there are many moving objects in the system, then when operating at 50 Hz there may not be enough time to process the locations of objects in near real time and the display of a located object may fall behind the actual location of an object by several seconds. For example, with a location cell with 1500 moving objects (tags and driven objects) and an aggregation frequency of 50 Hz it would take around 30 seconds for all objects to get processed, which means there could be a latency of up to 30 seconds between an object getting located in the location cell and this location being displayed in a graphical screen. Also, objects are processed in the order of their type and ID. So tags will get processed first and driven objects later. This will result in different latencies for a tag and its associated object. The result of this is that when a tag is manually moved, the associated object may not move for several seconds. Most of the time this does not matter because normally tag and object locations are not usually monitored side-by-side except for testing. Also object movements are usually relatively small so that a few skipped locations are not noticeable. Where it does become noticeable is when spatial monitoring is involved. Spatial monitoring happens in real time so an object may be reported as contained in a space but not be displayed in the space until some tens of seconds later.

Note: Spatial monitoring does not itself use aggregated locations. Entry and exit to spaces is evaluated directly from locations in the location cell and is therefore real time. Actions such as PLC messages that are triggered from spatial events are therefore not affected by aggregation lag.

How to Change the Aggregation Rate

The default aggregate frequency of 50 Hz is very conservative. If aggregation lag is a problem, generally if you have a very large number of moving objects in the location cells, you can increase the frequency of object processing in the location aggregation services. To do this, you specify a value for the aggregate_frequency configuration parameter.

Values of 500 or even 1000 have been used, but you should try out different values to find an appropriate setting. To get an idea of a suitable value, look at how many regularly moving objects are in the busiest location cell. Include both tags and driven objects. If you have 1000 objects getting located at 1 Hz, and can accept an average aggregation lag of 1 second (a maximum of 2 seconds), then an aggregation frequency of 500 will suffice. Remember location aggregation only considers objects whose locations have changes: static objects do not use up any of the aggregation rate.

Note: There is only one configuration setting and it covers all location aggregation services.

The parameter can be set using the ubisense_configuration_client application. The command

sets the configuration parameter <parameter name> to the value <parameter value>.

For example, use the command:

to set the aggregate frequency to 500 Hz.

After you have run the command, you must restart all location aggregation services: