JoAnn Hackos, Comtech Services, Inc.
We are hearing a lot about the Internet of Things these days—it’s one of the hot topics on the Internet. Gartner defines it as “the network of physical objects that contain embedded technology to communicate and sense or interface with their internal states or the external environment.” Or, to put it in lay terms, it is a world of devices that know how they are doing—are they humming along and happy, are they about to shut themselves down, or do they need help soon to keep humming.
According to a recent Cisco blog, while the current technology already can connect us to our devices, a number of key requirements has actually stood in the way of most investments in IoT. If we are going to receive messages from our devices, we need to ensure that they don’t use much power in communicating, that they can transfer data fairly slowly, and we can connect to them even if they are in extremely remote locations. Only recently has the technology been made available to support these requirements on an industrial scale at a low cost. The new technologies are called LPWA (Low Power Wire Area) technologies. These technologies are only now being deployed around the world.
Fortunately, the IoT is not new. Apparently the first internet-connected toaster was introduced at a 1989 conference. You could turn the toaster on and set the toast level remotely. Unfortunately, you still had to drop in the bread. In 1991, someone invented a robot to pick up a slice of bread and insert it into the toaster.
Like a lot of home owners today, I have an app on my phone that lets me see what my security cameras are seeing inside and outside my home. The security systems let me activate my alarm system, adjust the heat and air conditioning settings (if I had air conditioning that is), and turn on and off lights remotely. Of course, there is always the danger of the system being hacked for malicious reasons. But, the convenience of manipulating devices remotely is too intriguing to ignore.
In a November 2015 report, Gartner predicted that we’ll see 21 billion connected devices by 2020. Some of these will be self-driving cars, if they can solve the technology problems. This year (2016) alone we should see 6.4 billion connected devices in use. Many of these devices, such as specialized equipment used in hospital operating rooms, will be able to transmit information.
In a study conducted among Gartner Research Circle members, fewer than a third of the organizations are using IoT today. However, that number will likely increase to 43 percent by the end of 2016, a 50 percent increase. Companies are interested but need to have the benefits proven before they make an investment. They also lack, in many cases, the technical expertise, staff, and leadership necessary to deploy an IoT strategy. <http://www.gartner.com/newsroom/id/3236718>
So—what do all these connected devices have to do with information developers?
In May 2016, Hannan Saltzman of Zoomin and I delivered a webinar on the IoT.
Hannan demonstrated how information developers can look forward to developing content for devices linked to the internet. His example, which I’ll review below, reminded me of earlier work that Alan Rosenthal reported on, the Octane project, when he worked at Microsoft Networks. Octane was designed to optimize the incident management process in the Windows Live Operations Center. It facilitated the troubleshooting and problem resolution process of the service personnel. <http://www.infomanagementcenter.com/publications/best-practices-newsletter/2006-best-practices-newsletter/octane-enterprise-content-management-for-it-operations/>
The original troubleshooting documentation for the Operations Center consisted of an enormous Word document stored in binders. Each service staff member had a binder. When a procedure changed, all the binders had to be manually updated, a task that took more time than it took to make the change in the content.
Their first solution was to move the content to HTML Help and produce individual troubleshooting topics. That solution worked until the Help file became so large to be unusable.
The second solution was to move the troubleshooting content to an internal website. But indexing the content that changed daily and using the search mechanisms still proved difficult. With 8000 documents on the site, finding the precise document needed by the service staff member continued to be a challenge.
The third solution involved the implementation of a content management system and the development of a new twist for the content, one that prefigured our current interest in the IoT. When a service staff member received an alarm from the system, meaning that something had gone wrong in the network, the corresponding troubleshooting procedure was displayed. The service staff member followed the procedure to clear the alarm by executing the steps in the procedure one by one. The actions were built into the steps, so that by performing the action by interacting with the displayed content, the staff member actually performed the step in the system. Not only was the alarm resolved, but the system registered the completed troubleshooting task, recorded the time required for task completion, and billed the client for the time.
The specifics of this third (and fourth) solution are not covered in Alan’s article. They represent, at least for me, the early implementation of an IoT solution.
The prototype that Hannan Saltzman demonstrated in the webinar had a similar look and feel. In the demonstration, we saw a user diagnose a problem with a robot vacuum cleaner using an internet connection from a phone or tablet. The step-by-step troubleshooting procedure, when executed, interacted with the robot to diagnose the problem and to reach a solution. To the extent that the robot could correct its own problem, the troubleshooting task was controlled entirely remotely through the procedure itself.
Of course, not all troubleshooting tasks can be handled remotely. Sometimes you actually have to change the tire by jacking up the car. However, problems can be diagnosed remotely and, if they can be controlled through software, they may be resolved as well without requiring a technician to travel to a site or perform a physical action.
The IoT promises exactly this sort of connectivity. Software controls enable service providers to monitor systems remotely and correct problems as soon as they are detected. If we can couple these service processes to troubleshooting instructions that are capable of executing actions rather than just sitting there to be read, we create an enormous operation to save time and expense.
Augmented Reality (AR) is already working effectively, coupled with step-by-step instructions overlaying a real-world object to be repaired. And, information developers are working on creating standards for the development of these instructions using XML.1
In most cases, the instructions accompanying an AR display require that someone perform a physical task. By adding systems and connectivity to the machines themselves, some tasks may be performed remotely. In these cases, our ability to write procedures that interact with the devices will make information development an integral part of the system itself.
I would like to hear from any of our readers if they have examples of developing information for the IoT. It would be exciting to learn about your successes and your challenges.
1. See the work of the OASIS Technical Committee for Augmented Reality Information Products (ARIP) at <http://www.oasis-open.org>