![](bg2.png)
process. When, for example, the cargo leaves the
shipper (customer) and becomes the responsibility of
the carrier (transporter), the later becomes the active
controller of the process, while the former becomes
an observer who wants to keep track of status of the
process.
Inter-organisational processes such as cargo
transport and management have been the target of e-
business technologies and systems such as EDI and
EDIFACT for the best part of the last three decades.
More recent e-logistics systems are XML based and
provide Internet and web based services for freight
transportation and management.
The problem that such systems face is that they
represent the interests of a single stakeholder. Even
when such systems provide interfaces to the other
stakeholders through portals, APIs, or web services,
such interfaces are controlled by a single
stakeholder, usually a large transport service
provider. Even community oriented cargo
management systems are also effectively limited in
this respect, because it is difficult to accommodate
every potential stakeholder in the cargo management
process.
The cargo business is characterised by a large
number of smaller operator companies and by the
lack of global IT standards. Multiple systems,
interfaces and protocols must therefore coexist and
interface with each other. A truly universal cargo
management infrastructure can only be built on the
principles of decentralisation, and peer to peer
relations rather than on (portal or other based)
centralised architectures.
Below, we identify requirements for a cargo
management infrastructure and classify them across
the categories of identity, context, and security/
privacy.
2.1 Identity
One of the main problems in cargo management is
associating a single identifier with the cargo
throughout the transportation process, and making
such identifier available to everyone authorised. This
identifier is the connecting link between the physical
(cargo) world and the information system world. As
in other e-business/ecommerce applications, identity
management is therefore a key part of effective
cargo management.
Cargo often undergoes physical changes as it is
moves through different locations and means of
transportation. It can for example, be repackaged or
moved to different load units such as tanks (liquid)
cargo or containers (dry cargo). A cargo
management infrastructure must associate an
identifier with the cargo it identifies, and persist that
identifier for any desired period of time, regardless
of changes to the cargo, its attributes, or its location
on the transport chain.
Proposals for such identifiers exist, for example
in the form of GSIN (Global Shipment Identification
Number). GSIN is the GS1 organisation’s
Identification Key, used to identify a grouping of
logistics units that comprise a shipment from one
consignor to one consignee (buyer) referencing a
despatch advice and/or Bill Of Lading
(www.gs1.org). Identifiers such as the GSIN can be
implemented as bar codes, or included within
messages used in EDI and other logistics systems.
The problems however with approaches like this
is that they require all parties systems to conform to
the same encoding format. Also, such identifiers do
not satisfy privacy requirements, as the identity of
the sender or recipient can be inferred from the
cargo identifier. Finally such identifiers do not
convey other information about the cargo such as
status/context, nor they indicate a way as to how
such information can be obtained.
Thus, we establish the requirement that a cargo
identifier needs to act as a direct key to an
information source, e.g. a record, file, document etc.
that contains cargo information. By ‘direct key’ we
mean that there should be no need to obtain
additional keys to access cargo information. Instead,
the cargo identifier should yield access to the values
of cargo properties and context variables (see next
section).
As said above, a problem with cargo
management is that cargo can change its physical
characteristics as it is moved between different
containers or gets repackaged. The ability for an
identifier to persist independently from the loading
unit containing the cargo is therefore essential.
2.2 Context
Cargo can be described by static properties (attribute
variables) and dynamic properties that comprise its
context. Cargo attributes are fairly static through the
life of the cargo and include properties such as
product code, description and values for its physical
properties such as dimensions, weight etc.
Cargo’s context is all the other entities that are
associated with the cargo at some point in time.
Since this set of entities is potentially enormous, for
practical purposes, we need to restrict it to a more
manageable subset that consists of other uniquely
identified entities. Effectively then, context is
TRACKING CLOUD ON THE INTERNET USING A CLOUD INFRASTRUCTURE
389