sits: a system for uniform intermodal freight transport information exchange

International Journal of Transport Management 1 (2003) 175–186

www.elsevier.com/locate/traman

SITS: a system for uniform intermodal freight transportinformation exchange

Eug�ene D€urr a, G.A. Giannopoulos b,c,*

a Utrecht University and Euformatics, The Netherlandsb Department of Civil Engineering, Aristotle University of Thessaloniki, 540-06 Thessaloniki, Greece

c Hellenic Institute for Transport, 57001 Thessaloniki, Greece

Received 3 January 2002; received in revised form 15 December 2003; accepted 8 January 2004

Abstract

Intermodal transport chains consist of many actors and it is inherently difficult for a user to obtain an insight on the real progress

of their transport at any moment or to interpret the consequences of a deviation. Based upon the results of a European Union

financed project a user-friendly and technologically advanced method is proposed for trip information and data, transfer and

analysis. This is based upon a ‘‘Transport Transaction data set’’, which includes as a ‘‘Management Summary’’ all essential data for

the transport: i.e. the information on the planned and real locations and times of the cargo. ‘‘Coupling’’ of several chains is foreseen.

The data is represented as a eXtended Markup Language (XML) document. This approach is less error-prone than the common

strategy of distributing individual status messages about transport events relying on each party to maintain an historical record and

drawing conclusions from it. The proposed system for Simple Intermodal Tracking and Tracing Solutions (SITS), is a typical

example of the information aggregation needed for the next generation of distributed transport information systems. The system

presented here has been developed and demonstrated in pilot form.

� 2004 Elsevier Ltd. All rights reserved.

1. Introduction

Intermodal transport chains are inherently complex.

Even the simplest chain which consists of two modes of

transport, requires the interaction and exchange of

information between eight different ‘‘agents’’ or ‘‘par-

ties’’ which are by definition ‘‘sources of information’’––

receipt or transmittal.

In this simplest case (see Fig. 1) one can identify: aconsignor and consignee, the pick-up and delivery road

carriers, the two intermodal terminals and the party

performing the non-road transport.

Finally there is the forwarder role of organising the

transport. The number of organisations involved can be

less, of course when one organisation performs more

than one role. However, the points of information

transfer––reception or modification––and use can be

* Corresponding author. Address: Department of Civil Engineering,

Aristotle University of Thessaloniki, 540-06 Thessaloniki, Greece.

E-mail addresses: [email protected] (E. D€urr), [email protected]

(G.A. Giannopoulos).

1471-4051/$ - see front matter � 2004 Elsevier Ltd. All rights reserved.

doi:10.1016/j.ijtm.2004.01.003

many and differing in degree of Information Technologyadvancement.

Also the data and sources of initial information most

notably for the location and status of the cargo along

its route, are many and vary in nature. It is therefore by

no means a small task to combine cargo or vehicle sta-

tus messages received from different sources, and often

in various formats, to one common format. It is quite

common for a user to consult several companies andservice providers in order to find out where his cargo

is. Even if the trace is successful with the help of some

‘‘in house’’ system, it is still difficult to interpret the

information and decide whether there is reason for

concern or not. Such an interpretation needs, apart from

status messages, also information about what should

happen, as compared to what was originally planned.

Interpretation and use of the data is also difficult, forexample in case of a delay the user has to judge whether

the cargo can catch-up later to the originally planned

arrival times or what the new estimated arrival time

(ETA) is.

Capability to harmonise all this information and the

way it is presented to the final user is an essential basic

mail to: [email protected]

Fig. 1. Roles in a typical intermodal chain.

176 E. D€urr, G.A. Giannopoulos / Transport Management 1 (2003) 175–186

step in devising common Internet based platforms for

Transport data and services provision which may be

made available to large number of users. When such

information is available, parties in the chain can use it to

facilitate planning and allocate future capacity (CEN,

1998).

This paper presents an innovative concept and theprototype software package that was developed in

order to demonstrate and test it, within an EU fi-

nanced study project called ‘‘SITS, for Simple Inter-

modal Tracking and Tracing Solutions’’. The main aim

of the study was to investigate the setting up of a

system facilitating the exchange of information and

data used in Intermodal Tracking and Tracing and

present them in a uniform way. More specifically themain focus of the work was to ‘‘propose a concept for

