A data linkage analysis method for intelligent park abnormal working condition positioning

Abstract

This invention discloses a data linkage analysis method for locating abnormal operating conditions in smart parks, specifically relating to the field of data linkage analysis technology. The method includes collecting, sorting by time, and regularizing the operation log data and status data generated by various business applications within the park to form an operation data sequence; parsing the call relationship of the operation data sequence, matching trigger events with corresponding response events one by one, and calculating the response time and state change direction during the matching process to form a linkage record sequence; performing group statistics on the linkage record sequence within a historical operation window, calculating the stable response time interval and stable state change direction for the same trigger event and response application combination, and constructing the expected linkage structure between applications; transforming the implicit operational expectations between systems into a computable linkage structure within an industrial data analysis framework, and locating the abnormal source based on the time and propagation characteristics of linkage deviation.

Description

Technical Field

[0001] This invention relates to the field of data linkage analysis technology, and more specifically, to a data linkage analysis method for locating abnormal operating conditions in smart parks. Background Technology

[0002] In existing smart park operation and management technologies, the overall operation of the park is usually formed by the collaboration of multiple functional systems, including energy consumption management, equipment operation, scheduling control, and security protection. Each system operates independently based on its own business objectives and control logic, and achieves linkage through data interfaces. Within this technical framework, industrial data analysis mainly revolves around the data stability, indicator rationality, and rule compliance within a single system. The default premise is that the operational behavior of each system maintains a predetermined cooperative relationship in terms of time, frequency, and response mode. That is, each system has an implicit and stable expected dependency on the behavior of other systems. For example, it is assumed that load changes are continuous, control commands can be executed at the expected rhythm, and environmental state changes will not be frequently reversed. However, as the park expands, operational strategies are dynamically adjusted, and external environmental disturbances intensify, the expected dependencies between these systems may gradually fail without producing obvious numerical anomalies. Each system still outputs data and decision results that conform to its own rules, but its behavior no longer meets the implicit operational premises of other systems, leading to unpredictable or even uncontrollable abnormal operating conditions in the overall operation of the park. It is evident that existing technologies only analyze data from single systems and lack the ability to characterize and verify whether the expected relationships between systems continue to hold. As a result, they cannot identify and locate anomalies caused by the failure of expected dependencies. This contradiction between the invisible expectations between systems but the inevitable failure constitutes the core problem in the location of abnormal operating conditions in smart parks. Summary of the Invention

[0003] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a data linkage analysis method for locating abnormal operating conditions in smart parks. This method transforms implicit operational expectations between systems into a computable linkage structure within an industrial data analysis framework, and locates the abnormal source based on the time and propagation characteristics of linkage deviation.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a data linkage analysis method for locating abnormal operating conditions in smart parks, comprising: S1. Collect, sort by time, and normalize the operation log data and status data generated by various business applications within the park to form an operation data sequence arranged by application identifier and occurrence order; S2. Perform call relationship parsing on the running data sequence, match the triggering event with the corresponding response event one by one, and calculate the response time and state change direction during the matching process to form a linkage record sequence to describe the application linkage behavior; S3. Perform group statistics on the linkage record sequence within the historical operation window, calculate the stable response time interval and stable state change direction for the same trigger event and response application combination, and construct the expected linkage structure between applications. S4. Compare the real-time generated linkage records with the expected linkage structure between applications item by item to determine whether the response time exceeds the stable response time range and whether the state change direction deviates from the stable state change direction. Then, aggregate the linkage relationships that deviate continuously to form the expected failure linkage structure. S5. Perform reverse tracing and forward propagation calculations along the calling relationship for the expected failure linkage structure, and count the time and location of the first failure record of each application in the expected failure linkage structure and the subsequent propagation range. Based on the time and location and the propagation range, solve the abnormal source application and the corresponding propagation link, and output the abnormal source application and the propagation link as the location result of the abnormal working condition of the smart park.

[0005] In a preferred embodiment, S1 includes: S1-1. Read the operation log data and status data at the data collection endpoints corresponding to each business application, and uniformly add application identifiers and collection time stamps to the read data to form the original operation dataset; S1-2. Perform global time sorting on the original running dataset according to the collection time mark. Specifically, this includes: using the collection time mark as the sorting key, performing unified time axis rearrangement on data records from different business applications, and performing secondary sorting on data records with time mark conflicts according to the application identifier during the sorting process, thereby eliminating the data time offset between different business applications and forming a time-aligned data sequence. S1-3. Perform field mapping and field pruning on time-aligned data sequences. Specifically, this includes mapping semantically consistent running fields in different business applications to unified field names based on pre-established field correspondences, pruning fields that are irrelevant to the running linkage analysis after mapping, and outputting running data sequences arranged by application identifier and occurrence order for consistency processing of cross-application running data in industrial data analysis.

[0006] In a preferred embodiment, S2 includes: S2-1. For each data record in the running data sequence, read the call identifier, application identifier, event type and occurrence time in sequence. Use the call identifier as the grouping key to write the data record into the corresponding grouping container. In each grouping container, assign the sequential number in the running data sequence to each data record as the record position identifier. Then sort the record position identifiers according to the occurrence time to build a call index table containing an ordered sequence of call identifiers and their corresponding record position identifiers. S2-2. Scan the ordered sequence of record position identifiers corresponding to each call identifier in the call index table one by one in sorted order. For each scanned data record, determine whether it belongs to a trigger event based on whether the event type of the data record is consistent with any event type in the predefined set of trigger event types. When a trigger event is determined, the application identifier read from the data record is used as the trigger application identifier, and the trigger application identifier and the time of occurrence are written into the trigger stack to form a scan sequence with trigger stack state; S2-3. In the scan sequence, when a scanned data record is determined to have an event type that matches any event type in the predefined set of response event types, the following pairing confirmation process is executed: Read the most recently written trigger record that has not been marked as paired from the trigger stack. Read the call identifier in the trigger record and compare it with the call identifier in the current response record. When they match, mark the trigger record and the current response record as paired, forming a pairing record of trigger event and response event and output it.

