Abdullah and Pieter are surveyors working in the Omani desert. Glad to be leaving their survey site at the end of the day in their air-conditioned 4 x 4 they make a small driving error, and bury their vehicle up to the axles in soft sand. Realizing they won’t be able to dislodge their vehicle themselves, and knowing they are out of cell phone coverage, Abdullah presses a button on the vehicle’s dash. Immediately a sequence of three short messages is transmitted via satellite from a tracking device mounted in their vehicle’s roof that includes a GPS receiver.

Within minutes duty controllers and responsible personnel at Abdullah and Pieter’s camp, as well as at their company HQ, have been alerted via pager, SMS and email. The duty controller at their camp logs in to the company tracking website, clicks on the red alert button at the bottom of the page, and is able to view Abdullah and Pieter’s vehicle clearly marked on a map showing their position, and the details of their mayday call. Several minutes later he leans back and runs through the checklist once more. All the procedures have been followed and a rescue crew is on its way. Now all he need do is follow the rescue crew’s progress on the digital map on his monitor, as they make their way to the survey crew in distress.

James’ phone rang within minutes of having transmitted his insulin pump and glucose monitor logs to his diabetes monitoring service. As expected it was his MD, requesting him to make an appointment the next day, a little of his concern noticeable in the urgency of his request. James knew he still had not mastered the optimum usage of his insulin pump and readily agreed to an appointment the next day.

The next day James and his MD review his glucose levels matched to his insulin dosage and recorded habits logged by his insulin pump and glucose monitor. The graphic clearly shows periods dangerously approaching hyper and hypoglycemia. Cross-referencing to his dietary log he realizes that he has consistently miscalculated his carbohydrate intake and administered an incorrect bolus, the amount of extra insulin required to aid his metabolism, then over compensated. Together James and his MD review his eating habits, how to estimate his carbohydrate intake and required bolus. After half an hour James is visibly relieved and more confident about the usage of his equipment.

Just as James wants to conclude his visit, the MD tells him about a new set of devices that combine insulin pump, glucose monitor, a small computer and cellular phone transmitter in a device the size of a cigarette packet, that would monitor his glucose levels continuously and dispense the correct amount of insulin for his needs. It would also alert him if his blood sugar dropped below a risk-free level. For an additional service charge his personal data could be transmitted regularly to the diabetes monitoring service allowing his MD to monitor his health, as he is doing now daily. Even more reassuring is the ability of the device to alert his MD and family members of his condition and precise location, should he ever be in distress.

Victor, the support manager for high-end laser printers at an international high-tech firm settles in behind his PC and logs on to their support management web site. He scans quickly through the overview of problems that occurred at customer sites all over the world in the last 24 hours and that the system has collected by interrogating each of their installed printers.

Two sites, one in California, the other in South Africa, had critical problems. He checks each case and is satisfied that local support controllers were notified and responded appropriately by ordering appropriate replacement components and scheduling high-priority visits.

Then he proceeds to look through the lower priority cases. “Better but still too many”, he decides, and runs a statistical analysis by model, version and fault type. With a click of a button he turns the analysis into a graphic illustrating clearly which kinds of faults occur most frequently on which model printers.

Once he has printed his analysis, he makes his way to his team’s usual morning staff meeting. On his way down the corridor he muses just how much this new monitoring system has changed his job. Just a couple of months ago, all his team were doing was firefighting, reacting almost constantly in crisis mode.

The solution had been simple. They had always had remote diagnostic capability built in to their printers, but had always had to connect manually with primitive tools, one printer at a time. Few of his team had been knowledgeable enough to interpret the data gathered in this way. Now the new monitoring system automatically collected and interpreted the diagnostic data from each of their installed printers daily, alerting responsible personnel, logging faults and their frequency.

This had enabled his team to become proactive, and to direct ongoing development toward eliminating the causes of their most frequent problems. His “panic visits” to customer sites with priority 1 faults had drastically reduced in the last two months. It had been noticed by their customers too, and Victor smiles as he recalls the results of his company’s latest customer satisfaction survey.