an inexpensive, user friendly, cargo Tracking and

Tracing solution that is applicable at National and

International level and focused on shippers needs’’. Of

related importance are also some later work performed

under project GIFTS (GIFTS, 2000; Ziliaskopoulos

and Waller, 2000).

Fig. 2. Data, informatio

2. Overall approach, definitions

2.1. Transport transaction concept

As already mentioned in the Section 1, in the opera-

tion of a complex transport chain the parties involved,

and the end users are in need of continuous and up todate information about the transport status. There are

(generally speaking) 4 stages that can be distinguished in

the whole chain of information provision (Fig. 2).

• Stage 1: Data collection. This stage is the one in

which the various data elements are collected regard-

ing the specific transport. In other words it provides

the content of the data transfer and transmission thataccompanies a certain transport. The ways and

means of collecting these data are many and vary

from the various Tracking and Tracing equipment

(Global Positioning System (GPS), or Global System

for Mobile communications (GSM), or satellite

based, etc.), to electronic tags, or more ‘‘manual’’

types of data entry into the computer, etc.

n, services chain.

Fig. 3. Transportation with samples.

E. D€urr, G.A. Giannopoulos / Transport Management 1 (2003) 175–186 177

• Stage 2: Data processing. Information provision

means that the (raw) data that have been collected

via the different means and methods are analysed

and otherwise processed in order to give meaningful

information. This is the Information Provision stage,

i.e. the stage in which ‘‘information’’ is generated

from raw data.

• Stage 3: Information dissemination. In this stage theinformation that is generated is ‘‘made available’’ or

otherwise disseminated to the many ‘‘actors’’ in-

volved in the transport chain as well as the end-users.

This is done through an appropriate service provider

and thus it can also be termed the Service provision

stage.

• Stage 4: Information use. In this last stage, the pro-

duced and disseminated information is now used bythe end-users for their various front office applica-

tions or simply for information.

The work presented here, addresses a satisfactory

solution to Stages 2 and 3 of the above list, primarily as

regards Tracking and Tracing information.

The basic concept and idea of the SITS system is to

provide an Internet based intermediary ‘‘informationdissemination’’ platform, which can process (partly or

wholly) and make available to the various interested

parties all the necessary information relating to the po-

sition and status of a particular transport. Once this

platform has been set up, a number of other applications

can be made which use this platform to offer a complete

‘‘Service provision’’ to the end users in the sense of stage

3 above (INFOLOG project, 1999).The central notion in the conceptual architecture of

the system is the Transport Transaction. This is an

‘‘object’’ that represents the complete transport action

information from origin point A to destination point B.

In this context the concept of a Transport Transaction

Data Object, represented in XML (TTData.xml) for

each transport unit (container, item or parcel etc.) is

introduced. Such a container object has a limited ‘‘life-time’’ and is created when the party playing the for-

warder role accepts the transport booking. At this time

the object is ‘‘filled’’ with essential booking details, like

pick up and delivery locations, addresses and cargo

description. Also the electronic identification (tag

number) of the (load) unit has to be supplied before the

transport starts, when Automatic Identification of

Equipment (AIE, radio-labels or bar-codes) is in place.During the transport preparation phase the object is filled

with details on the transport plan: which locations the

cargo should pass and when. During the transport exe-

cution phase the status messages from the various

monitoring points and/or the message stream from GPS

are added to the Transport Transaction Data Object.

Several TTData.xml documents can be combined into

one overall document if necessary. The resulting XML

document is used to present the progress to the user, (or

it may be used by other systems).

Since the introduction of such an overview ‘‘object’’requires a unified way of describing the transport route

and the activities along its path and since during trans-

portation the location of a unit changes over time, i.e.

the ‘‘location’’ is a continuous function of time, an

innovative way has to be found to represent all this

information and ‘‘unify it’’ so that such a continuous

function can be sampled in time or in location (Fig. 3).

This innovative method is based on transformationtables within which one can use location names as well

as coordinates. This is because the satellite based lo-

calisation systems produce, at regular time intervals, the

geographical coordinates while samples at fixed loca-

tions from beacon/tag based systems give the time of

passing the reader, together with actual reader location,

and they use location names instead of coordinates. In

