Fire-fighting maintenance data offline synchronization method and system

Abstract

The application relates to the technical field of data synchronization, and discloses a fire-fighting maintenance data offline synchronization method and system. The method comprises the following steps: acquiring signal blind area inspection information, matching a device unique code and binding a local time source, and generating inspection data objects; extracting a maintenance personnel identity identification embedded object, calculating a hash value and adding an anti-tampering signature value to obtain complete record data; analyzing a device state, matching a level when an exception occurs, assigning a default level when normal, and generating graded record data; locally encrypting the graded data, writing the graded data into a safety area, establishing an index, and generating an offline file; reading the index, monitoring a network signal, extracting a file to obtain a to-be-synchronized set when recovery occurs, and maintaining storage when recovery does not occur; extracting a signature in the to-be-synchronized set and verifying the integrity, screening a passed set, sending the passed set to a central server, and receiving a confirmation receipt; marking a synchronized file according to the receipt, and completing synchronization. The method can solve the problem of insufficient timeliness of data synchronization.

Description

Technical Field

[0001] This invention relates to the field of data synchronization technology, and in particular to a method and system for offline synchronization of fire protection maintenance data. Background Technology

[0002] Currently, the maintenance and upkeep of fire protection facilities is an indispensable part of the urban safety system, especially in underground buildings, basements, and areas with weak signal coverage, where the workload for fire equipment inspection is enormous. Maintenance personnel must undergo identity verification and regularly record data from equipment such as fire hydrants and smoke detectors to ensure that critical facilities are always in reliable operating condition.

[0003] In one existing technology, maintenance personnel need to log in to the cloud-bound inspection APP with an account and password in an environment with network access to complete identity registration. In areas with network access, maintenance personnel can select the status of equipment such as fire hydrants and smoke detectors through the APP, and the data is uploaded to the cloud in real time. In scenarios without network or with weak network access, the equipment status and inspection time are handwritten in a paper notebook. After returning to an environment with network access, the paper records are manually transcribed to the APP.

[0004] However, data uploading and identity verification both require a stable network. Underground spaces and areas with no signal can not operate normally, and data cannot be collected in real time. When there is no network, paper records are prone to errors in status and inspection time due to human memory bias. Offline forms lack authoritative timestamps, and the time information is out of sync with the actual inspection time. Different maintenance personnel have different handwritten / offline filling formats, resulting in low data standardization. Subsequent cloud integration requires manual verification, which is inefficient. In summary, the existing technology has the problem of insufficient timeliness of data synchronization. Summary of the Invention

[0005] This invention provides a method and system for offline synchronization of fire protection maintenance data to solve the problem of insufficient timeliness of data synchronization in the prior art.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a method for offline synchronization of fire protection maintenance data, comprising: Obtain signal blind zone inspection information, generate inspection data objects based on the reliable time source of the internal hardware crystal oscillator and the signal blind zone inspection information; extract the maintenance personnel's identity identifier and embed it into the inspection data objects, and generate an anti-tampering signature value to be appended to the end of the record to generate complete record data; The device status in the complete record data is parsed. If the device status is abnormal, the corresponding abnormal level is matched. If the device status is normal, the default level is used to generate hierarchical record data. The hierarchical record data is locally encrypted, written to a preset secure storage area, and an offline inspection record file containing index information is generated. Read the index information of the offline inspection record file, monitor the network signal status, extract the offline inspection record file when the network is restored, and maintain local storage when the network is not restored to obtain a set of records to be synchronized. Extract the tamper-proof signature value of each data in the set of records to be synchronized and perform integrity verification. Filter out the set of records that pass the verification, send it to the central server, and receive the confirmation receipt returned by the server. Based on the confirmation receipt, the offline inspection record file that has been synchronized locally is marked for synchronization, and a record file with completed synchronization marking is generated.

[0007] Secondly, the present invention provides an offline synchronization system for fire protection maintenance data, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0008] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0009] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention calculates the local time source using a local crystal oscillator, without relying on external time synchronization; it completes signing and encrypted storage offline and continuously monitors network status, automatically synchronizing upon recovery. Compared to existing technologies that rely on a stable network connection for real-time data upload and identity verification, this method solves the problem of being unable to work in signal blind areas, as maintenance personnel cannot log in to the inspection APP or upload equipment status data in real time in signal blind areas.

[0010] (2) The present invention completely eliminates the interference of time synchronization deviation between the terminal and the server on the synchronization confirmation process by using the receipt matching mechanism based on the request identifier; and judges the actual network recovery status by using the RSSI threshold to avoid synchronization failure caused by signal jitter and improve synchronization efficiency. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the offline synchronization method for fire protection maintenance data provided in the first embodiment of the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] Reference Figure 1 The first embodiment of the present invention provides a method for offline synchronization of fire protection maintenance data, including the following steps: S11, Obtain signal blind zone inspection information, generate inspection data object based on the reliable time source of the internal hardware crystal oscillator and the signal blind zone inspection information; extract the maintenance personnel's identity identifier and embed it into the inspection data object, and generate an anti-tampering signature value to be appended to the end of the record to generate complete record data; S12, parse the device status in the complete record data. If the device status is abnormal, match the corresponding abnormal level. If the device status is normal, use the default level to generate hierarchical record data. S13, the hierarchical record data is locally encrypted and written to a preset secure storage area to generate an offline inspection record file containing index information; S14, Read the index information of the offline inspection record file, monitor the network signal status, extract the offline inspection record file when the network is restored, and maintain local storage when the network is not restored, to obtain the set of records to be synchronized; S15, extract the anti-tampering signature value of each data in the set of records to be synchronized and perform integrity verification, filter out the set of records that pass the verification, send it to the central server and receive the confirmation receipt returned by the server; S16, based on the confirmation receipt, the offline inspection record file that has been synchronized locally is marked for synchronization, and a record file with completed synchronization marking is generated.

