CLOUD ARCHITECTURE FOR E-COLLABORATION

IN THE INTERMODAL FREIGHT BUSINESS

Bill Karakostas

Centre for HCI Design, School of Informatics, City University, London, U.K.

Takis Katsoulakos

Inlecom Ltd., Sussex, U.K.

Keywords: e-Freight, Transport co-modality, e-Collaboration, Cloud architecture.

Abstract: The term freight refers to goods transported using different transport modes (truck, rail, ship), while inter-

modality refers to the ability for seamless transfer of freight and information across the different transport

modes. Because of the nature of the freight business (large number of small players, geographical

distribution, complex regulatory regime, multiple standards, and IT heterogeneity) we propose that cloud

computing presents an ideal platform for e-collaboration in the inter-modal transport networks (e-freight).

This paper identifies Cloud based collaboration scenarios in e-freight, proposes a Cloud architecture for

e-freight and analyses its business and technical benefits.

1 BACKGROUND

According to (European Commission, 2001) “Co-

modality” is the optimal use of all modes (land, sea,

air) of transport singly and in combination.

Many current governmental, EU and industry led

initiatives focus on quality and efficiency for the

movement of goods, as well as on ensuring that

freight-related information travels easily between

modes. Such objectives require collaboration

between all stakeholders involved in freight

transport chains. Although such collaboration must

be enabled by legal and organisational frameworks

being in place, it is largely underpinned by IT. IT

system interoperability and integration can enable

stakeholders such as transport operators, shippers/

freight forwarders, customs and other government

administrations, to seamlessly exchange information

in order to improve the efficiency and quality of

freight transport logistics.

To achieve efficient use of the different transport

modes on their own and in combination (co-

modality), stakeholders need improved means to

strategically manage networks, plan shipments and

to control the implementation of such strategies and

plans.

In centrally managed transportation networks,

coordination is achieved through centralised

mechanisms such as portals and exchanges, under a

single control, typically that of a large organisation

such as a large freight integrator/freight forwarder,

who carries out administration, marketing, pricing,

billing and so on.

However, inter-modality/co-modality will

gradually encourage in the future decentralised

organisations to get together to form transportation

networks without any prior arrangements and

centralised control. Therefore, open collaboration

approaches, decentralised network and

communication structures, and dynamic flexibility in

forming and dissolving transportation networks will

become increasingly important in setting and

managing co-modal transport networks in years to

come.

Cloud computing has recently been receiving

interest from businesses due to its inherent and

attractive properties of per-use pricing and elastic

scalability of computing resources. The effect has

been a shift to outsourcing of not only the hardware

and software IT infrastructure, but also of its

administration, (open Grid , 2009). In this paper we

go beyond the discussion of the obvious advantages

of Cloud technologies for the freight sector, which

mainly relate to the virtualisation of its IT

267

Karakostas B. and Katsoulakos T..

CLOUD ARCHITECTURE FOR E-COLLABORATION IN THE INTERMODAL FREIGHT BUSINESS .

DOI: 10.5220/0003143502670272

In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2010), pages 267-272

ISBN: 978-989-8425-30-0

 2010 SCITEPRESS (Science and Technology Publications, Lda.)

infrastructure with the resulting technical and

economic benefits.

Instead, this paper focuses on the analysis of how

Cloud can enable the e-collaboration between

transportation network participants and support the

goals of co-modality.

In the remaining of the paper we discuss the

patterns for collaboration that occur in a freight

transportation chain, and we define Cloud

architectural characteristics that enable such

collaboration. Next, we identify the business and

technical benefits from the proposed Cloud

architecture. Finally, we identify different business

models (for example private versus public cloud and

cloud federation approaches) for deploying the

proposed solution to the freight sector.

2 COLLABORATION PATTERNS

IN E-FREIGHT

2.1 Types of Freight Organisations

There are several types of organisations involved in

freight /logistic chains falling under the following

categories (Freightwise, 2009):

1. Transport users: These are organisations that

procure transportation services, (this includes

exporters & importers and freight forwarders acting

on behalf of shippers);

2. Transport service providers. These are

organisations that provide transportation services,

and include hauliers, operators of trains, ships, port

terminals, and other logistics services;

3. Transport infrastructure providers responsible for

managing the transport infrastructure such as ports,

roads and rail lines;

4. Transport Regulators: these are regulatory

authorities, specifically customs, safety & security

agencies, police (immigration) and animal welfare

and associated organisations.

Consequently, there is a wide variety of IT systems

used by the above organisations including

• internal systems used for procuring, planning and

managing transport related activities (e.g. booking

services);

• community systems (e.g. commerce exchanges

for bidding on transport services);

• authority systems such as port systems used for

monitoring and controlling movement of ships and

cargo;

