DARPA ULTRALOG Final Report - Industrial and Manufacturing ...

In the Cougaar planning model, the basic element is a
task. Each task has a unique identifier (UID) and a set of
fields including the task verb (e.g. “Supply”, “Project”,
“Transport”) and the direct object (e.g. the UID of the
Asset which the task acts on).
Each task element must be allocated to a plan element
during the distributed planning process. These include:
• Allocation elements. An allocation is a
assignments of tasks to particular assets. The
assets can be locally represented (e.g. an
inventory) or an organizational asset (e.g. a
customer organization allocates a task T to a
Supplier asset. Here, the Supplier asset
represents an actual agent to which T will be
forwarded.)
• Expansions. Decomposition of tasks into
subtasks.
• Aggregations. These collect multiple tasks into
a single task.
Each agent can therefore be modeled as taking inputs as a
set of tasks, generating local blackboard tasks and plan
elements, and generating outputs as a set of tasks to be
forwarded to the representative agent(s). (In Cougaar,
tasks are forwarded to another agent by the logic provider
if they are allocated to the (local) organization asset
which represents the target agent.) All the blackboards
and task elements are assumed to be persistent, unique
objects.
The result of a single planning run is logically a
connected, distributed plan graph that spans multiple
agents and multiple nodes. In addition, the plan graph
may evolve and change during replanning as tasks are
rescinded, modified and replanned.
2. Castellan System Design and
Implementation
The primary distinguishing aspect of Castellan is that
provides the ability to observe the time evolving state of
the distributed agent blackboards rather than the final
state after planning has been reached.
The Castellan system has two aspects: the client
implementation which monitors planning at agents, and
the server implementation that collects the logs
accumulated by the client side. Figure 1 shows an
example of the concept of operations. It shows a set of
agents which are being monitored and sending events
traces to a server application. In turn, the server
application can log them to a database or feed them
directly to monitoring and analysis applications. In the
current implementation of Castellan, the server
application is itself implemented as a plugin which can be
embedded in a Cougaar agent.
Castellan has evolved to support the following modes of
operation on the client implementation:
• Plugin based execution. A monitoring client
plugin loaded in each agent subscribes to all
modifications to the blackboard.
• Logic provider based execution. A Castellan
logic provider is attached to each agent and
monitors changes to the blackboard through the
logic provider interface.
The primary difference between these two approaches is
that the latter allows monitoring the source of each
change to the blackboard as well as the number of
execute cycles associated with each change. The latter
approach is useful in debugging since it can observe
which plugins execute and the number of execute cycles
of each plugin loaded for an agent. These features are
useful for debugging and detailed performance analysis of
agents.
Agent 1 Agent 2 Agent 3
Event
Database
Castellan Server
Plan Analysis
Applications
Sensors
Event Protocol
Figure 1. Castellan System Concept
As agent execution proceeds, the client implementation
generates a stream of events for each task and plan
element added, changed, or removed to the system
blackboard. The event trace and logging protocol extracts
a subset of the data encapsulated by the tasks, assets, and
plan elements sufficient to reconstitute the entire plan
graph. These include:
• The unique identifier, encoded as a symbol id
rather than a string.
• The timestamps associated with the blackboard
action (both simulation and wall clock time.)
• For tasks, the verb for tasks encoded as a
symbol id.