Engineering Quality Potential Defect Insurance System Based on Blockchain and Internet of Things

Abstract

This application relates to an engineering quality potential defect insurance system based on blockchain and the Internet of Things. The system includes an Internet of Things terminal for obtaining multiple sets of device data; a blockchain on which an intelligent contract for engineering quality potential defect insurance is deployed. The intelligent contract is used to input multiple sets of device data and execute a data check process according to the initially set time standard and data deviation range. The intelligent contract is also used to input detection data, and when it is queried that the reporting time of the device data meets the time standard, it starts a consensus mechanism, executes an error comparison process between the device data and the detection data, and obtains data that passes the verification; an engineering quality potential defect insurance platform for storing all data and returning a query result when receiving a data query request. Introducing blockchain technology into the engineering quality potential defect insurance system enables the Internet of Things terminal to combine with the engineering quality potential defect insurance intelligent contract to exclude data generated by faulty devices through the implementation of the consensus mechanism.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to an engineering quality potential defect insurance system based on blockchain and the Internet of Things. Background Art

[0002] The engineering quality potential defect insurance (Inherent Defects Insurance, hereinafter referred to as IDI) system is based on network technology. By comprehensively digitizing, networking, and highly integrating the insurance business process, and covering the entire process of insurance application, underwriting, and claims settlement, it improves the efficiency and transparency of business processing, and ensures that the service is more standardized and fair. However, problems such as abnormal device operation may occur during actual application. For example, over time, the electronic components in Internet of Things devices may experience performance degradation or even complete failure due to aging, which may lead to data errors in the operation of the IDI system, thereby affecting the accuracy of information and the reliability of the system.

[0003] Therefore, providing an engineering quality potential defect insurance system that can guarantee data accuracy is an urgent problem to be solved at present. Summary of the Invention

[0004] In view of this, the main purpose of the present invention is to provide an engineering quality potential defect insurance system introducing blockchain technology, enabling Internet of Things terminals to combine with the smart contract of engineering quality potential defect insurance, and excluding data generated by faulty devices through the implementation of a consensus mechanism, effectively solving the problem of result deviation caused by errors in a single data source.

[0005] In a first aspect, an embodiment of the present application provides an engineering quality potential defect insurance system based on blockchain and the Internet of Things, including:

[0006] An Internet of Things terminal for obtaining multiple sets of device data;

[0007] A blockchain deployed with a smart contract for engineering quality potential defect insurance, the smart contract being used to enter multiple sets of device data and execute a data check process according to an initially set time standard and data deviation range; and

[0008] The smart contract is further used to enter detection data, and when it is queried that the reporting time of the device data meets the time standard, start a consensus mechanism, execute an error comparison process between the device data and the detection data, and obtain verified data;

[0009] An engineering quality potential defect insurance platform for storing all data and returning a query result when receiving a data query request.

[0010] In some of these embodiments, when initializing and setting the time standard, the smart contract sets the maximum interval for the device to upload data according to the project requirements;

[0011] When initializing and setting the data deviation range, the smart contract sets the deviation range of the device - collected data corresponding to the key indicators, as well as the error range between the device data and the detection data according to the project requirements.

[0012] In some of these embodiments, the key indicators include the horizontal displacement indicator, the foundation settlement indicator, and the member inclination indicator.

[0013] In some of these embodiments, the data - checking step includes:

[0014] After recording the current device data in the smart contract, query whether there are data records for the other devices;

[0015] When there are data records for the other devices, calculate the time interval between the last reported time of the record and the current time, and determine whether it exceeds the maximum interval for the device to upload data;

[0016] If it exceeds, give an early warning and send a device - inspection notice;

[0017] If it does not exceed, determine whether multiple sets of device data are within the data deviation range, and give an early warning and send a device - inspection notice when it exceeds.

[0018] In some of these embodiments, the smart contract enters the detection data, and when the reported time of the device data meets the time standard, starts the consensus mechanism and executes the error - comparison process between the device data and the detection data to obtain the data that passes the verification, including:

[0019] After the smart contract enters the detection data, query whether there are data records for all devices;

[0020] When there are data records for all devices, calculate the interval between the last reported time of the record and the current time, and determine whether it exceeds the maximum interval for the device to upload data;

[0021] If it exceeds, give an early warning and send a device - inspection notice;

[0022] If it does not exceed, the smart contract starts the consensus mechanism and executes the error - comparison process between the device data and the detection data to obtain the data that passes the verification.

[0023] In some of these embodiments, the smart contract starts the consensus mechanism, including:

[0024] The smart contract queries the latest data in multiple sets of device data and determines whether there is a data error;

[0025] If the number of error data is greater than or equal to two, a warning is given and a device inspection notice is sent.

[0026] If the number of error data is less than or equal to one, the average value of the data without errors is taken.

[0027] In some embodiments, when the number of error data is equal to one, before taking the average value of the data without errors, it further includes:

[0028] Performing the steps of giving a warning and sending a device inspection notice.

[0029] In some embodiments, the process of comparing the error between the device data and the detection data to obtain the verified data includes:

[0030] After taking the average value of the data without errors, the consensus process ends, and the average value is compared with the detection data to determine whether the error between the two is within the error range.

[0031] If so, the verified data is obtained.

[0032] If not, a warning is given, and a notice for re-measuring the detection data and a device inspection notice are sent.

[0033] In some embodiments, the smart contract is further configured with a query interface, and the query interface is used to receive a data query request and query the corresponding device data and detection data in chronological order according to the item name in the data query request.

[0034] In some embodiments, the consensus mechanism is the raft consensus mechanism.

[0035] Technical effects of the present invention:

[0036] By introducing blockchain technology into the engineering quality potential defect insurance system, the present invention combines the IoT terminal with the smart contract of the engineering quality potential defect insurance, and excludes the data generated by faulty devices through the implementation of the consensus mechanism. Among them, the time standard and data deviation standard are set through the IDI contract as the basis for data inspection to check for errors in multiple groups of device data and detection data, and the double verification of the device data and the detection data can exclude the data generated by faulty devices, further ensuring the reliability of the data. And all device data and detection data are stored in the IDI platform to ensure the integrity and traceability of the data, and can return the content covering the entire life cycle when receiving a query request.

[0037] According to the following detailed description of the exemplary embodiments with reference to the accompanying drawings, other features and aspects of the present disclosure will become clear. Brief Description of the Drawings

[0038] The drawings included in and constituting a part of the specification, together with the specification, illustrate exemplary embodiments, features, and aspects of the present disclosure and are used to explain the principles of the present disclosure.

[0039] Figure 1 A schematic block diagram showing the composition of an engineering quality potential defect insurance system based on blockchain and the Internet of Things according to an embodiment of the present application;

[0040] Figure 2 A schematic flowchart showing the initialization process of an IDI contract in an engineering quality potential defect insurance system based on blockchain and the Internet of Things according to an embodiment of the present application;

[0041] Figure 3 A schematic flowchart showing the process of an IDI contract recording device data in an engineering quality potential defect insurance system based on blockchain and the Internet of Things according to an embodiment of the present application;

[0042] Figure 4 A schematic flowchart showing the process of an IDI contract recording detection data in an engineering quality potential defect insurance system based on blockchain and the Internet of Things according to an embodiment of the present application;

[0043] Figure 5 A schematic flowchart showing the process of data traceability and verification in an engineering quality potential defect insurance system based on blockchain and the Internet of Things according to an embodiment of the present application. Detailed Description of the Embodiments

[0044] Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the drawings. The same reference numerals in the drawings denote elements having the same or similar functions. Although various aspects of the embodiments are shown in the drawings, the drawings do not have to be drawn to scale unless otherwise specified.

[0045] The term "exemplary" used herein means "serving as an example, embodiment, or illustration". Any embodiment described herein as "exemplary" is not necessarily to be construed as superior or better than other embodiments.

[0046] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following detailed description. Those skilled in the art should understand that the present disclosure can be implemented without some of these specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art are not described in detail so as to highlight the gist of the present disclosure.