both cases the discrete transportation description con-sists of a sequence of location, time pairs. All these have

been incorporated in the Transport Transaction Object

mentioned above.

2.2. Description of a journey

Based on the above principles of location–time pairs

we can describe a transport journey from origin to

destination as a combination of trips and visits. A trip

has a start and end location and as attributes the

modality, distance and average velocity. A visit repre-

sents a transfer location, such as a terminal, port orrailway station, where loading and unloading can take

place. A visit has an entry and exit location and as an

attribute an average waiting time (Fig. 4).

In this way an intermodal journey description starts

with a visit at the consignor location and a pick-up trip to

the intermodal terminal. From the departure terminal

several trips with visits in between form the route to the

destination terminal. At the destination terminal adelivery trip to the location of the consignee concludes the

journey. At the consignor and consignee location one can

use respectively only the exit and entry location of the

VisitVisit TripTrip

delivery

Visit

Corridor level 1

Visit VisitTrip

entry and exit location + time

Delivery TripCorridor level 0

pickupvisit

visit

TTData

Pickup Trip

Fig. 4. Visits and trips in a Journey.


visits. The route between the departure and arrival

intermodal terminal can be described at several levels ofdetail. One could start with one trip in between and

‘‘zoom in’’ to more detail to see the composed sets of trip–

visit–trip combinations. This takes place at the level of the

user interface. The full detailed view of the whole journey

is needed to present all incoming status messages.

3. Data structures

3.1. Real and planned times

The combination of above definitions results in the

definition of a journey as a list of locations (two for each

trip and visit) with a time on which the load unit is ex-

pected. Such a Planned Time Table consists of tablelines. A table line has a location name, a time and

optionally a time window. A similar structure is used for

the actual (or real) observations. Each received status

message is ‘‘summarized’’ into a location–time pair,

which is again added as a line in a Real Time Table.

Evidently an exit location of a visit/trip (and vice versa)

is the entry location of the next trip/visit and thus each

location appears twice. This difference must be keptbecause in general different organisations are responsi-

ble for the visit and for the trip and service contracts are

also based on such a distinction. For timetables only one

line is used for each location.

A warning system is introduced here that uses for a

certain location the planned time of ‘‘entry’’, its time-

window and the real (i.e. observed) time. When the time-

window expires and no real time has been received forthis location, a ‘‘no-show alarm’’ is raised. When the unit

arrives later a ‘‘too late’’ alarm is generated. When a real

time measurement is received before the planned time

minus the time-window, a ‘‘too early’’ alarm is raised.

This can be an indication of an erroneous route e.g. if

the journey is a circle.

The complete Planned timetable gives the planned

(called SOLLSOLL) and the real situation (called ISTIST) at anymoment in time. In case of a substantial delay the planned

times for the future can be changed to reflect the adapted

journey and a new estimated time of arrival (ETA). The

plan for past events should be kept as read-only to pre-

vent ‘‘history forgery’’. In any case the foreseen time ofarrival, as in the original plan, is kept as read-only, be-

cause this ‘‘historical information’’ is needed for possible

cost claims on delays against the original contract.

3.2. Transport transaction identifier

The different mechanisms used for identification of aload unit (item, or parcel) are usually a major problem

in any collaboration on a transport chain. Each party

uses its own way to identify an item for example: order

number, booking number, invoice item number etc. This

situation is inherently error-prone and not very efficient.

For an information sharing solution it is necessary to

have one unique number for each transaction. We call

this identifier the Transport Transaction Identifier, in

short TTId. The concept of the ‘‘Transport Transaction

Identifier’’, does not mean that each party involved has

to use yet another code for referencing a unit. By pro-

viding a translation table for each party from the local

identifier to the TTId and backwards, we let users use

their own numbering schemes. In other words no one

has to change his/her usual business processes. Simply

for each party a ‘‘local identifier’’ is stored in theTTData structure in an actors section.

To summarise, the primary access to the individual

TTData documents is through the Transport Transac-

tion Identifier, TTId. This identifier is unique over the

entire transport chain and over time. It is generated at

the creation of a Transport Transaction in a readable

format.

It is defined as:

TTId ¼ Location Name�Organisation name

� Time Of Creation

The time is measured in seconds, and the implementa-

tion should make it impossible to create more than one

