SITMar Project: an Integrated Platform for Goods

Monitoring in Multimodal Transport

I. Zappia, P. Cianchi Negentis s.r.l.

Florence, Italy

G. Adembri, M. Gherardelli, D. Giuli University of Florence

Florence, Italy

F. Paganelli CNIT

Florence, Italy

Abstract— The SITMar project (Integrated System for

Maritime Transport) is an applied research project in the

maritime freight providing a set of innovative real-time services

for maritime surveillance and goods monitoring. SITMar services

are offered on an integrated platform. Specifically, in this paper

the system architecture and services for monitoring and tracking

of containerized goods during both terrestrial and maritime

transport are described. Performance of this system was tested

by means of a suitably implemented demonstrator.

Keywords—heterogeneous networks interoperability; platforms

and middleware for seamless services; goods monitoring; maritime

transport; RFID; data fusion; alarm management

I. INTRODUCTION

The Integrated System for Maritime Transport (SITMar) project [http://www.sitmar.net/] is an applied research project in the maritime freight, funded by the Italian Ministry for Economic Development, providing a set of innovative real-time services for maritime surveillance and goods monitoring on an integrated platform. It covers the entire process of transporting goods in containers, from departure to destination and enables continuous end-to-end shipment tracking and monitoring on both terrestrial and maritime routes. Two are the main areas of action of the project: goods monitoring and maritime surveillance [10]. In this paper we will focus on aspects related to good monitoring services.

At the current state of the art, systems for the continuous monitoring of the environmental status inside transported containers do not exist and the available solutions for goods monitoring do not operate in all transport phases but are restricted to just the phase of storage at the port terminal [3] or the maritime route [2] [4] [5]. The same limitations can be found in commercial devices used for the monitoring of some environmental parameters during a transport [6] [7] since they do not belong to a system that integrates maritime and terrestrial monitoring services with maritime surveillance services as implemented in SITMar.

The SITMar services, with reference to goods monitoring and tracking, cover multimodal transport (both terrestrial and maritime), for containerized freight. Goods are placed in SITMar compliant containers, equipped with multi-protocol active RFID technology and multi-sensor network for acquisition of some environmental parameters (e.g., temperature and pressure) and selected discrete events (i.e., door opening and light detection). Critical conditions during a

mission are reported as alarms to the system and managed in accordance with appropriate configurable policies.

The SITMar system exploits information coming from heterogeneous sources (e.g., goods status, radar tracks, intelligence reports, non-cooperative targets estimation) and leverages such information to build an integrated tactical picture effectively supporting the detection of possible threats.

Users that will take advantage of the SITMar services are:

Multimodal Transport Operators (MTO), the subjects in charge of goods transport from departure to destination. This type of user is interested in providing additional information to their customers about the transport and the status of goods.

Service end-users, the customers which entered into an agreement for transport of goods.

Ship owners concerned about transport safety in the maritime route.

“Security” users as land, maritime and port authorities which can benefit from an early warning in case of abnormal situations or danger.

This article is structured as follows: in Section II we describe the System Architecture with specific focus on its most relevant elements. In Section III we introduce a typical operating scenario paying specific attention to goods monitoring and alarm management. Section IV gives a description of the implemented test bed. Section V discusses achieved results.

II. SYSTEM ARCHITECTURE

To meet system requirements, we decided to develop a net-centric system built on a service-oriented architecture (SOA) infrastructure and with an event-driver architecture (EDA) approach for communication.

The SITMar system is made up of the following subsystems (as show in Fig. 1):

the SITMar Land Center (SLC) is the central control level and provides information services based on the integrated view of system resources;

the SITMar on Board Center (SBC) is the peripheral control subsystem for monitoring and management of

Fig. 1. Overview of the SITMar system architecture.

goods stowed in the ship. The SLC was developed to allow the management of a high number of SBC;

the Enhanced Traffic Services Platform (ETSP) implements the infrastructure for delivery of security and safety services in the context of maritime transport; it is a transversal control subsystem;

the SITMar Compliant Container (CSC) is a container equipped with instruments suitable to monitor environmental conditions of goods: SITMar TAG RFID (STR) comprising a multi-sensor network;

the Nodal Framework which includes SITMar Gates (SG) and SITMar Long-Range devices (SLR). The SG devices allow detecting the container transition through a controlled area (intermodal nodes as harbors and logistic centers). The SLR infrastructure includes the hardware and software components implementing the communication protocol with the RFID TAG of the CSC.

The SLR are part of the on board infrastructure and may also be present in those ports and logistic centers that integrate with the SITMar system.

SITMar was designed to interface with the Italian national system for integrated logistics and intermodal transport (UIRNet) [http://www.uirnet.it/uirnet/it/], which implements tracking services for road transport. The interaction with the UIRNet Platform allows SITMar to complete the offer of real-time services for goods monitoring along road routes on Italian soil.

A. SITMar Land Center (SLC)

The SLC plans missions, processes and integrates information from all the linked SBC subsystems and the ETSP, as well as from any external system operating at the intermodal node level (e.g., logistic centers, harbors, shipping companies).

The SLC is also responsible to organize received information in a shared documental pattern for fruition by users. The definition of sequences for message exchange, their format, routing and conversion policies, were carried according to the SOA-EDA architectural patterns to ensure interoperability among the SLC and external systems. With regard to the data flow, SITMar chose to adapt to the current trend which provides for the development of internet applications also for the logistics, thus implementing the use of XML protocols and Web Services [1]. SITMar is also able to operate with some messages of the UN/EDIFACT standard, which is specific for container management, since this standard is prevalent among operators in Europe [3]. To implement the SLC the NEGENTIS Enterprise Software Platform (in the following called NEGENTIS Platform) was adopted: based on both the Java Platform Standard Edition (Java SE) and the Java Platform Enterprise Edition (Java EE), the NEGENTIS Platform is an applications infrastructure for the Internet of Everything (IoE) able to integrate, from a process perspective, people, applications and devices in the context of distributed and net-centric systems. The “Net-centric Enterprise Architecture”, allows the integration of real-time management of operations and over-the-cloud business processes, and satisfies high reliability requirements through advanced policies of fail-over and load-balancing requests. A “Net-centric Enterprise Architecture” is a light-weight, massively distributed, horizontally-applied architecture, that distributes components and/or services across an enterprise's information value chain using Internet Technologies and other Network Protocols as the principal mechanism for supporting the distribution and processing of information services [11]. The architecture provides a set of “basic services” specialized in authentication management, authorization policies and transactional mechanisms, thus providing a uniform and consistent programming model for both front-end and back-end developers. Interoperability with existing external systems is supported through the specification of a framework for the rapid development of “adapters”. This framework uses an asynchronous messaging system for the production and reliable distribution of messages relevant for applications.

Modules to collect all the high-level data about the situation and manage the access to information according to user profiles were developed. The SITMar portal provides facilities and services that users can use to obtain detailed and updated in real-time information. A specific module is responsible for the dynamic presentation of the ongoing missions in the maritime phase on the Integrated Operational Picture (IOP), i.e. a Geographic Information System (GIS) map showing the actual position of active carriers and monitoring and maritime surveillance information of goods.

B. SITMar on Board Center (SBC)

The SBC is the peripheral control system, which includes various components implementing the on board goods monitoring services. Similarly to the SLC, the SBC has been developed as a net-centric applications infrastructure and is based on the NEGENTIS Platform. The platform offers a set of processes that interface with on board instruments by means of adapters and connectors. Specific applications allow the SBC

Fig. 2. SITMar interactions and reference scenario.

to implement various communication protocols with the monitored CSC, using SLR devices located in the hold. The SBC services allow: i) visualization of the CSC environmental parameters measured at regular intervals, ii) visualization of the CSC mission details, iii) visualization of monitoring data and iv) visualization and management of generated alarms. When the SBC is configured and all mission data are loaded, the SLC sends also the stowage plan by means of an EDIFACT/BAPLIE file [8] [9]; leveraging the information contained in this document, an operator can directly request monitoring data to the CSC which gave rise to the alarm and to adjacent CSCs, so as to better identify the event that triggered the anomaly.