• and, finally, information services systems

offering for example weather, traffic and other

safety related information.

2.2 Collaboration in Freight Industry

Collaboration in the freight business is driven

amongst others by the need to optimise the

utilisation of transportation resources and to better

balance risks. Collaboration requires interoperability

amongst the above types of systems. However, the

interoperability problem is not a static but a dynamic

one, because of the following two types of

collaboration that occur in the freight industry:

• Type A collaboration across partners who have

worked together before and have established

agreements and long term alliances;

• Type B collaboration which is a more loose

cooperative network between organisations (that

includes authorities too) and therefore form a more

dynamic (on-demand) freight logistics network.

We expect that transportation networks will

adopt a layered model for business networking,

comprising of an inner layer representing long term

alliances linked to value strategies (Type A

collaboration), a number of intermediate layers of

progressively looser relationships, and an outer layer

comprising of 'on demand' services linked to

responsiveness strategies (Type B collaboration).

Each layer may be characterised by different quality

of relations and strategic convergence requirements,

and would therefore require different interoperability

strategies from an IT point of view. Therefore, in

practice, both Type A and Type B collaborations

need to be supported.

Type A collaboration can be supported by fairly

fixed system integration/interoperability solutions,

such as point to point connections using web

services or other middleware architecture. This is

possible, because the collaborating systems and their

interfaces/APIs are known in advance, and therefore

interfaces can be designed and implemented. These

are essentially static and long term interoperability

solutions.

Type B collaboration, however, is between

systems that have to discover each other and agree

the rules for interoperability at runtime.

Thus, the second type of collaboration requires

more loose coupling between the participants

systems and is the main focus of this paper.

Of course, type A collaboration can also be

improved with the use of Cloud technologies, by

moving part or whole of the integration middleware

KMIS 2010 - International Conference on Knowledge Management and Information Sharing

268

on the Cloud, and by utilising Cloud based

integration services. This will result in typical Cloud

derived benefits such as efficient utilisation of

computing resources and reduction in IT costs.

Type B collaboration leads more naturally to a

service oriented (SOA) solution. Dynamic

collaboration and coordination of transport chain

participants requires a service architecture,

comprising service registries and a service discovery

facility, to allow respectively the publication and

discovery of transport related services.

Service matchmakers are required to match

transport service supply with demand. A service

matchmaker must be able to understand concepts in

the service description, such as price and location,

i.e. the start point and destination of the requested or

offered service). Such capabilities go beyond the

abilities of conventional web services (i.e. WSDL

service descriptions) and into the realm of semantic

web services.

Ontologies are essential in service match making

and interoperability, as they serve to integrate the

different standards and formats that are used in the

freight sector and to achieve semantic

interoperability.

A Cloud architecture needs therefore to address

the problem of standard heterogeneity. For example,

there are several data and document standards

employed in the transport sector such as GS1, CEN,

UN/CEFACT, UBL/OASIS and others.

Finally, a Cloud architecture needs to address the

problem of dynamic interoperability of

heterogeneous systems such as port systems, internal

transport planning and operation systems, safety and

information systems for sea transport and others.

In the next section we explain how the

coordination and interoperability is manifested in

transport planning, execution and monitoring

activities.

2.3 Collaborative Transport Chain

Planning

In transport network planning, collaboration

involves all participants exposing their internal

resource availability, plans and other

requirements/constraints to other participants in the

transportation network, in order for a transportation

plan to be established, that contains an accurate and

mutually agreed plan of responsibilities, deadlines

and actions for transporting the cargo from origin to

final destination. A transport plan can undergo

several iterations during which it is usually

optimised in terms of duration and resources. At this

stage, costs and payments are also established and

negotiated. A Cloud approach to transport chain

planning needs to leverage service oriented concepts

to expose internal databases and systems of the

participants in a controlled manner. Internal booking

systems of shippers need for example to interoperate

with pricing systems of service providers. Such

operations need to be carried out according to the

security and other controls of the different

participants, as confidential data about the cargo

may not be revealed until the time is appropriate. In

some cases, even the identities of the participating

organisations may be kept confidential until

contracts are exchanged.

2.4 Collaborative Transport Chain

Execution

During this stage, information generated at any point

of the transportation chain must be easily accessible

by all interested parties. A Cloud infrastructure can

allow such information to be replicated across cloud

storage systems, and its existence to be notified to al

interested parties, through reliable event based

notification mechanisms. In this approach, the Cloud

can become a high performance message relay that

transcends the communication and other networks

used by the transport chain participants. A typical

Cloud application for transport chain execution is

meeting the mandatory reporting requirements as the

cargo carrying vessels arrives at different ports and

terminals. Cloud, for example, can be used to

implement the concept of Single Windows

(UN/CEFACT, 2005) which refers to the