TT in the same second at the same location (e.g. by a

built-in delay of one second)! The Server contains a map

(table) in which the TTId’s are coupled to the transac-tion data documents and its objects.

This central server will thus contain the mapping

from:


TTId () XML TTdata-document

The entire TTData object consists of several segments.This structure can be illustrated as in Fig. 8.

In this respect, it is to be noted that the server pro-

vides the following elementary functions:

• Create a TTData document, which also defines a new

TTId.

• Remove a TTData document with given TTId.

• Retrieve (get) a TTData document with given TTId.• Update a TTData document with given TTId, mainly

intended to add new tracking and tracing observa-

tions.

3.3. TTData set

The Transport Transaction data set contains several

sections, as shown in Fig. 8. Details of Pick-up/Delivery

and Load description section are given here.

3.3.1. Pickup and delivery

The PickUp/Delivery section details are:

Here the basic concept of trips and visits is used

again. At the consignor’s location only the exit part of

the visit is used. At the consignee’s location only the

entry part is used. The pick-up and delivery itself isdescribed as normal road trips. In the location descrip-

tions of the visits full addresses can be given.

Sub-entity Attributes Value

Visit Departure loc.

Time Departure time

Visit Arrival loc.Time Planned ETA

Trip Pick-up trip

Trip Delivery trip

3.3.2. Cargo description

The Load section contains details on:

UTIId UTIId Alphanumeric

TagId TagId Alphanumeric

UTIproperties Length (Meters/foot)

Widthmax_weight

Freetext

CargoDescr. Freetext

HazGoods Codes

CargoCondi-

tion

Cond. name Cond. value

The Tag Identifier is used in the SITS system for the

Load Identification. This is not the same as the Trans-

port Unit Identification (UTI) used normally for the

container or the vehicle. This may not be the case in

many actual situations (e.g. when hiring equipment).

SITS is therefore primarily directed towards monitoring

the cargo and not the container unit or vehicle or the swap

body. This in itself is a major innovation and breakthrough

which (it is hoped) will be further utilized in the future.

The equipment position, (i.e. the UTI position) can

be obtained simply by maintaining the relation: TagId )UTIId. In this way any transport organisation can use

SITS to follow its equipment as well.

Also for the cargo description SITS uses a set of

‘‘conditions’’ like: temperature, shocks (in term of accel-

eration/deceleration g’s), radiation level etc. Because nostandard exists yet for the form of this information, the

final definition of the ‘‘conditions’’ parameter has been

left open for the time being. The value is denoted as a

pair of the ISO metric unit (�C, m/s2, rad or Rem, etc. . .)and its value.

4. Presenting the data

The structure and contents of the TTData object have

been described. This object is stored inside a server as an

XML document. Upon request, after authentication, a

user can ask the server for the full document and it canbe read in an Internet browser. The same procedure is

used for ‘‘Info applications’’ applications running at the

transport operators’ systems. In such a Business-to-

Business (B2B) situation the user interface will be re-

placed by parameter passing in a standard http request

and response protocol executed by the server (servlet).

The abundance of information on a transport activity

contained in the TTdata XML may ‘‘overload’’ the end-user and is not very attractive for a normal transpor-

tation user. One therefore has to include a number of

visualisers on this TTData.xml data set, in order to

present clearly the progress of the transport and some

important actual values like ETA. This visualisation was

called a TTDashBoard, because it resembles the dash-

board of a car with several meters and displays. The

‘‘TTDashboard’’, just as in a car, simply presents thedata that are transferred to it by their sources and there

is no way to change the incoming data. The dashboard

is implemented as a Java applet, which takes the

TTData.xml file as input. The use of the dashboard does

not require any installation at the client side; the

‘‘application’’ and the data are loaded from the server

upon request. This approach also facilitates easy main-

tenance: clients automatically use updates placed on theserver.

Fig. 5 shows a screen shot of a transaction visualisa-

tion through the TTDashboard applet. The ‘‘dashboard’’

Fig. 5. Transport transaction ‘‘DashBoard’’.


in Fig. 5 is only one example of visualisation. Severalrepresentations for groups of transactions have been

designed. The first example is the representation of a

multi-consignment. The user has defined earlier which

transactions belong to one group. The progress of the

