Defining Requirements for RTLS – Part 1
December 16, 2009 Leave a comment
So you’re planning to deploy RTLS? But there’s so many vendors out there providing different solutions – each claiming to be superior in every way. Here are a few things you want to look at before making the decision. We’ll cover three important factors first, and several more in the next post.
As always, you may want to note that as I do work for Ekahau, the entries in this blog may be slightly biased. I did try to make this as non-biased as possible, but consider yourselves warned…
1. Problems, Users and Use Cases
The RTLS solution is hopefully set up because you have problems or unanswered questions that you want to address. Examples:
- How can we find my 1000 healthcare assets when they’re due for maintenance
- How can we get help for staff members in trouble quickly
- How occupied are the operating rooms, and what are the bottlenecks causing low throughput
- How can our customers find their children
- What is typical customer behaviour in this store
These questions should drive the whole RTLS project. After figuring out the main problems, we can start drilling down to these issues: Who “owns” these problems, and how could they be solved?
Communicating with all the parties involved is essential: Only with good communication can you start figuring out how exactly these could be solved effectively. This is typically the point where people stumble upon enterprise RTLS.
After figuring out the basics of RTLS (oversimplified, it’s a way to locate people and assets in real-time using small-size, battery powered tags), the brainstorming starts to shifting to use cases: What exactly is the process with which we can solve the primary issues? What kind of system is required, and who would operate the system? What is the input, what is the output?
I will say this now and I will say this later: Keep things simple! Try to only solve the primary issues first. Keep the scope, timelines and ROI in mind!
2. Accuracy
After the high-level problem definition, it’s time to start looking at the actual requirements. Accuracy is critical: If the system shows your assets are on the floor they’re not, it’s useless (please do test on 3-5 floors when evaluating systems). If you’re trying to optimize your operating room usage and the system does not provide true room accuracy (think at least 95 times out of 100 correct), it’s useless.
Accuracy is often down-played: intentionally by some RTLS vendors (because their accuracy is worse than someone else’s), and unintentionally by buyers (they’ll find out the importance of accuracy when it’s already too late).
However, the more accurate the system, the more costly it will be (in many cases). Here’s some guidelines:
- As a general rule, with the right RTLS, your Wi-Fi network that supports VoIP is typically good enough for asset tracking – no extra infrastructure needed. But there’s differences between Wi-Fi location algorithms, so evaluate throughly and ask for references so you don’t end up paying for a system that shows your assets on incorrect floors or the building next door. Don’t trust Wi-Fi only systems that are not based on some kind of floor-level calibration.
- For true room-level accuracy (locates the person/asset to the correct room 95%+), extra infrastructure will be needed. Various readers/transmitters are available varying from $50 to $1000+ each. Cost does not always go hand-in-hand with performance, so again, evaluate. And be careful with the hidden costs: Some systems require cabling, which is expensive and intereferes with the daily operations of the facility. In addition, some “accuracy enhancing devices” (125KHz active and 868kHz passive RFID) have been found dangerous for healthcare use (http://jama.ama-assn.org/cgi/content/short/299/24/2884). Wi-Fi and various other technologies have not been found dangerous.
- For sub-room accuracy there’s different types of solutions: Technologies like ultra-wide band (UWB) can provide very good accuracy, but costs tons of money to deploy to the whole . Those are a good choice when money is no object and inch-level granularity is required everywhere in the room. A more cost-effective solution for bed or bay-level sub-room accuracy is a “beacon” approach, where, for example, a low-power infrared transmitter is placed in each location where high granularity is needed.
Some systems support hybrid capabilities, where you can use multiple technologies at the same time. For example, you have Wi-Fi providing 1-3 meter accuracy in the entire hospital, and put a few additional beacons in the operating rooms to provide true room accuracy or even bed level accuracy there.
The Point: Test the accuracy before buying a fully blown system. Test on multiple floors, on as large of an area as possible. If room or sub-room accuracy is required, extensively test that. Just remember to keep the costs in control.
3. Feature set
There are a few critical components in RTLS solutions where the feature sets is critical:
- Tag: You may need a tag that has a buzzer, button, tamper switch, display, motion sensor, intrinsic safety, etc. If your use case requires some of those, be careful to choose the tag and vendor accordingly. Keep in mind that if the tag hardware doesn’t support a feature, it’s simply not there and typically won’t be for a long time. Hardware is not easy to change quickly. And be cautious on the timelines the vendors promise for new tag models. However, with certain systems, some features can be updated with a software patch over-the-air directly to the tag. Obviously, software updates will not make your tags smaller, but they may enable some other advanced functionality to support your use case.
- The Application Layer: This is a bit easier than the previous: Software can be customized more quickly, although even still the vendors typically have long product backlogs. However, small changes are typically doable, and there’s always an alternative to create your own end user app or use an app from a third party. Virtually all RTLS systems have some kind of APIs to extract the location information out of. However, the ease of integration and policies for using the APIs may vary, as may the pricing: With some RTLS solutions, you will be forced to buy their end user application even to use the API, even if you didn’t use their end user application at all!
- Location Engine / Positioning Server: I don’t see a huge feature difference here per se, the difference is more in the accuracy of the location algorithms in the server. Of course, the better tools the IT has to monitor and manage the system, the better. So the IT folks probably want to take a look at the server GUI and features. Longer feature list in the server and tons of buttons and switches does not necessarily mean a better system, but a more complicated deployment and management. Ask for watchdogs via SNMP or similar and easy-to-understand status / troubleshooting screens.
I hope this was helpful. More about requirements in the next post. Happy holidays!
Cheers,
Jussi
