Bridge structure lightweight health monitoring method and system based on cloud side-end collaborative optimization

Abstract

The invention relates to a bridge structure lightweight health monitoring method and system based on cloud side end collaborative optimization, and the method comprises the following steps: S1, arranging a monitoring device and an edge calculation unit at a bridge end, and building a cloud calculation unit at a cloud end; s2, when a task request is received, evaluating processing time delay and energy consumption, and calculating the processing cost of a task k; and S3, defining a selection variable for cloud edge calculation, and scheduling. According to the cloud-side collaborative task scheduling mechanism designed by the invention, the tasks can be reasonably distributed to cloud computing or edge computing according to the processing delay and energy consumption conditions of the computing tasks, so that the system performance and energy consumption are balanced. Based on the cloud edge cooperation mechanism, an optimal deployment strategy of the edge gateways in the system is provided, a linear mixed integer programming formula with the operation cost and the deployment cost as the minimization target is modeled, the optimal deployment number of the edge gateways in the resource-constrained environment is solved, and the deployment efficiency of the edge gateways in the resource-constrained environment is improved. Therefore, the comprehensive optimization of the SHM system among the cost, the energy consumption and the working efficiency is realized.

Description

Technical Field

[0001] The present invention relates to the field of bridge monitoring technology, and specifically to a lightweight health monitoring method and system for bridge structures based on cloud-edge-end collaborative optimization. Background Art

[0002] As one of the relatively expensive infrastructures, bridges will inevitably experience structural cracking, performance degradation and other types of damage during long-term operation due to creep, corrosion and cyclic loading. Structural health monitoring (SHM) technology provides a real-time monitoring and control system. With the help of sensor technology, it provides a key data support platform to monitor the structural response and structural defects of bridges in daily operation in a real-time and dynamic manner, and analyze and evaluate the safety performance of bridge structures based on monitoring data, so that managers can understand the operating status and potential risks of bridges in real time.

[0003] Since the United States and the United Kingdom first tried to install sensors on bridges in the 1980s to monitor the displacement, strain and temperature data of the structure, bridge SHM technology has gone through decades of development. At present, SHM systems mostly use centralized architectures, and various types of sensors are embedded in the bridge structure or installed on the surface of the bridge structure. These sensors are connected to centralized data acquisition equipment and transmit data to the central system through wired networks or wireless sensor networks. This usually requires large-scale deployment. Take the Akashi Beach Bridge in Japan as an example, where hundreds of sensor monitoring devices of more than ten types are installed.

[0004] In recent years, non-contact perception technologies represented by computer vision have been gradually applied to bridge SHM, which has reduced the number of sensors deployed on bridges by SHM systems to a certain extent and improved efficiency. However, with the increasing complexity of computing tasks, the back-end centralized computing mode of traditional SHM systems is difficult to cope with the growing scale of monitoring data and computing complexity. The centralized architecture may cause devices and data far away from the data center to face delays and performance issues. Especially in emergency situations, any communication failure or response delay may limit timely operations and affect the implementation of emergency measures. At the same time, massive data transmission will also cause a lot of unnecessary bandwidth and computing resource consumption.

[0005] Existing monitoring solutions provide edge computing by introducing industrial computers and micro-servers on the side close to on-site monitoring devices. For example, existing research has developed online vision devices for bridge deformation monitoring and crack propagation monitoring. Although edge computing has shown obvious advantages and effectively reduced data transmission and task processing delays, it still faces challenges in practical applications. On the one hand, this actually increases the deployment complexity of the SHM system. In the system, various types of devices such as data acquisition devices, edge servers, and sensing units usually operate independently and cannot form an effective unity. The acquisition paths of multi-source heterogeneous data such as images, videos, and numerical data generated by various types of monitoring devices are complex, increasing the difficulty of data transmission, storage, and management. On the other hand, the deployment of edge servers makes the SHM system actually in a state of coexistence of cloud-edge resources. The edge server is close to the terminal side, with fast data transmission, but limited computing power and resources. The cloud server has strong computing power, but the channel bandwidth for data transmission to the cloud is limited. Summary of the Invention

