Data supervision method and system for engineering project, electronic equipment and program product

Abstract

The invention provides a data supervision method and system for an engineering project, electronic equipment and a program product, and relates to the technical field of computers. The data supervision method disclosed by the invention comprises the following steps: acquiring a field image acquired by an information acquisition terminal at a construction field; image recognition is carried out according to the field image, a corresponding image recognition result is determined, and the image recognition result is used for representing whether a risk event exists in the field image or not; determining a data hash value corresponding to the field image according to the field image; storing the field image and the corresponding image recognition result in an under-chain storage space, and determining a corresponding content addressing identifier; and uploading the content addressing identifier, the data hash value and the corresponding time information to a block chain network for evidence storage. According to the technical scheme, a high-cost server cluster does not need to be deployed due to a centralized system, the supervision data cannot be tampered, and the effectiveness of the supervision data is guaranteed.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a data supervision method, system, electronic equipment, and program product for an engineering project. Background Art

[0002] The large number and widespread distribution of small, decentralized projects make their supervision difficult. Current technical solutions rely primarily on manual construction logs, which cannot guarantee the legal validity of supervisory data. Furthermore, the difficulty in obtaining reliable on-site data in real time hinders the improvement of supervisory effectiveness. Summary of the Invention

[0003] The present disclosure provides a data supervision method, system, electronic equipment and program product for an engineering project.

[0004] According to one aspect of the present disclosure, a data supervision method for an engineering project is provided, comprising: acquiring a field image collected by an information collection terminal at a construction site; performing image recognition based on the field image to determine a corresponding image recognition result, wherein the image recognition result is used to characterize whether a risk event exists in the field image; determining a data hash value corresponding to the field image; storing the field image and its corresponding image recognition result in an off-chain storage space to determine a corresponding content addressing identifier; and uploading the content addressing identifier, the data hash value, and the corresponding time information to a blockchain network for evidence storage.

[0005] According to one aspect of the technical solution, an on-site image captured by an information collection terminal at a construction site is acquired, and image recognition is performed on the on-site image to determine a corresponding image recognition result. This image recognition result is used to indicate whether a risk event exists in the on-site image. Next, based on the on-site image, a corresponding data hash value is determined. The on-site image and its corresponding image recognition result are stored in an off-chain storage space, and a corresponding content-addressable identifier is determined. The content-addressable identifier, data hash value, and corresponding time information are then uploaded to the blockchain network for evidence storage.

[0006] In this way, by acquiring corresponding on-site images at the construction site through the information collection terminal, the validity of the acquired on-site images can be guaranteed, preventing the generation of false records. Furthermore, the on-site images and their corresponding image recognition results are stored in an off-chain storage space, and the corresponding content addressing identifier, data hash value, and time information are then recorded as evidence on the blockchain network. This achieves a dual-link evidence structure of off-chain storage and on-chain hashing, eliminating the need for the high-cost deployment of server clusters required by centralized systems, making regulatory data tamper-proof, and ensuring the judicial validity of regulatory data.

[0007] According to a data supervision method for an engineering project of at least one embodiment of the present disclosure, a data hash value corresponding to the on-site image is determined, including: determining a corresponding image hash value based on the on-site image; determining a corresponding data hash value based on the image hash value, the acquisition time corresponding to the on-site image, and the device identification and positioning information corresponding to the information acquisition terminal that acquired the on-site image.

[0008] According to the technical solution of this embodiment, multiple information can be integrated to generate a unique hash value that can represent all key information, so as to facilitate subsequent storage and verification in related systems such as blockchain.

[0009] According to a data supervision method for an engineering project of at least one embodiment of the present disclosure, a corresponding image hash value is determined based on the on-site image, including: compressing the on-site image into JPEG format; and determining the corresponding image hash value based on the compressed on-site image and its corresponding EXIF ​​metadata.

[0010] According to the technical solution of this embodiment, by compressing the on-site images, the size of the image file can be significantly reduced, the storage space occupied and the amount of data during the transmission process can be reduced, the storage efficiency and transmission speed can be improved, and the storage and bandwidth costs can be reduced.

[0011] According to the data supervision method for engineering projects of at least one embodiment of the present disclosure, the method also includes: determining the content addressing identifier corresponding to the data to be verified based on the received data verification request; determining the corresponding on-chain data hash value stored in the blockchain network based on the content addressing identifier; obtaining the corresponding on-site image from the off-chain storage space based on the content addressing identifier; determining the corresponding off-chain data hash value based on the on-site image obtained from the off-chain storage space; comparing the on-chain data hash value with the off-chain data hash value; and generating a corresponding electronic verification report based on the comparison result.

[0012] The technical solution of this embodiment provides reliable electronic evidence for the verification of on-site image data based on the generated electronic verification report. This report, which records detailed comparison information and results, can be used to verify the integrity and authenticity of on-site image data, providing strong support for dispute resolution and liability determination in the supervision of small and scattered projects.

[0013] According to a data supervision method for an engineering project of at least one embodiment of the present disclosure, obtaining on-site images collected by an information collection terminal at a construction site includes: obtaining on-site images collected by the information collection terminal at the construction site in response to a data analysis request sent by a central server; or receiving on-site images collected at the construction site sent by a paired information collection terminal. According to the technical solution of this embodiment, it can adapt to different construction site environments and supervision requirements, so that the data supervision system has good scalability and can be upgraded and expanded accordingly as the scale and complexity of the project increase.

[0014] According to the data supervision method for engineering projects of at least one embodiment of the present disclosure, the on-site image and its corresponding image recognition result are stored in the off-chain storage space, and the corresponding content addressing identifier is determined, including: uploading the on-site image and its corresponding image recognition result to the InterPlanetary File System for storage, and determining the content identifier corresponding to the contents of the two. According to the technical solution of this embodiment, there is no need to build and maintain a large centralized storage data center. Data can be stored with the help of existing resources in the IPFS network, thereby saving a lot of hardware equipment investment and operation and maintenance costs.

[0015] According to the data supervision method for engineering projects of at least one embodiment of the present disclosure, the on-site image is obtained by the information collection terminal based on the detection information of the sensor or by triggering the collection action according to the target time period, and the sensor includes at least one of an accelerometer, a gyroscope, a decibel detection sensor and a light intensity sensor.

[0016] According to the technical solution of this embodiment, various image information of the construction site can be obtained comprehensively and timely, including not only conventional images under normal construction conditions, but also key images under sudden abnormal conditions, realizing all-round and multi-level visual monitoring of the construction site, and providing rich and accurate first-hand image data for project supervision. According to the data supervision method for engineering projects of at least one embodiment of the present disclosure, after storing the on-site image and its corresponding image recognition result in the off-chain storage space and determining the corresponding content addressing identifier, the method further includes: if there is a target risk event in the on-site image, generating an alarm message according to the content addressing identifier and positioning information corresponding to the on-site image; and sending the alarm message to the supervision platform.

[0017] According to the technical solution of this embodiment, it can ensure that supervisors can be informed of risk events at the construction site in the first time and take timely measures to deal with them, thereby reducing potential safety risks and losses. According to another aspect of the present disclosure, a data supervision system for an engineering project is provided, comprising: an information collection terminal for acquiring on-site images at a construction site; an information processing terminal for executing a method as described in any of the aforementioned embodiments; and a blockchain network for storing evidence data uploaded by the information processing terminal.

[0018] According to at least one embodiment of the present disclosure, the data supervision system for an engineering project further includes: The central server is used to allocate data analysis tasks to the information processing terminals according to the load information of the information processing terminals.

[0019] According to another aspect of the present disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, so that the processor executes the data supervision method for the engineering project of any embodiment of the present disclosure.

[0020] According to another aspect of the present disclosure, a readable storage medium is provided, in which execution instructions are stored. When the execution instructions are executed by a processor, the data supervision method for the engineering project of any embodiment of the present disclosure is implemented.

[0021] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, wherein when the computer program is executed by a processor, the data supervision method for an engineering project according to any embodiment of the present disclosure is implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings illustrate exemplary embodiments of the present disclosure and together with the description serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0023] Figure 1 A schematic diagram of a data supervision system for an engineering project according to an embodiment of the present disclosure is shown.

[0024] Figure 2 A flow chart of a data supervision method for an engineering project according to an embodiment of the present disclosure is shown.

[0025] Figure 3 A flow chart of step S230 in a method for data supervision of an engineering project according to an embodiment of the present disclosure is shown.

[0026] Figure 4 A flow chart of step S231 in a method for data supervision of an engineering project according to an embodiment of the present disclosure is shown.

[0027] Figure 5 A schematic diagram of a process of data verification included in a data supervision method for an engineering project according to an embodiment of the present disclosure is shown.