[0047] The currently applied engineering quality potential defect insurance systems generally have the following drawbacks:

[0048] 1. Over time, in the Internet of Things devices on which the IDI system depends, the relevant electronic components may deteriorate in performance or even completely fail due to aging. In addition, since Internet of Things devices rely on network connections, their functions may be restricted or even completely inoperable in the event of a network interruption. Especially when problems occur with devices from the same vendor, the failure phenomena may occur concentratedly;

[0049] 2. During the on-site inspection of IDI, whether relying on machine detection or manual operation, errors may occur due to various factors. For example, machines may be limited by hardware sensitivity or algorithm design, while manual operations may lead to deviations due to insufficient personnel experience or operational negligence, both of which may affect the accuracy and reliability of the inspection results;

[0050] 3. The device data of the same vendor is usually uniformly produced and managed by the vendor platform. However, due to limitations in data collection methods, transmission processes, or platform algorithm design, etc., these data may have certain errors or deviations. If there are systematic problems in the vendor platform, it may affect the data consistency and accuracy of all devices, thus having an adverse impact on overall judgment and decision-making.

[0051] Therefore, in view of the imperfections of the prior art, the present invention provides an engineering quality potential defect insurance system based on blockchain and the Internet of Things. By introducing blockchain technology into the engineering quality potential defect insurance system, the Internet of Things terminal is combined with the smart contract of the engineering quality potential defect insurance, hereinafter referred to as the IDI contract, and by implementing a consensus mechanism to exclude the data generated by faulty devices, a blockchain for the offline Internet of Things is constructed, effectively preventing data error problems caused by device anomalies. It should be noted that blockchain technology is a new application model integrating distributed storage, peer-to-peer communication, consensus algorithms, and data encryption, with characteristics such as data sharing, difficulty in tampering, high credibility, and excellent security, and can effectively solve the problem of information asymmetry, promoting collaborative trust and consistent actions among multiple parties. Based on blockchain technology, the present invention can effectively improve the timeliness and accuracy of data in the engineering quality potential defect insurance system, while promoting information interconnection and deep integration across systems and organizations, and further optimizing the operation efficiency and service level of the system.

[0052] As Figure 1 shown, an embodiment of the present application provides an engineering quality potential defect insurance system 10 based on blockchain and the Internet of Things. The system includes:

[0053] An Internet of Things terminal 100, configured to obtain multiple sets of device data;

[0054] The blockchain 200 deploys smart contracts for the engineering quality potential defect insurance. The smart contracts are used to input multiple groups of device data and execute a data inspection process according to the initialized time standard and data deviation range; and

[0055] The smart contracts are also used to input inspection data, and when the reported time of the device data is queried to meet the time standard, start a consensus mechanism to execute an error comparison process between the device data and the inspection data to obtain verified data;

[0056] The engineering quality potential defect insurance platform 300 is used to store all data and return a query result when receiving a data query request.

[0057] In this embodiment, according to the requirements of a specific project, an Internet of Things terminal is used to detect on-site data, and the corresponding device data is recorded in the IDI contract. Among them, there are at least three groups of device data, that is, at least three different supplier devices are selected to ensure the diversity of the devices and avoid the emergence of risks caused by the aging and failure of the same device.

[0058] It should be noted that during the actual operation process, the IDI contract needs to be deployed on the blockchain first. Specifically, the initialization contract logic is written in the solidity language and deployed to the relevant blockchain. Among them, the initialization contract logic needs to be set according to the specific project requirements, including the time standard and the data deviation standard, and these are used as the basis for data inspection. That is to say, for multiple groups of device data, the requirements of both the time standard and the data deviation standard need to be met. Specifically, according to the requirements of a specific project, the Internet of Things terminals respectively report the data of their respective suppliers, record them in the IDI contract, and then execute the device data inspection steps according to the initialized time standard and deviation standard to verify the device data.

