<figure><img src="image_1.png" /></figure>

HAL
open science

# Management of local multi-sensors applied to SHM and long term infrared monitoring: Cloud2IR implementation

Antoine Crinière, Jean Dumoulin, Laurent Mevel

► To cite this version:

Antoine Crinière, Jean Dumoulin, Laurent Mevel. Management of local multi-sensors applied to SHM and long term infrared monitoring: Cloud2IR implementation. Quantitative InfraRed Thermography Journal, 2019, 16 (1), pp.55-73. 10.1080/17686733.2018.1519752. hal-02293809

HAL Id: hal-02293809

https://inria.hal.science/hal-02293809

Submitted on 22 Sep 2019

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
# Management of local multi-sensors applied to SHM and long term infrared monitoring: Cloud2IR implementation

Antoine Crinière<sup>a,b</sup> Jean Dumoulin<sup>a,b</sup> and Laurent Mevel<sup>a,b</sup>

<sup>a</sup>Inria, I4S Team, Campus de Beaulieu, F-35042 Rennes cedex, France;

<sup>b</sup>IFSTTAR, COSYS, SII, F-44344 Bouguenais, France

November 12, 2018

## Abstract

Cloud2IR is an autonomous software architecture, allowing multi-sensor connection, dedicated to the long term thermal monitoring of infrastructures. It has benefited of past experimental knowledge acquired in various research projects to redefine a lighter architecture using generic standards, more appropriated to autonomous operations in the field, and that can be later included in a wide distributed architecture. The system has been developed in order to cut down software integration time facilitating the system adaptation to each experiment specificities. After a detailed presentation of data standards, our bi-headed architecture is presented. First, a generic unit, a data management side able to aggregate any sensor data, type or size, automatically encapsulating them in various generic data format such as hierarchical data format or cloud data such as opengis standard. This whole part is also in charge of the acquisition scenario, the local storage management and the network management. Second, a specialized unit where the sensor specific development fitted to experimental requirements are addressed. The system has been deployed on two test sites for more than one year. It aggregates various sensor data issued from infrared thermal cameras, GPS units, pyranometers, weather stations. The software and some results in outdoor conditions are discussed.

Autonomous SHM software; Data Management; Long term infrared monitoring; OGC; Outdoor conditions.

## 1 Introduction and context

Being able to perform full field easily non invasive diagnostics for surveillance and monitoring of transport infrastructures and structures is a major concern for many technical offices. Among all the existing electromagnetic methods, long-term thermal monitoring by uncooled infrared cameras is a promising technique.
Anyway, moving camera from laboratory set-up to real field measurements con-
figuration (i.e. outdoor environmental conditions) requires efforts in system
architecture design (i.e. hardware and software) but also in black monitoring
environmental parameters during acquisition for further in-line or off-line mea-
surement corrections.

Though, infrared system manufacturers have made a strong standardiza-
tion effort for the implemented communication protocol used in their uncooled
infrared camera, their commercial software concerned mainly laboratory appli-
cations. So, addressing in parallel *in-situ* thermal infrared and environmental
measurements, for long term thermal monitoring, requires to address interop-
erability between sensors and multiple data types management. In a second
step, solving such measurement architecture issue, will help in studying and
developing new analysis methods in a context of massive data production.

