A multi-level security recording method and system for alarm information

Abstract

The application discloses a multi-level security recording method and system of alarm information, and relates to the technical field of intelligent security and protection, which generates structured alarm record data by uniformly packaging alarm event information, operation log information and defense area state change information, and constructs a chain type security storage structure to realize the correlation verification between alarm records, so that the data tamper resistance is improved. Meanwhile, a hierarchical storage mechanism combining a cache layer and a local persistent storage layer is established on the alarm host side to improve the data record stability in a high-frequency alarm scene. When the network is recovered, the data is uploaded to the cloud and redundantly backed up through batch synchronization and integrity verification to ensure long-term reliable storage of the data. In addition, in the case of power supply abnormality or system abnormality, an emergency writing mechanism is triggered to preferentially protect and write the non-persistent data. The method significantly improves the integrity, security and reliability of alarm information recording.

Description

Technical Field

[0001] This invention relates to the field of intelligent security technology, and more specifically, this application relates to a multi-level security recording method and system for alarm information. Background Technology

[0002] In related technologies, alarm information is usually saved by storing local logs or uploading them to cloud servers, which can achieve basic recording functions, but there are still shortcomings in terms of data security and system reliability.

[0003] Existing alarm logging methods mostly employ independent logs or sequential write mechanisms, lacking a correlation and verification structure between records. Once data is tampered with or partially lost, the system struggles to detect it promptly, compromising the integrity and reliability of alarm records. Furthermore, under high-frequency alarm conditions or high system loads, data often enters the cache before being written to storage; improper scheduling can easily lead to write delays or data loss. In addition, during network outages, alarm data cannot be uploaded in a timely manner, and the lack of effective batch synchronization and consistency verification mechanisms after recovery can result in data loss or duplication.

[0004] In the event of power outages or system failures, existing systems typically lack effective emergency protection mechanisms. This is especially true for cached data not yet written to persistent storage, which is highly susceptible to loss during sudden power outages, thus affecting the integrity of alarm records. Furthermore, existing cloud backup methods are mostly simple storage methods, lacking integrity verification and redundancy mechanisms, making it difficult to guarantee data reliability during transmission and storage. In addition, alarm record data is fragmented, lacking a unified structured organization and indexing mechanism, resulting in low efficiency for subsequent queries and tracing.

[0005] Therefore, how to construct an alarm information recording method that takes into account data integrity, tamper-proof capability, collaborative storage between local and cloud, and emergency protection against power outages has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] The summary section introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. This summary section is not intended to limit the key and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0007] Firstly, this application proposes a multi-level security recording method for alarm information, including:

[0008] The alarm host collects alarm event information in real time and encapsulates the alarm event information, operation log information and zone status change information in a unified manner to generate structured alarm record data. The structured alarm record data includes timestamp, device identifier and event type identifier.

[0009] A chain-like secure storage structure is built locally on the alarm host. The verification value of the current alarm record data is associated with the verification value of the previous alarm record data to generate the integrity verification value of the current alarm record, and then written to the local anti-tampering storage area in chronological order.

[0010] A hierarchical storage mechanism is established in the aforementioned alarm host, and the aforementioned structured alarm record data is written to the device cache layer and the local persistent storage layer respectively;

[0011] When the network connection is detected to be restored, the structured alarm record data and the corresponding integrity verification value stored in the local anti-tamper storage area are synchronized to the cloud server, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data.

[0012] When a power supply or system anomaly is detected, an emergency write mechanism is triggered to write the non-persistent alarm record data in the cache to a non-volatile storage medium.

[0013] In one feasible implementation, the alarm host collects alarm event information in real time, and encapsulates the alarm event information, operation log information, and zone status change information in a unified manner to generate structured alarm record data, including:

[0014] The alarm host receives alarm trigger signals from the alarm devices and performs event parsing on the alarm trigger signals to extract event type parameters, trigger zone identifiers, and event trigger time information from the alarm event information.

[0015] The alarm event information is associated and matched with the operation log information generated inside the alarm host and the real-time acquired zone status change information to form an event association dataset describing the same alarm process.

[0016] The above-mentioned event-related datasets are subjected to field standardization and format unification processing to generate the original alarm record data structure, which includes timestamp field, device identifier field, zone identifier field, event type field, and status change field.

[0017] Based on preset data encapsulation rules, the original alarm record data structure is serialized and encapsulated. During the encapsulation process, an event sequence number identifier and a record version identifier are added to the original alarm record data structure to generate the structured alarm record data.

[0018] In one feasible implementation, a chain-like secure storage structure is constructed locally on the alarm host. This structure associates the current alarm record data with the verification value of the previous alarm record to generate an integrity verification value for the current alarm record, which is then written to the local tamper-proof storage area in chronological order. This includes:

[0019] After receiving the above structured alarm record data, the alarm host assigns a sequentially increasing record number to the above structured alarm record data and obtains the verification value corresponding to the previous alarm record as a chain association parameter.

[0020] The current structured alarm record data, the record number, the timestamp, and the verification value corresponding to the previous alarm record are combined to construct a data calculation unit to be verified.

[0021] Hash operations are performed on the above data calculation units to generate the integrity verification value corresponding to the current structured alarm record data, so that a continuous verification association relationship is formed between the current alarm record and the previous alarm record, thereby constructing the above chain-like secure storage structure.

[0022] The structured alarm record data and the integrity verification value are bound and encapsulated to generate a chained alarm record data block, and the chained alarm record data block is written to the local anti-tamper storage area of ​​the alarm host in chronological order.

[0023] In one feasible implementation, the aforementioned hierarchical storage mechanism established on the alarm host side, which writes the structured alarm record data into the device cache layer and the local persistent storage layer respectively, includes:

[0024] The structured alarm record data bound by the integrity check value is received, and the structured alarm record data is first written into the device cache layer of the alarm host to form an alarm record cache queue arranged in chronological order.

[0025] After the structured alarm record data is written to the device cache layer, the cache status of the alarm record cache queue is monitored, and the alarm record cache queue is dynamically scheduled according to the preset cache capacity threshold, alarm event trigger frequency and system operating status to determine the target structured alarm record data that needs to be persistently written.

[0026] The aforementioned target structured alarm record data is persistently written to the local persistent storage layer of the alarm host, and the corresponding storage address identifier and time index information are generated during the writing process to establish a persistent index structure for the structured alarm record data.

[0027] After completing the writing to the local persistent storage layer, a cache status update operation is performed on the target structured alarm record data in the device cache layer to release the data cache space that has been persistently written and retain the data that has not been written.

[0028] In one feasible implementation, after the structured alarm record data is written to the device cache layer, the cache status of the alarm record cache queue is monitored, and the alarm record cache queue is dynamically scheduled according to a preset cache capacity threshold, alarm event triggering frequency, and system operating status to determine the target structured alarm record data that needs to be persistently written, including:

[0029] After the structured alarm record data is written into the device cache layer and forms the alarm record cache queue, the cache capacity occupancy status of the alarm record cache queue is monitored in real time to obtain the current cache occupancy ratio information.

[0030] After obtaining the above cache occupancy ratio information, the alarm event triggering frequency within the preset time window is statistically analyzed, and a cache scheduling evaluation parameter set is constructed by combining the above alarm host system operation status information.

[0031] Based on the above set of cache scheduling evaluation parameters, priority evaluation processing is performed on the above structured alarm record data in the above alarm record cache queue to generate cache scheduling priority values ​​corresponding to each of the above structured alarm record data.

[0032] Based on the aforementioned cache scheduling priority values, the aforementioned alarm record cache queue is sorted, and the aforementioned structured alarm record data with a priority higher than a preset threshold is selected from the aforementioned alarm record cache queue and determined as the aforementioned target structured alarm record data.

[0033] The determined target structured alarm record data is written to the local persistent storage layer.

[0034] In one feasible implementation, the above-mentioned persistent writing process for the target structured alarm record data involves writing the target structured alarm record data and its corresponding integrity check value into the local persistent storage layer of the alarm host, and generating corresponding storage address identifiers and time index information during the writing process to establish a persistent index structure for the structured alarm record data, including:

[0035] After receiving the aforementioned target structured alarm record data, the system performs write preparation processing on the aforementioned target structured alarm record data and its corresponding integrity verification value, and generates a unique data write identifier for each of the aforementioned target structured alarm record data.

[0036] Based on the above data writing identifier, the above target structured alarm record data and the above integrity verification value are written to the local persistent storage layer of the above alarm host in chronological order, and the corresponding data storage address information is recorded during the writing process.

[0037] After completing the writing of the target structured alarm record data, the corresponding time index information is generated according to the data storage address information, and the time index information is associated with the data writing identifier to form an index mapping relationship of the structured alarm record data.

[0038] Write the above index mapping relationship into the preset alarm record index table, and establish the persistent index structure of the above structured alarm record data based on the above alarm record index table.

[0039] The aforementioned persistent index structure enables rapid location and access to the target structured alarm record data, thereby completing the process of writing the structured alarm record data into the local persistent storage layer and establishing a persistent index structure.

[0040] In one feasible implementation, upon detecting network connection restoration, the structured alarm record data and corresponding integrity verification values ​​stored in the local tamper-proof storage area are synchronized to the cloud server, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data, including:

[0041] After detecting that the network connection status of the alarm host has been restored from the disconnected state to the communicable state, the alarm host first scans the structured alarm record data in the local anti-tamper storage area and determines the target structured alarm record data set that has not yet been synchronized with the cloud.

[0042] The structured alarm record data and the corresponding integrity verification value in the above target structured alarm record data set are batch packaged, and the corresponding synchronization batch identifier and data summary information are generated during the packaging process to form a data synchronization package to be synchronized.

[0043] Through the secure communication channel established between the alarm host and the cloud server, the data synchronization packet is sent to the cloud server, and the cloud server receives the structured alarm record data and the integrity verification value in the data synchronization packet.

[0044] After receiving the data synchronization packet, the cloud server performs integrity verification on the structured alarm record data. By recalculating the verification value of the structured alarm record data and comparing it with the integrity verification value, the integrity and consistency of the structured alarm record data during transmission are confirmed.

[0045] After the above integrity verification is passed, the structured alarm record data is written to multiple cloud storage nodes according to the preset distributed redundancy strategy, and the corresponding data backup identifier and synchronization confirmation information are generated and returned to the alarm host to complete the synchronization of structured alarm record data to the cloud server and perform integrity verification and redundant backup storage.

[0046] In one feasible implementation, the above-mentioned emergency write mechanism, triggered upon detecting a power supply anomaly or system anomaly, writes the non-persistent alarm record data in the cache to a non-volatile storage medium, including:

[0047] During the operation of the alarm host, the power supply status and system operation status of the alarm host are monitored in real time. When the power supply voltage is detected to be lower than the preset safety threshold or the system operation status is abnormal, an abnormal trigger signal is generated and the emergency writing mechanism is activated.

[0048] After the above emergency write mechanism is activated, the structured alarm record data in the above device cache layer is scanned and identified, and the target structured alarm record data set that has not yet been written to the above local persistent storage layer is determined.

[0049] The structured alarm record data and its corresponding integrity verification value in the above target structured alarm record data set are prioritized and sorted, and an emergency write data sequence is generated in chronological order.

[0050] The structured alarm record data and its corresponding integrity verification value in the above emergency write data sequence are written into a non-volatile storage medium, and corresponding emergency storage identifiers and time index information are generated for each of the above structured alarm record data during the writing process to form a power failure protection record unit.

[0051] After the above-mentioned non-volatile storage medium is written, the status of the above-mentioned emergency storage identifier is updated, and the above-mentioned power failure protection recording unit is marked as alarm record data that has been written for protection, so as to realize the safe transfer of non-persistent alarm record data in the above-mentioned device cache layer to the above-mentioned non-volatile storage medium.

[0052] In one feasible implementation, the above-mentioned prioritization of each structured alarm record data and its corresponding integrity check value in the target structured alarm record data set, and the generation of an emergency write data sequence according to time order, includes:

