Research on bridge monitoring system based on wireless sensor network

1 Introduction

Wireless sensor network WSN (Wireless Sensol Network) is the product of the combination of computer, communication and sensor technologies. It is a very active research branch in the field of computer science. In February 2003, the American Technology Review magazine ("Technology Review") listed the top ten new technologies that will have a profound impact on human future life, and wireless sensor network was listed as the first. Through the wireless sensor network, it is possible to monitor, sense and collect various information of the perceived objects of interest to the observers in the node deployment area in real time (such as temperature, humidity, strain, deflection, vibration and other physical phenomena), and send these information wirelessly after processing, and finally send them to the observers through the wireless network. Wireless sensor networks have broad application prospects in military reconnaissance, medical care, smart home, industrial production control, environmental monitoring and other fields. The bridge structure health monitoring system is a special environmental monitoring system.

Bridges are an important part of the transportation network. Once a bridge collapses, the economic losses and disasters caused will be enormous. For example, Canada (Quebec, 1907), the United States (Tacoma Narrows, 1940), South Korea (Han River Shengshui, 1994), China's Qijiang Rainbow Bridge (1999), China's Jiangsu Changzhou Canal Bridge [3] (2007), etc. Therefore, timely acquisition of bridge structure state parameters (strain, deflection, vibration, etc.), carrying out state parameter monitoring and safety assessment work, is of great significance for comprehensive analysis and understanding of bridge working conditions, achieving accident early warning, preventing sudden disasters, avoiding casualties and ensuring infrastructure safety.

2 System Architecture

This system adopts a homogeneous architecture, as shown in Figure 1, which includes sensor nodes, gateways, the Internet, and a monitoring center. The sensor nodes are mainly distributed in the bridge body, and the nodes have the functions of information acquisition, signal processing, routing calculation, and information forwarding. Through network self-organization and multi-hop routing, data is sent to the gateway. The gateway can communicate with external networks in a variety of ways, such as the Internet, satellite or mobile communication networks.

Figure 1 Sensor network architecture

3 Network Node Design

In different applications, the composition of sensor network nodes is different, but generally consists of four parts: sensor module, processor module, wireless communication module and energy supply module. For the bridge structure health monitoring system we studied, the sensor part is divided into internal module and external module. The internal module detects conventional state parameters such as temperature and humidity; the external module is generally planned and installed together during the bridge construction process. Here we propose two sensor external module solutions: embedded optical fiber sensor and bridge steel bar resistance detection. The embedded optical fiber sensor was first proposed by Mendez et al. of Brown University in the United States in 1989. Subsequently, some scholars in the United States, Europe, Japan and other countries began to apply this high-tech technology to civil engineering research and achieved good results. The bridge steel bar resistance detection scheme is newly proposed by us, and its application is simpler and more effective. The characteristics of the embedded optical fiber sensor solution are that the optical fiber sensor has strong corrosion resistance and good durability. Because of its small size, light weight and simple structure, it has almost no effect on the properties of the matrix material after being buried in the civil engineering structure. Single-mode and multi-mode fiber optic sensors can be used to detect stress, strain, deflection, bending, condensation, cracks, creep and displacement of the entire structure of concrete components (such as beams, plates and columns). The condition for using the bridge steel resistance detection scheme is that the steel bars to be tested are not short-circuited (using insulating materials as steel hoops), and the state changes of the bridge are judged by testing the changes in the resistance of key steel bars in the bridge structure.

The processor module uses Atmel's 8-bit low-power AVR microprocessor chip atmega128L as the CPU of the sensor node, which is responsible for data storage and processing. The wireless communication module uses the wireless transceiver chip CC2420 that supports the IEEE 802.15.4 protocol. CC2420 implements the MAC sublayer security operation of IEEE 802.15.4 in hardware and is accessed through the SPI interface with the processor. The power supply is powered by 3 No. 7 lithium batteries. [page]

