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

 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

Search for ”relevant”

Transport Services

TEP

Transport Service Provide

Offer Transport Services

TSD

Find ”best” sequence of

Transport Services

Negotiate conditions

(for each TS)

TSD

Negotiate conditions

TEP

Book Transport Service

(for each TS)

TEP

Order management

TEP

If no

sequence

matching

the TEP

was found

TEP

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