monitoring of a transport infrastructure via a sensor

Monitoring of a Transport Infrastructure via a Sensor-enabled SDI

Lorenzo Bigagli1, Stefano Nativi2, Mattia Santoro1, Enrico Boldrini1, Paolo Mazzetti2

Abstract

In the framework of the FP7 ISTIMES project (Integrated System for Transport Infrastructures Surveillance and Monitoring by Electromagnetic Sensing), we have designed a distributed, real-time, Web-based information system for sensor-based transport infrastructures monitoring applications.

The overall aim of the ISTIMES project is to make critical transport infrastructures more reliable and safe, provid-ing real-time, detailed information and imagery of the infrastructure status, to improve decision support for security stakeholders, by means of non-destructive electromagnetic monitoring, exploiting heterogeneous state-of-the-art in-situ sensors and specific satellite measurements.

From an ICT point of view, ISTIMES aims at the design of an open networked architecture capable of integrating measurements from a wide range of remote and in-situ sensors. Our main contributions have regarded: the formaliza-tion of system users and use-cases; the design of the service infrastructure, including peculiar value-added mediation services; the identification of the system components and of possible technological implementations.

The ISTIMES system is a middleware framework founded on a Spatial Data Infrastructure, hence enabling the im-plementation of individual test-bed applications, customized to the transport infrastructure of interest.

ISTIMES is an ideal test case for the Event Architecture paradigm, which naturally accommodates asynchronous events from disparate sources, e.g. a constellation of autonomous sensors deployed onto an infrastructure.

Besides, ISTIMES constitutes a valuable real-world application for the current best practices and standards in mul-ti-sensors, real-time monitoring systems, and its feedback may contribute to their future evolution.

1. Introduction In this work we present the design of a distributed, real-time, Web-based information system for publish-ing, cataloguing, integrating and processing satellite and in-situ data for transport infrastructures monitor-ing applications.

The system has been designed in the framework of the FP7 ISTIMES project (Integrated System for Transport Infrastructures Surveillance and Monitoring by Electromagnetic Sensing) (Proto 2010), whose overall aim is to improve the reliability and safety of critical transport infrastructures. ISTIMES exploits several innovative non-invasive imaging technologies based on electromagnetic sensing (optic fiber sensors, Synthetic Aperture Radar satellite platform based, hyper spectral spectroscopy, Infra-red thermography, Ground Penetrating Radar, low-frequency geophysical techniques, Ground based sys-tems for displacement monitoring), whose integration with state-of-the-art Information and Communica-tions Technologies (ICT) solutions enables remotely controlled monitoring and surveillance of critical transport infrastructures.

1 National Research Council of Italy, Institute of Methodologies for Environmental Analysis (CNR-IMAA), Area della Ricerca di Potenza, Contrada Santa Loja, Zona Industriale, I-85050 Tito Scalo (PZ), Italy, 2 National Research Council of Italy, Institute of Atmospheric Pollution Research (CNR-IIA), Area della Ricerca di Roma 1, Montelibretti, V. Salaria Km 29,300, Monterotondo (RM) email: [email protected], Internet: http://www.cnr.it.

EnviroInfo 2011: Innovations in Sharing Environmental Observations and InformationCopyright 2011 Shaker Verlag Aachen, ISBN: 978-3-8440-0451-9

From an ICT point of view, ISTIMES aims at the design an open networked architecture, that can ac-commodate a wide range of remote and in-situ sensors, and can scale up to allow the integration of addi-tional sensors and, possibly, interface with other monitoring networks (Bigagli 2010).

2. System architecture The ISTIMES system architecture is based on the following design rationale:

• Shift from “system” to “infrastructure” or “system of systems”; • Shift from the traditional data-centric approach to a Service-Oriented approach; • Focus on multidisciplinary interoperability.

As shown in Figure 1, the foundation for the ISTIMES system is a Spatial Data Infrastructure (SDI), as being specified by the major standardization initiatives in the field, such as ISO, OGC, GEO, INSPIRE, GMES, and other related EU research projects.

Figure 1 Overview of ISTIMES system architecture

