Agents in Logistics Planning – Experiences with the Coalition
Agents Experiment Project
Don Perugini 1, 2, Steven Wark 1, Andrew Zschorn 1,Dale Lambert 1, Leon Sterling 2 ,
Adrian Pearce 2
1 Defence Science and Technology Organisation (DSTO), PO Box 1500 Edinburgh, South Australia 5108,
Australia
{firstname.lastname}@v.au
2 Department of Computer Science and Software Engineering, The University of Melbourne, Victoria 3010
{leon / pearce}@au
Abstract
Military logistics planning is a complex process, involving many calculations, satisfaction of constraints, and cooperation amongst many organisational entities that provide rvices in order to achieve military logistics goals. Multi-Agent Logistics Tool (MALT) is a project aimed at supporting military logistics planning. MALT is being developed using agent technology, where agents reprent the organisations within the logistics domain, and model their logistics functions, process, experti, and interactions with other organisations. Agents are a suitable technology for modelling organisations within MALT, due to the similarity in characteristics between organisations and agents. A component of MALT was implemented within DARPA’经历的近义词
s Coalition Agent Experiment (CoAX) project. We discuss the CoAX implementation of MALT, and lessons learnt. We discovered that imp腿腿个人资料
lementing a centralid agent planning approach within MALT, and hence the decentralid military (operational) logistics planning domain, may not always be appropriate, and that a decentralid agent planning approach may be more suitable. Some of our obrvations regarding the future of agents for military logistics planning are discusd.
Keywords: Military Logistics Planning, Decentralid Agent Planning, BDI, CoAX
1. Military Logistics Planning
Military (operational) logistics planning primarily involves supplying and transporting resources and military asts. Logistics planners must form a plan to achieve specific logistics goals, such as deploying force elements1 and sustaining them throughout an operation (by providing food, water, fuel, ammunition, medical support, storage, etc.), and planning a medical evacuation (medevac) when casualties occur. The logistics goals are achieved by obtaining rvices from various organisational entities, for example, obtaining fuel from a fuel supplier, and having a freight company provide the transportation of the fuel from the fuel supplier to its required destination.
The military logistics planning domain is decentralid becau it typically requires the involvement of parate independent organisations – as a combination of Australian Defence Force (ADF), civilian and coalition organisations could be involved. The organisations, which primarily include supply, transport and怎么写请假条
force element organisations, are geographically distributed, and must cooperate in order to achieve the logistics goals. Each organisation have their own logistics “business” process in order to perform their particular logistics functions (rvices), required to achieve logistics goals. The logistics domain is decentralid, not becau it is geographically distributed, but becau it’s organisatioktv经典老歌
ns exhibit a strong notion of autonomy with characteristics such as: being lf interested; making their own decisions (i.e. not controlled by others); and being r
eluctant to relea information (e.g. becau it may be proprietary or classified). The logistics domain is also dynamic, where logistics goals, organisations’ capabilities (the type and availability of rvices they can provide) and beliefs are continually changing throughout the planning process; as well as open, where organisations may enter or leave the system at any time.
1 A Force Element (FE) is a military unit and its associated resources/asts and equipment, including personnel, vehicles, aircraft, and weapons.
To add to the complexity, logistics planning requires many interactions between organisations, many calculations and satisfaction of many constraints (e.g. ensure that casualties are delivered to the appropriate medical facilities in time). As a result of logistics planning complexities, there is typically a trade off between the time to form the logistics plans and the quality of the logistics plans formed. Multi-Agent Logistics Tool (MALT, formerly LPS) [1] is a project aimed towards developing a military logistics planning support system, which will automate aspects of logistics plan formation, analysis and information gathering.
MALT compris agents that reprent the organisations, modelling their logistics business process, experti, and interactions with other agents in the logistics domain, in order to achieve t
he organisations’ logistics functions. Agents in MALT cooperate with each other in order to form a distributed logistics plan (rvices from various organisations) to meet their logistics goals. The input for MALT is a logistics goal, and the output is a logistics plan, which can be executed in order to achieve the logistics goal.
In this paper, we will discuss the reasons for using agents in the logistics domain, our experiences with implementing components of MALT within DARPA’s Coalition Agent eXperiment (CoAX) [2] project, lessons learnt in MALT’s implementation, and our obrvations regarding the future of agent technology for logistics.
2. Why u agents?
Agents have strong autonomous characteristics that distinguish them from other software paradigms: “Objects do it for free; agents do it becau they want to.” [3].
In addition to autonomy, agents are proactive (goal directed and thus intentional), reactive, and exhibit complex social behaviour (rather than software entities that can execute each other’s functions/methods freely) [3].
The logistics domain is distributed and involves decentralized (autonomous) organisations. The organisations are also: intentional entities, with goals (functions and roles), beliefs, and u process and experti in order to achieve their goals; are reactive, and thus respond to changes that occur in their environment; and are social, so they interact with other organisations to achieve their goals, where the social interaction is typically complex, such as negotiation, rather than just action requests. The similarity in characteristics between agents and organisations make agents an appropriate choice for modelling organisations within MALT.
3. MALT within CoAX
DARPA’s Coalition Agent eXperiment (CoAX) [2] project was aimed at demonstrating the utility of agents for coalition planning [2, 4]. Some 20 organisations from the USA, UK and Australia were involved. MALT was implemented within CoAX (Oct 2002) [4], with the aims of demonstrating components of MALT, and thus the u of agents for military logistics planning in the Australian-Coalition contexts, interoperability with foreign agents (i.e. agents not developed by us), and the dynamic capability of MALT.
Our part of the CoAX project involved a vignette where an Australian ship was struck by a torpedo, r
esulting in damage to the ship and casualties. A medevac is required to transport the casualties from the ship to a coalition medical facility using available helicopters. Agents reprented the ship’s medevac function (medevac agent) and onboard resources, and a single proxy agent reprented the coalition helicopter and medical facility resources, providing information regarding the availability of medical facilities to treat casualties, and availability按摩手法背部
of helicopters to transport the casualties. The medevac agent modelled the logistics process of planning a medical evacuation from the ship. The agents cooperated in order to form a medevac logistics plan.
The medevac agent was developed using the ATTITUDE multi-agent architecture [5, 6], which is bad on the belief-desire-intention (BDI) agent model [7]. The logistics process for a medevac was reprented as a plan (routine), and executed when casualties were detected on the Australian ship, triggering the “medevac” task. Cooperation between the medevac agent and the other agents were facilitated by DARPA’s CoABS grid [8] and IHMC’s KAoS agent management system [9].
The medevac agent, when triggered, requests the availability of medical facilities to treat its casualties, and helicopter resources to plan the transportation of casualties from the Australian ship to the nearest suitable medical facility. The proxy agent responds with available medical facilities and helicopters, providing distances to facilities, start location, earliest start time, and types of helicopters
available. The medevac agent us prior knowledge of the carrying capacity and speed of the types of helicopters.
A simple algorithm is ud by the medevac agent to form a transportation plan. The helicopter that can transport the injured to the medical facility at the earliest time is lected to perform the transportation task. Highest priority casualties are transported first. If the lected helicopter cannot transport all the injured, the process is continued with the remaining injured.
The plan formed is nt to the foreign Multi-Level Coordination Agent for processing, to deconflict and optimi (merge) the medevac plan with existing flight plans developed by foreign (coalition) agents. The plan is then distributed to the appropriate coalition helicopters and medical facility for execution. The medevac agent reacts to any changes, such as helicopter availability, the number and type of casualties, or the availability of the helicopter landing pads and replans if necessary.
The CoAX demonstration was held in October 2002 at the US Navy Warfare College, Newport RI. It successfully prented components of MALT in operation, and thus demonstrated the u of agent technology for military logistics planning. UltraLog (or ALP) [10] has also demonstrated that agents can be ud for the U.S. logistics planning domain. We are focusing on the Australian-Coalition cont
exts. The logistics process of a (ship) medevac was effectively modelled in the medevac agent using A TTITUDE. The medevac agent successfully cooperated with foreign agents, nding the final medevac plan to the foreign Multi-Level Coordination Agent for processing and distribution to coalition helicopters and medical facility. The medevac agent was able to dynamically replan when the situation changed.
4. Lessons Learnt
This architecture for logistics planning was ud in the CoAX context to facilitate development and testing of the Australian agents independently from the rest of the coalition organisation. Although this transportation planning approach worked well for the CoAX demonstration, its esntially centralid nature impod veral limitations. By centralid, we mean that all information about the helicopters agent’s capabilities are nt and procesd by the centralid medevac agent, which forms a transportation plan by deciding (alone) how the coalition helicopters’ capabilities will be ud to achieve its transportation task. This may be appropriate if the medevac agent and helicopters are from the same organisation (e.g. ADF), which typically act towards a common goal and may have a limited right to issue orders among themlves. However, if other organisations are involved, e.g. coalition organisations, such as the coalition helicopters, this may not always be appropriate. Coalitio
n helicopters, which are from one organisation, may not want to be told what to do by the ADF medevac agent that is from another organisation. The coalition helicopters may be lf-interested and decisions made by the medevac agent may not be in the interests of the coalition helicopters. Also, information by one organisation (e.g. coalition helicopters) may not be able to be relead for processing by a centralid agent that is from another organisation (e.g. ADF medevac agent), becau the information may be proprietary or classified. For example, in the CoAX experiment, coalition helicopters were not immediately available as they had already been scheduled for other tasks – information not relead to the medevac agent. As a result, the Multi-level Coordination Agent described above was needed to resolve any conflicts and maximi synergies between the medevac plan and the existing coalition flight plans. In a decentralid system this would be embedded within the negotiation process. Limitations of a centralid approach are not only confined to coalition operations. Most ADF logistics operations are likely to involve civilian (other) organisations. Therefore, in general, a centralid agent planning approach may not always be appropriate within MALT, and hence the decentralid military (operational) logistics planning domain.
The centralid agent planning approach also has a technical limitation. The medevac agent ud a
simplified protocol that assumed that the helicopters are available anytime after its specified start time, and can carry its full capacity of casualties throughout the time it is available. If the medevac agent was to accommodate situations such as helicopters not being available at various times after their specified start time, or can arrive at the ship during some other trip (piggyback), and hence can only carry a portion of its full capacity, then the coalition agent will have to communicate much more information,
possibly the complete flight plans of all helicopters in the theatre of operations, to the centralid medevac agent. The quantity of information th奥尼尔球衣号码
at would need to be communicated to the medevac agent in such a ca would be extensive. If a decentralid approach was implemented, agents could process the information themlves and nd just the results.
A new protocol is being developed, called the Provisional Agreement Protocol (PAP), which allows decentralid agent planning [11, 12]. An 鸿门宴古今异义
agent’s logistics goal is nt to rvice providing agents that may be ud to achieve the goal. The rvice providing agents only relea capabilities (rvices) that they are willing to perform in order to fully, or partially, achieve the l大圣归来壁纸
ogistics goal. The most suited capability is lected. If the lected capability did not achieve the complete logistics goal, the portion of the logistics goal that the capability did not achieve becomes the new logistics go
al to be achieved. The process repeats until the logistics goal is completely achieved, resulting in a distributed plan that describes the capabilities to be performed by the various rvice providing agents in order to achieve the logistics goal. The protocol allows backtracking, hence if a lected capability was later found to be inappropriate to achieve the logistics goal, then the agent performing the planning process may de-commit from the lected capability, and lect another capability to replace it. The protocol provides policies regarding the commitment and persistence of agents’ capabilities and goals, and speech acts to facilitate this interaction (planning process).
5. Future of Agents for Logistics
Bad on our experiences with using agents for logistics planning, we found two main issues2 that need to be overcome in order for agents to be effectively ud for military logistics planning – technology and social (human) acceptability.
5.1 Technology
• Logistics business process modelling– How can the logistics process be effectively modelled using agents? A framework is required that allows a developer to extract logistics process from an organisation that are to be automated, and embed the process into an agent(s). The framework
will most likely be dependent on the agent architecture, e.g. BDI agent a梦见被狗咬到手
rchitecture. If the organisations logistics process are dynamic, how can they be maintained in the agent system? There are also technical issues that need to be resolved regarding logistics process, such as how to cope with late or inconsistent information, and how can learning be ud?
• Protocols – Need to devi protocols that can facilitate decentralid agent planning, that will consider the type of interactions and negotiations that take place between organisations within the logistics (business/e-commerce) domain. This work is currently under development.
• Ontologies– What knowledge is required for the logistics domain, and how does one effectively reprent it and reason about it? Ontologies will allow agent interactions by providing agents with common mantics, enabling agents to understand communicated information from other agents, such as logistics goals, rvices (capabilities), and descriptions of resources (physical objects). The type of reasoning that can be achieved, bad on requirements, needs to be investigated, since there is a trade off between expressiveness and computational complexity. CoAX demonstrated the u of DAML, “which is a language that provides a rich t of constructs with which to create ontologies and to markup information so that it is machine readable and understandable” ().
• Automated information gathering– MALT intends to incorporate agent “experts” who can provide advice and knowledge to other agents bad on their domain of experti. Expert system technology typically focus on the single agent. Complex social issues need to be investigated, such as providing a mechanism for agents to find the appropriate experti, particularly when the experti may be the conjunction of knowledge provided by more than one expert agent. Agents may arch for information themlves, where the information is stored in various information sources. This will be facilitated using mantic web technologies, such as DAML, where information is tagged with knowledge, bad on some ontology, making the information “machine readable”, allowing agents to arch for information on their own (in an automated way). Elements of automated information gathering were demonstrated in CoAX, including the briefing agent by DSTO [4], Mobile Agent for Medical Monitoring by Dartmouth College (agents.cs.Dartmouth.edu), Verona by
2This list is by no means complete.
GITI and ISX (), Decision Desktop by QinetiQ (), and Ariadne by University of Southern California and ISI (www.isi.edu/ariadne).
• Security– Security has traditionally been a major concern with information technology systems. Iss
ues such as integrity, authentication, and cure communication, need to be considered. In CoAX, policy control of agent registration, behaviour and communication was demonstrated using the KAoS system developed by IHMC [9].
5.2 Social Acceptability
• Trusting agents to do business for you– Will humans or organisations trust agents to do business for them without supervision, i.e. have agents ll and buy rvices and products?
There may be a concern that software may not act rationally, and result in the organisation losing money, or possibly wor conquences. Can we ensure that agents will always do the correct thing, or can we demonstrate that agents will do the correct thing most of the time (everyone makes mistakes, even humans), in order to increa the human level of trust in agents? Can we implement mechanisms that can prevent riously damaging actions by agents? Our initial implementation of MALT intends to form a logistics plan but not act on any of the elements in the plan. The plan is intended as a possible cour of action, and if the ur finds that it is suitable, the ur may act on it. Whether we will get to a stage where the ur will allow the agent to act will remain to be en.
• Accountability and the law – If an agent does something wrong, who will be accountable? Is it the o
rganisation or the agent developer?
• Humans and agents working together – Rather than having humans “using” the system, we may want humans as “part of” the agent system. How can this be done effectively, and what effect on the systems overall performance will it have? Suitable human friendly protocols and interfaces need to be in place in order for this to be realid.
• Agents can do logistics planning more efficiently – It needs to be shown that agents can do aspects of logistics planning more efficiently.
• Ea of u – We need to bridge the gap between the human and the machine, so that humans can u the system with ea. Such a task may not be trivial, particularly since it may be dependent on the individual ur. Hence, an interface that can be adjusted to the urs preferences may be required.
• Adjustable autonomy [13] – The level of control that the ur has over the agents (or system) should be adjustable. Some urs may want the agent to make all the decisions (press a button and get all the answers), where others may want to take more control over the agent’s actions, specifying exactly how the agent should solve the particular problem.
• Adjustable visibility– The level of visibility of what the agent does and how it came to a decision should be adjustable. Some urs may not care how an agent came to a decision, where others may. Higher visibility is uful particularly if the ur wants to gain trust in the agent’s decisions.
• Social Acceptability versus Optimality– First, humans may not accept a plan even though it may be optimal. For example, it may be cheaper to schedule flights for a husband and wife on parate flights, but the husband and wife may not accept that plan. Second, agents may undergo complex negotiation process and protocols, possibly allowing them to obtain better results. Humans may not be willing to do the same, becau of complexity (hard to understand) or long iterative process required (may not want to waste time performing some process over and over again), and thus may be willing to sacrifice optimality for simple and quick negotiation strategies.
6. Conclusion
MALT is a military logistics planning support tool, aimed at automating the complex process of plan formation, information gathering and analysis. It is being developed using agents, where agents reprent the organisations within the logistics domain, and model their logistics functions, process, experti, and interactions with other organisations. Due to the similarity in characteristic
s between organisations and (intelligent) agents, agent technology is an appropriate choice for modelling organisations in the logistics domain. MALT was implemented within CoAX, and the aims of MALT were achieved. Lessons learnt from the CoAX implementation was that the centralid planning approach ud may not be appropriate for MALT, and hence the decentralid military logistics planning domain, and that a decentralid agent planning approach may be more suited. A protocol, called Provisional Agreement Protocol (PAP) is being developed to facilitate decentralid agent