[0028] Figure 6A schematic diagram of the process of event alarms included in the data supervision method for an engineering project according to an embodiment of the present disclosure is shown.

[0029] Figure 7 A schematic diagram of the interaction process of a data supervision system for an engineering project according to an embodiment of the present disclosure is shown.

[0030] Figure 8 A schematic diagram of the flow of data collection and data processing in a data supervision system for an engineering project according to an embodiment of the present disclosure is shown.

[0031] Figure 9 A flow chart of the data evidence storage phase and the data evidence collection phase in a data supervision system for an engineering project according to an embodiment of the present disclosure is shown.

[0032] Figure 10 is a schematic structural block diagram of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0033] The present disclosure is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are intended only to illustrate the relevant content and are not intended to limit the present disclosure. It should also be noted that, for ease of description, only the portions relevant to the present disclosure are shown in the accompanying drawings.

[0034] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in the present disclosure can be combined with each other. The technical solution of the present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0035] In the supervision scenarios of small, decentralized projects (such as temporary construction and high-altitude operations), the traditional centralized supervision model faces three main challenges: lack of trustworthy on-site data: manually filled-in construction logs are easy to tamper with, making it difficult to trace the true responsible party; delayed response to safety hazards: the average response time to accidents is greater than 48 hours, and high-risk behaviors cannot be intercepted in time; serious waste of hardware resources: centralized systems require the deployment of high-cost server clusters, but the unstable network environment on the construction site leads to low resource utilization.

[0036] To this end, the present disclosure proposes the following technical solution, wherein, in this technical solution, corresponding on-site images are obtained at the construction site through an information collection terminal, which can ensure the validity of the obtained on-site images and avoid the generation of false records. In addition, the on-site images and their corresponding image recognition results are stored in an off-chain storage space, and the corresponding content addressing identifier, data hash value, and time information are then recorded on the blockchain network. This realizes a dual-link evidence structure of off-chain storage and on-chain hashing. This not only eliminates the need to deploy high-cost server clusters due to centralized systems, but also makes the regulatory data tamper-proof and ensures the judicial validity of the regulatory data.

[0037] Figure 1 A schematic diagram of the framework of a data monitoring system for an engineering project according to one embodiment of the present disclosure is shown. This data monitoring system may include an information collection terminal 101, an information processing terminal 102, and a blockchain network 103. Information collection terminal 101 may be a terminal device, such as a hard hat, that integrates a low-power camera and a Bluetooth module. It can capture on-site images during construction, providing raw visual data for subsequent analysis and monitoring.

[0038] Information processing terminal 102 can be an electronic device such as a smartphone, tablet, or laptop. It can be equipped with a lightweight AI model to perform real-time analysis of on-site images received from information collection terminal 101, identifying violations, etc. Information processing terminal 102 can extract key frames from on-site images and generate corresponding data hash values. It is also responsible for storing the original on-site images in off-chain storage (not shown) and submitting relevant data to blockchain nodes for evidence storage.

[0039] The blockchain network 103 may include several blockchain nodes, which can be divided into full nodes and light nodes. Full nodes operated by regulatory agencies can store complete blockchain data, participate in consensus verification and block generation, etc. The light nodes built into the information processing terminal 102 are primarily responsible for submitting hash evidence transactions, initiating SPV verification requests, and synchronizing block header data, thereby implementing trusted data storage and verification functions.

[0040] In some embodiments of the present disclosure, the data supervision system may further include a central server (not shown in the figure), which may be used to assign corresponding data analysis tasks to the information processing terminal 102 based on the load information uploaded by the information processing terminal 102 to achieve resource scheduling.

[0041] In some embodiments of the present disclosure, Figure 1As shown, the data supervision system may also include a supervision platform 104 and a dynamic resource pool 105. The supervision platform 104 serves as a hub for supervisors to conduct real-time monitoring and intervention. It receives alerts pushed by the information processing terminal 102, allowing supervisors to manually review events on this platform. Based on the review results, supervisors can issue corrective action instructions to the project owner's mobile device, thereby achieving effective supervision of small and scattered projects.

[0042] Dynamic resource pool 105 can contain several idle nodes (including smartphones, servers, etc.) that can participate in edge cloud computing. Various cloud resource nodes can participate in cloud computing, thereby reducing the load on central servers. As a core resource management and allocation platform, it receives status information from information processing terminals and dynamically schedules resources based on load status reported by smartphones and cloud nodes. This allows for the proper allocation of computing tasks, improving overall system resource utilization and ensuring efficient task execution.

[0043] Figure 2 FIG. 1 shows a flow chart of a data supervision method for an engineering project according to an embodiment of the present disclosure, which can be used in the aforementioned information processing terminal 102. Figure 2 As shown, the data supervision method of the engineering project includes at least steps S210 to S250, which are described in detail as follows.

[0044] In step S210, the on-site images collected by the information collection terminal at the construction site are obtained. The on-site images can be image data that can reflect various conditions such as the construction site conditions, personnel working status, equipment and facility conditions, and the surrounding environment, thereby providing important data support for subsequent project supervision, safety inspections, and problem tracing.

[0045] In this embodiment, construction workers may carry an information collection terminal during the construction process, and the information collection terminal may photograph the construction site during the construction process, thereby collecting on-site images.

[0046] In one example, the camera of the information collection terminal uses the OV5640 low-power CMOS sensor with a resolution of 720P@30fps, an encoding format of H.265 / HEVC, and a 120° wide-angle viewing angle. It can meet the shooting needs of different scenes at the construction site, and its low power consumption characteristics adapt to the limited power supply that may exist at the construction site.

[0047] Additionally, the information collection terminal can be equipped with a Bluetooth communication module, which can be paired with the information processing terminal to enable data transmission. In one example, the Bluetooth communication module can use the BLE 5.0 protocol, support a 2Mbps transmission rate, and a transmission distance of up to 50 meters (line of sight). It also features AES-128 hardware encryption, ensuring the security and stability of image data transmission, allowing the terminal to effectively pair and connect with information processing devices (such as mobile phones).

[0048] In this way, the information processing terminal can transmit the collected scene images to the information processing terminal through the Bluetooth communication module, and the information processing terminal can perform subsequent processing based on the received scene images.

[0049] In some embodiments of the present disclosure, the on-site image can be obtained by the information collection terminal based on the detection information of the sensor configured by itself or by triggering the collection action according to the target time period. The sensor includes at least one of an accelerometer, a gyroscope, a decibel detection sensor, and a light intensity sensor.

[0050] In this way, the information collection terminal can adopt one or more of the following shooting trigger strategies when collecting on-site images.

[0051] Timed baseline sampling: Every 5 minutes (i.e., the aforementioned target time period), one frame of 720PJPEG format image is automatically captured with a quality factor of 80%. An image file named with a timestamp, such as "20231001_120500_hat001.jpg," is generated and transmitted to the information processing terminal via Bluetooth. This method can regularly record routine images of the construction site, facilitating subsequent macro-control of construction progress and status.

[0052] Sensor emergency trigger: Utilizing sensors such as the accelerometer and gyroscope configured on the information collection terminal, when an acceleration value > 3G or a gyroscope angular velocity > 30° / second is detected, 1080P@30fps recording is initiated for 10 seconds, and key frames (the first and last frames) are captured, with key frames being prioritized for transmission. For example, in the event of an emergency such as a falling object or collision, images of the moment of the accident and the period immediately preceding and following the accident can be recorded, providing critical evidence for accident analysis and liability determination.

[0053] Audio linkage trigger: When the decibel detection sensor (such as a microphone) on the information collection terminal detects a noise level of 80dB or above (such as an impact sound) that lasts for more than 2 seconds, it triggers continuous screenshots, taking 1 frame per second, for a total of 5 frames, and attaching an audio waveform clip (WAV format, 8kHz sampling rate). The combination of images and audio can more comprehensively reflect abnormal conditions at the construction site, facilitating accurate judgment of the nature and severity of the incident.

[0054] Sudden light change trigger: When the light intensity sensor on the information collection terminal detects a brightness change rate of >50% / second (such as welding flash), it takes three consecutive frames with an interval of 0.5 seconds to record the light intensity value sequence. This can effectively capture relevant images for some special light changes at the construction site, avoiding construction safety hazards caused by sudden light changes or the problem of illegal operations not being recorded.

[0055] In this way, based on the above shooting trigger strategy, various image information of the construction site can be obtained comprehensively and timely, including not only conventional images under normal construction conditions, but also key images under sudden abnormal conditions, realizing all-round and multi-level visual monitoring of the construction site, and providing rich and accurate first-hand image data for project supervision.