group is then shown in one 3D picture (Fig. 6), based on

one XML document per cargo unit. At the lowest level of

detail for a transport Journey, the grouping may fall apart

and the physical transportation companies in the chaincan treat the units as single consignments.

If a specific point along the route is a Terminal, a

different visualisation application for a group of trans-

actions has been designed. For any point in time the

position of load units on a terminal can be shown. Be-

Fig. 6. Multi-consi

cause the real time table has the same structure as theplanned timetable it is quite easy to represent the ter-

minal situation for some time in the future. Such a view

allows peak loads to be anticipated long before they

actually occur, based on the plans in the system. The set

of relevant TT’s is obtained from the server side by a

search (XML-Query) for all TT’s which have in their

planned or real-time table an entry for the requested

terminal within the requested time limits (e.g. Waalha-ven, Wednesday, from 12 to 24H).

Evidently the authorisation has to allow for visibility

of the timetables of all relevant transactions by the ter-

minal organisation. Future developments such as mon-

itoring cargo temperature, door (un)locking etc. can also

gnment view.

Fig. 7. View of activities on a terminal.


be taken into account in the Dashboard representation

since the TTData set has a Load Condition section.

However, since no relatively stable set of proposals is

available yet on what kind of information can be pro-

vided with a commonly agreed data representation,

these items have been left out from the current SITS

reference implementation and the ‘‘Dashboard’’ inter-face definitions. Therefore, for the time being, the SITS

system focuses on the general location/time information

every T&T service can offer.

The ‘‘Terminal View’’ is given in Fig. 7.

Fig. 8. Logical structure of TTData.

5. Data protection

The entire TTData object consists of several seg-

ments. This structure can be illustrated as in Fig. 8.

Evidently there must be some access restrictions for

the Transaction data. These restrictions are applied to

enable authorized access, i.e. only the eligible parties canhave different levels of access to a certain TTData set.

Therefore the concept of ‘‘actors’’ is introduced. A

user is identified by the combination of his/her user

name and their organisation name. To this combination

a password is coupled. This enables people within one

organisation to share the same access rights, even when

they use different names (group concept). If needed the

organisation name can be extended with a departmentname. Then different access rights can be given at the

department level.

This access authorization function has been imple-

mented as follows:


• Access rights are divided into read and write of each

section of a TTdata set.

• In the TTdata definition an Actors section is in-

cluded. Here a Transaction owner is introduced and

a readers list.

• For each section: the consignment section, the load

section, the pickup-delivery section, the planned time

table and the real time table, a list of organisationnames can be provided.

• If a user belongs to an organisation in the list then he

gets access to these data sections to read their con-

tents. Otherwise empty fields are shown. In the worst

case i.e. when no Consignment section access is al-

lowed even the existence of a TTdata set is hidden

from the user.

The owner of a document has by default all access

rights, even the deletion of the transaction. The software

that has implemented the entire ‘‘security’’ and data

protection scheme allows for many further security

applications that can be added according to the

requirements of the specific clients or future applications.

Three storages are in use for the normal retrieval pro-

cedures for the transport users inside the server: theusersStorage, the TTData Store and the OrgRefStore. At

the creation of a transaction, these stores get entries

based on the contents of the TTData.xml file. Using these

storage structures the retrieval procedure is as follows:

• obtain user-name and organisation name (through a

login window),

• check pass word with usersStorage.

Then two possible selection methods for the TT’s are

shown:

• use of TTId’s in TTdataStore or,

• use local references translated by the system into

TTId’s through OrgRefStore.

When a user has requested a TTData XML docu-

ment, the server assembles a document with only the

sections for which he has read access. The other sections

remain empty. This very fine grain protection mecha-

nism at the lowest level allows for many different but

flexible security schemes.

6. Important elements of the proposed architecture

Given the complexity of the intermodal chains and

the fact that an end-to-end journey can consist of several

different sub-chains managed by various organizations,many and varied ‘‘status messages’’ are coming from

many different sources and in many formats. The sour-

ces and formats range from:

• electronic tags, smart cards etc. and their readers,

• Global Positioning Systems (GPS) data messages,

• barcode and other optical identification means like

video recognition,

• Electronic Data Interchange for Administration,

Commerce and Transport (EDIFACT) status mes-