[0053] After determining the above-mentioned target structured alarm record data set, extract the event type information, trigger zone identifier, timestamp information, and integrity verification value corresponding to each of the above-mentioned structured alarm record data in the above-mentioned target structured alarm record data set to form an emergency dispatch parameter set;

[0054] Based on the above set of emergency dispatch parameters, the corresponding emergency write priority value is calculated for each of the above structured alarm record data. The above emergency write priority value is determined by the severity of the alarm event, the time of the event, and the risk level of the defense zone.

[0055] The above-mentioned target structured alarm record data set is sorted according to the above-mentioned emergency write priority values ​​to generate a priority sorting list, and data with the same priority are arranged in chronological order during the sorting process.

[0056] Based on the priority sorting list above, the sorted structured alarm record data and their corresponding integrity verification values ​​are combined sequentially to generate an emergency write data sequence arranged in chronological order.

[0057] The generated emergency write data sequence will be used to write the structured alarm record data to a non-volatile storage medium for emergency write processing in the event of a power outage.

[0058] Secondly, this application proposes a multi-level security recording system for alarm information, used to execute the multi-level security recording method for alarm information described in the first aspect, including:

[0059] The generation unit is used to collect alarm event information generated by the alarm in real time through the alarm host, and to encapsulate the alarm event information, operation log information and zone status change information in a unified manner to generate structured alarm record data. The structured alarm record data includes timestamp, device identifier and event type identifier.

[0060] The first writing unit is used to build a chain-like secure storage structure on the local side of the alarm host, associate the current alarm record data with the verification value of the previous alarm record data to generate the integrity verification value of the current alarm record, and write it to the local anti-tampering storage area in chronological order.

[0061] The second writing unit is used to establish a hierarchical storage mechanism in the alarm host and write the structured alarm record data into the device cache layer and the local persistent storage layer respectively.

[0062] The synchronization unit is used to synchronize the structured alarm record data and the corresponding integrity verification value stored in the local anti-tamper storage area to the cloud server when the network connection is detected to be restored, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data.

[0063] The third write unit is used to trigger an emergency write mechanism when a power supply abnormality or system abnormality is detected, and to write the non-persistent alarm record data in the cache to a non-volatile storage medium.

[0064] In summary, this invention unifies the encapsulation of alarm event information, operation log information, and zone status change information to form structured alarm record data. This makes alarm information more complete and has a unified data format, which is beneficial for subsequent processing and analysis. Simultaneously, by constructing a chain-like secure storage structure, a sequential verification relationship is established between each alarm record. Once data is tampered with, it can be quickly identified, thus significantly improving the tamper resistance and data reliability of alarm records. This invention establishes a hierarchical storage mechanism combining a device caching layer and a local persistent storage layer, enabling alarm data to achieve stable access and orderly writing under high-frequency triggering or system load fluctuations, effectively reducing the risk of data loss. Furthermore, the establishment of time indexes and address identifiers during local storage improves the query efficiency and traceability of alarm data. This invention introduces a batch synchronization and integrity verification mechanism during network recovery, combined with a cloud-based distributed redundant backup strategy, to ensure the reliability and long-term security of alarm data during transmission and storage. In the event of power failure or system anomalies, an emergency write mechanism prioritizes the protection of critical alarm record data, preventing the loss of cached data during power outages.

[0065] The multi-level security recording method for alarm information proposed in this application, along with other advantages, objectives, and features of this application, will be partly apparent from the following description and partly understood by those skilled in the art through study and practice of this application. Attached Figure Description

[0066] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0067] Figure 1 This is a flowchart illustrating a multi-level security recording method for alarm information provided in an embodiment of this application.

[0068] Figure 2 This is a flowchart illustrating a method for generating structured alarm recording data, as provided in an embodiment of this application.

[0069] Figure 3 This is a flowchart illustrating a method for generating an integrity check value for the current alarm record, as provided in an embodiment of this application.

[0070] Figure 4 This application provides a flowchart illustrating a method for writing to a device cache layer and a local persistent storage layer, as shown in the embodiments of this application.

[0071] Figure 5 This is a flowchart illustrating a method for determining target structured alarm record data that needs to be persistently written, as provided in an embodiment of this application.

[0072] Figure 6 This application provides a flowchart illustrating a method for establishing a persistent index structure for structured alarm record data, as illustrated in an embodiment of the present application.

[0073] Figure 7 This is a flowchart illustrating a method for synchronizing data to a cloud server, as provided in an embodiment of this application.

[0074] Figure 8 A flowchart illustrating a method for writing non-persistent alarm record data from a cache to a non-volatile storage medium, as provided in this application embodiment;

[0075] Figure 9 This application provides a flowchart illustrating a method for generating an emergency write data sequence in chronological order, as shown in the embodiments of the present application.

[0076] Figure 10 This is a structural diagram of a multi-level security recording system for alarm information provided in an embodiment of this application. Detailed Implementation

[0077] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus. The technical solutions of the embodiments of this application will now be clearly and completely described in conjunction with the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them.

[0078] Please see Figure 1 This is a flowchart illustrating a multi-level security recording method for alarm information provided in an embodiment of this application, which may specifically include:

[0079] S110. The alarm host collects alarm event information generated by the alarm in real time, and encapsulates the alarm event information, operation log information and zone status change information in a unified manner to generate structured alarm record data, wherein the structured alarm record data includes timestamp, device identifier and event type identifier.

[0080] S120. Construct a chain-like secure storage structure locally on the alarm host, associate the current alarm record data with the verification value of the previous alarm record data to generate the integrity verification value of the current alarm record, and write it into the local anti-tampering storage area in chronological order.

[0081] S130. Establish a hierarchical storage mechanism on the alarm host and write the structured alarm record data to the device cache layer and the local persistent storage layer respectively.

[0082] S140. When the network connection is detected to be restored, the structured alarm record data and the corresponding integrity verification value stored in the local anti-tampering storage area are synchronized to the cloud server, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data.

[0083] S150. When a power supply abnormality or system abnormality is detected, an emergency write mechanism is triggered to write the non-persistent alarm record data in the cache to a non-volatile storage medium.

[0084] For example, in this embodiment, in step S110, the alarm host first collects alarm event information generated by the alarm device in real time. Specifically, the alarm host receives the alarm trigger signal from the alarm device and simultaneously acquires operation log information and zone status change information related to the alarm event. The alarm event information, operation log information, and zone status change information are then uniformly encapsulated to generate structured alarm record data. This structured alarm record data includes key fields such as timestamp, device identifier, and event type identifier to provide a unified description of the alarm event's occurrence time, source device, and event type, thus providing a standardized data foundation for subsequent secure data storage and traceability.

[0085] After generating the structured alarm record data, in step S120, a chain-like secure storage structure is constructed locally on the alarm host. Specifically, the currently generated alarm record data is correlated with the checksum corresponding to the previous alarm record data to generate an integrity checksum corresponding to the current alarm record, thus forming a continuous checksum correlation between alarm records. In this way, when any historical alarm record data is tampered with, the checksum correlation of subsequent alarm records will change, thereby enabling timely detection of data anomalies. Subsequently, the current alarm record data and its corresponding integrity checksum are written to the local tamper-proof storage area in chronological order to achieve secure storage of the alarm record data.

[0086] In step S130, a hierarchical storage mechanism is established on the alarm host side to further improve the recording stability of alarm record data in high-frequency alarm scenarios or system anomalies. Specifically, the structured alarm record data is first written to the device cache layer to form an alarm record cache queue arranged in chronological order, and the alarm record data is temporarily stored and scheduled in the cache layer. At the same time, according to the cache capacity status and system operation status, some alarm record data is synchronously written to the local persistent storage layer to achieve long-term preservation of alarm record data, thereby forming a hierarchical storage structure in which the device cache layer and the local persistent storage layer work together.

[0087] In step S140, when the alarm host detects that the network connection has been restored from a disconnected state to a normal communication state, it batch synchronizes the structured alarm record data and its corresponding integrity check value stored in the local tamper-proof storage area, and sends it to the cloud server through a secure communication channel. Upon receiving the structured alarm record data, the cloud server recalculates the check value and compares it with the synchronized integrity check value to perform integrity verification on the alarm record data. If the verification passes, the cloud server stores the structured alarm record data on multiple storage nodes according to a preset redundancy strategy to achieve redundant backup and long-term secure storage of the alarm record data.

[0088] In step S150, when the alarm host detects a power supply abnormality or system malfunction, it triggers an emergency write mechanism. At this time, the system identifies non-persistent alarm record data in the device cache layer and preferentially writes this portion of alarm record data to non-volatile storage media, thus ensuring the complete preservation of alarm record data even in the event of a power outage or system malfunction. This emergency write mechanism avoids the problem of alarm record data loss due to sudden power outages.

[0089] In summary, this invention first unifies the encapsulation of alarm event information, operation log information, and zone status change information to generate structured alarm record data. This transforms alarm information from a scattered, singular log format into a multi-dimensional, integrated data structure, significantly improving the integrity of alarm record content and the standardization of data processing. Building upon this, a chain-like secure storage structure is constructed, linking the integrity verification value of the current alarm record with that of the previous record. This creates a continuous verification chain, allowing for rapid identification of data tampering or loss, effectively enhancing the tamper-proof capability and reliability of alarm data. Furthermore, this invention establishes a hierarchical storage mechanism on the alarm host side, combining a device cache layer and a local persistent storage layer. This allows alarm data to be efficiently accessed in the cache layer first, and then dynamically scheduled and written to persistent storage based on cache status, alarm frequency, and system operating conditions. This ensures the continuity and stability of data records even under high-frequency alarms or fluctuating system load scenarios, significantly reducing the risk of data loss. Simultaneously, the establishment of storage address identifiers and time index structures during persistence improves the query efficiency and traceability of alarm data. This invention introduces a batch-encapsulated data synchronization mechanism during network recovery and ensures the consistency and reliability of alarm data during transmission and cloud storage by combining integrity verification with distributed redundant backup in the cloud, avoiding data duplication, loss, or corruption. Furthermore, in the event of power outages or system failures, an emergency write mechanism identifies and prioritizes non-persistent data, prioritizing the writing of critical alarm records to non-volatile storage media, thus maximizing the retention of important data even under extreme conditions such as power outages. In summary, this invention achieves end-to-end security for alarm information throughout its generation, storage, transmission, and abnormal scenarios through the coordinated efforts of structured processing, chain-based tamper-proofing, hierarchical storage, trusted cloud synchronization, and emergency protection, significantly improving the integrity, security, continuity, and reliability of alarm data.

[0090] In one feasible implementation, such as Figure 2As shown, step S110 above involves real-time collection of alarm event information generated by the alarm through the alarm host, and unified encapsulation of the alarm event information, operation log information, and zone status change information to generate structured alarm record data, including:

[0091] S1101. Receive alarm trigger signals from alarm devices through the alarm host and perform event analysis on the alarm trigger signals to extract event type parameters, trigger zone identifiers and event trigger time information from the alarm event information.

[0092] S1102. The alarm event information is associated and matched with the operation log information generated inside the alarm host and the real-time acquired zone status change information to form an event association dataset describing the same alarm process.

[0093] S1103. Perform field standardization and format unification processing on the above event-related dataset to generate the original alarm record data structure, which includes timestamp field, device identifier field, zone identifier field, event type field, and status change field.

[0094] S1104. Based on the preset data encapsulation rules, the original alarm record data structure is serialized and encapsulated, and during the encapsulation process, an event sequence number identifier and a record version identifier are added to the original alarm record data structure to generate the structured alarm record data.

[0095] For example, in step S1101, the alarm host first receives an alarm trigger signal from an alarm device. The alarm trigger signal can originate from a door sensor, infrared sensor, smoke detector, vibration detector, emergency button, or other security sensing device. When the alarm host receives the alarm trigger signal, it does not directly write the signal to the log. Instead, it performs event parsing processing on the alarm trigger signal to extract the event type parameter, trigger zone identifier, and event trigger time information from the alarm event information. In this embodiment, an alarm event parsing vector can be constructed:

[0096]

[0097] in, Indicates the first The basic event parsing vector corresponding to the next alarm trigger; This parameter represents the event type, used to characterize different event categories such as intrusion, smoke, dismantling, emergency assistance, or equipment failure. This indicates the trigger zone identifier, used to specify the exact zone where the event occurred; Indicates the event trigger time information; This represents the identifier of the source device triggering the alarm signal. By constructing the basic event parsing vector, the original trigger signal can be transformed into a standardized input unit that can be processed subsequently. To enhance creativity, an event reliability calculation model can be introduced during the parsing process to quantitatively evaluate the reliability of the alarm trigger signal itself.

[0098]

[0099] in, Indicates the first The credibility of triggering an alarm event; This indicates the current alarm signal strength or signal stability parameter; This indicates the historical health status or failure rate of the corresponding alarm device; This indicates the time interval between the current event and the previous event on the device. and These represent the normalized mapping functions for signal quality, device health status, and trigger rhythm characteristics, respectively. This represents the weighting coefficients of different influencing factors, and Through the aforementioned credibility calculation, the subsequently generated structured alarm log data can not only describe the content of the event, but also the credibility of the event, thereby enhancing the interpretability of the log data and its subsequent audit value.

[0100] After completing the basic event analysis, proceed to step S1102. In this step, the alarm event information is correlated and matched with the operation log information generated internally by the alarm host and the real-time acquired zone status change information to form an event association dataset describing the same alarm process. The key to this step is not simply concatenating data, but identifying the contextual boundaries of the same alarm process. Because an alarm trigger is often not an isolated event, it may be accompanied by operations such as arming, disarming, permission switching, manual confirmation, detector testing, or zone bypassing. Therefore, aggregation is required from three levels: temporal proximity, device correlation, and logical consistency. An event association scoring function can be constructed for this purpose:

[0101]

[0102] in, Indicates an alarm event With candidate logs or zone status records Correlation ratings between them; Indicates the time difference between the two; This represents the time decay coefficient, used to control the degree of influence of time proximity on the correlation results; This represents the zone consistency function, which takes the value 1 when two records correspond to the same zone, and otherwise takes the value 1. This represents a logical consistency function used to determine whether the operation behavior, state change and alarm event meet preset rules, such as the confidence level of an intrusion alarm triggered after disarming decreases or the confidence level of an intrusion zone triggered after arming increases. This represents the weighting coefficient for the corresponding influencing item. Based on this association scoring function, the information items most relevant to the current alarm event can be selected from multiple candidate logs and status records, forming an event association dataset:

[0103]

[0104] in, Indicates the first The event association dataset corresponding to each alarm event; Indicates the number associated with this alarm event Operation log information; Indicates the number associated with this alarm event Information on changes in the status of each protection zone. Through this method, the system can expand a single alarm trigger into a complete description of the alarm process with operational context, thereby providing higher information density for subsequent reliable recording.

[0105] Subsequently, in step S1103, the event-related dataset undergoes field standardization and format unification processing to generate an original alarm record data structure including a timestamp field, device identifier field, zone identifier field, event type field, and status change field. Essentially, this step transforms data from different sources, with different formats, and different units into data objects with a unified model. Considering that different alarm devices, different manufacturer protocols, and different subsystems may have inconsistent output formats, this embodiment can define a standardized mapping function:

[0106]

[0107] in, Indicates the first The original alarm record data structure corresponding to each alarm event; Represents the normalized mapping function; This represents the unified timestamp field; This indicates the device identification field; This indicates the zone identifier field; This indicates the event type field; The status change field is used to describe the status of the zone, arming / disarming status, or device status changes before and after an alarm. This represents the operation context field, which describes a summary of the operation behavior related to this alarm process; This represents the event credibility field obtained from the aforementioned calculation. To further improve the stability and verifiability of the data structure, constraints can be applied to the information entropy of the standardized fields to construct a field completeness index:

[0108]

[0109] in, Indicates the first Field completeness of the original alarm record data structure; Indicates the total number of predefined fields; Indicates the first The value used to determine whether a field exists is 1 if it exists and is valid, otherwise it is 0. Indicates the first The importance weight of each field. Only when... The system only sends the original alarm record data structure to the subsequent encapsulation stage when the data exceeds a preset threshold; if the data falls below the threshold, a supplementary acquisition or missing data marking mechanism is triggered. This prevents low-quality records from directly entering the secure storage process, thus improving the overall record quality.

[0110] Finally, in step S1104, based on preset data encapsulation rules, the original alarm record data structure is serialized and encapsulated. During the encapsulation process, an event sequence number identifier and a record version identifier are added to the original alarm record data structure to generate the structured alarm record data. This step not only achieves data format conversion but also further establishes traceable, iterable, and version-manageable record units for subsequent chained secure storage. The final structured alarm record data can be represented as:

[0111]

[0112] in, Indicates the first Structured alarm log data; This represents the event sequence number, used to indicate the current record's sequential position in the global record stream; This represents a record version identifier, used to mark the data structure template, field definition, or protocol version; This represents the original alarm record data structure generated in step S1103; This represents encapsulated metadata, used to record additional information such as serialization method, compression method, encoding method, or source marker. To make the encapsulated data more suitable for subsequent secure recording, this embodiment can also construct an encapsulation stability evaluation function:

[0113]

[0114] in, Indicates the first Priority quality score for encapsulation of structured alarm log data; Indicates the completeness of the field; Indicates the credibility of an event; This represents a version compatibility indicator, used to characterize the degree of matching between the current record format and the system's current processing template; This represents the weighting coefficient of each indicator. These scores determine whether to add enhanced redundancy fields, enhanced summary fields, or fast index fields to certain records, thereby providing a higher level of protection for high-risk, high-value alarm data during subsequent chained storage and cloud synchronization.

[0115] In one feasible implementation, such as Figure 3 As shown, step S120 above constructs a chain-like secure storage structure locally on the alarm host, associates the current alarm record data with the verification value of the previous alarm record to generate an integrity verification value for the current alarm record, and writes it to the local tamper-proof storage area in chronological order, including:

[0116] S1201. After receiving the above-mentioned structured alarm record data, assign sequentially increasing record numbers to the above-mentioned structured alarm record data in the above-mentioned alarm host, and obtain the verification value corresponding to the previous alarm record as a chain association parameter.

[0117] S1202. Combine the current structured alarm record data, the record number, the timestamp, and the verification value corresponding to the previous alarm record to construct a data calculation unit to be verified.

[0118] S1203. Perform hash operation on the above data calculation unit to generate the integrity verification value corresponding to the current structured alarm record data, so that the current alarm record and the previous alarm record form a continuous verification association relationship, thereby constructing the above chain-like secure storage structure.

[0119] S1204. Bind and encapsulate the current structured alarm record data with the integrity verification value to generate a chained alarm record data block, and write the chained alarm record data block into the local anti-tamper storage area of ​​the alarm host in chronological order.

[0120] For example, in step S1201, after receiving the structured alarm record data, an incrementally increasing record number is assigned to the structured alarm record data in the alarm host, and the verification value corresponding to the previous alarm record is obtained as a chain association parameter. The technical significance of this step lies in establishing a clear temporal position and forward dependency relationship for the current alarm record. Specifically, the first... Structured alarm log data is represented as And assign it a corresponding record number. Simultaneously, read the integrity check value corresponding to the previous alarm record. This serves as the chained association parameter for the current record. Therefore, the chained input primitive for the current record can be defined as:

[0121]

[0122] in, Indicates the first An alarm record is entered into a chain of input primitives before entering the chained secure storage process; This indicates the current structured alarm record data; Indicates a sequentially increasing record number; This represents the integrity check value corresponding to the previous alarm record. When... When this happens, an initial check value can be preset. As initial verification parameters, this step introduces the record sequence number and the verification value corresponding to the previous alarm record, compared to the existing recording method that only uses timestamps for sorting. This ensures that the current alarm record not only belongs to a certain moment but also depends on the existence state of the previous record, thus providing a foundation for building a continuous verification chain.

[0123] To further enhance creativity, a chain head stabilization factor can be introduced in this step to avoid ambiguity in the chain structure during system restarts, batch switching, or cache recovery. Correspondingly, a chain context identification function can be constructed:

[0124]

[0125] in, Indicates the first The chain context identifier of the alarm record; This indicates the storage batch number to which the current record belongs; This indicates the current running cycle number of the alarm control panel, such as the system power-on cycle or recovery cycle. This represents the context generation function. By incorporating the chain context identifier into subsequent verification calculations, conflicts arising from the same record number in different recovery cycles can be avoided, improving the stability of the chain structure in complex operating environments.

[0126] Subsequently, in step S1202, the current structured alarm record data, the record number, the timestamp, and the verification value corresponding to the previous alarm record are combined to construct a data calculation unit to be verified. This step is not a simple concatenation of fields, but rather the fusion of key information representing the current record content, the current record's temporal position, the time of occurrence of the current record, and the status of the previous record into an indivisible verification input unit. The data calculation unit to be verified can be defined as:

[0127]

[0128] in, Indicates the first The data calculation unit corresponding to each alarm record; This indicates a field combination function or a normalized concatenation function. This indicates the timestamp contained in the current structured alarm log data; This indicates the aforementioned chain context identifier. Preferably, the field combination function... A combination of fixed-length field mapping, sequential encoding, and boundary marking is used to prevent ambiguity at the byte level caused by different field combinations. Thus, even if two alarm records are similar, as long as their record sequence number, timestamp, or preceding checksum differs, the generated data calculation unit to be verified will necessarily be different.

[0129] To enhance anti-forgery capabilities, local perturbation digests can be introduced when constructing the data computation unit to be verified, forming an enhanced data computation unit:

[0130]

[0131] in, This represents an enhanced data verification calculation unit; This represents a summary of local perturbations. This represents a subset of key fields in the current structured alarm log data; Indicates the currently triggered defense zone identifier; This indicates the current alarm device identifier. By attaching the local perturbation summary, even if an attacker attempts to forge a new record by copying historical data, it will be difficult to generate a consistent input unit without knowing the full context, thereby improving the replay resistance of the chained secure storage structure.

[0132] Next, in step S1203, a hash operation is performed on the data calculation unit to generate an integrity verification value corresponding to the current structured alarm record data. This establishes a continuous verification association between the current alarm record and the previous alarm record, thereby constructing the chained secure storage structure. This step is a crucial part of the entire chained secure storage scheme. The integrity verification value corresponding to the current alarm record can be defined as:

[0133]

[0134] in, Indicates the first The integrity check value corresponding to each alarm record; This indicates the preset hash function, which can be a one-way hash function. Because... It contains the current structured alarm record data, record number, timestamp, checksum corresponding to the previous alarm record, and chain context identifier. Therefore, the integrity checksum... It carries both the content characteristics of this record and the status characteristics of the preceding records. Therefore, once the historical records... If it is tampered with, then Changes occurred, further leading to This process continues until all subsequent checksums fail, allowing for rapid identification of tampering.

[0135] To enhance the inventiveness of this solution, this embodiment can also introduce a chain-coupled enhancement model based on the basic hash chain to measure the group stability of locally continuous records. For example, a local chain stability factor can be defined:

[0136]

[0137] in, Indicates the first The local chain stability factor between a new alarm record and the previous alarm record; This indicates the semantic or field similarity between two adjacent structured alarm record data. Indicates the time interval between two adjacent records; Indicates the time decay coefficient; This indicates the consistency index between two adjacent records in terms of device origin or defense zone origin; This represents the weight of each influencing factor. Then, the local chain stability factor can be mapped to an additional verification enhancement term:

[0138]

[0139] in, This represents the enhanced integrity check value. In other words, the system not only performs hash calculations on the static content of individual records, but also incorporates the contextual adjacency relationships between records into the check value generation process. This gives the chained secure storage structure the dual technical effects of preventing content tampering and contextual breakage. Thus, the system's detection capabilities are further enhanced when facing complex attacks such as inserting forged records, deleting intermediate records, or rearranging record order.