streamlining of cargo and traffic information

exchange between authorities and between

authorities and other stakeholders. Services can be

deployed on the Cloud for 'one stop reporting',

allowing operators to submit a single report, which

is then relayed to all relevant authorities.

3 A CLOUD ARCHITECTURE

FOR E-FREIGHT

Based on the requirements for collaboration and

system interoperability in e-freight identified in the

previous sections, in Figure 1 we provide a

conceptual architecture for Cloud based freight

collaboration. Such architecture can be utilised by

the combination of several commercial and open

source Cloud technologies. Our aim is to define an

collaboration architecture for e-freight using Cloud

concepts that remain stable even when the

CLOUD ARCHITECTURE FOR E-COLLABORATION IN THE INTERMODAL FREIGHT BUSINESS

269

implementation technologies change. The

architecture diagram of Figure 1 shows the major

subsystems and components that comprise a

collaborative Cloud for e-freight. According to the

architecture, transport chain participants are granted

access to the Cloud by a set of

authentication/authorisation services. After been

authorised by the Cloud, they can advertise their

transport services (offerings) or transport service

requests, and participate in transport chains.

Exchanges are mechanisms for forming virtual

transportation networks within the Cloud, in which

participants can securely collaborate via message

based communications and document sharing.

Exchanges contain message queues, i.e. high

performance message Cloud middleware that allows

the store and forwarding of large volumes of

messages under defined QoS rules. Organisations

can subscribe to existing queues for publishing and

receiving messages (notifications) or they can create

their own queues. Queue subscription can be by

topic (e.g. for receiving notifications for requests for

a particular type of cargo or for a particular

destination point). Message queues are the

mechanisms for members of an established

transportation chain to communicate safely and

reliably with each other. As all queues are entirely

Cloud based, participants do not need to own any

middleware system as part of their internal IT.

The Process Choreographer allows the execution

of transportation processes such as plan, execute and

monitor. The Process Choreographer knows the

sequence in which messages must be exchanged in a

particular transport chain and enforces their

sending/receiving in a correct sequence. To enable

loose coupling, the Process Choreographer controls

only the interactions between the partners processes

rather than their internal processes. Thus, internally

the partners can implement any process management

system such as an ERP system, a process

orchestration (BPEL based) or other type of

Business Process Management (BPM) system. The

Process Choreographer service can operate as an

event machine or state based machine that interprets

notifications (messages) received by the message

queue during the execution stage of the transport

chain, or by updates to documents (for example an

update to freight delivery status). The Process

Choreographer responds to such updates by sending

new messages/notifications to the transport chain

participants, using the message queue mechanism

discussed above.

To disambiguate the content of messages, the

Process Choreographer utilises ontologies for

freight. Thus, with the use of ontologies, messages

are automatically converted to the format suitable

for the intended recipient. This ability supports the

goal of interoperability, by not forcing participants

to use the same document standard.

Finally, Document Storage in the architectural

diagram, refers to a distributed Cloud storage service

that allows simultaneous publishing editing and

accessing of documents pertaining to a

transportation chain planning execution. The storage

of such documents is distributed over the Cloud.

Access to a document's contents is through the use

of view mechanisms that allow controlled access and

modifications to a document's contents. This

approach also simplifies the task of interoperability

as it allows many participants to share and

collaboratively update the same document.

Figure 1: e-Freight Cloud collaboration architecture.

KMIS 2010 - International Conference on Knowledge Management and Information Sharing

270

Table 1: Business Advantages.

User needs and

expectations

How Cloud meets them

Customer satisfaction

A collaborative Cloud solution

should contribute towards

lowering the transportation

costs , service reliability and

performance, and therefore

ultimately towards improving

customer satisfaction

Improved operational

efficiency (e.g.

number of deliveries

per day)

The Cloud approach allows the

execution of a larger number of

transactions (higher throughput/

performance) compared to

architectures with fixed

numbers of servers.

Distribution of risks

amongst participants

A collaborative Cloud

architecture distributes

decisions and business risks,

rather than aggregating and

centralising them.

More accurate

payments to transport

service providers

The Cloud approach provides

reliable information about

actual service performance

during transport chain

execution.

Reducing the cost of

non-compliance (e.g.

avoiding fines for

non-compliance)

The Cloud approach automates

the compliance procedures (for

example reporting to

authorities) thus making it more

efficient.

Optimal utilisation of

transport resources

through the network

The Cloud approach allows

pooling of transport resources

(e.g. vehicles, containers,..)

and better sharing them

throughout the transportation

chain.

Transport network

optimisation due to

better horizontal

collaboration

between users and

providers

The Cloud approach can

optimise the network both

statically and in real time, due

to improved information

sharing and availability.

Reduction in lost