[0056] In one embodiment, after the information collection terminal captures the on-site image, it can compress the captured on-site image before transmitting it. For example, H.265 encoding can be used to compress the 720P image to about 100-200KB / frame, reducing the amount of data and improving transmission efficiency, while retaining the key information and details of the image to ensure the accuracy of subsequent analysis.

[0057] In addition, metadata in JSON format can be embedded in each frame of the on-site image, including timestamps, GPS coordinates, sensor readings, device IDs, and other information. These metadata provide rich contextual information for the image, making the image not just a visual picture, but also possessing multi-dimensional attributes such as time, space, and environment, providing strong support for subsequent precise supervision and problem tracing.

[0058] Please continue to refer to Figure 2 In step S220, image recognition is performed based on the scene image to determine a corresponding image recognition result, and the image recognition result is used to characterize whether there is a risk event in the scene image.

[0059] Among them, risk events can be various situations or accidents at the construction site that may have an adverse impact on personnel safety, project quality, construction progress, etc., such as personnel not wearing safety helmets, people entering dangerous areas, exposed wires, fire smoke, etc.

[0060] In this embodiment, after receiving on-site images captured by the information collection terminal, the information processing terminal can invoke its own lightweight object detection model (e.g., pruned and optimized YOLOv8s) to perform real-time analysis of the on-site images, thereby identifying risk events. The model can output corresponding image recognition results (including labels and their corresponding confidence levels) and keyframe images.

[0061] In one embodiment, when the model detects a risk event in an on-site image and the confidence level exceeds a certain threshold, in addition to capturing the current frame, it can also capture two frames before and after it as corresponding key frames for further analysis and recording. This allows timely capture of relevant image information at the moment the risk event occurred and its surroundings, providing more comprehensive and accurate evidence support for subsequent accident analysis and liability determination.

[0062] In this way, by using the lightweight target detection model carried by the information processing terminal to perform real-time identification and analysis of on-site images, it is possible to determine whether there are risk events at the construction site in a relatively short period of time, realize real-time risk monitoring and early warning of small and scattered projects, effectively shorten the accident response time, and reduce accident losses.

[0063] In step S230, a data hash value corresponding to the scene image is determined based on the scene image. The information processing terminal may employ a hash algorithm based on the scene image (which may be each frame of the scene image used for image recognition, or a key frame image determined from multiple scene images after a risk event is identified) to obtain the data hash value corresponding to the scene image. It should be understood that this data hash value is unique and can be used to identify data integrity.

[0064] In one embodiment, the information processing terminal may generate a data hash value based solely on the scene image. In other embodiments, the information processing terminal may also generate a corresponding data hash value in combination with other relevant data.

[0065] In step S240, the scene image and its corresponding image recognition result are stored in an off-chain storage space, and the corresponding content addressing identifier is determined. The off-chain storage space can be an external storage system different from the storage space of the blockchain itself.

[0066] A content-addressable identifier (CAI) can be generated by a specific algorithm based on the stored file content (i.e., the scene image and its corresponding image recognition result). It should be noted that the CAI corresponds to the file content. Whenever the file content changes, the corresponding CAI will also change. Therefore, the CAI can accurately locate and retrieve specific files stored in off-chain storage space.

[0067] In this embodiment, the information processing terminal can associate (e.g., package) the production restriction image to be stored with its corresponding image recognition result. The image recognition result can be stored in a structured data format, such as JSON format, and contain information about various detected risk events, detection locations, confidence levels, etc. This information is then associated with the corresponding on-site image.

[0068] To facilitate storage and transmission in off-chain storage space, on-site images can be converted to JPEG format, image recognition results can be kept in JSON format, or the two can be combined into a compliant file format (such as ZIP format, etc.) to ensure data integrity and readability.

[0069] Then, the information processing terminal can transmit the associated processed on-site images and image recognition results to the off-chain storage space for storage, and receive the content addressing identifier corresponding to the stored content fed back by the off-chain storage space.

[0070] In this way, the content-addressable identifier (CAI) of each file is calculated based on the file content, making it unique and immutable. Once the on-site image and its image recognition results are stored in off-chain storage, any tampering with the data will result in a change in the CAI. Therefore, by verifying the consistency of the CAI, the security and integrity of the data can be ensured, providing reliable protection for subsequent data use.

[0071] In step S250, the content addressing identifier, the data hash value and the corresponding time information are uploaded to the blockchain network for storage.

[0072] Among them, a blockchain network can be a distributed ledger technology architecture composed of multiple nodes, each of which stores a copy of the ledger. In the technical solution disclosed herein, a permissioned private chain can be adopted, with the regulator operating the full node and mobile phones and other information processing terminals having built-in blockchain light nodes. It should be understood that the blockchain network has the characteristics of decentralization, immutability, and data transparency, making it suitable for scenarios such as data storage and traceability, and can provide a trusted data storage and verification environment for the supervision of small and scattered projects.

[0073] In this embodiment, the information processing terminal can organize and encapsulate the content addressing identifier, data hash value, and corresponding timestamp information to form a standard evidence transaction data structure. The timestamp can be in Coordinated Universal Time or local time format and accurate to the second, thereby ensuring the accuracy and uniqueness of the time information.

[0074] Next, the blockchain light node built into the information processing terminal can call the smart contract and submit the above information to the private chain network. After the private chain full node passes the SPV (Simplified Payment Verification) verification, the transaction record is written into the block.

[0075] In this way, leveraging the blockchain's immutable nature, once data such as content addressing identifiers, data hash values, and time information are uploaded to the blockchain network and stored, they are permanently recorded on the blockchain, making any tampering impossible, thereby ensuring the data's authenticity and credibility. This provides a solid legal basis and evidentiary support for the supervision of small and scattered projects, enabling regulatory authorities, project owners, and other relevant parties to reach a consensus on the authenticity of data such as on-site images and their recognition results, thereby enhancing the credibility and authority of supervision.

[0076] based on Figure 2 The illustrated embodiment acquires on-site images captured by an information collection terminal at the construction site, performs image recognition on the images, and determines corresponding image recognition results. This image recognition result is used to indicate whether a risk event exists in the on-site images. Next, based on the on-site images, a corresponding data hash value is determined. The on-site images and their corresponding image recognition results are stored in off-chain storage, and a corresponding content-addressable identifier is determined. The content-addressable identifier, data hash value, and corresponding time information are then uploaded to the blockchain network for evidence storage.

[0077] In this way, by acquiring corresponding on-site images at the construction site through the information collection terminal, the validity of the acquired on-site images can be guaranteed, preventing the generation of false records. Furthermore, the on-site images and their corresponding image recognition results are stored in an off-chain storage space, and the corresponding content addressing identifier, data hash value, and time information are then recorded as evidence on the blockchain network. This achieves a dual-link evidence structure of off-chain storage and on-chain hashing, eliminating the need for the high-cost deployment of server clusters required by centralized systems, making regulatory data tamper-proof, and ensuring the judicial validity of regulatory data.

[0078] Regarding step S230, in some embodiments of the present disclosure, it may include the following Figure 3 Steps S231 to S232 are shown.

[0079] In step S231, a corresponding image hash value is determined based on the on-site image. In this embodiment, the information processing terminal can use a hash algorithm (such as SHA-256) based on the on-site image to obtain a fixed-length value, namely the image hash value, to uniquely identify the image data. Based on this image hash value, it can quickly verify whether the image has been tampered with, ensuring the integrity and authenticity of the image data.

[0080] In step S232, the corresponding data hash value is determined based on the image hash value, the acquisition time corresponding to the on-site image, and the device identification and positioning information corresponding to the information acquisition terminal that acquired the on-site image. The device identification can be a number or name that uniquely identifies the information acquisition terminal, used to distinguish different devices. The positioning information can be the location information when the information acquisition terminal acquires the on-site image, usually expressed as GPS coordinates, reflecting the geographical location corresponding to the image. In this embodiment, as described above, after acquiring the on-site image, the information acquisition terminal can combine relevant information with the on-site image for synchronous transmission to the information processing terminal. The relevant information can be the device identification and positioning information of the information acquisition terminal.

[0081] After determining the image hash value corresponding to the on-site image, the information processing terminal can encapsulate the image hash value, the timestamp information of the information collection terminal's acquisition of the on-site image, the device identification of the information collection terminal, and the location information into a data packet. The data packet is then subjected to a hashing algorithm to generate a final data hash value. This allows multiple pieces of information to be combined to generate a unique hash value representing all key information, facilitating subsequent storage and verification in related systems such as blockchain.

[0082] Regarding step S231, in some embodiments of the present disclosure, step S231 may include: Figure 4 Steps S2311 to S2312 are shown.

