Avoid crying wolf
2020.05.01During the last few weeks, we have been working on the development of a Blue Force tracker integration.. The main goal of this project is to be able to indicate a radar target is known/friendly. We got this idea from a project where the end user asked if this was possible. It would be beneficial both for the operator to see where the friendly personnel is located and also be possible for approved personnel to pass into an area and not create an alarm that needs to be managed by monitoring operators.
To achieve this we had the idea of using a GPS tracker that a guard could wear. The tracker could then send position data to a server and then pushed into the system as a track. We would then use the “Fusion-track” functionality in the system to fuse both the radar- and the GPS-target.
To be able to fuse the targets they have to be pretty close to each other; our estimation was that we needed a maximum of 10-15 meters. This means that the update rate has to fairly high. The system needs to be updated with a new position once every second. By using one GPS-position, course and speed we thought we could do it with one GPS-position every 10 seconds.
We started scanning the market of GPS-trackers but very soon found that the commercial trackers do not really meet these requirements. Most of them have the purpose to track equipment, children, or the elderly and the update rate is low; 1 update every 1-30 minutes. We made contact with 2 companies in western Europe and asked if it was possible to adjust the update frequency. This was possible but then there we would hit another limitation, namely battery life. It turned out that these commercial trackers had to be really small and light to appeal end-users.
If you are interested or are looking for GPS-trackers we can recommend Tailit [https://www.tailit.com/] from Norway and Yepzon [https://yepzon.com/sv/] from Finland. Really handy products although they did not fit our needs.
We also looked at other systems that do GPS-tracking. The Long Range RF Trackers from RTS [https://www.remotetrackingsystems.com/] looks really good. It both has a high update rate and a large battery. Motorola has all technology and know-how regarding radio communication and they also have a GPS-tracking system that uses its radio infrastructure and technology [https://www.motorolasolutions.com/en_us/application-catalog/gps-tracking-asset-management.html#benefits]. The downside with both of these systems is that a special radio infrastructure has to be installed. This might be totally acceptable in a real project or even already in place, but we wanted to do a proof-of-concept in a short time. For sure we can integrate position-data from these systems.
Mobile apps
We did initial tests with iOS and Android phones loaded with the app Owntracks. The tests showed that the idea was promising although there were some downsides to using mobile phones. We did get fairly ok update rates; 1 update per 7-14 seconds but from the Android, we could not get reliable course and speed. We need this data to be able to do dead reckoning and deliver an update to the system once every second. The data from the iOS gave very accurate results, but we had issues with that when we wanted a high refresh rate the app needed to be open all the time. We realized that we were in the hands of Google and Apple and what restrictions they put on the OS. Although it would be handy to use a standard mobile phone there are considerable downsides not limited to the problems discussed but also battery life and configuration. A mobile phone does so much more than sending GPS-positions and they are made to be as slim as possible. If we managed to reliably and continuously send data we would drain the battery like there is no tomorrow! We also considered potential configuration problems where an end-user has a different phone than the one we tested on or that Android/Apple decides to increase the limitations further.
Securify tracker and back-end
This made us investigate the possibility of building our own GPS-tracker. The initial goal was to be able to provide a proof-of-concept ability.We found a cell module with both 3G and GPS ability on a breakout board. It was also possible to program the module with LUA which would make development easy.
We began to discuss design guidelines for the back-end. We needed to receive the GPS-data, possibly do some recalculation, and send it to the system incorrect format. Scalability and reliability were important. We also understood that the back-end would open up a world of possibilities of integrating other types of systems and data into the system. Therefore the back-end should be general enough to, without too much work, handle other types of data.
Therefore the Securify Gateway ended up with this overall architecture:
RabbitMQ [https://www.rabbitmq.com/ ] is a well-trusted and reliable message broker and work-queue. Workers represented by Python-scripts would receive a message from the queue and process the data. By using a work-queue we could easily scale deployment by starting as many python-workers as needed.
Every update to the system needs to be a complete list of all active GPS-targets and therefore we needed a way of managing a stream of timestamp data and thanks to a suggestion from Fred Juhlin @ Axis Communications (thx Fred! ) we tested a time-series database; InfluxDB [https://www.influxdata.com/].
Although we have not done extensive testings on performance when the system is loaded with a lot of data from many clients we are confident that we are able to scale well within any expected limit.
The end of the beginning
This development has taught us a lot. Mainly on work-queues, time-databases and GPS-data. To be honest, the most satisfying part has been to discover and learn more about all these excellent tools that are out there. No one would dream of developing their own database. There are already database engines for all your needs and it's the same thing with work-queues and time-series. Also, we have once again been struck by how flexible and function-packed the system is. The API is extensive and well documented.
As for now, we are happy with the result. The Securify tracker has a battery-life of +26h with a refresh rate of 1 update / 8 seconds. The Securify Gateway back-end feels robust and we are already looking into doing other types of integrations.