[0007] In a preferred embodiment, S2 further includes: S2-4. Read the occurrence time of the trigger event and the occurrence time of the response event for the paired records respectively. Calculate the time difference between the two events to solve the time interval between the occurrence time of the response event and the occurrence time of the trigger event, and output the response time consumption. S2-5. For the triggering event in the paired record, retrieve the most recent state data that occurred before the time the triggering event occurred by moving forward along the running data sequence, and use it as the state value before triggering. For a response event in a paired record, retrieve the most recent state data that occurred after the time the response event occurred along the running data sequence, and use it as the post-response state value; Perform differential calculation on the state value before triggering and the state value after response, determine the direction of state change based on the positive or negative sign of the differential result, and output the direction of state change; S2-6. For multiple paired records generated under the same call identifier, sort them according to the time of occurrence of the response event. When multiple paired records corresponding to the same response event are detected, determine whether the response time of each paired record falls between the preset lower limit and the preset upper limit of the time. Among the paired records that meet the conditions, select the time interval between the time of occurrence of the trigger event and the time of occurrence of the response event. Paired records that fall within the range of the preset lower limit and the preset upper limit of the time interval are taken as valid records. Output the set of paired records after conflict resolution. S2-7. For each pairing record in the pairing record set after conflict resolution, read: the triggering application identifier read from the triggering event data record, the response application identifier read from the response event data record, the triggering event type read from the triggering event data record, the response event type read from the response event data record, and the response time and state change direction corresponding to the pairing record. Write the linked record field set sequentially according to the preset field order to form a linked record. Output a linked record sequence to describe the linked behavior of the application, which can be used for the calculation and modeling of the linkage characteristics between applications in the process of industrial data analysis.

[0008] In a preferred embodiment, S3 includes: S3-1. In the historical operation window, read the trigger event type, response application identifier, response time and state change direction of each linkage record sequence, and write the linkage record into the corresponding group set using the combination of trigger event type and response application identifier as the group key. S3-2. Sort the response times in each group set according to their numerical values ​​to obtain an ordered sequence of response times. Using an ordered response time sequence as input, the difference between adjacent response times is scanned sequentially along the numerical axis. When the adjacent difference does not exceed the preset time interval threshold, the corresponding response times are assigned to the same candidate interval. For each candidate interval, count the number of response times it contains. When the number of response times reaches the preset lower limit of occurrence, take the lower limit of response time in the candidate interval as the lower limit of the stable response time interval, and take the upper limit of response time in the candidate interval as the upper limit of the stable response time interval, so as to solve the stable response time interval corresponding to the group. S3-3. Perform frequency statistics on the state change directions in each group set, calculate the number of times each state change direction appears in the group, and select the state change directions whose occurrence count falls into the preset direction consistency lower limit as the stable state change directions to be output. S3-4. Combine the fields corresponding to the group key, such as the trigger event type, response application identifier, stable response time interval, and stable state change direction, to form an expected linkage record. S3-5. Collect all expected linkage records generated within the historical operation window and construct an inter-application expected linkage structure containing multiple expected linkage records for use in operational behavior benchmark modeling in industrial data analysis.

[0009] In a preferred embodiment, S4 includes: S4-1. For each linkage record generated in real time, read the trigger event type, response application identifier, response time and state change direction, and use the combination of the trigger event type and response application identifier as the index key to locate the corresponding expected linkage record in the expected linkage structure between applications. S4-2. Read the lower and upper limits of the stable response time interval for the located expected linkage record, and perform interval determination by comparing the response time in the linkage record with the corresponding lower and upper limits. When the response time is less than the lower limit of the stable response time interval or greater than the upper limit of the stable response time interval, the output response time deviation judgment result is "deviation"; otherwise, the output response time deviation judgment result is "no deviation". S4-3. Read the stable state change direction of the located expected linkage record, and perform a consistency judgment between the state change direction in the linkage record and the corresponding stable state change direction. When the direction of state change in the linkage record is not equal to the direction of stable state change, the output state direction deviation judgment result is "deviation"; otherwise, the output state direction deviation judgment result is "no deviation".

[0010] In a preferred embodiment, S4 further includes: S4-4. Perform a joint judgment on the response time deviation judgment result and the state direction deviation judgment result. When the response time deviation judgment result is a deviation or the state direction deviation judgment result is a deviation, mark the corresponding linkage record as a failed linkage record and write it into the failure buffer sequence. When both judgment results are not a deviation, do not write the linkage record into the failure buffer sequence. S4-5. Perform aggregation statistics on the failure buffer sequence within a preset continuous time window. When the number of failure linkage records corresponding to the same index key reaches the preset lower limit of the number of failures, generate the corresponding failure linkage entry. S4-6. Write the generated failure linkage entries into the failure linkage set according to the index key, failure time window and failure count, and aggregate them to form the expected failure linkage structure, so as to identify and aggregate the deviation behavior of the operation linkage in the process of industrial data analysis; where the failure time window refers to the preset continuous time window corresponding to the failure linkage entry.

[0011] In a preferred embodiment, S5 includes: S5-1. Take each failure linkage entry in the expected failure linkage structure as input and read its index key, failure time window and failure count. Based on the index key, in the call relationship obtained by parsing the running data sequence, the triggering application node corresponding to the triggering event and the response application node corresponding to the response application identifier are located, and the response application node is used as the failure starting point node and aggregated to form a failure starting point set. S5-2. For each failure starting point node in the failure starting point set, perform a reverse traversal along the calling relationship and visit its upstream calling nodes level by level. During the traversal, for each accessed calling node, the failure linkage entry associated with that node is read, and the start time of the failure time window of that failure linkage entry is taken as the failure time position of that calling node, and the results are collected to form a reverse tracing result set. S5-3. For each calling node in the reverse tracing result set, perform a forward traversal along the calling relationship and visit its downstream calling nodes level by level. During the forward traversal, the number of failed linkage entries associated with the downstream calling nodes that are visited is counted, and the number is used as the propagation range corresponding to the calling node, which is then aggregated to form a forward propagation result set.