The communication between the SBC and the SLC is achieved via the web service (transmission of alarms) and FTP (provision of reports) protocols.

C. SITMar TAG RFID (STR)

The TAG RFID used in the SITMar system is a multi-active TAG, configured to meet the various operational needs for monitoring containerized goods. It operates according to three distinct modes.

Passive RFID modality. This operation mode is typical of passive RFID, when the identification code associated to the TAG is reflected as a result of the proximity to a RFID Reader device. This feature is implemented at passage through access ways to ports or logistic centers (hub or harbor gates).

Spontaneous Transmitter. The TAG RFID periodically transmits information about the status of the monitored parameters. This feature is active during the whole mission.

Query Transceiver. The SITMar TAG implements a communication protocol that, as a result of a request by a SLR device, allows the reception of commands and configurations and the transmission of data from readings.

The STR integrates the active TAG RFID with a sensor network, which monitors two types of parameters:

Environmental parameters, these parameters represent the environmental conditions of the container:

Temperature;

Humidity;

Generic sensor, optional and configurable through a 4/20 mA input.

Discrete parameters, these parameters have a Boolean true/false value and describe particularly meaningful events:

Opened container door;

Light detection inside the container.

The monitoring system is configured for each specific mission using a configurable set of rules (monitoring policies), which defines thresholds and alarms.