4 Research and transplantation of TinyOS

TinyOS is a component-based open source embedded operating system developed by UC Berkeley. Its application field is wireless sensor networks. In sensor networks, sensor nodes have two outstanding characteristics: one is strong concurrency, and there may be multiple logical controls that need to be executed simultaneously; the other is that the nodes are highly modular. These two characteristics pose new challenges to the design of operating systems for sensor networks. In response to these characteristics, the University of California, Berkeley has developed a component programming language nesC and a micro operating system TinyOS suitable for wireless sensor networks, introducing technologies such as lightweight threads, active messages, event-driven modes, and component-based programming, making good use of the limited resources of sensor nodes. At present, this system is widely used by universities and research institutions at home and abroad.

4.1 TinyOS Component Model

TinyOS is implemented based on the component programming language nesC, which links modular/component programming with event-driven execution. TinyOS and the applications running on it can be regarded as composed of many independent and interconnected software components. A component provides some interfaces. The interface contains commands and events. Commands are the functions of the interface. Interface users can call commands through the keyword call; events are the ability of the interface to notify events. Users can be notified of events through the keyword signal. Events are implemented in the interface user's component. Components are divided into two types: module files and configuration files. Module files specifically implement commands and events in the interface; configuration files complete the interface connection between components. Generally, an application can only have one top-level accessory.

4.2 TinyOS Scheduling Mechanism

The scheduling mechanism of TinyOS is relatively simple. It schedules lightweight threads (i.e. tasks) in a FIFO manner. Threads are not allowed to occupy each other. When a hardware interrupt arrives, the user's lightweight thread can be interrupted to respond quickly to the hardware interrupt. Tasks can call lower-level commands, send signals to the upper layer to notify the occurrence of events, or schedule other tasks within the component. The atomicity of tasks means that TinyOS only needs to maintain a task stack. This method is very effective in sensor nodes with extremely limited resources. TinyOS is an event-driven operating system. When a task is completed, an event can be triggered, and TinyOS will automatically call the corresponding processing function. Therefore, the CPU will only wake up and process when an event is triggered, and it can be in sleep mode the rest of the time, which can greatly reduce the energy consumption of the system.

4.3 TinyOS Communication Mechanism

The communication mode of TinyOS adopts the Active Message Model (AM). AM is a communication mode for message communication. It is address-based and supports information confirmation and distribution. In order to implement more complex communication protocols at the application layer, the active message model needs to be implemented as a basic communication component of TinyOS. This can not only shield the different communication hardware of the lower layer, but also provide a unified communication primitive for the upper layer to facilitate application development. When the data reaches the sensor node through the network, it must first be cached, and then the active message dispatch layer will hand over the cached messages to the upper layer for processing. Because nesC does not support dynamic memory allocation, it is required that each application must be able to return an unused memory after the message is released to receive the next incoming message. Therefore, the active message communication component needs to maintain an additional message cache. In TinyOS, after each message is sent, the receiver will send a synchronous confirmation message. In order to save overhead, the confirmation packet is generated at the bottom layer of the active message, and only a random number sequence is sent as confirmation each time.

4.4 TinyOS porting process

The porting of the TinyOS operating system mainly considers whether the hardware processor supports the compilation of nesC (gcc) and the processing of the hardware platform-related parts in TinyOS. We chose Atmel's AVR chip as the microprocessor. GCC has good support for AVR, so there is no need to decouple nesC from GCC. TinyOS has three layers of hardware abstraction architecture (HAA), namely the hardware description layer (HPL), the hardware adaptation layer (HAL) and the hardware interface layer (HIL). The layered structure and component description improve portability and simplify the development of application layer software. The lower the level, the more related to the hardware. The upper layer components call the interface provided by the lower layer. The HPL layer mainly describes the hardware resources and establishes communication with the hardware through memory or I/O mapping ports. It hides the complexity of the hardware and provides an interface for the upper layer to display the hardware capabilities; HAL is an encapsulation of hardware-specific functions based on HPL, which is a hardware-related function interface; HIL is a hardware-independent function interface.