[0012] In a preferred embodiment, S5 further includes: S5-4. Perform joint computation on the reverse tracing result set and the forward propagation result set, specifically including: For each calling node, read its corresponding failure time location and propagation range. When the failure time location of the calling node is earlier than the failure time locations of all its downstream calling nodes, and its propagation range reaches the preset propagation quantity lower limit, the calling node is identified as the abnormal source application, thereby solving the abnormal source application. S5-5. Starting with the abnormal source application, connect its upstream path in the reverse tracing result set and its downstream path in the forward propagation result set to form a complete propagation link corresponding to the abnormal source application. S5-6. The solution of the abnormal source application and its corresponding propagation link is output as the location result of the abnormal working condition in the smart park, so as to be used for tracing the cause of the abnormal working condition and analyzing the impact path in the industrial data analysis scenario.

[0013] The technical effects and advantages of this invention are as follows: 1. This solution explicitly depicts the implicit expected operational relationships between systems by pairing and modeling cross-application trigger events and response events and constructing expected linkage structures. This enables the identification of overall abnormal operating conditions in the park where expected dependency failures have occurred even though no single system numerical anomalies have occurred. This directly solves the problem that existing technologies cannot detect expected failures between systems. 2. Within the historical operating window, statistically analyze the stable response time interval and the direction of stable state change to establish a calculable long-term operating benchmark for inter-application linkage behavior. This enables real-time industrial data analysis to no longer rely on fixed thresholds or empirical assumptions, but to adaptively judge whether the linkage has deviated substantially based on historical behavior. 3. The real-time linkage records are compared with the expected linkage structure item by item, and failure aggregation judgment within a continuous time window is introduced to effectively distinguish between occasional fluctuations and continuous linkage failures, thereby reducing the probability of misjudgment caused by instantaneous anomalies within a certain range and improving the stability of anomaly identification results. 4. Simultaneously perform reverse tracing and forward propagation calculations on the expected failure linkage structure, and combine the time and location of the first occurrence of failure with the propagation range to achieve a structured judgment of the application of the abnormal source, avoiding the positioning deviation caused by positioning based solely on the intensity or frequency of the abnormality; and use the application of the abnormal source and its corresponding propagation link as a unified output result, so that the cause analysis and impact range assessment of abnormal working conditions can be completed in the same data structure, which helps to understand the overall impact path of abnormal decision-making and subsequent handling in industrial data analysis scenarios. Attached Figure Description

[0014] Figure 1 This is a flowchart outlining the method steps of the present invention. Detailed Implementation

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

[0016] Refer to the instruction manual appendix Figure 1 An embodiment of the present invention provides a data linkage analysis method for locating abnormal operating conditions in a smart park, comprising: S1. Collect, sort by time, and standardize the operation log data and status data generated by various business applications in the park to form an operation data sequence; S1 includes: In this embodiment, addressing the issues of scattered sources, inconsistent time bases, and significant differences in field semantics among the operation log data and status data generated during the operation of multiple business applications within a smart park, the original operation data is uniformly collected, time-aligned, and field-normalized. This transforms the multi-source operation data into a data foundation that can be directly used for subsequent industrial data analysis, thereby providing consistent data input conditions for analyzing inter-application linkages and locating abnormal operating conditions. The implementation process includes the following steps: First, the raw operational data is collected and labeled to ensure that the data generated by different business applications is distinguishable and traceable in subsequent processing. In this step, the system reads operation log data and status data from the data collection endpoints corresponding to each business application as input. The operation log data includes event trigger records, call records, etc., and the status data includes application operation status values, resource status values, etc. During the reading process, application source identification is performed on each data record, and the unique identifier of the corresponding business application is written into the data record. At the same time, the data generation time or collection time is read and written as a collection timestamp. When a data record is missing a collection timestamp, the receiving time is written as a substitute timestamp according to preset rules. After the above processing, the data records with the application identifier and collection timestamp are collected to form the original operation dataset, and the original operation dataset is written into the cache area for the next step to read. Secondly, perform global time sorting processing on the raw running data to eliminate time misalignment between different business applications caused by clock deviation or acquisition delay; In this step, the original running dataset is used as input. The collection timestamp in each data record is read, and the collection timestamp is used as the primary sorting key to perform a unified timeline rearrangement on the data records from different business applications. When multiple data records have the same collection timestamp, their application identifiers are further read as secondary sorting keys to perform secondary sorting on the data records, thereby ensuring the determinism of the sorting results. Through the above sorting operations, the original running dataset is converted into a data sequence arranged in chronological order. When it is detected that a certain business application has no data records within a continuous time period, no interpolation processing is performed on that time period; instead, the timeline continuity identifier is maintained. Finally, a time-aligned data sequence is output and written to the data buffer for subsequent field normalization steps. Then, field mapping and field pruning of time-aligned data sequences are performed to unify the data semantics across different business applications and reduce the complexity of subsequent analysis. In this step, using time-aligned data sequences as input, a pre-established field mapping table is first read. This table, generated by business rule configuration, describes the correspondence between semantically consistent running fields in different business applications. Based on the field mapping table, a field mapping operation is performed on each data record in the time-aligned data sequence, converting semantically consistent running fields from different sources into unified field names. After field mapping, field pruning is performed on the data records, specifically deleting fields that do not participate in application linkage analysis and retaining only necessary fields for subsequent linkage parsing, time consumption calculation, and state change determination. When a data record is missing a necessary field after field mapping, it is marked as an unanalyzable record and removed from the output sequence. Finally, the output forms a running data sequence arranged by application identifier and occurrence order, and this running data sequence is written to the analysis data area for consistency processing of cross-application running data during industrial data analysis. Through the above implementation process, unified processing of multi-business application operation data in the collection stage, time dimension and field semantic level was achieved, effectively eliminating the interference caused by differences in data sources, time offset and inconsistent field expression between different business applications, and providing a stable and reusable data foundation for subsequent construction of inter-application linkage relationship, analysis of expected linkage structure and abnormal working condition location. In practical applications, such as in smart park scenarios that include energy management applications, security management applications, and equipment monitoring applications, after processing through the above embodiments, the operational data generated by each application can be jointly analyzed under the same timeline and unified field semantics, thereby providing reliable input for the accurate identification of application linkage behavior and abnormal propagation paths in subsequent industrial data analysis tasks. S2. Perform call relationship parsing on the running data sequence, match the triggering event with the corresponding response event one by one, and calculate the response time and state change direction during the matching process to form a linkage record sequence; S2 includes: In this embodiment, addressing the challenges of complex call relationships between various business applications in a smart park, concurrent and overlapping event triggering and responses, and difficulty in directly identifying true linkage relationships, the scattered operational events are transformed into a structured linkage record sequence by performing call relationship parsing, event pairing, and time consumption and state change calculations on the operational data sequence. This provides foundational data for modeling and anomaly identification of operational linkage characteristics between applications in subsequent industrial data analysis. The implementation process includes the following steps: First, by constructing a call index table, data records belonging to the same call chain in the running data sequence are organized into a sequentially traversable structure to support subsequent event scanning and pairing; In this step, the running data sequence is used as input, and the call identifier, application identifier, event type, and occurrence time of each data record are read sequentially. Using the call identifier as a grouping key, the data records are written to the corresponding grouping containers, and each data record is assigned its sequential number in the running data sequence as a record position identifier during writing. Within each grouping container, the occurrence time of the data record is read, and the record position identifiers are sorted to form an ordered sequence of record position identifiers arranged chronologically. When a call identifier corresponds to only a single data record, an ordered sequence containing only one record position identifier is still generated. Finally, a call index table containing the call identifiers and their corresponding ordered sequences of record position identifiers is constructed and written into a memory structure for the next step to read. Secondly, by performing a sequential scan of the call index table, the triggering events in the call chain are identified and the trigger stack state is maintained, providing candidate triggering contexts for subsequent response event pairing; In this step, the call index table is used as input. The ordered sequence of record position identifiers corresponding to each call identifier is scanned sequentially to locate the corresponding data record in the running data sequence. For each scanned data record, its event type is read and matched against a pre-configured set of trigger event types, provided by the business rule configuration file. When the data record is determined to be a trigger event, the application identifier in the data record is read as the trigger application identifier, and its occurrence time is also read. The trigger application identifier and occurrence time are written to the trigger stack. When the data record is not a trigger event, no write operation is performed on the trigger stack. After the above processing, a scan sequence carrying the dynamic state of the trigger stack is formed and passed to the next step. Then, by identifying response events and performing trigger-response pairing confirmation during the scanning process, the basic unit of event-level linkage is established; In this step, for each data record scanned in the scan sequence, its event type is read and matched against a pre-configured set of response event types, which is also provided by the business rule configuration file. When the current data record is determined to be a response event, the most recently written trigger record that has not yet been marked as paired is read from the trigger stack, and the call identifier in both the trigger record and the current response record is read. When the call identifiers match, both the trigger record and the current response record are marked as paired, and they are combined to form a pairing record of trigger event and response event. When the call identifiers do not match, the pairing operation is not performed and scanning continues. The paired record is written as an output to the pairing record set for subsequent calculation steps. Next, by performing time difference calculation on the paired records, the timing relationship between the triggering event and the response event is quantified.

