This section describes considerations for usage and adaptation of the reference solution.
The hlc-server open source software package can be deployed on anything from a Raspberry Pi to a high-end cloud server, as it is designed for accessibility and versatility. Up to a given throughput of real-time location data, simply providing an adequate CPU is sufficient to ensure good performance. However, beyond a certain threshold, it is more efficient to optimize the architecture as opposed to simply scale up the CPU. This is discussed in the Scaling Considerations below.
The Elastic stack can also be deployed on a different machine than the hlc-server, allowing tailored resources for the very different needs of each.
With respect to real-time location hardware (the devices that detect and relay radio packets to the RTLS software), there are many vendors and technologies to consider. The most widespread Active RFID technology is Bluetooth Low Energy, and its Passive RFID counterpart is RAIN RFID. In the case of BLE, an off-the-shelf device such as the Raspberry Pi 3 can act as a receiver, and relay the packets with our open source software. In the case of RAIN RFID, more elaborate hardware is required, which can be sourced from a variety of vendors.
With respect to open source technology-agnostic RTLS software, we are not aware of any alternatives.
With respect to databases and analytics suites, there are many alternatives to the Elastic stack. In most cases, it would be straightforward to write a connector (equivalent to barnacles-elasticsearch) to integrate another database.
Data Architecture Considerations
The output of the Sample Solution is data, specifically a stream of data points representing who/what is where/how. In a purely real-time application (where no data is stored), the only consideration is to make use of the data as it is produced. In applications where data is stored, there are many more considerations.
Where to store the data?
The type of database or medium in which to store the historic data will impact the cost and the performance of retrieval and manipulation of that data. The geographic location of the computing resources on which the data is stored may also be a consideration. Legal or contractual requirements may stipulate that the data be stored in the country or region where it is produced.
How long to store the data?
A real-time location system running 24/7 can produce a significant amount of data, which, if not archived or destroyed after a given time, can lead to degradation of system performance and significant additional costs.
What data to store?
A Bluetooth Low Energy RTLS can collect real-time location data about all BLE devices present in the space(s) under observation. In the case where only specific devices should be tracked (e.g. tagged assets) and others can be ignored (e.g. smartphones and wearables), simply whitelisting the devices of interest can reduce the amount of stored data, and hence costs, significantly.
The Sample Solution is designed for convenience of experimentation rather than for secure production deployment. By default, the software will accept input data (in the form of UDP packets) from any source and provide API access without authentication.
Security of ingress and egress data, if required, is left to the user. For ingress, the simplest solution is to apply firewall rules (e.g. ufw on Ubuntu) to accept inbound UDP packets only from specific IP addresses. For egress, a simple solution is to install and configure NGINX such that basic authentication is required to access the API and web apps.
There are no significant networking considerations aside from industry-standard best practices.
The Sample Solution’s scalability is limited by the data throughput and the available computing resources (primarily CPU). Past a certain throughput, it is more effective to parallelize the architecture rather than scale up the CPU.
With respect to the hlc-server software, in a high-throughput application, it may be more effective to run multiple instances of the barnacles sub-package, balancing the load between them based on the radio-identifiers of the incoming data stream. In other words, multiple barnacles instances can operate completely independently, provided that data from each specific radio-identified device is always routed to the same barnacles instance.
With respect to Elasticsearch and Kibana, in a high-throughput application, it is recommended to observe the best practices for Elastic stack. Running these on the same machine as hlc-server, as in the Sample Solution, will only scale to a limited extent. The Elasticsearch service instead provides flexible scalabilty, albeit for a fee.
The Sample Solution is not specifically designed to maximise availability, but has nonetheless demonstrated high availability when operating within its scaling limits. Operating parallel instances, similar to that described in the Scalability Considerations section, is recommended where availability is a critical factor.
User Interface (UI) Considerations
The hlc-server software package of the Sample Solution includes a number of open source web applications which serve as a user interface. These web applications are written in HTML, CSS and vanilla JS (no frameworks) for readability and ease of modification/extension. Users are encouraged to customise and extend these web applications, and to share with the community.
Most real-time web applications are built using beaver.js, which abstracts away from the developer the interaction with the WebSocket API so they can focus on building the application itself.
The APIs provided by the hlc-server software package of the Sample Solution are sufficient for most use cases. Should an extended or revised API be required for data access, it is recommended to create a barnacles interface package. Should an API be required to ingest data from third-party RTLS hardware, it is recommended to create a barnowl listener package.
The APIs may also be wrapped in a layer of security and/or authentication if required.
The Sample Solution is I/O intensive and most costs are related to the continuous processing of a real-time data stream. Aside from optimizing the cloud hardware specifications to manage costs, a compelling alternative is to push as much processing as possible to the edge, offloading the cloud.
A good edge/cloud balance is often achieved by running barnowl at the edge and barnacles in the cloud. In this case, barnowl buffers data for one second (by default) resulting in significant (lossless) compression, reducing bandwidth and upstream processing requirements.
The hlc-server open source software package of the Sample Solution is MIT licensed. This is a permissive license where, in most cases, the only consideration for a user/developer is the following clause:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
The open source versions of Elasticsearch and Kibana are licensed under the Apache License Version 2.0. Alternative versions of these products use the Elastic License.
The source code of the hlc-server and the reelyActive software packages on which it depends can be found on reelyActive’s GitHub account: github.com/reelyactive
The open source Elasticsearch and Kibana can be found on Elastic’s GitHub account: github.com/elastic
The following terminology, as defined below, may be used throughout this document.
|IoT||Internet of Things|
|BLE||Bluetooth Low Energy|
|RTLS||Real-Time Location System|
|raddec||RADio DECoding (see raddec library)|
|API||Application Programming Interface|