The present paper focuses on the first aspect, new system architecture dedi-
cated to long term thermal monitoring, and intends to show how standards can
be addressed to favour high computing processing in a near future (for instance
to reconstruct the inner 3D thermal field of structures.

Following research works initiated in the European project ISTIMES [24][8],
the project Cloud2SM (Cloud architecture design for Structural Monitoring with
in-line Sensors and Models tasking) [1], has been launched to develop a robust
information system able to assess the long term monitoring of civil engineering
structures as well as interfacing various sensors and data. The specificity of such
architecture is to be built upon the notion of data processing through physical or
statistical models. Thus the data processing, whether material or mathematical,
can be seen here as a resource of the main architecture. The project can be
divided in various items as the sensors and their measurements processes, the
storage resources, the computational resources, the models themselves, the user
interface, and the structures themselves. The project intends to be standardized
by following the Open Geoscience Consortium (OGC - [20]) recommendations
for its web interfaces and for example the Hierarchical Data Format (Hdf5 -
[10]) for its local data format. Figure 1 presents a global schematic view of
Cloud2SM project.

Cloud2IR [12] represents the infrared and environmental sensor side of Cloud2SM
project, i.e. its connection to the data side. This paper will introduce standard-
ized data concepts used to produce a generic sensor interface on wich Cloud2IR
is based. Then the specialization process of Cloud2IR is presented as well as
two deployments on real test sites. Preliminary results are discussed and finally,
conclusion and perspectives are proposed.

2 Used standard

## 2.1 Standardized access for infrared camera (Genicam)

The Generic Interface for Cameras (GenICam) is a generic programming in-
terface for machine vision (industrial) cameras. The goal of this standard is
<figure><img src="image_2.png" /><figcaption>Figure 1: Cloud2SM architecture principle.</figcaption></figure>

to decouple industrial camera interfaces technologies, such as GigE Vision or
Camera Link etc., from the user Application Programming Interface (API) [11].
The GenICam standard is administered by the European Machine Vision Asso-
ciation (EMVA - [5]). Any manufacturers which follow the Genicam standard
provide a Genicam descriptive scheme (in XML format) which allow then any
camera to be interfaced with various generic software independently from the
technology used, see Figure 2.

<figure><img src="image_3.png" /><figcaption>Figure 2: GenICam principle schematic illustration.</figcaption></figure>

A growing number of infrared camera manufacturers replace their propri-
etary solution by a GenICam implementation [9] which allows to define lighter
drivers through an external library (ex: Aravis [22], PleoraTM, ...) to get data
and send setup requests to the infrared camera.
## 2.2 Data standardization for improved exchange

In a world where a lot of actors (industrial, academics, public policy...) produce and aggregate massive data flows, the data standardization is one of the keys to insure the interoperability between systems. A growing number of solutions are developed to give scientists an access to those data and to computing systems [27, 13]. From that point of view raw data exist into various formats (matlab, csv, text, binary, proprietary...). Those are called legacy data and have to be a *posteriori* shaped into intelligible format like Hdf5 [10], Network Common Data Form (NetCDF) from OGC [17], standard data base systems (i.e. SQL), Observation and Measurements encodings [14, 18], normalized encoding for Geographical Information System (GIS - [25]), etc... The main objective of this development action plan is to propose a fully inter-operable system in terms of data as well as metadata.

### 2.2.1 Hdf5 as a raw format

Firstly proposed by the National Center for Supercomputing Applications and now developed by the HDF Group [10], the Hierarchical Data Format is a generic data container able to structure and describe a huge amount of data. Available in BSD (Berkeley Software Distribution License) open source, the HDF library is common to multiple systems and programming languages (Matlab, C/C++, Java, Python). Various versions of the format have been proposed, the Hdf5 (the last one) simplifies the structure, as well as the access strategies to the data contained in the file. The Hdf5 file structure includes only two major types of objects (Datasets and Groups) for which metadata can be specified:

* The **Datasets** which are multidimensional arrays of homogeneous type.

* The **Groups** which are structured containers that can hold datasets and other groups.

* The **Metadata** stored as attributes and attached to groups and datasets.

Figure 3 summarizes the Hdf5 architecture.

This results in a truly hierarchical, filesystem-like data format, in the same way as any modern operating system, and proposes the same access philosophy. This file format presents at least three main advantages, the external typing and sizing of the data which allows the auto-generation of datasets, the tree structure facilitating the data access and the metadata management which enforces the interoperability with other systems. Note also that the Hdf5 natively provides a compression algorithm (i.e in case of a large amount of IR raw data). The Hdf5 container can be contained itself in a NetCDF format, another highly used standard for raw data. Such file can be directly sent and used by most of the HPC (High Performance Computer/Computing) centers. Once the system is able to produce standardized raw data, it will be able to interact with other ISO compliant solutions as well as the OGC sensor observation and measurement.
<figure><img src="image_4.png" /><figcaption>Figure 3: HDFfile format hierarchy.</figcaption></figure>

### 2.2.2 OGC Sensors Observation and Measurement web service (SOS)

The Open Geospatial Consortium (OGC) is an international voluntary consensus standards organization, originated in 1994. In the OGC, more than 500 commercial, governmental, nonprofit and research organizations worldwide collaborate in a consensus process encouraging development and implementation of open standards for geospatial content and services, Geographical Information System (GIS) [25] data processing and data sharing. One of the main aim of this consortium is to promote open standards able to create wide information systems. OGC acts as a link between the accepted standards like ISO and the information technologies as the World Wide Web Consortium (W3C). The OGC provides various standards [4]. From the sensor side the main paradigm is resumed by the Sensor Web Enablement (SWE). The SWE standards [20] enable developers to make all types of sensors, transducers and sensor data repositories discoverable, accessible and usable via the Web.

SWE can be divided into two essential components. On the first hand the encodings (O&M [18], Sensor Model Language [21] etc...) made to represent data, sensors and their metadata in XML format. On the second hand the SWE provides various web services like the Sensor Observation Service (SOS) [19] which allows real-time query of sensor data, all described by the encodings presented below. Such sensor web paradigm first defined in [3] and [4], is here addressed by the common definition of the OGC SWE namely "Sensor Web is an infrastructure enabling access to sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application programming interfaces". The OGC standards are mainly based on the web service idea (SOAP and Rest communication protocols), which beside its apparent complexity allows a generic use of their proposed resources, in the SOS case the measurements and the sensor description itself. Figure 5 shows an example of how such a system can be used to exchange and present various
<figure><img src="image_5.png" /><figcaption>Figure 4: OGC standards schematic view. Definition available at http://www.opengeospatial.org/standards/http://www.opengeospatial.org/standards/</figcaption></figure>

data.

<figure><img src="image_6.png" /><figcaption>Figure 5: Sensor observation service (Data exchange use).</figcaption></figure>

## 3 Networking operation and data exchange

Our initiative in this project is to provide sensor architectures and frameworks able to produce standardized data. The Hdf5 allows to store locally and externally a huge amount of data. For that purpose, this file format is well adapted to the thermal long term monitoring of civil engineering structures. As the Hdf5 file follows the ISO recommendations for metadata, it can be easily converted into cloud information data based on the OGC-SOS web service [14]. In the end, the system will be able to produce raw data (Hdf5) sent through a network (step 1 Figure 6) and provide redundancy of critical data by duplicating it as cloud data (SOS) (step 3 Figure 6). As civil engineering structures are
not always connected to the network, the raw data should also be externally
converted into SOS web format (step 2 Figure 6).

<figure><img src="image_7.png" /><figcaption>Figure 6: System future integration.</figcaption></figure>

This type of implementation allows maintainer to build a critical redundancy
system, data are duplicated in both formats. In common use, the SOS database
can be tasked by standard SOS client which can print augmented data (value and
their metadata) while Hdf5 database provides access to raw data for scientific
use.

4 Local management of multi sensors

4.1 Highlight needs of modularity

For many years now our team has used a complete system called IrLaw to control
IR cameras and various environmental sensors [8][7][6][2]. IrLaW has been built
for local experiment and on a legacy ubuntu, over time this system has shown
its limits for a long term easy use. Two of them were problematic. The HMI
(Human Machine Interface) which consumes computing and power resources.
Moreover the system needed high development costs for maintenance operations
and adaptation to each experiment specificities. Within the Cloud2SM project
it has been decided to develop a system according to a few guidelines:

* Reusing part of the IrLaW software and manage technical debt

• No HMI

* Provide a generic and modular development framework to adapt effort-
  lessly the system for each experiment

* Insure the data standardization
Formerly in IrLaW, real-time sensors (like IR cameras) were controlled by a hard coded setup inside system core, other non real-time sensors were then demonized by a specific service and their data stored inside read-only registers. Now in Cloud2IR this philosophy has been conserved but real-time sensors have been also demonized in order to improve the modularity of the whole architecture, (see Figure 7).

<figure><img src="image_8.png" /><figcaption>Figure 7: From IrLaW to Cloud2IR.</figcaption></figure>

As it have been presented, the modularity of the system is the key to adaptation, so it has been developed in order to cut down software integration time which facilitates the system configuration to each experiment specificity. We propose a bi-headed architecture with a specialized part which represents the sensor specific development as well as their drivers and their different fixed configurations, and a generic part, which can be seen as the data management side.

## 4.2 Data Management of Local MultiSensor paradigm (DaMa-LoS)

DaMaLos stands for Data Management of Local multiSensors, it corresponds to the generic part of the system. Based on the Hdf5 external data typing (see below), this module can be seen as a generic framework to manage data produced by the sensors. It instantiates through a generic interface all the sensors and control the data access loop (not the requesting). This side of the system is weakly coupled with the sensor side. It can be seen as a general framework able to aggregate any sensor data, type or size and automatically encapsulate them in various generic data format as HDF5 or cloud data as OGC SWE standard. This whole part is also responsible of the acquisition scenario, the local storage management and the network management through SFTP or SOAP for the
OGC frame. The framework is mainly composed by:

* **The Sensor interface**, where each external sensor attaches its bytes data and specify its type, size or need for compression.

* **The data standardization**, auto generation of Hdf5 data files and in the future OGC O&M compliant data.

* **The local data management**, users can specify the amount of data they want on local backup

* **Network management**, the framework manages all the networking operations.

* **The acquisition strategy**, for now the system can only sub-sample data

The whole configuration is achieved by an XML file. The main goal of such strategy is to build modular applications, easy to connect to the internet and where the resources are fully focused on the sensors and other experimental requirements instead of generic data aggregation mechanisms, see Figure 8.

<figure><img src="image_9.png" /><figcaption>Figure 8: Schematic representation of the presented paradigm.</figcaption></figure>

## 4.3 Few words about meta-data

A certain amount of data over long time periods is addressed. It is relevant to be able to retrieve data and attach right information onto them. That is why the metadata management is a key issue.
As [16] defines it, Metadata is structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. In fact, metadata is a fundamental requirement to ensure that resources will survive and continue to be accessible in the future (like DOI for scientific papers archive for example). But according to the James Frews empirical laws [23]

* Scientists don't write metadata

* Any scientist can be forced to write bad metadata

In fact it is often time-consuming to think about the right metadata and the right scheme to use. Presented developments are geared towards the use of the Hdf5 and OGC O&M standards which are built to support geographical metadata scheme [15]. For now the system produces autonomously basic metadata thanks to the definitions of the used standards (Name, type, size, time, position etc...). Future developments will have to partly focus on the metadata management, for example with the support of the dublin-core scheme [16], in order to propose, as part of the sensor interface a dynamic and autonomous management of the metadata able to help and guide users'.

# 5 Cloud2IR: An infrared and environmental SHM information system

Cloud2IR (C2IR) represents the sensor system used inside the Cloud2SM project.

For each experiment we have different sensors and needs, as the data management is already achieved by DaMaLoS the effort is then focused on the sensor drivers if they are not already built. The resources can now be oriented to specific treatment as computing algorithm or for the IR camera the redirection of their video flux to a streaming server (RTSP), this is achieved with the help of the *Live555* library. Another example of *Live555* deployment can be found in [26]. Once each driver is attached to DaMaLoS through the sensor interface, the data management is automatically done and Hdf5 files are directly shaped.

Following a typical custom implementation of the system designed for an outdoor long term experiment, the system implements a weather station, a pyranometer, a GPS and an uncooled IR Cam using GiGe Genicam standard and the synchronous update strategy inherited from IrLaW.

Figure 9 presents the architecture. As the data management does not need specific resources, development was focused on drivers conception and embedded RTSP system building, to access to the infrared stream without disturbing the acquisition process. Another point is that we connect to our register database a light TCP/IP client which can also provide data to an external proprietary server (different from the Cloud2SM one). Those functionalities reveal our former needs of modularity.
<figure><img src="image_10.png" /><figcaption>Figure 9: Sense-City implementation.</figcaption></figure>

# 6 Test beds and results

## 6.1 The Sense-City experimental test site

The Sense-City Equipex (see Figure 10 (a)) is a large scale equipment which has received support from the French government in the framework of the Programme d'Investissement d'Avenir (Future Investment Programme). This project is led by the French Institute of Science and Technology for Transport, Development and Networks (IFSTTAR) with ESIEE- Paris, the Laboratory of Physics of Interfaces and Thin Films (LPICM) and the Scientific and Technical Centre for Building (CSTB) as consortium partners. The Sense-City project is a collection of high-quality facilities for the design, the prototyping and the evaluation of performance and risks of innovative micro- and nanotechnology based sensors devoted to measurements in urban environment. The building of the large scale testing facility in controlled environment was initiated in 2016. The Equipex is fully operational since April 2018 and is currently used to test a first mini-city scenario.

While waiting the full site availability a first demonstrator has been built in 2015 at the IFSTTAR headquarter office (Figure 10 (b)). This first site is fully instrumented (smart road, energy consumption efficiency, GPR test site...) and this is where the long term infrared monitoring system has been deployed during more than a year (Figure 10 (c) and (d)). The IT system runs on a zotac mini PC under ubuntu. Composed of an infrared camera FLIR A65sc model ®, a weather station VAISALA WXT 520®, a pyranometer DELTA-T SPN1®, and
<figure><img src="image_11.png" /><figcaption>Figure 10: (a) Next Sense-City test site, (b) presented first demonstrator, (c) deployed system, (d) hardware system, (e) Digital levels infrared image acquired at sunrise.</figcaption></figure>

a GPS UBLOX®, the system is designed to operate on normal or emergency power supply. Figure 11 presents four infrared images taken on March the 13rd of 2016.

It is interesting to see the sun path influence, especially on sunrise where only the main side of the lodge is heated and where it can be seen the shadow of the second lodge. On the Figure 11 (b) and (c) the effects of the local atmosphere and insulation inside the lodge are clearly visible and roof superstructure can be discriminated. During the night insulating faults which have been included on the lodge wall can be clearly discriminated. Figures 12 and 13 present the digital levels evolution of four characteristic pixels over a week and also the air temperature and solar heat flux evolution with time. The four pixels are respectively located on the front wall (left wall with a window on the thermal image), on the insulating defect (visible on Figure 10 (e)), on the roof and on the opposite side of the lodge.
<figure><img src="image_12.png" /><figcaption>Figure 11: Digital levels infrared images acquired on March the 13rd of 2016, clockwise top left: around sunrise, noon, sunset and during the night</figcaption></figure>

Over this seven days it appears that the insulating flaw has a slight effect (above the ambient noise) mainly visible on the relaxation phases, especially when the weather seems cloudy. As the lodge is east oriented, the opposite side is sunbathed once a day at sunrise and during few hours, whereupon it enters in relaxation phase. Following this observation it will certainly be interesting to induce another insulating defect on the opposite side. The roof presents the highest day-night range of temperature variations, its solar orientation as its apparent emissivity, and the fact that the inner roof is thermally insulated can induce such behaviour. Figure 14 sums up all the quantities measured such as the prevalent wind direction for a given week.

## 6.2 Inria office buildings test site

A second test site has been instrumented at the Inria office in Rennes (France). This test bed differs from the first one, as the building currently in use presents various facades with different orientations and is composed of multi-materials, see Figure 15. Those particularities make this test bed unique and a promising site for future experiments. For now the site is composed of just an uncooled IR camera and runs since the beginning of 2016.

Figure 16 shows multiple digital level maps acquired on February 25th of 2016. Unlike Figure 15 those maps have been cropped in order to focus on the
<figure><img src="image_13.png" /><figcaption>Figure 12: Evolution of four points from the 10 to the 16 March 2016.</figcaption></figure>

Inria buildings. By comparison with the Sense-City test bed, it can be seen
that the inner structure of the building appears on IR data during the night but
without treatment it does not clearly appear at sunset for example, also data
on the left building appear hard to interpret which highlights the multi-material
specificity of such test bed.

As the building orientation are North East and South East it is interesting
to see in Figure 16 (top right) the impact of the sun path when it goes down.

Figure 17 shows the evolution of two pixel values belonging to each buildings.
Both pixels are East oriented so they are sunbathed at least in the morning,
but (as for the lodges on the Sense-City test site) the building oriented North
East has a smaller solar contribution the rest of the day. Another point is
that the third and fourth day, the South East building thermal evolution seems
particularity eroded, only its amplitude appears perturbed.

Figure 18 presents some environmental variable measured at the Rennes
airport (about 10 Km from the test site). These data have been obtained
thanks to www.infoclimat.fr. By looking at February the 27th and 28th, the
external temperature and humidity do not appear to have a different behavior
than the other days. However the wind speed increases and the wind orientation
is about zero degree (0 and 360 correspond to the North) and does not change
for a while. Crossing the available data it appears that the south east oriented
building faces a strong wind on February the 27th and 28th affecting its surface
<figure><img src="image_14.png" /><figcaption>Figure 13: Evolution of solar heat flux density and external temperature from the 10 to the 16 March 2016</figcaption></figure>

thermal amplitude.

Complementary instrumentation will be installed on this second test site, in order to develop quantitative analysis.

## 6.3 Cloud2IR software outcomes

This new software architecture has allowed us to reduce time for deployment in real site. The preparation and the set-up of measurements scenarios (i.e. amount of additional sensors) were also simplified. As no native graphical interface is implemented in the core of Cloud2IR, remote control of the system is lighter and requires less data communication bandwidth. In particular, the Sense-City experiment has permitted to test a double database feeding configuration, one in CSV file format (only for environmental parameters and located in a private network) and a second one in HDF file format (all data including infrared images and located in a different network at Inria Rennes). Moreover, the Inria test bed, was a proof of concept of deploying the system in an existing internet network architecture (institutional one) by setting-up the infrared camera on a building roof and the hardware part (hosting Cloud2IR) inside a different building. Premises of interoperability with alternative and accessible existing environmental measurements data were drawn. Finally, such experi-
<figure><img src="image_15.png" /><figcaption>Figure 14: Viewing interface</figcaption></figure>

<figure><img src="image_16.png" /><figcaption>Figure 15: Inria test bed, and main IR image around sunrise.</figcaption></figure>

ments have paved the way to extend the capabilities of Cloud2IR to cover large areas by using multiple infrared cameras associated with local environmental sensors or external (open resources) environmental measurements.

# 7 Conclusion and perspectives

This paper has introduced various standards used to ensure the interoperability of the measurement process during in the field system deployment. Based on such standards a new software architecture Cloud2IR, mainly used to assess the long term thermal monitoring of civil engineering structures, has been presented. This development has been motivated by the need of engineers and researchers
<figure><img src="image_17.png" /><figcaption>Figure 16: Digital levels infrared images acquired on February the 25th of 2016 clockwise top left sunrise, noon, sunset and during the night.</figcaption></figure>

<figure><img src="image_18.png" /><figcaption>Figure 17: Digital levels evolution of two pixels from the 25 to the 29 February 2016.</figcaption></figure>

to focus on the experimental specific operations and not on the IT process nor the data formatting. This gain in autonomy and therefore in deployment time is mainly achieved by "DaMaLoS" the main core of the system. Then
<figure><img src="image_19.png" /><figcaption>Figure 18: Environmental variable measured at the airport.</figcaption></figure>

the Cloud2IR architecture can be easily tuned according to experimental needs only. In this case, as the main sensor is a thermal camera, an embedded real time streaming server based on the Genicam standard has been added to the whole infrastructure with the lowest integration time. The robustness of this new architecture is still under evaluation in two test sites, and in the future on a third one (real bridge). Thanks to the large dataset acquired on the Sense-City test site and the measurement of environmental parameters at each time step of thermal image acquisition, investigation on an adapted lock-in approach will be initiated. Statistical approach could also be investigated on such large dataset. Finally, we also have the opportunity on this test site to follow the ageing of some building material. The second test site allows to test IR long term monitoring on a building with a higher thermal inertia than the Sense-City Lodges. The configuration of this second test site is also helpful to develop radiative correction models in presence of a non-negligible reflective object in the scene. For both experiments, it is planned to make cross-analysis with local sensors that are or will be added to the buildings in a near future. The next development may focus on the full integration of observation and measurement standard as well as the externalization of the DaMaLoS framework
# 8 Acknowledgement

Authors want to thank G. Andrade-Barroso from the Inria Rennes *Service d'Expérimentation et de Développement* (SED) who provided insight and expertise that greatly assisted the research.

## References

[1] A. Criniere, J. Dumoulin, L. Mevel, G. Andrade-Barosso, and M. Simonin. The cloud2sm project. In *European Geosciences Union General Assembly*, Vienna, Austria, 2015.

[2] Antoine Criniere, Jean Dumoulin, Frederic Bourquin, and Laetitia Perez. Civil engineering structure daily monitored through IR Thermography and environmental measurement. In *12th International Conference on Quantitative InfraRed Thermography*, Bordeaux, France, July 2014.

[3] K. A. Delin. The sensor web: A new instrument concept. In *SPIEs Symposium on Integrated Optics*, San Jose, USA, 2001.

[4] K. A. Delin. Sensor webs in the wild. *Wireless Sensor Networks: A Systems Perspective*. Artech House, 2005.

[5] F. Dierks. Genicam standard generic interface for cameras. Technical Report 2.0, European Machine Vision Association, 2009.

[6] J. Dumoulin and R. Averty. Infrared imaging system monitors transportation structures in real time. *Spie Newsroom*, 10:4, 2014.

[7] J. Dumoulin and V. Boucher. Infrared thermography system for transport infrastructures survey with inline local atmospheric parameter measurements and offline model for radiation attenuation evaluation. *Journal of Applied Remote Sensing*, 2014.

[8] Jean Dumoulin, Antoine Crinière, and Rodolphe Averty. The detection and thermal characterization of the inner structure of the musmeci bridge deck by infrared thermography monitoring. *Journal of Geophysics and Engineering*, 10(6):064003, 2013.

[9] FLIR. Genicam icd flir ax5 camera - pc. Technical Report T 559 775, Rev. C, FLIR Systems AB, 2013.

[10] HDF. High level introduction to hdf5. Technical Report 1, HDF Group, 2016.

[11] H. Hogan. Will changing machine vision standards cut costs and boost performance? *Photonics spectra*, 42:94–96, 2008.

[12] Ifsttar and Inria. Iddn.fr.001.240012.000.s.p.2017.000.10200. *Inter Deposit Digital Number*., 2017.
[13] A. Ip, C. Brodie, Kelsey Druken, Irina Bastrakova, Ben Evans, and Carina Kemp. Unleashing geophysics data with modern formats and services. In *European Geosciences Union General Assembly*, Vienna, Austria, 2016.

[14] ISO. Geographic information – observations and measurements. ISO 19156:2011, International Organization for Standardization, Geneva, Switzerland, 2011.

[15] ISO. Geographic information – metadata – part 1: Fundamentals. ISO 19115-1:2014, International Organization for Standardization, Geneva, Switzerland, 2014.

[16] NISO. Understanding metadata. ISBN 1-880124-62-9, National Information Standards Organization, Baltimore USA, 2004.

[17] OGC. Network common data form (netcdf) core encoding standard version 1.0. Technical report, Open Geospatial Consortium, 2011.

[18] OGC. Observations and measurements - xml implementation. Technical Report OGC 10-025r1, Open Geospatial Consortium, 2011.

[19] OGC. Ogc sensor observation service interface standard v2.0. Technical Report OGC 12-006, Open Geospatial Consortium, 2012.

[20] OGC. Sensor web enablement: Overview and high level architecture. White Paper 07-165r1, Open Geospatial Consortium, 2013.

[21] OGC. Sensorml: Model and xml encoding standard. Encoding Standard OGC 12-000, Open Geospatial Consortium, 2014.

[22] E. Pacaud. Aravis reference manual. Technical Report 0.4, GNOME Aravis, 2016.

[23] E. Pebesma, S. Scheider, B. Grler, C. Stasch, and M. Hinz. An algebra for spatio-temporal information generation. In *European Geosciences Union General Assembly*, Vienna, Austria, 2016.

[24] Monica Proto, Massimo Bavusi, Romeo Bernini, Lorenzo Bigagli, Marie Bost, Fredreric Bourquin, Louis-Marie Cottineau, Vincenzo Cuomo, Pietro Della Vecchia, Mauro Dolce, Jean Dumoulin, Lev Eppelbaum, Gianfranco Fornaro, Mats Gustafsson, Johannes Hugenschimdt, Peter Kaspersen, Hyunwook Kim, Vincenzo Lapenna, Mario Leggio, Antonio Loperte, Paolo Mazzetti, Claudio Moroni, Stefano Nativi, Sven Nordebo, Fabrizio Pacini, Angelo Palombo, Simone Pascucci, Angela Perrone, Stefano Pignatti, Fice Carlo Ponzo, Enzo Rizzo, Francesco Soldovieri, and Fedreric Taillade. Transport infrastructure surveillance and monitoring by electromagnetic sensing: the istimes project. *Sensors*, 10:10620–10639, 2010.

[25] J. Specht. Reflecting on dr. roger tomlinsons contributions to gis. *Earth Imaging Journal*, 2014.
[26] C. Wei and H. Zhang. Applications of a streaming video server in a mobile phone live streaming system. *Journal of Software Engineering and Applications*, 7:975–982, 2014.

[27] L. Wyborn and B. Evans. The big challenge in big earth science data: Modeling to transdisciplinary data platforms that are relevant to government, research and industry. In *European Geosciences Union General Assembly*, Vienna, Austria, 2016.