[0017] In this step, the set of paired records is used as input. For each paired record, the occurrence time of the trigger event and the occurrence time of the response event are read, and the time difference between the two is calculated to obtain the time interval between the occurrence time of the response event and the occurrence time of the trigger event. If the occurrence time of the response event is earlier than the occurrence time of the trigger event, the paired record is marked as invalid and removed from the subsequent processing flow. For valid paired records, the calculated time interval is written as the response time consumption and written into the paired record to form an updated set of paired records carrying response time consumption information. Subsequently, by performing differential calculations on the state data before and after the trigger, the direction of state change during the trigger-response process is identified; In this step, the updated set of paired records is used as input. For each paired record, the time of the trigger event is read, and the state data record closest to that time is retrieved forward along the running data sequence. Its state value is read as the pre-trigger state value. At the same time, the time of the response event is read, and the state data record closest to that time is retrieved backward along the running data sequence. Its state value is read as the post-response state value. When no state data is retrieved in either direction, the paired record is marked as a state undeterminable record. For paired records with determinable states, a difference calculation is performed between the post-response state value and the pre-trigger state value. The direction of state change is determined based on whether the difference result is positive or negative. The direction of state change is written into the paired record, forming a set of paired records containing state change information. Then, valid matching records are filtered through conflict resolution rules to eliminate ambiguity caused by multiple triggering events corresponding to the same response event; In this step, a set of paired records containing response time and state change direction is used as input. Paired records under the same call identifier are sorted according to the time of the response event. When multiple trigger event paired records are detected corresponding to the same response event, the response time of each paired record is read and it is determined whether it falls within the effective time interval formed by the system's preset lower and upper time limits, which are estimated from historical statistics. Among the paired records that meet the time limit conditions, it is further determined whether the time interval between the trigger event time and the response event time falls within the preset lower and upper time interval limits. Only when both conditions are met simultaneously is the paired record retained as a valid record, and the remaining paired records are discarded. Finally, the set of paired records after conflict resolution is output. Finally, by performing field combinations on the effective paired records, a linked record sequence that can be directly used for industrial data analysis is formed; In this step, the set of paired records after conflict resolution is used as input. For each paired record, the triggering application identifier from the triggering event data record, the response application identifier from the response event data record, the triggering event type, the response event type, and the response time and state change direction corresponding to the paired record are read. The fields are written into the linkage record field set in a preset field order to form a structured linkage record. All linkage records are collected to form a linkage record sequence, and the linkage record sequence is output for the calculation and modeling of the linkage characteristics between applications in the process of industrial data analysis. Through the above embodiments, the running events that were originally scattered across multiple business applications are transformed into a sequence of linked records with clear trigger-response relationships, response times, and state change directions, thereby realizing a computable expression of the running linkage behavior between applications. In practical applications, such as scenarios where energy management applications in smart parks trigger load adjustment events and equipment monitoring applications generate status response events, the linkage record sequence generated by this embodiment can be used as input to an industrial data analysis model to identify abnormal linkage time, abnormal state change direction, and subsequent abnormal operating condition propagation path analysis and location. S3. Perform group statistics on the linkage record sequence within the historical operation window, calculate the stable response time interval and stable state change direction for the same trigger event and response application combination, and construct the expected linkage structure between applications. S3 includes: In this embodiment, addressing the issue that the interaction behavior between applications evolves gradually over time during the operation of a smart park, and that short-term observations are insufficient to distinguish between occasional fluctuations and long-term stable patterns, a projected interaction structure reflecting the long-term operational behavior benchmark between applications is constructed by performing grouped statistical analysis and stability analysis on the interaction record sequences within a historical operating window. This provides a reference for identifying abnormal deviations in subsequent industrial data analysis. The implementation process includes the following steps: First, by grouping the linked record sequences, records with the same linked semantics are merged into the same statistical unit, laying the foundation for stability calculation; In this step, the sequence of linked records generated within the historical execution window is used as input. The trigger event type, response application identifier, response time, and state change direction of each linked record are read one by one. The combination of the trigger event type and the response application identifier is used as a grouping key, and the linked records are written to the corresponding grouping set based on this key. When a grouping key appears for the first time, the corresponding grouping set is initialized. When a linked record lacks a trigger event type or response application identifier, it is marked as an ungroupable record and removed from subsequent statistical processing. After the above processing, multiple grouping sets are output, each corresponding to a fixed trigger-response linkage relationship. Secondly, by performing interval stability analysis on the response time in the group set, the stable response time range of this linkage relationship in historical operation is identified; In this step, the response time data in a single group set is used as input. First, the response times are sorted according to their numerical values ​​to form an ordered response time sequence. Using this ordered response time sequence as input, the difference between adjacent response times is calculated sequentially along the numerical axis, and the difference is compared with a preset time interval threshold. The time interval threshold is estimated from historical statistics and is used to limit the allowable fluctuation range of time consumption within the same stable interval. When the difference between adjacent values ​​does not exceed the threshold, the corresponding response times are assigned to the same candidate interval. After the candidate interval division is completed, the number of response times contained in each candidate interval is counted. When the number reaches the preset lower limit of occurrence frequency configured by the system, the minimum response time in the candidate interval is taken as the lower limit of the stable response time interval, and the maximum response time is taken as the upper limit of the stable response time interval. If there is no candidate interval in a group set that meets the lower limit of occurrence frequency, the group is marked as an unstable time consumption group and no stable response time interval is generated. Finally, the stable response time interval corresponding to the group is output. Then, by performing consistency statistics on the direction of state change, the dominant direction of state change of this linkage in historical operation is determined; In this step, the frequency of occurrence of each state change direction within the same group set is counted using the input. The counted frequency is then compared with a preset lower bound for direction consistency. This lower bound, determined by business rule configuration or historical experience, limits the minimum consistency required for stable state change directions. When the frequency of occurrence of a state change direction reaches the lower bound, that state change direction is identified as a stable state change direction for that group. If no state change direction satisfies the lower bound, the group is marked as an unstable state direction group. The stable state change direction result for each group is then output. Next, through field combination operations, the grouped statistical results are transformed into structured expected linked records; In this step, the trigger event type and response application identifier corresponding to the group key are used as input fields, and the stable response time interval and stable state change direction calculated in the previous steps are read simultaneously. The trigger event type, response application identifier, lower limit of stable response time interval, upper limit of stable response time interval, and stable state change direction are written into the same record structure according to the preset field order to form an expected linkage record. When a group is marked as having unstable time or unstable state direction, no corresponding expected linkage record is generated. The generated expected linkage record is output for subsequent aggregation processing. Finally, by uniformly aggregating all expected linkage records generated within the historical operation window, an expected linkage structure between applications is constructed. In this step, all expected linkage records generated within the historical operation window are used as input. The expected linkage records are aggregated according to the combination relationship between the trigger event type and the response application identifier to form a set structure containing multiple expected linkage records. This set structure is written to the expected linkage storage area as the expected linkage structure output between applications, which is used for benchmark modeling of operational behavior in industrial data analysis. Through the above embodiments, the scattered linkage behaviors in the historical operation process are abstracted into stable response time intervals and stable state change directions, realizing a structured characterization of the long-term operation linkage rules between applications, and providing a reliable reference for subsequent real-time linkage deviation judgment; In practical applications, such as when a certain type of equipment control application in a smart park triggers an energy consumption management application for a long time and generates a stable response time and state change pattern, the expected linkage structure between applications constructed through this embodiment can be used as the benchmark input for an industrial data analysis model to identify abnormal time fluctuations or deviations in the direction of state changes that occur during subsequent operation, thereby supporting the accurate location and analysis of abnormal operating conditions. S4. Compare the real-time generated linkage records with the expected linkage structure between applications item by item to determine whether the response time exceeds the stable response time range and whether the state change direction deviates from the stable state change direction. Then, aggregate the linkage relationships that deviate continuously to form the expected failure linkage structure. S4 includes: In this embodiment, to address the issue that inter-application linkage behavior may gradually deviate from historical stable patterns during real-time operation, and that single anomalies are difficult to directly identify as operational anomalies, the system compares real-time generated linkage records with historically constructed expected inter-application linkage structures item by item. Combined with aggregation judgments within continuous time windows, it identifies linkage deviation behaviors that are both persistent and structural, thereby constructing expected failure linkage structures and providing an input basis for subsequent anomaly source localization. This implementation process includes the following steps: First, by using the indexing and positioning operation, a one-to-one correspondence is established between the real-time linkage records and their corresponding expected linkage benchmarks, providing a reference object for subsequent deviation judgment; In this step, the real-time generated sequence of linkage records is used as input. For each linkage record, the trigger event type, responding application identifier, response time, and state change direction are read sequentially. The combination of the trigger event type and the responding application identifier is used as the index key to perform a search operation in the expected linkage structure between applications, locating the expected linkage record that matches the index key. When the corresponding expected linkage record is successfully located, it is used as the reference for the current linkage record. When the corresponding expected linkage record cannot be located, it is marked as a record without a reference and the subsequent deviation judgment process is skipped. The output forms a comparison input pair containing the real-time linkage record and its corresponding expected linkage record for the next step to read. Secondly, the interval determination method is used to identify whether the response time deviates from the historical stable range, so as to quantify the degree of abnormality in the linkage response timing. In this step, the lower limit and upper limit of the stable response time interval in the expected linkage record are read as input, and the response time in the real-time linkage record is read simultaneously. The response time is compared with the lower and upper limits. When the response time is less than the lower limit of the stable response time interval or greater than the upper limit of the stable response time interval, the response time deviation judgment result is output as "deviation". When the response time falls between the lower and upper limits of the stable response time interval, the response time deviation judgment result is output as "no deviation". The judgment result is written into the judgment field of the linkage record for subsequent joint judgment steps to read. Then, the consistency determination method is used to identify whether the direction of state change deviates from the historical dominant pattern in order to capture anomalies at the linkage semantic level; In this step, using the same comparison input pair as input, the direction of stable state change in the expected linkage record and the direction of state change in the real-time linkage record are read; a consistency comparison operation is performed on the two; when the direction of state change in the real-time linkage record is not equal to the direction of stable state change, the output state direction deviation judgment result is "deviation"; when the two are consistent, the output state direction deviation judgment result is "no deviation"; the state direction deviation judgment result is written into the judgment field of the linkage record to form a linkage judgment record containing the time consumption judgment result and the state direction judgment result. Next, by combining the results of time consumption deviation and state direction deviation through a joint judgment mechanism, failure linkage records that need further attention are screened. In this step, the linkage judgment record containing two types of judgment results is used as input, and a logical joint operation is performed on the response time deviation judgment result and the state direction deviation judgment result. When either judgment result is a deviation, the corresponding linkage record is marked as a failed linkage record and written into the failure buffer sequence. When both judgment results are not a deviation, the linkage record is not written into the failure buffer sequence. The failure buffer sequence is used to temporarily store failed linkage records that occur consecutively in time and serves as the input for subsequent aggregation statistics. Subsequently, by using aggregated statistics within a continuous time window, persistent linkage deviation behaviors are identified to avoid misjudgments triggered by occasional anomalies. In this step, the failure buffer sequence is used as input, and sliding window statistics are performed on the failure linkage records according to the system's preset continuous time window, which is set by the operation configuration parameters. Within each time window, the failure linkage records are grouped and statistically analyzed according to the index key. When the number of failure linkage records corresponding to the same index key reaches the preset lower limit of the number of failures, a failure linkage entry is generated. The lower limit of the number of failures is configured by historical operation experience or rule constraints to limit the minimum sustained intensity required for linkage deviation. The generated failure linkage entries are output for the next step of aggregation and processing. Finally, by performing structured writing and aggregation on the failure linkage items, a expected failure linkage structure that can be used for subsequent analysis is formed. In this step, the generated failure linkage entries are used as input. For each failure linkage entry, its corresponding index key, failure time window, and the number of failures counted within that time window are read. The index key, failure time window, and number of failures are written into the failure linkage set, and all failure linkage entries are aggregated to form an expected failure linkage structure containing multiple failure linkage entries. The failure time window is a preset continuous time window corresponding to the failure linkage entry. The resulting expected failure linkage structure is output and used for the identification and aggregation judgment of operational linkage deviation behavior in industrial data analysis. Through the above embodiments, the sporadic time-consuming anomalies or state direction anomalies that appear in real-time linkage records are transformed into expected failure linkage structures with temporal continuity and structural characteristics, which effectively improves the stability and reliability of abnormal linkage identification. In practical applications, such as in a scenario where a business application in a smart park continuously triggers downstream applications but the response time continuously exceeds the historical stable range, the expected failure linkage structure constructed through this embodiment can be used as input to the industrial data analysis module to further perform anomaly source tracing and propagation path analysis, thereby supporting the accurate location and decision-making of abnormal operating conditions. S5. Perform reverse tracing and forward propagation calculations along the calling relationship for the expected failure linkage structure, and count the time and location of the first failure record of each application in the expected failure linkage structure and the subsequent propagation range. Based on the time and location and the propagation range, solve the abnormal source application and the corresponding propagation link, and output the abnormal source application and the propagation link as the location result of the abnormal working condition of the smart park. S5 includes: In this embodiment, to address the issue that inter-application linkage behavior may gradually deviate from historical stable patterns during real-time operation, and that single anomalies are difficult to directly identify as operational anomalies, the system compares real-time generated linkage records with historically constructed expected inter-application linkage structures item by item. Combined with aggregation judgments within continuous time windows, it identifies linkage deviation behaviors that are both persistent and structural, thereby constructing expected failure linkage structures and providing an input basis for subsequent anomaly source localization. This implementation process includes the following steps: First, by using the indexing and positioning operation, a one-to-one correspondence is established between the real-time linkage records and their corresponding expected linkage benchmarks, providing a reference object for subsequent deviation judgment; In this step, the real-time generated sequence of linkage records is used as input. For each linkage record, the trigger event type, responding application identifier, response time, and state change direction are read sequentially. The combination of the trigger event type and the responding application identifier is used as the index key to perform a search operation in the expected linkage structure between applications, locating the expected linkage record that matches the index key. When the corresponding expected linkage record is successfully located, it is used as the reference for the current linkage record. When the corresponding expected linkage record cannot be located, it is marked as a record without a reference and the subsequent deviation judgment process is skipped. The output forms a comparison input pair containing the real-time linkage record and its corresponding expected linkage record for the next step to read. Secondly, the interval determination method is used to identify whether the response time deviates from the historical stable range, so as to quantify the degree of abnormality in the linkage response timing. In this step, the lower limit and upper limit of the stable response time interval in the expected linkage record are read as input, and the response time in the real-time linkage record is read simultaneously. The response time is compared with the lower and upper limits. When the response time is less than the lower limit of the stable response time interval or greater than the upper limit of the stable response time interval, the response time deviation judgment result is output as "deviation". When the response time falls between the lower and upper limits of the stable response time interval, the response time deviation judgment result is output as "no deviation". The judgment result is written into the judgment field of the linkage record for subsequent joint judgment steps to read. Then, the consistency determination method is used to identify whether the direction of state change deviates from the historical dominant pattern in order to capture anomalies at the linkage semantic level; In this step, using the same comparison input pair as input, the direction of stable state change in the expected linkage record and the direction of state change in the real-time linkage record are read; a consistency comparison operation is performed on the two; when the direction of state change in the real-time linkage record is not equal to the direction of stable state change, the output state direction deviation judgment result is "deviation"; when the two are consistent, the output state direction deviation judgment result is "no deviation"; the state direction deviation judgment result is written into the judgment field of the linkage record to form a linkage judgment record containing the time consumption judgment result and the state direction judgment result. Next, by combining the results of time consumption deviation and state direction deviation through a joint judgment mechanism, failure linkage records that need further attention are screened. In this step, the linkage judgment record containing two types of judgment results is used as input, and a logical joint operation is performed on the response time deviation judgment result and the state direction deviation judgment result. When either judgment result is a deviation, the corresponding linkage record is marked as a failed linkage record and written into the failure buffer sequence. When both judgment results are not a deviation, the linkage record is not written into the failure buffer sequence. The failure buffer sequence is used to temporarily store failed linkage records that occur consecutively in time and serves as the input for subsequent aggregation statistics. Subsequently, by using aggregated statistics within a continuous time window, persistent linkage deviation behaviors are identified to avoid misjudgments triggered by occasional anomalies. In this step, the failure buffer sequence is used as input, and sliding window statistics are performed on the failure linkage records according to the system's preset continuous time window, which is set by the operation configuration parameters. Within each time window, the failure linkage records are grouped and statistically analyzed according to the index key. When the number of failure linkage records corresponding to the same index key reaches the preset lower limit of the number of failures, a failure linkage entry is generated. The lower limit of the number of failures is configured by historical operation experience or rule constraints to limit the minimum sustained intensity required for linkage deviation. The generated failure linkage entries are output for the next step of aggregation and processing. Finally, by performing structured writing and aggregation on the failure linkage items, a expected failure linkage structure that can be used for subsequent analysis is formed. In this step, the generated failure linkage entries are used as input. For each failure linkage entry, its corresponding index key, failure time window, and the number of failures counted within that time window are read. The index key, failure time window, and number of failures are written into the failure linkage set, and all failure linkage entries are aggregated to form an expected failure linkage structure containing multiple failure linkage entries. The failure time window is a preset continuous time window corresponding to the failure linkage entry. The resulting expected failure linkage structure is output and used for the identification and aggregation judgment of operational linkage deviation behavior in industrial data analysis. Through the above embodiments, the sporadic time-consuming anomalies or state direction anomalies that appear in real-time linkage records are transformed into expected failure linkage structures with temporal continuity and structural characteristics, which effectively improves the stability and reliability of abnormal linkage identification. In practical applications, such as scenarios where a business application in a smart park continuously triggers downstream applications but the response time consistently exceeds the historical stable range, the expected failure linkage structure constructed in this embodiment can serve as input to an industrial data analysis module for further anomaly source tracing and propagation path analysis, thereby supporting accurate location and decision-making for abnormal operating conditions. The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A data linkage analysis method for locating abnormal operating conditions in smart parks, characterized in that, include: S1. Collect, sort by time, and standardize the operation log data and status data generated by various business applications in the park to form an operation data sequence; S2. Perform call relationship parsing on the running data sequence, match the triggering event with the corresponding response event one by one, and calculate the response time and state change direction during the matching process to form a linkage record sequence; S3. Perform group statistics on the linkage record sequence within the historical operation window, calculate the stable response time interval and stable state change direction for the same trigger event and response application combination, and construct the expected linkage structure between applications. S4. Compare the real-time generated linkage records with the expected linkage structure between applications item by item to determine whether the response time exceeds the stable response time range and whether the state change direction deviates from the stable state change direction. Then, aggregate the linkage relationships that deviate continuously to form the expected failure linkage structure. S5. Perform reverse tracing and forward propagation calculations along the calling relationship for the expected failure linkage structure, and count the time and location of the first failure record of each application in the expected failure linkage structure and the subsequent propagation range. Based on the time and location and the propagation range, solve the abnormal source application and the corresponding propagation link, and output the abnormal source application and the propagation link as the location result of the abnormal working condition of the smart park.

