Fig. 3. SmartShirt by Sensatex. A flexible data bus carries signals from various sensors plugged into connectors in the shirt to a controller at the waist.
One of the more interesting examples of smart clothing is the Wearable Motherboard, funded by the Navy. It is designed to not only detect the exact location of bullet holes but monitor the vital signs of the wearer and transmit these data to field hospitals in the rear. A PDA would receive the data from the fabric-embedded sensors via Bluetooth or 802.11b and transmit them to the field hospital.
A related example is a smart baby outfit (Fig. 4) designed to prevent SIDS (Sudden Infant Death Syndrome). The outfit would alert parents as soon as the baby stopped breathing. Sensors in the outfit monitor heart and respiration rates, and body temperature. The sensors send the data to the parent’s PDA (or other device such as the PC or even a specialty watch).
Fig. 4. An e-textile shirt from Sensatex alerts parents the moment a baby stops breathing. (Credit: Sundaresan Jayaraman)
A firefighter’s suit could be made smart. There might be one master node for data collection, possibly a specialized PDA, and slave nodes for sensing temperatures over an area of fabric. These data, collected from several firefighters’ suits and transmitted to the Fire Chief, would enable the Chief to order his charges into or out of an area of a burning building depending on distributed temperature data.
One of the popular functions of Pocket PCs is MP3 audio capabilities. Look at the MP3 PDA of the future. The cyclist in Figure 5 is wearing it. The jacket is for playing MP3 files and recording memos. This concept jacket, by Infineon, has a keyboard on the sleeve, a data storage pack, an earphone, a microphone, and a central audio module.
Fig. 5. Wearable electronics from Infineon: MP3 player jacket.
Anatole Gershman, in the article “Beyond the Ultimate Device: From ‘Anytime, Anywhere’ to ‘Always and Everywhere’,” says that “as this trend toward embedded and wearable devices continues, computing will become infused into the environment. We will no longer have to look through a small screen to interact with technology. The services we use will rely on the infrastructure in our environment to sense our context. They will know where we are, and what we’re seeing and hearing; they will be all around us, working unobtrusively to sense needs and changes, and triggering actions in response” (http://www.accenture.com/xd/xd.asp?it=enweb&xd=ideas%5Coutlook%5Cpov%5Cpov_device.xml).
The end of one era and the beginning of another
It was once thought that the PDA would become ubiquitous among corporate users and the public at large. This has not happened as yet. In fact, according to the research firm IDC, worldwide shipments in 2003 should decline 8.4% to 11.35 million units from 12.4 million in 2002. According to IDC, handhelds have reached their ceiling. (http://asia.cnet.com/newstech/personaltech/0,39001147,39150523,00.htm). Various reasons are offered for disappointing sales, including power problems, small screens, security issues, lack of central administration, and convergence with other technologies such as smartphones.
But ABI, another research firm, sees a much brighter future for PDAs. ABI thinks the PDA market will grow at a rate of 8% to $10 billion by 2008
(http://www.abiresearch.com/reports/PDA.html). This growth will come from new, specialized functions for PDAs. Such technologies as GPS, telematics, barcode and RFID scanning, and even digital photography, will give PDAs new functions not easily supported by smartphones.
In the not-too-distant future, one’s “PDA” will likely be a set of services coming from various networks to a variety of devices, some even woven into clothing. The devices will be smaller, lighter, less power-hungry, and will be used for a limited period of time, then disposed of to be replaced by a newer-generation device. The components of the PDA will likely be separated and distributed over the network. The only part held by the user will be a thin client continuously connected to numerous networks. n
* * *
Jeffrey Wales is the founder and president of the Electronic Education Network, Inc. E.E.Net is a Los Angeles based software training company that specializes in custom, onsite network operating system and application classes for vertical markets. He is a certified trainer with Microsoft, Lotus, and previously Novell. Prior to starting his own company, he was on the faculties of UCLA and the University of Southern California. Jeff's current interest focuses on issues of integrating PDAs in the enterprise. You can contact Jeff at [email protected].
Hollywood and Real Police Adopt Positioning Systems
by Jeremy Straub
In the recent thriller Out of Time, Denzel Washington stars as small-town Florida police chief Matt Whitlock, who gets in over his head with a lover turned thief. There is the requisite amount of gunplay for this sort of movie but, ironically, what saves Whitlock’s life is an iPAQ. He has installed a GPS tracking system that allows him and other officers to locate each other immediately. Though we have to imagine exactly how the handheld knows where it is (a car-mounted Bluetooth GPS receiver perhaps?) and how it communicates this to the other handhelds, Out of Time demonstrates how vital GPS technology can be—and how perfect the PDA form factor is for it. I don’t want to give the ending of the movie away, but let’s just say that a car-based positioning system (as opposed to a GPS-enabled Pocket PC) wouldn’t have had the same effect.
Is that an iPAQ you’re packing, Denzel? (Credit: MGM)
Many real-life police departments use GPS, in systems ranging from installed-in-car solutions to laptop and tablet-based solutions to even some PDA deployments. These real-life systems, though, do far more than simply find a fellow officer. In their PDA incarnation, they can be used to direct car chases, run license plates, verify suspect information, and even solve crimes.
So why don’t more departments have such systems? There are a few common reasons, such as budget restrictions and incompatibility between the GPS system and existing systems. But in most cases, it is simply because the department has not yet seen the value proposition in installing one. Let’s look at some of the issues.
Components of a successful GPS system
In order for a system of this type to be effective, it needs four components: secure network access, a source of position information, a handheld unit, and software. The software makes the first three work together and allows the handhelds to talk with back-end dispatch and database systems.
1. Secure network access
The first component, secure network access, is perhaps the easiest to provide, as in most areas it can be as simple as contracting with a wireless carrier such as Sprint or AT&T to provide service. Standard protocols such as HTTPS can be used to secure the information. While this is a good entry-level solution (especially for a small department), the cost of this wireless access can add up quickly for multiple users, and intermittent network coverage could severely limit the system’s usefulness in remote areas. An alternate approach is to use a pager network such as that operated by Bell South (which provides service to RIM Blackberries, among a variety of other devices). This network can cost pennies on the dollar compared to mobile phone operators, but in many cases doesn’t come close to their speed. Some larger departments may even look at deploying their own wireless access system (such as secure Wi-Fi or a proprietary technology) or converting an existing communications system.
2. Position information
The choice of device for acquiring position information is primarily dependent on the level of accuracy that your deployment needs. Network-based positioning, if available in your area, can be very cost-effective if you are using a wireless network for communications, as no additional hardware is required. At present, though, it is not suitable for dispatching an officer to a crime scene or for following a chase, as it provides very general position information at best. For those needing more accurate positioning, a GPS device can be hooked to most handhelds (or laptops, tablets, etc.) to locate the device to within about 10 feet.
3. Handheld unit
The hand
held unit selection is in many ways dependent on the network and the positioning requirements. If you are using a wireless carrier’s network for communication, you might choose a handheld, such as the T-Mobile or Siemens Pocket PC Phone Edition or the Hitachi G1000 from Sprint, which includes everything necessary to connect. If you are using GPS instead of network-based positioning, you will want to ensure that you select a handheld that can have GPS hardware easily connected to it, whether as a sleeve or via serial, CompactFlash (CF), Secure Digital (SD), or Bluetooth. It is critical to consider this connection decision, as an inappropriate GPS device connection method could severely limit the system’s usefulness.
(above) San Diego State University police use Pocket PCs to locate an accident or wirelessly report an event back to the campus control center.
4. Software
Of course, the final piece of the puzzle is the software. There have been a number of public-safety PDA deployments. Most have used custom-written software to integrate with existing dispatch and data storage systems. With custom software, a variety of features can be easily integrated, such as a time-clock to track hours worked and time off, mapping to help officers find their way to the scene, and other applications to provide officers with information about known criminals, dangerous areas, and department procedures. A full-fledged implementation might even include an application that would allow officers to submit reports from their handhelds.
(above) Pocket Zone software used by Hamilton County (Tenn.) Sheriff’s Department to collect data at crime and accident scenes.
Some Implementations of the Pocket PC in Law Enforcement
North Wales, UK police use Pocket PCs to report crimes
www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=14058
San Diego State University police use Pocket PCs to respond to campus emergencies and make on-the-fly decisions
http://map.sdsu.edu/mobilegis/photo_campus.htm
Phoenix Police use Mapopolis to position helicopters
Sleepy Eye, Minnesota police use Mobile Enforcer to manage case load
Montgomery County Police stop racial profiling by monitoring with Pocket PCs
www.microsoft.com/resources/casestudies/CaseStudy.asp?CaseStudyID=13375
Hong Kong police accept reports from citizens via Pocket PCs
www.info.gov.hk/police/pda/index.htm
New York police use Pocket PCs to track parking tickets
www.symbol.com/news/pressreleases/nypd_gets__mobile__computers.html
Hamilton County (Tenn.) sheriff’s deputies use Pocket PCs to reconstruct accidents
www.accidentreconstruction.com/newsletter/jul03/cad.asp
Boston police use Pocket Cop
www.hp.com/hpinfo/newsroom/feature_stories/2003/crime03.html
Not just for the movies
When it’s all assembled, it may not be quite as exciting as what Denzel does to extricate himself when he’s almost “out of time.” But a properly implemented handheld deployment can be an asset to most police departments, decreasing the hours spent, and inaccuracies caused, by officers having to transfer their notes to a paper form—and it may even save lives!
* * *
Jeremy Straub is CEO of Positioning Solutions. His e-mail is [email protected].
Bringing Mobility to the Oil Field
by Paul Hamel
Many challenges confront software vendors seeking to increase Pocket PC adoption in the oil field. These may be categorized into five areas:
Data acquisition
Quality control
First-line surveillance
Communications
Cost of ownership
While developing Handheld Field Operator, our development team was met with several interesting challenges. With hard work, lots of long days, and a bit of luck, we were able to release the application within a nine-month project timeline and budget. The major challenges included:
Code portability
.NET Framework 1.0 Beta
Performance of SQL CE 2.0 on Pocket PC 2002
Application and data hosting
Internet security
Hardware inde pendence
Oil field automation is a common method of data collection for high-production oil or gas wells. However, many oil fields in the United States have been producing for 50 to 100 years, and a well may yield just 5–10 barrels of oil per day. At such levels, economics preclude the installation of expensive automated field data capture systems.
Manual field data capture typically involves a field operator driving from well site to well site and writing well temperatures, pressures, and other pertinent information on a piece of paper known as a “gauge sheet,” then faxing it to a clerk for entry into a computer. Data quality is marginal, and it can take from one day to several weeks for the information to become available to production engineers, who are responsible for maintaining production levels and ensuring well uptime. Potential problem identification is delayed, and resolution may be too late, which leads to deferred or lost production.
Recent improvements in Pocket PC technology enable the field operators to enter data directly into an electronic form and then synchronize with an engineering database through cellular or wireless systems. When real-time information captured on a Pocket PC is brought into an engineering relational database where historic field information is readily available, the surveillance engineer can further discover production performance variances and use other analytical tools to understand the issues and quickly recommend remedial action.
Today’s economic climate and competitive pressures are driving software vendors to find more efficient ways to build these new technologies and reduce ongoing maintenance costs. To fulfill these goals, our development team chose .NET as our development environment. We used .NET Visual Studio and .NET Compact Framework with a local database in SQL CE. Each element of the code was built to suit the handheld, laptop, tablet PC, and desktop environments. While the screen design for each platform had to be appropriate to the available screen real estate, the business rules, data access layers, mathematical engines, communications, validations, and panel editors were common across all platforms.
At the start of the project we faced a potential problem: .NET CF 1.1 was in its beta release. Counting on our strong technical relationship with Microsoft, we began development. The full release of .NET CF 1.1 was to come while we were transitioning our application from development to testing, four months before its release. Microsoft kept us current with code changes and release dates. Other than causing a few minor delays, the release of .NET CF 1.1 did not interfere with our concentration on the product’s core functionality.
Data acquisition
The core component of any field force automation tool is data acquisition. Without up-to-date information, the remaining elements are useless.
Smart use of limited screen real estate is of the utmost importance. It is important to provide the system administrator with a panel editor on the desktop to tailor each panel to the operator’s preferences. Options may include:
fonts and colors
landscape vs. portrait
screen layout
validation rules
activated and required fields
text and audio
Colors are an excellent way to show a user when a set of data is completely entered. By default the product provides yellow for incomplete panels and white when a panel is complete (Fig. 1). This becomes important when reviewing well history, as it provides an immediate clue to potentially missing information.
(above) Fig. 1. Well entry screen and associated panels
With Windows Mobile 2003, we are able to provide an optional landscape mode. Grid summary views are best provided in landscape mode to accommodate higher volumes of data. The ability to manipulate the screen layout allows each user to move often-used data fields to the top and lesser-used elements to the bottom of each screen. These choices are often depen
dent on the oil field’s well and equipment types and not usually customized to individual users.
We will explore calculated validations in a later section, but the rules should be set by the system administrator and managed in the Panel Editor (Fig. 3), as each data field may include a different set of validations. In addition, each field may be “visible” and/or “activated.” The Panel Editor allows the administrator to ensure that the essential data elements are entered and that users are not allowed to close the application without filling in all of the required fields.
(above) Fig. 3. The Panel Editor resides on an administrator’s desktop.
Windows Mobile provides a soft keyboard for complete text and numeric data entry. Unfortunately, it hijacks 30 percent of the screen. We designed a slim keyboard (Fig. 2) for Handheld Field Operator to accommodate numeric data entry and easy navigation, since text is required only when entering comments.
(above) Fig. 2. Providing a slim set of keys for numeric entry and navigation
Although voice-to-text conversion remains an obstacle, voice recording is an excellent Windows Mobile tool for audio comments. With the added ability to attach an image from a digital camera attachment, voice notes and images provide powerful ways to describe an event or situation to the next shift.
Pocket PC magazine, Apr/May 2004 Page 16