[0140] Finally, in step S1204, the current structured alarm record data and the integrity verification value are bound and encapsulated to generate a chained alarm record data block. This chained alarm record data block is then written to the local tamper-proof storage area of ​​the alarm host in chronological order. Essentially, this step fixes the original record content and the chained verification result into a unified data block, serving as the smallest trusted unit for subsequent local storage, synchronous uploading, and consistency verification. The chained alarm record data block can be defined as:

[0141]

[0142] in, Indicates the first Each chain alarm record data block; Indicates the record number; Represents a timestamp; This represents structured alarm log data; This indicates the checksum corresponding to the previous alarm record; This represents the current enhanced integrity verification value. Through this binding and encapsulation method, the system can directly complete the associated verification based on the chained alarm record data block without additionally querying external dependent data when performing local or cloud-synchronized verification, thereby improving verification efficiency and independence.

[0143] Furthermore, to improve the write reliability of the local tamper-proof storage area, this embodiment can also generate block-level write confidence parameters before writing:

[0144]

[0145] in, Indicates the first Write confidence level of each chain alarm record data block; This indicates the completeness of the fields in this record; This indicates the credibility of the event being triggered; Indicates the local chain stability factor; This represents the weighting coefficients for each item. When... When the value exceeds the preset threshold, the standard write mode can be used; when... If the alarm record is below the threshold but still needs to be retained, an anomaly marker or redundant summary field can be attached before writing it to the local tamper-proof storage area. This makes high-value, high-risk, or highly anomalous alarm records more easily distinguishable in local storage, facilitating subsequent auditing and tracing.

[0146] In one feasible implementation, such as Figure 4 As shown, step S130 establishes a hierarchical storage mechanism on the alarm host side, writing the structured alarm record data into the device cache layer and the local persistent storage layer respectively, including:

[0147] S1301. Receive the structured alarm record data bound by the integrity check value, and first write the structured alarm record data into the device cache layer of the alarm host to form an alarm record cache queue arranged in chronological order.

[0148] S1302. After the structured alarm record data is written to the device cache layer, the cache status of the alarm record cache queue is monitored, and the alarm record cache queue is dynamically scheduled according to the preset cache capacity threshold, alarm event trigger frequency and system operating status to determine the target structured alarm record data that needs to be persistently written.

[0149] S1303. Perform persistent writing processing on the above-mentioned target structured alarm record data, write the above-mentioned target structured alarm record data and its corresponding integrity verification value into the local persistent storage layer of the above-mentioned alarm host, and generate the corresponding storage address identifier and time index information during the writing process to establish a persistent index structure for the structured alarm record data.

[0150] S1304. After completing the writing to the local persistent storage layer, perform a cache status update operation on the target structured alarm record data in the device cache layer to release the data cache space that has been persistently written and retain the data that has not been written.

[0151] In one feasible implementation, such as Figure 5 As shown, in step S1302, after the structured alarm record data is written to the device cache layer, the cache status of the alarm record cache queue is monitored, and the alarm record cache queue is dynamically scheduled according to a preset cache capacity threshold, alarm event triggering frequency, and system operating status to determine the target structured alarm record data that needs to be persistently written, including:

[0152] S13021. After the structured alarm record data is written into the device cache layer and the alarm record cache queue is formed, the cache capacity occupancy status of the alarm record cache queue is monitored in real time to obtain the current cache occupancy ratio information.

[0153] S13022. After obtaining the above cache occupancy ratio information, the alarm event triggering frequency within the preset time window is statistically analyzed, and a cache scheduling evaluation parameter set is constructed in combination with the system operation status information of the above alarm host.

[0154] S13023. Based on the above set of cache scheduling evaluation parameters, perform priority evaluation processing on the above structured alarm record data in the above alarm record cache queue to generate cache scheduling priority values ​​corresponding to each of the above structured alarm record data.

[0155] S13024. Based on the aforementioned cache scheduling priority values, sort the aforementioned alarm record cache queue, and select the aforementioned structured alarm record data with a priority higher than a preset threshold from the aforementioned alarm record cache queue, and determine it as the aforementioned target structured alarm record data.

[0156] S13025, Perform a write operation on the determined target structured alarm record data to the local persistent storage layer.

[0157] In one feasible implementation, such as Figure 6 As shown, step S1303 above performs persistent writing processing on the target structured alarm record data, writing the target structured alarm record data and its corresponding integrity verification value into the local persistent storage layer of the alarm host, and generating corresponding storage address identifiers and time index information during the writing process to establish a persistent index structure for the structured alarm record data, including:

[0158] S13031. After receiving the above-mentioned target structured alarm record data, perform write preparation processing on the above-mentioned target structured alarm record data and its corresponding integrity verification value, and generate a unique data write identifier for each of the above-mentioned target structured alarm record data.

[0159] S13032. Based on the above data writing identifier, the above target structured alarm record data and the above integrity verification value are written to the local persistent storage layer of the alarm host in chronological order, and the corresponding data storage address information is recorded during the writing process.

[0160] S13033. After completing the writing of the above-mentioned target structured alarm record data, generate the corresponding time index information according to the above-mentioned data storage address information, and associate the above-mentioned time index information with the above-mentioned data writing identifier to form an index mapping relationship of the structured alarm record data.

[0161] S13034. Write the above index mapping relationship into the preset alarm record index table, and establish the persistent index structure of the above structured alarm record data based on the above alarm record index table.

[0162] S13035. The above-mentioned persistent index structure enables rapid location and access to the target structured alarm record data, thereby completing the process of writing the structured alarm record data into the local persistent storage layer and establishing a persistent index structure.

[0163] For example, in step S1301, structured alarm record data bound with integrity check values ​​is first received, and the structured alarm record data is first written into the device cache layer of the alarm host to form an alarm record cache queue arranged in chronological order. Binding with integrity check values ​​indicates that the data input to the hierarchical storage stage has completed the preceding chain-based secure storage processing; therefore, each record includes not only the structured content of the alarm event itself, but also the corresponding integrity check value and the chain-based association result with the preceding record. The first... A record entering the device cache layer is defined as follows:

[0164]

[0165] in, Indicates the first Cache record unit; This represents structured alarm log data; This represents the integrity check value bound to the structured alarm record data; This indicates the timestamp of the record; This indicates the record sequence number. After receiving the cached record unit, the alarm host pushes it into the device cache queue according to time sequence or record sequence number order. This forms an alarm record cache queue:

[0166] Q(k) = {R1, R2, ..., R} k}

[0167] in, This indicates the cumulative number of cached items in the current device cache layer. An alarm record cache queue is used. This method allows the system to prioritize and accept consecutively arriving alarm records at high speed, avoiding write blocking caused by direct access to persistent media during high-frequency alarms.

[0168] To improve the fine-grained management capabilities during the cache access phase, this embodiment can also generate a cache occupancy strength factor for each cache record:

[0169]

[0170] in, Indicates the first The cache occupancy intensity factor for each alarm record; This indicates the data length of the record; This indicates the number of context fields or metadata associated with the record; This indicates the initial value of the event importance corresponding to this record; and These represent the normalized baseline value for length and the normalized baseline value for the number of fields, respectively. This represents the weighting coefficient.

[0171] After completing step S1301, proceed to step S1302. In this step, the system does not directly write to the local persistent storage layer using a fixed time period or a fixed number of records threshold. Instead, it monitors the cache status of the alarm record cache queue and dynamically schedules the write based on a preset cache capacity threshold, alarm event triggering frequency, and system operating status to determine the target structured alarm record data that needs to be persistently written. Further, in Figure 5 In the embodiment shown, step S1302 further includes steps S13021 to S13025, thereby forming an adaptive scheduling process driven by multiple factors.

[0172] First, in step S13021, after the structured alarm record data is written to the device cache layer and forms an alarm record cache queue, the cache capacity occupancy status of the alarm record cache queue is monitored in real time to obtain the current cache occupancy ratio information. This process is essentially a basic perception of the operating pressure of the device cache layer. The cache occupancy ratio can be defined as:

[0173] in, This indicates the current cache usage percentage of the device's cache layer. This indicates that the cache space is currently occupied; Indicates the total cache capacity. When... When the value continues to rise, it indicates that the cache layer is nearing saturation, and the frequency of persistent scheduling of subsequent records needs to be increased. To further enhance flexibility, a cache growth rate parameter can be introduced:

[0174]

[0175] in, This indicates the percentage of cache usage within the time window. The rate of change within the cache. This parameter reflects whether the cache pressure is increasing steadily or rapidly, thus allowing subsequent scheduling to consider not only the instantaneous occupancy rate but also the trend of occupancy changes.

[0176] Subsequently, in step S13022, after obtaining the cache occupancy ratio information, the alarm event trigger frequency within a preset time window is statistically analyzed, and combined with the system operating status information of the alarm host, a cache scheduling evaluation parameter set is constructed. Here, the alarm event trigger frequency reflects the density of alarm records arriving at the device cache layer per unit time, while the system operating status reflects the host's current processing capacity and resource reserves. The alarm event trigger frequency can be defined as:

[0177]

[0178] in, Indicates the preset time window The frequency of alarm event triggering within the system; This indicates the number of alarm records that entered the cache queue within the stated time window. Simultaneously, system operating status load indicators can be defined:

[0179]

[0180] in, This indicates the system operating status and load indicators of the alarm control panel; This represents the normalized value of CPU load. This represents the normalized value of storage I / O usage; This represents the normalized value of memory usage; This indicates an abnormal state and is used to represent the degree of abnormality such as thread blocking, unstable communication, increased write retries, or module degradation. These are the weighting coefficients. This leads to a set of cache scheduling evaluation parameters:

[0181]

[0182] in, This represents the set of cache scheduling evaluation parameters. Through this set, the system can comprehensively characterize the current cache environment from four dimensions: cache occupancy status, cache pressure trends, alarm input strength, and host processing capacity.

[0183] Next, in step S13023, based on the aforementioned cache scheduling evaluation parameter set, priority evaluation processing is performed on the structured alarm record data in the alarm record cache queue to generate a cache scheduling priority value corresponding to each structured alarm record data. The key here is that not all cached records should be immediately migrated to the local persistent storage layer; instead, they should be comprehensively sorted based on factors such as their residence time, event risk, chain-related sensitivity, and cache pressure background. A cache scheduling priority function can be constructed as follows:

[0184]

[0185] in, Indicates the first The cache scheduling priority value corresponding to each structured alarm record data; This indicates the dwell time between the current time and the time the record entered the cache; Indicates the time normalization reference; The event risk weight of this record can be determined by a combination of alarm type, zone level, and event credibility. This represents the aforementioned cache occupancy strength factor; It indicates chain continuity sensitivity, used to characterize whether the record is at an important position in a continuous alarm chain; Indicates the current cache usage percentage; Indicates the frequency of alarm event triggering; This indicates the load index representing the system's operating status; to This represents the weighting coefficients for each item. By introducing these factors, the priority value not only reflects the importance of a single record, but also the current host operating environment and cache pressure, thus enabling a more intelligent determination of the persistent write order.

[0186]

[0187] in, This indicates the current cache usage percentage of the device's cache layer. This indicates that the cache space is currently occupied; Indicates the total cache capacity. When... When the value continues to rise, it indicates that the cache layer is nearing saturation, and the frequency of persistent scheduling of subsequent records needs to be increased. To further enhance flexibility, a cache growth rate parameter can be introduced:

[0188]

[0189] in, This indicates the percentage of cache usage within the time window. The rate of change within the cache. This parameter reflects whether the cache pressure is increasing steadily or rapidly, thus allowing subsequent scheduling to consider not only the instantaneous occupancy rate but also the trend of occupancy changes.

[0190] Then, in step S13024, the alarm record cache queue is sorted according to the priority values ​​of each cache scheduling, and structured alarm record data with a priority higher than a preset threshold is selected from the alarm record cache queue and determined as the target structured alarm record data. This can be represented as:

[0191]