sages,

• mode specific information systems (e.g. the Hermesfor the railways),

• input from manually created observation reports,

• faxes (hopefully via some standard format and read-

able by Optical Character Reading (OCR)),

• Global Navigation Satellite System (GNSS) based

services, etc.

All these sources have to be normalized before theycan be added to the SITS Transport Transaction data

set. We defined this result as a XML document: status.

xml, which contains:

• Identification code of the cargo unit (either Tag or

UTIId),

• location of the observation,

• time of the observation,• responsible organization (for information on specific

section of the ‘‘journey’’).

The ‘‘responsible organization’’ item is included for

legal purposes, i.e. when faulty messages lead to delays,

potential damage, and thus claims, the source (organi-

sation) of the message can be determined.

The SITS system handles all available status messagesin any format, to assemble an overview as complete as

possible. Therefore a translation mechanism was built in

order to ‘‘normalize’’ the different incoming formats

(and communication protocols) into a common general

‘‘status message’’ format, which as already said before

was defined as a XML document, the: status.xml.

7. Data collection modules

Our first and main objective is to provide location/time

information in a source independent way. In order to deal

with the differences in format as well as in the way theinformation is transferred to the SITS system, previously

mentioned, a separate ‘‘message layer’’ has been intro-

duced. In this message layer so called Data Collection

Modules (DCMs) provide the communication interface,

as well as the translation into the normalized format

mentioned before. So far Data Collection Modules have

been realized for tag readers, bar code readers and

EDIFACT (IFTSTA) messages. More will follow in thefuture. Part of the Functionality of the DCMs is to

handle the data transfer between the T&T source (service

provider) and the SITS system. Here mechanisms like

T & T Sources

readers& tags

GPS messages manual

EDI messages

GSM

status data collection

many formats

status.xml

Fig. 9. Role of data collection modules.


interrogation (polling) the source, or simply awaitingreceipt of a message, had to be harmonized to the func-

tionality and format of a given Tracing & Tracking

(T&T) source. The DCMs and the status.xml ‘‘transla-

tion service form the so called SITS ‘‘middle ware’’ layer

which has been kept as simple and fundamental as pos-

sible. The main objective was to provide location/time

information in a source-independent way. Specific

information related to the DCMs function within theoverall SITS ‘‘middle layer’’, is as follows:

7.1. Communication protocols

Internet (TCP/IP) based services and protocols like

e-mail, ftp, Java Messaging, CORBA, sockets, LAN file

transfer and file sharing, are all compatible and in use in

order to realize the communication needs.

7.2. Transformation rules

A major contribution of the SITS approach is the

definition of the necessary transformation rules used in

order to ‘‘normalize’’ any incoming status information

into the status.xml document (see Fig. 9). After such a‘‘normalization’’ the recording of the new observation in

the individual transport transactions can be performed

by the other layers of the architecture.

7.3. Bundling

In principle there should be one translation module

per T&T Service provider, i.e. any source of T&T

T&TSource

Commu-nication

Tran

Oth

Fig. 10. Sub-modules inside a

information. ‘‘Bundling’’ and re-use of code for similaractions is therefore included in the SITS architecture.

The problem of ‘‘unification’’ or ‘‘bundling’’ of all rel-

evant status information from different sources can be

divided into three parts:

1. Retrieving the status data from the source either ac-

tively or passively.

2. Translating the status data into a full status.xml for-mat. If information items are missing in the original

message, they will have to be retrieved from elsewhere

(other databases, tables etc.) or estimated.

3. Transferring the status.xml document into the

‘‘inbox’’ of the SITS server.

7.4. Keeping logs

In some special cases there may be a need to keep a

‘‘log’’ of all performed actions for instance for

accounting reasons. The three different activities for

logging described previously, can be sketched as in Figs.10 and 11. The activities and the functionality of the

three different sub-modules are described in the next

sections of this chapter.

Due to the open architecture, the actual implemen-

tation can be adapted to the needs and capabilities

for connectivity for a particular T&T Service pro-

vider. This means in practice that one or more of these

three sub-modules can either run on the systems of theservice provider, or on a dedicated system (gate way

function).

slation

er Sources

Transfer

SITSInbox

data collection module.

ClientWeb

BrowserWebServer