III. GOODS MONITORING AND ALARM MANAGEMENT

The goods monitoring service proposed by SITMar is carried out continuously by suitable STR as long as the goods are inside a CSC. The data collected by the sensor network are transmitted spontaneously by the STR on a configurable periodic basis. Thanks to the characteristics of the STR multiprotocol transmitter, the acquired data are forwarded in real time to the SLC. In any case, data collected by the sensor network are stored also by the STR throughout the mission and can be retrieved at a later time if needed for instance to investigate an abnormal situation.

All data collected are analyzed by a specialized SBC component implementing a rule engine in order to generated alarms each time monitored parameters don’t match the monitoring policies assigned to each specific CSC; such policies are defined on the SLC when missions are created and configured and then loaded on the SBC together with other mission data. A SITMar mission is in fact associated with a specific CSC and contains information such as its route nodes, details on transported goods (e.g., name, description, category, physical attributes, hazard class) and monitoring policies.

Each policy defines the threshold associated to one of the available parameters and the severity level the generated alarm has to be associated with. The rule engine will use the policy to filter the huge amount of sensor-produced data in order to extrapolate only meaningful information: when the threshold is surpassed an alarm is produced.

Fig. 3. Alarm notification display on SBC web interface.

Alarm severity level is color coded.

A. Reference Scenario

For a better understanding of the interactions occurring between the SITMar components, this section describes a typical operating scenario relating to the multimodal transport of goods on board of a CSC as shown in Fig. 2. The assigned route comprises four logistical nodes: origin and destination hubs, departure and arrival harbors; the latter are equipped with SG and SLR, for CSC identification and monitoring during the storage phase at the terminal. For simplicity we consider only one SBC.

In the considered scenario we assume that a communication channel is ensured during the entire goods transfer, therefore monitoring data are available in real time to the SLC and to the users during the whole CSC mission.

On road routes the transmission of monitoring reports is performed via the UIRNet On Board Unit (OBU). Each SG notifies the SLC of the CSC arrival and departure from the harbors. The SLR devices placed along the terminal, supplies the communication channel between the SLC and the STR.

On board monitoring is preceded by a synchronization step, whereby the SLC communicates mission configuration data to the SBC. During the sea travel, the SBC collects monitoring reports from the STR through the SLR devices and forwards them to the SLC. The SLC processes the information from the various subsystems in order to enable the delivery of its services. The SBC receives from the SLC processed information of maritime surveillance and alarms management.

The SBC offers an interface that visually represents the status of each on board CSC in term of the monitored parameters and, in an appropriate notification area, promptly displays any generated alarm; the severity level of each alarms is color coded in accordance to the associated monitoring policy (as shown in Fig. 3). The on board operators are therefore notified of alarms in real-time and are able to inspect the problem performing focused queries to the alarmed CSC, and to the adjacent ones, without waiting the next spontaneous reading from the STR. Alarms with a particular severity level are automatically and immediately communicated to the SLC to trigger proper management actions.

The information of an active alarm on a CSC is also processed by the SLC monitoring logic, together with other information on the corresponding mission. Only after the SLC determines that the alarm comes from an abnormal state, instructions on how to handle the situation are sent to the SBC. The operator applies the appropriate procedures and his

involvement may also include a reconfiguration of the monitoring policy. For situations identified as critical by the SLC logic, alerts sending to remote operators (e.g., institutions, authorities in neighboring ports) can be set, so as to promptly notify the situation and call for possible actions.

IV. THE SITMAR DEMONSTRATOR

With the aim to validate and verify the compliance of the SITMar system with application requirements a simulator and a demonstrator were implemented. The former was employed to functionally test in a controlled environment the capabilities of all the developed modules; the latter was employed to test the effectiveness of the SITMar system in a more realistic set-up. Both the simulator and the demonstrator show how the system reacts automatically to abnormal conditions and creates an effective single integrated operational picture by aggregating information obtained from different systems and in different domains (i.e., tracking, monitoring and security).