According to the above analysis, when porting, we only need to modify the files starting with HPL and HAL according to the resources of our hardware platform, add the description of hardware resources in the HPL file, and modify the functional functions of hardware resources in the HAL file.

5 Network Communication Protocol

At present, communication protocols, especially MAC protocols at the link layer and routing protocols at the network layer, are hot topics in sensor network research. For different applications, researchers have proposed different MAC protocols and routing protocols, each of which has its own advantages. This system uses the CTP (Collection Tree Protocol) routing protocol at the network layer and the LEEP (Link Estimate Exchange Protocol) protocol at the link layer to calculate the quality of the bidirectional link to provide a basis for the routing selection of the upper layer. The communication protocol abstract layer structure is shown in Figure 2.

Figure 2 System communication protocol layer structure

[page]

5.1 Implementation of CTP Protocol

The CTP protocol is a tree-based multi-hop protocol. The nodes in the network are abstracted as trees. Each tree has a root node, which is responsible for collecting information about all nodes in the tree. Nodes in the network select routes hop by hop through the routing gradient value (ETX) until they reach the root node. The ETX value of the root node is 0, and the ETX value of each child node is equal to the ETX value of the parent node plus the ETX value of the path from the node to its parent node. Therefore, the ETX value decreases in the direction toward the root node, and CTP selects the path with the smallest ETX value as the route.

The implementation of CTP is based on the results of the lower-layer link estimation. Link estimation maintains a neighbor node table, which stores the path ETX value of each neighbor node. The CtpRoutingEngine component in the CTP protocol implements route selection, which selects the next route for data transmission based on the ETX value of the neighbor node. Another key component function is CtpForwardingEngine, which mainly maintains a message sending queue to send locally generated or forwarded data packets to the lower layer; this component can also detect repeated data packets to suppress repeated packet transmission.

The four key functions implemented are: packet reception (SubReceive.receive()), packet forwarding (forward()), packet transmission (sendTask()), and send completion event (SubSend.sendDone()).

The function SubReceive.receive() decides whether to forward a packet. It checks for duplicate packets by maintaining a cache of recently received packets. If a packet is determined not to be a duplicate, the forward() function is called.

The forward() function encapsulates the packet to be sent. This function also checks whether there is a loop. When sending, the packet is placed in the sending queue. If the queue is full, the packet is discarded and the C position is set to 1. If the queue is empty, the sending task is immediately posted.

sendTask() checks the data packet at the head of the sending queue, encapsulates it and submits it to the AM layer. After the sending is completed, the sendDone() function checks the sending result. If the data packet has been confirmed, the packet is taken out of the queue. If it is a local packet, the event notification is sent to the upper-layer client. If it is a forwarded packet, it is placed in the forwarding message pool. If there are still packets in the queue, a random clock is started and the sending task is reposted.

5.2 LEEP Protocol Implementation

LEEP is a link estimation exchange protocol, which is mainly used to calculate the bidirectional link quality between a node and its neighboring nodes. The link quality of node A→B refers to the probability that B successfully receives the data packet sent by A. The bidirectional link quality between nodes (A, B) is the product of the link quality of A→B (in-bound link quality) and the link quality of B→A (out-bound link quality).

6 Conclusion

Based on the wireless sensor network bridge structure health monitoring system, we studied the design of sensor nodes and the transplantation of the embedded operating system TinyOS that supports the system operation. There are two more issues that need further in-depth research. One is that the dormant energy-saving technology of the sensor network needs to solve the synchronization problem of each node in the network; the second is to establish an expert system for bridge structure health assessment, which can make accurate analysis and judgment based on the large amount of bridge structure information summarized by the sensor network, so as to realize accident pre-alarm, prevent sudden disasters, and ensure bridge safety.