[0006] To solve the problems existing in the above-mentioned prior art, the present invention provides a lightweight health monitoring method for bridge structures based on cloud-edge-end collaborative optimization, including the following steps:

[0007] S1. Arrange monitoring devices and edge computing units at the bridge end, and build a cloud computing unit in the cloud.

[0008] S2. When receiving a task request, evaluate the processing delay and energy consumption, and calculate the processing cost of task k. The calculation formula is:

[0009]

[0010] where c w and c t are respectively the cost weight parameters of energy consumption and processing delay, is the energy consumption generated when task k is transmitted from the monitoring device to the cloud, is the task processing delay of the cloud computing unit, is the energy consumption of the edge computing unit for calculating task k, is the task processing delay of the edge computing unit.

[0011] S3. Define λ (m,k) as the selection variable for cloud-edge computing and perform scheduling; if λ (m,k) is assigned a value of 0, task k is calculated and processed by the cloud computing unit; if λ (m,k) is assigned a value of 1, task k is calculated and processed by the edge computing unit.

[0012] The data received by the edge computing unit is regarded as an independent task unit and submitted for processing in the form of a task flow. Both the cloud and the edge can process tasks. When the edge computing unit receives a task request, it will conduct a comprehensive evaluation based on the characteristics of the task, such as task processing latency and energy consumption, and dynamically schedule the computing task to the local edge computing node or the cloud for processing.

[0013] Furthermore, The calculation formula of

[0014]

[0015] In the formula, is the energy consumption generated when task k is transmitted from the monitoring device to the edge computing unit, is the energy consumption when task k is transmitted from the edge computing unit to the cloud computing unit, p edge is the transmission power of the edge computing unit, is the latency for the edge computing unit to upload task data to the cloud, d (m,k) is the data volume of task k, r edge is the channel transmission rate for the edge computing unit to upload task data to the cloud.

[0016] Furthermore, The calculation formula of

[0017]

[0018] ω edge = η(f edge ) 2

[0019] In the formula, is the energy consumption generated when task k is calculated in the edge computing unit, c (m,k) is the number of CPU cycles required to process 1 bit of task data, ω edge is the energy consumption of the edge computing unit CPU cycle, η is the edge computing unit energy consumption coefficient determined according to the chip architecture, f edge is the number of CPU cycles that the edge computing unit can execute per second.

[0020] Furthermore, The calculation formula of

[0021]

[0022] In the formula, p terminal is the data transmission power when task k is transmitted from the monitoring device to the edge computing unit, is the latency for the monitoring device to transmit to the edge computing unit.

[0023] Furthermore, The calculation formula is:

[0024]

[0025] In the formula, is the time for task k to wait in line for resource release, is the latency for the data of task k to be transmitted from the monitoring device to the edge computing unit, is the latency of the edge computing unit, r switch is the transmission speed of the currently used network, t processing is the processing latency of the switch and the receiving end, r optic is the data transmission speed, is the data transmission distance, is the data transmission latency, is the network latency. edge is idle indicates that the edge computing unit is in an idle state, that is, there is no computing task.

[0026] Furthermore, The calculation formula is:

[0027]

[0028] In the formula, d (m,k) is the data volume of task k, c (m,k) is the number of CPU cycles required to process 1 bit of task data, f edge is the number of CPU cycles that the edge computing unit can execute per second.

[0029] Furthermore, The calculation formula is:

[0030]

[0031] In the formula, is the latency for the data to be transmitted from the edge computing unit to the cloud computing unit, is the latency of task k in cloud computing, r edge is the channel transmission rate for the edge computing unit to upload task data to the cloud, f cloud is the number of CPU cycles that the cloud computing unit can execute per second.

[0032] Furthermore, r edge The calculation formula is:

[0033]

[0034] In the formula, h is the channel power gain of the edge computing unit, p edge$P$ is the transmission power of the edge computing unit, $n$ is the noise power of the edge computing unit within all bandwidths, and $b$ is the channel bandwidth.

[0035] Furthermore, several edge computing units are provided, and it also includes optimizing the deployment quantity $M$ of the edge computing units; including a cost function $C$:

[0036]

