ALP Demonstration and Meeting with Jim Hendler
February 4, 1999
Object Services and Consulting
The Advanced Logistics Project (ALP) carried out a series of demonstrations
of its distributed agent technology for developing logistics plans at the
TIE facility at DARPA, in Arlington, VA. I attended the Feb. 4 afternoon
session at the invitation of Todd Carrico, the ALP Program Manager.
The demonstration involved a network of 5 sites running ALP agent software,
including DARPA, Defense Logistics Agency (DLA), US Transportation Command,
US Central Command, and US Army Forces Command, and included access to
"live" systems and databases. Goals of the program (from the program
There are over 450 stovepipe logistics systems which handle various parts
of the logistics problem for the various services (these include such things
as complex route planners and scheduling systems, and simulations used
to verify whether a proposed plan or portion thereof is feasible).
These systems often do a very good job on their particular parts of the
problem, but are not interoperable, were often designed for static planning
rather than dynamic use, and were not designed to contribute to an end-to-end
solution. One of the things ALP does is tie these systems together.
ALP also provides capabilities for integrating non-DoD systems. For
example, the demo involves accessing the Georgia Port Authority's database
to get information about commercial shipping activity in the Port of Savannah.
Also, the DLA's ALP cluster has business rules that determine how to source
parts. One of its available mechanisms is to send EDI messages to
vendors to satisfy part requirements.
Automated logistics plan generation. Tightly link the J3 [joint operations]
and J4 [joint logistics] planning and execution processes to produce an
executable, level-5 [down to the individual item level] time-phased force
and deployment database (TPFDD) in one hour [for a major force deployment].
Real-time logistics situation assessment. Identify plan deviations
within 15 minutes and update a logistics plan within 10 minutes of detecting
End-to-end movement control. Minimize cargo, equipment, and personnel
staging while globally optimizing air-, land-, and sea-lift resources across
the spectrum of movement activities.
End-to-end rapid supply. Continuously assess the demand and sourcing
of materiel and supplies from DoD and commercial inventories.
The demo used a Southwest Asia scenario involving the deployment and
sustainment of an Army mechanized infantry divisiion and an Air Force Expeditionary
Force. The presentation took about 2 hours, with the demo itself
(which went on concurrently with the presentation) lasting about an hour.
The briefing was done partly by Todd, and partly by Cola Atkinson, firstname.lastname@example.org,
of ALPINE (ALP Integration and Engineering, a joint venture of BBN and
Raytheon). Part of the briefing described the cluster architecture
of ALP. Clusters are essentially agents representing specific organizations
(or components of organizations). A cluster contains three components
that represent parts of an abstract human cognitive process:
Clusters also have plug-ins. These plug-ins represent domain knowledge
(rules or business processes that define, e.g., how to schedule trucks,
order parts, etc.; plug-ins can also be wrapped legacy systems).
The plug-ins define the specific capabilities a given cluster has, and
tailor it to its specific role. Clusters form collections called
communities, which in turn form societies. [One question which occurred
to me was whether and how the system determined what tasks a given cluster
was capable of supporting. Was there "type-like" information about
the plug-ins contained in a given cluster (or about the likely capabilities
of the type of unit represented by the cluster)? Were tasks simply
sent to clusters to which they would respond negatively if they didn't
have the right plug-ins?]
an Expander, which decomposes a problem (task) received by the cluster
into smaller pieces
an Allocator, which decides whether to do the task or assign the task to
an Assessor, which monitors progress
The demo also illustrated how the clusters divided up and performed
the work of building (and updating) the logistics plan. For example,
battalion-level clusters might determine, on the basis of information they
have received on the operational tempo (OPTEMPO) and duration of the planned
operation, that they would need more ammunition than they have organically.
This would cause them to generate a support requirement. This in
turn would generate a requirement for truck units, which in turn would
generate movement requirements, etc. All this would percolate up
and down the plan. For an organization like, e.g., DLA, requirements
come in constantly, so any "plan" that included their "plan" would be changing
constantly as well.
The demo was rather impressive. Todd Carrico said that the FY99
focus was on execution monitoring and dynamic replanning (trigger replanning
based on detection that the plan is not meeting requirements, or that parts
of the plan cannot be carried out for some reason; dynamic replanning
is also needed to allow changes based on operational information to feed
back into the logistics plan, e.g., to deal with changes in where materiel
has to go based on unit movements, or to deal with casualties). Other
aspects not yet included in ALP, to be addressed in later phases, include
consideration of multiple Courses of Action (COAs), fault tolerance, and
dynamic reconfiguration (e.g., adding organizations and systems).
[The need for continuous replanning, in keeping a plan up to date, suggests
a possible role for any work in CoABS concerning guarantees of stability/convergence
of these computations. A related issue might be decisions a Grid
architecture might want to make in deciding when to expend cycles on continuously
tweaking a logistics plan vs. other uses of the same computing resources.
This is somewhat less relevant today since the systems that would be doing
most of the tweaking are systems already dedicated to logistics, but in
a grid these systems might be taskable for other uses.]
Todd said that several of the DoD components participating in the program
have spent a good deal of their own efforts in customizing their clusters
to make them more capable, and are using or going to use ALP technology
for system development (I think I got all this right):
Todd noted that systems like this can initially function as stand-alone
applications, but as other clusters come up elsewhere, they are positioned
to interoperate to form parts of a complete solution.
DLA is using ALP clusters in a prototype sourcing application.
The AMC (Air Mobility Command) has implemented an air crew scheduler (AirCAMS)
based on this technology that is said to have improved their processes.
MTMC (Military Traffic Movement Command, a component of the US Transportation
Command) is using the technology outside the program to deal with port
operations scheduling, tying together three existing systems: ICODES
(an agent-based system that generates ship stow plans), LSA (Load Sequencing
Agent, which generates a derived ship loading schedule) and PORTSIM (simulates
workflow through a port, used to derive schedules for material to arrive
at the port).
The Air Force Research Lab has used clusters in a Wing Logistics Planner
An interesting question came up following the demo concerning whether
an operator could find out the assumptions that some of the clusters were
using to generate certain results. The question was initially answered
as if it referred to access control, but it really referred to whether
the "business rules" used by various components were explicitly available
for inspection and possible alteration if they were unrealistic.
Todd picked up on this (the example he used was "this plan assumes you
can overfly France"), and noted that ALP would need to be able to provide
this information when it is extended to support "other worlds" (what-if
situations, contingency plans).
The demo very much billed ALP as distributed agent technology ("the
first large-scale distributed agent architecture"). Hence the technology
integration issue with CoABS is along the lines of "what does ALP, as an
agent-based system, need that CoABS might be able to provide, and what
lessons can CoABS learn / what technologies can CoABS borrow / etc., from
this more-thoroughly-developed system.
Following the demo, I spoke briefly with Todd, and at more length with
Max Mansur, Deputy Program Manager, of Alpine <email@example.com>.
He said to send him a description of what I was doing [which I have since
done], and he'd get me access to any Web sites or other documentation I
needed. During our discussion, he indicated he'd been working on
data warehouses before this, and hence understood the need for more and
better metadata in these systems to enable interoperability (a particular
issue he'd run into was multiple use of acronyms, a well-known DoD problem!).
Meeting with Jim Hendler
Later that same day, I met with Jim Hendler, CoABS Program Manager, in
order to talk over the newly-started CoABS-ALP technology interchange project
that I'm working on. Jim said that my job was to tell him (and Todd)
what ought to be done regarding technical exchange between the projects,
and that he was looking for unbiased, practical advice, and a vision as
to how to build a joint architecture, rather than deep detailed analysis.
He is looking for "low hanging fruit" (in GTE terminology, these would
be termed "drive-by shootings"), i.e., things that can be started quickly,
and that will give maximum results for minimum effort or redirection, since
this is a key time in both programs to identify integration opportunities.
He said that he thought the first step should be the rapid production of
a bullet list of things to do (in effect, a statement of work) and how
to do them (with some options), for Jim and Todd's consumption only.
The three of us would meet to discuss the list, roughly around the end
of February, and agree on a course of action. In the meantime, he's
prepared for a lot of email interaction (he said he prefers meetings to
a lot of detailed writeup). He seemed to feel that Craig had a pretty
good handle on the architectural issues of both CoABS and ALP, based on
the bullet list of issues he'd produced earlier. Jim said he'd like
to see this work briefed at the June/July CoABS meeting. He also
mentioned that GITI was to have a first cut Grid defined by the end of
March, and it would be good to have defined any hooks in the Grid that
ALP would need by that time. Jim also said that although we're funded
for around 6 months, the end date is December, so it might make sense to
have some peaks and valleys in the amount of work going on at various times,
in order to save some time for consultations with development contractors
working on any tech transfer activities.
Jim said he felt that one area in which CoABS could help ALP was in
dealing with more heterogeneity; that ALP was relatively homogeneous
both in terms of its system organization, and the types of problems it
was designed to solve (those that break down into a hierarchical subproblem
structure). Another area was in tracking, i.e., if a bad plan was
generated, being able to figure out why, so corrections could be made.
CoABS work on control should be able to address this problem. (This
issue seems related to the question which came up at the ALP demo concerning
whether an operator could find out the assumptions that some of the clusters
were using to generate certain results.) Jim identified as key contacts
Brian Kettler from the CoABS side, and Steve Milligan from the ALP side
(I'd noted that Marshall Brinn was now the ALP chief architect, but Jim
said that Steve was also somewhat familiar with CoABS, and so had some
perspective on both sides). All in all, even though the meeting was
rather brief (around 30 minutes), I think things are off to a good start.