internet

Visualiser

ttdata.xml corridor.xml

name,id

SITS Storages

DataCollection

UnitsTracing&tracking

messageT &TService

Providers

documentlayer

document mgt

layer

message layer

Fig. 11. Data collection unit components.


7.5. Communication tasks

The front and back-end communication tasks will be

specific for each type of service provider. A number of

possibilities exist here. The remote control of a single tagor bar code reader can be put inside the communication

front-end if necessary. After such a normalisation the

other layers of the architecture can perform recording of

the new observation in the individual transport trans-

actions.

8. The implications for transport management and possi-

ble business models

The system proposed here and developed on a pilot

form, can have important (positive) implications for

Transport management. The following ‘‘scenario’’ is

envisaged.

The users first access via their own browser thelocation (URL) of the SITS server. Then at that moment

via the Internet, the SITS applets are loaded. Optionally

this can be done by using the same code as a plug-in,

which can be installed by the browser only once, thus

accelerating the access speeds considerably.

After the establishment of a server connection, the

user performs a login with the organisation name, the

user-name and a password. If the combination is cor-rect, the list of transactions is shown for which this user

has read access rights. Transactions are listed by the

SITS Transport Transaction Identifier as well as by the

transaction identifiers in use by the user’s organisation,

like booking numbers etc.

When a transaction is chosen, the actual transac-

tion data is returned in the form of a XML document

together with a set of fixed details for the route. Thevisualisers, to present the data on the user’s screen,

use these documents. One of these presentations is the

TTdashboard view. The server processes incoming

Tracing and Tracking messages from the various

participating T&T service providers and maintains

the Transport Transaction Data documents in real

time.

For each session a user gets the latest version.The system described above is designed as a com-

pletely distributed architecture. All exchange interfaces

are defined as XML documents and can thus be ex-

changed quite easily in many ways. The effort was to

design an ‘‘organization independent’’ solution. There

maybe chains in which one party has all the informa-

tion, but in other chains (or sub-chains) parties may not

be inclined to relay progress information to a big player.In such situations smaller companies (SME’s) can (even

for a part of their activities) set up a server in collabo-

ration and present their group to the users as one Virtual

Enterprise.

In this way SME’s can also benefit from providing up-

to-date progress information to their customers. Large

global companies already have this capability through

handling everything within their own in-house systems.The SITS concept can thus be realized at several

levels depending on who is running the servers for status

data, transport transaction data collection and for rep-

resentation.

Possible scenario’s that have been investigated are:

• One service provider (apart from the transport par-

ties) as a kind of Information Service Provider (ISP).• A combination of such ISP’s to cover a chain of cor-

ridors.

• A virtual company formed by some SME’s.

Any other combination can be realized within the

distributed SITS architecture to cope with organiza-

tional (and political) diversity in a real world situation.

The SITS architecture is designed to support ‘‘an openbusiness model’’. As an open architecture it is based on

the fact that all interfaces between the different layers


and thus all input and output formats are defined as

XML documents. The dtd’s are published on the SITS

web site. The architecture and the realization of a

‘‘reference implementation’’ are described fully in the

deliverables. A full version with demonstration trans-

action data, using Java Server Pages (JSP), Java and

Java storage mechanisms is running on the SITS web

site.

9. Conclusions and final remarks

The fully distributed architecture that has been pre-sented here, provides a simple and flexible ‘‘model’’ for

the ‘‘grouping’’ together of data, and information, that

describes a transportation chain (modal or intermodal),

and for disseminating it to all interested users of the

system. Data about the status of the Transport chain

may come from different sources and in different for-

mats. A translation mechanism is therefore been incor-

porated in the SITS system, to handle and translate allthe incoming data and assemble them in an overview

that is easily comprehensible by the users and as com-

plete as possible.

The SITS ‘‘architecture’’ achieves this, by introducing

the creation of a Transport Transaction Object for each

Transport Unit (container, parcel, etc.) represented in

XML format and called the TTData.xml, and also by

creating the status.xml document which contains allnecessary information. These ‘‘Objects’’ contain all the

necessary information fields that fully describe a par-

ticular Transport transaction and its status. They are

created when the transport itself is originated, i.e. with

the transport booking and exist throughout the lifetime

of the transport, being destroyed after its conclusion or