[0192] in, This represents the target structured alarm record data set; This indicates the cache scheduling priority threshold. When... If the value is higher than the threshold, it indicates that the record is more suitable for priority writing to the local persistent storage layer. To improve adaptability, this embodiment can also dynamically change the threshold, for example:

[0193]

[0194] in, The threshold varies with cache availability and system resource availability. When cache usage is high and system load is moderate, the threshold decreases, and more records are selected as target structured alarm log data. When cache is sufficiently free or system load is high, the threshold increases to reduce frequent disk writes. This design further enhances the innovation of the solution.

[0195] Finally, in step S13025, the determined target structured alarm record data is output to the persistent write processing flow corresponding to step S1303 to perform the write operation of the target structured alarm record data to the local persistent storage layer. Although this step is a process connection step in words, its technical significance lies in: achieving decoupling between scheduling logic and storage logic through steps S13021 to S13024. The output mapping can be represented as:

[0196]

[0197] in, This indicates the set of tasks to be persisted and written. This represents the scheduling output mapping function, used to convert the target structured alarm record data set into an executable sequence of write tasks. This decoupled design allows for independent optimization of subsequent persistent write strategies without altering the cache scheduling logic.

[0198] After entering step S1303, the system begins persistent writing of the target structured alarm record data, generating corresponding storage address identifiers and time index information during the writing process to establish a persistent index structure for the structured alarm record data. For example... Figure 6 As shown, step S1303 further includes steps S13031 to S13035, thereby forming a complete write preparation, write execution, index mapping, index database creation, and fast access process.

[0199] First, in step S13031, after receiving the target structured alarm record data, the target structured alarm record data and its corresponding integrity check value are prepared for writing, and a unique data write identifier is generated for each target structured alarm record data. Its core purpose is to assign a unique disk write identity to each record to be written before it is formally written to the local persistent storage layer. The data write identifier can be defined as:

[0200]

[0201] in, Indicates the first The data write identifier corresponding to the structured alarm record data of each target; Indicates the record number; Represents a timestamp; Indicates the integrity check value; Indicates equipment identification; This indicates a concatenation operation. This data write identifier ensures that each written record is unique within the local persistent storage layer, preventing duplicate writes or index mismatches.

[0202] Subsequently, in step S13032, based on the data write identifier, the target structured alarm record data and integrity verification value are written to the local persistent storage layer of the alarm host in chronological order, and the corresponding data storage address information is recorded during the writing process. The persistent mapping object after writing can be represented as:

[0203]

[0204] in, Indicates the first The persistent mapping object of the record; Indicates the data write flag; This represents the target structured alarm record data and its integrity check value; This indicates the data storage address information after the record is written to the local persistent storage layer. To enhance write reliability, this embodiment can define a write reliability function:

[0205]

[0206] in, Indicates the first The write reliability of the target record; This indicates the health status of the local persistent storage medium. This indicates the stability metric of the write path; This indicates the consistency index after writing; This represents the weighting coefficient. If... If the value is below a preset threshold, a rewrite, spare area write, or additional redundant digest operation can be triggered to avoid record loss due to local anomalies in the persistent media.

[0207] Next, in step S13033, after writing the target structured alarm record data, corresponding time index information is generated based on the data storage address information, and the time index information is associated with the data writing identifier to form an index mapping relationship for the structured alarm record data. The core here is to bind the physical storage location with the time dimension, enabling the alarm host to quickly locate the corresponding data during subsequent queries. The time index information can be defined as follows:

[0208]

[0209] in, Indicates the first The time index information corresponding to each record; This represents a time bucket mapping function that can convert timestamps... The mapping is done to hourly, daily, segmented, or preset time-slice indices. Furthermore, index mapping relationships can be formed:

[0210]

[0211] in, Indicates the first The index mapping relationship of each record is used to establish a one-to-one correspondence between data write identifiers, time index information, and data storage address information. To further enhance creativity, composite index keys can also be constructed.

[0212]

[0213] in, Indicates a composite index key; Indicates defense zone markings; Indicates the event type parameter; Indicates the record number; This represents the index generation function. Using a composite index key, subsequent queries can be performed not only by time, but also quickly filtered by defense zone and event type.

[0214] Then, in step S13034, the index mapping relationship is written into a preset alarm record index table, and a persistent index structure for structured alarm record data is established based on the alarm record index table. The alarm record index table here can be considered as the basic data organization unit of the alarm host's local tracing engine. The index table can be represented as:

[0215]

[0216] in, This represents the alarm record index table; This indicates the number of records for which index construction has been completed. If a composite index key is introduced, the persistent index structure can also be represented as:

[0217]

[0218] in, This represents a composite persistent index structure. This structure supports time range retrieval, specific zone retrieval, specific event type retrieval, and fast backtracking of continuous record chains, significantly outperforming traditional local storage methods that rely solely on sequential scanning.

[0219] Finally, in step S13035, the target structured alarm record data is quickly located and accessed through the aforementioned persistent index structure, thereby completing the process of writing the structured alarm record data into the local persistent storage layer and establishing the persistent index structure. This step not only reflects the result of the preceding steps but also embodies the design philosophy of this embodiment: storage serves traceability. A retrieval cost function can be defined:

[0220]

[0221] in, Indicates the retrieval cost of the target record; Indicates the number of index entries that need to be scanned; This indicates the time overhead of locating the physical storage address; This indicates the time cost of recovering the target record from the index mapping relationship; , This represents the weighting coefficient. The persistent index structure described above can significantly reduce... and This reduces the overall retrieval cost and improves the local tracing efficiency of the alarm host in an offline environment.

[0222] After completing steps S13031 to S13035, return to step S1304 to perform a cache status update operation on the target structured alarm record data in the device cache layer, in order to release the data cache space that has been persistently written and retain the data that has not been written. A cache release determination function can be constructed as follows:

[0223]

[0224] in, Indicates the first The cache release flag for the target record; when When the record is successfully written to the local persistent storage layer and the write reliability meets the requirements, it can be released from the device cache layer; when This indicates that the record still needs to be retained in the device cache layer for retry or rewriting. The remaining queue after the device cache layer update can be represented as:

[0225]

[0226] in, This represents the updated alarm record cache queue. Furthermore, cache recovery margin can be defined:

[0227]

[0228] in, This indicates the newly released cache space after a persistent write is completed and the cache state is updated; Indicates the remaining cache space before the update; This indicates the remaining cache space after the update. The system can adjust the priority threshold for the next round based on this cache recovery margin. This enables the hierarchical storage mechanism to have adaptive feedback capabilities.

[0229] In one feasible implementation, such as Figure 7 As shown, when the network connection is restored in step S140, the structured alarm record data and the corresponding integrity verification value stored in the local anti-tampering storage area are synchronized to the cloud server. The cloud server then performs integrity verification and redundant backup storage on the structured alarm record data, including:

[0230] S1401. After detecting that the network connection status of the alarm host has been restored from the disconnected state to the communicable state, the alarm host first scans the structured alarm record data in the local anti-tampering storage area and determines the target structured alarm record data set that has not yet been synchronized with the cloud.

[0231] S1402. Perform batch encapsulation processing on each of the above-mentioned structured alarm record data and the corresponding integrity verification value in the above-mentioned target structured alarm record data set, and generate the corresponding synchronization batch identifier and data summary information during the encapsulation process to form a data synchronization package to be synchronized.

[0232] S1403. Through the secure communication channel established between the alarm host and the cloud server, the data synchronization packet is sent to the cloud server, and the cloud server receives the structured alarm record data and the integrity verification value in the data synchronization packet.

[0233] S1404. After the cloud server receives the data synchronization packet, it performs integrity verification processing on the structured alarm record data. By recalculating the verification value of the structured alarm record data and comparing it with the integrity verification value, the integrity and consistency of the structured alarm record data during transmission are confirmed.

[0234] S1405. After the above integrity verification is passed, the above structured alarm record data is written to multiple cloud storage nodes according to the preset distributed redundancy strategy, and the corresponding data backup identifier and synchronization confirmation information are generated and returned to the above alarm host to complete the synchronization of structured alarm record data to the cloud server and perform integrity verification and redundant backup storage.

[0235] For example, in step S1401, after detecting that the network connection status of the alarm host has recovered from a disconnected state to a communicable state, the alarm host first scans the structured alarm record data in the local tamper-proof storage area and identifies the target set of structured alarm record data that has not yet completed cloud synchronization. The key technical point of this step is that after network recovery, not all local alarm record data is uploaded indiscriminately, but a status-aware scan is first performed on the local tamper-proof storage area to identify those data records that have not yet completed cloud synchronization, thus avoiding duplicate synchronization, invalid transmission, and duplicate storage in the cloud. The cumulative set of alarm records stored in the local tamper-proof storage area can be represented as:

[0236]

[0237] in, This represents the total set of alarm records in the local tamper-proof storage area; Indicates the first A chain-like alarm record data block, comprising at least structured alarm record data, corresponding integrity check values, and chain-like association information. Simultaneously, a cloud-synchronized status flag can be maintained for each record. , among which when This indicates that the record has not yet been synchronized to the cloud server. This indicates that the record has been successfully synchronized to the cloud. Therefore, the target structured alarm record data set can be determined as follows:

[0238]

[0239] in, This represents the target structured alarm record data set that has not yet been fully synchronized to the cloud. To improve creativity during the scanning phase, this embodiment can also introduce a network recovery stability judgment factor to avoid immediately initiating large-scale synchronization when the network experiences frequent jitter immediately after recovery. Correspondingly, the following can be defined:

[0240]

[0241] in, Indicates the network recovery stability factor; This represents a normalized metric indicating the continuous online time of the link; Indicates the stability of link latency; This represents a reverse indicator of packet loss rate; Indicates the weighting coefficient. Only when The system will only continue to perform subsequent batch synchronization processing when the value exceeds the preset stability threshold, thereby improving the stability of the cloud synchronization process.

[0242] After determining the target structured alarm record data set, proceed to step S1402. In this step, each structured alarm record data and its corresponding integrity verification value in the target structured alarm record data set are batch-packaged, and a corresponding synchronization batch identifier and data digest information are generated during the packaging process to form a data synchronization package to be synchronized. The key to this step is not simple compression or packaging, but rather the construction of a verifiable batch transmission unit for cloud verification and backup, so that a batch of records, when transmitted over the network, simultaneously possesses the characteristics of overall identifiability, batch traceability, and content digestibility. The target data set included in the current synchronization batch can be set as follows:

[0243]

[0244] in, Indicates the first Each synchronous batch contains a set of chained alarm record data blocks; This indicates the number of data blocks contained in the batch. Based on this batch of data, a synchronization batch identifier can be generated:

[0245]

[0246] in, Indicates the first Synchronization batch identifier for each data synchronization package; This indicates the timestamp of the earliest alarm record in this batch; This indicates the timestamp of the latest alarm record in this batch; Indicates the number of records in this batch; This indicates the batch serial number or the current synchronization round identifier of the local host; This indicates a concatenation operation. By using a synchronized batch identifier, the cloud server can quickly confirm the identity and scope of the batch upon receiving the data synchronization packet.

[0247] Furthermore, to enable the entire package of data to have overall summarization capabilities, batch data summary information can be constructed:

[0248]

[0249] in, Indicates the first Data digest information corresponding to each data synchronization package. For further innovation, a tree-structured aggregated digest mechanism can be used, for example, generating batch digest root values ​​based on hierarchical hashing:

[0250]

[0251] in, Indicates the first The root value of the tree summary for each synchronous batch; This indicates that the root digest generation function, after constructing a Merkle tree, is executed on the batch dataset. The advantage of this approach is that when the cloud server verifies an anomaly in a portion of the data, it does not need to re-verify the entire package; instead, it can quickly locate the anomaly record through a local path, thereby improving the verification efficiency after batch synchronization. Finally, the data synchronization package to be synchronized can be represented as:

[0252]