2. The data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 1, characterized in that: S1 includes: S1-1. Read the operation log data and status data at the data collection endpoints corresponding to each business application, and uniformly add application identifiers and collection time stamps to the read data to form the original operation dataset; S1-2. Perform global time sorting on the original running dataset according to the collection time mark. Specifically, this includes: using the collection time mark as the sorting key, performing unified time axis rearrangement on data records from different business applications, and performing secondary sorting on data records with time mark conflicts according to the application identifier during the sorting process, thereby eliminating the data time offset between different business applications and forming a time-aligned data sequence. S1-3. Perform field mapping and field pruning on the time-aligned data sequence. Specifically, based on the pre-established field correspondence, map semantically consistent running fields in different business applications to unified field names, and prune fields that are not related to the running linkage analysis after mapping, and output the running data sequence arranged by application identifier and occurrence order.

3. The data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 2, characterized in that: S2 includes: S2-1. For each data record in the running data sequence, read the call identifier, application identifier, event type and occurrence time in sequence. Use the call identifier as the grouping key to write the data record into the corresponding grouping container. In each grouping container, assign the sequential number in the running data sequence to each data record as the record position identifier. Then sort the record position identifiers according to the occurrence time to build a call index table containing an ordered sequence of call identifiers and their corresponding record position identifiers. S2-2. Scan the ordered sequence of record position identifiers corresponding to each call identifier in the call index table one by one in sorted order. For each scanned data record, determine whether it belongs to a trigger event based on whether the event type of the data record is consistent with any event type in the predefined set of trigger event types. When a trigger event is determined, the application identifier read from the data record is used as the trigger application identifier, and the trigger application identifier and the time of occurrence are written into the trigger stack to form a scan sequence with trigger stack state; S2-3. In the scan sequence, when a scanned data record is determined to have an event type that matches any event type in the predefined set of response event types, the following pairing confirmation process is executed: Read the most recently written trigger record that has not been marked as paired from the trigger stack. Read the call identifier in the trigger record and compare it with the call identifier in the current response record. When they match, mark the trigger record and the current response record as paired, forming a pairing record of trigger event and response event and output it.

