ParcelCall: An Open Architecture for Intelligent Tracing Solutions in Transports and Logistics

Carsten Pils1, Michael Wallbaum1, Birgit Kreller2, Jens Hartmann3

1

Aachen University of Technology, Department of Computer Science, Informatik IV, 52074 Aachen, Germany. Email: {pils||wallbaum}@i4.informatik.rwth-aachen.de
2

Siemens AG, Munich, Germany, email: birgit.kreller@mchp.siemens.de

3

Ericsson Eurolab Deutschland, Herzogenrath, Germany, email: jens.hartmann@eed.ericsson.se

Abstract - While many carriers in transport and logistics have tracking and tracing systems in place today, these are typically proprietary solutions. At the same time, supply chains are becoming more and more complex, involving multiple carriers and multiple transport modes. There is a high demand for accurate and up-to-date information exchange across the different carriers and modes of transport. In this paper we present the European project ParcelCall. The objective of ParcelCall is the development of an open and standardised architecture for seamless tracking and tracing across the entire logistics and transportation chain. Owing to its open and scalable system architecture, the ParcelCall system can be easily extended by adding new server components. A small trucking company can adopt the ParcelCall tracking and tracing services as well as a huge multinational integrator.

Introduction

Transport and logistics today have evolved into a high-technology industry. Distribution is no longer about moving cargo over road or via air from A to B, but is a complex process based on intelligent systems for sorting, planning, routing, and consolidation that supports faster transportation, different transportation modes, fallback scenarios in case of failures, value added services such as time sensitive deliveries and tracing of products throughout the supply chain or transport network. Many larger companies have developed solutions for delivering these services in order to meet the requirements of their customers and to improve their services. Smaller companies cannot afford these investments and are mainly active in the old pointto-point transportation market, or co-operate with the larger companies, using their respective systems. The companies that have the necessary information systems in place to participate in the market for high-end transport solutions normally offer their customers methods for tracing their consignments. Even though many customers would benefit from using this information in their own information systems, only few of them are doing this today because of the large investments in their systems required to adapt to the proprietary interfaces of the transport companies. Continuous information about the current position or status of transport goods (in the sense that the exact geographic position can be queried at any time) at a piece level is not commonly available today. Typically, this information is provided if at all at a vehicle or container level only. Existing tracking solutions are typically based on scanning bar codes at process or control points. Furthermore, very few companies have

199

GPS

RFID Tag Reader Reader

Mobile Mobile Logistic Logistic Server (MLS) Server (MLS)

Terminals

Tag

Public Access Goods Mobile Tracing Logistic Server (GTS) Server (MLS) Public Network Goods Goods Information Information Server (GIS) Server (GIS)

Logistic or Logistic or Transportation Transportation Provider Provider

Goods Goods Goods Goods Goods Tracing Tracing Goods Tracing Tracing Tracing Server (GTS) Server (GTS) ServerTracing (GTS) Server (GTS) Server (GTS) Server (GTS)

Figure 1: The ParcelCall Architecture true global or even European coverage. In daily business, products are frequently shipped by subcontractors of the transport company. If the subcontractor does not provide a point-topoint service, tracing is no longer possible. Only in a few cases do carriers exchange tracing information, but in most cases the costs for adapting the proprietary systems to each other are prohibitive. The objective of the European IST project ParcelCall [1] is the development of a new, unified information and communication plane, thus enabling seamless tracking and tracing across different operators and across different transport modes. The key idea is to provide common open (and ideally standardised) interfaces among all system components. Easy adaptation of legacy systems operated by the carriers to the new information infrastructure, is a key design criterion. The Paper is organised as follows: In the next section we describe the ParcelCall system architecture. Finally, we summarise our results in section 3.

System Architecture

Basically, the ParcelCall system consists of different servers and tag readers as depicted in figure 1. Each transport good is identified by a passive or active tag. While passive tags are only used to identify a transport good, active tags are equipped with an air-interface and sensors. Thus, actives tags are capable of sending alarm messages if certain environment constraints are exceeded. The identification information stored on a passive tag is read by a tag reader and transferred to a Mobile Logistic Server (MLS) inside the transport unit, i. e., container, trailer, freight wagon, etc. Using the tag reader and for example the GPS satellite

