Secure Trade Lane: A Sensor Network Solution for More Predictable and More Secure Container Shipments Steffen Schaefer IBM Hollerithstr. 1 80339 Muenchen, Germany +49 170 6323 090
[email protected]
ABSTRACT Due to globalization and especially with China becoming the world’s production center, global trade is strongly increasing. The vast majority of all goods are shipped in ocean-going containers. Secure Trade Lane (STL) is a solution for making container shipments more predictable and more secure. The solution comprises an embedded controller that is mounted on ocean-going containers, and a sophisticated backend communicating with the embedded controller and integrating all trading partners. Both components are tightly linked and couldn’t exist in isolation. In this paper we outline the rationale of technologies being used in this Sensor Network solution, and describe end-to-end architecture and key components. We share the key lessons learned and take a look at the future evolution of asset tracking and monitoring, in particular in transportation industries.
Categories and Subject Descriptors C.2.1 [Computer-Communication Networks] Network Architecture and Design – Distributed networks; C.2.4 [Computer-Communication Networks] Distributed Systems – Distributed applications; J.m [Computer Applications] Miscellaneous;
General Terms Algorithms, Management, Measurement, Documentation, Design, Economics, Reliability, Security, Standardization, Legal Aspects, Verification.
Keywords Secure Trade Lane, container tracking, sensor network, embedded controller, GPS, satellite communication, GPRS, ZigBee, EPCglobal, WCO, WSC, TREC, mote.
Copyright is held by the author/owner(s). OOPSLA’06 October 22–26, 2006, Portland, Oregon, USA. ACM 1-59593-491-X/06/0010.
1. INTRODUCTION Eighty percent of all world trade is traveling in containers to its point of destination, mostly aboard ocean-going ships. Location of the freight or quality of service of the transport is important information for the supply chain. Only 2-4% of all containers get inspected when entering a country, posing a severe security risk. Supply chain visibility and security together form a compelling business case for monitoring container shipments globally. The STL solution makes container shipments more predictable and more secure. The solution comprises an embedded controller that can be mounted on a container and a sophisticated backend, based on a Service Oriented Architecture, that can be integrated with trading partners across the entire transportation chain. IBM has developed this solution together with major partners in shipping industries over the past three years. The solution has gone through thorough testing and a variety of pilots, and is currently being deployed with innovative customers. This paper describes supply chain tracking challenges, the STL major components and the primary services implemented by STL. We will then summarize our experience implementing this system and describe future scenarios for goods and container tracking.
2. CHALLENGES IN TRACKING CONTAINER SHIPMENTS Improved supply chain visibility and enhanced security across all modes of transportation (ocean vessel, river barge, train, and truck) are key business drivers for STL To satisfy logistics companies, manufacturers, retailers, and governmental organizations a comprehensive set of requirements need to be
covered. To give just a few examples, container integrity (e.g. door openings) needs to be monitored continuously, container location must be determined with high accuracy, and alerts must be sent in real-time in case of an incident. Shipment data must be stored at the container traveling the world, but this data is very vulnerable and hence must be secured so that only authorized parties are able to read it. Battery life must last for months if not even years. And the solution of course must be as cheap as possible as the shipping industry is extremely price sensitive. Containers are ubiquitous and can be found everywhere from major ports to small side streets. An RFID-based solution which is dependent on installation of local readers at an infinite number of places is impractical.
3. SECURE TRADE LANE SOLUTION COMPONENTS Figure 1 depicts a highly simplified view of the major components of STL. It comprises the hardware components that are leveraged for capturing real-world information through the sensor network and forwarding it to backend applications and databases and eventually existing enterprise systems. The next section describes some of the major components in more detail.
3.1 TREC The device that captures the real-world data has been developed by IBM’s Zurich Research Lab and is called TREC - in short for ‘Tamper Resistant Embedded Controller’. It is mounted at a container door and comprises a set of sensors, processors, data storage, and wireless radio, effectively turning ocean-going containers into smart objects. The built-in sensors can detect door
opening, light, temperature, humidity, acceleration, position (through Global Positioning System), and more. Sensors are either built into the TREC, or can be detached from the TREC inside or even outside the container. The detached sensors are connected over wireless radio. The TREC filters, aggregates, and correlates the data collected by the sensors, and turns the vast array of collected data into information that is relevant from a business perspective. Sensor readings get logged to obtain a complete history of the container being monitored. Business rules get executed and alerts can be sent in real-time when the situation becomes critical. Some of the most interesting information is the location of a container throughout its trip. This is supported through predefined ‘geo-zones’ describing a planned route as a set of polygons or corridors in which the container should always remain. The geo-zones are stored on the TREC and correlated against the actual container position determined from the GPS. If a container is detected leaving a planned route or approaching a place of destination, alerts can be sent to inform security organizations, warehouse managers, or whoever else might be interested. The collected data can be extremely sensitive, and the TREC can also hold additional supply chain data such as a bill of lading describing the container’s content. In order to secure the data while it is stored on the TREC or sent to the backend, a Smart Card is used for controlling access and providing encryption. The Smart Card technology also provides the ability to separate data spaces, i.e. making one set of data available to trucker, a different set available to a customs officer, and so on. This category of small, low-power, and low-cost computers equipped with sensors and wireless radio is also referred to as a ‘Mote’ (short for remote) in the industry.
Satellite
TREC Sensor
TREC
Handheld
GSM/GPRS
Tracking Application
Wireless Router Tracking Database
Figure 1: Secure Trade Lane high-level Architecture
Enterprise Application (‚Legacy‘)
3.4 STL Backend 3.2 Handheld As the TREC has neither a display nor a keyboard or buttons, a handheld device can be used to configure the device or to access stored data. At container loading time, the handheld can be used to support mounting, configuration, and arming of the TREC. Throughout the container trip authorized parties (e.g. customs officers) can use a handheld to access the data relevant for them (and for which they’re authorized). Combined with integrated RFID or bar code readers, the exact container content can be recorded with a handheld (or an RFID portal).
3.3 Communication The TREC regularly ‘calls home’ transmitting its current position and the sensor readings of interest. Any kind of alert, such as an unexpected door opening, is sent to the backend (and from there to subscribed parties) in real-time. Both wide and short range radio are available for the TREC to communicate with the backend services. Wide range communication provides independence from locally installed readers. GSM/GPRS and Satellite connectivity is used to achieve global coverage. The GSM/GPRS network used in cellular phones provides coverage in most of the populated areas. This technology is well understood and comes at reasonable cost. However, in remote places such as in parts of the Chinese hinterland, the Australian outback, or secluded areas in the Americas and even Europe, there is no network coverage; and certainly not on the open sea. For such areas without GSM/GPRS coverage, satellite communication is the only option to achieve connectivity with the backend. Recently satellite modems that can be used in Motes have come to the market, and at the same time communication cost has dropped, making satellite connectivity an interesting alternative for global communication. Short range communication is provided in STL via ZigBee [6]. ZigBee is an open protocol defined by the ZigBee Alliance and based on IEEE 802.15.4 [3]. It is ideally suited for Sensor Networks as it is optimized for low power consumption and supports a large number of nodes (up to 65.000). Short range communication can be established between the TREC and the Handheld as described above, or between the TREC and an Edge Server. Edge Servers are low-cost, ruggedized computers without displays or data entry mechanism. For a container tracking solution they can be installed in ports, distribution centers and warehouses. They can act as wireless routers, bringing down communication cost significantly. In conjunction with entry bars, movement detectors, or camera equipment they can also act as intelligent nodes, for example at the gate of a container terminal.
The STL Backend is the intermediary between the TREC and enterprise applications such as route planning, order management, or booking systems. As such, the STL Backend plays a number of important roles. It is used to configure the TREC with the correct business rules and geo-zone information for a particular trip. It communicates with the TREC and receives the heartbeats and alerts. It filters, correlates, and aggregates the received data and forwards this data to interested parties. It can provide automated decision making. It notifies trading partners about incidents or delays. And it displays collected data to authorized users through a portal. The most important components are the following: •
The TREC Gateway performs all wide range communication to and from the TREC. It receives incoming GSM or satellite messages, validates them and transforms them into XML messages (MQ Series) so they can be further processed and forwarded.
•
The Correlation Engine has the responsibility to filter, aggregate, and correlate incoming data and to compile business sense out of low level real-world information.
•
The Business Rule and Geo-zone Editors allow a business user to specify events they are interested in. Business rule examples include temperature thresholds that shouldn’t be exceeded throughout the trip or the aforementioned geo-zones that can be edited on a map. Figure 2 depicts sample corridors in which the container must remain for a particular trip.
Figure 2: Geo-zone Editor •
The Notification Engine is able to forward messages as MQ or JMS messages if sent to an external system, or alternatively as email, phone text messages, or fax when directly addressed to a person.
•
•
The Tracking Portal provides detailed information about container shipments, routes, custodians, container seals, and a lot more critical information for the supply chain. A network of distributed databases with a Service Oriented interface, Discovery and Query Services. It will be covered in more detail in the next section.
In order to make the solution easily deployable, most of the above components are provided as a hosted service, where data privacy is not an issue.
4. SERVICES STL is implemented as a Service Oriented Architecture (SOA). In the first instance, three major composite services are implemented (depicted in Figure 3).
Container Tracking Services
Supply Chain Process Services
Container Information Services
4.2 Container Information Services Container Information Services (CIS) are a secure means of exchanging container-related data between trading parties. This data can include information concerning container content and manifest, location history and door openings, environmental data on shipment conditions (e.g. temperature or humidity), and much more. It is important to understand that the data provided by CIS is not limited to the data collected through TREC. Other relevant data can come from RFID Readers detecting container content, from warehouse management systems, order tracking systems, and so forth. CIS tie various data sources together and retrieve the data from multiple distributed databases ‘On Demand’ – at request time (rather than building up a large central database with all information). In conjunction with complementary supply chain information CIS unfolds into a very powerful platform providing answers to queries such as: •
Has a particular product (instance) been shipped and stored at required temperature conditions at all times?
•
What goods have been shipped or stored together in case the possibility of contamination exists?
•
Where in the world is a particular shipment that is awaited?
•
Where in some proximity to a given location can specific goods be found?
•
What dock workers or customs officers had access to a particular container?
Figure 3: Secure Trade Lane Primary Services Those services are ‘composite’ or ‘primary’ services, each comprising a set of finer grained services. We subsequently describe each of those composite services.
4.1 Container Tracking Services Container Tracking Services (CTS) are services for real-time and near-time tracking and monitoring of container shipments. Realworld information is captured using the TREC device, then filtered, aggregated, and provided to backend systems and databases. Business rules such as allowed temperature ranges or expected whereabouts (defined as ‘geo-zones’) can be defined for a particular shipment. Container Tracking Services monitor and correlate the incoming TREC data, and then forward events of interest to external systems and user groups. Collected data can also be augmented, e.g. the name of a location may be concluded from its position coordinates, the Universal Coordinated Time (UCT) of an incident detected by the TREC must be converted to local time, and so on.
Container Information Services are leveraging the EPCglobal network and EPCIS (Electronic Product Code Information Services) standards [2] currently under definition by EPCglobal. Those standards define interfaces, discovery services, security mechanisms and other infrastructure for capturing and querying supply chain data (and other EPC related data). The EPCglobal network, also called the ‘internet of things’ is the ideal backbone for tracking goods moving along a supply chain. It leverages the infrastructure from the internet to create an open standards, SOA based data sharing mechanism between trading partners.
4.3 Supply Chain Process Services Supply Chain Process Services (SCPS) provide business process integration and choreography between trading partners. The primary role is to provide an industry integration platform to which participating trading partners can subscribe and rely on, for secure mediation between all parties. One of the most important services is the facilitation of document exchange accompanying a shipment (as well as other trading documents), based on open standards. This business choreography between existing backend systems will enable the integration between customs organizations
across countries, the integration between businesses and customs for import/export, the integration between shippers and logistics companies, and so forth. Additional features beyond exchange of trading documents can be value added services for optimization of assets, load, or routes, forecasting, and so on.
5. KEY LESSONS LEARNED After development time of several years, the STL solution is currently being piloted with major players in transportation industries. During this development time we have learned some important lessons which are shared subsequently.
5.1 When building a Sensor Network solution, scarce resources and physics dictate design In order to make a Sensor Network solution really practical and ‘weave computing into the fabrics of everyday life’ computing devices need to ‘disappear’ – meaning they need to be small, highly usable, tightly integrated in existing processes, and so forth. In practice for STL, this meant that the TREC had to be as small and as light as possible, mountable at a container door in a manner that is fool-proof and secure, and require as little maintenance as possible. This last point and the fact that batteries can’t be recharged for several months had significant impact on solution design. Battery power in such a solution is extremely precious and must be used very wisely. A key rule when building Sensor Network solutions is that communication is much more power consuming than local computation. This has been one of the key points why business rules and geo-fences are transferred and get executed on the TREC. Thus, besides the regular ‘heartbeats’ every few hours, communication will only occur when an incident has been detected (out of temperature range alert, geo-zone change, etc.). The TREC determines locally when a message needs to be sent. To extend battery life time (up to a period of several years) the TREC has a dual-processor architecture, with one processor being hibernated for most of the time. A low power processor is attached to the sensors, monitoring defined business rules and only waking up the main processor when communication is required.
5.2 Selecting the ideal short range radio is essential As mentioned above, wireless communication is very power consuming; hence selecting the right communication techniques is paramount. For short range radio we quickly discarded wireless protocols such as Bluetooth or 802.11, as those would have used far too much power. Instead, we decided to use the ZigBee
protocol [7], which is based on IEEE 802.15.4 [3]. We found ZigBee to be the most suitable wireless protocol as it is optimized for low power consumption. The protocol supports an over-the-air data rate of 250 kb/s which is absolutely sufficient for this type of application, and covers a communication distance of 50-70 meters without power amplification. A ZigBee network has one network coordinator and can form a star, mesh, or tree topology. The protocol has built-in capabilities for forming an ad-hoc network which is an interesting feature for extending coverage in a busy container yard or when containers are stacked in a vessel. Although perfectly suited for Sensor Networks, ZigBee today still has some teething problems. Interoperability between software stacks from different vendors is still emerging, and profiles must be defined for specific domains for making its usage more standardized and interoperable.
5.3 Selecting the ‘right’ satellite communication provider is essential Satellite communication for machine-to-machine communication is emerging as modems are becoming smaller, cheaper, and specialized on data rather than voice. At the same time prices are dropping significantly, turning satellite connectivity into a real alternative for wide range communication. As with the short range radio, selection of the ideal wide range communication is critical. It is easy to make a bad technology decision with respect to satellite connectivity where there is little experience with their use in Sensor Networks. Satellite communication technology can be characterized by their orbit. Various types exist, most notably Geostationary, Medium Earth Orbit, and Low Earth Orbit satellite systems. As the name suggests, geostationary satellite systems are stationary relative to a point of the earth’s surface, as they revolve in the same direction and with the same speed as the earth’s rotation. As the distance to the earth is approx. 35.000 km, only very few (potentially less than five) satellites are required to provide global coverage. To minimise the number of satellites those geostationary satellites orbit across the equator covering basically all inhabited zones north and south the equator. From a usage perspective this means that the antenna of a mobile earth station (an intelligent device) should be directed towards the equator to achieve favourable results in terms of reliability and throughput. Low Earth Orbit (LEO) systems in contrast orbit in only 200 to 1200 km distance above the Earth’s surface. Because of their lower altitude they cover a smaller radius and thus require far more satellites (50 to several hundreds) to cover the globe with their network. Iridium, Orbcomm, and Globalstar are examples of this category.
We found LEO systems most suitable for Sensor Network solutions for various reasons. The distance between the earth and the satellite has impact on the required transceiver power as well as on network latency. Also, as containers can face any direction, communication is not dependent on the antenna facing the equator. For STL, the Iridium Short Burst Data Service is used for transferring alerts and heartbeats in real-time. It is designed to serve a range of applications that send data messages of 300 bytes or less.
5.4 Business Logic on Mote and Backend must be tightly integrated in order to provide meaningful information Although a Sensor Network wouldn’t exist without a Mote with its sensors and the wireless radio, the Backend is playing a crucial role in the end solution. The intelligent device and Backend must seamlessly complement each other in order to be most efficient. Neither of them alone would provide information meaningful for the business. In the context of STL, there are numerous cases where TREC and Backend are closely integrated to provide business value. As the TREC gathers very low level data it is the Backend’s responsibility to turn this data into information for the business. For example, the TREC can determine XY coordinates of the container at any time. Those mere XY coordinates straight from the TREC’s GPS would be not very meaningful for a user but instead must be augmented. The user is interested to know that the container has arrived at a particular port, is approaching a distribution centre, or to see a trace of the container movements on a map. In case of an incident – say an unexpected door opening or the measured temperature going out of a defined range – the TREC can send alerts in real-time to the backend. The Backend translates the optimized and compressed data into XML messages that can be forwarded, and it determines what organizations or individuals needs to be notified about the event, and through which channel – be it an MQ message, text messages, a person’s phone, email, fax, or similar. Recipient and communication channel can vary depending on location, time of the day, owner of the shipment and many more aspects – information which is far too complex to be known by the TREC. The configuration of the TREC at the beginning of a shipment is yet another example where TREC and Backend complement each other. In the absence of a user entry mechanism on the TREC, the user specifies through geo-zone and a business rules editor what events they want to be notified about, or what data shall be gathered. Only by defining valid geo-zones, downloading them to the TREC where they get correlated, can it be determined in real-
time, at reasonable communication cost, and extremely limited battery power when a container goes off-track.
5.5 Middleware can significantly reduce development efforts also for Sensor Networks As for any other computer system, the usage of middleware components can also drastically reduce development efforts for Sensor Network solutions. Where TREC, Handheld, and Edge Servers are involved the STL solution primarily leverages communications and messaging middleware. Application servers, portal servers, messaging middleware, databases, web services gateways, etc. were used where backend systems are involved and integrated. As this latter area is well understood, a few more words on the middleware on the front end will be illuminating. Over the past couple of years, powerful messaging infrastructure has been emerging that is specialized for pervasive computing and Sensor Networks. As real-world data is proving increasingly important and organizations strive to closely monitor and control aspects of their business at remote locations it is crucial to integrate such remote data into existing enterprise applications. This can be achieved by integration of messaging middleware on mobile devices or embedded system with existing messaging infrastructure on backend systems. As a matter of fact this means an extension of an Enterprise Service Bus into the real world, for which two de-facto standards can be leveraged: IBM MicroBroker is a publish/subscribe message broker ideal for hardware appliances or handhelds. It can perform most typical messaging related tasks, in example transform raw sensor data into XML formatted messages. With its small footprint of only 250 kB Java Byte Code it is executable in J2ME, J2SE, and OSGi runtime environments. STL leverages this product on the Edge Server and on handhelds to forward collected data to the ‘regular’ MQ MessageBroker. Secondly, MQ Telemetry Transport is an open and light-weight protocol which allows any device to easily communicate with enterprise applications when no Java Virtual Machine is available. The protocol is optimized for communication over low bandwidth, high cost networks, such as satellite connections. Clients have a very small footprint (around 30 kB) and can be in Java, C, or any other language. Usage of the protocol is royaltyfree and reference implementations can be downloaded free of charge from http://www. mqtt.org.
5.6 A single and central database is unacceptable for a solution involving so many parties The shipper of containerized goods is paying for improved supply chain visibility, and therefore owns the collected TREC data for their respective shipments. As mentioned above, information
provided by CIS is not limited to TREC data but includes other shipment related data from RFID readers, supply chain or warehouse management systems, import/export declaration systems, risk management systems, and more. A single central database from a data privacy perspective is out of the question for data concerning and provided by so many parties! The two fundamental principles that were defined for data sharing through CIS are (1) that ‘the owner of data can define whom they share the data with and under what conditions’ and (2) that ‘data doesn’t get moved unless it has to’. Those two principles, together with the principles of supporting an SOA and using open standards whenever possible, have pointed to the standards defined by EPCglobal. EPCglobal has proposed EPC Information Services and the EPCglobal network and is currently very active in defining standards specifically for transportation industries, through the Transportation Business Action Group. Concepts of EPC Information Services are sound and appealing. The EPCIS Data Definition Layer could be easily extended to hold shipment data including a Unique Consignment Reference (UCR) as proposed by World Customs Organization (WCO). However, the first EPCIS industry products are just emerging and their interoperability is currently being tested. For example, Discovery Services, Object Naming Services, and Query Services across multiple EPCIS are currently not that clear from the standard definition and are in fact in some areas still subject to Research. For this reason STL is built on IBM’s EPCIS implementation.
The corresponding Backend seamlessly complements the TREC. In absence of data entry and display mechanisms on the TREC, the Backend (in conjunction with the Handheld) is essential for configuring the device with the appropriate business rules and geo-zones for a specific container trip. The Backend receives incoming TREC data, and further correlates, filters, and aggregates, turning TREC data into information meaningful for the business. Supporting a Service Oriented Architecture, the STL Backend is an ideal platform for integrating trade lane participants. The STL Backend does not only provide TREC data, it also makes other shipment related data available - from RFID readers, supply chain or warehouse management systems, import/export declaration systems, shipping documents, and more. In such a networked and open environment, data privacy is becoming increasingly important. As a fundamental principle in STL, the owner of the data remains in control of their data. STL implements this principle by leveraging EPCglobal network concepts and other open standards that help ensuring data privacy and security.
7. REFERENCES [1] Container Handbook:
http://www.containerhandbuch.de/
[2] EPCglobal:
http://www.epcglobalinc.org/
[3] IEEE 802.15.4 http://www.ieee802.org/15/pub/TG4.html [4] MQTT:
http://www.mqtt.org
6. CONCLUSION
[5] World Customs Organization: http://www.wcoomd.org/
Secure Trade Lane is a Sensor Network solution for tracking and monitoring containers. With a Tamper Resistant Embedded Controller mounted on container doors and a total of more than 20 million containers travelling the world, STL literally enables a ubiquitous worldwide computing environment. We have started with ocean-going containers but basically of the concepts can be applied for tracking other kinds of shipments, such as air freight or conveyances.
[6] World Shipping Council: http://www.worldshipping.org/
For this kind of application short range radio is important to contain communication cost. However, devices with short range radio only are not practical, as an infinite number of readers would be required for tracking and communicating with the device. Instead, when global tracking is required and alerts need to be sent in real-time, a Global Positioning System to determine location and wide range radio with global coverage as provided through satellite are vital. To limit usage of battery power and communication cost, data collected through the sensors must first get correlated and filtered in the TREC before it is sent to the Backend. As shipment data is sensitive and highly vulnerable, the data stored on the TREC is protected through a SmartCard.
[7] ZigBee Alliance:
http://www.zigbee.org/