[0037] In the formula, $c$ edge is the deployment cost of each edge computing unit, $K$ m is the total number of tasks received by the $m$-th edge computing unit, is the processing cost of task $k$ in the cloud computing unit, is the processing cost of task $k$ in the edge computing unit;

[0038] The target optimization is described by the following cost minimization function model:

[0039]

[0040] The constraint conditions include:

[0041]

[0042] In the model, is the number of tasks processed in parallel by the edge computing unit $m$, $T$ max is the maximum allowable task processing delay, $Y$ device is the number of monitoring devices, is the set of positive integers.

[0043] The present invention also provides a lightweight health monitoring system for bridge structures based on cloud-edge-end collaborative optimization, which uses the method described above to arrange monitoring devices and edge computing units at the bridge end and build a cloud computing unit in the cloud; the monitoring devices include strain sensors, temperature sensors, acceleration sensors, and / or monitoring cameras, and each monitoring device is connected to the corresponding edge computing unit. The edge computing unit includes an edge computing module and a transmission module, and the transmission module is used to connect to the cloud computing unit.

[0044] The present invention designs a cloud-edge collaborative task scheduling mechanism, which can reasonably allocate tasks to cloud computing or edge computing according to the processing delay and energy consumption of computing tasks, so as to balance system performance and energy consumption. Secondly, based on this cloud-edge collaborative mechanism, an optimal deployment strategy for edge gateways within the system is proposed, and a linear mixed integer programming (MILP) formula with the minimization of operating cost and deployment cost as the objective is modeled to solve the optimal number of edge gateway deployments in a resource-constrained environment, so as to achieve the comprehensive optimization of the SHM system among cost, energy consumption, and working efficiency.

[0045] The present invention can be used to construct a lightweight monitoring system based on computer vision and edge gateways. Important indicators in bridge health monitoring include deflection, strain, temperature, and acceleration. The present invention can achieve remote and multi-measurement point synchronous structural deformation monitoring through vision-based technologies, and simultaneously collect strain, temperature, and acceleration signals. The system takes a compact and multifunctional edge gateway as the core, integrating edge computing, analog signal acquisition, power supply, and data transmission functions for data processing, and has the characteristics of low cost, low energy consumption, and fast and flexible deployment. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0047] Figure 1 is a schematic diagram of the task scheduling mechanism of the present invention;

[0048] Figure 2 is a schematic diagram of the total cost of each number of edge computing units at different running times in Embodiment 2 of the present invention;

[0049] Figure 3 is a schematic diagram of the total energy consumption of each number of edge computing units at different running times in Embodiment 2 of the present invention;

[0050] Figure 4 is a schematic diagram of the task scheduling ratio and average response time in Embodiment 2 of the present invention;

[0051] Figure 5 is a schematic diagram of the total energy consumption of different numbers of edge computing units in Embodiment 2 of the present invention;

[0052] Figure 6 is a schematic diagram of the average task response time under four schemes in Embodiment 2 of the present invention;

[0053] Figure 7 is a schematic diagram of the total energy consumption under four schemes in Embodiment 2 of the present invention;

[0054] Figure 8 is a schematic diagram of the monitoring system of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0055] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0056] Embodiment 1:

[0057] In this embodiment, a task scheduling mechanism based on cloud-edge collaboration is designed for multi-dimensional data calculation tasks in a lightweight system. When the edge gateway receives a task request, it will comprehensively evaluate based on the characteristics of the task (such as task processing delay and energy consumption), and dynamically schedule the calculation task to the local edge computing node or cloud for processing.

[0058] The data received by the edge computing unit is regarded as an independent task unit and submitted for processing in the form of a task flow. Both the cloud and the edge can process tasks. Under high-frequency sampling, the sensor data volume is several to dozens of KB, while the industrial camera image data volume reaches dozens of MB. Therefore, the system load is mainly determined by the image processing task, and we only focus on the consumption of visual monitoring tasks.

[0059] Figure 1 A task scheduling mechanism is described. For the k-th task, the data volume of the task and the number of CPU cycles required to process 1 bit of task data are defined, denoted by d (m，k) and c (m，k) respectively, and the unit of data volume is bit. The computing capabilities of the cloud server and the edge gateway are defined as f cloud and f edge respectively, that is, the number of CPU cycles they can execute per second.