[0014] In step S11, acquiring signal blind zone inspection information and generating inspection data objects based on the reliable time source of the internal hardware crystal oscillator and the signal blind zone inspection information includes: Obtain the current count value of the internal hardware crystal oscillator in the fire-fighting equipment currently under inspection; The signal blind zone inspection information is input into a pre-built equipment identification database for spatial comparison. When a corresponding fire-fighting equipment is matched, the unique code of the fire-fighting equipment to be inspected is extracted. The millisecond-level time offset of the device since the last network synchronization is calculated based on the current count value, and the local time source is deduced. The local time source is used to perform a time binding operation on the unique code to generate associated data containing the device identity and the time of occurrence; The associated data is encapsulated and a cyclic redundancy check code is added to obtain an inspection data object carrying precise time.

[0015] It should be noted that the inspection information in signal blind zones includes the current location coordinates of the equipment, operating status parameters such as vibration amplitude, pressure, temperature, and visual inspection results. Location coordinates are obtained via GPS, Bluetooth beacons, or geomagnetic positioning; status parameters are obtained through terminal sensor measurements or manual input; and visual inspection results are selected by maintenance personnel or input via voice. In signal blind zones, the inspection terminal cannot obtain external time synchronization via base stations or network time protocols. Therefore, the terminal integrates an independently operating hardware crystal oscillator with a fixed and known oscillation frequency, such as 32.768 kHz, which is the standard frequency of the real-time clock circuit. The system directly reads the number of oscillation cycles accumulated by the oscillator from the last successful synchronization with the central server to the current inspection time to obtain the current count value. Simultaneously, the terminal's local non-volatile memory always stores a "last network synchronization reference timestamp" variable, which is updated to the standard time returned by the server after each data synchronization with the central server. This count value does not depend on any external network signal and is generated entirely by the terminal's local hardware, thus ensuring the continuity of the time base in offline mode.

[0016] Maintenance personnel confirm their current location on the inspection terminal. To ensure spatial data consistency, the system uniformly converts all location information to the WGS84 geographic coordinate system. For outdoor areas, it directly uses the GPS / BeiDou coordinates cached when the terminal signal is good; for indoor areas, it uses pre-deployed Bluetooth beacons (each beacon is calibrated with WGS84 coordinates) or a pre-collected geomagnetic fingerprint database (each fingerprint point is calibrated with coordinates) to obtain the current location's WGS84 coordinates in real time. The system uses these coordinates as input parameters and performs spatial comparisons against a pre-built and locally stored device identification database. This database pre-inputs the installation coordinates and corresponding unique codes of all fire-fighting equipment, all using the WGS84 coordinate system. During matching, a nearest neighbor spatial matching algorithm is used, setting a reasonable search radius, such as 2.0 meters, to search for registered equipment within this coordinate range. When a unique fire-fighting device is matched within this radius, its corresponding unique code is extracted, for example, "857392". If multiple devices are matched within the search radius, they are sorted in ascending order of their Euclidean distance from the inspection point. If equal distances are found, the first device is selected in ascending order of its string ID. If no device is matched, the terminal prompts maintenance personnel to manually enter the device ID or relocate it.

[0017] In underground buildings or areas with dense equipment, fire protection equipment (such as smoke detectors and sprinkler heads) is often installed side by side with a spacing of less than 1 meter. However, positioning methods such as Bluetooth or GPS have a positioning error of 2-5 meters in indoor environments. If only nearest neighbor matching is relied upon, inspection data may be incorrectly bound to adjacent devices. If the difference between the minimum and second-minimum distances is less than a preset tolerance threshold, such as 0.5 meters, the positioning is considered ambiguous, triggering the terminal to display the candidate device list for maintenance personnel to manually confirm and select. If the difference between the minimum and second-minimum distances is greater than or equal to the preset tolerance threshold, the device with the smallest distance is automatically selected as the matching result.

[0018] The tolerance threshold is dynamically set based on the nominal accuracy of the positioning technology currently used by the terminal. If the nominal accuracy of the positioning technology is set to ±ε meters, then the error in the measured distance between the positioning point and any device is ±ε meters, and the error range of the difference in the measured distance between the two devices and the positioning point is ±2ε meters. If the difference between the minimum and second minimum distances is greater than 2ε meters, the system determines the automatic matching result is correct with over 95% confidence; if the distance difference is less than or equal to 2ε meters, the positioning accuracy is insufficient to reliably distinguish between the two candidate devices, triggering manual confirmation. For example, the limit accuracy of Bluetooth 5.0 with filtering algorithm is approximately ±1 meter, so the tolerance threshold is set to 2 meters, meaning that when the distance difference between the two devices and the positioning point is less than 2 meters, maintenance personnel must manually confirm and select the device.

[0019] For mobile fire-fighting equipment, such as temporarily placed fire extinguishers and mobile fire pumps, their location information may change. The system automatically retrieves the latest equipment location database from the central server and updates its local storage each time a network connection is available; in offline mode, it uses the last updated database for matching. If maintenance personnel find that the actual equipment location does not match the database, they can manually trigger a data synchronization update when a network connection is available.

[0020] After obtaining the current count value of the crystal oscillator, the system calculates the time offset since the last network synchronization based on its fixed operating frequency. Dividing the current count value by the oscillator frequency yields the time offset in seconds. The system reads the reference timestamp stored locally on the terminal when it last successfully synchronized with the central server, such as the standard time returned by the server. Adding the calculated time offset to this reference timestamp allows the system to deduce the local time source for the current inspection moment.

[0021] Using the local time source calculated above, a time binding operation is performed on the extracted device unique code. Specifically, the precise time of the local time source is logically associated with the unique code to generate associated data containing "device identity information" and "inspection occurrence time". For example, the content of this associated data is in the form of device number 857392 plus inspection time (May 31, 2025, 14:35:20:123). This binding operation establishes a one-to-one correspondence between the device and the time.

