 |
Simulation testbeds are important for developing complex systems, such as autonomous oceanographic sampling networks (AOSNs), as they allow the development and testing of control mechanisms without incurring the cost or risk of using real vehicles. Over the past several years, two simulators for AOSNs, CoDA and CADCON, have been developed. The CoDA simulator is a multi-fidelity simulation testbed for the intelligent AOSN control mechanisms being developed at the University of Maine. While it can simulate AOSNs at a range of fidelities, it lacks truly high-fidelity simulation of the environment and of vehicle dynamics. CADCON is a high-fidelity multi-AUV simulation testbed developed at the Autonomous Undersea Systems Institute. This paper reports on work done to combine the two simulators into the CoDA/CADCON simulator, which is capable of a range of AOSN simulations, from faster-than-real-time simulations of aggregate AOSN control mechanism properties to high-fidelity, real-time simulations of an AOSN as it carries out missions.
Work on developing complex systems is facilitated by the availability of simulators. This is especially true if the system is expensive or contains many expensive or difficult to obtain components. Such is the case for autonomous oceanographic sampling networks (AOSNs) [4], which are composed of many autonomous underwater vehicles (AUVs) and other instrument platforms.
There are several existing simulators for AOSNs (e.g., [10,16,3]). These typically either simulate the high-level behavior of an AOSN (e.g., SAMON [10]) or the low-level behavior of the vehicles within the AOSN (e.g., CADCON [3]).
The CoDA (Cooperative Distributed AOSN controller) project [17] takes a different approach. The CoDA simulator, described in more detail elsewhere [16], is meant to allow AOSNs to be simulated at several different levels: it is a multi-fidelity simulator. For example, once the designers have completed an overall design for an AOSN control mechanism, they can use CoDA to quickly implement a high-level model and run simulation experiments. As experience with the design accrues, the model can be made incrementally more detailed, so that higher-fidelity simulations can be run. Different pieces of the model can be simultaneously at different levels of detail. For example, the high-level behavior of a group of AOSN agents (i.e., the vehicles and other instrument platforms) can be simulated by rules that model the overall effects of cooperation protocols, while other parts of the model (e.g., task assignment) can be modeled at a higher fidelity, perhaps even with the code that would be fielded in an actual AOSN. Multi-fidelity simulation promotes rapid prototyping and faster-than-real-time simulation (e.g., by discrete-event simulation) of overall system properties by selectively avoiding high-fidelity, continuous time-dependent pieces of the simulator, yet it also allows more detailed simulations to be done later for accuracy.
|
Until the current phase of the CoDA project, while the simulator has been able to simulate AOSNs at a range of fidelity levels, it has not been able to support truly high-fidelity simulations of vehicle dynamics and sensors. This paper reports on the current phase, in which work that has been done add this capability to CoDA by interfacing it with the Autonomous Undersea Systems Institute's (AUSI's) CADCON high-fidelity simulator. The combined simulator, called CoDA/CADCON, is now able to perform at fidelity levels ranging from high-level, low-fidelity simulation of only the AOSN's aggregate properties to high-fidelity simulations which include agents' reasoning processes as well as vehicle dynamics.
In the remainder of this paper, we first discuss the two major pieces comprising CoDA/CADCON, CoDA and CADCON. We then describe the CoDA/CADCON simulator, and discuss some of the problems we faced in interfacing the two and our solutions. We then give an example of a CoDA/CADCON simulation.
The CoDA project has as its goal developing an open, distributed, intelligent control mechanism for AOSNs. We assume that for many AOSN missions of interest, it may be impossible to pre-specify an organization for the system. For example, it may be impossible to predict ahead of time which agents will take part in the AOSN (e.g., due to attrition during transit through a hostile or dangerous area). We further assume that many missions will require the absence of contact with the AOSN, either due to mission characteristics (e.g., covert missions) or the environment (e.g., when operating under ice). Consequently, the AOSN must be able to organize itself autonomously, carry out its mission, and reorganize as needed.
Our approach treats the AOSN as a multiagent system that uses cooperative distributed problem solving (CDPS) (e.g., [5]) to organize and reorganize. No single agent is assumed to have a complete global view or complete control. Instead, the agents cooperate to organize the AOSN, carry out its mission, and reorganize it as needed.
CoDA uses a two-level approach. When the AOSN components arrive at the work site, some subset of them communicate and cooperate to form a meta-level organization (MLO). The MLO is a loose organization composed of those agents intelligent enough to participate in organization design. Its job is to analyze the current situation and design another organization, the task-level organization (TLO), that will actually conduct the mission. Once designed, the TLO takes over control of the AOSN until there is a significant problem (e.g., loss of a vehicle), at which point an MLO re-forms and repairs or redesigns the TLO. Figure 1 illustrates this process.
Cooperation protocols [17] control the interaction of the AOSN's agents. Different protocols are used in different phases of CoDA's operation and by different classes of agents. Task assignment is done based on matching an agent's capabilities with those needed for the mission. This is currently done via a constraint-based mechanism [11,12] that is based on constrained heuristic search [6]; in the future, this will be done in a distributed manner. Organization design is currently done very simply, and the TLO is always a simple hierarchy. In the future, other organizational structures will be used as well.
The CoDA simulator is written in Allegro Common Lisp (Franz, Inc.) and CLIPS, a rule-based language developed by NASA [7], and runs on Linux and other Unix-like systems. Low-fidelity, high-level aspects of the AOSN's behavior are encoded in CLIPS rules, while higher-fidelity portions of the control mechanism are written in Lisp. The simulator can be under the control of either CLIPS or Lisp, the former to use CLIPS' graphical user interface for debugging and the latter to run simulation experiments.
Figure 2 shows CoDA's structure prior to interfacing with CADCON. The CLIPS portion contains rules for a low-fidelity simulation of the AOSN's environment and agent movement as well as rules that simulate the agents' behavior when following the CoDA protocols. It also contains a discrete-event simulation (DES) component [1] that manages the simulation time. For example, when one agent sends a message via acoustic link, the time-of-flight is determined and an event is posted to cause delivery of the message at the appropriate time. If no other events are scheduled before that one, and there are no other high-priority rules triggered, the DES component will advance the system's simulated time to the time of that event.
The Lisp portion of the simulator contains a module to control CLIPS as well as modules for high-fidelity simulation of parts of CoDA's operation. Included in these are modules for constrained heuristic search-based task assignment and TLO design. This portion of CoDA also contains an ``experiment harness'' that generates various AOSN configurations for experiments.
Communication between the two parts of CoDA is by means of standard input/output and Unix named pipes (FIFOs). The pipes handle bidirectional I/O between the two languages during normal operation. For example, requests to generate randomly-configured AOSNs travel over one FIFO from CLIPS to Lisp, and the result travels back via the other FIFO. Lisp uses standard input/output (stdin/stdout) to control CLIPS. Basically, when Lisp is in control of the simulation, it interacts with CLIPS essentially as would a user typing at the keyboard. In this way, commands, rather than simulation messages, can be given to CLIPS and the results received by Lisp.
CADCON is a high-fidelity, multi-vehicle simulator written in C and OpenGL that runs under the Linux and MS Windows operating systems [3]. It realistically simulates several different kinds of AUV, as well as several different kinds of sensor data. It is a distributed simulation testbed; users can connect from around the world to control the simulated AUVs. It also allows hardware-in-the-loop simulation. Clients are available via the World Wide Web2.
Figure 3 shows the structure of CADCON. It is a client-server system. An environment server provides a simulation of the environment, including sensor information and communication (e.g., acoustic link) simulation. A visualization client provides a graphical user interface to the distributed system. One or more AUVSim clients are used to simulate AUVs, which interact with the environment server to comprise the simulated system. Additional clients are planned, as the figure shows. All agents communicate with one another via the Internet.
In this section, we discuss the overall design of the combined simulator. In the next section, we discuss the integration issues that arose and our solutions.
The overall design of the combined CoDA/CADCON simulator is shown in Figure 4. The interface between CADCON and CoDA is via the Internet.
CADCON was designed to support multi-agent simulations, but the assumption was that each piece of vehicle control software would control a single AUVSim. Vehicle control software would communicate with its AUVSim ``body'' via the generic behavior-based Common Command Language, CCL [15,3]. In contrast, CoDA needs to control several or many simulated AUVs simultaneously.
One approach would have been to have CoDA control several instances of AUVSim clients via the network and CCL. However, this has the drawback of requiring CoDA to translate from its internal representation to CCL for each command sent to each AUVSim. In addition, CCL itself is still under active development, hence subject to change.
Consequently, we took the approach of implementing AUVSim functionality in Lisp. In CoDA/CADCON, the Common Lisp Object System (CLOS) class VIPbase3 implements a Lisp-based AUVSim. This has several benefits:
We anticipate that over time, the Lisp-based AUVSim client will become the home for more and more of the intelligent vehicle control software, as, for example, mission controllers such as Orca [13,14] replace the simulated mission controllers currently present in CLIPS rules. We also anticipate that as CADCON and CoDA mature, VIPbase will become less of an AUVSim client and more of an interface to AUSI's AUVSim clients. This is part of the planned progression in CoDA from high-level simulation to fielded AOSNs.
In the remainder of this paper, we will refer to instances of VIPbase as AUVSim agents.
Specifications for AUVSim agents are written in a frame-based knowledge representation language. This not only provides a convenient way to describe the vehicles, but it also provides compatibility with other, frame-based systems (e.g., Orca) that will use the agents in the future. So far, specifications exist for (and there can be AUVSim agents for) EAVE vehicles [8], solar-powered AUVs [9], and some instrument moorings, in particular, a simplified version of a CONVEX mooring used to detect convective overturn events [2]. For example, Figure 5 shows the definition of an EAVE vehicle.
To set up a simulation, CoDA either generates a sample AOSN or creates one based on a file the user specifies. The AOSN's agents, represented by Lisp AUVSim agents, are also reflected in corresponding facts in CLIPS' working memory. When each AUVSim agent is created, it registers as a vehicle with CADCON's environment server. When the simulation begins, CLIPS rules simulate the AOSN as it follows CoDA protocols to organize itself and carry out its missions. Movement and other commands are sent to the corresponding AUVSim, which communicates with the environment server. As the server sends back updated position, posture, sensor, and other data, AUVSim translates this as necessary to match what CoDA expects, then informs CLIPS, which asserts it as facts in its working memory.
The CoDA and CADCON simulators are quite different from one another, both in purpose and implementation. Consequently, integrating the two was challenging. The major issues that arose are the following:
to 
, the simulator's rules
determine the travel time and simply post an event representing the AUV's
arrival at its destination.
This mismatch in time representation was one of the thorniest issues in creating the CoDA/CADCON simulator, especially since we wanted (1) to keep the ability to post events (e.g., to simulate the loss of an AUV) and (2) to keep the DES ability so that we could still run CoDA apart from CADCON when needed.
The first solution we considered was to create a process that would run on the Lisp side of CoDA constantly send time information to CLIPS. We rejected this idea because CADCON has its own system time maintained by the environment server, and one typically wants each part of a simulation to agree on the state of the current simulation environment. Different time values could lead, for example, to CADCON and CoDA having different velocity/acceleration values for an AUV.
We solved this problem by using the system time from CADCON. The packets CoDA receives from the environment server include timestamps. The Lisp side of CoDA passes this information to CLIPS, where it is asserted as the new system time. The CLIPS rules that determine which events should take place simply check that the system time is greater than or equal to the time an event should take place. Because this mechanism for performing a scheduled event is independent of the mechanism for advancing time, simply making this alteration to how time advances causes each scheduled event to happen in real time (within the resolution of CADCON's time cycle). A problem in implementing this solution was that vehicle bodies are not created in CADCON at the start of the simulation, but rather as they enter the AOSN work area, via events defined ahead of time in the problem statement. Without vehicle bodies connected to the environment server, there are no packets (and therefore no timestamps) being received from CADCON. Our solution was to create a new vehicle body type called a clock-vip. Clock-vips are massless agents that the server treats like any other agent, yet have no detectable physical presence within the simulation. Their only function is to receive the time from the server and pass this information to CLIPS. One of CoDA's first actions is to create an instance of clock-vip.
The environment server provides information about a vehicle's position and attitude. Some information is provided about the local environment as well, such as magnetic flux, current velocity, temperature, and so on. This information is the actual data from the simulated environment, not sensor data. The AUVSim agent, like the ``real'' AUVSim client, must simulate sensors that view this information and provide simulated data. For now, most of this information is simply passed through as data to CLIPS; in the future, the agent will be able to modify the data via various noise models, etc. Sensors whose information is not provided by the environment server are simulated completely by the agent, then their information is reported to CLIPS.
Commands to move, to communicate, or (ultimately) to activate effectors are sent from CLIPS rules to the appropriate agent in Lisp via the FIFOs. For example, Figure 6 shows a rule that initiates a raster search of an area by setting a waypoint and telling the corresponding AUVSim to move to that waypoint. To move, the AUVSim agent computes the appropriate desired velocity vector and angular velocities, then sends this information to the environment server. For simulated communication (e.g., via an acoustic modem) or effector commands, messages are also sent to the environment server. The environment server uses the desired velocities to move the vehicle.4
To use the CoDA/CADCON simulator, the user first defines the vehicles and instrument platforms by defining frames to represent them (see Figure 5), then either defines a problem or else lets the simulator build one or more problems.
To specify a problem, the user creates a file containing a problem definition. Figure 7 shows one such problem definition. Currently, the parts of a problem definition are:
The user next makes an instance of the simulator, telling it the location of the problem file. When the simulator is run, the problem definition specifies which AUVSims are created and when they are to be created (i.e., as the simulated vehicles arrive at the work site). These then register with CADCON's environment server.
Figure 8 shows two screenshots from CADCON's visualization client when CoDA/CADCON is running. On the right is a simple problem containing a solar AUV, an EAVE, and a CONVEX mooring. On the left is a more complex simulation containing seven AUVSims: six solar AUVs and a CONVEX mooring. (A mooring with multiple sensors, such as CONVEX, currently shows up in the simulation as multiple AUVSim clients.)
Multi-fidelity simulators facilitate the development of complex systems such as AOSNs. Such simulators allow simulations to be run at several different levels, depending on the needs of the current development efforts, from high-level, faster than real-time simulations of aggregate AOSN properties to highly-realistic simulations of vehicle movement and behavior.
The purpose of this phase of the CoDA project was to extend the CoDA multi-fidelity simulator to support highly-fidelity simulations of AUVs via interfacing with the CADCON simulator. Currently, CoDA/CADCON simulations can range from aggregate property simulations to those involving very realistic AUV behavior.
In addition, this phase of the project supports its sister project, Orca, and projects building on Orca. The mechanisms developed for utilizing CADCON from within Lisp will shortly also be used by the Orca intelligent mission controller, allowing Orca to drive simulated AUVs in CADCON simulations. This replaces an older, much cruder simulation testbed.
Future work in the CoDA project will focus on issues related both to CoDA protocols and to simulation. Most of the future work will focus on further developing the mechanisms and protocols for AOSN operation, in particular for autonomous organization/reorganization and task assignment. Work will also focus on improving the rather primitive means CoDA now uses to describe problems and, to a lesser extent, vehicles and instrument platforms. Currently, for example, tasks require particular capabilities, but there is no principled way to specify when and where those capabilities will be needed, nor is there a way to specify resource needs. Constraints between capabilities are also not well-supported; at the current time, for example, one cannot specify ``capability A needs to be done by the same vehicle as capability B''.
With respect to the CoDA/CADCON simulation, most of our future work will be on the CoDA side. We anticipate moving more of the CoDA control mechanism into Lisp and out of CLIPS as we move from aggregate property simulation to agent-based simulation. To do this, vehicle controllers (e.g., Orca) will be linked to our Lisp AUVSims (VIPbase objects). Also, as we mentioned above, as work on CADCON progresses, VIPbase will contain less vehicle simulation code; instead, VIPbase will be modified to interact with AUSI's AUVSim clients. This will allow higher-fidelity simulations as well as the option of using real hardware. This will be an important step along the path toward eventually moving CoDA out of simulation and into the real world.
This work was funded in part by grants N0001-14-96-1-5009, N0001-14-98-1-0648, and N00014-00-1-0614 from the Office of Naval Research. The content of this paper does not necessarily reflect the position or the policy of the U.S. government, and no official endorsement should be inferred. Authors are listed alphabetically; contact author is Roy M. Turner (rmt@umcs.maine.edu). The authors thank Andrew Sylvia for his work on part of the simulator and also the other members of the Maine Software Agents and Artificial Intelligence Laboratory (MaineSAIL).