[0060] The task scheduling mechanism determines whether each task k is processed independently by the edge node or by the cloud server. In this process, λ (m，k) is defined as the cloud-edge computing selection variable. When the value of λ (m，k) is 0, it means the task is processed by cloud computing; when the value of λ (m，k) is 1, it means the task is processed by edge computing. Compared with the delay caused by data transmission and task processing, the delay of task division can be ignored. At the same time, for many bridge monitoring and warning tasks, due to the small data volume of the task calculation results, the download or upload time of the calculation results can also be ignored.

[0061] Edge computing model: The task is calculated by the NUC built in the edge computing unit, and the data does not need to be uploaded to the cloud. Assume that the maximum number of parallel tasks of the edge gateway is I. When the number of executed tasks is less than I, new tasks can be received immediately; if the upper limit is reached, new tasks will wait for resource release according to the first-in-first-out (FIFO) principle. Therefore, the task processing delay of edge computing can be divided into the following situations:

[0062]

[0063] Among them, is the time for task k to queue and wait for resource release. is the delay for the data of task k to be transmitted from the terminal device to the NUC, is the delay of edge computing for the task.

[0064] Among them, can be expressed as:

[0065]

[0066] r switch The transmission speed of the currently used network. In this embodiment, a 10 Gigabit Ethernet is taken as an example for illustration, and the transmission rate is 10 Gbps (10,000,000,000 bits per second).

[0067]

[0068] r optic is the data transmission speed, which is 2×10 8 m / s in this embodiment, is the transmission distance. At a transmission distance of 20 m, t optic = 20 / 2×10 8 = 0.0001 ms, which can be ignored compared with other delays.

[0069] t processing is the processing delay of the switch and the receiving end, usually assumed to be between 0.5 ms and 1 ms. Then the terminal transmission can be expressed as:

[0070]

[0071] is the time consumed for task k to be calculated by the edge gateway, and can be calculated as:

[0072]

[0073] Based on the mathematical expression of the delay, the energy consumption of edge computing can be calculated as:

[0074]

[0075] The energy consumption transmitted from the terminal to the edge gateway for task k can be expressed as:

[0076]

[0077] p terminal represents the data transmission power of the task transmitted from the terminal to the edge node.

[0078] The energy consumption generated by the edge gateway for task k can be expressed as:

[0079]

[0080] where ω edge = η(f edge ) 2 is the energy consumption of CPU cycles, and η is the energy consumption coefficient of the edge device according to the chip architecture. It means that it holds for all m and k.

[0081] Cloud computing model: Compared with edge computing, cloud computing needs to additionally consider the data transmission delay from the edge to the cloud and the computing delay in the cloud. For task k, the total delay from data collection to computing completion can be expressed as:

[0082]

[0083] is the delay of data transmitted from the edge gateway to the cloud for computing. is the computing delay of task k in the cloud and can be expressed as:

[0084]

[0085] where r edge is the channel transmission rate at which the edge computing unit uploads the task data to the cloud. According to the Shannon formula, r edge can be expressed as:

[0086]

[0087] h is the channel power gain of the edge computing unit, p edge is the transmission power of the edge computing unit, n represents the noise power of the edge computing unit within all bandwidths, and b is the channel bandwidth.

[0088] When calculating the energy consumption generated by cloud computing, it is considered that the cloud resources are sufficient, so we do not consider the energy consumption brought by cloud computing itself. Based on this, the energy consumption of task k in cloud computing is only the energy consumption generated during the transmission of data from the terminal device to the cloud, which can be expressed as:

[0089]

[0090] where is the energy consumption transmitted from the edge computing unit to the cloud, which can be calculated as:

[0091]

[0092] The edge computing unit introduces a scheduling mechanism. When receiving a task request, it comprehensively evaluates the processing delay and energy consumption to achieve efficient scheduling. Task calculation is closely related to the data structure. To ensure the accuracy of calculation, it is assumed that the edge node and the cloud server need to receive the complete data before starting the calculation. In addition, due to device connection limitations, the data of the same terminal device can only be transmitted to a specific edge computing unit to ensure transmission stability and calculation continuity.

