Trip Report

ALP Demonstration and Meeting with Jim Hendler

February 4, 1999

Frank Manola
Object Services and Consulting

ALP Demo

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 brochure) include: 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.

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,, 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?]

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.

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 <>.  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.