[0253] in, Indicates the first A data synchronization packet to be synchronized. In step S1403, the data synchronization packet is sent to the cloud server through a secure communication channel established between the alarm host and the cloud server, and the cloud server receives the structured alarm record data and integrity verification value in the data synchronization packet. The key point of this step is that the synchronization process is not completed through ordinary plaintext transmission, but is executed through a secure communication channel with authentication, encryption, and transmission status confirmation capabilities. The reliable transmission capability of the secure communication channel can be expressed as:

[0254]

[0255] in, Indicates the first The reliability of the transmission of each synchronous batch under the current secure communication channel; Indicates the link encryption strength index; This indicates the strength of authentication between the communicating parties. Indicates transmission acknowledgment integrity metrics, such as whether segmented acknowledgments, retransmission acknowledgments, and packet-level acknowledgments are supported; Indicates the weighting coefficient. Only when... The system will only process the first [item] when the value exceeds a preset threshold. The batch is then officially sent to the cloud server. To enhance adaptability to weak network environments, the number of fragments in the batch transmission can also be defined:

[0256]

[0257] in, Indicates the first The number of transmission fragments into which a data synchronization packet is divided; Indicates the total byte length of the data synchronization packet; This indicates the maximum fragment length allowed to be sent in a single transmission. Fragmentation transmission and fragmentation acknowledgment mechanisms can improve synchronization success rates during periods of network fluctuation in the initial recovery phase.

[0258] Subsequently, in step S1404, after the cloud server receives the data synchronization packet, it performs integrity verification processing on the structured alarm record data. This involves recalculating the checksum of the structured alarm record data and comparing it with the integrity checksum to confirm the integrity and consistency of the structured alarm record data during transmission. This step is crucial for achieving trusted cloud reception. Specifically, the cloud server does not directly trust the data sent by the alarm host; instead, it recalculates the checksum based on the structured alarm record data in the synchronization packet and compares it with the integrity checksum carried in the synchronization packet to determine whether the data has been damaged, missing, tampered with, or rearranged during transmission. For the first... The received structured alarm record data can be represented by the cloud-recalculated checksum as follows:

[0259]

[0260] in, Indicates the cloud server for the first The verification value is obtained by recalculating the structured alarm record data; Represents the hash operation function; This refers to the data calculation unit reconstructed by the cloud server based on the received structured alarm record data, record number, timestamp, and preceding verification association information. If the original integrity check value carried in the synchronization packet is denoted as... Then the consistency determination function for a single record can be defined as:

[0261]

[0262] in, Indicates the first The integrity and consistency determination result of the record; when This indicates that the structured alarm record data remains intact and consistent with the original local record during transmission; when This indicates that the data entry has a risk of inconsistency. For batch data synchronization packages, a batch consistency pass rate can also be defined:

[0263]

[0264] in, Indicates the first The pass rate of integrity verification for each synchronized batch; This represents the total number of records in the batch. If the aforementioned Merkle tree root digest mechanism is used, the cloud server can also reconstruct the batch digest root value from the received data. and the digest root value carried in the synchronization packet. Comparison:

[0265]

[0266] in, Indicates the first The overall summary consistency judgment value for each synchronous batch. By combining single record verification with batch summary verification, the system can simultaneously achieve fine-grained record verification and rapid batch verification, significantly improving the verification capability and creativity during the cloud reception stage.

[0267] In step S1405, after the integrity verification passes, the structured alarm record data is written to multiple cloud storage nodes according to a preset distributed redundancy strategy, and corresponding data backup identifiers and synchronization confirmation information are generated and returned to the alarm host to complete the synchronization of structured alarm record data to the cloud server and perform integrity verification and redundant backup storage. This step means that the cloud server not only completes the reception and verification, but also further performs multi-node redundant disk write of the alarm record data based on the distributed storage concept, thereby avoiding the data unrecoverable problem caused by the failure of a single cloud node. A single record can be... The set of redundant write nodes in the cloud is represented as:

[0268]

[0269] in, Indicates the first The set of storage nodes where alarm records are written to the cloud; Indicates the preset number of redundant copies; Indicates the first There are several target storage nodes. If node load, geographical distribution, and reliability are further considered, a distributed redundancy strategy scoring function can be constructed:

[0270]

[0271] in, Indicates the first The alarm record is written to the first Compatibility score of each cloud storage node; This indicates the geographic dispersion of the node relative to the current host or the current batch. This indicates the current bandwidth and write load adaptability metrics of the node; This indicates the historical reliability index of the node; This represents the weighting coefficient. The cloud server can prioritize selecting the nodes with the highest scores to complete redundant writes. After the write is complete, a cloud data backup identifier can be generated for each record.

[0272]

[0273] in, Indicates the first The cloud data backup identifier corresponding to each structured alarm record data; Indicates the batch identifier to which it belongs; This indicates the integrity check value corresponding to this record; This indicates the set of redundant storage nodes corresponding to this record. Subsequently, the cloud server generates a synchronization confirmation message based on the cloud data backup identifier and batch processing results, and returns it to the alarm host. The synchronization confirmation message can be represented as:

[0274]

[0275] in, Indicates the first Synchronization confirmation information corresponding to each synchronization batch; Indicates the batch integrity verification pass rate; This indicates the overall summary consistency score. This represents the set of cloud data backup identifiers for each record in this batch. After receiving the synchronization confirmation information, the alarm host can update the synchronization status flag of the corresponding record locally. Update to a synchronized state to complete the state loop between local records and cloud backup records.

[0276] To further enhance the creativity of this embodiment, a batch cloud backup reliability function can also be defined:

[0277]

[0278] in, Indicates the first The reliability of cloud backups in a single synchronized batch; Indicates the batch integrity verification pass rate; This indicates the overall summary consistency determination result; This represents the ratio of the number of nodes that actually completed redundant writing for a single record to the preset number of redundant replicas. This represents the weighting coefficient. When... Only when the reliability exceeds a preset threshold will the alarm host officially mark the batch of local records as successfully archived in the cloud; otherwise, it can retain the retransmission mark or trigger the next round of synchronization. Thus, the system does not simply determine synchronization success based on whether an ACK has been received, but rather comprehensively assesses the quality of cloud archiving based on three aspects: verification, digest, and redundancy.

[0279] In one feasible implementation, such as Figure 8 As shown, in step S150 above, when a power supply abnormality or system abnormality is detected, an emergency write mechanism is triggered to write the non-persistent alarm record data in the cache to a non-volatile storage medium, including:

[0280] S1501. During the operation of the above-mentioned alarm host, the power supply status and system operation status of the alarm host are monitored in real time. When the power supply voltage is detected to be lower than the preset safety threshold or the system operation status is abnormal, an abnormal trigger signal is generated and the emergency writing mechanism is activated.

[0281] S1502. After the above-mentioned emergency write mechanism is activated, the above-mentioned structured alarm record data in the above-mentioned device cache layer is scanned and identified, and the target structured alarm record data set that has not yet been written to the above-mentioned local persistent storage layer is determined.

[0282] S1503. Prioritize and sort the structured alarm record data and their corresponding integrity verification values ​​in the above target structured alarm record data set, and generate an emergency write data sequence in chronological order.

[0283] S1504. Write the structured alarm record data and its corresponding integrity check value in the above emergency write data sequence into a non-volatile storage medium, and generate corresponding emergency storage identifier and time index information for each of the above structured alarm record data during the writing process to form a power failure protection record unit.

[0284] S1505. After completing the writing to the non-volatile storage medium, the status of the emergency storage identifier is updated, and the power failure protection recording unit is marked as alarm record data that has been written for protection, so as to realize the safe transfer of non-persistent alarm record data in the device cache layer to the non-volatile storage medium.

[0285] In one feasible implementation, such as Figure 9 As shown, step S1503 prioritizes each structured alarm record data and its corresponding integrity check value in the target structured alarm record data set, and generates an emergency write data sequence in chronological order, including:

[0286] S15031. After determining the above-mentioned target structured alarm record data set, extract the event type information, trigger zone identifier, timestamp information and the above-mentioned integrity verification value corresponding to each of the above-mentioned structured alarm record data in the above-mentioned target structured alarm record data set to form an emergency dispatch parameter set.

[0287] S15032. Based on the above set of emergency dispatch parameters, calculate the corresponding emergency write priority value for each of the above structured alarm record data, wherein the above emergency write priority value is determined by the severity of the alarm event, the time of the event, and the risk level of the defense zone.

[0288] S15033. Sort the above target structured alarm record data set according to the above emergency write priority values ​​to generate a priority sorting list, and keep the data with the same priority in chronological order during the sorting process.

[0289] S15034. According to the priority sorting list above, the sorted structured alarm record data and its corresponding integrity verification value are combined in sequence to generate an emergency write data sequence arranged in chronological order.

[0290] S15035. The generated emergency write data sequence is written to the structured alarm record data into a non-volatile storage medium for emergency write processing in the event of a power outage.

[0291] For example, in step S1501, during the operation of the alarm host, the power supply status and system operating status of the alarm host are monitored in real time. When the power supply voltage is detected to be lower than a preset safety threshold or the system operating status is abnormal, an abnormal trigger signal is generated, and an emergency writing mechanism is initiated. The key to this step is that the system does not wait until a real power outage occurs before it begins to respond, but rather enters the emergency protection mode in advance when power attenuation or system abnormality just begins to appear, thereby gaining effective writing time. For this purpose, power supply abnormality indicators and system abnormality indicators can be defined separately. The power supply abnormality indicator can be expressed as:

[0292]

[0293] in, Indicates the current degree of power supply anomaly; This indicates the power supply voltage detected by the alarm control panel at the current moment; This indicates the preset safety threshold voltage. When... hour, A positive value indicates that the power supply is closer to an unsustainable state. Meanwhile, abnormal system operating status indicators can be represented as:

[0294]

[0295] in, Indicates the degree of system malfunction; This represents the normalized value of CPU load. This represents the normalized value of memory usage; This represents the normalized value indicating the degree of I / O blocking. Indicates abnormal indicators for task threads, such as thread backlog, thread crash, or task timeout. Indicates the degree of communication anomaly between modules; to These are the weighting coefficients. Based on the above two dimensions, an emergency triggering determination function can be further constructed:

[0296]

[0297] in, Indicates the overall abnormal trigger value; This represents the weighting coefficient corresponding to power supply anomalies and system anomalies. When... At that time, the system generates an abnormal trigger signal and activates the emergency write mechanism, in which This represents the emergency activation threshold. To further enhance creativity, a prediction of remaining writable time can also be introduced:

[0298]

[0299] in, This indicates a safe time window during which the system can still perform emergency writes even under the current abnormal state; Indicates the duration that the backup capacitor or power supply can support. This represents the inverse margin of the estimated minimum time required to complete a single write operation of the currently cached data. This indicates the predicted remaining time for the system to maintain basic write capabilities under the current level of anomaly. , This is a weighting coefficient. By introducing the aforementioned security time window, the system can determine how many records should be prioritized for protection and what write granularity should be used during subsequent emergency write operations.

[0300] In step S1502, after the emergency write mechanism is activated, the structured alarm record data in the device cache layer is scanned and identified, and the target set of structured alarm record data that has not yet been written to the local persistent storage layer is determined. This step does not essentially process all cached data indiscriminately, but rather quickly filters out critical data that still exists in the device cache layer, has not been successfully persisted, and will be lost upon power failure. The current cache queue of the device cache layer can be set as follows:

[0301]

[0302] in, This represents the set of cached records in the current device's cache layer; Indicates the first A cache record unit consists of structured alarm record data and its corresponding integrity check value. Simultaneously, a persistent status flag is maintained for each cache record. , among which when This indicates that the record has not yet been written to the local persistent storage layer. This indicates that the record has been successfully written to the local database. Therefore, the target structured alarm record data set can be determined as follows:

[0303]

[0304] in, This represents the target structured alarm record data set corresponding to the emergency write mechanism. To improve scanning efficiency, a non-persistent density index can also be defined:

[0305]

[0306] in, This indicates the proportion of non-persistent records in the current device's cache layer out of all cached records. This metric reflects the potential data loss under current power outage risks and can also serve as a reference for subsequent emergency sorting thresholds and write pruning strategies.