The ISTIMES system is intended as an enabling middleware framework, onto which appropriate individu-al test-bed applications can be implemented. As such, the ISTIMES architectural solution should be easily customizable to the application scenario of interest, i.e. to the online, real-time monitoring of the transport infrastructure of interest.

The ISTIMES system architecture takes into account other relevant EU-funded projects (e.g. FP6 Or-chestra, SANY, OSIRIS), as well as the state-of-the-art of the current standardization initiatives in the field, namely the OGC-promoted Sensor Web Enablement (SWE) initiative, which aims at identifying ar-chitectural solutions for building the Sensor Web.

SWE is the current geomatics standard baseline for the implementation of a network of Web-enabled sensors, the so-called Sensor Web, which is commonly recognized as a key enabler for many applications.

Copyright 2011 Shaker Verlag Aachen, ISBN: 978-3-8440-0451-9

SWE collects and integrates several standards in a service-oriented approach and offers solutions for sensor system discovery and control based on the Web and the OGC’s geo-processing framework. It pro-motes interoperability of sensor description, data encoding, sensor location and motion, and provides Web-based application interfaces to sensors, sensor systems, sensor services, and sensor data archives.

In the next sections, we describe our main contributions to the design of ISTIMES system architecture: • The formalization of the potential users of the system (including scientists and generic users) and

of appropriate use-cases; • The design of a four-layered set of services, progressively abstracting the low-level acquisition of

data to the production of synthesized meaningful notifications. In particular, the architecture of ISTIMES services introduces peculiar value-added mediation services that constitute specific scientific contributions of the project;

• The identification of the system components and of possible technological implementations.

Figure 2 ISTIMES use-cases


3 System use-cases As depicted in Figure 2, the system use-cases include generating, publishing, cataloguing, and processing spatial remote-sensing data, to extract situation indexes concerning a target transport infrastructure.

The Security stakeholder is the main target of the ISTIMES system, hence he/she can execute most of the use-cases, including accessing and configuring the DSS, browsing all sensors and acquisitions, and grant other users access to the different system resources, including public content.

The Scientific user is considered an important target of the ISTIMES system; hence he/she can execute important use-cases, including browsing sensors and acquisitions. Due to security concerns, his/her use-cases are subject to authorization checks; for the same reasons, use-cases that may hinder system operation by the decision maker are forbidden to scientific users, although considered of interest (e.g. sensor task-ing).

The Generic user may reach the ISTIMES Web application through a Web browser and may be inter-ested in the infrastructure under monitoring. In general, these users are anonymous and not authenticated; hence they are allowed access to simple, public information only, if any at all.

Although sensor autonomy is desirable, the current practice and state of the art require some sensors to be supervised by humans, e.g. for acquisition post-processing. Sensor operators supervise the acquisition process and ingest the data (possibly after appropriate post-processing) into the ISTIMES system

4. System services As depicted in Figure 3, the services implemented by the ISTIMES system for the generic infrastructure under monitoring are layered in four distinct domains. Service layering is a typical organizational pattern for distributed system (cf. the ISO OSI model for networked applications), because it promotes composa-bility and separation of concerns. Each layer is in charge of exposing specific services to the upper layer, in turn exploiting those exposed by the lower level.

In particular, the Acquisition domain realizes the abstraction of networked sensors into standard ser-vices. Three main functional components are identified:

• Data access service – this endpoint supports acquisition retrieval, possibly parameterized, e.g. by area of interest;

• Data publishing service – this endpoint supports the uploading of acquisitions to a persistent repository;

• Sensor tasking service – this endpoint supports tasking a sensor to acquire data. The standard framework at this level is being defined by the OGC SWE initiative, which includes service specifications for the three above functionalities, respectively:

• Sensor Observation Service (SOS) - Defines a standard Web interface for accessing observation data from sensor systems; the above specification also defines a transactional module (SOS-T) for data publishing;

• Sensor Planning Service (SPS) - Defines a standard Web interface for preparing collection feasibility plans and a service to process collection requests for a sensor or sensor constellation.

The SWE framework is designed as a middleware between physical sensors and user applications; hence it fits naturally in the ISTIMES layered design described in this section. Additional data types of interest for the ISTIMES system, such as maps and coverage data, are accessed by means of specific OGC standard services:

• Web Map Service (WMS); • Web Coverage Service (WCS);


• Web Feature Service (WFS). ISTIMES is based on an extension of the SOA (Service Oriented Architecture) approach, termed Brokered SOA. It extends the traditional SOA introducing middleware components that facilitates the communica-tion between the consumer and provider actors of the SOA archetype, by means of appropriate value-added services, according to the mediation-based approach. This decoupling of servers and clients has proven beneficial in a number of use-cases related to geospatial data harmonization.

The Mediation domain is additional to the baseline OGC layering, introducing services that are peculiar to ISTIMES and constitute specific scientific contributions of the project. This approach is also adopted by the SANY Sensor Service Architecture, where such services “mediate the access from the upper applica-tion domain to the underlying information sources.” (SANY 2009)

In the ISTIMES system, the following advanced functionalities feature a mediated approach: • Discovery – via a Catalog Broker, distributing the queries to a federation of disparate sources; • Processing – via a Process Broker, coordinating the execution of the tasks needed by higher-level

processes (e.g. fusion), in turn required by the system applications; • Notification – via a Message Broker, receiving and relaying the event messages originated by the

various ISTIMES subsystems, including individual sensor controllers (e.g. to notify of sensor failures) and data stores (e.g. to notify of new data).

Figure 3 Service layers of the ISTIMES system

The standard OGC services identified for the discovery and processing functionalities are: • Catalogue Services for the Web (CSW);


• Web Processing Service (WPS). The implementation of notification functionality is still an open issue in the geospatial community. The OGC has published several documents on the topic, including best practices and discussion papers, and is currently addressing the specification of a standard service specification. In the ISTIMES system architec-ture, notification services are implemented by a number of mechanisms, including Web Notification Ser-vice (WNS), GeoRSS, and Web Hooks.

5 System components The main components of the ISTIMES system are depicted in Figure 4, with their interconnecting ports and protocols. Continuous lines represent static links; dashed lines represent dynamic, more loosely cou-pled links.

Figure 4 ISTIMES system components

We had intended to evaluate the OWS SWE 2.0 standards for the Sensor Controller and the In-situ Data Store components, since ISTIMES would be one of the first real-world applications and possibly contrib-ute to the future evolution of the specifications. However, no reference implementation of the standards was available, and an ISTIMES implementation would have been out of the scope of the project. Hence, we selected the OGC SWE 1.0 standard baseline as the enabling service framework of the acquisition do-main.

The broker components are of particular interest and are elaborated in the following sections.


5.1 Catalog Broker The Data Catalog, based on GI-cat technology (Nativi/Bigagli 2009), implements the discovery services needed for sensor and data retrieval through standard discovery interfaces. It acts as a broker to both the system In-situ and Remote Data Store, through static connections based on standard OWS interfaces. Queries can be exercised on a variety of metadata fields, depending on the connections in use (e.g. queries by sensors names and identifiers, by sampling area, by keywords).

The catalog may also implement discovery services to a distributed federation of other resources (e.g. catalogues external to the ISTIMES system, which are not shown in the picture) (Na-tivi/Bigagli/Mazzetti/Boldrini/Papeschi 2009).

Several international and community services are indeed supported by the Catalog Broker. They in-clude: W*S (e.g. CSW, WCS, WMS, WFS, WPS, SOS), THREDDS Data Service, GBIF services, SeaDa-taNet CDI, GeoRSS, OpenSearch, OAI-PMH. Queries can also be exercised against local data repositories (e.g. data and metadata collections stored in the filesystem or in a database). Several XML metadata en-codings are supported, like: Dublin Core, ISO 19139 (encoding of ISO 19115 and ISO 19115-2 data mod-els), Directory Interchange Format (DIF), SeaDataNet CDI, ncML (CF and OD attribute conventions). Bi-nary files are also supported, such as the NetCDF.

Significant SOA and Web 2.0 standard discovery interfaces can in turn be published by the Data Cata-log, such as OGC Catalogue Service for the Web (CSW) in its ISO and ebRIM profiles, OpenSearch, OAI-PMH, making possible to effectively query the Data Catalog by means of a plethora of different dis-covery clients. They include clients that are widespread in the geoscientific community, such as ESRI ArcGIS and Geoportal, the GEO/GEOSS Portal, GeoNetwork and GI-go Geobrowser. Moreover the cata-log can be queried through its built-in web portal by using a common browser; it is also possible to sub-scribe to results feeds using a feed reader.