[0083] In step S2311, the scene image is compressed into JPEG format. In step S2312, a corresponding image hash value is determined based on the compressed scene image and its corresponding EXIF ​​metadata.

[0084] In this embodiment, the information processing terminal can compress the on-site image and convert it into JPEG format. It should be noted that during the compression process, the compression quality parameter can be set to balance the compression efficiency and image quality.

[0085] During or after the image compression process, specialized metadata extraction tools can be used to extract the corresponding EXIF ​​metadata from the compressed JPEG image. This metadata can include key information such as the capture time, device identification, and location information. The compressed live image is then combined with the extracted EXIF ​​metadata to form a complete data package. For example, the EXIF ​​metadata can be appended to the image data in JSON or other structured formats, or embedded in the image data in a specific order. A hash algorithm is then used to perform a hash operation on the combined data to obtain the corresponding image hash value.

[0086] In this way, by compressing the on-site images, the size of the image files can be significantly reduced, the storage space occupied and the amount of data during transmission can be reduced, the storage efficiency and transmission speed can be improved, and the storage and bandwidth costs can be reduced.

[0087] In addition, retaining key EXIF ​​metadata provides contextual information of the image, which helps to trace and verify the time, location, and device in subsequent image management and applications, and provides more reference information for subsequent image use and analysis.

[0088] Based on the above implementation, Figure 5 FIG. 1 shows a flow chart of data verification included in a data supervision method for an engineering project according to an embodiment of the present disclosure. Figure 5 As shown, data verification includes at least steps S510 to S560, which are described in detail below.

[0089] In step S510, the content addressable identifier (CAI) corresponding to the data to be verified is determined based on the received data verification request. The data verification request may be initiated by a supervisory platform, a project owner, or other relevant party, requesting verification of the authenticity and integrity of specific on-site images and related data.

[0090] In this embodiment, the supervision platform or the information processing terminal can receive the corresponding data verification request.

[0091] In one example, the data verification request can include specific information about the data to be verified, such as the time period when the image was taken, the project location, equipment identification, and other key clues, to clearly specify the scope of the on-site images and related data that require verification. Based on this key information, the supervision platform or information processing terminal can perform a query operation in a local database or blockchain ledger.

[0092] It's important to note that the local database stores metadata associated with the content-addressable identifier (CAI) when live images are uploaded, such as capture time, device ID, and GPS coordinates. The blockchain ledger records transaction information associated with the data, including CAI, data hash values, and timestamps. This allows users to construct query conditions and search for matching records within these storage structures, thereby obtaining the CAI corresponding to the data being verified.

[0093] In other examples, the data verification request may also include a content addressing identifier corresponding to the data to be verified. By parsing the data verification request, the regulatory platform or information processing terminal can directly obtain the content addressing identifier corresponding to the data to be verified, thereby performing subsequent verification operations.

[0094] In step S520, based on the content addressing identifier, the corresponding on-chain data hash value stored in the blockchain network is determined. In this embodiment, a query operation can be performed on the blockchain network using the determined content addressing identifier corresponding to the data to be verified. In a permissioned private blockchain environment, a query request can be sent to the blockchain network via a blockchain light node or a full node. The query request can include the content addressing identifier, requesting the blockchain network to return the on-chain data hash value associated with the content addressing identifier. It should be understood that the on-chain data hash value is the data hash value corresponding to the content addressing identifier when the evidence is first stored.

[0095] In step S530, the corresponding on-site image is retrieved from the off-chain storage space based on the content-addressable identifier. In this embodiment, a query request for the corresponding off-chain storage space can be constructed using the content-addressable identifier corresponding to the data to be verified, and the query request is sent to the off-chain storage space. The off-chain storage space can respond to the query request by searching for the associated on-site image based on the content-addressable identifier contained in the query request and providing feedback on the file content.

[0096] After receiving the live images fed back from the off-chain storage space, they can be processed accordingly, such as decoding, format conversion, etc., to ensure that the acquired live images can be displayed and used correctly.

[0097] In step S540, the corresponding off-chain data hash value is determined based on the on-site image obtained from the off-chain storage space.

[0098] In this embodiment, based on the on-site image obtained from the off-chain storage space, the same processing method as described above for evidence storage can be performed to generate a data hash value corresponding to the on-site image (i.e., the off-chain data hash value).

[0099] In step S550, the hash value of the on-chain data is compared with the hash value of the off-chain data.

[0100] In this embodiment, the obtained on-chain data hash value and the off-chain data hash value can be compared for consistency to determine whether the two are identical. In one example, a pre-defined comparison function can be used, with the on-chain data hash value and the off-chain data hash value as input parameters. The comparison function can compare the two hash values ​​bit by bit. If the two are completely consistent, the comparison is determined to be successful; otherwise, the comparison is determined to have failed.

[0101] In step S560, a corresponding electronic verification report is generated according to the comparison result.

[0102] In this embodiment, a corresponding electronic verification report can be prepared based on the comparison results. The electronic verification report may include a comparison timestamp, a content addressing identifier, a hash value of the data involved in the comparison (i.e., an on-chain data hash value and an off-chain data hash value), data packet information (including a hash value, a timestamp, a device identifier, a positioning information), etc., as well as a comparison conclusion (such as data consistency or data inconsistency, etc.).

[0103] The resulting electronic verification report provides reliable electronic evidence for the verification of on-site image data. This report, which records detailed comparison information and results, can be used to verify the integrity and authenticity of on-site image data, providing strong support for dispute resolution and liability determination in the supervision of small and scattered projects.

[0104] Regarding step S210, in some embodiments of the present disclosure, it may include: in response to a data analysis request sent by the central server, obtaining on-site images collected by the information collection terminal at the construction site. The central server may be a centralized computing and storage center with powerful data processing, storage, and network communication capabilities, responsible for managing and coordinating tasks such as data storage, analysis, and distribution throughout the system.

[0105] The data analysis request can be a task instruction initiated by the central server, that is, the central server can determine the idle information processing terminal or cloud node based on the status information of the information processing terminal or cloud node, and then send a data analysis request to the idle information processing terminal or cloud node to enable it to perform the corresponding data analysis task.

[0106] In one example, the data analysis request may include a task ID, a scene image collected by the information collection terminal, and related parameter information, etc. After receiving the data analysis request, the information processing terminal may parse it to obtain the relevant content required to perform the data analysis task.

[0107] In other embodiments of the present disclosure, step S210 may further include: receiving a site image collected at the construction site and sent by a paired information collection terminal.

[0108] In this embodiment, the information processing terminal can be paired with one or more information collection terminals through pre-configuration. That is, after capturing on-site images, the information collection terminal can directly transmit them to the paired information processing terminal. The information processing terminal can then perform corresponding data processing based on the on-site images transmitted by the paired information collection terminal.

[0109] In this way, among the above two data acquisition methods, technical personnel in this field can choose one or a combination of the two to acquire on-site images according to actual implementation needs, so as to adapt to different construction site environments and supervision requirements, so that the data supervision system has good scalability and can be upgraded and expanded accordingly as the scale and complexity of the project expands.

[0110] Regarding step S240, in some embodiments of the present disclosure, step S240 includes: uploading the on-site image and its corresponding image recognition result to the InterPlanetary File System for storage, and determining the content identifier corresponding to the two contents.

[0111] In this embodiment, the InterPlanetary File System (IPFS) is used as off-chain storage. It should be understood that IPFS is a distributed storage network that stores data using content-addressable methods, enabling flexible data storage and sharing. It also features decentralization and data immutability.

[0112] In addition, the distributed nature of IPFS allows data to be stored across multiple nodes, providing excellent fault tolerance and robustness. Even if some nodes fail, data will not be lost. Furthermore, content-addressable identifiers (CIDs) allow for rapid data location and retrieval, improving the efficiency and convenience of data management.

[0113] Moreover, compared to traditional centralized storage solutions, the IPFS distributed storage network effectively reduces storage costs by leveraging the storage resources of multiple nodes in the network. In the supervision of small and scattered projects, there is no need to build and maintain large centralized storage data centers. Instead, data can be stored using existing resources in the IPFS network, saving a lot of hardware equipment investment and operation and maintenance costs.

[0114] Figure 6 FIG. 1 shows a flow chart of event alarms included in a data supervision method for an engineering project according to an embodiment of the present disclosure. Figure 6 As shown, the event alarm includes at least steps S610 to S620, which are described in detail below.

[0115] In step S610, if a target risk event exists in the scene image, an alarm message is generated according to the content addressing identifier and positioning information corresponding to the scene image.

[0116] The target risk event may be a pre-set event type with high risk factors, such as fire smoke recognition.

