Lower Cost, Better Results with Wearable Computers in the Enterprise
To get the most out of wearable computers in the enterprise, enable the mobile worker with applications based on the Service Oriented Architecture, and back up those applications with device features and an application framework.
LARRY RICCI, EUROTECH
Page 1 of 1
Wearable computers are becoming part of the fabric of enterprise application deployment. Today, a large portion of the information workforce is “deskless” yet still needs data interchange with the enterprise. Such information workers include police, fire, utility linemen, soldiers, medical personnel and construction supervisors. Separating out the workday into information capture (typically pen and ink to paper) and information data entry (key stroking it into a PC at the office), is monstrously inefficient and prone to error.
As we deploy more and more applications to the deskless worker, we are beginning to see how very different wearable computers are from portable computers like laptops, and we are learning the techniques to deploy these wearables into a robust, Service Oriented Architecture.
Start with the Device
Mobile and wearable devices are very different from laptops. Even a subnotebook or netbook should be best considered a small desktop PC. Obviously, a wearable device is very different (Figure 1). Even if running similar or the same OS as a laptop, a wearable device requires different assumptions at the start. The primary input is no longer a keyboard or mouse. The primary input may be a touch screen, but voice, on-screen keyboards, functions buttons and keypads are also used. It is often sensor-based with GPS, ambient light and inertial sensors as well as biometric and process sensors.
In the role of host or client, the wearable computer is often a “host” in the field, but a “client” back in the office. It may even be part of a “mesh” network such as Wi-Fi or Zigbee. It is often location- and situation-aware using GPS and the ability to sense movement, lighting levels and arm position. It must often be designed for use in hostile locations like a construction site, mine or the battlefield. It is usually purchased for enterprise use, almost always with some enterprise application on a server, and usually as part of a fleet of devices. It is purchased to do a job and is loaded with just that software. Often its power must last from four to twelve hours.
For a wearable, battery life is everything. Unlike a laptop that might be used for a few minutes on the go, a wearable is on full time, for a shift, even for a day or more. The situational awareness of the device needs to be exploited to extend battery life. Clearly there is no reason to run a LCD backlight unless someone is looking at it, and it should not be brighter than the ambient conditions warrant. Not only the backlight, but Wi-Fi and WWAN networks are significant power consumers and can be enabled based on the situation—for example when the device location is known based on GPS readings.
All versions of a useful wearable computer should make the most of power management to extend battery life. Some of these devices are configured with inertial sensors that will put the device into sleep mode when the arm is down, and will wake it up when it is raised to reading position. A civilian version of a wearable should be good for a full shift; a mission-specific version might have special batteries for even longer use.
Personalization is not just about hardware and hygiene. The device software must be personalized at the start of use by the application environment. There are many personal aspects to a wearable application. These include allowed access to on-premises systems as well as to cellular networks, which may follow the person, not the device. Wearables can be personalized for left or right handedness, language and speech recognition libraries in addition to more familiar things like phone and email directories, contact lists, calendars and the like. This and other information would typically be provided from “the cloud.”
Security is a related issue. A wearable can be lost or stolen, and with it confidential data. Biometrics can be built in to enforce only authorized access. Also, it should be possible to remotely wipe the memory of any device that has gone unaccounted for.
The final and perhaps ultimately most important aspect of wearable device personalization is its ability to identify the wearer within society. Any tool we bring to our person, like a watch, a clipboard or hard hat, serves to identify the user as a certain type of individual, a member of certain group. In the future, this will be even truer for a wearable computer, and the applications architect needs to be aware of this.
Moving Up the Stack – from Hardware to OS
There was a time when mobile and wearable devices were based on hard-coded, proprietary operating systems, but those days are gone. Now devices based on the Microsoft or Linux platform are the norm. But don’t expect full compatibility with existing enterprise applications. On the Microsoft front, XP, Vista, Embedded XP, Windows Embedded Standard, Windows Mobile and Windows CE all present a different API, and some adaptations and recompiling of existing applications should be expected. Similarly, as is central to the open source business model, virtually all Linux platforms are different.
Since enterprise scale applications need lifetimes of a decade or more, the best approach to reduce maintenance may be to code applications in a high-level language like Java or C#. This abstracts the business logic from the hardware. Updates to hardware, device drivers and OS are handled by the JVM (Java) or JIT interpreter (Windows/C#). Of course, if the user of the device plans to migrate his applications, he needs to be sure that his device supplier offers the Java or C# interface to all the I/O on the device that he needs.
Various application frameworks are available, from Microsoft and from third parties. For practical applications the question is simple—“What I/O is visible from the application logic?” A big part of the Eurotech value-add is that we can include, and maintain, the branded EveryWare Software Framework (ESF) inside any of our products, with all I/O and network features visible to the application environment.
Again, OS fragmentations driven by device variation have, in the past, required developers to work with hard-edge tools like compliers, text editors and specialized debuggers. For comprehensive enterprise applications, the trend is to mandate powerful development tools, from the mobile/wearable device up to the cloud. More and more, these tools tend to be Eclipse for the Java/Linux users and Visual Studio of the Microsoft camp. Both are excellent platforms, with plug-in tools and rich third-party support to manage development and maintenance of any scale of enterprise application.
The Eclipse foundation offers the Service Oriented Device Architecture (SODA), which defines the key set of architectural constraints for SOA architectures (Figure 2). The Microsoft approach with .NET and the Windows Communication Framework (WCF) is similar and embraces many emerging industry specifications like universal plug and play and wireless plug and play. Most commodity devices today, for example printers, GPS units and so forth, are incorporating into their firmware elements of the industry specifications embraced by .NET.
Reaching for the Clouds
Wearable computers are the natural partner for cloud computing. As the server room vanishes to the cloud, the desktop can become an appliance, a wearable tool. This is the perfect environment for a Service Oriented Architecture. While this may superficially look like an embedded client/remote server architecture, the fundamentals are different. It is the difference between Embedded and Pervasive computing.
A smart embedded computer system is any microprocessor-based device encapsulating basic process knowledge. The consequence of this is IT integration is at best an effort in hindsight and at worst ignored altogether.
On the other hand, pervasive computing provides technology and infrastructure enabling the distribution within the enterprise of process knowledge and associated parameters. As a consequence, IT integration becomes a native capability of the system.
Have a Drink of SODA
SODA for Devices is a breakthrough. In the client/server model, devices are slaves displaying and querying data that only a single hosting program controls. Thin client interaction is even more limited: Displays and controls developed for a desktop system are presented, awkwardly, to a mobile worker with a wearable device and no keyboard.
However, in the SODA model each device can not only consume data, but it can also source data. For example, consider the evolution of personal GPS systems. Before the turn of the century, GPS devices were not too smart. They had 8- or 16-bit processors and were hard-coded to give basic latitude and longitude information. Currently, all GPS personal navigators are smart 32-bit systems and can provide graphics and turn-by-turn directions. Development time for these was a fraction of the time required for the hard-coded 16-bit predecessors. Increasingly, more of these personal navigation devices are networked, to get traffic and weather reports, for example. Networks are wide area cellular or FM data sideband, or they may be local Bluetooth for cell phones and car infotainment.
Recently, service-oriented devices are appearing for GPS applications. One GPS now provides, as well as consumes, traffic data. It publishes its current location and speed to all users of the same GPS so best routes can be plotted. This demonstrates how perfectly a pervasive computing device can distribute process knowledge (for example traffic reports), within an enterprise as loosely defined as the owners of a specific brand of navigation device.
To make SODA work, every connection on the network needs to be able to publish and subscribe to events throughout the system. Framework software will provide mechanisms for this via an object broker or enterprise bus. Using a mechanism like this, any device or application anywhere in the network can be messaged with a change that it is interested in. Since the industry is migrating to XML, SOAP, DPWS and other industry standards, networks can be transparent across platform and vendor, subject to security provisions.
In an ideal world, users of any smart navigation device would be able to publish their traffic data as a service in exchange for getting other people’s traffic data to consume as a client or, more likely, to get better routing information published by a powerful computer on the Net and consumed by the personal networked device as a service. This service might or might not be offered by the device supplier.
The Wearable Is the Ultimate Service Provider
Because a wearable computer is in full-time physical contact with the user, and in personal area network (PAN) range of the user’s other tools and devices, it can publish extraordinary levels of data as a service.
For example, one OEM offers a wearable biomedical sensor shrunk to a patch. Connected by Bluetooth to a wearable computer, the patch can report the state of health of the wearer to anyone on the Net. The patch might be on a patient and a wearable computer by Eurotech, called the Zypad, might be on a nurse, or might be on the EMT working in an ambulance. Or, alternately, such a patch might be on the same soldier or fireman who is wearing the Zypad.
Collecting and publishing the vital signs without intervention and with no data collection/transcription errors could be important to many parties, including the attending physician, the health insurance company or the trauma center where the ambulance is headed. Collecting and publishing vital sign data of a soldier in combat or a fireman in a burning building could direct life or death actions of their brigade or platoon.
The wearable often becomes a hub for other devices in the PAN space. Typically these devices are basic tools. Devices with their own power, like a belt-worn printer, tend to use Bluetooth for the PAN. Devices that need power, like an RFID reader or the Eurotech barcode Ring scanner, tend to use a USB connect for both data and power (Figure 3).
The networks for these connections can be power-aware, fault-tolerant and ubiquitous. Wi-Fi, 3G, Bluetooth and Zigbee all have different profiles of energy use and should be selectively used by the application according to availability and task. In some situations, such as the deployed military platoon, an access point on a vehicle might be eliminated by hostile action, and the units might have to reconfigure to a mesh network. Ideally, all of this logic should be supported by the application framework, between the business logic of the application and the hardware/OS level.
Service Oriented Device Architecture is coming for wearable and most other forms of embedded computing. Hard-coded 16-bit solutions are just too costly to implement and maintain. The detailed plumbing of the user interface and sensor data is all local to the device, and does not need to be known by remote information providers and information consumers. With modern, 32-bit software frameworks, wearable computers can achieve this open-ended application extendibility at low development and low maintenance cost, and do it in perfect synchronization to the emergence of cloud-based application architectures.