Skip to main content
Version: DeepHub 2024 R2 - 2.6.0

Trackable Hierarchy

Consider a simple asset tracking scenario where you want to track assets in your warehouse. You can either:

  • track assets individually by applying tracking hardware, so-called "tags", on each of them OR
  • track them indirectly (i.e. track their movements by tracking the vehicles that transport them).

The latter is the most realistic and feasible scenario, as equipping each asset with a tag would be too expensive and would require too much maintenance (e.g. replacing batteries or charging them). Indirect tracking is the way to go and the architectual concepts of omlox and the DeepHub were exactly invented for this scenario. Previously, this would have been done by attaching so-called "location provider" objects, representing a tag and being the actual source of location information, to each and every so-called "trackable" object, representing the assets and vehicles of the real world. See the explanations on this general mechanism here: The Basic Entities and Mechanisms of the DeepHub - Trackables

The new concept called "trackable hierarchy" makes it easy to model the physical process in a more intuitive way, with less source code to write and maintain: trackables can now be linked together in a parent-child-hierarchy, propagating location information from a parent trackable to child trackables. Attaching location providers to each and every trackable is now obsolete!

To create a trackable hierarchy, fill the parent property of one trackable with the id of another trackable, thereby making the latter the parent of the former. See the trackable object documentation for details.

Example

Consider the following scenario: there are two assets, "Asset A" and "Asset B", that are both placed on a pallet. The pallet is picked up by a forklift and then placed on a truck. In the DeepHub, Asset A, Asset B, the pallet, the forklift, and the truck are all represented as individual trackables.

Ideally, you would want to use the location information of the location provider attached to the forklift as the location information for the pallet and the assets placed on it.

Previously, the location provider objects would have had to be attached to all the trackable objects. Transferring the pallet from the forklift to the truck would have required re-attaching/re-linking all trackable objects to the location provider of the truck.

Now, it is as simple as attaching/linking the trackables together in a hierarchy. To create a hierarchy, the trackables representing Asset A and Asset B are configured so that the pallet trackable becomes their "parent". This parent trackable is also configured to have a parent: the trackable representing the forklift. The only trackable object with a location provider attached to it is the forklift. The location information propagates to all trackables in the hierarchy. Asset A and Asset B get their location from the pallet, which gets its location from the forklift.

When the forklift places the pallet on the truck, the pallet trackable becomes unlinked from the forklift trackable and linked to the truck trackable. The pallet trackable now retrieves its location information from that source. The hierarchy on the lower level remains unchanged: Asset A and Asset B are still children trackables of the pallet trackable.

In the illustration below, two different hierarchies are shown at different times. At first, the pallet carrying the two assets is transported by the forklift. Subsequently, the forklift offloads the pallet onto the truck.

interface