# Wireless Accelerometer Architecture for Bridge SHM: From Sensor Design to System Deployment
## 2 Wireless Sensor Network Architecture
### Network Architecture  
Three distinct WSN topologies commonly used in bridge monitoring applications:
* Linear WSN: In this topology, sensor nodes are deployed sequentially along the length of the bridge. Each node relays its collected data to the next node in the chain, eventually reaching the sink node (central processing unit). This architecture is highly energy-efficient for long, narrow structures like bridges but can be prone to data loss if any intermediate node fails. It is particularly useful when continuous monitoring along the span is required.
* Star Topology: multiple sensor nodes are distributed across the bridge and configured to transmit data directly to a central node, which processes and analyzes the information. The central node is usually equipped with high computational power and acts as a hub for communication. This topology simplifies data collection and analysis, reducing the burden on individual sensors. However, it relies heavily on the central node, which can be a single point of failure.
* Edge-Computing Topology: This emerging approach leverages edge-computation capabilities within the sensor nodes. Instead of sending raw data to a central node, each sensor locally processes and analyzes data, transmitting only critical insights or summarized information. This reduces the data transmission load, conserves energy, and enables real-time anomaly detection.  
In this study, a dual-layer star topology was implemented. Sensor nodes communicate with their respective gateway, and the data collected by multiple gateways is then transmitted to a central server for analysis. This approach ensures efficient data handling while addressing the limitations of edge computing for OMA applications, which demand comprehensive data from all sensors.  
The proposed architecture is represented in Figure 2, consisting of two primary components: the edge system (Raspberry Pi) and the central system. Wireless sensors deployed across the bridge form a star topology around the edge system. The latter receives data from the sensors that collect data and send it to a data ingestion module. These data are stored locally in a database within the gateway, which acts as a hub for processing and management. Local computations, such as OMA analysis, are performed on the stored data. The gateway also includes a configuration module accessible via application programming interfaces (APIs), enabling remote management and customization of settings. Processed data are transmitted to the central system using an FTP data sender. Multiple gateways, each representing a different bridge, form a second star topology around the central server. In the central system, the received data are stored in a global storage database managed by a file transfer protocol (FTP) server. The central system includes a gateway manager for centralized control and coordination of edge gateways. Visualization APIs are employed to access and present the data from global storage, providing insights through user interfaces or other external systems. In Figure 2, the data flow is represented with arrows, where red indicates data being pushed to a database, yellow signifies data being fetched, and blue denotes API interactions. Physical components, software components, and edge implementations are distinguished visually in the diagram. This architecture is designed to enable efficient data collection, processing, and centralized management for high-frequency applications.