200

positioning system the MLS is aware of its current location and about the identity of the goods, which are contained in the respective transport unit. Furthermore, applying sensors located on active tags or attached to the transport unit, the MLS can check environment conditions. By using the public and wireless data communication network, this information is relayed to a network of Good Tracing Servers (GTSs) operated by the different transport and logistic companies. The network of GTS servers uses public communication networks (e. g., the Internet) as a low-cost communications backbone and makes tracking and tracing information available using unified interfaces. A Goods Information Server (GIS) serves as a gateway between the distributed GTS system and a multitude of mobile and fixed end-user devices, e. g., mobile phones, PDAs, or home and business PCs. 2.1 Passive and Active Tags

Passive RFID tags are available today at moderate costs, and can be easily integrated into labels with printed and bar code information. Due to the costs (compared with simple printed tags) and infrastructure requirements (printers, readers), this technology has yet to gain widespread acceptance for tagging of short life-cycle products and low value transactions. However, it is only a matter of a few years before it reaches the retail sector and gathers the momentum necessary to play an active role in global markets. Static RFID tags with limited data capacity and read-only access can already be printed using standard printers with special ink, without the need of integrating any hardware (chips). RFID tags with read/write capability and a capacity of a few hundred bytes are available as low-cost one-chip solutions. Complementing 1-D and 2-D bar code labels by RFID tags, i. e., passive transponders with limited functionality and data capacity, will enable automatic identification upon transhipping, without the need for manually handling the consignments and scanning the labels. As a further innovative step, ParcelCall will explore the technological issues of active Thinking Tags instead of passive RFID tags. These Thinking Tags, developed by the project, will combine active short-range communication capabilities with sensing, memory, and computing power. Key issues in their design will be low power consumption and low costs. Thinking Tags will offer opportunities far beyond the mere transmission of static identification information, such as: ! continuous measuring and monitoring of environment conditions (temperature, humidity) for sensitive shipments (e. g., food) at the level of individual pieces, ! active alerting of the owner of a shipment in case of an alarm, i. e., deviation from the planned transport route, inadequate environment conditions, etc., ! recording of the history (location, environment conditions, status) of a shipment in order to provide evidence in liability issues (e. g., for security transports). Subsequently, we assume that each transport good has a Thinking Tag. 2.2 The Mobile Logistic Server

Each transport unit has a Mobile Logistic Server (MLS) which keeps track of the goods within that unit. As mentioned transport units are for instance trucks, freight wagons, and containers. Containers contain transport goods or other containers, thus building up a tree hierarchy of transport units. Since each container might have a MLS, the transport unit hierarchy causes a MLS hierarchy as depicted in figure 2. Except for the top level MLS (root of the hierarchy tree) all MLSs communicate with their father MLS and their sons. Implementing this hierarchy tree has several advantages: First, as the this hierarchy corresponds to the carriers delivery plan the hierarchy approach allows validating the carriers

201

MLS0
ML ML Container 1 Container 2

Goods