[0093] To more comprehensively evaluate various computing tasks, a discriminant index, that is, the processing cost of task k, is defined in the task scheduling mechanism. The processing cost of task k can be expressed by the following formula:

[0094]

[0095] where c w and c t are the cost weight parameters of energy consumption and processing delay respectively. They are determined through empirical data or monitoring demand situations, and are used to associate the increase and decrease of delay and energy consumption with economic costs such as system monitoring efficiency and power expenditure, and comprehensively evaluate the impacts of both under the same measurement standard. For example, if the bridge SHM system is mainly composed of delay-sensitive applications, then c t can be set significantly higher than c w . Based on this, the task scheduling strategy in the edge gateway, that is, the cloud-edge computing selection λ (m，k) can be intuitively expressed as:

[0096]

[0097] Example 2:

[0098] Based on Example 1, this example further optimizes the hardware deployment cost of the SHM system, aiming to balance the system operation cost and the resource deployment cost.

[0099] Due to the task scheduling λ (m，k) and the operation cost Crun and the deployment cost C depoly are interrelated and their interdependencies need to be considered. First, the operating cost C of the SHM system run and the deployment cost C depoly can be calculated as:

[0100]

[0101] C depoly = Mc edge

[0102] where M is the number of edge computing unit deployments, K m is the total number of tasks received by the m-th edge computing unit, and c edge is the deployment cost of each edge computing unit. Thus, we can obtain the total cost function C of the SHM system:

[0103]

[0104] On the premise of comprehensively considering the deployment cost and operating cost, the optimization goal is the number of edge computing unit deployments M to minimize the total system cost. Based on this, the target optimization problem in this paper can be described by the following model, which is the cost minimization function:

[0105]

[0106] The constraints include:

[0107]

[0108]

[0109] In the model, represents the number of tasks processed in parallel by edge computing unit m, and T max is the maximum allowable task processing delay, Y device is the number of monitoring devices. Due to the limitation of device connections, if the number of edge computing units is greater than the number of monitoring devices, it will cause the edge computing units to be idle. When considering the limitation of parallel task processing, it is necessary to ensure that the memory and CPU requirements of parallel tasks do not exceed the device processing capacity. The model parameters are interrelated and depend on the value of M, making the problem a mixed integer linear programming (MILP). Gurobi is used to solve this problem, and the optimal solution or approximate solution can be found within a limited time through the branch and bound algorithm and heuristic method to minimize the total system cost. The feasibility of the method is verified through an actual engineering case below.

[0110] In this embodiment, a lightweight monitoring system for a cross-river arch bridge is designed as an example for illustration, and based on this, the effectiveness of the proposed cloud-edge collaborative optimization method is evaluated. The system includes a total of 10 monitoring cameras, 10 inclinometers, 30 strain gauges, and 16 temperature sensors. The edge computing unit provides edge computing, sensor signal acquisition, and data transmission on-site.

[0111] According to the established MILP optimization objective problem model, the edge computing capacity of the edge computing unit, the computing capacity of the cloud server, the transmission power of the edge gateway, the data scale of the computing task, the maximum task response time, etc. are used as inputs, and the optimal number of edge computing unit deployments, the total cost, the total energy consumption, and the average task response time are used as outputs.

[0112] The MILP objective optimization problem is solved by the standard MILP solver Gurobi 9.0.1. Under the Windows 10 operating system, a simulation environment is built based on the Python 3.7 platform. The main input parameter settings are shown in the table:

[0113]

[0114]

[0115] On the premise of ensuring the timeliness of computing task processing, the optimal number of edge computing unit deployments is obtained by solving the established MILP problem, and the total cost of different deployment schemes is shown when the system runs for 4 days, 30 days, 180 days, 365 days, and 720 days, as Figure 2 shown.