[0022] The system employs a binary serialization algorithm to encapsulate the aforementioned associated data, converting it into binary data blocks with a fixed format. During serialization, fields are written sequentially according to a preset order, such as timestamp fields, device code fields, and reserved fields, ensuring the integrity of the data structure and the determinism of parsing. After encapsulation, the system calculates the cyclic redundancy check (CRC) code for the entire binary data block, for example, using the CRC32 algorithm, and appends the calculated checksum to the end of the data block. This CRC code is used to quickly detect whether bit errors have occurred in the data due to storage medium wear or transmission interference during subsequent local storage, index building, or network synchronization. After the above encapsulation and checksum appending process, a final inspection data object carrying precise time and possessing integrity self-checking capabilities is obtained.

[0023] Specifically, the process involves extracting the maintenance personnel's identification and embedding it into the inspection data object, generating an tamper-proof signature value and appending it to the end to create complete record data, including: Obtain the current session token and the private key of the inspection terminal; Extract the feature hash value of the biometric template of the maintenance personnel, bind the feature hash value with the current session token to generate the maintenance personnel identity identifier; The maintenance personnel identification is embedded as an additional field into the inspection data object to form extended record data that integrates identity information. The extended record data is iteratively compressed to obtain a hash digest; By combining the private key of the inspection terminal with the hash digest for signature operation, an anti-tamper signature value is generated and appended to the end of the record to obtain complete record data.

[0024] It should be noted that before maintenance personnel log into the inspection terminal and begin offline inspection tasks, the terminal has already authenticated with the central server during its last network connection and obtained a temporary session token. This session token is issued by the server, and its data structure includes the issuance time, validity period (e.g., 8 hours), and the server's signature. The terminal stores this token encrypted in its local non-volatile memory. Simultaneously, a pair of asymmetric keys is pre-installed in the inspection terminal's internal security chip or encrypted storage area, including the inspection terminal's private key, which is held exclusively by the terminal. In offline mode, the system directly reads the session token and the inspection terminal's private key from its local secure storage.

[0025] In offline mode, the terminal cannot verify with the server in real time whether the session token has been prematurely cancelled, such as due to personnel leaving the company. Therefore, the terminal checks the validity period field in the session token locally, comparing the current local time (calculated by a hardware crystal oscillator) with the expiration time. If the current time has exceeded the expiration date, the token is deemed invalid, the terminal prevents the generation of new inspection record data, and prompts maintenance personnel with "Offline session expired, please log in again online." If the token is still valid, even if the server has unilaterally cancelled the token, such as through forced cancellation by an administrator, inspection records can still be generated because this cannot be known during offline operation. However, during subsequent network synchronization, the central server will verify the signature and token validity. The server can check whether the token is valid and has not been revoked. If it finds that it has been prematurely cancelled, it will refuse to receive that batch of data and notify the terminal to update the token.

[0026] Before commencing inspections, maintenance personnel must input their biometric templates using the terminal's biometric data acquisition module, such as a fingerprint sensor or facial recognition camera. Upon initial use, personnel input their biometrics (fingerprint or face) via the terminal in a network environment. The terminal extracts the feature vector and calculates its hash value, for example, using the SM3 algorithm. This hash value is then encrypted using the terminal's public key and uploaded to the central server, while simultaneously being encrypted and stored locally in the terminal's secure area. Subsequently, with a network connection, the terminal can periodically download the latest template hash value from the server to overwrite the local version. For situations where multiple personnel share the terminal, it can store the template hash values ​​for multiple maintenance personnel, each with a unique personnel ID. In offline mode, maintenance personnel first perform local identity verification via biometrics.

[0027] The terminal collects the biometric features of the current person in real time and extracts feature vectors of fixed dimensions, such as 128 or 512 dimensions for facial feature vectors and 256 dimensions for fingerprint minutiae feature vectors. The system has already saved the person's baseline feature vector template library in its local secure storage area during initial registration or the last synchronization. During offline verification, the similarity distance between the real-time collected feature vectors and each template vector in the template library is calculated. For face recognition, Euclidean distance or cosine similarity is calculated; for fingerprint recognition, each dimension is normalized using Min-Max normalization to map the value range of each dimension uniformly to the [0,1] interval, and then the Manhattan distance of the normalized minutiae set or the matching degree based on Hausdorff distance is calculated. When the similarity distance is less than a preset security threshold, for example, a face Euclidean distance threshold of 0.6 and a fingerprint Manhattan distance threshold of 0.7, it is determined to be the same person, and verification passes; otherwise, verification fails. If a match is successful, the corresponding identity identifier is extracted for subsequent record generation. If the template for the person is not stored locally, the inspection cannot be started offline. The template must be synchronized online before use.

[0028] The face Euclidean distance threshold utilizes widely used open-source libraries such as face_recognition. The authors of the underlying dlib library calculated the Euclidean distance using a large number of positive and negative sample pairs (same person / different people) and found the optimal split point of 0.6 using a decision tree algorithm. In dlib's 128-dimensional feature space, the feature distance for the same person is typically less than 0.6, while for different people it is greater than 1.2. The fingerprint Manhattan distance threshold is determined by collecting a large number of real fingerprint samples, plotting the Receiver Operating Characteristic (ROC) curve, and analyzing the balance point between FAR and FRR, i.e., the "equal error rate" EER. In this embodiment, it is set to 0.7.

[0029] When generating an identity identifier, the system extracts the hash value of the biometric template and performs a binding calculation with the current session token. Specifically, the feature hash value and the session token are concatenated in a predetermined order and then input into a hash algorithm for iterative compression, generating a 256-bit hash result, which is the maintenance personnel's identity identifier. This binding calculation uniquely associates the personnel's biometric features with the current session, preventing identity impersonation or replay attacks.

[0030] The maintenance personnel identification identifier generated above is used as an additional field and embedded into the inspection data object generated in step S11 using a structured mapping protocol. This embedding operation does not destroy the original data structure; instead, it writes the identification identifier to the preset extended field position. To improve efficiency, memory mapping (mmap) can be used to directly map this data block from the storage device to the user process virtual address space of the inspection terminal. This allows the application to directly manipulate the memory data in the mapped area in user mode, avoiding redundant copying of data between the kernel buffer and the user buffer in traditional I / O operations, thereby reducing CPU overhead and improving data writing efficiency. Ultimately, this forms an extended record data that integrates device information, inspection time, and maintenance personnel identification information.

