Data transfer & storage

A simplified topology of our cloud infrastructure can be seen here:

No positioning data (live or historic) is stored in our cloud.

The Pozyx Cloud API uses a MongoDB to store user data and setup configurations, but it does not store positioning data. The following data from each setup connected to our cloud is stored in our MongoDB:

Postioning server information
Anchors & tags configuration
Floor plan & zones configuration
Positioning & UWB settings
API keys for MQTT access via the cloud
Virtual tags configuration
Simulator configuration
Tag recordings taken in the validation tool & validation reports (Pozyx developer tool only)

The postioning server also has 2 databases running inside of it:

A NoSQL database to store the configuration data: postioning server information
- Anchors & tags configuration
- Floor plan & zones configuration
- Positioning & UWB settings
- Virtual tags configuration
- Simulator configuration

An SQL database optimized for time-series data to store the analytics data

Some data that is stored in the cloud is not stored on the postioning server:

Validation reports (Pozyx developer tool only): The validation reports are generated by a microservice that is only running in the cloud and is not available on the postioning server, therefore this feature and it's data are not available on the postioning server itself.
API keys for MQTT access via the cloud: These are only needed for access to the MQTT stream via the cloud, therefor they don't need to be stored on the postioning server.

And some data that is stored on the postioning server is not stored in the cloud:

Analytics data: Our cloud does not store ANY positioning data.

Data between the postioning server and the Cloud API flows in 2 directions. From the postioning server to the Cloud API, and from the Cloud API to the postioning server:

When data is changed from within the postioning server (e.g. when a user updates a setting through the web application running in the postioning server) it will be changed in the NoSQL database running in the postioning server and the data change will be pushed to the cloud.
When data is changed from within the cloud (e.g. when a user updates a setting through the web application running in the cloud) it will be changed in the MongoDB database running in the cloud and the data change will be pushed to the postioning server.

When the postioning server gets disconnected from the cloud for some time, discrepancies between the database in the postioning server and the database in the cloud will arise. The following mechanism is in place to solve these discrepancies:

A queue in the postioning server keeps record of deltas to be sent to the cloud.
When a connection has been successfully established, the postioning server sends all queued messages. This applies all pending deltas to the database in the cloud.
The postioning server then fetches all relevant data from the cloud and applies this to the local database in the postioning server.

There is no timestamp check in place that checks which data is older and which data is newer. This means that data stored in the database in the postioning server has priority over the data stored in the database in the cloud: When the postioning server is disconnected from the cloud and a setting (e.g. the UWB channel) is changed to value x in the postioning server and to value y in the cloud, then upon a reconnect the setting's value x will be pushed from the postioning server to the cloud and will there override value y.