[0117] In this embodiment, based on the image recognition results, if the identified event type is a target risk event, the information processing terminal can promptly generate corresponding alarm information based on the content addressing identifier and positioning information corresponding to the on-site image to remind supervisors or relevant responsible personnel to handle it in a timely manner.

[0118] In step S620, the alarm information is sent to the supervision platform.

[0119] In this embodiment, the information processing terminal can establish a secure communication connection with the supervision platform. After generating an alarm, it can be sent to the supervision platform via this communication connection. Supervisors can use the content addressing identifier carried in the alarm to retrieve the corresponding on-site image from off-chain storage for review. Based on the review results, they can assign an event level (such as general or urgent) and issue corrective action instructions to the engineering party's information processing terminal based on the event level.

[0120] In this way, it can ensure that supervisors can be informed of risk events at the construction site at the first time and take timely measures to deal with them, thereby reducing potential safety risks and losses.

[0121] Based on the technical solutions of the above embodiments, a specific application scenario of the embodiments of the present application is introduced below: Based on the aforementioned embodiments, the present disclosure provides a specific design scheme for a data supervision method applicable to engineering projects, which is described in detail as follows.

[0122] 1. Terminal layer: The hard hat (i.e., information collection terminal) integrates a low-power camera and a Bluetooth 5.0 module to capture on-site images and transmit them to a mobile phone. It mainly includes the following contents.

[0123] 1. Hard hat hardware architecture design 1) Camera module Model: OV5640 low-power CMOS sensor Resolution: 720P@30fps (can be switched to 1080P by event trigger) Coding format: H.265 / HEVC Viewing angle: 120° wide angle (FOV) 2) Bluetooth communication module Protocol: BLE5.0 (supports 2Mbps transmission rate) Transmission distance: 50 meters (line of sight, measured on site) Encryption: AES128 hardware encryption 3) Main control chip Model: ESP32S3 (dual-core XtensaLX7, built-in WiFi / BLE) Memory: 512KB SRAM + 4MB SRAM Storage: 8MB Flash 4) Sensor group Accelerometer (LIS3DH, ±16G) Gyroscope (MPU6050, ±2000° / s) Light intensity sensor (BH1750, 0.65535 Lux) Microphone (SPQ2410, 60dB SNR) 5) Power Management Battery: 5000mAh lithium polymer battery (IP67 protection) Battery life: 12 hours of continuous work (low load mode) Charging: Type C fast charge (support PD18W) Low power mode: standby power consumption <1mW 6) Physical structure Weight: <300g (including all modules) Protection level: IP67 (dustproof, waterproof, and 2-meter drop-resistant) Heat dissipation: passive heat dissipation + thermal conductive silicone pad 2. Trigger and shooting logic design 2.1 Triggering Strategy Timed baseline sampling One frame (720PJPEG, quality factor 80%) is automatically captured every 5 minutes to generate a timestamp-named image (such as 20231001_120500_hat001.jpg) and transmitted to the mobile phone via Bluetooth.

[0124] Sensor emergency trigger If the accelerometer exceeds 3G or the gyroscope angular velocity exceeds 30° / s, 1080P@30fps recording (lasting 10 seconds) is started, key frames (first frame + last frame) are captured, and key frames are transmitted first.

[0125] Audio linkage trigger The microphone detects noise levels above 80dB (e.g., impact) lasting >2 seconds, triggering a continuous capture (1 frame per second, 5 frames total) with an attached audio waveform clip (WAV format, 8kHz sampling rate).

[0126] Light mutation trigger When the light intensity sensor detects a brightness change rate greater than 50% / second (such as welding flash), it takes three consecutive frames (with an interval of 0.5 seconds) and records the sequence of light intensity values.

[0127] 2.2 Local Preprocessing Image compression: H.265 encoding (CRF=28), 720P image compression to 100-200KB / frame; Metadata encapsulation: Each frame image is embedded with a JSON header (including timestamp, GPS coordinates, sensor readings, and device ID); Cache management: The local TF card stores 48 hours of video in a loop (overwrite), and the video segment corresponding to the trigger event is locked to prevent deletion.

[0128] 3. Bluetooth transmission protocol design 3.1 Communication process 1) Pairing and binding: The helmet and the phone are paired with one touch via NFC, generating a unique AES-128 link key; The binding information is stored in the helmet's Flash and will automatically reconnect after reboot.

[0129] 2) Data transmission: Data packet structure: [Header (2B)] + [Data Type (1B)] + [Length (2B)] + [Payload (N×256B)] + [CRC (2B)]; Data type: 0x01 (image), 0x02 (sensor data), 0x03 (heartbeat packet); Segmented transmission: A single image frame is segmented into multiple 256B data packets, which are reassembled and CRC checked on the mobile phone.

[0130] 3) Resuming downloads: If the mobile phone fails to receive the data, it sends a NAK command and the helmet retransmits the lost fragment (maximum retries 3 times); After a transmission interruption, the hardhat buffers unacknowledged data packets and resumes transmission after the link is restored.

[0131] 3.2 Anti-interference optimization 1) Channel hopping: Based on BLE 5.0 Adaptive Frequency Hopping, it avoids Wi-Fi interference bands (such as 2.4 GHz channels 1-11); 2) Signal enhancement: The PCB has a built-in F-shaped antenna, and the transmission distance measured on site is ≥30 meters (non-line-of-sight); 3) Power consumption control: Enters Sniff mode (100ms interval) when idle and switches to HighDutyCycle mode when transmitting.

[0132] Edge layer: Mobile phones are equipped with lightweight AI models (such as YOLOv8s) to perform real-time image analysis (e.g., personnel compliance detection, wire exposure detection, etc.), extract key frames, generate hash values, and write them to the blockchain. The original images are also distributed and stored in IPFS. 1. Lightweight AI model design and optimization 1.1 Basic model: YOLOv8s (640×640 input, 22M parameters, mAP@0.5=45.2%), adapted for real-time detection on mobile devices.

[0133] 1.2 Optimization strategy: Pruning: Based on channel importance evaluation (such as the BN layer scaling factor), redundant channels are removed, the number of parameters is reduced to 12M, and the mAP loss is <3%.

[0134] Quantization: FP32 → INT8 quantization (TensorRT / TFLite), compressing the model size by 60% and increasing the inference speed by 2 times.

[0135] Knowledge distillation: Use a teacher model (YOLOv8x) to guide the training of a lightweight student model to improve small object detection capabilities (such as exposed wire identification).

[0136] 2. Real-time image analysis process 2.1 Data Preprocessing Image decoding: Receive the JPEG image transmitted by the helmet and decode it into RGB format (OpenCV acceleration); Normalize the image size: Resize to 640×640, maintaining the aspect ratio (fill the edges with grayscale pixels). Normalization: pixel values ​​are normalized to [0,1] ( / 255.0); Data augmentation: Mosaic augmentation is enabled only during testing (done during training).

[0137] 2.2 Real-time Inference and Post-processing 1) Multi-threaded pipeline: classInferenceThreadextendsThread{ void run(){ while(true){ Bitmapimage=queue.take(); / / Get the image from the helmet Tensorinput=preprocess(image); Tensoroutput=model.run(input); Resultresult=postprocess(output); if(result.has_anomaly()){ trigger_hash_and_upload(result); } }} } 2) Post-processing: Non-maximum suppression (NMS): IOU threshold = 0.45, confidence threshold = 0.5; Classification output: personnel compliance (safety helmets / reflective clothing), equipment status (exposed wires, tilted scaffolding), environmental risks (fire smoke).

[0138] 2.3 Keyframe extraction strategy Scheduled sampling: One frame (I frame) is sampled every 5 seconds for routine inspection.

[0139] AI detection anomaly: When a high-risk target is detected (confidence level > 0.7), the current frame + the two frames before and after the accident record are captured.

[0140] Sensor collaboration: When the accelerometer is > 2G, continuous screenshots (2 frames per second for 5 seconds) are triggered for fall and collision events.

[0141] 3. Blockchain Evidence Storage and IPFS Storage 3.1 Hash Generation and Evidence Storage Data encapsulation: json { "image_hash": "sha256 (image binary data)", "timestamp":1696123456, "gps":"22.5432,113.9345", "detection_result":[ {"class":"Not wearing a helmet","confidence":0.82,"bbox":[x1,y1,x2,y2]}] } Hash on chain: Call the blockchain light node SDK (such as Hyperledger Fabric Client SDK) to write the JSON data hash to the private chain; Transaction structure: TxID + block height + Merkle tree path.

[0142] 3.2IPFS Storage Integration SDK selection: js-ipfs (Web) or mobile-ipfs-lite (lightweight library for mobile); Multi-part upload: The image is divided into 1MB pieces, and the CID generation algorithm is SHA2-256; Caching strategy: The CID records for the last 24 hours are retained locally, and failed fragments are retransmitted after the network is restored.

