TABLE OF CONTENTS


In certain environments, such as smart factories, multiple locating technologies may be installed that simultaneously track individual objects. For example, an AGV could be tracked using UWB and Wi-Fi, where each technology sends location updates to the DeepHub at the same time. This makes it challenging to determine which location update is correct. 

 

The DeepHub rule engine circumvents this issue by enabling you to apply rules that dictate the prioritization of location providers in relation to trackables. 

 

Through the DeepHub API or the DeepHub UI, you may define either a ruleset that applies to all trackables, or specific rules for individual trackables. Here is a comprehensive Technical Deep Dive on this feature:



Ruleset

When working with the global ruleset that applies to all trackables in your DeepHub instance, there are a few API endpoints that are relevant: 

  • GET /trackables/rules/locating - returns the global ruleset for all trackables.

  • PUT /trackables/rules/locating - used for creating, updating, or deleting the global ruleset.

  • POST /validator/rules/locating - used for validating a single locating rule expression.

 

Alternatively, you can modify the global ruleset entirely using the UI. In the event that you provide an incorrect locating rule expression, the UI will flag this.



Rules for Individual Trackables

For even greater control of your data, you may also define trackable-specific rules. These override the global ruleset. There are two API endpoints that are relevant for trackable-specific rules: 

  • GET /trackables/{trackable_id} - returns the trackable with the given id, including any locating rules associated with it.

  • PUT /trackables/{trackable_id} - used for creating, updating, or deleting a locating rule for the given trackable.

 

Alternatively, you can use the UI to modify trackable-specific rules.


Note: a rule with the largest 'priority' value will have the highest priority.


Properties

Locating rule expressions may incorporate the properties below. There is a wide spectrum of use cases and conditions that warrant different combinations and applications of these properties.


Accuracy

The 'accuracy' property refers to the horizontal accuracy of the location update in meters.


An example application of this could be a scenario in which a trackable is tracked throughout outdoor and indoor environments with GPS and UWB. When the trackable leaves an indoor area, the UWB location provider would become inaccurate. Therefore, a location update from the GPS location provider should take precedence as long as it is recent and sufficiently accurate. Example expression:

  {
    "expression": "type = 'gps' AND timestamp_diff <= 1000 AND accuracy < 5",
    "priority": 10
  }

Provider ID

The 'provider_id' property refers to the unique identifier of the location provider.

Type

The 'type' property refers to the locating technology of the location provider ('uwb', 'wifi', 'rfid', 'ibeacon', 'virtual', 'unknown', 'gps').

Source

The 'source' property refers to the unique identifier of the RTLS (zone_id or foreign_id).

An example application of this could be a scenario in which a single locating technology is installed from multiple RTLS, however a specific RTLS should take precedence. Example expression:
  {
    "expression": "type = 'wifi' AND source = 'wifi_zone_1'",
    "priority": 7
  }

Floor

The 'floor' property represents the building floor, where 0 is the ground floor.


An example application of this could be a scenario in which an object is tracked with multiple locating technologies across multiple floors of a building. Each floor is installed with a RTLS from different location providers. When the trackable is on a specific floor, it needs to be tracked using the best possible location provider. Example expression:

  {
    "expression": "type = 'wifi' AND floor = 2 AND timestamp_diff <= 3000",
    "priority": 9
  }

Speed

The 'speed' property refers to the speed in meters per second.


Timestamp Difference

The 'timestamp_diff' property refers to an integer that represents the difference between current time and the timestamp of a location (i.e. timestamp_generated) in milliseconds.

An example application of this could be a scenario in which a trackable is tracked throughout outdoor and indoor environments with GPS and UWB. When the trackable is indoors, the GPS location provider would be inaccurate and send fewer location updates. Therefore, a location update from the UWB location provider should take precedence as long as it is recent. Example expression:

  {
    "expression": "type = 'uwb' AND timestamp_diff <= 1000",
    "priority": 5
  }


Expression Language

The language used for locating rule expressions follows SQL language expressions. At a basic level, the following are supported:

  • Boolean expressions (AND, OR)
  • Negation (NOT)
  • Pairwise comparison (BETWEEN)
  • Comparison list (IN, NOT IN)
  • Basic arithmetic operations (+, -, *, /)
  • Comparison operators (<, >, <=, >=, =, NOT NULL, ISNULL)