[0059] It also should be noted that the inspection data in this embodiment is manually collected inspection data, specifically the data measured by manual use of corresponding measuring equipment according to the specific project requirements. That is, during the IDI inspection process, a machine - human combination method is adopted to effectively prevent result deviation caused by errors in a single data source through complementary advantages. And after the manual inspection data is input into the IDI contract, when the reported time of the device data is queried to meet the time standard, a consensus mechanism is started to judge the error data, that is, under double verification, the reliability of the data is further ensured, thereby preventing the impact of machine failures or human errors on the data accuracy. And all the above data are stored in the IDI platform, that is, both the verified data and the error data found after verification are stored in the IDI platform, enabling third - party institutions to query the data according to the specific project name and realizing the traceability of the data throughout the project life cycle.

[0060] Such as Figure 2As shown, in some of these embodiments, when initializing and setting the time standard, the smart contract sets the maximum interval for devices to upload data according to project requirements; when initializing and setting the data deviation range, the smart contract sets the deviation range of the device - collected data corresponding to key indicators and the error range between device data and detection data according to project requirements.

[0061] To ensure that the subsequently collected and uploaded data meets project requirements, in this embodiment, the following logic is used to set the basic parameters for the entire IDI contract operation. Specifically, according to the requirements of a specific project, the maximum interval for devices to upload data is set to ensure the timeliness and integrity of the data. At the same time, a reasonable deviation range for device - collected data is also set according to the requirements of a specific project to ensure the accuracy and controllability of the data.

[0062] It should be noted that the range of the interval time unit set in this embodiment supports minutes to hours. In principle, the shorter the better, but due to the limitation of the block - generation speed of the blockchain, it needs to be greater than the block - generation speed of the blockchain. Among them, the block - generation speed of the blockchain is related to the specific blockchain and is usually set to an interval of more than 5 minutes, which can be determined specifically according to the actual project party and construction details.

[0063] In some of these embodiments, the key indicators include horizontal displacement indicators, foundation settlement indicators, and member inclination indicators.

[0064] In this embodiment, according to the specific project characteristics, reasonable deviation ranges are defined for key indicators such as horizontal displacement, foundation settlement, and member inclination. The reason is that different project environments have different requirements for data accuracy. For example, in building projects with different geological conditions, the allowable deviation of foundation settlement is different, or for buildings of different structural types, the reasonable degree of member inclination also varies. By setting the deviation range for the above - mentioned key indicators, it is possible to accurately judge whether the collected data is reliable, thereby ensuring data quality and providing an effective basis for subsequent analysis and decision - making.

[0065] For example, for horizontal displacement, in high - rise buildings with a height of not less than 250m, the ratio of the maximum inter - floor displacement to the floor height △u / h is preferably less than 1 / 500.

[0066] For foundation settlement, the allowable value for residential buildings is 5 - 10mm, for high - rise buildings is 3 - 5mm, for bridges and tunnels is 5 - 10mm, and the settlement value of public buildings with earthquake - proof requirements and multi - storey factories, warehouses and other structures is less than 8mm.

[0067] For member inclination, the inclination of straight poles and corner poles is less than 15%, the inclination of iron towers with a height of 50m and above is less than 5%, the inclination of terminal poles towards the guy - wire side is less than 200mm, and the inclination of corner poles towards the guy - wire side is also less than 200mm.

[0068] In some of these embodiments, the device data inspection step includes:

[0069] After recording the current device data in the smart contract, query whether there are data records for the remaining devices;

[0070] When there are data records for the remaining devices, calculate the time interval between the last reported time of the record and the current time, and determine whether it exceeds the maximum interval time for device data upload;

[0071] If it exceeds, give an early warning and send a device inspection notice;

[0072] If it does not exceed, determine whether multiple sets of device data are within the data deviation range, and give an early warning and send a device inspection notice when it exceeds.

[0073] As Figure 3 shown, after the IDI contract records the current device data, first query whether there are recorded data for the remaining devices in the system except the currently entered device. If there are, continue to execute the remaining steps; if not, end the process. When it is queried that the remaining devices have recorded data, further query the last reported time of the record, and calculate the interval from the current time. If it exceeds the maximum reporting time interval set during initialization, send an early warning and notify the personnel to conduct a device inspection. After the inspection is completed, the process ends.

