Bridge Sensor Mart: A Flexible and Scalable Data Storage and Analysis Framework for Structural Health Monitoring Nazif C. Tas & Ciprian Raileanu & Mathaeus Dejori & Claus Neubauer Siemens Corporate Research, Princeton, NJ ABSTRACT: This paper reports on the new sensor data collection, analysis and storage framework, Bridge Sensor Mart (BSM), for bridge health monitoring data. BSM defines a distributed data storage and data ana- lytics infrastructure in order to collect, store, analyze and manage sensor data for Structural Health Monitor- ing applications. 1 INRODUCTION data very cumbersome or even impractical. In this work, we present a new data storage and analysis Continuously monitoring or even real-time forecast- framework, Bridge Sensor Mart (BSM), designed ing the performance of civil infrastructures based on specifically for long term SHM. gathered sensing information offers a tremendous opportunity to increase safety by detecting and loca- The key features of this framework are: lizing damage before it reaches a critical level. Such 1. Distributed Data Analytics: The post- monitoring and analysis help reduce costs by shift- processing of incoming data is usually per- ing from current “run-to-failure” or preventive main- formed on a single computer. The BSM tenance practices towards predictive maintenance framework allows distributing data analysis strategies. Additionally, structure engineers can use and data processing procedures across mul- the collected data for retrospective analyses in order tiple machines allowing users to handle large to better understand structural behaviors and their amounts of data. interrelationship with external factors such as traffic, 2. Distributed Data Storage: BSM also supports load or environmental influences. the distributed storage of accumulated data. Federal and industrial interest in Structural Health This distributed architecture allows the sys- Monitoring (SHM) projects have been significantly tem to be extended to handle larger scales of increased in the past decades, also fueled by the data by simply adding additional hardware progress made in the area of sensor networks and in- components without changing the design or formation technology. Smart sensor networks, dis- codebase. tributed over disparate structures and communicat- 3. Flexible Sensor Support: Current data man- ing wirelessly with each other have been proven to agement systems are designed to support be effective in many studies, and consequently have specific sensing hardware or certain vendors. been deployed on signature structures. Kim et. al The BSM architecture is sensor- and provid- (2007) for example designed and implemented a er agnostic. The data import layer provides a wireless sensor network to monitor the 4200 ft long generic interface that can be extended main span and the south tower of the Golden Gate through a plug-in mechanism to support new Bridge. See Ansari (2005) for many more examples sensor hardware. of SHM applications. 4. Flexible Data Analytics Support: BSM pro- Albeit the tremendous progress made in new sens- vides a generic interface for users to plug-in ing and networking technologies, one of the biggest their own data analysis algorithms, and to ex- challenges remains: How to efficiently collect, store tend the analytical capabilities without re- and provide the accumulated data to the end users quiring any changes in the system. and applications for further analysis? SHM applica- tions are gathering large amounts of data that are BSM is based on a very efficient hybrid database impossible to manage with the current systems, and structure which combines and utilizes two kinds of hence making the dissemination and sharing of such databases: a scientific database for storing large amounts of historical sensor data and a regular row- paper describes a data collection and data analysis oriented databases for storing metadata. Simulations framework that overcomes the limitations of existing performed showed that the BSM database structure IT solutions by providing an architecture that considerably outperform traditional databases for enables users to handle large amounts of data by dis- sensor-related data tasks. tributing algorithmic components as well as the data Overall BSM allows to robustly manage large across different machines (shown in Figure 2) amounts of data, by implementing a fully distributed Similar existing frameworks are vendor-specific architecture for data gathering, analysis and disse- and therefore not opened for collecting data from the mination. Thus, a single point of failure is avoided sensing hardware of different providers, and most and the workload is distributed among several com- notably not flexible enough to connect to sensing puters. This architecture promises high scalability, technologies not seen so far. Furthermore, existing as it is straightforwarded to extend the system by frameworks do nott allow the creation and modifica- simply deploying new hardware (e.g. new server tion of novel analysis algorithms. nodes) in order to lessen the pressure on highly BSM implements a plug-in interface that allows loaded computers. for the integration of a variety of different sensor types, technologies and data analysis methods. This approach enables users to extend the system based 2 BACKGROUND on their individual requirements with customized da- ta acquisition and data analysis methods. In the rest of this document, the BSM architecture components and the underlying principles are dis- cussed and various performance results are pro- vided. Figure 1 Data flow of a typical long-term monitoring scenario. As shown in Figure 1, a possible workflow for long-time monitoring can be decomposed into three major steps1. First, the data are collected from a ded- icated hardware device (such as a data logger) and stored into a database. Secondly, the stored data are constantly analyzed through different analysis me- thods, such as outlier detection or state estimation models. Based on the results of the analysis methods the data are labeled accordingly and events are gen- erated. For instance, to mark intervals where a cer- tain error has been observed or to trigger events when a certain threshold has been exceeded. Such labels are finally stored as events and aligned to the corresponding sensor signal through unique ids and Figure 2 Bridge Sensor Mart system architecture. a time interval. The architecture shown in Figure 1 is sparsely scalable since all the data are gathered, processed 3 DISTRIBUTED ARCHITECTURE and stored by single machines making it impossible to scale up with growing data. Especially when dep- Just as a common typical SHM application, the loyed as part of long-term SHM settings, IT frame- BSM system is expected to collect, store and process works have to provide a scalable architecture in or- vast amounts of data from sensing devices located in der to cope with the growing amount of data. This diverse physical locations with possibly high sam- pling frequencies. As the number of data sources 1 Note that Figure 1 depicts one among many different and the number of users increase, a centralized IT workflows and does not cover all aspects of SHM. solution poses serious scalability problems. The BSM system defined in this document overcomes sor readings per day) with a large variable update these kinds of issues by utilizing a distributed peer- frequency range (from “once a day” update to to-peer infrastructure, as shown in the top part of 100Hz readings). In addition to the sensor readings, Figure 2, and thus allowing convenient extensibility the BSM system stores several other types of data of the entire system through addition of new com- structured in variety of ways such as the sensor in- puters, so called BSM nodes. ventory information stored for hardware manage- A BSM node is a logical entity which supports ment, the user information stored for secure system whole or partial functionalities of data collection, access and authorization, and metadata information storage, processing and data access. BSM nodes are for storing the steps of data transformation during organized in a peer-to-peer fashion, enabling fast da- the data import/analysis processes. Hence, BSM da- ta discovery and access. In this system, each BSM tabase structure faces the challenges of storing hete- node is responsible for collecting the data locally rogeneous data with diverse set of requirements. from one or more sensing devices. The collected da- In order to tackle this problem, BSM system dep- ta are stored and processed locally and the metadata loys an efficient, fast hybrid database structure defining the nature of the fetched data together with which promises the fast querying speed of scientific the outcomes of the analysis engine is dissipated databases without the insertion bottleneck common among the other BSM nodes through the peer-to- in such systems. BSM utilizes two databases at the peer infrastructure for data lookup and remote same time and optimizes the queries issued for the access. maximum performance. When the users are interested in a particular type of information and issue a query to a target node, firstly the query is performed on the local database 4.1 Column-oriented databases vs. Row-oriented searching for immediate availability. If it is possible Databases to respond to the query entirely, the information is fetched from the local database and made available Traditional databases implement a record oriented to the user. If the information needed to respond to database schema where the records are stored conti- the query is distributed among other BSM nodes, the nuously. Through this row-oriented storage mechan- target node first discovers the locations of the other ism, new records (data insertion) can be handled BSM nodes needed to complete the query response, very efficiently by pushing all the record informa- through the peer-to-peer infrastructure. Once the lo- tion into the storage system. Hence this kind of da- cations of the BSM nodes are discovered, the target tabase systems is usually referred as write-optimized node communicates with them separately by trans- or row-oriented databases (Stonebreaker et al.