sales due to bidding

failures, e.g.

inaccurate bidding

The Cloud allows faster

notifications for bidding

opportunities to transport

service requests.

4 QUANTITATIVE

AND QUALITATIVE BENEFITS

OF E-FREIGHT CLOUDS

Based on the collaboration requirements and the

proposed Cloud architecture for e-freight, below we

identify potential business and technical benefits.

Some of these benefits (mainly regarding IT costs)

are fairly easy to quantify, while the impact of

business benefits is harder to assess and require a

case by case analysis using 'what if' scenarios and

simulations. We expect however that the business

benefits of the proposed Cloud collaboration will

typically outweigh the more obvious IT cost savings.

5 CONCLUSIONS

This paper has argued that Cloud computing

represents a suitable platform for e-collaboration in

the freight business. Cloud computing is currently a

rapidly changing area with many emerging standards

and business models (Vigfusson and Chockler, 2010).

Table 2: Technical (IT) Advantages.

IT requirements

and constraints

How a Cloud Solution

Meets them

Reduce operational IT

cost reduction

(hardware,

software license &

maintenance)

By migrating to the Cloud

part of the IT infrastructure

costs such as

hardware/software

purchase, licensing and

maintenance are reduced

Improve and simplified

communication

between shippers,

carriers and customers'

systems

By using integration

services provided by the

Cloud.

Dynamic pricing

algorithms based on

real time demand,

availability etc.

By improved availability

of real time information

throughout the

transportation network.

Balance system

performance during peak

demands.

By using the Cloud's

elastic resources, demand

peaks (e.g. in bookings)

can be handled more

easily.

Reduce incompatibility

information systems

used by members of

the transportation chain

Through the use of SOA

principles, loose coupling

(message queues) and

event based notifications.

There are many open questions as to the ideal shape

of a Cloud for e-freight, namely:

• The question of whether this should be a public

(open) or a private Cloud;

• What Cloud standards to use for its

implementation;

• What kind of interoperability with other systems

including other Cloud systems is required;

CLOUD ARCHITECTURE FOR E-COLLABORATION IN THE INTERMODAL FREIGHT BUSINESS

271

• The business model used for the Cloud, such as

who owns the Cloud.

The freight sector is characterised by a

community of private companies and government/

intergovernmental agencies covering wide

geographical regions and transport modes.

It is likely that under such conditions more than

one Cloud approaches will emerge. Cloud ownership

and control could mirror the current structures of the

freight industry, i.e. the centrally coordinated

networks, cooperative networks and more loose

cooperative associations that currently exist in the

industry. One or more of such Clouds could be

concerned with legal and compliance aspects of the

freight sector (i.e. to enforce standardisation and

compliance across the industry). Other Clouds could

be more commercial in nature, i.e. they would

represent the migration of the current e-freight

networks and alliances to a Cloud environment.

Thus, ownership and membership of the Cloud

could vary depending on the purpose of the Cloud.

Some of such Clouds could be owned and managed

by a single organisation such as a large freight

integrator/forwarder, or a governmental or

intergovernmental entity. It is possible also that non

freight companies such as IT service providers could

become responsible for managing some of these

Clouds.

It is reasonable to expect therefore, that Cloud

interoperability standards such as OCCI (OpenGrid

Forum, 2009) promoted by consortia such as Open

Cloud Manifesto, DTMF Open Cloud Standards

Incubator, Open Group’s Cloud Work Group) and

others, will become very important for the success of

the approach proposed in this paper.

ACKNOWLEDGEMENTS

Work reported in this paper was supported in part by

the Project e-Freight (European e-Freight

capabilities for Co-modal transport) under Grant

agreement no.: 233758, as part of the Seventh

Framework Programme SST–2008–TREN–1

(SST.2008. 2.1.5)

REFERENCES

European Commission, 2001. White paper – ‘European

transport policy for 2010: time to decide’. Available

from http://ec.europa.eu/transport/strategies/2001_

white_paper_en.htm

FREIGHTWISE 2009. Management Framework for

Intelligent Intermodal Transport Deliverable D13.2 –

WP13 FREIGHTWISE framework architecture,

release 2, 2009.

Open Grid Forum, 2009. Cloud Storage for Cloud.

September 2009.

UN/CEFACT 2005. Recommendation and Guidelines on

establishing a Single Window to enhance the efficient

exchange of information between trade and

government. Recommendation No. 33. Available from

http://www.unece.org/cefact/recommendations/rec33/r

ec33_trd352e.pdf

Vigfusson, Y and Chockler, G, 2010. Clouds at the

Crossroads. Research Perspectives Spring 2010/Vol.

16, No. 3 www.acm.org/crossroads

KMIS 2010 - International Conference on Knowledge Management and Information Sharing

272