Figure 2: The MLS Hierarchy plan. Second, in general communication peers are very close to each other (less than 10m range). Thus, the hierarchy approach allows for short range communication. From a MLSs point of view there is no difference between a tag or an MLS. In the remainder we call goods and transport units within a container just items. A plain MLS must only implement an item interface. Only a top level MLS must implement an item interface as well as a Goods Tracing Server (GTS) interface. Among others, intelligent tags and MLSs store a unique identifier, the items destination address, and constraints related to e.g. temperature, shocks, or humidity. If a threshold of one of the items constraints exceeds an event will be generated and passed to its father MLS within the hierarchy. The latter forwards the event to the responsible GTS. Finally, the GTS forwards the event to the carriers IT system (which reacts to the event) or a Goods Information Server (GIS). If a transport unit within this message chain has a control system (e.g. the control system of a refrigeration unit) the control system can register to its MLS to receive events. Thus, transport units can also react to certain events. This is of outermost importance as a transport unit, for instance a vehicle, might be disconnected from the carriers IT system and cannot receive instructions. Furthermore, only the transport units control system can take appropriate actions to certain events. Loading of transport units changes the MLS hierarchy. To keep track of hierarchy changes items are scanned while being loaded. As the carriers IT system plans the loading process in advance the ParcelCall system can check the loading procedure while scanning the items. Therefore, each MLS receives a list of contents from a GTS in advance of the loading procedure. While the items are scanned the MLS checks whether the item belongs to the received list or not. If an item is loaded which is not in the list of contents the local MLS sends an alarm message to the control system of the transport unit. When the loading procedure is finished the MLS notifies the responsible GTS that the loading procedure has been completed successfully. 2.3 The Goods Tracing Server

Goods Tracing Servers (GTS) are located in a carriers intranet. The GTS network is the backbone of the ParcelCall system as it glues the different ParcelCall servers and the carriers IT system together. A GTS comprises of two databases: a Home Database and a Transient database. The Home Database contains item information, e.g. the items current position, its expected time of delivery, etc.. The Transient database contains MLS hierarchies.

202

2.3.1

The Home Database

As it is required that the ParcelCall system must scale it is impossible to store information of each item within each Home Database. A GTS is responsible for a fixed number of top level MLSs (top level MLS cannot move). When an item enters the ParcelCall system for the first time it must be either registered at the GTS or at a MLS. The MLS forwards registration information to its responsible GTS. The GTS stores the item status information and the identification of the responsible top level MLS in its Home Database. Note that the top level MLS which is currently responsible for that item might belong to another GTS. In that case it is also necessary to store the identification of this GTS. Thus, the Home Database contains information of those items which have entered the ParcelCall system within the responsibility of the GTS. A GTS which receives information about a certain item which is not registered at its Home Database forwards this information to the responsible GTS. Note that each tag must store the ID of the responsible GTS. Having both the unique ID of a transport good and the ID of the responsible GTS it is straightforward to retrieve information about this transport good. 2.3.2 The Transient Database

The Transient Database contains several MLS hierarchies (one for each top level MLS). To request instant status information of a certain item, the request must be routed through the MLS hierarchy. Having the ID of the responsible top level MLS it is straightforward to retrieve the required routing information from the Transient Database. Note that the Transient Database has one entry for each item which is currently under control of the GTS. 2.3.3 The carriers IT system

Among others, the GTS has an interface to the carriers IT system. The carriers IT system provides delivery plans to the ParcelCall system which the latter uses to build up the MLS hierarchy. On the other hand the GTS provides status information as well as alarm messages to the carriers system. 2.4 The Goods Information Server

The Goods Information Server (GIS) provides customers status information about their transport goods. To this end a GIS connects to a carriers GTS to retrieve this information. Basically, the GIS processes the information received from the GTS network and presents it to the user in an appropriate format. For example the GIS might take a parcels geographical information and generate a map showing its current position. This information can then be presented in different markup-languages such as HTML or XML and sent to the user using different transport protocols such as HTTP or WAPs WTP. To retrieve information about a certain transport good a user authenticates to the GIS and provides the ID of the good as well as the ID of the responsible Home Database. Having both IDs it is straightforward to retrieve the information from the GTS network.

Conclusions

In this paper we presented the ParcelCall approach of an open architecture for tracking and tracing in transport and logistics. Therefore, we described the basic functionality of the different components. A major design issue of the approach is to provide common open (and ideally standardised) interfaces among all system components thus enabling seamless tracking and tracing across different operators and across different transport modes.

203

We believe that the European transport and logistic industry will greatly benefit from a unified architecture for the exchange of continuous tracing information. It will enable the deployment of new products and services and the improvement of existing ones.

References
[1] ParcelCall Homepage, http://www.parcelcall.com

204