All three of these scenarios, as disparate as they are, have something in common. They are all examples of Telemetry or Remote Monitoring applications. The systems whose usage they illustrate gather information from sensors via a communication channel, even over long distance, then interpret and react to that information, and provide the ability to collate and further use the information.

Here are key common elements in the above scenarios:

All three scenarios provide some sensory data, but from quite different sensors:

• The GPS receiver and panic button on Abdullah and Pieter’s 4 x 4 provide geographic position and the notification that they are in distress
• Glucose levels are provided by James’ glucose monitor, insulin dispensed and log of dietary intake by his insulin pump, or if he chooses the artificial pancreas described by his MD, it will provide all the necessary data
• A whole array of sensor data, such as toner level, and control information that ranges from fault-codes to usage, is available from the embedded processors in the high-end laser printers

All three scenarios rely on the sensory data being communicated:

• Via satellite for Abdullah and Pieter
• Via James’ normal internet connection, or with the new artificial pancreas, via its built in cell phone
• Via the internet and normal local area networks that already connect high-end laser printers to the computers which provide their print data

All three scenarios interpret the sensory data received in the context of some monitored and valued asset:

• In Abdullah and Pieter’s case it is their 4x4 vehicle, and those of the rescue crews that are monitored
• In James’ case, it is James himself, or at least those characteristics important to James’ diabetes and health, that are monitored
• The high-end laser printers installed at Victor’s customers are the monitored assets

In all cases, the software system that has collected and interpreted the sensor data then reacts according to predefined rules:

• Abdullah and Pieter’s distress signal is responded to by notifying relevant “on duty personnel” according to the emergency escalation procedures established by their company
• James’ MD is alerted to the problems he is having maintaining his blood sugar levels
• And in Victor’s organization fault situations are identified and reported to local support personnel, and 2nd level support when necessary, to schedule maintenance visits and provide details of problem diagnostics for on-site personnel to be properly equipped to repair the fault

In all scenarios, the system provides the capability to resolve the problem situation and to allow further use of the collected information:

• In Abdullah and Pieter’s case the duty controller would be informed of the panic button being reset once the rescue crew arrived, and of their movement once their vehicle had been freed
• James’ MD is able to use the collected data to identify James’ mistake and to educate him in the proper usage of his insulin pump and glucose monitor
• Victor’s team has the information to deal with customer problems more effectively and to identify the causes of common problems in the field, and are now able to direct the development teams on where to make improvements

The technologies that enable all three scenarios and many more like it are:

• Sensors and monitoring devices
• Communication networks and the internet
• Software systems

One would normally expect to see a wide diversity of sensors and monitoring devices, as well as different communication networks for widely different uses, and abilities as illustrated in the examples.

The challenge for the software component is in coping with this diversity of sensory data, communication networks, assets and their monitored characteristics, possible reaction and resolutions. The software component has other requirements imposed on it too, such as its own reliability and robustness. What use would a monitoring system be if you couldn’t rely on it?

If one could provide a software platform inherently capable of coping easily with the diversity of sensory data, monitoring devices, networks, assets, and reactions to events, that is also reliable and robust enough to trust the monitoring of valuable assets to, then one would have a blueprint for any number of commercially viable applications.

Just as a word processor is capable of easing the task of creating any kind of document, be it a simple letter, or a complex cross-referenced technical manual, so an asset monitoring framework can monitor any kind of asset and provide the tools to manage its effective use and operation..

ROAM is just such an asset monitoring framework. It provides the ability to simply and easily cope with the diversities of monitoring equipment, communications, and applications required, as well as providing the pre-requisite “always on” reliability and robustness. ROAM’s capabilities have been proven in half a dozen applications, using a variety of networks, and monitoring devices, over a period of 3 years.

ROAM is provided by Omnitec International based in Dubai Internet City, through partners, distributors and VAR’s world-wide. Omnitec International works closely with network providers, telemetry and monitoring equipment manufacturers, and service providers, to continuously develop and offer new, exciting, and commercially viable solutions based on their ROAM platform and applications suite.