DARPA ULTRALOG Final Report - Industrial and Manufacturing ...
DARPA ULTRALOG Final Report - Industrial and Manufacturing ...
DARPA ULTRALOG Final Report - Industrial and Manufacturing ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Proceedings of the 1st Open Cougaar Conference 2<br />
promising approach to deal with the large-scale systems is<br />
multiagent systems (MAS), we agentify the components<br />
in purely control point of view. In MAS, agents address<br />
the scalability issue by computing solutions locally <strong>and</strong><br />
then using this information in a social way. In this paper<br />
we develop a multiagent-based adaptive control<br />
mechanism with scalability <strong>and</strong> predictability to support<br />
survivability of large-scale networks.<br />
Specifically, in Section 2, we discuss problem domain<br />
<strong>and</strong> in Section 3 formally define the problem in detail.<br />
We review previous control approaches in Section 4. We<br />
design an adaptive control mechanism in Section 5 <strong>and</strong><br />
show empirical results in Section 6. <strong>Final</strong>ly, we discuss<br />
implications <strong>and</strong> possible extensions of our work in<br />
Section 7.<br />
2. Problem domain<br />
The networks we study in this paper represent<br />
distributed <strong>and</strong> component-based architectures. As an<br />
instance, Cougaar (Cognitive Agent Architecture:<br />
http://www.cougaar.org) developed by <strong>DARPA</strong> (Defense<br />
Advanced Research Project Agency), follows such an<br />
architecture for building large-scale multiagent systems.<br />
Recently, there have been efforts to combine the<br />
technologies of agents <strong>and</strong> components to improve the<br />
way of building large-scale software systems [8][9][10].<br />
While component technology focuses on reusability,<br />
agent technology focuses on processing complex tasks as<br />
a community. Cougaar is in line with this trend. In<br />
Cougaar a software system is comprises of agents <strong>and</strong> an<br />
agent of components (called plugins). The task flow<br />
structure in those systems is that of components as a<br />
combination of intra-agent <strong>and</strong> inter-agent task flows. As<br />
the agents in Cougaar can be distributed both from<br />
geographical <strong>and</strong> information content sense, the networks<br />
implemented in Cougaar have distributed <strong>and</strong> componentbased<br />
architecture.<br />
UltraLog (http://www.ultralog.net) networks are<br />
military supply chain planning systems implemented in<br />
Cougaar. Agents in those networks represent<br />
organizations in military supply chains. The objective of<br />
an UltraLog network is to provide appropriate logistics<br />
plan to a military operational plan. The system produces a<br />
logistics plan by decomposing the operational plan into<br />
logistics tasks <strong>and</strong> processing them through a task flow<br />
structure. The system makes initial planning for a given<br />
operation <strong>and</strong> continuous replanning in the execution<br />
mode to cope with logistics plan deviations or operational<br />
plan changes. As the scale of operation increases there<br />
can be thous<strong>and</strong>s of agents working together to generate a<br />
logistics plan.<br />
Initial planning or replanning generates a logistics plan<br />
as a global solution, which is an aggregate of individual<br />
schedules built by plugins through their task flow<br />
structure. Each plugin can implement one of its available<br />
implementation alternatives which trade off processing<br />
time <strong>and</strong> quality of the schedule. Quality of service is<br />
determined by two metrics, quality of logistics plan <strong>and</strong><br />
plan completion time. These two metrics directly affect<br />
the performance of the operation.<br />
Planning <strong>and</strong> replanning of UltraLog networks are the<br />
instances of the current research problem. An UltraLog<br />
network cannot work in isolation from outside world<br />
because they utilize external databases <strong>and</strong> users should<br />
be able to access the system. This inevitable connection to<br />
the outside makes the system exposed to malicious<br />
attacks in addition to accidental failure. Now, the<br />
question is how can we make this system survivable to<br />
generate high quality logistics plans in a timely manner in<br />
the presence of accidental failures <strong>and</strong> malicious attacks?<br />
3. Problem specification<br />
In this Section we formally define the problem by<br />
detailing the network model. We concentrate on<br />
computational CPU resources assuming that the system is<br />
computation-bounded.<br />
3.1. Network model<br />
We define four elements of the network to clarify its<br />
mechanics: network configuration, implementation<br />
alternatives, quality of service, <strong>and</strong> stress environment.<br />
Network configuration<br />
A network is composed of a set of agents A with each<br />
agent located in its own machine. Task flow structure of<br />
the network, which defines precedence relationship<br />
between agents, is an acyclic directed graph with each<br />
link assigned a positive real number. A link number l ij<br />
(i≠j) indicates the number of tasks generated for successor<br />
agent j when agent i processes a task in its queue. Once<br />
accumulated tasks for a successor agent becomes over<br />
one, the corresponding integer number of tasks are sent to<br />
the successor agent. By using real numbers we can<br />
represent wide range of task flow structure including noninteger<br />
aggregation <strong>and</strong> expansion.<br />
A problem given to a network is decomposed in terms<br />
of root tasks for some agents. And, those tasks are<br />
propagated through task flow structure.<br />
Implementation alternatives<br />
An agent can have multiple implementation<br />
alternatives to process a task. Different alternatives trade<br />
off CPU time <strong>and</strong> solution value with more CPU time