Extended customizations are enabled from a user friendly interface, in order to tailor the broker to the desired use case: they include resources management, service homepage customization and advanced set-tings setup (e.g. proxy parameters, authentication).

In the typical scenario the desired services and resources are added one at a time: for each of them a discovery strategy is chosen (i.e. distributed search, manual harvesting or periodic harvesting); the publis-hed interfaces are then setup as well.

Three interfaces are present by default: • CSW – to the system DSS component; • OpenSearch – to the portal component; • Web Hook – a simpler interface to support notification of the availability of new acquisitions by

the sensor controllers; it may be invoked also when new remote data are published to the Remote Data Store (offline procedure, not shown in the picture).

By the latter mechanism, the Data Catalog participates in the implementation of the system notification services: the Web hook causes the Data Catalog to harvest the new acquisition and consequently to send a WNS notification to the Message Broker, which in turns distributes it to the subscribed components (e.g. the DSS, for updating the situation indexes).

5.2 Process Broker The Data Processor was introduced to provide high-level ISTIMES applications (e.g. the DSS) with a sin-gle and standard entry point for accessing datasets. In fact, such applications generally require that input datasets satisfy some pre-conditions (e.g. all datasets expressed according to the same CRS, or encoded in the same format). In heterogeneous environments such as a System of Systems, such pre-conditions can-


not be ensured. Thus, there is the need to pre-process datasets before these can be exploited. This task re-sults very complex because of the large number of possible communication protocols, data models, format encodings, etc.

The Brokered SOA approach applied by ISTIMES can be conveniently used in this case as well. A bro-kering component, named Process Broker, was designed and developed. The Process Broker implements the processing services and coordinates the execution of the tasks (pre-processing) needed by higher-level processes acting as a broker to a distributed set of computational resources (e.g. WPS’s external to the ISTIMES system, which are not shown in the picture).

Through the Process Broker it is possible to access normalized data from both the system In-situ and Remote Data Store, through static connections respectively based on standard SOS and W*S interfaces, in a transparent and seamless way. This is achieved by invoking an appropriate sequence of data pre-processing services, including:

a) Sub-setting (i.e. trimming, slicing); b) Format conversion; c) CRS transformation; d) Data Interpolation.

Existing standards for data access services are quite flexible with regards to the above functionalities: that is, such operations are optional. Thus, data providers typically support only a subset of the above func-tionalities or implement only a partial support to some of the above functionalities, limiting to a subset of their possible parameters (e.g. a given WCS might support CRS transformation, but only among a limited set of CRSs).

Figure 5 ISTIMES Process Broker

The design of the Process Broker, based on a Brokered SOA (Service Oriented Architecture) approach, allowed to move the complex task of pre-processing data from the data users (or client applications such as the DSS) to the system, resulting in an infrastructure with a significantly lower “entry-barrier”.


Other important requirements for the Process Broker are the following: 1. Complement, rather than supplant, the existing functionalities of access systems/services; 2. Be compliant with INSPIRE transformation services implementing rules; 3. Support the existing Community of Practices in using their own pre-processing compo-

nents/services. The first point aims to apply the well-known expert architectural design pattern (Larman 2005) assigning specific tasks (responsibilities) to components that have the information needed to carry out the task. Ac-cording to this, data providers execute all requested pre-processing tasks that they support because they are the most “expert” about their data.

As far as compliance with INSPIRE Directive (INSPIRE 2007), the Process Broker publishes on OGC WPS Application Profile (AP) which implements the abstract INSPIRE Transformation Service interface (INSPIRE 2009).