[0031] The entire byte sequence of the extended record data is taken as input, and an iterative compression calculation is performed using a cryptographic hash algorithm, such as SHA-256. This algorithm converts an input of arbitrary length into a fixed-length output. The hash digest is one-way and collision-resistant, meaning it is impossible to deduce the original data from the digest, and the probability of different data producing the same digest is extremely low.

[0032] Using the private key of the inspection terminal obtained in step one, a digital signature operation is performed on the hash digest. Specifically, an elliptic curve digital signature algorithm, such as ECDSA, is used, with the curve parameters selectable as secp256k1 or SM2. This algorithm takes the hash digest and the terminal's private key as input and generates a fixed-length signature value, for example, 512 bits. Due to the computational complexity of the elliptic curve discrete logarithm problem, this signature value is unforgeable: only the terminal holding the corresponding private key can generate a valid signature, and no third party can forge it.

[0033] The generated tamper-proof signature value is appended to the end of the extended record data, forming a complete record data containing the original data, identity information, hash digest, and digital signature. This complete record data can be stored independently without an internet connection, and its authenticity and integrity can be verified by a central server using a pre-acquired terminal public key after the network is restored in the future.

[0034] In step S12, the device status in the complete record data is parsed. If the device status is abnormal, the corresponding abnormal level is matched; if the device status is normal, the default level is used to generate hierarchical record data, including: The device status in the complete recorded data is analyzed, and the vibration amplitude of the device is detected based on the device status. If the vibration amplitude exceeds a preset amplitude threshold, the deviation between the vibration amplitude and the amplitude threshold is calculated. Calculate the absolute difference between the deviation value and the boundary of each level in the preset level mapping table, and determine the abnormal level based on the absolute difference; If the device status is normal, directly assign the default level to form hierarchical record data.

[0035] The system analyzes the complete record data generated in step S11, and extracts the device status field according to the predefined data structure format. This field contains the device operation parameters collected by the maintenance personnel through terminal sensors or manual input during the patrol inspection, such as vibration amplitude, temperature, pressure, current, etc. In this embodiment, the vibration amplitude is used as the core index for judging whether the device is abnormal.

[0036] The system reads the preset normal amplitude threshold from the local configuration, for example, set to 8.5 millimeters per second. Compare the actually detected vibration amplitude with this threshold. If the actual vibration amplitude is less than or equal to the preset threshold, it is determined that the device status is normal; if the actual vibration amplitude is greater than the preset threshold, it is determined that the device status is abnormal, and an abnormal level matching process is triggered.

[0037] The "preset normal amplitude threshold" is pre-determined based on the national fire equipment operation standards, the technical specifications provided by the equipment manufacturer, and the statistical analysis results of historical patrol inspection data. Specifically, at least 30 fire equipment of the same model, same work conditions and confirmed as "normal" by the factory calibration or third-party inspection are selected, and the vibration amplitude data is collected using the vibration sensor supporting the terminal under standard operating conditions. Ensure that the sampling frequency is not less than 1 kHz during collection, and the collection duration is not less than 10 seconds each time. Take the root mean square value as the amplitude representative value of the device.汇总所有采集到的代表值,计算算术平均值μ和样本标准差σ。依据统计过程控制中的3σ准则,即正态分布下99.7%的正常数据落在μ±3σ范围内,将正常幅值阈值设为μ+3σ,对于本例,阈值为4.2+3×1.1=7.5mm / s。该阈值可在系统部署阶段由管理员根据实际设备型号和现场环境配置,并存储在巡检终端的本地配置文件中。在本发明的离线巡检场景下,该阈值无需网络获取,直接由终端本地读取并用于实时判断。

[0038] When it is determined to be abnormal, the system calculates the deviation value between the current vibration amplitude and the preset threshold. The deviation value is equal to the absolute value of the actual vibration amplitude minus the preset threshold. This deviation value reflects the degree of device abnormality. The greater the deviation, the more the device operation state deviates from the normal range. If it is determined that the device status is normal, the system does not calculate the difference, but directly assigns a default level. For example, the default level is level 1, indicating that the device is operating normally. This default level occupies the same field position as the abnormal level in the data structure.