[0074] It should be noted that time is converted in terms of block intervals on the blockchain. Therefore, in this embodiment, querying the last reported time of the remaining devices is querying the height of the record block of the remaining devices last time, and the initialized maximum upload interval time is also the number of block intervals. For example, if the block interval is 5 seconds, the data of device A is currently recorded at the 10th block height, and it is simultaneously queried that the last record of device B was at the 2nd block height, then the time interval between the two is 8 block heights, that is, a 40 - second interval.

[0075] Furthermore, if the reporting data time interval of the remaining devices is normal, then start comparing the latest data of multiple supplier devices to determine whether it is within the reasonable deviation range set during initialization. If it is, end the entire device data inspection process; if not, send an early warning and notify the personnel to inspect the device. After the inspection is completed, the process ends. That is, through the comparison of multi - source data, the accuracy of the data is further verified, avoiding the adoption of incorrect data due to errors or failures of individual devices, and thus ensuring that the device data finally used for analysis and decision - making is true, reliable, and accurately reflects the actual situation of the project.

[0076] In some of these embodiments, detection data is entered into the smart contract, and when the reporting time of the device data is queried and meets the time standard, the consensus mechanism is started, and the error comparison process between the device data and the detection data is executed to obtain the data that passes the verification, including:

[0077] After the smart contract enters the detection data, query whether there are data records for all devices;

[0078] When there are data records for all devices, calculate the interval between the last reported time of the record and the current time, and determine whether it exceeds the maximum interval time for the device to upload data;

[0079] If it exceeds, give an early warning and send a device inspection notice;

[0080] If it does not exceed, the smart contract starts the consensus mechanism and executes the error comparison process between the device data and the detection data to obtain the data that passes the verification.

[0081] As Figure 4 shown, for the entry of manual detection data, after recording it into the IDI contract, it is necessary to query whether there is recorded data for all Internet of Things devices in the system. If not, the process ends. If so, continue to query the last data reporting time of all devices and calculate the interval from the current time, that is, judge whether the data upload of all devices times out. If this interval exceeds the maximum reporting time set during initialization, an early warning will be triggered to notify the manual to conduct a device inspection, and the process ends after the inspection is completed. If the data reporting time intervals of all devices are normal and do not time out, the IDI contract will start the raft consensus mechanism. It can be seen that by starting from the overall data timeliness and ensuring the rationality of all data in the time dimension according to the time standard set during initialization, it is possible to prevent the accurate judgment of the project from being affected by the untimely update of some data.

[0082] In some of these embodiments, the smart contract starts the consensus mechanism, including:

[0083] The smart contract queries the latest data in multiple groups of device data and determines whether there are data errors;

[0084] If the number of error data is greater than or equal to two, give an early warning and send a device inspection notice;

[0085] If the number of error data is less than or equal to one, take the average value of the data without errors.

[0086] It should be noted that during the IDI inspection process, by introducing a consensus mechanism, the probability of errors occurring in IoT devices can be further reduced, and the reliability of the inspection results can be improved. That is, if the data reporting time intervals of all devices are normal, the IDI contract will start the raft consensus mechanism. First, it will query the latest data of multiple devices, which serves as the operating basis for subsequent data comparison. And when comparing the data of multiple devices, such as when comparing the data of three devices, if data errors occur, a warning will be triggered and manual device inspection will be notified. Specifically, if the number of data with errors reaches or exceeds two, after sending a warning and notifying manual device inspection, the process will end, that is, at this time, the data consistency is poor, and it is difficult to make effective judgments relying on the existing data, and manual device inspection and re-detection are required. If the number of data with errors is less than or equal to one, the IDI smart contract will take the average value of the data without errors and end the consensus process, reaching a consensus on data consistency. That is, the IDI contract eliminates the influence of individual data deviations by taking the average value of the data without errors, ensuring the relative accuracy of the data.

[0087] In some of these embodiments, when the number of error data is equal to one, before taking the average value of the data without errors, it further includes: performing a warning and sending a device inspection notice step.

