Overview

What is the DeepHub®?

The DeepHub® is the premier reference implementation of an omlox™ hub, a locating middleware able to run on the edge, on-premises, and in the cloud. It is compatible with the omlox™ standard - the world's first open location standard.

The DeepHub allows for seamless tracking of any asset across different positioning technologies, and facilitates all location-aware use cases in smart production and logistics, healthcare, and retail.

The most important features at a glance:

• omlox-compliant: one standardized API across all locating technologies and vendors. Consume and manage location data in the same data format.
• Georeferencing: transformation of local coordinates to global coordinate systems (e.g. WGS84) for all your sites. Stay in the lead and consume location information from all over the world in a standardized way.
• Geofencing: define areas within your sites to trigger events every time a tracked object enters or leaves the areas. Intelligent industrial automation is built on automatic triggering of actions based on locations.
• Collision detection: identify whenever two or more tracked objects come too close to each other. This is ideal to complement existing heterogeneous AGV fleet management software systems, adding an additional layer of security.

To get access to a shared cloud instance, contact our Partner Management team at partners@flowcate.com.

It is also possible to easily download and run your own DeepHub instance on your personal macOS, Windows, or Linux computer. The Running the DeepHub Locally chapter covers this in detail.

If you are familiar with Docker and Git, you can skip this step. Simply clone and run the deephub-basic-setup repository and enjoy! For a comprehensive overview, refer to our Getting Started with the DeepHub video.

The Basic Entities and Mechanisms of the DeepHub®

These are the basic entities within an omlox hub:

• Zones
• Location Providers
• Trackables
• Fences

Zones and location providers represent the software abstraction of low-level hardware and infrastructure associated with physical location tracking technologies.

Trackables and fences represent the high-level entities that are used in applications that consume assets and their locations. These applications may include asset management, traffic management, warehouse management, shopfloor management, ERP, or MES.

Let's explore the low-level entities in a bit more detail.

Zones and Location Providers

A real-time locating system connected to a DeepHub instance is represented as a zone in the DeepHub, while the devices that generate location updates, such as tags, are represented in the DeepHub as location providers. A zone can be an "RTLS zone", providing x,y,z-coordinates, or a so-called "Proximity Zone", which only provides a "is near" information.

Whenever a tag moves and is tracked, the locating system delivers the new location of the tag to the DeepHub. There this update gets processed in the form of events:

• [location_updates](./deephub/The APIs/WebsocketAPI.md#location_updates)
• [fence_events](./deephub/The APIs/WebsocketAPI.md#fence_events)
• [collision_events](./deephub/The APIs/WebsocketAPI.md#collision_events)

Location update events happen of course always, fence events and collision events only if relevant.

Refer to these videos for detailed descriptions of these two entities:

• Overview of Location Providers
• Overview of Zones

Now let's explore the high-level entities in a bit more detail:

Trackables

Applications interface with location updates, and all the other events mentioned above, via a "trackable". A trackable refers to an actual object or asset being tracked, such as a forklift, truck, or worker. It may have one or more location providers attached to it. Therefore, a location update of a location provider subsequently leads to an update of the trackable's location as well.

Trackables have a name, unique id, location, radial extrusion, or geometry. Here is a detailed [definition of a trackable](./deephub/The APIs/api.mdx#/schemas/Trackable).

Several location providers may be attached to one trackable, with each representing one locating technology. For example, in a typical industrial yard scenario, a trackable could be affixed with a GPS location provider for outdoor tracking and an UWB location provider for indoor tracking. While outside the facility, the GPS location provider would deliver location updates, thereby updating the trackable's location. While inside the facility, other locating technologies may be used. For example, BLE could be used to track a forklift, RFID tags could be attached to materials stored in a warehouse, and UWB could be used to track AGVs. Each of these locating technologies is also represented by a dedicated location provider that delivers location updates, thereby updating the trackable's location. These granular details are abstracted away for application developers - their only concern is the trackable entity itself!

Additionally, a trackable can act as a data container for metadata associated with it in the form of "custom properties". These may represent an order number, an item number, a process step, or any other vital information specifically relevant for your use case, or information that should be analyzed by the consuming high-level application.

Refer to our Overview of Trackables video for more information.

Fences

A fence, or geofence, is an entity representing a geographical area/region of special concern. Trackables and location providers entering or leaving a fence trigger fence events. These events are delivered to clients and are an integral ingredient for smart factory automation, where areas of a site are directly related to process steps. Therefore, entering or leaving an area represents a change of state within an application, such as an MES.

For a comprehensive explanation, refer to our Overview of Fences video.

The Basics About Georeferencing

To understand georeferencing, some terms from the field of GIS (geographic information system) have to be explained first.

Let's start with the "Coordinate Reference Systems (CRS)", sometimes also called "Spatial Reference System (SRS)": Put simply, a CRS defines in which way spatial data that represents the earth’s surface is defined and how it can be “flattened” to be able to be displayed on a 2-dimensional surface. A CRS uses longitude and latitude values to specify a point on the earth’s surface. There are two parts that form a Coordinate Reference System:

• Geographic Coordinate Systems (GCS)
• Projected Coordinate Systems (PCS)

A GCS is used to define your real-world points on a 3-dimensional surface. WGS84 (“World Geodetic System” number 84) is one example of a GCS. It is the most famous one. As a GCS represents points on a 3-dimensional surface it is not possible to do calculations with latitude and longitude coordinates as if they would be carthesic!

A PCS is used to take those points that you defined with your GCS and translate them to a 2-dimensional surface. This is what people commonly refer to as a "projection". It does the “flattening” that was mentioned above. It solves the problem to display a curved object on a plane surface. PCS are based on a so-called “reference ellipsoid” and define the systematic conversion of the locations given in latitudes and longitudes into locations of a plane. This results in the transformation of the geographic coordinates (latitude and longitude) into cartesian coordinates (x and y).

The standard PCS for sharing maps on the web is the so-called “Web Mercator Projection", or "Web Mercator" for short, and this is a cylindric, normal, slightly non-conformal projection based on a sphere, using coordinates of the WGS84. Such modified Mercator projection is not designed to minimize distortion at all. Instead, it was engineered for convenience in working with cached map tiles. That means:

• There is an increased distortion in north/south direction compared to the traditional Global/World Mercator projection and to a slight non-conformity.
• The entire globe is fitted into a square area that could be covered by 256 x 256 pixel tiles.
• Errors are minimized along the Equator.
• The farther away from the Equator you get, the more distorted your measurements will be.

Georeferencing, or georegistration, in the context of omlox and the DeepHub, is the act of transforming local coordinates of omlox entities, like e.g. the ground control points of a zone or a location of a location provider, into CRS coordinates. Put simply, the DeepHub allows to locate the entities precisely in the real world.

Product Requirements

• The DeepHub is offered as a Docker image (orchestrated through Docker Compose) for easy installation and flexible integration with omlox-compliant applications.
• Through Docker Compose, the DeepHub can be installed and operated on all standard operating systems.
• In order to ensure uninterrupted installation, a Docker environment for running x86_64 containers is required.
• The containerized deployment of the DeepHub through Docker enables seamless integration in various scenarios, including isolated and secure environments, without the need for high-end device specifications.

Docker Engine

The DeepHub has a small digital footprint, allowing it to run on low power industry PCs and edge devices. If the DeepHub is deployed via Docker containers, it's necessary to consider the basic requirements for running Docker Engine. Refer to the latest updates and requirements for Windows and macOS.

The host system operating the DeepHub must have Docker version 20.10.10 or higher. If this version is not available for your Linux distribution out-of-the-box, you can get it directly from Docker by following these steps:

Step 1

sudo apt-get install \
apt-transport-https ca-certificates \
curl gnupg lsb-release

Step 2

curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
| sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Step 3

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" \
| sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Step 4

sudo apt-get install \
docker-ce docker-ce-cli containerd.io

Virtualization

Virtualization must be enabled in order to run the Docker containers on non-Linux operating systems. For this purpose, the following features should be enabled:

• Virtual Machine Platform
• Windows subsystem for Linux
• Hyper-V

Network

The DeepHub uses multiple network ports that must be available during installation.

Port 8081: DeepHub Docker Proxy

This port needs to be available on the host device. Docker Compose orchestration is configured on this port to facilitate the communication between the DeepHub backend with external interfaces.

Port 443: Outgoing Internet Access for License Lease & Consumption API Endpoint

This port needs to be available in order to get a lease for the DeepHub instance when contacting our license server. For more information, refer to the license mechanism section.

Pricing Model

The pricing model of the DeepHub is subscription-based. For each end-customer and project, you acquire a subscription with the necessary features and capabilities to build your tailored solution with the pricing model that suits that specific use-case and business-case:

• per site depending on the number of locating technologies you want to use and the number of zones/areas to cover
• per sqm
• per number of tracked assets
• consumption based; i.e. based on the number of processed events

You may deploy a DeepHub instance on-premise at your customer's site, or operate and maintain it yourself - this is entirely up to you.

Our DeepHub is also available as a white label product if your intention is for product bundling.

Please get in contact with us to learn more about the possibilities.

License Mechanism

The DeepHub comes with a simple license mechanism:

• Once a day, the DeepHub sends consumption and usage statistics to a Flowcate License Server on SSL/HTTPS port 443 and gets a "lease" back in response.
• The latter contains all necessary information for the DeepHub, including when to contact the license server again.
• This mechanism is always in place, regardless of whether you have an industrial-grade production system or a first trial installation.
• For every subscription, you will receive a trial license key, a development license key, and a production license key. These would have to be defined in the DeepHub configuration.

You get even more

As a partner, you'll get access to the latest versions of the DeepHub via a Docker repository from which you can pull the latest images. Additionally, you'll get access to our online support tool, enabling you to request support, send feature requests, access the latest information on upcoming releases, share thoughts and insights in the DeepHub community, and get all the latest onboarding material.

Get in touch with our Partner Management team at partners@flowcate.com and start your journey into the Deep Universe.