Home | People | Projects | Publications | Resources
TRIPS Home | TRIPS Architecture | TRIPS Movies | TRIPS Domains | TRAINS vs. TRIPS
Introduction
One of the less appreciated obstacles to scaling multi-agent systems is understanding how people will play roles in those systems, and the nature of their interactions with them. We expect that many multi-agent systems will evolve out of existing software tools, suitably "agentized" so that they have greater access to other software agent resources, and to other classes of users. To develop these kinds of agent-based applications, playing supportive roles in larger multi-agent systems, we must develop strategies for coordinating not only the problem solving behavior of these agent communities, but also their information sharing and interactive behavior with users. Our research is on mixed-initiative (user/agent) control of intelligent systems (Burstein and McDermott, 1996; Burstein, Mulvehill and Deutsch, 1998; Ferguson, Allen and Miller, 1996), and, in particular, of interactive planning systems comprised of a heterogeneous collection of software agents. Over the past year, we have been experimenting in the space of mixed-initiative, multi-agent planning systems. We have developed a prototype mixed-initiative planning tool for airlift scheduling by integrating elements of TRIPS, The Rochester Interactive Planning System, an agent-based, interactive, mixed-initiative planning system using spoken natural language dialogue (Ferguson and Allen, 1997), with the CAMPS Mission Planner, an interactive airlift scheduling tool developed for the Air Force (Emerson and Burstein, 1999), together with some related resource management agents representing other parts of the airlift planning organization. This effort had a number of goals. First, we wished to demonstrate the relative ease with which the TRIPS agent architecture could be adapted to a new planning domain, and to interaction with a new back-end planner. Second, we sought to understand what would be required for an effective agent ACL interface to a scheduling or planning tool that had its own GUI and was not developed for multi-modal mixed-initiative interaction. Third, we wished to develop a model for the problem solving agent that could mediate between the user and a set of "back room" planning agents. The last of these goals is an ongoing activity.
Component systems
Our work involves the integration of three existing systems, each of which is described briefly in this section. TRIPS, The Rochester Interactive Planner System (Ferguson and Allen, 1998) is a multi-agent system that includes agents for speech recognition, natural language understanding, reference resolution, discourse management agents, speech generation, planning and plan recognition, among others. It is the latest in a series of mixed-initiative systems produced by an extended multi-year research program at the University of Rochester that began with the TRAINS system (Allen et al., 1995; Ferguson et al., 1996). The TRIPS agents collectively provide a multi-modal interface by which users can discuss and develop plans through mixed-initiative interactions with what appears to them to be a single "intelligent" agent. The agents interact to produce this behavior by exchanging messages using the KQML (Finin et al., 1993) agent communication language, operating in a hub-based architecture provided by the TRIPS Input Manager (TIM). TRIPS supports a wide range of speech acts, ranging from direct requests (e.g., "show me the map"), questions ("Where are the transports?"), suggestions ("Let's use a helicopter instead."), acceptances, rejections, and a range of social acts. The Conversational Agent is domain independent. It is driven by a set of rules that identify possible interpretations intended by a user, and plans an appropriate kind of system response for each. Each interpretation/response is ranked and a single response is selected. The Problem Solving agent (PS) is responsible for maintaining the problem solving context, interacting with the Conversational Agent to decide which interpretations of user actions are plausible, and plan for the execution of the selected action by communicating with the appropriate back end agent(s). The specialized back-end agents in TRIPS-98 and earlier incarnations included an incremental (repair-oriented) temporal planner, a route finder, a scheduler, a simulator that represented the changing world state, and a temporal knowledge base agent. These various agents were invoked by the problem solving manager in response to user inputs. The CAMPS Mission Planner (Emerson and Burstein, 1999) is one of several prototype scheduling tools developed jointly by BBN Technologies, Kestrel Institute and CMU for the US Air Force. It is currently undergoing refinement and integration in preparation for deployment in about a year's time. As part of the DARPA Control of Agent-Based Systems Program, BBN has "agent-ized" the Mission Planner (MP) for experimental use in mixed-initiative multi-agent systems. The MP takes as inputs a set of "requirements", each consisting of quantities of cargo and people to be moved from one airport to another during some time interval. It produces detailed schedules specifying the times at which an aircraft of some type will fly from where they are based to pick up this cargo and carry it to its destination, and then return to home base. Requirement sets can be quite large, numbering hundreds or even thousands of elements, and hundreds of tons of cargo, from tens of locations. Numerous constraints must be satisfied simultaneously to produce valid schedules, which the scheduler can do in seconds or minutes. A simplistic view of the task faced by a user of the Mission Planner is, given a set of requirements, is to specify a set of suitable aircraft resources, the ports to be made available for refueling (or locations for aerial refueling), should that be necessary, and to ensure that the schedule produced moves all of the requirements by their due dates. The scheduler will fail to schedule flights for all of the cargo requirements if there are constraint violations, or insufficient resources provided, in which case some cargo may be scheduled to arrive late or not at all. As originally developed, the CAMPS Mission Planner had a traditional graphical user interface for specifying input parameters, and a variety of views of the product schedules produced, including maps, tables and GANTT charts. All user interactions were by keyboard and mouse. A second scheduling tool, called the Barrel Allocator (Smith and Becker, forthcoming) was developed jointly by CMU and BBN for another community of users (called Barrelmasters for historical reasons) within the same Air Force planning organization. It is used to manage all of the cargo aircraft available from different bases around the country. This tool takes as input the schedules produced by planners once those plans have been committed to, and finds an allocation of aircraft to missions that makes the most productive use of the limited available resources. As more airlift missions are planned by different planners than there are aircraft to fly them all, and because they are often planning far in advance, planners often plan against notional resources, rather than checking for where aircraft will be available. This tool is used to commit particular bases to particular missions, by priority, proximity, and availability, and if necessary reschedule flights to use aircraft from different bases then originally planned. To represent the interaction between the planners and the allocators, a simplified version of the Barrel system was developed into an agent for use in the prototype system.
Integration experiment
In developing this demonstration system, our approach was to provide a straightforward API to the MP and BARREL agents the KQML agent communications language, and to collect and catalog the reasoning and information interchange issues of the various agents forming the complete system. This included problems arising in interpretation and reformulation of user intent, and the planning of requests to the various back-end, airlift-domain-specific agents. The shows some of the graphical views as seen from a user's perspective. All of the dialogue was verbal, and the conversation was managed by the TRIPS agents. The graphic displays were generated by the MP agent, using pre-existing views, with one exception. While a user could have accomplished much the same result by interaction with the CAMPS-MP GUIs, many steps would have required tedious entry of information through dialog windows.
![]() User view for TRIPS/CAMPS
Using spoken language dialogue, users can quickly arrive at a solution to typical scheduling problems, in many ways more easily and more naturally than through the GUI. They can select problems to work on, request advice on the resources required to solve the problem, suggest particular assets to use, request views of the state of problem definition and of the solutions produced, and receive explanations when things don't go as expected. TRIPS manages the interaction with CAMPS-MP and the BARREL agent, and automatically invokes the scheduler when it is appropriate. This first-cut integration of TRIPS and CAMPS agents was developed in a relatively short period of time (approximately three months) in part because of the modular, agent-oriented construction of TRIPS itself. Aside from small efforts for extending the vocabulary and language understanding modules, the main effort was in "agent-ifying" the aiflift domain agents, CAMPS-MP and BARREL, and in developing a specialized problem-solver manager agent that could do the required interpretation and translation of user actions and airlift agent responses, in the context of the airlift mission planneršs task. The ongoing scientific focus of our effort is now on understanding the capabilities needed in a problem-solver that can manage this kind of interaction. In particular, we are now developing a model of the overall problem solving task, that can be used by a more general purpose problem solving agent to interpret user requests in terms of a more declaratively described domain model and relate these to models of the back-end agents. This document was taken from Mark Burstein, George Ferguson and James F. Allen, "Integrating Agent-Based Mixed-Initiative Control with an Existing Multi-Agent Planning System", TR729, Computer Science Dept., U. Rochester, May 2000. [PS] |