Joseph Reynolds, Tracor Aerospace, Austin TX, USA
We have for the past few years been involved investigating and defining systems for mobile CSCW with funding from both DARPA and internal sources.
We are concerned with mobile teams, in vehicles and on foot, and with their supporting central resources. Our emphasis has been on ensuring consistent situation awareness among the teams, on enabling coordinated planning, and on support for executing the plans. To a lesser degree we have worked on modeling and planning tools specific to particular disciplines and objectives.
Our teams of interest have coordinated objectives, and common overall goals. But, due to separation have different native viewpoints, with little or nothing in common through direct observation. They may be forest fire teams on opposite sides of a mountain ridge, urban fire teams on different city blocks, or hurricane disaster response teams. The teams have shared central resources and mutually accessible modeling programs and databases. They have a shared general situation awareness ( for instance through training ) but need specific, current, real time awareness of landmarks (natural or cultural), routes, waypoints, obstacles, and conditions. We have approached our problem by deriving requirements from operational scenarios and by consulting domain experts.
We have found two cognitive modes for the teams; a "Hands-On" mode when the team members (or leader) actively utilize the computing/communication tools to plan and coordinate; and a "Hands-Off" mode when they are much too distracted, and their hands are busy with other tools, to use computing devices, to plan or coordinate. We have developed approaches for both conditions. We have observed "dis-enablers," deficiencies which if present negate the usefulness of the automated system. An example of such a deficiency would be a break in continuity of input & response which might be experienced if a user were forced by circumstance to be in "Hands-Off" mode when other teams systems need "Hands-ON" buy the user. For instance, if teams were coordinating a particular fire fight, one team cooling an area while another moves special equipment (interdependent efforts) but the cooling team becomes so busy that they can't respond to status / coordinating requests from the equipment team. Then the real value of the automation is reduced to that of voice radio traffic. If the system automates the task to some degree, responding that the cooling team is moved to its assigned place, that water is flowing, etc. then the equipment team can proceed with the plan. In another example, if an evacuation is being negotiated, the rendezvous place and time have been decided, but the details of confirmation, or the selection of the agency, are pending; the system must automate the closure of the evacuation in the event the team is forced to move to safety during that time and can't interact with the handheld. Finally, we have observed that training in an operational doctrine is necessary for effective use of tools in the context of the overall task. The teams must know what to expect from each other.
We have examined a frequently encountered task of route selection and planning. In this task the teams must select acceptable routes to a common goal. The routes are subject to a variety of constraints. Speed of travel may be the selection criteria, or safety of travel, or hazard avoidance, or covert movement. The teams may be able to adequately generate and select alternatives, needing support only to coordinate and agree on the selection. Or, they may need new data, say real time update on hazards, to make a selection. They may need modeling support to evaluate their choice.
Along the routes, events or activities may be tied to waypoints. Alternate selections may be chosen depending on conditions at the waypoints; resources or supplies may be at waypoints. Observed conditions at a waypoint may be reported and shared. One important aspect of waypoints is that they act as markers to time progress for the teams to coordinate arrival at a rendezvous.
We have addressed the system requirements to support the CSCW aspects of route planning and coordination. The teams may or not be in "Hands-On" or "Hands-Off" mode during travel or at waypoints, yet the need to coordinate or act in accordance with the agreed plan or support the other team(s) is still in force. As discussed earlier, the system must support these inter team needs whatever the human mode. In some instances the handheld will interrupt the human and cause them to enter "Hands-On" mode to accomplish the necessary actions. In others the unit will accomplish the action autonomously.
We have addressed the problem of consistent situation awareness through the sharing of common maps, diagrams, plans, lists, and images; and through controlled and coordinated interaction with the maps among the teams. For the focused tasks under study, this has proved more efficient than voice communication. Support from central resources is an important adjunct to situation awareness; support through updated sensing or intelligence of say an infrared image of a fires progress or reports on arson paraphernalia found at the scene. Shared team observations are important as well. Depending on team geographic density (as low as one team per 20 km2), central support may be necessary since the teams may be tremendously undersampling the area with their observations.
From the cognitive modes and from the human activities that are likely in the scenarios, we have identified several requirements.
For the tasks and scenarios studied thus far we have a common core of characteristics for a useful handheld; it's display and controls, communication, processing and storage, geolocation and orientation, and user authentication interface. These could be split into a hand unit and a wearable computer, but we have identified no case where the handheld can not adequately serve alone. The overriding constraint in the design is low power (battery life matched to the mission duration), followed by weight/volume, and with items such as HCI being dependent on the task. A typical unit would have large display suited to maps/charts/diagrams, simple controls (no qwerty keyboard!), communications, geolocation, and sensor with audio/video.
While our efforts have determined that teams with only organic resources (their handheld units, communication, and initial dataload) can function in scenarios of interest; performance is far better if shared central facilities and auxiliary sensors are included. Central shared facilities inject needed data resources not available to the teams. The central site can have skilled operators continually in analysis and planing tasks while the teams can only be in those cognitive modes occasionally. The central site can collect and analyze sensor and intelligence. The central site can generate predictive material with models that are inconvenient or infeasible in a handheld. Auxiliary sensors can be placed by a team to monitor a condition for distribution to teams, or to be a sentinel &endash; warning for instance of a fire moving from an area without team coverage.
The essential characteristics of the central site are the existence of staff, rich communications to sources outside the immediate area of operation, and processing and storage capability not dependent on battery power. A vehicle can adequately house a "central site" facility in the field if staff requirements are limited enough, but usually communications are available to have permanent facilities with resident staff that are not located in the field.
AARD is a special business unit of Tracor Aerospace (now Marconi Aerospace NA), located in Austin, Texas, with a staff of approximately 50 involved in contract research and development, and a 35-year history of technology development. Contact Joseph Reynolds, Principal Scientist, 6500 Tracor Ln. Austin, Texas 78725 (512)926-2800 or joer@galileo.tracor.com