[0039] The system pre-stores anomaly level mapping table, which defines the boundaries of vibration amplitude exceedances (i.e., deviation values) corresponding to different anomaly levels. These boundary values ​​are set according to the vibration intensity level ranges for the corresponding equipment type in the International Organization for Standardization (ISO) standard ISO 10816, "Mechanical vibration – Measurement and evaluation of vibration of machines on non-rotating parts". ISO 10816 provides effective vibration velocity ranges (in mm / s) for four zones (A (good), B (acceptable), C (alarm), and D (dangerous) for rotating machinery of different power and installation methods (such as fire pumps and fans). Specifically, the mapping method is that the vibration amplitude for the normal level (default) requires μ + 3σ (corresponding to the boundaries of zones A / B in ISO 10816). The deviation value for a first-level anomaly (minor) is equal to the actual amplitude minus (μ + 3σ), and the deviation range corresponds to the entire width of zone C (alarm zone) in ISO 10816. For example, if zone C for a certain type of water pump is 7.5~11.5 mm / s, then the deviation value boundary is 0~4.0 mm / s. The deviation range for Level 2 anomalies (severe) corresponds to the lower half of Zone D (hazardous zone) in ISO 10816, for example, 4.0~8.0 mm / s. The deviation range for Level 3 anomalies (critical) exceeds the median value of Zone D, for example, >8.0 mm / s. For example, if the deviation is 4.2 mm / s, it falls within the Level 2 anomaly range and is therefore classified as a Level 2 anomaly.

[0040] The above-determined anomaly level (or default level) is associated with other information in the complete record data, such as device code, timestamp, personnel identity, and device status parameters, to generate a record data containing a classification marker, i.e., classification record data.

[0041] In step S13, the local encryption processing of the hierarchical record data, the writing of it to a preset secure storage area, and the generation of an offline inspection record file containing index information include: Obtain the device's unique hardware fingerprint; A session key is generated based on the unique hardware fingerprint, and the hierarchical record data is encrypted in blocks based on the session key to obtain block record data. The block record data is written into a preset secure storage area, the address offset is calculated, and index information is generated. Calculate the file size of the hierarchical record data, and organize the file size, the index information, the address offset, and the block record data into a file to obtain the offline inspection record file.

[0042] It should be noted that the inspection terminal has a built-in, tamper-proof, unique hardware fingerprint. This fingerprint is read by a security chip (TPM), and the session key derivation process is completed internally within the security chip; the original hardware fingerprint value cannot be directly read externally. The system reads this unique hardware fingerprint by calling the underlying hardware interface. This fingerprint is globally unique and cannot be copied. The system uses a key derivation function, such as an HMAC-based extraction and expansion algorithm, to derive a 256-bit session key using the unique hardware fingerprint as input and a randomly generated salt value. Subsequently, an authentication encryption algorithm, such as AES-256-GCM, is used to encrypt all bytes of the hierarchical record data. To improve encryption efficiency and flexibility, the system divides the data into multiple fixed-size blocks, such as 64 bytes or 128 bytes per block, and encrypts each block separately, forming block-based record data. Simultaneously, the GCM mode generates an authentication tag used to verify data integrity during decryption.

[0043] To protect the overall integrity of the entire segmented record dataset, after segmented encryption is completed, the system additionally calculates a hash value (e.g., SHA-256) for the ciphertext data of all segments and records this hash value as integrity verification information in the file header metadata. In the subsequent verification stage before synchronization, the system recalculates the overall hash value of all segmented ciphertext and compares it with the recorded value in the metadata to detect any changes in segment order, missing segments, or replays. At the same time, GCM authentication tags are used to verify the transmission integrity of individual data blocks during synchronous transmission. The combination of these two measures forms a dual integrity protection from storage to transmission.

[0044] The system pre-allocates a secure storage area in the terminal's flash memory or encrypted storage chip, for example, by pre-creating encrypted files of a fixed size or partitioning a dedicated storage area. This area has a fixed size and an independent file namespace. During the data writing phase, the system sequentially writes to this storage area using the operating system's standard file I / O interfaces (such as open, write, and fsync) to ensure data persistence to disk. This area is typically located within an encrypted file system to prevent unauthorized access by ordinary applications.

[0045] The system writes the encrypted block record data sequentially into the region and records the file offset of each block relative to the start position of the storage region. For example, the file offset of the first block is 0x0000, the second is 0x0080, and so on. Simultaneously, a unique record identifier (which can be an auto-incrementing ID or a UUID) is generated for each hierarchical record data, and this record identifier is concatenated with the timestamp generated in step S11 to form a 64-bit integer, which serves as the index key. The system uses a B+ tree data structure to construct the index, inserting the key into the B+ tree. The leaf nodes contain the corresponding file offset, block length, and expiration timestamp, such as 172800 seconds, or 48 hours. This index information enables fast retrieval of offline files by record ID or time range without sequentially scanning the entire storage region.

[0046] To ensure correct addressing during subsequent data retrieval, the system records a unique identifier for the preset secure storage area and the file offset of each data block relative to the starting position of that storage area in the file header metadata of the offline inspection log file. During reading, the system locates the corresponding persistent storage file using the unique identifier, then adds the current starting position of that file to the recorded relative offset to obtain the accurate byte position of the target data block within the file. This allows for precise reading of the data blocks through a file read interface with offsets (such as the pread system call).

[0047] The system collects all the above elements, including the file size of the hierarchical record data, the index information, the address offset, and the block record data itself, and packages them according to a predefined binary file format. The file header stores metadata (file size, index information start position, etc.), the middle area stores index information, and the tail or data area stores the block record data. After packaging, a complete offline inspection record file is obtained. This file can be stored, copied, or transmitted independently, and can be parsed by the synchronization module after network recovery.

[0048] In step S14, the process of reading the index information of the offline inspection record file, monitoring the network signal status, retrieving the offline inspection record file when the network is restored, and maintaining local storage when the network is not restored, yields a set of records to be synchronized, including: Read the index information from the encrypted offline inspection record file, retrieve the leaf nodes based on the index information, and obtain the leaf node set; Monitor network signal status, calculate signal strength indicator value and packet loss rate. When the signal strength indicator value is greater than a preset strength threshold and the packet loss rate of five consecutive network probes is less than a preset percentage, it is determined that the network signal has been restored. If the network signal is not restored, the local storage state will continue, and the set of leaf nodes will be marked as pending synchronization. If the network signal is restored, the block record data in the leaf node set is loaded into memory according to the offset in the leaf node set to form a set of records to be synchronized.

[0049] It should be noted that, from the encrypted offline inspection record file generated in step S13, the system first reads the starting position of the index information at the beginning of the file to locate the root node of the B+ tree index structure. Depending on the synchronization requirements, such as synchronizing all unmarked records, the system starts from the B+ tree root node and uses binary search within the current node to locate the pointer to the child node corresponding to the target key value. It traverses downwards layer by layer until the corresponding leaf node is found, obtaining a set of leaf nodes. This set points to the specific location of all encrypted record blocks to be extracted in the secure storage area.

[0050] The system activates a network signal monitoring module, which periodically acquires the Received Signal Strength Indicator (RSSI) value of the current network interface and calculates the packet loss rate by sending Internet Control Message Protocol (ICMP) probe packets. To accurately determine whether the network has recovered to a synchronizeable level, the system sets a preset strength threshold, such as -65 dBm (decibels per milliwatt), which corresponds to the lower limit of signal strength for stable data transmission. When the detected RSSI value is greater than -65 dBm, the system determines that the network signal has recovered.

[0051] The preset signal strength threshold is a key indicator for measuring wireless signal strength, usually measured in decibels and milliwatts (dB / mW). A higher value indicates a stronger signal. According to the IEEE 802.11 standard, an RSSI above -50dBm indicates excellent signal strength, suitable for high-speed data transmission; an RSSI between -50dBm and -70dBm indicates good signal strength, supporting stable transmission with a low error rate; an RSSI below -70dBm indicates weak signal strength, potentially leading to unstable connections and increased packet loss; and an RSSI below -80dBm indicates very poor signal strength, potentially causing frequent connection interruptions and difficulty in data upload. Considering that fire safety maintenance data synchronization requires the transmission of encrypted record files, such as hundreds of KB per record, totaling hundreds of KB to several MB, the network must support TLS secure connection establishment and complete file uploads. Therefore, an RSSI of at least -65dBm is typically required. This threshold is effective in most areas with weak but still passable signals, such as underground parking garages and stairwells, while avoiding upload failures or repeated retransmissions due to excessively low signal strength, thus saving power and time. Meanwhile, -65dBm can be used as a universal judgment value for mobile communication networks (4G / 5G) and Wi-Fi at the edge of blind spots, and has universality.

[0052] To ensure synchronization success rate and efficiency, and to avoid misjudgments due to momentary interference or brief signal fluctuations, the system activates a network signal monitoring module to periodically acquire the RSSI value of the current network interface. It also initiates TCP layer connectivity probes to the central server, such as TCP SYN handshakes or TLS ClientHello, to calculate connection success rate and response latency. The system determines that the network signal has recovered when the RSSI is greater than a preset strength threshold, the connection success rate of five consecutive TCP probes is higher than a preset percentage (e.g., 95%), and the packet loss rate is equal to 1 minus the success rate (i.e., a packet loss rate below 5%).

[0053] If the above conditions are not met, the network signal is determined to have not been restored. At this time, the system does not perform any data extraction operations and continues to maintain the local storage state of the offline inspection record files. Simultaneously, the obtained set of leaf nodes is marked as "pending synchronization" so that it can be retried in subsequent network monitoring cycles. The system will continuously run the network monitoring module, re-checking the signal status at regular intervals (e.g., 30 seconds) until the network is restored.

[0054] It should be noted that the system activates the network signal monitoring module, simultaneously performing two types of probes: a rapid assessment of network connectivity via ICMP probe packets and a TCP layer connectivity probe initiated to the central server, such as a TCP SYN handshake or TLS ClientHello, to calculate connection success rate and response latency. The final determination of network recovery is based on the TCP probe results. When the RSSI value is greater than a preset strength threshold and the connection success rate of five consecutive TCP probes is higher than 95%, the network signal is considered to have recovered. The ICMP probe results serve as a quick pre-check of network status. Even if the probe fails (e.g., if a firewall blocks ICMP responses), the system should still directly initiate a TCP probe, ensuring that the synchronization process is not hindered by ICMP failure. Once the network signal is determined to have recovered, the system immediately triggers the data extraction process. Specifically, this involves traversing the leaf node set. Based on the logical offset and block length recorded in each leaf node, the corresponding ciphertext block is read from the persistent storage area and loaded into memory using a standard file read interface, such as the `pread` system call with offset, forming a set of records to be synchronized. This set contains the encrypted data from all offline inspection record files that have not yet been synchronized.

[0055] In step S15, the extraction of the tamper-proof signature value of each piece of data in the set of records to be synchronized and the execution of integrity verification, the selection of the set of records that pass the verification, the sending to the central server, and the receipt of the confirmation acknowledgment returned by the server include: Obtain the public key; Extract the tamper-proof signature value of each data item in the set of records to be synchronized, and verify the tamper-proof signature value using the public key to obtain the first hash value; The hash value of each data item in the set of records to be synchronized, excluding the tamper-proof signature value, is recalculated to obtain a second hash value. For each piece of data, compare the first hash value with the second hash value. If they are equal, the data is determined to have passed the verification. All data that have passed the verification are combined into a set of verified records. The verified record set is sent to the central server, and a confirmation receipt is received from the central server.

[0056] It should be noted that when the inspection terminal completes its initial registration or authentication with the central server, the server issues a digital certificate to the terminal. This certificate contains the terminal's public key, which is paired with the terminal's private key. The terminal pre-stores this public key in a local secure area, such as a protected file system or a security chip. Before the verification process begins, the system reads this public key directly from the local storage. The public key is public information and does not involve confidentiality requirements, but its source must be trustworthy, and its authenticity is usually verified through a server certificate chain.

[0057] The system iterates through the set of records to be synchronized generated in step S14. For each complete record in the set, it first locates the tamper-proof signature value segment at the end of the record. This signature segment is generated after signing the hash digest of the record content using the terminal's private key in step S11. Taking the tamper-proof signature value and the public key as input, the system uses the same elliptic curve digital signature algorithm (e.g., ECDSA) as used during signing to recover the original hash digest, which is recorded as the first hash value. If the signature has not been tampered with during storage and was indeed generated by the corresponding private key, decryption is successful; if the signature or record content is corrupted, the decryption process will fail or result in invalid data.

[0058] The system recalculates the hash value for all original content of the same complete record data, excluding the signature portion—that is, the extended record data described in step S11. The hash algorithm used must be consistent with the algorithm used to generate the signature in step S11, such as SHA-256. The calculated hash value is recorded as the second hash value, representing the digital fingerprint of the currently stored record content.

[0059] The first hash value is compared with the second hash value. If they are exactly equal, the data verification is considered successful; otherwise, the verification is considered unsuccessful. All successfully verified records are collected to form a set of verified records. For records that fail verification, i.e., records deemed corrupt due to signature verification failure or hash comparison failure, the system marks them as "corrupted," records the reason for the failure and the corresponding unique record identifier, and writes the corrupt record information to the local corrupt list. These records are not included in this synchronization, and a local alarm is triggered on the terminal, prompting maintenance personnel that the inspection data is corrupted and requesting a re-inspection of the relevant equipment.

[0060] The system sends the verified record set to the central server via a secure transmission channel. A secure connection is established using the TLS 1.3 protocol, and the set is sent in blocks, each 4KB in size, with a sequence number embedded in each block to ensure the server can reassemble the data in sequence. After receiving all data blocks, the server performs an integrity check on the received data, verifying the continuity of the sequence numbers in each block and the integrity of the data after TLS decryption. Once the data is confirmed to be complete and error-free, an acknowledgment receipt is generated for this synchronization. This receipt includes a synchronization timestamp, such as the server's current time, and a unique identifier for this synchronization. The server returns the receipt to the inspection terminal. Upon receiving the receipt, the terminal confirms that the batch of data has been securely stored in the database.

[0061] In step S16, the step of marking the locally synchronized offline inspection record file according to the confirmation receipt and generating a record file with completed synchronization marking includes: Extract the synchronization timestamp and unique identifier from the confirmation receipt, and match the locally synchronized offline inspection record file based on the synchronization timestamp and unique identifier; For the offline inspection record files that fail to match, analyze the reasons for the failure, record the abnormal information, and rematch until successful or the preset maximum number of retries is reached; A synchronization flag is embedded in the metadata header of the successfully matched offline inspection record file to generate a record file with the synchronization flag complete.

[0062] It should be noted that after receiving the confirmation receipt from the central server in step S15, the system first parses the receipt data. The confirmation receipt is a data packet signed by the server using its private key. To ensure the authenticity and non-repudiation of the receipt, the system calls a pre-set server public key, which is stored in the terminal's secure area, to verify the signature. After successful verification, two key pieces of information are extracted: a synchronization timestamp, i.e., the server's current time, and a unique identifier, such as the UUID or synchronization record ID of this synchronization operation.

[0063] The system uses the extracted synchronization timestamp and unique identifier as matching criteria, traversing the encrypted offline inspection record file index generated in local step S13 (e.g., a B+ tree index) to find the record file corresponding to this synchronization. Matching rules can be pre-defined, such as the unique identifier returned by the server in the receipt corresponding to a preset batch number or record ID prefix in the local record file header; verifying whether the inspection timestamp is earlier than the synchronization timestamp, and that the difference between the two does not exceed a preset maximum reasonable offline duration, such as 48 hours. If the above conditions are met, the timestamp matching is considered successful. After successful matching, the corresponding offline inspection record file is located.

[0064] The crystal oscillator's accuracy is between ±20ppm and ±50ppm; ideally, the daily error is approximately 1.7 seconds, but when operating across the entire temperature range (-20°C to 70°C), the daily error can accumulate to several minutes. Excessive time drift can cause the timestamps of the terminal and the server to mismatch, resulting in synchronization failure. Therefore, to ensure a high synchronization success rate, synchronization must be completed before the crystal oscillator error accumulates to an unacceptable level; in this case, this is set at 48 hours.

[0065] If no corresponding offline inspection record file is found according to the above matching rules, the matching is considered a failure. The system analyzes the causes of such failures, which may include: the unique identifier in the confirmation receipt does not match the identifier of any local file (possibly due to receipt loss or corruption during network transmission); the synchronization timestamp deviates significantly from the inspection time of the local record, for example, the terminal's local clock and the server's clock have not been synchronized for a long time, causing drift; the local file has been deleted or corrupted, etc. The system records abnormal information, such as the failure time, failure record identifier, error code, etc., in the local log file.

[0066] In one implementation, for files that fail to match, the system does not immediately give up but triggers a retry mechanism. The failure record is placed in a retry queue, waiting for the next network synchronization cycle, such as after 5 minutes, to request an acknowledgment from the server or resend the data. Retry can be performed multiple times until success is achieved or the maximum number of retries is reached, such as 3 times.

[0067] For successfully matched offline inspection log files, the system writes a synchronization flag to their metadata header. The synchronization flag can be a specific flag or field, such as changing the "Synchronization Status" field in the file header from 0 (not synchronized) to 1 (synchronized), and simultaneously recording the synchronization timestamp and a unique identifier returned by the server for subsequent auditing. This flagging operation does not modify the encrypted data content, only the file metadata, and therefore does not affect the integrity of the stored inspection records.

[0068] After marking is complete, the system updates the local index database, such as updating the synchronization status field in the leaf nodes of the B+ tree, to ensure that synchronized and unsynchronized files can be quickly distinguished the next time the index is read. Finally, a record file is obtained showing that synchronization has been completed. These files remain in local storage as a backup of the synchronized data, and a lifecycle policy can be set, such as automatic deletion after 30 days.

[0069] In summary, this invention utilizes a local crystal oscillator to calculate a local time source, eliminating reliance on external time synchronization. It performs offline signing and encrypted storage while continuously monitoring network status, automatically synchronizing upon recovery. Compared to existing technologies that rely on stable network connections for real-time data uploads and identity verification, this method addresses the issue of operational limitations in signal-dead zones. In areas with no signal coverage, maintenance personnel cannot log into the inspection app or upload equipment status data in real time. This method achieves complete data collection, identity binding, and encrypted storage without a network connection, fundamentally solving the problem of inaccessible operations in signal-dead zones. Furthermore, this invention employs a request identifier-based receipt matching mechanism to completely eliminate interference from time synchronization discrepancies between the terminal and server in the synchronization confirmation process. It uses dual thresholds—RSSI and TCP connectivity success rate—to determine the true network recovery status, preventing synchronization failures caused by signal jitter.

[0070] The second embodiment of the present invention provides a fire protection maintenance data offline synchronization system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method described above.

[0071] It should be noted that the fire protection maintenance data offline synchronization system provided in this embodiment of the invention is used to execute all the process steps of the fire protection maintenance data offline synchronization method in the above embodiment. The working principle and beneficial effects of the two are one-to-one, so they will not be described again.

[0072] It should be noted that the system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0073] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A method for offline synchronization of fire protection maintenance data, characterized in that, include: Obtain signal blind zone inspection information, and generate inspection data objects based on the reliable time source of the internal hardware crystal oscillator and the signal blind zone inspection information; Extract the maintenance personnel's identification and embed it into the inspection data object, and generate an anti-tamper-proof signature value to be appended to the end to generate complete record data; The device status in the complete record data is parsed. If the device status is abnormal, the corresponding abnormal level is matched. If the device status is normal, the default level is used to generate hierarchical record data. The hierarchical record data is locally encrypted, written to a preset secure storage area, and an offline inspection record file containing index information is generated. Read the index information of the offline inspection record file, monitor the network signal status, extract the offline inspection record file when the network is restored, and maintain local storage when the network is not restored to obtain a set of records to be synchronized. Extract the tamper-proof signature value of each data in the set of records to be synchronized and perform integrity verification. Filter out the set of records that pass the verification, send it to the central server, and receive the confirmation receipt returned by the server. Based on the confirmation receipt, the offline inspection record file that has been synchronized locally is marked for synchronization, and a record file with completed synchronization marking is generated.

2. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The acquisition of signal blind zone inspection information, based on the reliable time source of the internal hardware crystal oscillator and the signal blind zone inspection information, generates inspection data objects, including: Obtain the current count value of the internal hardware crystal oscillator in the fire-fighting equipment currently under inspection; The signal blind zone inspection information is input into a pre-built equipment identification database for spatial comparison. When a corresponding fire-fighting equipment is matched, the unique code of the fire-fighting equipment to be inspected is extracted. The millisecond-level time offset of the device since the last network synchronization is calculated based on the current count value, and the local time source is deduced. The local time source is used to perform a time binding operation on the unique code to generate associated data containing the device identity and the time of occurrence; The associated data is encapsulated and a cyclic redundancy check code is added to obtain an inspection data object carrying precise time.

3. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The process involves extracting the maintenance personnel's identification and embedding it into the inspection data object, generating an tamper-proof signature value and appending it to the end to create complete record data, including: Obtain the current session token and the private key of the inspection terminal; Extract the feature hash value of the biometric template of the maintenance personnel, bind the feature hash value with the current session token to generate the maintenance personnel identity identifier; The maintenance personnel identification is embedded as an additional field into the inspection data object to form extended record data that integrates identity information. The extended record data is iteratively compressed to obtain a hash digest; By combining the private key of the inspection terminal with the hash digest for signature operation, an anti-tamper signature value is generated and appended to the end of the record to obtain complete record data.

4. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The process involves parsing the device status from the complete record data. If the device status is abnormal, a corresponding abnormality level is matched; if the device status is normal, a default level is used to generate hierarchical record data, including: The device status in the complete recorded data is analyzed, and the vibration amplitude of the device is detected based on the device status. If the vibration amplitude exceeds a preset amplitude threshold, the deviation between the vibration amplitude and the amplitude threshold is calculated. Calculate the absolute difference between the deviation value and the boundary of each level in the preset level mapping table, and determine the abnormal level based on the absolute difference; If the device is in normal condition, the default level is assigned directly, forming hierarchical record data.

5. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The step of locally encrypting the hierarchical record data, writing it to a preset secure storage area, and generating an offline inspection record file containing index information includes: Obtain the device's unique hardware fingerprint; A session key is generated based on the unique hardware fingerprint, and the hierarchical record data is encrypted in blocks based on the session key to obtain block record data. The block record data is written into a preset secure storage area, the address offset is calculated, and index information is generated. Calculate the file size of the hierarchical record data, and organize the file size, the index information, the address offset, and the block record data into a file to obtain the offline inspection record file.

6. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The process involves reading the index information of the offline inspection record file, monitoring the network signal status, retrieving the offline inspection record file when the network is restored, and maintaining local storage when the network is not restored, resulting in a set of records to be synchronized, including: Read the index information from the encrypted offline inspection record file, retrieve the leaf nodes based on the index information, and obtain the leaf node set; Monitor network signal status, calculate signal strength indicator value and packet loss rate. When the signal strength indicator value is greater than a preset strength threshold and the packet loss rate of five consecutive network probes is less than a preset percentage, it is determined that the network signal has been restored. If the network signal is not restored, the local storage state will continue, and the set of leaf nodes will be marked as pending synchronization. If the network signal is restored, the block record data in the leaf node set is loaded into memory according to the offset in the leaf node set to form a set of records to be synchronized.

7. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The process of extracting the tamper-proof signature value of each data entry in the set of records to be synchronized and performing integrity verification, filtering out the set of records that pass the verification, sending it to the central server, and receiving a confirmation acknowledgment from the server includes: Obtain the public key; Extract the tamper-proof signature value of each data item in the set of records to be synchronized, and verify the tamper-proof signature value using the public key to obtain the first hash value; The hash value of each data item in the set of records to be synchronized, excluding the tamper-proof signature value, is recalculated to obtain a second hash value. For each piece of data, compare the first hash value with the second hash value. If they are equal, the data is determined to have passed the verification. All data that have passed the verification are combined into a set of verified records. The verified record set is sent to the central server, and a confirmation receipt is received from the central server.

8. The offline synchronization method for fire protection maintenance data according to claim 1, characterized in that, The step of synchronizing the locally synchronized offline inspection record file according to the confirmation receipt and generating a record file with completed synchronization marking includes: Extract the synchronization timestamp and unique identifier from the confirmation receipt, and match the locally synchronized offline inspection record file based on the synchronization timestamp and unique identifier; For the offline inspection record files that fail to match, analyze the reasons for the failure, record the abnormal information, and rematch until successful or the preset maximum number of retries is reached; A synchronization flag is embedded in the metadata header of the successfully matched offline inspection record file to generate a record file with the synchronization flag complete.

9. A fire protection maintenance data offline synchronization system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method described in any one of claims 1 to 8.

Images