[0088] It should be noted that when the number of data with errors is one, before performing the error comparison step between the device data and the manual detection data, a warning needs to be sent and manual device inspection needs to be notified. That is, although the number of data with errors is only one at this time, in order to ensure data reliability and prevent the final result from deviating from the normal data, it is preferably to notify the manual to conduct a comprehensive inspection from multiple aspects such as the hardware condition of the device itself, the connection line, and the supporting software, and timely discover and repair these potential systematic problems, thereby overall improving the data quality level of the system.

[0089] In some of these embodiments, the consensus mechanism is the raft consensus mechanism.

[0090] Since the IDI system needs to analyze and process device data in a timely manner, adopting the raft consensus mechanism can quickly determine whether the data is valid and whether measures need to be taken. Compared with the proof-of-work (PoW) mechanism, etc., there is no need for nodes to perform a large number of complex calculations (such as finding hash values) to compete for the right to record accounts, thus avoiding consensus delays caused by the consumption of computing resources and being able to process a large amount of real-time data more efficiently.

[0091] In some of these embodiments, performing the error comparison process between the device data and the detection data to obtain the data that passes the verification includes:

[0092] After taking the average of the error-free data, the consensus process ends, and the average value is compared with the detected data to determine whether the error between the two is within the error range;

[0093] If it is, the data that passes the verification is obtained;

[0094] If not, a warning is issued, and a notice to re-measure the detected data and a notice to check the equipment are sent.

[0095] It should be noted that when initializing and setting the reasonable deviation range of the device to collect data, it includes setting the error between the device and manual work. The specific error value range can be adjusted according to the actual project situation. When the IDI smart contract takes the average of the error-free data, the obtained average value is compared with the manual detection data. If the error between the two is within the acceptable range set during initialization, the process ends, and the data that passes the verification is recorded in the blockchain; if the error between the two exceeds the acceptable range set during initialization, a warning needs to be sent before ending the overall process, and the manual is notified to re-measure the manual data and check the equipment. Thus, it can be seen that by the IDI smart contract, the deviation range and data reporting time are set, and the errors in the equipment and manual data are checked to prevent data distortion.

[0096] In some of the embodiments, the smart contract is further configured with a query interface, and the query interface is used to receive a data query request and query the corresponding device data and detection data in chronological order according to the project name in the data query request.

[0097] As Figure 5 shown, it should be noted that through the IDI contract query interface, after the user inputs the specific project name, the device and manual data recorded for this project can be viewed in chronological order, and the above data is summarized in the IDI platform. For third-party institutions, such as regulatory agencies, insurance companies, service agencies, etc., they can either directly obtain the above corresponding data from the IDI smart contract or directly query from the platform to achieve traceability of the data throughout the project life cycle.

[0098] In addition, the third-party institution can also compare and verify the queried results with the historical data in the IDI platform or other source registrations. Through the IDI contract, the data is classified according to the project name and shared to other systems and platforms, so as to trace the data of the entire life cycle of the project through the IDI contract interface and conduct data comparison and verification. Here, it should be noted that the historical data in this embodiment is the device historical data stored by the IDI contract according to the project name. Since the data previously queried by the third-party institution from the IDI platform or IDI contract may be stored locally, and the stored data may be affected by manual operation errors and other factors resulting in data errors, the re-queried results can be compared and verified with the historical data to ensure the accuracy and reliability of the data used.

[0099] In summary, this application introduces blockchain technology into the engineering quality potential defect insurance system, uses the IDI contract to record device information and manual inspection data respectively, introduces a consensus mechanism to exclude the data generated by faulty devices, and ensures the reliability of the data. And all device and manually generated data are recorded on the blockchain to achieve data verification and traceability management based on the project name, covering the content of the entire life cycle to ensure the integrity and traceability of the data.

[0100] In the description of this specification, the descriptions referring to terms such as "one embodiment", "example", "specific example", etc. mean that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in a suitable manner in any one or more embodiments or examples.