[0307] After target record identification is completed, proceed to step S1503. In this step, the structured alarm record data and their corresponding integrity check values ​​in the target structured alarm record data set are prioritized and sorted, and an emergency write data sequence is generated in chronological order. This step is the core of the entire emergency protection mechanism because, in extreme cases, the remaining safe time... Often, it is insufficient to write all the target data completely to the non-volatile storage medium; therefore, the writing order must be determined based on the importance and urgency of the data. For example... Figure 9 As shown, step S1503 further includes steps S15031 to S15035, thereby forming a priority modeling and emergency sequence generation process for power outage conditions.

[0308] First, in step S15031, after determining the target structured alarm record data set, the event type information, trigger zone identifier, timestamp information, and integrity check value corresponding to each structured alarm record data in the target structured alarm record data set are extracted to form an emergency dispatch parameter set. The first... The emergency dispatch parameter vector corresponding to each target record is represented as follows:

[0309]

[0310] in, Indicates the first The emergency dispatch parameter vector corresponding to the structured alarm record data of each target; Indicates event type information; Indicates that the zone indicator has been triggered; Represents timestamp information; This represents the integrity check value corresponding to this record. Furthermore, the emergency dispatch parameters of all target records can be combined into a set:

[0311]

[0312] in, Represents the set of emergency dispatch parameters; This indicates the number of structured alarm record data points currently awaiting emergency protection. The significance of this step is that subsequent priority calculations no longer rely solely on which data arrives in the cache first, but rather on a comprehensive judgment based on event attributes, spatial location, time urgency, and verification relevance.

[0313] Next, in step S15032, based on the emergency dispatch parameter set, the corresponding emergency write priority value is calculated for each structured alarm record data. The emergency write priority value is determined by the severity of the alarm event, the time of the event, and the risk level of the defense zone. This step is one of the key creative aspects of this embodiment. The emergency write priority function can be defined as:

[0314]

[0315] in, Indicates the first Emergency write priority value for structured alarm log data; Indicators representing the severity of alarm incidents; Indicators representing the urgency of an event; Indicators representing the risk level of the defense zone; Indicates the sensitivity index for continuity in chained checks; This represents the weighting coefficients for each item. The four indicators mentioned above can be further defined as follows.

[0316] The severity index of an alarm event can be expressed as:

[0317]

[0318] in, This function represents the mapping from event type to severity level. For example, events such as fire alarms, emergency calls, and demolition / vandalism can be assigned a higher severity level, while events such as normal status changes or low-risk warnings can be assigned a lower severity level.

[0319] The time urgency of an event can be expressed as:

[0320]

[0321] in, Indicates the first The time urgency of each record; This indicates the current moment when the emergency write phase has begun; This indicates the time when the event corresponding to this record occurred; This represents the time decay coefficient. This formula shows that the more recent the record is, the higher its time urgency, because these records often haven't had time to be saved on other paths.

[0322] The risk level index of the defense zone can be expressed as:

[0323]

[0324] in, This represents the mapping function from zone identifiers to zone risk levels. Higher risk levels can be assigned to high-risk zones such as core computer rooms, finance offices, hazardous materials areas, and key security boundary areas.

[0325] The chain check continuity sensitivity index can be expressed as:

[0326]

[0327] in, Indicates the first Chain-checking of records for continuity sensitivity; Indicates the indicator function, when the first... The record is located at the set of critical nodes in a continuous alarm chain. The value is 1 when it is in the middle, otherwise it is 1. This indicates the chain distance between this record and the most recently persisted record; This represents the weighting coefficient. By introducing this term, we can prioritize the protection of critical records whose absence would disrupt the entire chain of checksums, rather than just protecting records with high event priority.

[0328] Furthermore, considering that the system may not be able to complete the writing of all data under abnormal conditions, this embodiment can also define an emergency writeable scale:

[0329]

[0330] in, This indicates the maximum number of records that can be written to under emergency conditions within the current safe time window; This represents the average emergency write time for a single record. Therefore, the system can select only the records ranked highest after calculating priorities. These records are mandatory, thereby further improving the efficiency of emergency protection under abnormal operating conditions.

[0331] In step S15033, the target structured alarm record data set is sorted according to each emergency write priority value to generate a priority sorting list, and data with the same priority are arranged in chronological order during the sorting process. The sorting result can be represented as:

[0332]

[0333] in, This represents a priority-sorted list; This indicates the sorting function; priority values ​​are first written according to the emergency. Sort by priority from highest to lowest, and if two records have the same priority value, then sort by timestamp. The data is stably sorted according to a preset order from morning to night or from critical moments to the current moment. This ensures that the system can prioritize writing high-value records in emergency situations without disrupting the chronological order of records of the same priority. To enhance creativity, a sorting stability coefficient can also be defined.

[0334]

[0335] in, This indicates the time stability of the sorted record sequence. When... When the value approaches 1, it indicates that the sorting results maintain temporal continuity well based on priority hierarchy, which is beneficial for subsequent recovery and auditing.

[0336] Subsequently, in step S15034, according to the priority sorting list, the sorted structured alarm record data and their corresponding integrity check values ​​are combined sequentially to generate an emergency write data sequence arranged in chronological order. The first... The serialized emergency write unit is represented as follows:

[0337]

[0338] in, Indicates an emergency write unit; This represents structured alarm log data; This represents the corresponding integrity check value; This indicates its ranking position in the priority sorting list. Therefore, an emergency write data sequence can be formed:

[0339]

[0340] in, This indicates an emergency write data sequence; This indicates the actual number of data entries included in this round of emergency writes. To balance chronological order and write efficiency, the emergency write data sequence can be aggregated at the block level. For example, records from adjacent time periods or the same defense zone can be packaged into the smallest write block, thereby reducing the addressing and write overhead of non-volatile storage media. Its block-level aggregation expression can be represented as:

[0341]

[0342] in, Indicates the set of emergency write blocks; This represents the packing function; Indicates the time aggregation threshold; This indicates the zone aggregation condition. This design improves write throughput efficiency within a limited write time.

[0343] Finally, in step S15035, the generated emergency write data sequence is output to the subsequent non-volatile storage medium write step for emergency write processing in the event of a power outage. Although this step is a connecting step in the process flow, its technical significance lies in the fact that the preceding sorting and sequence generation results are no longer static lists, but are transformed into a directly executable emergency write task stream. This can be represented as:

[0344]

[0345] in, This indicates that emergency writes should be made to the task stream; This represents a mapping function from an emergency write data sequence to a storage write task. Through this task flow, the system can send critical records to non-volatile storage media in a predetermined order within a very short time, without requiring complex judgments during the write process.

[0346] After completing step S1503, proceed to step S1504. In this step, the structured alarm record data and its corresponding integrity check value in the emergency write data sequence are written to a non-volatile storage medium. During the writing process, a corresponding emergency storage identifier and time index information are generated for each structured alarm record data to form a power outage protection recording unit. The technical focus of this step is that the writing result is not a simple data copy, but a power outage protection recording unit with independent identification and rapid recovery capabilities. The first... The emergency storage identifier corresponding to each record is:

[0347]

[0348] in, Indicates the first Emergency storage identifier for each record; Indicates the record number; Represents a timestamp; Indicates the integrity check value; This indicates the current emergency write round identifier. Simultaneously, time index information can be generated:

[0349]

[0350] in, This indicates the corresponding emergency time index information; This represents a time index mapping function. This allows the formation of a power outage protection recording unit:

[0351]

[0352] in, This indicates a power failure protection recording unit. To further enhance the creativity of this embodiment, an emergency write success rate can also be defined:

[0353]

[0354] in, Indicates the first Success rate of emergency write to power outage protection records; Indicates the current availability or health status of non-volatile storage media; This indicates the stability of the current emergency write path; This indicates the consistency index after write verification; For weighting coefficients. When When the value is below the threshold, a backup block rewrite or redundant write strategy on the same medium can be triggered to further ensure the quality of emergency protection.

[0355] In step S1505, after writing to the non-volatile storage medium is completed, the emergency storage identifier is updated, and the power failure protection recording unit is marked as alarm record data for which protection writing has been completed, thereby realizing the safe transfer of non-persistent alarm record data in the device cache layer to the non-volatile storage medium. The emergency protection completion flag is defined as:

[0356]

[0357] in, Indicates the first The protection completion mark in the power outage protection record; This indicates the threshold for successful emergency write operations. When... When this occurs, it indicates that the record has been reliably written to the non-volatile storage medium and can be marked as having completed the protection write. Therefore, the result of the secure transfer of the target structured alarm record data in the device cache layer can be represented as:

[0358]

[0359] in, This represents the data set for which power outage protection has been successfully written. Furthermore, the coverage rate of this round of emergency protection can be defined:

[0360]

[0361] in, This indicates the percentage of non-persistent target data successfully protected and written under the current abnormal scenario. This metric can be used to audit the protection effectiveness of the emergency write mechanism after system recovery, and to provide a basis for subsequent threshold optimization, priority model correction, and storage resource configuration.

[0362] After completing step S1503, proceed to step S1504. In this step, the structured alarm record data and its corresponding integrity check value in the emergency write data sequence are written to a non-volatile storage medium. During the writing process, a corresponding emergency storage identifier and time index information are generated for each structured alarm record data to form a power outage protection recording unit. The technical focus of this step is that the writing result is not a simple data copy, but a power outage protection recording unit with independent identification and rapid recovery capabilities. The first... The emergency storage identifier corresponding to each record is:

[0363]

[0364] in, Indicates the first Emergency storage identifier for each record; Indicates the record number; Represents a timestamp; Indicates the integrity check value; This indicates the current emergency write round identifier. Simultaneously, time index information can be generated:

[0365]

[0366] in, This indicates the corresponding emergency time index information; This represents a time index mapping function. This allows the formation of a power outage protection recording unit:

[0367]

[0368] in, This indicates a power failure protection recording unit. To further enhance the inventiveness of this embodiment, an emergency write success rate can be defined:

[0369]

[0370] in, Indicates the first Success rate of emergency write to power outage protection records; Indicates the current availability or health status of non-volatile storage media; This indicates the stability of the current emergency write path; This indicates the consistency index after write verification; For weighting coefficients. When When the value is below the threshold, a backup block rewrite or redundant write strategy on the same medium can be triggered to further ensure the quality of emergency protection.

[0371] In step S1505, after writing to the non-volatile storage medium is completed, the emergency storage identifier is updated, and the power failure protection recording unit is marked as alarm record data for which protection writing has been completed, thereby realizing the safe transfer of non-persistent alarm record data in the device cache layer to the non-volatile storage medium. The emergency protection completion flag can be defined as:

[0372]

[0373] in, Indicates the first The protection completion mark in the power outage protection record; This indicates the threshold for successful emergency write operations. When... When this occurs, it indicates that the record has been reliably written to the non-volatile storage medium and can be marked as having completed the protection write. Therefore, the result of the secure transfer of the target structured alarm record data in the device cache layer can be represented as:

[0374]

[0375] in, This represents the data set for which power outage protection has been successfully written. Furthermore, the coverage rate of this round of emergency protection can be defined:

[0376]

[0377] in, This indicates the percentage of non-persistent target data successfully protected and written under the current abnormal scenario. This metric can be used to audit the protection effectiveness of the emergency write mechanism after system recovery, and to provide a basis for subsequent threshold optimization, priority model correction, and storage resource configuration.

[0378] like Figure 10 As shown, this application proposes a multi-level security recording system 10 for alarm information, used to execute the multi-level security recording method for alarm information described in the first aspect, including:

[0379] The generation unit 101 is used to collect alarm event information generated by the alarm in real time through the alarm host, and to encapsulate the alarm event information, operation log information and zone status change information in a unified manner to generate structured alarm record data, wherein the structured alarm record data includes timestamp, device identifier and event type identifier.

