22-02-2013, 09:39 AM
Agent-Oriented Supply-Chain Management
Agent-Oriented Supply.pdf (Size: 741.99 KB / Downloads: 14)
Abstract
The supply chain is a worldwide network of suppliers, factories, warehouses, distribution centers, and
retailers through which raw materials are acquired, transformed, and delivered to customers. In recent years, a new
software architecture for managing the supply chain at the tactical and operational levels has emerged. It views the
supply chain as composed of a set of intelligent software agents, each responsible for one or more activities in the
supply chain and each interacting with other agents in the planning and execution of their responsibilities. This
paper investigates issues and presents solutions for the construction of such an agent-oriented software architecture.
The approach relies on the use of an agent building shell, providing generic, reusable, and guaranteed components
and services for communicative-act-based communication, conversational coordination, role-based organization
modeling, and others. Using these components, we show two nontrivial agent-based supply-chain architectures
able to support complex cooperative work and the management of perturbation caused by stochastic events in the
supply chain.
Introduction
The supply chain is a worldwide network of suppliers, factories, warehouses, distribution
centers, and retailers through which raw materials are acquired, transformed, and delivered
to customers. Supply-chain management is the strategic, tactical, and operational decision
making that optimizes supply-chain performance. The strategic level defines the supply
chain network; that is, the selection of suppliers, transportation routes, manufacturing facilities,
production levels, warehouses, and the like. The tactical level plans and schedules
the supply chain to meet actual demand. The operational level executes plans. Tactical- and
operational-level decision-making functions are distributed across the supply chain.
To optimize performance, supply-chain functions must operate in a coordinated manner.
But the dynamics of the enterprise and the market make this difficult: Materials do not
arrive on time, production facilities fail, workers are ill, customers change or cancel orders,
and so forth, causing deviations from the plan. In some cases, these events may be dealt
with locally; that is, they lie within the scope of a single supply-chain function. In other
cases, the problem cannot be “locally contained” and modifications across many functions
are required. Consequently, the supply-chain management system must coordinate the revision
of plans or schedules across supply-chain functions. The ability to manage the tactical
and operational levels of the supply chain so that the timely dissemination of information,
accurate coordination of decisions, and management of actions among people and systems
is achieved ultimately determines the efficient, coordinated achievement of enterprise
goals.
Design issues for a multiagent supply-chain system
Which are the most important issues to address, to effectively build an agent-based software
architecture for the supply chain? The first issue we face is deciding how supply-chain
activities should be distributed across the agents. Existing decompositions, as found in
MRP (Material Resource Planning) systems, arose out of organizational constraints, legacy
systems, and limitations on algorithms. For example, the distinction between master production
scheduling and detailed scheduling is due primarily to algorithm limitations. The
merging of these two functions and the inclusion of some activities found in inventory management
and activity planning becomes possible with the availability of more sophisticated
planning and scheduling algorithms. With more sophisticated planning, scheduling, and
coordination methods, we can build better decompositions, improving the overall quality
of supply-chain management.
The Agent Building Shell
Given the complexity and difficulty of the issues just reviewed, how should we approach the
construction of a software architecture able to address these concerns? Our answer is that
many of these concerns can be addressed in generic and reusableways by means of an Agent
Building Shell (ABS) (Barbuceanu and Fox, 1996a). The ABS is a collection of reusable
software components and interfaces, providing support for application-independent agent
services. Using these services, developers can build on a high-level infrastructure, whose
abstractions provide a conceptual framework that helps in designing and understanding
agent systems; eliminate work duplication; and offer guarantees about the services provided
by the tool.
Figure 1 shows the current architecture of the ABS. At the outermost layer, communication
services allow agents to exchange messages composed from domain-independent
communicative acts and domain-dependent content specifications. The next coordination
level provides a full design of a coordination language (COOL) based on the conversation
metaphor. Conversations can model peer-to-peer interaction in which autonomous agents
make requests, volunteer information, react to events, update their state, and so on. Conversations
express the shared conventions that stand at the basis of coordination (Jennings,
1993) and are used as the basic abstraction for capturing the coordination knowledge and
social know-how discussed by Fox (1987) and Jennings (1992). The shell provides a full
conversational ontology, containing conversation plans, conversation rules, and actual conversations,
in terms of which complex interactions are described.
Synchronized conversation execution.
Normally, one conversation may spawn another
one, and they continue in parallel. When we need to synchronize their execution, we can do
that by freezing the execution of one conversation until several others reach certain states.
This is important in situations where an agent cannot continue along one path of interaction
unless some conditions are achieved. In such cases, the conversation that cannot be
continued is suspended, the conversations that can bring about the desired state of affairs
are created or continued, and the system ensures that the suspended conversation will be
resumed as soon as the condition it is waiting for becomes true.
Control architecture. Each agent operates in a loop where (1) events are sensed, like
the arrival of messages expressing requests from other agents; (2) the current situation is
evaluated, updating or creating new beliefs or adding new conversations to the agenda; (3)
an agent selects an entry from the agenda. This is either a newly requested conversation,
for which a conversation plan is retrieved and initiated, or one that is under processing, in
which case its execution continues incrementally.
Supply-chain applications
This section talks about two supply chain applications. In the first, we design coordination
structures to handle the dynamic formation and operation of teams. This example is relevant
for the virtual enterprise approach to manufacturing. The second application captures a realistic
supply chain and uses our approach to design and implement a number of coordination
mechanisms that account for both the steady-state behavior and, more interestingly, the
coordinated behaviors that can be applied to cope with unexpected events that perturbate
the operation of the supply chain.