[0116] It can be seen that in the initial stage of system operation (10 days), under different numbers of edge computing unit deployments, the total cost almost increases in proportion, and the cost mainly comes from the deployment cost of the edge computing unit. The performance is optimal when M = 2. As the operation time extends and the number of tasks increases, the proportion of the deployment cost gradually decreases, and the main source of the total cost becomes the computing task. Under long-term operation, the total cost of M = 2 gradually exceeds other cases, and M = 4 shows the lowest cost when running for 180 days, 365 days, and 730 days, indicating that it has better balance among various indicators and is a more cost-effective choice in the current monitoring scenario.

[0117] Under the optimal deployment scheme M = 4, the energy consumption and task processing delay of the lightweight bridge SHM system and the traditional centralized system are compared. The traditional system uses two NIPXIe-1082 to connect each sensor through a star connection, and the tasks are centrally processed by an on-site industrial computer. Figure 3It shows that the task processing delay of the lightweight SHM system is similar to that of the traditional system, both about 2.5 seconds, and there is almost no significant fluctuation in the long-term operation delay, indicating that the lightweight system can be comparable to the high-computing centralized system in real-time online computing tasks, ensuring long-term stable operation.

[0118] As the running time increases, the energy consumption difference gradually appears. The difference is not obvious in the initial stage of operation, but after 60 days, the energy consumption of the traditional system increases to 4.77E8 J, while that of the lightweight system is only 4.52E7 J, saving about 4.3E8 J of energy consumption, which is equivalent to reducing 62.69 kg of carbon emissions, showing its significant advantages in energy conservation and emission reduction, as Figure 3 shown.

[0119] This embodiment analyzes the effect of the cloud-edge collaboration mechanism on system optimization, and shows the total energy consumption and average task response time of the system within 24 hours under different conditions. Generally speaking, increasing the number of edge computing units effectively reduces the task response time, but also significantly increases the system energy consumption.

[0120] Figure 4 It shows that as the number of edge computing units increases, more tasks are assigned to the edge for processing, reducing the high delay caused by cloud transmission. The average task delay gradually decreases as the number of edge computing units increases, proving the effectiveness of the cloud-edge scheduling mechanism.

[0121] Figure 5 It shows that the system energy consumption increases with time, and the more edge computing units there are, the faster the energy consumption grows, indicating that increasing the number of edge computing units can reduce the delay but increase the energy consumption. Therefore, it is necessary to find a balance between the number of device deployments and energy consumption to avoid low efficiency improvement and cost increase caused by over-deployment.

[0122] The cloud-edge collaboration mechanism combines the low latency of the edge and the high computing power of the cloud, and has significant advantages in terms of performance and resource utilization. To verify its effect, we compared it with four scheduling modes: (1) Cloud-only: all tasks are processed in the cloud; (2) Edge-only: tasks are preferentially assigned to the edge node with the most sufficient resources; (3) Random: tasks are randomly assigned; (4) Random mode: computing tasks are randomly assigned between the edge and the cloud. The comparison results under the optimal deployment M = 4 are as Figures 6-7 shown.

[0123] Figure 6The results show that there are significant differences in the average task response time among different scheduling strategies. When the task volume is small, the response times of all strategies are relatively low. However, when the task volume exceeds 100, the response times of the Edge-only and Random strategies increase sharply. In particular, when the task volume reaches 1500, the latency of the Edge-only strategy is close to 80 seconds, indicating queue congestion caused by insufficient processing capacity at the edge. In contrast, the proposed method and the Cloud-only strategy maintain stable response times during task growth. Among them, the Cloud-only strategy is slightly higher (5 - 6 seconds), while the proposed method is about 2 seconds, which is suitable for high-real-time scenarios.

[0124] Figure 7 Figure shows the total energy consumption of different strategies. The Cloud-only strategy has the lowest energy consumption because it only considers communication energy consumption and ignores computational energy consumption. The proposed method also performs excellently in terms of energy consumption, always remaining at a relatively low level. The energy consumption of the Edge-only strategy increases rapidly after the task volume exceeds 500, making it difficult to handle large-scale tasks. The energy consumption of the Random mode is between that of the Edge-only strategy and the proposed method, as random allocation fails to effectively reduce energy consumption.

[0125] Example 3:

[0126] See Figure 8 , the main components of the lightweight system and the edge gateway designed in this embodiment include a data acquisition module, an edge computing module, and a 5G transmission module. It can be externally connected to various sensors such as strain, temperature, and acceleration sensors, as well as multiple monitoring cameras, forming a flexible monitoring network, which can provide the system with the capabilities of edge computing, data acquisition, and transmission.

[0127] The core of the lightweight system is to use visual technology through monitoring cameras to achieve synchronous and precise monitoring of bridge multi-point deformations with the advantages of long-distance and multi-target, so as to reduce the deployment of sensors. The method combines the centroid recognition of the light spot of the infrared target and the light spot centroid tracking algorithm, considering environmental factors such as strong light, rain, and fog at the engineering site, as well as the feature point matching problem under long-distance and large field of view, with high accuracy and strong robustness. The visual algorithm is embedded in the edge computing module. The edge computing module uses a NUC equipped with an Intel i5-1135G7, providing 4 USB-C interfaces, 2 Thunderbolt 4 interfaces, and 3 RJ45 interfaces. The Monitoring camera is connected to the NUC through the RJ45 interface. The edge computing module converts the image data collected by the monitoring camera in real time from two-dimensional images to one-dimensional deformation data through its edge computing ability.

[0128] Monitoring of bridge responses such as strain, temperature, and acceleration is still indispensable. The acquisition module is used for collecting analog signals of such sensors. The acquisition module uses the STM32F407ZGT6 microcontroller produced by STMicroelectronics. The microcontroller is based on -M4 core, which balances computing performance and energy consumption efficiency. When all peripherals are enabled at a maximum operating frequency of 168 MHz, the current consumption is approximately 90 mA. The microcontroller supports multiple communication interfaces such as SPI, I2C, SDIO, CAN, and USART. To expand storage, the microcontroller is equipped with 1 Mbyte of SRAM and 16 Mbytes of reprogrammable flash memory, and connects an SD card through SDIO to back up sensor data to prevent data loss caused by transmission interruption.

[0129] A single acquisition module uses two 16-bit eight-channel analog-to-digital converters AD7606 produced by Texas Instruments, which can simultaneously convert 16 analog sensor signals into digital signals for the microcontroller to use. Among them, 8 channels are used for temperature measurement and 8 channels are used for strain measurement. In acceleration measurement, the microcontroller can be connected to multiple MEMS accelerometers through the CAN bus that supports multi-master communication, and the internal circuit of the accelerometer converts the analog signal into a digital signal. In the designed sensing module, the PCB of the peripheral signal acquisition circuit is connected to the PCB of the embedded computing module through a pin connector.

[0130] The acquisition module is connected to the edge computing module through a USB-C interface, which supports 5V power and bidirectional high-speed data transmission. The independent pin design improves reliability. The edge computing module is powered by 12VAC, and the USB-C connection facilitates flexible expansion of sensor channels. Multi-source heterogeneous data is centrally preprocessed in the edge computing module, stored locally or transmitted to the cloud through a 5G module to achieve remote processing and real-time monitoring. The integrated design simplifies the data transmission and power supply path, and has the advantages of miniaturization, multi-function, and flexible expansion.

[0131] This embodiment can be used to construct a lightweight monitoring system based on computer vision and edge gateways. Important indicators in bridge health monitoring include deflection, strain, temperature, and acceleration. Remote and multi-point synchronous structural deformation monitoring can be achieved through vision-based technologies, and strain, temperature, and acceleration signals can be collected simultaneously. The system takes a compact and multi-functional edge gateway as the core, integrating edge computing, analog signal acquisition, power supply, and data transmission functions for data processing, and has the characteristics of low cost, low energy consumption, and fast and flexible deployment.

[0132] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalent technologies, the present invention also intends to include these modifications and variations.

Claims