4. The data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 3, characterized in that: S2 also includes: S2-4. Read the occurrence time of the trigger event and the occurrence time of the response event for the paired records respectively. Calculate the time difference between the two events to solve the time interval between the occurrence time of the response event and the occurrence time of the trigger event, and output the response time consumption. S2-5. For the triggering event in the paired record, retrieve the most recent state data that occurred before the time the triggering event occurred by moving forward along the running data sequence, and use it as the state value before triggering. For a response event in a paired record, retrieve the most recent state data that occurred after the time the response event occurred along the running data sequence, and use it as the post-response state value; Perform differential calculation on the state value before triggering and the state value after response, determine the direction of state change based on the positive or negative sign of the differential result, and output the direction of state change; S2-6. For multiple paired records generated under the same call identifier, sort them according to the time of occurrence of the response event. When multiple paired records corresponding to the same response event are detected, determine whether the response time of each paired record falls between the preset lower limit and the preset upper limit of the time. Among the paired records that meet the conditions, select the time interval between the time of occurrence of the trigger event and the time of occurrence of the response event. Paired records that fall within the range of the preset lower limit and the preset upper limit of the time interval are taken as valid records. Output the set of paired records after conflict resolution. S2-7. For each pairing record in the pairing record set after conflict resolution, read: the triggering application identifier read from the triggering event data record, the response application identifier read from the response event data record, the triggering event type read from the triggering event data record, the response event type read from the response event data record, and the response time and state change direction corresponding to the pairing record. Write the linked record field set sequentially according to the preset field order to form a linked record, and output the linked record sequence used to describe the linked behavior of the application.