[0143] 3.3 Evidence Verification Process On-chain query: Get the hash value through the transaction TxID; IPFS retrieval: Use CID to download the original image and detection results; Hash check: sha256 (download file) == hash value on the chain; Judicial report generation: Automatically generate PDF reports (including timestamp, GPS, and visual annotation of test results).

[0144] 4. Performance optimization and fault tolerance mechanism 4.1 Resource Management Memory optimization: intermediate tensors are released immediately after model inference; 4.2 Exception Handling Network outage: The local cache does not upload data (SQLite database), and will be retransmitted according to priority after the network is restored; Heartbeat packets detect cloud service availability and switch to the backup IPFS gateway (e.g., ipfs.io → cf-ipfs.com).

[0145] Model inference failed: Fallback to low-precision mode (FP16). If the failure persists, log the error and restart the inference engine.

[0146] 3. Detailed Design of Resource Dynamic Scheduling Layer 1. Node heartbeat mechanism design 1.1 Heartbeat Protocol and Data Structure Heartbeat period: fixed at 30 seconds, with a ±2 second jitter allowed (to avoid network congestion).

[0147] Heartbeat packet structure (JSON format): json { "node_id": "Mobile_Device_001", / / Node unique identifier (mobile phone IMEI / cloud instance ID) "timestamp": 1696123456, / / Unix timestamp (seconds) "resource": { "gpu_util": 15.3, / / GPU utilization (percentage) "mem_util": 40.2, / / Memory usage (percentage) "network_bw": 50.5, / / Available uplink bandwidth (Mbps) "battery": 65, / / Remaining battery (percentage, mobile only) "latency": 28.7 / / Network latency to the resource pool (ms) }, "status_flags": 0x0F, / / Status bit mask (0x01: idle, 0x02: maintenance...) } Transport Protocol: Mobile: Based on HTTPS long connection, use ProtoBuf to compress data (volume reduced by 60%); Cloud nodes: UDP multicast (within the local area network) or QUIC protocol (on the public network), low overhead and high real-time performance.

[0148] 1.2 Heartbeat Processing Flow 1) Receiving and parsing: The resource pool central controller (deployed in a high-availability cluster) receives the heartbeat packet and verifies the signature (HMAC-SHA256) to prevent tampering. After parsing, update the node status table (stored in RedisSortedSet, sorted by node load score).

[0149] 2) Status mark: Mark node status according to preset thresholds (e.g. GPU_util < 20% → idle, mem_util > 80% → overloaded); Calculate the composite load rating: Score=α*GPU_util+β*mem_util+γ / network_bw+δ*latency (Weight coefficient: α=0.5, β=0.3, γ=0.1, δ=0.1) 2. Offline node removal mechanism 2.1 Elimination strategy Timeout judgment: If a node fails to send heartbeats for three consecutive times (90 seconds cumulatively), it is marked as suspected offline; Final culling: Send ICMPPing+TCP port probe to the node. If there is no response within 5 seconds, remove the node from the list of available resources. Record the removal event in the audit log (including timestamp, node ID, and last heartbeat time).

[0150] 2.2 Task Migration and Recovery 1) Task status tracking: Use a distributed transaction manager (such as Seata) to record the task and node binding relationship (TaskID→NodeID).

[0151] 2) Migration process: After detecting that a node is offline, query its unfinished task list; Reassign tasks to low-load nodes based on their priority (P0-P3); The new node loads the task context from shared storage (such as MinIO) and continues execution.

[0152] 3. Dynamic load balancing strategy 3.1 Load Assessment and Task Classification 1) Task classification: Task types include real-time analysis, batch processing, and background tasks. Real-time analysis has a priority of P0 and requires high GPU resources and low latency (<50ms), such as analyzing video frames from a fall incident. Batch processing has a priority of P1 and requires high memory and bandwidth, such as compliance screening of historical footage. Background tasks have a priority of P2 and require low resource usage and latency (>5 minutes), such as compressed log uploads.

[0153] 2) Node matching rules: def match_task_to_node(task, nodes): candidates = [] for node in nodes: if node.status != "Idle": continue # Check hard constraints if task.gpu_req>node.gpu_available: continue if task.mem_req>node.mem_available: continue # Calculate matching score score = (node.network_bw / task.bw_need) + (1 / node.latency) candidates.append((node, score)) # Return in descending order of score return sorted(candidates, key=lambda x: -x[1]) 3.2 Scheduling Algorithm Implementation 1) Core algorithm: Improved weighted least connections (WLC) + priority preemption.

[0154] Normal scheduling: Sort by task priority and assign P0 tasks to the idle nodes with the highest comprehensive scores.

[0155] Preemption mechanism: P0 tasks can preempt P2 task resources, and the preempted tasks are suspended and then re-entered the queue (checkpoints are retained).

[0156] 2) Distributed lock: Use Redis RedLock to ensure that the same task is assigned only once, avoiding repeated execution.

[0157] 3.3 Resource Allocation Example Scenario: A mobile node (GPU_util=15%, latency=30ms) receives a P0 task (requires GPU ≥ 10%, latency < 50ms).

[0158] The scheduler verifies that the nodes meet the hard constraints; Calculate the matching score: (50Mbps / 20Mbps) + (1 / 0.03s) = 2.5 + 33.3 = 35.8; If the score is the highest, the task is assigned and the node status is updated to busy.

[0159] 4. Fault-tolerance and scalability design 1) Resource pool high availability: The controller uses master-slave hot standby (Keepalived + VIP), with a failover time of less than 10 seconds; Node status table multi-copy storage (Redis Cluster), partition tolerance (AP model).

[0160] 2) Horizontal expansion: Support dynamic registration of new nodes (mobile / cloud) and automatic joining of scheduling pool; Automatically scale up cloud elastic instances (such as AWS Auto Scaling Group) when the load is overloaded.

[0161] 5. Monitoring and Logging 1) Real-time dashboard: Grafana displays metrics such as node online rate, task throughput, and average latency; 2) Abnormal alarm (PrometheusAlertManager): Node offline rate > 10% or task timeout rate > 5% triggers email / SMS notification.

[0162] 3) Audit log: Record task assignments and node status change events (stored in Elasticsearch and retained for 6 months); Supports judicial audit traceability (such as proving that a task was processed by a certain node at a specific time).

[0163] 4. Detailed Design of Blockchain Evidence Storage Layer 1. Blockchain Network Architecture 1. Full Node (Regulatory Agency (Government Cloud)) Store complete blockchain data Participate in consensus verification and block generation Provide SPV certification services 2. Light node (mobile phone, engineering / supervisory personnel’s mobile phone) Submit hash evidence transaction Initiate SPV verification request Synchronize block header data 3) IPFS Cluster (Government Cloud + Edge Node) Distributed storage of original images / videos Provide CID (content identifier) ​​retrieval service and hybrid deployment 4. CA Certification Center (Regulatory Agency) Issuing digital certificates (X.509) Management node access permissions 2. Blockchain Core Design 2.1 Chain Type and Consensus Mechanism Chain type: permissioned private chain (customized Hyperledger Fabric); Consensus algorithm: Raft consensus (suitable for low-Byzantine environments, block time ≤ 1 second); Block structure: message Block { Header header = 1; / / Block header (version, timestamp, preceding hash) repeated Transaction txs = 2; / / Transaction list (certificate transaction, governance transaction) bytes validator_sig = 3; / / Verify node signature (RSA-2048) } 2.2 Evidence Transaction Structure message AttestationTx { string tx_id = 1; / / Transaction ID (UUIDv4) bytes data_hash = 2; / / Data hash (SHA-256) string cid = 3; / / IPFS content identifier int64 timestamp = 4; / / Timestamp (synchronized with the National Time Service Center) string device_id = 5; / / Helmet / mobile phone device ID bytes digital_sign = 6; / / Device private key signature (ECDSA-secp256k1) string cert_id = 7; / / Device certificate ID (issued by CA) } 3. Light Node SPV Verification Process 3.1 Transaction Submission Local signature: The phone uses the device private key to sign (data_hash + timestamp) to generate digital_sign; Constructing a transaction: Encapsulate AttestationTx and attach the device certificate issued by the CA; Broadcasting a transaction: Light nodes send transactions to at least three full nodes via gRPC (to prevent single point of failure).