As previously stated the SLC and the SBC are based on the NEGENTIS Platform. In addition to the components introduced in sections II and III, a set of other modules was developed in order to enable the scenario simulation. This section is deputed to the description of all the components constituting the simulation environment. Both platforms communicate with each other and with external parties through a series of different techniques which will be introduced and explained through the course of this section. Persistence is obtained locally thought the adoption of a MySQL database.

A. Per functionality overall analysis

The SLC is designed as a communication hub and as a data repository kept up to date consolidating data produced by sensing infrastructures installed in other systems (i.e., on board systems and external systems like UIRNet compliant vehicles or marine surveillance agents). Main functionalities are classifiable in the following categories:

SITMar NEGENTIS Platform processes. The platform offers specific business processes to complete various configuration and management tasks like: i) SITMar infrastructure configuration (e.g., locations, receivers, available routes and policies manipulation), ii) SITMar infrastructure monitoring (e.g., adapter and gate receivers status monitoring), iii) SITMar missions configuration (e.g., route plan, goods details, risk class and monitoring policies configuration) and iv) SITMar missions monitoring (e.g., goods tracking, monitoring data browsing and generated alarms management).

Integration with SBC. The platform offers specific business processes and adapters to enable data transfers to and from the SBC: missions data can be uploaded to the onboard station when needed; monitoring and alarm data produced on board are received periodically via FTP; finally, critical alarms can be directly forwarded at generation time.

Fig. 4. Simulator components.

UIRNet integration. The aforementioned business processes, used to consume monitoring and position reports, can process also UIRNet reports.

Simulation. The platform offers specific business processes and adapters to simulate various scenario aspects (more details are reported in section IV.B).

The SBC system main goal is to offer all the tools needed to follow SITMar missions evolution and effectively perform goods monitoring. Main functionalities are:

Integration with SLC. The platform offers specific business processes and adapters to enable data transfer: missions data can be imported from the SLC when new CSC are loaded on board; monitoring and alarm data produced can be transferred periodically to the SLC via FTP; finally, critical alarms can be directly forwarded at generation time.

SITMar missions monitoring. The platform offers specific business processes and adapters to collect monitoring data and infer alarms on the basis of loaded monitoring policies.

Simulation. The platform offers specific business processes and adapters to simulate various scenarios aspects (more details are reported in section IV.B).

To ensure a clear separation between different users and groups, the processes hosted on each platform were configured with well-defined access control lists (ACL).

The interaction between SLC and SBC is performed via two different communication techniques: web services (used for mission data loading and alarms forwarding) and FTP (used for data dumps download).

Specifically designed hardware devices consists of gate receivers (for the SLC) and long range receiver with integrated RFID simulator (for the SBC) communicating with the NEGENTIS platform thought specific adapters; the integrated RFID simulator was used to produce test monitoring reports without the need of actual sensing hardware.

To simulate a UIRNet data source, a number of processes and adapters were implemented; these components, provided by the SLC platform, generate data regarding the on road transport phases.

B. Per component in depth analysis

In this section we introduce the main components deployed on each platform (as shown in Fig. 4).

The SLC platform is equipped with:

UIRNet simulator adapter. This adapter simulates the UIRNet transport route sections. The adapter produces periodic reports containing tracking and monitoring information; this data is then processed by the platform analogously to what happens to data produced by the SBC.

FTP server adapter. This adapter supplies an FTP endpoint; through this component the SBC can transfer on board generated monitoring data and alarms to the SLC; the FTP protocol was adopted to permit the resume of the transfer in case of unstable connection.

SG adapter. This adapter enables the interaction with the SG receiver hardware components; it can receive tags passage records and also produces a periodic report about the receiver activity.

Alarm WS endpoint adapter. This adapter receives critical alarms directly forwarded to the SLC by the SBC. It’s implemented as a web service server endpoint wrapped in an adapter.

Mission WS service. This component enables interaction with the SBC in order to transmit mission plan data.

Viewer service. This component enables SLC operators to visually follow the missions evolution on the IOP and being informed of generated alarms in real-time.

The SBC platform is equipped with:

SLR adapter. This adapter enables interaction with the SLR receiver hardware component; has two primary uses: the first is to receive tags monitoring records; the second is to permit the control of the integrated RFID simulator to produce the desired monitoring records: for instance it is possible to edit the simulated tags temperature value to trigger the alarms generation pattern.