5. A data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 4, characterized in that: S3 includes: S3-1. In the historical operation window, read the trigger event type, response application identifier, response time and state change direction of each linkage record sequence, and write the linkage record into the corresponding group set using the combination of trigger event type and response application identifier as the group key. S3-2. Sort the response times in each group set according to their numerical values ​​to obtain an ordered sequence of response times. Using an ordered response time sequence as input, the difference between adjacent response times is scanned sequentially along the numerical axis. When the adjacent difference does not exceed the preset time interval threshold, the corresponding response times are assigned to the same candidate interval. For each candidate interval, count the number of response times it contains. When the number of response times reaches the preset lower limit of occurrence, take the lower limit of response time in the candidate interval as the lower limit of the stable response time interval, and take the upper limit of response time in the candidate interval as the upper limit of the stable response time interval, so as to solve the stable response time interval corresponding to the group. S3-3. Perform frequency statistics on the state change directions in each group set, calculate the number of times each state change direction appears in the group, and select the state change directions whose occurrence count falls into the preset direction consistency lower limit as the stable state change directions to be output. S3-4. Combine the fields corresponding to the group key, such as the trigger event type, response application identifier, stable response time interval, and stable state change direction, to form an expected linkage record. S3-5. Collect all expected linkage records generated within the historical operation window and construct an inter-application expected linkage structure containing multiple expected linkage records.