[0164] 3.2 SPV Verification Request proof: The light node sends an SPV request (including tx_id and data_hash) to the full node. Generate Merkle proof: The full node extracts the transaction from the block and generates a Merkle path proof containing the transaction; Verification Proof: The light node verifies the Merkle root consistency through the block header and confirms that the transaction has been uploaded to the chain; def verify_spv(block_header, merkle_proof, target_tx_hash): root = calculate_merkle_root(merkle_proof.tx_hashes) return root == block_header.merkle_root and target_tx_hash in merkle_proof.tx_hashes 4. Data Storage and Retrieval 4.1 Evidence Data Flow Edge side: The phone detects an abnormal event and generates an image hash and CID; The light node submits AttestationTx to the private chain; On-chain processing: The full node verifies the signature and certificate validity (calls CA service); Raft consensus blocks (finality is achieved when 3 nodes confirm); IPFS storage: The original file is uploaded to the IPFS cluster in pieces (government cloud nodes are prioritized); Record the mapping relationship between CID and block height (such as LevelDB index).

[0165] 4.2 Judicial Evidence Collection Process On-chain forensics: Enter tx_id through the judicial interface to query the corresponding block height and transaction details; Data Validation: Pull the file corresponding to the CID from IPFS and calculate sha256(file); Compare the data_hash on the chain, and generate an "Electronic Data Integrity Verification Report" if they are consistent; Timestamp traceability: The on-chain timestamp is cross-verified with the national time service center log (such as NTSC) to prove that it has not been tampered with.

[0166] 5. Security and compliance design 5.1 Permission Management Node admission: Full node: CA issues server certificate and whitelist registration is performed during deployment; Light node: device certificate pre-set (one device, one certificate), regular synchronization of the CRL; Smart contract permissions: Evidence contract: only light nodes are allowed to submit, and full nodes are allowed to verify; Governance contract: Only the regulator key can modify the consensus parameters.

[0167] 5.2 Judicial Compliance Standards Compliance: Comply with legal and regulatory requirements for reliable electronic signatures (authentic identity, complete content, and unaltered signatures); Connecting to judicial blockchain platforms (such as the "Tianping Chain") to achieve cross-chain mutual recognition; Audit interface: Provide a standardized API for courts to retrieve stored evidence data.

[0168] 6. Disaster recovery and recovery Blockchain shard backup: Daily snapshots of all node data, stored remotely (two locations and three centers); Multiple copies of IPFS content (Replication=3) are distributed across data centers; Light node cache: The phone locally caches the last 30 days of evidence transactions (SQLite), and can generate evidence applications offline when the network is disconnected; Automatically synchronize to the chain after the network is restored.

[0169] Based on the above design scheme, Figure 7 FIG. 1 shows a schematic diagram of the interaction process of a data supervision system for an engineering project according to an embodiment of the present disclosure. Figure 7 As shown, the interaction process includes at least steps S710 to S790, which are described in detail below.

[0170] In step S710, the information collection terminal uses its integrated low-power camera at the construction site to capture on-site images according to preset trigger strategies (such as timed baseline sampling, sensor emergency triggering, audio linkage triggering, and sudden light change triggering). After local pre-processing (image compression and metadata encapsulation), the images are transmitted to the paired information processing terminal via the Bluetooth 5.0 module. In step S720, the information processing terminal receives the on-site images and related information (such as device identification, location information, and time information) from the information collection terminal. In step S730, the information processing terminal uses its own lightweight AI model (such as YOLOv8s) to perform real-time analysis of the images, identifying whether there are risk events (such as people not wearing safety helmets or entering hazardous areas) in the images, and outputs the detection results (label + confidence level) and keyframe images. In step S740, the information processing terminal uploads the on-site images and their corresponding image recognition results to the IPFS distributed storage network for off-chain storage and obtains the corresponding content-addressable identifier (CID). In step S750, the information processing terminal determines the corresponding image hash value based on the compressed on-site image and its corresponding EXIF ​​metadata. It also determines the corresponding data hash value based on the image hash value, image acquisition time, device identifier, and location information. The data hash value, content addressing identifier, and time information are then packaged into transaction data and sent to the blockchain network.

[0171] In step S760, the blockchain network writes the received transaction data into the block, completing the on-chain data storage. In step S770, if the AI ​​model of the information processing terminal detects a high-risk event, it immediately generates an alert message, which may include the event type, time, location, and corresponding CID, and sends the alert message to the regulatory platform. In step S780, regulators can view the alert details on the regulatory platform and retrieve the original image and related data from the IPFS network using the CID for manual review. Based on the review results, regulators mark the event level.

[0172] In step S790, the supervisor issues a rectification instruction to the information processing terminal of the engineering party according to the reviewed event level.

[0173] like Figure 8 As shown, in some embodiments of the present disclosure, the data collection and data processing process of the information collection terminal and the information processing terminal includes at least steps S801 to S810, which are described in detail as follows.

[0174] S801: Sensor Detection Abnormality: Sensors in the information collection terminal (such as accelerometers, gyroscopes, light intensity sensors, and microphones) monitor the construction site environment and personnel activities in real time. The system determines whether abnormalities have been detected, for example, by checking whether the accelerometer value exceeds a set threshold (e.g., 3G), whether the gyroscope angular velocity exceeds a set threshold (e.g., 30° / second), whether the brightness change rate detected by the light intensity sensor exceeds a set threshold (e.g., 50% / second), or whether the noise level detected by the microphone exceeds a set threshold (e.g., 80dB for a duration exceeding 2 seconds). If yes, the system proceeds to S802. If no, the system proceeds to S804.

[0175] S802, triggering recording: When the sensor detects an abnormality, the camera module of the information collection terminal is triggered and starts recording at a high resolution (such as 1080P@30fps) for a certain period of time (such as 10 seconds) to capture the complete process of the abnormal event.

[0176] S803, transmitting key frames to the information processing terminal: extracting key frames (such as the first frame and the last frame) from the recorded video, and transmitting them encrypted via the Bluetooth 5.0 module to the paired information processing terminal.

[0177] S804. Timed shooting of baseline frames: If the sensor does not detect an abnormality, the information collection terminal collects baseline frames according to the preset timed shooting strategy (such as shooting one frame every 5 minutes). The captured image is in 720PJPEG format with a quality factor of 80%. An image file named with a timestamp (such as 20231001_120500_hat001.jpg) is generated and transmitted to the information processing terminal via Bluetooth.

[0178] S805. Receive image: The information processing terminal receives image data from the helmet terminal, including baseline frames shot at regular intervals and key frames triggered by abnormalities.

[0179] S806, AI Analysis: The information processing terminal uses a lightweight AI model (such as YOLOv8s) to perform real-time image analysis to identify whether there are risk events in the image (such as people not wearing safety helmets, intrusions into dangerous areas, exposed wires, etc.), and outputs the detection results (label + confidence level) and key frame images.

[0180] S807, Detect Anomaly: Based on the AI ​​analysis results, determine whether a risk event exists. If yes, proceed to S808. If no, proceed to S810.

[0181] S808. Extract key frames: Extract key frames from the image sequence. The selection of key frames is based on the AI ​​detection results and a preset strategy. For example, the current frame in which a high-risk target is detected and the two frames before and after it are extracted, or the key frames in the baseline frames of timed shooting are extracted (such as one frame every 5 seconds).

[0182] S809, Compression + Metadata Encapsulation: Compress the extracted keyframe images into JPEG format and associate metadata (such as timestamp, GPS coordinates, device ID, etc.) to generate a complete data packet. At the same time, calculate the data hash value to ensure data integrity and security.

[0183] S810, discard low-priority data: If no risk event is detected in the image, or the image priority is low (for example, no abnormality is found in the baseline frame), the low-priority data is discarded to save storage space and transmission bandwidth and optimize system performance.

[0184] like Figure 9 As shown, in some embodiments of the present disclosure, the data storage stage and the data evidence collection stage include at least steps S901 to S910, which are described in detail below.

[0185] Evidence storage stage S901. Generate data hash value: An information processing terminal (such as a mobile phone) integrates the on-site image and its associated data (including image recognition results, acquisition time, device identification, and location information) into a complete data packet. This data packet is hashed using the secure hash algorithm SHA-256 to generate a unique data hash value, which is used to identify the data's integrity.

[0186] S902, call the light node SDK: The information processing terminal invokes the blockchain light node software development kit (SDK) to submit the generated data hash and related information to the blockchain network. The light node SDK provides interfaces and tools for interacting with the blockchain network, allowing mobile devices and other terminals to easily submit and query transactions.

[0187] S903, full node verification signature: After receiving submitted transaction data, a full node in the blockchain network (operated by a regulatory body) first verifies the transaction's digital signature. Using the device's public key, it verifies that the transaction data was generated by the corresponding private key, ensuring the authenticity and integrity of the data source.