Rule engine adapter. This adapter implements a rule engine targeted at tags reports analysis; when, given a

set of monitoring policies, the measured values don’t match the imposed constraints, an alert message is generated and consequently processed by the on board infrastructure.

Alarm WS endpoint adapter. This adapter receives critical alarms directly forwarded to the SBC by the SLC. It is implemented as a web service server endpoint wrapped in an adapter.

Viewer service. This component enables SBC operators to visually follow the sensor readings from all the loaded CSC and being informed of generated alarms in real-time.

V. CONCLUSION

In this article we have presented the SITMar system, an innovative platform offering services for multimodal transport of containerized cargo in a seamless end-to-end flow by means of continuously updated awareness on the goods status during shipping for both maritime and terrestrial routes. Specifically, we focused our attention on services for goods monitoring allowing to check the occurrence of dangerous situations (e.g., burglary for the purpose of theft, dangerous goods spills, fires) and promptly activate actions, which may involve both ship personnel with specific instructions for the on-site management of the emergency, and authority staff.

We have presented an overview of the system architecture designed during the project and a typical scenario to exemplify the interaction flow envisioned among the components constituting the SITMar system.

Internally, a simulator has been implemented to functionally test in a controlled environment the capabilities of all the developed modules. At a later stage a demonstrator was assembled; sharing the software components with the simulator but representing a substantially more mature implementation, the demonstrator was employed to test the effectiveness of the SITMar system. Both the simulator and the demonstrator show how the system reacts automatically to abnormal conditions and create an effective single integrated operational picture by aggregating information obtained from different systems and in different domains (i.e., tracking, monitoring and security).

SITMar offers its users the services of goods monitoring during all phases of transport, by resorting to advanced RFID technology, the SITMar and UIRNet sensing and communication infrastructures and implementation logic based

on the NEGENTIS Platform, providing all the necessary capabilities to systems integration and interoperability through the adoption of a net-centric distributed architecture able to effectively integrate people, applications and devices with a general approach that closely recalls the Industrial Internet definition.

ACKNOWLEDGMENT

The authors would like to thank all the colleagues at Negentis s.r.l. and in particular Dr. Leonardo Landi, Dr. David Parlanti, and Dr. Paolo Bussotti for their valuable hard work during both the research and the development phases of the SITMar project.

REFERENCES

[1] Props (Promotional Platform for short sea Shipping and intermodality) “STANDARDISATION OF D2D INFORMATION FLOWS”, 2010.

[2] Tsilingiris P., Psaraftis H., and Lyridis D., “RFID-enabled innovative solutions promote container security”, International Symposium on Maritime Safety, Security and Environmental Protection (SSE07), Athens, (2007).

[3] M. K. Uddin, M. K. Hossen, “A safe system with safe logistics support for Chittagong Port”, Computer and Information Technology (ICCIT), 2010 13th International Conference on , vol., no., pp.347-351, 23-25 Dec. 2010.

[4] Bai Y., Zhang Y., Shen C., “Remote container monitoring with wireless networking and Cyber-Physical System”, Mobile Congress (GMC), 2010 Global , vol., no., pp.1-5, 18-19 Oct. 2010.

[5] Yingjun Z., Shengwei X., Peng X., Xinquan W., “Shipping containers of dangerous goods condition monitoring system based on wireless sensor network”, Networked Computing (INC), 2010 6th International Conference on , vol., no., pp.1-3, 11-13 May 2010.

[6] http://www.cubic.com/Solutions/Cubic-Global-Tracking-Solutions

[7] http://www.libelium.com/wireless_sensor_networks_m2m_logistics_operations/

[8] ITIGG, “Guide to UN/EDIFACT Container messages”, Issued by the International Transport Implementation Guidelines Group (ITIGG) - a Sub-Group of the UN/EDIFACT JRT Joint Message Development Group 4 (Transport), VERSION 1.3 – (1997).

[9] UNECE, United Nations Directories for Electronic Data Interchange for Administration, Commerce and Transport, Message Type: BAPLIE, Vers.: D, Release: 12A, Contr. Ag.: UN, Revision: 6, Date: 2012-08-17.

[10] M.Cresta, E.Storti, E.Simetti and G.Casalino, ”ARCHIMEDE - Integrated Network Centric Harbour Protection System”, International Conference on Waterside Security (WSS2010), Marina di Carrara, Italy, November 2010.

[11] http://en.wikipedia.org/wiki/Net-centric