[0101] Unless otherwise defined, the technical terms or scientific terms involved in this application should have the ordinary meanings understood by those of ordinary skill in the technical field to which this application belongs. The words such as "a", "one", "the" and the like involved in this application do not represent a quantity limitation and can represent a single or plural number. The terms "including", "comprising", "having" and any variations thereof involved in this application are intended to cover non-exclusive inclusion. The words such as "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but include electrical connections, whether direct or indirect. The "multiple" involved in this application means two or more, and the " / " in "and / or" describes the association relationship of associated objects, indicating that three relationships can exist. The character " / " generally represents an "or" relationship between the associated objects before and after. The terms "first", "second", "third", etc. involved in this application are only used to distinguish similar objects and do not represent a specific order for the objects.

[0102] The above embodiments only represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation to the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications or improvements can still be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the appended claims.

Claims

1. A potential defect insurance system for engineering quality based on blockchain and the Internet of Things, characterized by: include: IoT terminals, used to obtain multiple sets of device data; The blockchain deploys a smart contract with insurance for potential defects in engineering quality. The smart contract is used to input multiple sets of equipment data and execute the data inspection process according to the time standard and data deviation range set by the initialization, where: After the current device data is recorded in the smart contract, query whether other devices have data records; When data records exist for other devices, calculate the time interval between the last reporting time and the current time, and determine whether it exceeds the maximum interval for the device to upload data: if it exceeds, issue an early warning and send a device inspection notification; if it does not exceed, determine whether multiple sets of device data are within the data deviation range, and issue an early warning if it exceeds, and send a device inspection notification; The smart contract is also used to enter the test data. After entering the test data, it queries all devices to see if there are data records. When all devices have data records, the interval between the last reporting time and the current time is calculated, and it is determined whether it exceeds the maximum interval for the device to upload data: if it exceeds, an early warning is issued and a device inspection notification is sent; if it does not exceed, the smart contract starts the consensus mechanism and executes the error comparison process between the device data and the detection data to obtain the verified data; where: The smart contract starts the consensus mechanism including: the smart contract queries the latest data in multiple sets of device data and determines whether there is a data error: if the number of error data is greater than or equal to two, an early warning is issued and a device inspection notification is sent; if the number of error data is less than or equal to one, the average value of the data without error is taken; The engineering quality potential defect insurance platform is used to store all data and return query results when receiving data query requests.

2. The engineering quality potential defect insurance system based on blockchain and the Internet of Things according to claim 1 is characterized in that: When the smart contract initializes the time standard, it sets the maximum interval time for the device to upload data according to the project requirements; When the smart contract initializes the data deviation range, it sets the equipment collection data deviation range corresponding to the key indicators and the error range between the equipment data and the detection data according to the project requirements.

3. The engineering quality potential defect insurance system based on blockchain and the Internet of Things according to claim 2 is characterized in that: The key indicators include horizontal displacement indicators, foundation settlement indicators and rod inclination indicators.

4. The engineering quality potential defect insurance system based on blockchain and the Internet of Things according to claim 1 is characterized in that: When the number of error data is equal to one, before averaging the data without errors, also include: Execute the steps of warning and sending equipment inspection notification.

5. The engineering quality potential defect insurance system based on blockchain and the Internet of Things according to claim 1 is characterized in that: The error comparison process between the execution device data and the detection data to obtain the verified data includes: After taking the average value of the data without error, the consensus process ends, and the average value is compared with the test data to determine whether the error between the two is within the error range; If so, the verified data is obtained; If it is not there, an early warning will be issued, and a notification to re-measure the test data and a notification to check the equipment will be sent.

6. The engineering quality potential defect insurance system based on blockchain and the Internet of Things according to claim 1 is characterized in that: The smart contract is also configured with a query interface, which is used to receive a data query request and query the corresponding device data and detection data in chronological order according to the project name in the data query request.

7. The engineering quality potential defect insurance system based on blockchain and the Internet of Things according to any one of claims 1 to 6 is characterized in that: The consensus mechanism is the raft consensus mechanism.

Images