[0188] S904, Raft consensus block generation: After passing full node verification, they participate in the voting and negotiation process of the Raft consensus algorithm. The Raft consensus algorithm is a fault-tolerant consistency algorithm used in distributed systems that can quickly reach consensus and package verified transactions into new blocks.

[0189] S905, IPFS uploads original data: When a blockchain transaction is successfully completed, the information processing terminal uploads the original on-site image and related data to the IPFS distributed storage network. IPFS stores data using content addressing and returns a unique content-addressable identifier (CID) for subsequent data retrieval.

[0190] Evidence Collection Phase S906. Enter TxID: The user or system of the regulatory platform enters the corresponding blockchain transaction ID (TxID) as the entry point for the query based on the data that needs to be verified.

[0191] S907, query the hash on the chain: The regulatory platform uses the TxID to query the corresponding block through the query interface of the blockchain network and obtain the hash value of the data stored on the chain.

[0192] S908, IPFS pulls CID data: Based on the CID of the data to be verified, the regulatory platform sends a request to the IPFS network to pull the original data (on-site images and related information) stored in IPFS.

[0193] S909, Hash check: The data hash value (i.e., the off-chain data hash value) is recalculated for the original data obtained from IPFS and compared with the hash value stored on the chain. If the two match, the verification passes, indicating that the data is complete and has not been tampered with. If they do not match, the verification fails, indicating that there may be problems with the data.

[0194] S910. Generate judicial report: Based on the verification results, a judicially recognized report is generated by combining on-site images, data hash values, timestamps, and other information. This report contains detailed information about the verification process, results, and related data, and is legally binding and can be used as judicial evidence.

[0195] According to one embodiment of the present disclosure, a data supervision system for small and scattered projects is also provided. This data supervision system aims to implement real-time monitoring of construction sites, risk warnings, data storage, and supervisory intervention, thereby improving the efficiency and reliability of project supervision and reducing safety risks and management costs. The data supervision system mainly includes two components: AI edge computing and a blockchain network.

[0196] Specifically, the AI ​​edge computing component primarily involves connecting data between the phone and the helmet. The helmet terminal uses its integrated low-power camera to capture on-site images and establishes an encrypted connection with the phone using the Bluetooth 5.0 module, transmitting the image data to the phone in real time. The helmet terminal then captures images based on pre-set triggering strategies (such as timed shooting and sensor triggering). After receiving the images transmitted by the helmet, the phone uses a locally installed lightweight AI model to analyze the images in real time, identify risk events, and extract key frames to generate hash values. This edge computing approach reduces the pressure on cloud computing and improves the real-time and efficiency of data processing.

[0197] The blockchain network primarily includes smart contracts for evidence storage and cloud computing. The smart contract for evidence storage is deployed within the blockchain network. The information processing terminal encapsulates keyframe image hash values, IPFS content addressable identifiers (CIDs), timestamps, and other information as transaction data, then invokes the smart contract to submit it to the blockchain network. The blockchain's immutable nature ensures data authenticity and integrity.

[0198] Cloud computing smart contracts utilize cloud computing resources to deploy smart contracts, implementing more complex business logic and data processing functions such as resource allocation and data analysis. The automated execution of smart contracts improves system efficiency and transparency. Dynamic resource pools monitor the load status of mobile phones and cloud nodes in real time, dynamically scheduling computing tasks based on task priority and node load, ensuring efficient utilization of system resources.

[0199] Meanwhile, mobile phones and cloud nodes periodically send heartbeat packets to the resource pool, reporting their load status (such as GPU / memory utilization, network bandwidth, remaining battery life, etc.). The resource pool updates the global resource status table based on the heartbeat data, marking idle resources and removing offline nodes that have been continuously unresponsive.

[0200] In this way, the long-standing pain points in the supervision of small and scattered projects, such as poor real-time performance, low data credibility, serious waste of resources, and weak environmental adaptability, have been solved, providing core technical support for building a low-cost, highly reliable, and judicially credible digital supervision system.

[0201] The present disclosure also provides an electronic device. Figure 10 A schematic diagram showing a hardware implementation using a processing system is shown.

[0202] like Figure 10As shown, the hardware structure of electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnecting buses and bridges, depending on the specific application and overall design constraints of the hardware. Bus 1100 connects various circuits including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400 such as peripheral devices, voltage regulators, power management circuits, external antennas, etc. Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of illustration, the figure only uses a single connecting line, but this does not mean that there is only one bus or only one type of bus.

[0203] The present disclosure also provides a readable storage medium, in which a computer program is stored, and the computer program is used to implement the above-mentioned method when executed by a processor. "Readable storage medium" can be any device that can contain storage, communication, dissemination or transmission programs for use in an instruction execution system, device or equipment or in combination with these instruction execution systems, devices or equipment. More specific examples of readable storage media include the following: an electrical connection portion with one or more wirings (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and editable read-only memory (EPROM or flash memory), an optical fiber device, and a portable read-only memory (CDROM), etc.

[0204] The present disclosure also provides a computer program product. The method of the present disclosure can be implemented in whole or in part using software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, the process or function of the present disclosure is performed in whole or in part.

[0205] A computer program or instruction can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instruction can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any accessible medium or a data storage device such as a server or data center that integrates one or more accessible media. The accessible medium can be a magnetic medium such as a floppy disk, hard disk, or magnetic tape; an optical medium such as a digital video disk; or a semiconductor medium such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or can include both volatile and non-volatile types of storage media.

[0206] Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0207] The present disclosure is described with reference to the flowcharts and / or block diagrams of the methods, apparatuses, electronic devices, and computer program products according to the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as the combination of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0208] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0209] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0210] Those skilled in the art will appreciate that the above embodiments are merely intended to clearly illustrate the present disclosure and are not intended to limit the scope of the present disclosure. Other changes or modifications may be made based on the above disclosure, and such changes or modifications are still within the scope of the present disclosure.

Claims

1. A data supervision method for an engineering project, characterized in that: include: Acquire on-site images collected by the information collection terminal at the construction site; Performing image recognition based on the scene image to determine a corresponding image recognition result, wherein the image recognition result is used to indicate whether there is a risk event in the scene image; Determine, based on the scene image, a data hash value corresponding thereto; Storing the on-site image and its corresponding image recognition result in an off-chain storage space, and determining the corresponding content addressing identifier; The content addressing identifier, the data hash value and the corresponding time information are uploaded to the blockchain network for evidence storage.

2. The method according to claim 1, wherein Determining a data hash value corresponding to the scene image according to the scene image includes: Determine a corresponding image hash value based on the scene image; A corresponding data hash value is determined according to the image hash value, the acquisition time corresponding to the on-site image, and the device identification and positioning information corresponding to the information acquisition terminal that acquires the on-site image.

3. The method according to claim 2, wherein Determining a corresponding image hash value based on the scene image includes: Compressing the live image into JPEG format; Based on the compressed live image and its corresponding EXIF ​​metadata, the corresponding image hash value is determined.

4. The method according to any one of claims 1 to 3, wherein The method further comprises: Determine the content addressing identifier corresponding to the data to be verified according to the received data verification request; Determine, based on the content addressing identifier, a corresponding hash value of the on-chain data stored in the blockchain network; According to the content addressable identifier, obtain the corresponding on-site image from the off-chain storage space; Determine the corresponding off-chain data hash value based on the on-site image obtained from the off-chain storage space; Compare the hash value of the on-chain data with the hash value of the off-chain data; Based on the comparison results, a corresponding electronic verification report is generated.

5. The method according to claim 1, wherein Acquire on-site images collected by the information collection terminal at the construction site, including: Responding to a data analysis request sent by the central server, acquiring a site image collected by the information collection terminal at the construction site; Or receive on-site images collected at the construction site and sent by a paired information collection terminal.

6. The method according to claim 1, wherein The on-site image is obtained by the information collection terminal according to detection information of a sensor or by triggering a collection action according to a target time period. The sensor includes at least one of an accelerometer, a gyroscope, a decibel detection sensor, and a light intensity sensor.

7. The method according to claim 1, wherein After storing the on-site image and its corresponding image recognition result in an off-chain storage space and determining the corresponding content addressing identifier, the method further includes: If a target risk event exists in the scene image, generating an alarm message according to the content addressing identifier and positioning information corresponding to the scene image; The warning information is sent to the supervision platform.

8. A data supervision system for an engineering project, characterized in that: include: Information collection terminal, used to obtain on-site images at the construction site; An information processing terminal, configured to execute the method according to any one of claims 1 to 7; The blockchain network is used to store the evidence data uploaded by the information processing terminal.

9. An electronic device, characterized in that: include: a memory storing execution instructions; A processor, wherein the processor executes the execution instructions stored in the memory, so that the processor executes the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images