[0380] The first writing unit 102 is used to build a chain-like secure storage structure locally on the alarm host, associate the current alarm record data with the verification value of the previous alarm record data to generate the integrity verification value of the current alarm record, and write it to the local anti-tampering storage area in chronological order.

[0381] The second writing unit 103 is used to establish a hierarchical storage mechanism in the alarm host and write the structured alarm record data into the device cache layer and the local persistent storage layer respectively.

[0382] The synchronization unit 104 is used to synchronize the structured alarm record data and the corresponding integrity verification value stored in the local anti-tampering storage area to the cloud server when the network connection is detected to be restored, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data.

[0383] The third write unit 105 is used to trigger an emergency write mechanism when a power supply abnormality or system abnormality is detected, and to write the non-persistent alarm record data in the cache to a non-volatile storage medium.

[0384] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A multi-level security recording method for alarm information, characterized in that, include: The alarm host collects alarm event information in real time and encapsulates the alarm event information, operation log information and zone status change information in a unified manner to generate structured alarm record data. The structured alarm record data includes timestamp, device identifier and event type identifier. A chain-like secure storage structure is built locally on the alarm host. The verification value of the current alarm record data is associated with the verification value of the previous alarm record data to generate the integrity verification value of the current alarm record, and then written to the local anti-tampering storage area in chronological order. A hierarchical storage mechanism is established in the alarm host to write the structured alarm record data into the device cache layer and the local persistent storage layer, respectively. The step of establishing a hierarchical storage mechanism on the alarm host side, and writing the structured alarm record data into the device cache layer and the local persistent storage layer respectively, includes: receiving the structured alarm record data bound by the integrity check value, and first writing the structured alarm record data into the device cache layer of the alarm host to form an alarm record cache queue arranged in chronological order; after the structured alarm record data is written into the device cache layer, monitoring the cache status of the alarm record cache queue, and dynamically scheduling the alarm record cache queue according to a preset cache capacity threshold, alarm event triggering frequency, and system operating status to determine the target structured alarm record data that needs to be persistently written; performing persistent writing processing on the target structured alarm record data, writing the target structured alarm record data and its corresponding integrity check value into the local persistent storage layer of the alarm host, and generating corresponding storage address identifiers and time index information during the writing process to establish a persistent index structure for the structured alarm record data; When network connection is detected to be restored, the structured alarm record data and the corresponding integrity verification value stored in the local anti-tampering storage area are synchronized to the cloud server, and the cloud server performs integrity verification and distributed redundant backup storage on the structured alarm record data. When a power supply or system anomaly is detected, an emergency write mechanism is triggered to write the non-persistent alarm record data in the cache to a non-volatile storage medium.

2. The multi-level security recording method for alarm information according to claim 1, characterized in that, The alarm host collects alarm event information in real time, and encapsulates the alarm event information, operation log information, and zone status change information into structured alarm record data, including: The alarm host receives alarm trigger signals from alarm devices and performs event parsing on the alarm trigger signals to extract event type parameters, trigger zone identifiers, and event trigger time information from the alarm event information. The alarm event information is associated and matched with the operation log information generated inside the alarm host and the real-time acquired zone status change information to form an event association dataset describing the same alarm process. The event-related dataset is subjected to field standardization and format unification processing to generate an original alarm record data structure including timestamp field, device identifier field, zone identifier field, event type field, and status change field; Based on preset data encapsulation rules, the original alarm record data structure is serialized and encapsulated. During the encapsulation process, an event sequence number identifier and a record version identifier are added to the original alarm record data structure to generate the structured alarm record data.

3. The multi-level security recording method for alarm information according to claim 1, characterized in that, The step involves constructing a chain-like secure storage structure locally on the alarm host, associating the current alarm record data with the verification value of the previous alarm record to generate an integrity verification value for the current alarm record, and writing it to the local tamper-proof storage area in chronological order, including: After receiving the structured alarm record data, the alarm host assigns a sequentially increasing record number to the structured alarm record data and obtains the verification value corresponding to the previous alarm record as a chain association parameter. The current structured alarm record data, the record number, the timestamp, and the verification value corresponding to the previous alarm record are combined to construct a data calculation unit to be verified. A hash operation is performed on the data calculation unit to generate an integrity verification value corresponding to the current structured alarm record data, so that a continuous verification association relationship is formed between the current alarm record and the previous alarm record, thereby constructing the chain-like secure storage structure. The current structured alarm record data is bound and encapsulated with the integrity verification value to generate a chained alarm record data block, and the chained alarm record data block is written into the local anti-tamper storage area of ​​the alarm host in chronological order.

4. The multi-level security recording method for alarm information according to claim 1, characterized in that, The step of establishing a hierarchical storage mechanism on the alarm host side, and writing the structured alarm record data into the device cache layer and the local persistent storage layer respectively, further includes: After the local persistent storage layer is written, a cache status update operation is performed on the target structured alarm record data in the device cache layer to release the data cache space that has been persistently written and retain the data that has not been written.

5. The multi-level security recording method for alarm information according to claim 4, characterized in that, After the structured alarm record data is written to the device cache layer, the cache status of the alarm record cache queue is monitored, and the alarm record cache queue is dynamically scheduled according to a preset cache capacity threshold, alarm event triggering frequency, and system operating status to determine the target structured alarm record data that needs to be persistently written, including: After the structured alarm record data is written into the device cache layer and forms the alarm record cache queue, the cache capacity occupancy status of the alarm record cache queue is monitored in real time to obtain the current cache occupancy ratio information. After obtaining the cache occupancy ratio information, the alarm event triggering frequency within a preset time window is statistically analyzed, and a cache scheduling evaluation parameter set is constructed in conjunction with the system operation status information of the alarm host. Based on the cache scheduling evaluation parameter set, priority evaluation processing is performed on the structured alarm record data in the alarm record cache queue to generate a cache scheduling priority value corresponding to each structured alarm record data. Based on the respective cache scheduling priority values, the alarm record cache queue is sorted, and the structured alarm record data with a priority higher than a preset threshold is selected from the alarm record cache queue and determined as the target structured alarm record data. The target structured alarm record data is written to the local persistent storage layer.

6. The multi-level security recording method for alarm information according to claim 4, characterized in that, The persistent writing process for the target structured alarm record data involves writing the target structured alarm record data and its corresponding integrity check value into the local persistent storage layer of the alarm host, and generating corresponding storage address identifiers and time index information during the writing process to establish a persistent index structure for the structured alarm record data, including: After receiving the target structured alarm record data, the target structured alarm record data and its corresponding integrity verification value are prepared for writing, and a unique data writing identifier is generated for each target structured alarm record data. Based on the data write identifier, the target structured alarm record data and the integrity verification value are written to the local persistent storage layer of the alarm host in chronological order, and the corresponding data storage address information is recorded during the writing process. After the target structured alarm record data is written, corresponding time index information is generated according to the data storage address information, and the time index information is associated with the data writing identifier to form an index mapping relationship for the structured alarm record data. Write the index mapping relationship into a preset alarm record index table, and establish a persistent index structure for the structured alarm record data based on the alarm record index table; The persistent index structure enables rapid location and access to the target structured alarm record data, thereby completing the process of writing the structured alarm record data into the local persistent storage layer and establishing a persistent index structure.

7. The multi-level security recording method for alarm information according to claim 1, characterized in that, When network connectivity is detected to be restored, the structured alarm record data and the corresponding integrity verification value stored in the local tamper-proof storage area are synchronized to the cloud server, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data, including: After detecting that the network connection status of the alarm host has been restored from the disconnected state to the communicable state, the alarm host first scans the structured alarm record data in the local anti-tamper storage area and determines the target structured alarm record data set that has not yet been synchronized with the cloud. The structured alarm record data and the corresponding integrity verification value in the target structured alarm record data set are batch packaged, and corresponding synchronization batch identifier and data digest information are generated during the packaging process to form a data synchronization package to be synchronized; The data synchronization packet is sent to the cloud server through a secure communication channel established between the alarm host and the cloud server, and the cloud server receives the structured alarm record data and the integrity verification value in the data synchronization packet. After receiving the data synchronization packet, the cloud server performs integrity verification on the structured alarm record data. By recalculating the verification value of the structured alarm record data and comparing it with the integrity verification value, the integrity and consistency of the structured alarm record data during transmission are confirmed. After the integrity verification is passed, the structured alarm record data is written to multiple cloud storage nodes according to a preset distributed redundancy strategy, and corresponding data backup identifiers and synchronization confirmation information are generated and returned to the alarm host to complete the synchronization of structured alarm record data to the cloud server and perform integrity verification and redundant backup storage.

8. The multi-level security recording method for alarm information according to claim 1, characterized in that, The emergency write mechanism, triggered when a power supply or system anomaly is detected, writes non-persistent alarm record data from the cache to a non-volatile storage medium, including: During the operation of the alarm host, the power supply status and system operation status of the alarm host are monitored in real time. When the power supply voltage is detected to be lower than the preset safety threshold or the system operation status is abnormal, an abnormal trigger signal is generated and an emergency writing mechanism is activated. After the emergency write mechanism is activated, the structured alarm record data in the device cache layer is scanned and identified, and the target set of structured alarm record data that has not yet been written to the local persistent storage layer is determined. The structured alarm record data and its corresponding integrity verification value in the target structured alarm record data set are prioritized and sorted, and an emergency write data sequence is generated in chronological order. The structured alarm record data and its corresponding integrity verification value in the emergency write data sequence are written into a non-volatile storage medium, and during the writing process, a corresponding emergency storage identifier and time index information are generated for each structured alarm record data to form a power failure protection record unit. After the non-volatile storage medium is written, the emergency storage identifier is updated and the power failure protection recording unit is marked as alarm record data that has been written for protection, so as to realize the safe transfer of non-persistent alarm record data in the device cache layer to the non-volatile storage medium.

9. The multi-level security recording method for alarm information according to claim 8, characterized in that, The step of prioritizing and sorting the structured alarm record data and its corresponding integrity verification value in the target structured alarm record data set, and generating an emergency write data sequence in chronological order, includes: After determining the target structured alarm record data set, the event type information, trigger zone identifier, timestamp information, and integrity verification value corresponding to each structured alarm record data in the target structured alarm record data set are extracted to form an emergency dispatch parameter set. Based on the set of emergency dispatch parameters, the corresponding emergency write priority value is calculated for each of the structured alarm record data, wherein the emergency write priority value is determined by the severity of the alarm event, the time of the event, and the risk level of the defense zone. The target structured alarm record data set is sorted according to the emergency write priority value to generate a priority sorting list, and data with the same priority are arranged in chronological order during the sorting process. According to the priority sorting list, the sorted structured alarm record data and its corresponding integrity verification value are combined in sequence to generate an emergency write data sequence arranged in chronological order. The structured alarm record data and its corresponding integrity check value in the generated emergency write data sequence are written to a non-volatile storage medium for emergency write processing in the event of a power outage.

10. A multi-level security recording system for alarm information, used to execute the multi-level security recording method for alarm information as described in any one of claims 1 to 9, characterized in that, include: The generation unit is used to collect alarm event information generated by the alarm in real time through the alarm host, and to encapsulate the alarm event information, operation log information and zone status change information in a unified manner to generate structured alarm record data, wherein the structured alarm record data includes timestamp, device identifier and event type identifier; The first writing unit is used to build a chain-like secure storage structure on the local side of the alarm host, associate the current alarm record data with the verification value of the previous alarm record data to generate the integrity verification value of the current alarm record, and write it to the local anti-tampering storage area in chronological order. The second writing unit is used to establish a hierarchical storage mechanism in the alarm host and write the structured alarm record data into the device cache layer and the local persistent storage layer respectively. The synchronization unit is used to synchronize the structured alarm record data stored in the local anti-tamper storage area and the corresponding integrity verification value to the cloud server when the network connection is detected to be restored, and the cloud server performs integrity verification and redundant backup storage on the structured alarm record data. The third write unit is used to trigger an emergency write mechanism when a power supply abnormality or system abnormality is detected, and to write the non-persistent alarm record data in the cache to a non-volatile storage medium.

Images