Particularly important for the ISTIMES requirements is the third point. In fact, pre-processing can have an important impact on the final result of the computation. Thus, supporting the existing Community of Practices in using their pre-processing components and services (e.g. a particular interpolation algorithm) is central in achieving a reliable final result. This goal is achieved by means of architectural extensibility and specific support to the integration external processing services (i.e. MATLAB libraries, which are very common in the scientific community). Fig. 5 depicts how the Process Broker interfaces towards ex-ternal processing services: for each type of service, the Process Broker makes use of a particular software module – named Adapter – which is in charge of mediating between the Process Broker WPS interface and the external service interface (e.g. a different WPS AP). This design makes the Process Broker very easy to extend in order to support new types of external services; in fact, only the needed new Adapter must be implemented.

In this way, the Process Broker effectively enables the implementation of multidisciplinary interopera-bility, which is one of the main challenges in developing Information and Communication Technology (ICT) systems for effective geospatial resources sharing, namely for transport infrastructure monitoring and surveillance.

5.3 Message Broker A significant challenge of ISTIMES concerns asynchronous event management, which is naturally im-plied by monitoring applications.

As noted above, the implementation of a messaging service is still an open issue in the geospatial com-munity. The approach taken in the ISTIMES system architecture supports the implementation of notifica-tion services by a number of mechanisms, including OGC best practices like Web Notification Service (WNS), GeoRSS, and Web Hooks. The Message Broker is the component in charge of mediating the de-livery of notifications of events to the appropriate system modules, with the appropriate protocol.

We are actively contributing to the recently started OGC effort to identify a standard solution for pub-lish/subscribe functionalities in OGC services, as a component of the more general Event-driven Architec-ture pattern, under investigation by the OGC and other standardization bodies.

6. Conclusions We have described several architectural aspects of the ISTIMES distributed, real-time, Web-based infor-mation system for publishing, cataloguing, integrating and processing remote and in-situ data for transport infrastructure monitoring applications.


As a monitoring application, ISTIMES is an ideal test case for the Event Architecture paradigm, which naturally accommodates asynchronous events from disparate sources, e.g. a constellation of autonomous sensors deployed onto a transport infrastructure.

It constitutes a valuable test bed for the current best practices and standards in multi-sensor, real-time, geospatial systems, including the state-of-the-art OGC SWE 1.0 standard framework. We are contributing our experience to the OGC PubSub Standards Working Group, formed in September 2010 to identify a standard solution for implementing geospatial event notification functionalities for the OGC services.

The described system architecture has been contributed to the GEOSS Architecture Implementation Pi-lot-4, started early 2011.

Acknowledgements The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under Grant Agreement n° 225663.

Bibliography Bigagli, L. (et al.) (2010): System Architecture document, first release, Deliverable 2.1, 2010. INSPIRE (2007): Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007

establishing an Infrastructure for Spatial Information in the European Community (INSPIRE), OJ L 108, 25.4.2007, p. 1–14

INSPIRE (2009): Draft Implementing Rules for INSPIRE Transformation Services, v. 3.0, available at http://inspire.jrc.ec.europa.eu/documents/Network_Services/INSPIRE_Draft_Implementing_Rules_Transformation_Services_(version_3.0).pdf, last accessed on 05/07/2011

Larman, C. (2005): Applying UML and Patterns - An Introduction to Object-Oriented Analysis and De-sign and Iterative Development, (3rd ed.). Prentice Hall PTR.

Nativi, S., Bigagli, L. (2009): Discovery, Mediation, and Access Services for Earth Observation Data, Se-lected Topics in Applied Earth Observations and Remote Sensing, IEEE Journal of Volume 2, No 4, Page(s): 233 – 240.

Nativi, S., Bigagli, L., Mazzetti, P., Boldrini, E., Papeschi, F. (2009): GI-Cat: A Mediation Solution for Building a Clearinghouse Catalog Service, Advanced Geographic Information Systems & Web Ser-vices, 2009. GEOWS '09. International Conference on , vol., no., pp.68-74, 1-7 Feb. 2009, URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4782694&isnumber=4782675

Proto, M. (et al.) (2010): Transport Infrastructure Surveillance and Monitoring by Electromagnetic Sens-ing: The ISTIMES Project, Sensors 2010, doi: 10.3390/s101210620, 2010.

SANY (2009): D2.3.4 Specification of the Sensor Service Architecture V3, doc. ver. 3.2, OGC 09-132r1, 2009.


monitoring of a transport infrastructure via a sensor

Documents