stored (if so wished) for statistical records.

Several TTData.xml documents can be combined intoone overall document that presents the progress of one

or a number of related transport chains to the user of

the system.

In relation to the innovatory notion of the TTData.

xml, a set of other equally novel ways of describing the

transport route that is being followed, the ‘‘trip’’ or

‘‘journey’’, as well as the format in which this infor-

mation is presented to the user has been proposed. Alsothe various data structures for the travel time informa-

tion, the cargo status, the route description, and the

various characteristic phases in the load’s journey (e.g.

pick, modal transfer, delivery) have been defined and

presented.

The question of data protection and security is ad-

dressed by forming a multi-segment structure for the

Transport Transaction data set, and introducing a re-stricted access system (via passwords identifying the

particular users and the extend to which they can access

particular types of information). When a user requests a

TTData document, the server ‘‘assembles’’ a ‘‘docu-

ment’’ with only the sections for which he has access

while the other sections remain empty. This ‘‘fine grain

protection’’ mechanism at the lowest level allows for

many different but flexible security systems to be further

applied if so wished.

In order for the SITS architecture and prototype

system to be meaningful it must be used widely and inany case (in the beginning) by a certain minimum

number of users that would represent a ‘‘critical mass’’.

A number of business models were therefore examined

and evaluated among which the following:

1. Existing Service providing Organizations can under-

take to set up the server and its applications and offer

SITS related services to users. These may be the someof the current ‘‘big players’’ who would primarily be

interested for developing the system for their own use

at least in the beginning but later on offering its ser-

vices to other users as well.

2. Many smaller companies could set up SITS servers

co-ops, link them in collaboration, and create a sort

of ‘‘virtual enterprise’’ offering their users the SITS

related services.3. Major freight Terminals such as ports, railway yards,

freight centres (by preference intermodal in nature)

could set up and operate the servers offering the cor-

responding services to the users.

The work reported here and the system developed

could be the basis for a number of applications in the

field of freight transport and logistics that will be fullycompatible with the possibilities offered by ICT (Infor-

mation Communication Technologies) and the Internet.

It will also enhance Freight Transport Management by

facilitating the monitoring and control of the Trans-

portation chain from the very beginning to the very end.

Acknowledgements

The SITS project was funded by the European

Commission, DG TREN June 2000, contract number

R98/98/sin001936-B6 792013.

The project consortium consisted of: Cable andWireless Communications (Coordinator) (UK), TRD

Int’l Transport Research and Development Interna-

tional (GR), TNO Institute for Infrastructure, transport

and regional development (NL), TFK Transportfors-

chung gmbh (GE), NEI Netherlands Economic Institute

(NL), EBSC Erasmus Business Support Centre (NL)

PTV Plannung Transport Verkehr (GE).

Prof. G.A. Giannopoulos was the project’s technicalcoordinator, while Prof. Eug�ene D€urr, was responsible

for the SITS system architecture design and the major

initiator of the entire SITS concept.


Presentations, deliverables and the demo are avail-

able via: http://www.phys.uu.nl/~durr/sits.

References

CEN, 1998. Technical Committee 278, Road Transport and Traffic

Telematics, Working Group 2 Freight and Fleet management

systems(1998). The Reference Architecture and Terminology: Part 1

High Level architecture and terminology (N124) and Part 2 Detailed

Architecture (N130). See also http://www.phys.uu.nl/~durr/HIFA.

GIFTS, 2000. Global Intermodal Freight Transport System. European

Commission project no. IST-2000-29364 DG INFSO.

INFOLOG project, 1999. Information technologies for the Logistics

chain management. EU DGTREN project no. 2035.98. User

Requirements Specification, INFOLOG Deliverable 1000.1, 1998,

System Architecture, INFOLOG Deliverable 2000.1, 1998, and

System specification, INFOLOG Deliverable 3000.1, EU 5th FP

project, 1999.

Ziliaskopoulos, A.K., Waller, S.T., 2000. An internet based geographic

information system, that integrates data models and users for

transportation applications. Transportation Research, Part C 8,

427–444.

http://www.phys.uu.nl/~durr/sits

http://www.phys.uu.nl/~durr/HIFA

sits: a system for uniform intermodal freight transport information exchange

Documents