A Real-time locating system (RTLS) automatically tracks the location of objects or people. Beacons, sometimes called tags, are placed on things that move and gateways, sometimes called locators, detect the beacons and send data to software either locally or in the cloud. A user interface shows the current locations.
Most organisations looking for a RTLS for the first time don’t know what aspects of systems are most important. People usually focus on maximum accuracy when, in fact, a system with maximum accuracy involves consequent undesirable compromises. Some suppliers’ marketing also focuses on performance that’s only achievable in a lab or factors that might seem important now but will become less important when other issues are known. In practice, every situation is different and you need to balance factors based on your needs.
Number of Assets
The number of assets you need to track usually has largest influence on the type of system you should consider. All systems are limited by how much data they can process. More accurate systems such as Ultra-Wideband (UWB) and Bluetooth AoA produce more data and hence support a lower maximum number of assets. However, the actual number depends on many factors such as the underlying hardware speed, the network speed (i.e. is local or in the cloud) and settings within the RTLS system itself.
Scalability
When talking to vendors, it’s important they assess the number assets you will need in the future, as well as now, so as to not outgrow a system. Scalability isn’t only about assets. It also involves the number of gateways, the degree to which they overlap physical areas, thus producing more data for more accuracy, and the scalability of subsequent processing software.
API
The use of RTLS is much like the Internet of Things (IoT) in that everyone wants to get something slightly different out of the data. If you require something other than searching for assets, this means you or your vendor will need to write reports, scripts or use reporting tools such as Grafana to extract insights. The RTLS should have an API, usually using HTTP REST, to extract data. If you have local access to the system, it’s often more flexible and faster if you can also gain direct access to the underlying database for reporting. This also opens up the number of off-the-self reporting tools that can be used.
Most systems have a user interface where you can add and remove beacons and gateways. However, imagine doing this for 1000s of assets. Look for an API to allow you to add, modify and view beacons and gateways programmatically. This allows other programs such as apps, ERP, WMS, your custom systems and scripts to simplify integration.
Flexibility
In reality, systems tend to get re-used for more than one use case as the organisation’s digital maturity grows. Check the system provides suitable access to the data for future uses. Ensure various beacon models are available for those anticipated uses.
Accuracy
As previously mentioned, the best accuracy isn’t always the top consideration. Our article on microlocation accuracy explains the different kinds of system and corresponding accuracy. Note also, that many RTLS have settings that balance accuracy with latency and maximum number of assets.
Latency
Latency is how long it takes to know a new location after something has moved. A shorter latency requires the assets to send data more often thus decreasing asset battery life. More data also implies a fewer maximum number of beacons.
Battery Life
As mentioned, above, the frequency of beacons advertising their location directly impacts beacon battery life. Systems such as UWB and Bluetooth AoA tend to have beacons advertising more often to allow higher accuracy. However, look for beacons that have accelerometers that advertise more often only when moving thus saving battery life.
License Type
Consider if you need a system locally, in the vendor’s cloud or your own cloud. For thousands of assets, reporting frequently for low latency, you will need the system to be local. If you are using SaaS you will also need to consider issues such as the service level agreement (SLA) and the location of the server for privacy requirements such as GDPR. Another issue related to SaaS, particularly with VC start-ups, is the longevity of the solution. Is the vendor going to be providing the platform as long as your project? Some early beacon platforms have already closed. Others have been taken over by large companies that have other agendas.
Security
You need to assess the security of the proposed system. This includes factors such as logins, SSL, secure APIs and the security related to the location/hosting of system.
Price
As well as the headline price, also consider if the solution is financially scalable once you increase the number of assets and gateways. Also determine if future costs are known and acceptable.
Summary
Remember that the ‘best’ RTLS is not the one the vendor claims as best for some arbitrary feature but instead is the one that best suits your needs. You will need to balance the needs of the project with the capability of the RTLS that offers the best fit.