6. The data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 5, characterized in that: S4 includes: S4-1. For each linkage record generated in real time, read the trigger event type, response application identifier, response time and state change direction, and use the combination of the trigger event type and response application identifier as the index key to locate the corresponding expected linkage record in the expected linkage structure between applications. S4-2. Read the lower and upper limits of the stable response time interval for the located expected linkage record, and perform interval determination by comparing the response time in the linkage record with the corresponding lower and upper limits. When the response time is less than the lower limit of the stable response time interval or greater than the upper limit of the stable response time interval, the output response time deviation judgment result is "deviation"; otherwise, the output response time deviation judgment result is "no deviation". S4-3. Read the stable state change direction of the located expected linkage record, and perform a consistency judgment between the state change direction in the linkage record and the corresponding stable state change direction. When the direction of state change in the linkage record is not equal to the direction of stable state change, the output state direction deviation judgment result is "deviation"; otherwise, the output state direction deviation judgment result is "no deviation".

7. A data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 6, characterized in that: S4 also includes: S4-4. Perform a joint judgment on the response time deviation judgment result and the state direction deviation judgment result. When the response time deviation judgment result is a deviation or the state direction deviation judgment result is a deviation, mark the corresponding linkage record as a failed linkage record and write it into the failure buffer sequence. When both judgment results are not a deviation, do not write the linkage record into the failure buffer sequence. S4-5. Perform aggregation statistics on the failure buffer sequence within a preset continuous time window. When the number of failure linkage records corresponding to the same index key reaches the preset lower limit of the number of failures, generate the corresponding failure linkage entry. S4-6. Write the generated failure linkage entries into the failure linkage set according to the index key, failure time window and failure count, and collect them to form the expected failure linkage structure.

8. A data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 7, characterized in that: S5 includes: S5-1. Take each failure linkage entry in the expected failure linkage structure as input and read its index key, failure time window and failure count. Based on the index key, in the call relationship obtained by parsing the running data sequence, the triggering application node corresponding to the triggering event and the response application node corresponding to the response application identifier are located, and the response application node is used as the failure starting point node and aggregated to form a failure starting point set. S5-2. For each failure starting point node in the failure starting point set, perform a reverse traversal along the calling relationship and visit its upstream calling nodes level by level. During the traversal, for each accessed calling node, the failure linkage entry associated with that node is read, and the start time of the failure time window of that failure linkage entry is taken as the failure time position of that calling node, and the results are collected to form a reverse tracing result set. S5-3. For each calling node in the reverse tracing result set, perform a forward traversal along the calling relationship and visit its downstream calling nodes level by level. During the forward traversal, the number of failed linkage entries associated with the downstream calling nodes that are visited is counted, and the number is used as the propagation range corresponding to the calling node, which is then aggregated to form a forward propagation result set.

9. A data linkage analysis method for locating abnormal operating conditions in a smart park according to claim 8, characterized in that: S5 also includes: S5-4. Perform joint computation on the reverse tracing result set and the forward propagation result set, specifically including: For each calling node, read its corresponding failure time location and propagation range. When the failure time location of the calling node is earlier than the failure time locations of all its downstream calling nodes, and its propagation range reaches the preset propagation quantity lower limit, the calling node is identified as the abnormal source application, thereby solving the abnormal source application. S5-5. Starting with the abnormal source application, connect its upstream path in the reverse tracing result set and its downstream path in the forward propagation result set to form a complete propagation link corresponding to the abnormal source application. S5-6. Output the solution of the abnormal source application and its corresponding propagation link as the location result of the abnormal working condition of the smart park.

Images