1. A lightweight health monitoring method for bridge structure based on cloud-edge-device collaborative optimization, characterized in that: The following steps are involved: S1. Deploy monitoring devices and edge computing units at the bridge end and build cloud computing units in the cloud; S2. When receiving a task request, evaluate the processing delay and energy consumption, and calculate the processing cost of task k. The calculation formula is: Among them, c w and c t are the cost weight parameters for energy consumption and processing delay, respectively. is the energy consumption of task k transmitted from the monitoring device to the cloud, is the task processing latency of the cloud computing unit, Calculate the energy consumption of task k for the edge computing unit, The task processing latency of the edge computing unit; S3. Define λ (m,k) Select variables for cloud-edge computing and schedule them; if λ (m,k) Assign a value of 0, and task k is processed by the cloud computing unit; if λ (m,k) The value is assigned to 1, and task k is calculated and processed by the edge computing unit.

2. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 1 is characterized in that: The calculation formula is: In the formula, is the energy consumption of task k transmitted from the monitoring device to the edge computing unit, is the energy consumption of task k transferred from the edge computing unit to the cloud computing unit, p edge is the transmit power of the edge computing unit, is the latency of the edge computing unit uploading task data to the cloud, d (m,k) is the amount of data for task k, r edge It is the channel transmission rate for the edge computing unit to upload task data to the cloud.

3. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 1 is characterized in that: The calculation formula is: oh edge =η(f edge ) 2 In the formula, is the energy consumption of task k in the edge computing unit, c ( m,k ) is the number of CPU cycles required to process 1 bit of task data, ω edge is the energy consumption of the edge computing unit CPU cycle, η is the energy consumption coefficient of the edge computing unit determined according to the chip architecture, and f edge It is the number of CPU cycles that the edge computing unit can execute per second.

4. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to any one of claims 2-3 is characterized in that: The calculation formula is: In the formula, ptermina l is the data transmission power of task k from the monitoring device to the edge computing unit, It is the latency from the monitoring device to the edge computing unit.

5. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 1 is characterized in that: The calculation formula is: In the formula, is the time that task k needs to wait in line for resource release, is the latency of transmitting the data of task k from the monitoring device to the edge computing unit, is the latency of the edge computing unit, r switch is the transmission speed of the current network, t processing is the processing delay between the switch and the receiver, r optic is the data transmission speed, is the data transmission distance, is the data transmission delay, It is the network delay.

6. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 5 is characterized in that: The calculation formula is: Where, d (m,k) is the data volume of task k, c (m,k) is the number of CPU cycles required to process 1 bit of task data, f edge It is the number of CPU cycles that the edge computing unit can execute per second.

7. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 1 is characterized in that: The calculation formula is: In the formula, is the latency of data transmission from the edge computing unit to the cloud computing unit, is the computing latency of task k in the cloud, r edge is the channel transmission rate for the edge computing unit to upload task data to the cloud, f cloud It is the number of CPU cycles that the cloud computing unit can execute per second.

8. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 7 is characterized in that: r edge The calculation formula is: Where h is the channel power gain of the edge computing unit, p edge is the transmit power of the edge computing unit, n is the noise power of the edge computing unit in all bandwidths, and b is the channel bandwidth.

9. The lightweight health monitoring method for bridge structure based on cloud-edge-end collaborative optimization according to claim 1 is characterized in that: The edge computing units are provided with a plurality of edge computing units, and also include optimizing the number of edge computing units deployed M; including a cost function C: In the formula, c edge K is the deployment cost of each edge computing unit. m is the total number of tasks received by the mth edge computing unit, is the processing cost of task k in the cloud computing unit, is the processing cost of task k in the edge computing unit; The target optimization is described by the following cost minimization function model: The constraints include: In the model, is the number of tasks processed in parallel by edge computing unit m, T max is the maximum allowed task processing delay, Y device is the number of monitoring devices, I is the maximum number of parallel tasks of the edge computing unit, is a set of positive integers.

10. A lightweight health monitoring system for bridge structures based on cloud-edge-end collaborative optimization, using the method described in any one of claims 1 to 9, characterized in that: A monitoring device and an edge computing unit are arranged at the bridge end, and a cloud computing unit is built in the cloud; the monitoring device includes a strain sensor, a temperature sensor, an acceleration sensor and / or a monitoring camera, and each monitoring device is connected to a corresponding edge computing unit; the edge computing unit includes an edge computing module and a transmission module, and the transmission module is used to connect to the cloud computing unit.

Images