AN AGENT-BASED APPROACH TO TRANSPORT CHAIN
MANAGEMENT
Paul Davidsson, Jan A. Persson
Blekinge Institute of Technology, Sweden
Andreas Jacobsson
School of Technology, Malmö University, Sweden
Keywords: Dynamic e-business collaboration, Virtual organizations, Collaborative business systems, Supply chain
management.
Abstract: A novel application of agent-mediated electronic commerce is presented. It concerns developing and main-
taining efficient and effective transport solutions. The suggested approach is inspired by the concepts of vir-
tual enterprises and breeding environments, as well as peer-to-peer technology. We discuss the requirements
of such an approach and outline a software architecture meeting these requirements.
1 INTRODUCTION
It is well known that collaboration is essential for
improved business processes and increased profit-
ability within supply chains in the e-commerce area.
Consequently, there is a need for increased collabo-
ration between transport chain actors, e.g. transport
users, transport coordinators, transport operators and
terminal operators, in order to achieve efficient,
cost-effective, and agile co-modal transport chains.
The proposed approach Plug and Play Transport
Chain Management (PnP TCM) focus on business-
to-business (B2B) interaction for developing trans-
port solutions, activity coordination, and business
transactions, based on the FREIGHTWISE frame-
work (FWF) outlined by Fjørtoft et al. (2008).
(FREIGHTWISE (Management Framework for In-
telligent Intermodal Transport) is a EU-funded FP6
Integrated Project with 55 partners from 14 different
countries. Its goal is to enable modal shift of cargo
flows from road to intermodal transport through im-
proved information exchange between all stake-
holders across all transport modes) The PnP TCM
approach is inspired by the more general Plug and
Play Business concept as introduced by Davidsson et
al. (2006), Jacobsson et al. (2006), and Jacobsson et
al. (2008).
The PnP TCM approach aims to:
increase integration of transport chains by mak-
ing information about transport services easily
accessible (partially by providing interoperability
between the ERP systems of the involved actors),
increase adaptivity and agility of transport chains
by providing a match-making functionality that
makes it easier for potential transport chain ac-
tors to find each other and negotiate over terms
of collaboration with potential partners, and
lower the entry barriers for small-sized compa-
nies to participate in highly integrated transport
chains by providing low cost open source and
easy-to-use software tools.
Moreover, it should ideally be implemented in a
completely distributed fashion, both with respect to
control and information, and it should be seamlessly
interoperable with relevant legacy ERP systems of
the participating actors. Figure 1 illustrates the PnP
TCM approach where each actor use the FWF (or
PnP TCM) software to set up and participate in a
transport chain. The FWF software has two types of
interfaces, one type interacts directly with legacy
ERP (Enterprise Resource Planning) systems, or
other relevant information systems, and the other is a
simple web interface, which may be particularly
useful for small enterprises.
175
Davidsson P., Persson J. and Jacobsson A. (2009).
AN AGENT-BASED APPROACH TO TRANSPORT CHAIN MANAGEMENT.
In Proceedings of the International Conference on e-Business, pages 175-182
DOI: 10.5220/0002234501750182
Copyright
c
SciTePress
Internet
FWF (PnPTCM)
software
ERP X interface
FWF (PnPTCM)
software
ERP Y interface
Transport User
Transport Service Provider 1
ERP
system
type Y
FWF (PnPTCM)
software
Web interface
Transport Service Provider 2
ERP
system
type X
Figure 1: An illustration of the PnP TCM approach with three participating transport chain actors.
There are four roles identified in the FWF. The
Transport User is anyone that needs to have cargo
transported. The Transport Service Provider is the
role that ensures the transport of the cargo including
the management of the transport services and the
operation of the transport means and handling
equipment. The Traffic Manager is responsible for
information regarding the infrastructure (static or
dynamic) related to planning and executing trans-
port. Finally, the Transport Regulator monitors that
all transport services are completed according to
existing rules and regulations.
To achieve interoperable and cost-efficient col-
laboration within transport chain management, these
roles are important when identifying the functional
requirements of the PnP TCM software. In the next
section, we will see how this can be achieved.
2 FUNCTIONAL SPECIFICATION
As indicated in Figure 1, we here focus on two roles
of the FWF, the Transport User and the Transport
Service Provider. Moreover, we concentrate on the
Planning phase as the two other phases, Execution
and Completion, concern more straightforward in-
teraction between the involved actors. A more de-
tailed illustration of the interaction between Trans-
port Users and Transport Service Providers during
the Planning process is provided in Figure 2.
At the beginning of the planning process, the
Transport User specifies its transport demands, re-
sulting in an initial Transport Execution Plan (TEP)
covering the complete transport from origin to desti-
nation. The TEP is initial, or preliminary in the sense
that it specifies the items that are to be transported,
the desired time and date of collection and delivery,
the origin and destination, and the condition of the
items during the transport (e.g., ambient temperature
conditions), but not which Transport Service(s) to
use. The next step is to find relevant transport ser-
vices that potentially can meet the transport demands
specified in the initial TEP. This is done by search-
ing among the Transport Service Descriptions (TSD)
published by the Transport Service Providers and by
selecting those that (at least partially) match the
TEP.
This set of TSDs then provides the input to the
next step, which is to find the sequence of TSDs that
satisfies the requirements of the TEP, and, if more
than one such sequence is found, the one that is
“best” according to one or more criteria, such as,
cost, reliability, environmental impact, etc. If no
sequence that satisfies the requirements is found, the
TEP needs to be revised, e.g. with respect to desired
time of delivery. When a sequence is found, it is
time to negotiate the detailed conditions for each of
the TSD with the corresponding Transport Service
Provider. This is done in terms of a TEP correspond-
ing to that part of the transport, i.e., for
ICE-B 2009 - International Conference on E-business
176
If no
agreement
reached
(for one or
more TS)
Transport Service
Demand definition
Transport Use
r
Search for ”relevant”
Transport Services
TEP
Transport Service Provide
r
Offer Transport Services
TSD
Find ”best” sequence of
Transport Services
Negotiate conditions
(for each TS)
TSD
1
TSD
2
TSD
3
Negotiate conditions
TEP
i
Book Transport Service
(for each TS)
TEP
1
TEP
2
TEP
3
Order management
TEP
i
If no
sequence
matching
the TEP
was found
TEP
TSD
TSD
TSD
TSD
Figure 2: The interaction between Transport Users and Transport Service Providers during the Planning phase.
each TSD in the sequence, a TEP will be produced.
And the sequence of TEPs will correspond to the
initial TEP covering the complete transport from
origin to destination. If no agreement is reached for
one (or more) of the TSDs, it (they) will be removed
from the set of potential TSDs and the finding of the
best sequence will be resumed. The final step of the
planning phase is to book the transport services (one
for each TEP in the sequence).
3 REALIZATION
Due to the large number of actors involved and their
different roles, we believe that there is a need for a
new type of software for supporting the FWF, build-
ing on concepts, such as, Internet communities, and
Virtual Enterprises, and technologies, such as, Peer-
to-Peer software, and Software Agents.
3.1 Conceptual View
In PnP TCM, we view transport chains as virtual
enterprises, which may be defined as temporary alli-
ances of enterprises that come together to share
skills or core competencies and resources in order to
better respond to business opportunities, and whose
cooperation is supported by computer networks
(Camarinha-Matos and Afsarmanesh, 2003). The
common business goal for the participants of a
transport chain is to deliver the goods to the final
destination in time. Another important concept for
PnP TCM is Internet community. Potential transport
chain actors dynamically join a PnP TCM commu-
nity by (installing and) executing the agent-based
PnP TCM software. To enter the community, an
actor needs to declare its address and other formali-
ties, as well as agreeing on an end-user license
agreement. A Transport Service Provider needs, in
addition, to provide a Transport Service Description
(TSD) for each transport service it provides. The
TSDs should be updated continuously so as to mir-
ror the current situation. The community is dynamic
in the sense that enterprises may (in principle) join
and leave the community at any time. The PnP TCM
community can be seen as a breeding environment
(Camarinha-Matos and Afsarmanesh, 2003) for
transport chains. A breeding environment represents
an association of enterprises that have both the po-
tential and the ambition to collaborate with each
other through an interoperable infrastructure. A real-
ized transport solution within the breeding environ-
ment is an agent-supported virtual enterprise.
The set of installed PnP TCM software agents in
a community can be viewed to form an artificial
society. Davidsson (2001) lists four types of artifi-
cial society structures: open, closed, semi-closed,
AN AGENT-BASED APPROACH TO TRANSPORT CHAIN MANAGEMENT
177
and semi-open artificial societies. The four catego-
ries balance the trade-off between important society
properties, such as, openness, flexibility, stability,
and trustfulness differently. In open societies there
are no restrictions at all for joining the society. In a
FWF setting, this may correspond to that all interac-
tion is performed in an ad-hoc fashion, e.g., TSDs
are published openly on the WWW and the Trans-
port Users need to find the offers through the use of
general WWW search engines, etc. An open society
supports openness and flexibility, but not stability
and trustfulness, and the opposite is true for closed
societies. In a FWF setting, a closed society solution
may be a completely centralized system in which all
information is stored and through which all interac-
tion between the transport chain actors is mediated.
In many situations, such as in breeding environ-
ments for transport chains, there is a need for socie-
ties that better balance the trade-off between the
society properties. We will therefore limit our dis-
cussion to the two intermediate categories.
An important actor in the context of artificial so-
cieties is the “owner” of the society, or environment
owner. By this we mean, the person or organization
that have the power to decide which software enti-
ties may enter the society, which roles they are al-
lowed to occupy, what communication language
should be used, the set of norms and rules that are
valid within the society, etc.
In semi-closed artificial societies, external soft-
ware agents are not allowed to enter. However, ac-
tors have the possibility to initiate new software
agents in the society, which will act on behalf of the
actor. In semi-closed societies, there is a (central)
physical environment, in which the agents (repre-
senting their owners) execute and communicate with
other agents. This requires that the actors’ agents can
access some level of mutual communication proper-
ties, which are included in the breeding environ-
ment. Semi-closed societies convey almost the same
degree of openness as semi-open societies, but are
less flexible. From a FWF perspective, they fail to
meet the requirement of a distributed solution. On
the other hand, they have a larger potential for im-
plementing important society attributes, such as,
security and trustfulness.
The main difference to semi-closed artificial so-
cieties is that, in semi-open societies, agents execute
locally on the clients individual computer systems.
However, another distinction is that the environment
owner is no longer in control of the agents even
though the environment owner still has the power to,
for instance, dictate the rules of engagement within
the society. In order to meet security-related re-
quirements, semi-open societies are equipped with a
gate-keeper, to which every agent needs to connect
before entering the society.
When analyzing semi-open societies, it is useful
to make a distinction between two types of such so-
cieties, those with a centralized and those with de-
centralized communication architecture. In the case
of centralized communication, the agents run on the
members’ own individual computer systems, but all
communication between the agents is routed via a
central server. In decentralized communication, the
agents run on the members’ individual computer
systems and all communication is conducted directly
between these end nodes. As the vision of FWF con-
sists of a distributed solution, a semi-open agent
society with decentralized communication seems
desirable.
3.2 PnP TCM Software Requirements
The concept of PnP TCM relies on an integrated set
of agent-based ICT-tools that support the creation
and management of transport chains. ICT-
infrastructures for business creation and collabora-
tion are particularly relevant to small-sized transport
chain actors. While allowing themselves to maintain
their business independence, they are able to reach
otherwise unreachable markets and to take advan-
tage of economies of scale with the support of ICT.
Thus, the realization of ICT-based collaboration
support is envisioned to boost transport chain man-
agement.
A PnP TCM community requires certain general
functionalities. One example is the gate-keeper facil-
ity that regulates the entering (and leaving) of the
transport chain actors (and the software agents act-
ing on their behalf) and registers them as members
of the community. Moreover, a surveillance mecha-
nism that monitors the behavior of members may be
necessary in order to cope with malicious acts
(Davidsson et al., 2009). In addition, the gate-
keeper facility, being a trusted third party, may also
mediate the payment of transport services, contract
validation, etc. In the planning phase, there are a
number of functions that are helpful for the Trans-
port User in forming a successful transport chain:
finding potential transport services to be included
in the transport chain from a possibly huge num-
ber of offered services distributed through the
WWW,
finding the best path of transport services, ac-
cording to some criteria, from origin to destina-
tion out of the set of potential transport services,
ICE-B 2009 - International Conference on E-business
178
supporting the negotiations with Transport Ser-
vice Providers,
supporting contract design, and
supporting the transport booking.
When the planning phase is finished and a trans-
port chain (virtual enterprise) is formed, the PnP
TCM software should provide support also for the
execution phase, i.e., the management of the actual
activities within the transport chain. This support
may be on a quite shallow level, e.g., transactions of
information between actors, but may also support
and facilitate more complex coordination and syn-
chronization of activities.
As stated by Fjørtoft et al. (2008), only a limited
number of information types, or packages, need to
be supported. In addition to TSD and TEP, Trans-
port Execution Status and Transport Item Status
need to be exchanged between Transport User and
Transport Service Provider during the execution
phase. In the interaction with Traffic Managers there
are two additional packages that should be handled,
Transport Operation Status, as well as Network and
Traffic Status. These information packages need to
be transferred by the software agents in an efficient
and secure way in order to reduce the administra-
tional costs of the actors, as well as reducing the risk
of inaccuracy in information. In promoting security,
the gate-keeper functionality, with its guarding and
surveillance features, come well at hand.
In addition to the functional requirements pre-
sented above, there are some relevant non-functional
requirements that should be met, which could be
specified in terms of quality attributes (and meas-
ured using some metric). Based on interviews with
transport chain actors, we believe that the following
quality attributes are important for PnP TCM soft-
ware: scalability, flexibility, performance, cost, us-
ability, and security (which is represented by the
requirements of confidentiality, integrity, availabil-
ity).
3.3 Architecture
The choice of system architecture is closely related
to the system’s performance in terms of a number of
the criteria listed above. An extreme system archi-
tecture is a traditional client-server architecture
where all information, e.g., the Transport Service
Descriptions, is stored on a central server and all
communication is routed through this server. The
other extreme is a completely distributed architec-
ture where no information is stored centrally. In or-
der to implement a semi-open society, however, a
hybrid architecture seems necessary. For instance,
the gate-keeper facility is difficult to realize in a
strictly distributed manner as it assumes some au-
thorizing organization.
Compared to a centralized architecture, a distrib-
uted architecture supports many of the quality attrib-
utes, e.g., flexibility, scalability, and dynamicity.
Also, the risk of single point of failure may be
avoided increasing the robustness of the system. A
decentralized paradigm, for instance, built on Peer-
to-Peer (P2P) technology (Oram, 2001) may be
preferable for the PnP TCM software, because no
central authority determines how the participants
interact or coordinates them in order to accomplish
some task, and minimal use of central repositories of
information is needed. A pure P2P system does not
make use of the notions of clients and servers; in-
stead it uses the notion of peers, which function both
as clients and servers simultaneously. Moreover,
there is no central server or router managing the
communication. In addition, there are hybrid P2P
systems that have some central server functions,
such as, keeping (and providing) information about
peers in the network.
It is possible to distinguish between structured
and unstructured P2P systems. A structured P2P
system uses a globally consistent protocol for find-
ing relevant peers, using, e.g. distributed hash tables
like the Chord Protocol (Stoica et al., 2001). An un-
structured P2P system, based on, e.g. Gnutella (an
open protocol used by many P2P systems), a query
needs to be “flooded” through the network of peers.
Although many of the popular P2P systems are un-
structured, this flooding causes a large amount of
signaling traffic and therefore typically shows poor
search efficiency, and sometimes the query even
may not be resolved. Thus, to implement the search
for Transport Service Providers offering relevant
transport services, it seems as if a structured ap-
proach should be chosen. It is also possible to make
use of a slightly more centralized approach, where
the gate-keeper handles abstract (high level) descrip-
tions of the transport services that a Transport Ser-
vice Provider offers, for instance, “ship line between
port A and port B”, “truck transports in area C”,
“train transport in country D”, etc. It is assumed that
these high level descriptions do not change often.
When they are changed, the Transport Service Pro-
vider (through the PnP TCM software) may notify
the gate-keeper, who then broadcasts this informa-
tion to the Transport User PnP TCM clients. This
would make the search for relevant transport ser-
vices more efficient, at the expense of some over-
head communication.
AN AGENT-BASED APPROACH TO TRANSPORT CHAIN MANAGEMENT
179
Transport Service Provider software client Transport User software client
Information
package
repository
TSD
Finder
TEP
Manager
Optimizer
Negotiation
& booking
manager
ERP X
adapter
agent
TSD
announcer
TSD
Manager
Negotiation
& order
manager
Information
package
repository
ERP Y
adapter
agent
Figure 3: Possible architectures of PnP TCM software clients (with adapter agent interfaces).
A P2P infrastructure self-configures and nodes
can coordinate autonomously in order to search for
resources, find them, and interact together. P2P be-
ing a paradigm that allows building dynamic overlay
networks, it can be used in order to realize an envi-
ronment that manages a dynamic network of busi-
ness relations. Dealing with business-sensitive as-
sets, searching and retrieval of contents should be
made secure and trustable. This can be implemented
using, for instance, the gate-keeper facility and the
environment owner, which can govern interaction by
means of rules and regulation. The P2P infrastruc-
ture provides an environment in which every organi-
zation can make its knowledge and services avail-
able to other organizations while keeping complete
control over them. Each organization can autono-
mously manage this task without having to delegate
it to an external central authority that could be per-
ceived as less trusted than the organization itself,
and should be the object of an external (to the col-
laborating network) agreement between all the in-
volved organizations.
An important part of the PnP TCM software is to
find the best sequence of transport services. A large
number of optimization algorithms have been devel-
oped that can be applied to solve this task, e.g.,
based on Integer Programming (Wolsey, 1998).
From the users’ perspective, the complexity of
the process of setting up the transport chain should
be hidden by the PnP TCM software. There are thus,
at least, two types of interfaces:
1. A web-based interface, which can be used by all
types of users, independently of company size
and IT maturity. One version for the Transport
User, which consists of a number of different
views specialized for each of the phases in the
process, and one version for the Transport Ser-
vice Provider, also with a number of different
views.
2. An adapter agent interface, which makes the PnP
TCM software interoperable with the user’s ERP
or other legacy system. An adapter may have to
be developed for each ERP system, but once it is
developed it can be reused by other organizations
using that ERP system. One approach to imple-
ment the adapters is the general wrapper agent
solution based on open source freeware intro-
duced by Davidsson et al. (2005) that makes it
possible for any business system to exchange
(administrational) information with any other
business system.
To summarize, the different agents of the PnP
TCM software and how they interact are illustrated
in Figure 3. These agents have different degrees of
autonomy, from the quite reactive TSD announcer
agent to the quite sophisticated manager agents.
4 RELATED WORK
With respect to finding agreements through negotia-
tion, there is a long tradition in the area of agent-
based systems of studying this topic, for instance
ICE-B 2009 - International Conference on E-business
180
using the Contract Net Protocol (Smith, 1980) and
computational auctions (Rosenschein and Zlotkin,
1994). Within the negotiation area (cf. Jennings et
al. (2001)), four different components are relevant
for the PnP TCM setting, namely: a negotiation set,
which represents the space of possible obligations
that agents can make, a protocol, which defines the
legal obligations that the agents can make, a collec-
tion of strategies, one for each agent, which deter-
mines what obligations the enterprises will make,
and a rule that determines when the negotiation is
over and the deal has been closed. Negotiation re-
sults in an electronic contract, which govern the col-
laboration process. Electronic contracts are to be
regarded as virtual representations of traditional con-
tracts, i.e., “formalizations of the behavior of a
group of agents that jointly agree on a specific busi-
ness activity” (Cardoso and Oliveira, 2005). Elec-
tronic contracts usually have a set of identified roles,
obligations or prohibitions to be fulfilled by the par-
ties involved in the relation. PnP TCM software fo-
cuses on obligations, i.e., that an agent’s role is de-
fined by the obligation, which it has towards another
agent to bring about a certain state of affairs before a
certain deadline.
Several examinations on current state of the art
technologies useful for building ICT-infrastructures
with the purpose of collaboration within virtual en-
terprises have been undertaken (cf. Camarinha-
Matos and Afsarmanesh (2003)). Some common
conclusions are that multi agent technology consti-
tutes a promising contributor to the development of
support infrastructures and services. Internet and
web technologies, such as web services, represent a
fast growing sector with large potential in inter-
enterprise collaboration support. However, further
support in terms of supporting multi-lateral collabo-
ration is necessary. A number of emerging technolo-
gies, e.g., service-oriented architectures, enterprise
application integration, the semantic web, and count-
less collections of software standards (cf. the
ebXML framework) are likely to provide important
contributions. As a solution, it seems that Micro-
soft’s BizTalk Server, and similar solutions, are the
most sophisticated alternative for inter-enterprise
collaboration widely available. However, being a
centralized proprietary client-server solution it has
several disadvantages, such as, making the actors
dependent of a third party, being expensive, and
having possible risks for communication bottle-
necks.
5 CONCLUSIONS
Collaboration is one of the key building blocks for
improved business processes and increased profit-
ability within transport chain management. We have
suggested an agent-based approach to realize the
FREIGHTWISE Framework vision, which is as de-
centralized as possible while still having the ability
to provide means for handling issues related to in-
formation security and integrity. However, further
work will be carried out within the FREGHTWISE
project in order to validate the approach.
REFERENCES
L. M. Camarinha-Matos, and H. Afsarmanesh. “Elements
of a Base VE Infrastructure”, Journal of Computers in
Industry, vol. 51, no. 2, pp. 139-163, 2003.
L. C. Cardoso, and E. Oliveira, Virtual Enterprise Norma-
tive Framework Within Electronic Institutions, Engi-
neering Societies in the Agents World V, Lecture
Notes in Artificial Intelligence, Vol. 3451, pp. 14-32,
Springer, 2005.
P. Davidsson. “Categories of Artificial Societies”, Engi-
neering Societies in the Agents World II, Lecture
Notes in Artificial Intelligence, Vol. 2203, Springer,
2001.
P. Davidsson, A. Hederstierna, A. Jacobsson, J.A. Persson,
et al., “The Concept and Technology of Plug and Play
Business”, 8th International Conference on Enterprise
Information Systems, 2006.
P. Davidsson and A. Jacobsson. “Towards Norm-
Governed Behavior in Virtual Enterprises”, Intelligent
Agents in the Evolution of Web and Applications,
Studies in Computational Intelligence, Vol-ume 167,
Springer, 2009.
P. Davidsson, L. Ramstedt, and J. Törnquist, “Inter-
Organization Interoperability in Transport Chains Us-
ing Adapters Based on Open Source Freeware”, Inter-
operability of Enterprise Software and Applications,
Springer, 2005.
K. E. Fjørtoft, H. Westerheim, M.K. Natvig, J.T. Peder-
sen, T. Georgios, et al., “WP13 FREIGHTWISE
framework architecture, release 2”, 2008.
A. Jacobsson, P. Davidsson. “An Analysis of Plug and
Play Business Software”, Project E-Society: Building
Bricks (Proceedings of the Sixth IFIP International
Conference on e-Commerce, e-Business and e-
Government), Springer, 2006.
A. Jacobsson, P. Davidsson. “A Formal Analysis of Vir-
tual Enterprise Creation and Operation”, eds. Król, D,
and Nguyen, NT: Intelligence Integration in Distrib-
uted Knowledge Management, Information Science
Reference, 2008.
N. R. Jennings, P. Faratin, A.R. Lomuscio, S. Parsons, C.
Sierra, and M. Wooldridge, “Automated Negotiation:
Prospects”, Methods and Challenges. International
AN AGENT-BASED APPROACH TO TRANSPORT CHAIN MANAGEMENT
181
Journal of Group Decision and Negotiation, vol. 10,
no. 2, pp. 199–215, 2001.
A. Oram (ed.). Peer-to-Peer: Harnessing the Power of
Disruptive Technologies, O'Reilly, 2001.
J. S. Rosenschein, and G. Zlotkin, Rules of Encounter:
Designing Conventions for Automated Negotiation
among Computers, MIT Press, Cambridge MA, 1994.
R. G. Smith, “The Contract Net Protocol: High-Level
Communication and Control in a Distributed Problem
Solver”, IEEE Transactions on Computers, Vol. C-29,
no. 12, pp. 1104-1113, 1980.
I. Stoica, R. Morris, D. Karger, M.F. Kaashoek, H.
Balakrishnan. “Chord: A Scalable Peer-to-peer
Lookup Service for Internet Applications”, SIG-
COMM’01, ACM, 2001.
L. A. Wolsey. Integer Programming, Wiley, 1998.
ICE-B 2009 - International Conference on E-business
182