A method and device for off-line caching and emergency monitoring of DCS picture data

Abstract

The application discloses a DCS picture data offline caching and emergency monitoring method and device, and belongs to the technical field of industrial automation control, comprising the following steps: in response to detecting a communication connection interruption instruction between a client and a DCS real-time data server, obtaining a preset picture level configuration; the picture level configuration divides DCS monitoring pictures into multiple levels according to monitoring priorities; based on the order from high to low, loading picture data of the corresponding level from the local cache of the client to obtain display data for rendering the monitoring picture, wherein the local cache stores time series data of the measuring points in advance according to the cache rules associated with the level; extracting time series data within a time window before the communication interruption; obtaining a data change rate based on the least square method fitting the time series data; generating a predicted value sequence based on the last time value and the data change rate to obtain predicted trajectory data; and presenting the predicted value sequence in the monitoring picture as a semi-transparent trajectory.

Description

Technical Field

[0001] This invention discloses a method and device for offline caching and emergency monitoring of DCS screen data, belonging to the field of industrial automation control technology. Background Technology

[0002] Existing DCS monitoring screens heavily rely on real-time data servers. Once the communication connection between the client and the server is interrupted, the dynamic data in the monitoring screen is cleared or displayed as an error code, the screen cannot be interacted with normally, the operator cannot view the data trend before the failure, and there is a lack of emergency saving and fault prediction mechanisms for dynamic process data.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This invention provides a method and apparatus for offline caching and emergency monitoring of DCS screen data, which at least solves the technical problems in the prior art where DCS systems cannot obtain real-time data when communication is interrupted, resulting in blank monitoring screens, loss of continuous monitoring capabilities for operators, and inability to predict the risk of parameters exceeding limits.

[0005] According to one aspect of the present invention, in order to achieve the above-mentioned objective, a method for offline caching and emergency monitoring of DCS screen data is provided, comprising: in response to detecting a communication connection interruption command between a client and a DCS real-time data server, obtaining a preset screen level configuration, wherein the screen level configuration divides the DCS monitoring screen into multiple levels according to monitoring priority; loading screen data of the corresponding level from the client's local cache according to the order of the levels from high to low, to obtain display data for rendering the monitoring screen, wherein the local cache stores time series data of the measuring points in advance according to the caching rules associated with the levels; extracting the time series data within the time window before the communication interruption, fitting the time series data based on the least squares method to obtain the data change rate, and generating a predicted value sequence based on the last time value and the data change rate to obtain predicted trajectory data, and presenting the predicted value sequence as a semi-transparent trajectory in the monitoring screen.

[0006] Furthermore, the DCS screen data offline caching and emergency monitoring method also includes: when communication is restored, generating an upload data stream based on the local operation log and sending it to the server, updating the local cache based on the real-time data returned by the server during the interruption, obtaining the updated cached data, and restoring the monitoring screen to online display.

[0007] Furthermore, the caching rules include: for the highest level of images, high-frequency caching is performed based on the DCS real-time sampling frequency to obtain first-level cache data; for the intermediate level of images, incremental caching is performed based on the data change time to obtain second-level cache data; and for the lowest level of images, snapshot caching is performed based on the device state change time to obtain third-level cache data.

[0008] Furthermore, the local cache adopts a ring storage structure, and configures the storage capacity threshold based on the user-defined maximum storage duration. When the storage capacity reaches the threshold, it automatically overwrites the oldest data and retains the full data of core parameters based on the predetermined time length before the communication interruption, thus obtaining a data snapshot before the interruption.

[0009] Furthermore, based on the detection results of no response for three consecutive heartbeat cycles or the detection results of a packet loss rate greater than 80%, a judgment result of communication connection interruption is obtained; based on the judgment result, a visual identifier of offline emergency mode is generated in the monitoring screen.

[0010] Furthermore, based on the judgment result, after generating a visual identifier for the offline emergency mode in the monitoring screen, the process also includes: obtaining an over-limit alarm signal based on the comparison result between the predicted value sequence and the preset alarm threshold, and generating a local alarm log based on the over-limit alarm signal; and filtering operation instructions based on the preset permission configuration during the communication interruption period to obtain an executable instruction set, and issuing the execution after secondary verification of the executable instruction set based on a dual confirmation mechanism, while generating a local operation log based on the execution record.

[0011] Furthermore, based on the detection results of normal response for 5 consecutive heartbeat cycles and the detection results of packet loss rate of less than 5%, the judgment result of communication recovery is obtained.

[0012] According to one embodiment of the present invention, a DCS screen data offline caching and emergency monitoring device is also provided, comprising: an emergency triggering module, used to respond to a detected interruption command in the communication connection between the client and the DCS real-time data server, to obtain a preset screen level configuration, wherein the screen level configuration divides the DCS monitoring screen into multiple levels according to the monitoring priority; a hierarchical loading module, used to load screen data of the corresponding level from the client's local cache in descending order of level, to obtain display data for rendering the monitoring screen, wherein the local cache stores time series data of the measuring points in advance according to the caching rules associated with the level; and a trajectory prediction module, used to extract the time series data within the time window before the communication interruption, fit the time series data based on the least squares method to obtain the data change rate, and generate a predicted value sequence based on the last moment value and the data change rate, to obtain predicted trajectory data, and present the predicted value sequence as a semi-transparent trajectory in the monitoring screen.

[0013] According to another aspect of the present invention, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor performs the methods of various embodiments of the present invention.

[0014] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of the present invention.

[0015] In this embodiment of the invention, by responding to a communication interruption command, local cached time-series data is loaded in descending order of screen level to ensure that the monitoring screen continuously displays key operating condition information. At the same time, based on the data before the interruption, the least squares method is used to fit and predict future trends and present them as a semi-transparent trajectory, enabling the operator to intuitively assess the direction of parameter evolution. This achieves operating condition simulation and potential limit exceedance warning in offline state, significantly improving the emergency monitoring continuity and operational safety of the DCS system. It also solves the technical problems in the prior art where the DCS system cannot obtain real-time data when communication is interrupted, resulting in blank monitoring screens, loss of continuous monitoring ability of operators, and inability to predict parameter limit exceedance risks. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a flowchart of a DCS screen data offline caching and emergency monitoring method according to one embodiment of the present invention; Figure 2 This is a structural block diagram of a DCS screen data offline caching and emergency monitoring device according to one embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention 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 of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a 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.

[0019] According to an embodiment of the present invention, a method for offline caching and emergency monitoring of DCS screen data is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This method embodiment can be executed in an electronic device or similar computing device that includes a memory and a processor. Taking operation on a vehicle terminal as an example, the vehicle terminal may include one or more processors (processors may include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), digital signal processing (DSP) chips, microcontroller units (MCUs), field-programmable gate arrays (FPGAs), neural network processors (NPUs), tensor processors (TPUs), artificial intelligence (AI) type processors, etc.) and a memory for storing data. Optionally, the vehicle terminal may also include transmission devices, input / output devices, and display devices for communication functions. Those skilled in the art will understand that the above structural description is merely illustrative and does not limit the structure of the vehicle terminal. For example, the vehicle terminal may include more or fewer components than described above, or have a different configuration than described above.

[0021] The memory can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the CS screen data offline caching and emergency monitoring method in this embodiment of the invention. The processor executes various functional applications and data processing by running the computer program stored in the memory, thereby realizing the aforementioned CS screen data offline caching and emergency monitoring method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0022] The transmission device is used to receive or send data via a network. Specific examples of the network mentioned above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0023] Display devices can be, for example, touchscreen liquid crystal displays (LCDs) and touch displays (also referred to as "touchscreens" or "touch displays"). The LCD allows users to interact with the user interface of the mobile terminal. In some embodiments, the mobile terminal has a graphical user interface (GUI), which allows users to interact with the GUI through finger contact and / or gestures on a touch-sensitive surface. Optional human-computer interaction functions include: creating web pages, drawing, word processing, creating electronic documents, playing games, video conferencing, instant messaging, sending and receiving emails, call interfaces, playing digital video, playing digital music, and / or web browsing, etc. Executable instructions for performing the above human-computer interaction functions are configured / stored in one or more processor-executable computer program products or readable storage media.

[0024] Figure 1 This is a flowchart of a DCS screen data offline caching and emergency monitoring method according to one embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps: Step S110: In response to the detected interruption command of the communication connection between the client and the DCS real-time data server, the preset screen level configuration is obtained. The screen level configuration divides the DCS monitoring screen into multiple levels according to the monitoring priority, as detailed below: In step S110, a periodic heartbeat detection mechanism is maintained between the client and the real-time data server in the DCS system. The client sends heartbeat packets to the server every 500 milliseconds and continuously listens for the server's response signal. When a network failure occurs or the server malfunctions, the heartbeat response will not return normally. The health of the communication link is determined by continuously monitoring the heartbeat response status. Specifically, when no heartbeat response is received for three consecutive heartbeat detection cycles, it indicates that the physical link or service process between the client and the server has been completely interrupted. In addition, packet loss rate is used as an auxiliary judgment indicator: when the packet loss rate exceeds 80%, even if there are still sporadic heartbeat responses, it is considered that the communication quality can no longer meet the real-time monitoring requirements and is regarded as a communication connection interruption. When any of the above conditions are met, a communication connection interruption command is generated. This command serves as the start signal for triggering the emergency monitoring mode, driving all subsequent offline caching and emergency processing procedures.

[0025] Based on the DCS operation monitoring priorities, a set of screen hierarchy configurations was pre-established. The core idea of ​​this configuration is that not all monitoring screens have equal monitoring value when offline. Operators first need to grasp the core parameters reflecting the overall operating condition, then the details, and finally the information from auxiliary equipment. Based on this, the configuration divides the DCS monitoring screens into three levels: the first level is the core operating condition overview screen, such as global parameters like unit load, main steam temperature, main steam pressure, and feedwater flow rate. These parameters directly relate to the safe operation of the unit and have the highest monitoring priority. The second level consists of sub-monitoring screens, such as boiler combustion, turbine regulation, and generator excitation, used for in-depth analysis of the operating status of each major process stage. The third level consists of auxiliary monitoring screens, such as cooling water, lubricating oil, and compressed air. Although these devices do not directly determine the main process, their abnormalities can lead to cascading failures. This hierarchical division ensures that data can be loaded in an orderly manner after communication interruptions, ensuring that limited local cache resources and display areas prioritize the most critical information.

[0026] In response to a communication connection interruption command, the client immediately performs a level configuration retrieval operation. This configuration is typically pre-stored in the client's local storage as a structured file (e.g., XML or JSON format) or a registry key. The client first reads the local configuration file, parsing out the screen level division rules, including the list of screen identifiers for each level, the corresponding set of measurement point labels, and the default display layout parameters for each screen. Subsequently, the client verifies the completeness and validity of the configuration, such as checking for circular dependencies and ensuring that all referenced measurement points are recorded in the local time-series cache database. If the configuration verification passes, the client loads it into the configuration management module in memory for use in subsequent hierarchical loading steps. This mechanism completes the logical chain from the occurrence of a communication interruption event to the retrieval of the screen level configuration, laying the data foundation for subsequent priority-based hierarchical loading of screen data.

[0027] Step S120: Based on the order of the levels from high to low, load the corresponding level's screen data from the client's local cache to obtain the display data used to render the monitoring screen. The local cache pre-stores the time-series data of the measurement points according to caching rules associated with the level. The specific details are as follows: In step S120, a lightweight time-series cache database is pre-established locally on the client side. This database is specifically used to store the time-series data of each measuring point in the DCS monitoring screen. Different caching rules are configured for different screen levels to achieve a balance between storage efficiency and data timeliness. Specifically, for the highest-level core operational overview screen, a high-frequency real-time caching strategy is adopted, with the caching frequency consistent with the sampling frequency of the DCS real-time data server, ensuring that the complete operational evolution process can be restored in offline mode. For the intermediate-level sub-monitoring screens, a periodic incremental caching strategy is adopted, storing the value at the moment of change only when the measuring point value changes, without generating redundant storage during steady state, thereby significantly reducing storage overhead while ensuring the recording of key changes. For the lowest-level auxiliary monitoring screens, a static snapshot caching strategy is adopted, caching data only once when the device state changes, without occupying storage resources at other times.

[0028] When the communication connection interruption command is triggered, the client immediately initiates a tiered loading process. This process strictly follows the order of screen priority from highest to lowest, ensuring the display of the highest priority screens. The client first reads all measurement point data belonging to the first-level cache in the local time-series cache database, and refreshes the dynamic controls on the screen according to the latest cached value of each measurement point, thereby fully rendering the core operating condition overview screen. Because the first-level cache adopts a high-frequency real-time strategy, each parameter on the core screen can display the last sampled value before the interruption occurred, without data blanks or error codes.

[0029] After loading and rendering the primary screen, the system continues loading the sub-monitoring screen data corresponding to the secondary cache. Since the secondary cache uses incremental change storage, the client needs to extract the latest change record and the timestamp of the change for each measurement point from the cache, using this as the basis for the displayed values. For measurement points that haven't changed for a long time before the communication interruption, the value at the time of their last change is displayed. This approach ensures the readability of the sub-monitoring screen while avoiding loading delays caused by excessive cached data.

[0030] Finally, the auxiliary monitoring screen data corresponding to the three-level cache is loaded. Because the three-level cache uses a static snapshot strategy, each measurement point is only cached when the device status changes. The client reads the latest status snapshot of each auxiliary device from the local cache and renders the status indicator lights and brief parameters on the screen accordingly.

[0031] Throughout the tiered loading process, the client submits the display data obtained from each tier to the screen rendering engine to generate the final monitoring screen. This tiered loading mechanism, based on hierarchical order, ensures that even under extreme conditions of communication interruption, operators can still obtain the most complete operational information possible, with the most critical core parameters always presented first, minimizing the risk of misoperation due to blank screens or missing information.

[0032] Step S140: Extract time-series data within the time window prior to the communication interruption. Fit the time-series data using the least squares method to obtain the data change rate. Generate a predicted value sequence based on the final time value and the data change rate to obtain the predicted trajectory data. Present the predicted value sequence as a semi-transparent trajectory on the monitoring screen. The specific details are as follows: In step S140, under emergency monitoring mode, the client first extracts time-series data within a preset time window before the communication interruption from the local time-series cache database. The length of this time window can be preset based on the dynamic characteristics of the core parameters. Because the local cache uses a ring storage structure and retains all core parameter data for the predetermined time period before the interruption, the client can reliably obtain continuous and complete historical measurement point sequences. The extracted data includes the timestamp of each measurement point and its corresponding value; these data constitute the basic sample set for subsequent operational condition simulations. For the core parameters in the first-level cache, due to the adoption of a high-frequency real-time caching strategy, the extracted data points are dense and continuous, accurately reflecting the dynamic evolution trajectory of the parameters before the interruption. For the parameters in the second and third-level caches, although the data points are relatively sparse, key change nodes and state transition moments are completely recorded, sufficient to support trend analysis.

[0033] The client performs a least-squares linear fitting operation on the extracted time-series data. Specifically, for each measurement point to be extrapolated, its timestamp is used as the independent variable and the measurement point value as the dependent variable to construct a linear regression equation. The rate of change of that measurement point at the instant of communication interruption is calculated, i.e., the slope of the fitted line. This slope reflects the average rate and direction of change of the parameter over the period before the interruption: a positive slope indicates an upward trend, a negative slope indicates a downward trend, and a larger absolute value indicates a more drastic change. Least-squares fitting can effectively suppress the interference of sampling noise on trend judgment, making the calculated rate of change more stable and reliable.

[0034] Based on the calculated rate of change of the data and the last moment value in the time series data, the client further generates a sequence of predicted values ​​for a preset future time period. The time granularity of the prediction points is determined according to the original sampling period of the DCS real-time data server, generating a continuous sequence of predicted values ​​and forming complete predicted trajectory data. On the monitoring screen, the client presents this predicted value sequence as a semi-transparent trajectory, distinct from the real-time curve. Through this semi-transparent visualization, operators can intuitively assess the possible evolution direction of parameters in offline mode, providing a decision-making reference for whether emergency operations are necessary.

[0035] When the client detects that the communication connection with the server has been restored, it initiates a two-way data synchronization process. The recovery criteria are: receiving normal heartbeat responses for five consecutive heartbeat detection cycles, and a packet loss rate of less than 5%. After confirming communication restoration, the client first generates an upload data stream based on the local operation logs and local alarm logs recorded in emergency monitoring mode, and sends this data stream to the DCS real-time data server. The local operation logs record the operation instructions executed by the operator during offline periods and double confirmation records; the local alarm logs record potential over-limit alarm information generated during operational scenario simulations. These log data are fully archived by the server after being uploaded.

[0036] Meanwhile, the client requests all real-time data from the server during the interruption. The server returns its cached historical data from the period of communication interruption to the client, which then updates its local time-series cache database based on this returned real-time data. After the local cache update is complete, the client automatically restores the monitoring screen to online display mode: the inferred parameter curves switch from semi-transparent predicted trajectories to real-time parameter curves obtained from the server, the "Offline Emergency Mode" indicator on the screen automatically disappears, and all dynamic data sources are redirected to the real-time server. The entire switching process is smooth and seamless, and the operator can restore normal online monitoring without manual intervention.

[0037] Based on steps S110 to S140 above, in this embodiment of the invention, by responding to a communication interruption command, local cached time-series data is loaded in descending order of screen level to ensure that the monitoring screen continuously displays key operating condition information; at the same time, based on the data before the interruption, the least squares method is used to fit and predict future trends and present them as a semi-transparent trajectory, enabling the operator to intuitively assess the direction of parameter evolution, realize operating condition simulation and potential limit exceedance warning in offline state, significantly improve the emergency monitoring continuity and operational safety of the DCS system, and thus solve the technical problems in the prior art where the DCS system cannot obtain real-time data when communication is interrupted, resulting in blank monitoring screens, loss of continuous monitoring ability of operators on operating conditions, and inability to predict parameter limit exceedance risks.

[0038] The DCS screen data offline caching and emergency monitoring method of this invention further includes: when communication is restored, generating an upload data stream based on the local operation log and sending it to the server; updating the local cache based on the real-time data returned by the server during the interruption period to obtain the updated cached data; and simultaneously restoring the monitoring screen to online display. This achieves seamless connection and bidirectional synchronization between offline and online data, while automatically restoring the monitoring screen to online display. It ensures complete archiving of operation records and alarm information during offline periods, eliminates data gaps in the monitoring screen, and allows for smooth switching without manual intervention, significantly improving the fault tolerance and automation level of the DCS system.

[0039] Furthermore, the caching rules include: for the highest-level images, high-frequency caching is performed based on the DCS real-time sampling frequency to obtain level 1 cache data; for intermediate-level images, incremental caching is performed based on data change moments to obtain level 2 cache data; and for the lowest-level images, snapshot caching is performed based on device state changes to obtain level 3 cache data. This significantly reduces local cache capacity usage and write frequency while ensuring that critical operational information is not lost, achieving a balance between data timeliness and storage efficiency.

[0040] Specifically, the local cache adopts a ring storage structure, configuring a storage capacity threshold based on the user-defined maximum storage duration. When the storage capacity reaches the threshold, it automatically overwrites the oldest data and retains the full data of core parameters based on a predetermined time length before the communication interruption, thus obtaining a data snapshot before the interruption. This achieves an optimal balance between data timeliness and the persistence of critical information with limited storage resources.

[0041] In this embodiment, a communication connection interruption is determined based on the detection result of no response for three consecutive heartbeat cycles or a data packet loss rate greater than 80%. Based on the determination result, a visual indicator of offline emergency mode is generated on the monitoring screen. This can immediately inform the operator that the system is in an offline monitoring state, reminding them to carefully assess the timeliness of the displayed data, thereby reducing the operational risks caused by mistakenly believing that the data is online in real time.

[0042] In one exemplary embodiment, after generating a visual identifier for the offline emergency mode on the monitoring screen based on the judgment result, the method further includes: obtaining an over-limit alarm signal based on the comparison result between the predicted value sequence and the preset alarm threshold, and generating a local alarm log based on the over-limit alarm signal; and filtering operation instructions based on the preset permission configuration during the communication interruption period to obtain an executable instruction set, and issuing the execution after secondary verification of the executable instruction set based on a dual confirmation mechanism, while generating a local operation log based on the execution record. This effectively prevents security incidents caused by misoperation or unauthorized operation in the offline state, and provides complete operation audit evidence for post-event traceability, thereby significantly improving the system security and controllability during emergency monitoring.

[0043] Furthermore, based on the detection results of normal response for five consecutive heartbeat cycles and the detection results of packet loss rate less than 5%, the judgment result of communication recovery is obtained, which effectively avoids frequent mode switching caused by instantaneous network fluctuations or occasional packet loss. This ensures that the system only exits emergency mode when the connection is truly reliable, thereby guaranteeing the smoothness of monitoring screen switching and the integrity of data updates.

[0044] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0045] This invention also provides a DCS screen data offline caching and emergency monitoring device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0046] Figure 2 According to one embodiment of the present invention, a DCS screen data offline caching and emergency monitoring device includes: The emergency trigger module 201 is used to respond to the detected interruption command of the communication connection between the client and the DCS real-time data server, obtain the preset screen level configuration, and divide the DCS monitoring screen into multiple levels according to the monitoring priority. The hierarchical loading module 202 is used to load the corresponding level of screen data from the local cache of the client in descending order of level, so as to obtain the display data for rendering the monitoring screen. The local cache stores the time series data of the measurement points in advance according to the caching rules associated with the level. The predicted trajectory module 203 is used to extract time series data within the time window before the communication interruption, fit the time series data based on the least squares method to obtain the data change rate, and generate a predicted value sequence based on the final value and the data change rate to obtain the predicted trajectory data. The predicted value sequence is presented as a semi-transparent trajectory in the monitoring screen.

[0047] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0048] According to one embodiment of the present invention, an electronic device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described method for offline caching and emergency monitoring of CS screen data during runtime.

[0049] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program: Step S1: In response to the detected interruption command of the communication connection between the client and the DCS real-time data server, obtain the preset screen level configuration. The screen level configuration divides the DCS monitoring screen into multiple levels according to the monitoring priority. Step S2: Based on the order of the levels from high to low, load the corresponding level of the screen data from the client's local cache to obtain the display data used to render the monitoring screen. The local cache stores the time series data of the measurement points in advance according to the caching rules associated with the level. Step S3: Extract time series data within the time window before the communication interruption, fit the time series data using the least squares method to obtain the data change rate, and generate a predicted value sequence based on the final value and the data change rate to obtain the predicted trajectory data. The predicted value sequence is then presented as a semi-transparent trajectory on the monitoring screen.

[0050] According to one embodiment of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the storage medium is located to execute the above-described CS screen data offline caching and emergency monitoring method.

[0051] Optionally, in this embodiment, the storage medium may be configured to store a computer program for performing the following steps: Step S1: In response to the detected interruption command of the communication connection between the client and the DCS real-time data server, obtain the preset screen level configuration. The screen level configuration divides the DCS monitoring screen into multiple levels according to the monitoring priority. Step S2: Based on the order of the levels from high to low, load the corresponding level of the screen data from the client's local cache to obtain the display data used to render the monitoring screen. The local cache stores the time series data of the measurement points in advance according to the caching rules associated with the level. Step S3: Extract time series data within the time window before the communication interruption, fit the time series data using the least squares method to obtain the data change rate, and generate a predicted value sequence based on the final value and the data change rate to obtain the predicted trajectory data. The predicted value sequence is then presented as a semi-transparent trajectory on the monitoring screen.

[0052] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0053] According to one embodiment of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described method for offline CS screen data caching and emergency monitoring.

[0054] Optionally, in this embodiment, the above-mentioned computer program product can be configured as a computer program that performs the following steps: Step S1: In response to the detected interruption command of the communication connection between the client and the DCS real-time data server, obtain the preset screen level configuration. The screen level configuration divides the DCS monitoring screen into multiple levels according to the monitoring priority. Step S2: Based on the order of the levels from high to low, load the corresponding level of the screen data from the client's local cache to obtain the display data used to render the monitoring screen. The local cache stores the time series data of the measurement points in advance according to the caching rules associated with the level. Step S3: Extract time series data within the time window before the communication interruption, fit the time series data using the least squares method to obtain the data change rate, and generate a predicted value sequence based on the final value and the data change rate to obtain the predicted trajectory data. The predicted value sequence is then presented as a semi-transparent trajectory on the monitoring screen.

[0055] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0056] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0057] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0058] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0059] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0060] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0061] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for offline caching and emergency monitoring of DCS screen data, characterized in that, include: In response to the detection of a communication connection interruption command between the client and the DCS real-time data server, a preset screen level configuration is obtained, which divides the DCS monitoring screen into multiple levels according to the monitoring priority. Based on the order of the levels from high to low, the corresponding level of screen data is loaded from the client's local cache to obtain display data for rendering the monitoring screen. The local cache stores the time series data of the measurement points in advance according to the caching rules associated with the level. Extract time-series data within the time window prior to the communication interruption, fit the time-series data using the least squares method to obtain the data change rate, and generate a predicted value sequence based on the final time value and the data change rate to obtain predicted trajectory data. The predicted value sequence is then presented as a semi-transparent trajectory on the monitoring screen.

2. The DCS screen data offline caching and emergency monitoring method according to claim 1, characterized in that, The DCS screen data offline caching and emergency monitoring method also includes: When communication is restored, an upload data stream is generated based on the local operation log and sent to the server. The local cache is updated based on the real-time data returned by the server during the interruption, and the updated cached data is obtained. At the same time, the monitoring screen is restored to online display.

3. The DCS screen data offline caching and emergency monitoring method according to claim 1, characterized in that, The caching rules include: For the highest level of image quality, high-frequency caching is performed based on the DCS real-time sampling frequency to obtain first-level cache data; For intermediate-level images, incremental caching is performed based on the data shift time to obtain second-level cache data; For the lowest level of image quality, snapshot caching is performed based on changes in device state to obtain three levels of cached data.

4. The DCS screen data offline caching and emergency monitoring method according to claim 1, characterized in that, The local cache adopts a ring storage structure and configures a storage capacity threshold based on the user-defined maximum storage duration. When the storage capacity reaches the threshold, the oldest data is automatically overwritten, and the core parameter full data is retained based on a predetermined time length before the communication interruption, thus obtaining a data snapshot before the interruption.

5. The DCS screen data offline caching and emergency monitoring method according to claim 1, characterized in that, Based on the detection results of no response for three consecutive heartbeat cycles or the detection results of a packet loss rate greater than 80%, a judgment result of communication connection interruption is obtained; based on the judgment result, a visual identifier of offline emergency mode is generated in the monitoring screen.

6. The DCS screen data offline caching and emergency monitoring method according to claim 5, characterized in that, Based on the determination result, after generating the visual identifier of the offline emergency mode in the monitoring screen, the method further includes: Based on the comparison result between the predicted value sequence and the preset alarm threshold, an over-limit alarm signal is obtained, and a local alarm log is generated based on the over-limit alarm signal. Furthermore, the operation instructions are filtered based on the preset permission configuration during the communication interruption to obtain an executable instruction set. The executable instruction set is then verified a second time based on a dual confirmation mechanism before being sent for execution. At the same time, a local operation log is generated based on the execution record.

7. The DCS screen data offline caching and emergency monitoring method according to claim 1, characterized in that, Based on the detection results of normal response for 5 consecutive heartbeat cycles and the detection results of packet loss rate of less than 5%, the judgment result of communication recovery is obtained.

8. A DCS screen data offline caching and emergency monitoring device, characterized in that, include: The emergency trigger module is used to respond to the detection of a communication connection interruption command between the client and the DCS real-time data server, and to obtain a preset screen level configuration. The screen level configuration divides the DCS monitoring screen into multiple levels according to the monitoring priority. The hierarchical loading module is used to load the corresponding level of screen data from the client's local cache in descending order of the level, so as to obtain the display data for rendering the monitoring screen. The local cache stores the time series data of the measurement points in advance according to the caching rules associated with the level. The trajectory prediction module is used to extract time-series data within the time window before the communication interruption, fit the time-series data based on the least squares method to obtain the data change rate, and generate a prediction value sequence based on the final time value and the data change rate to obtain the prediction trajectory data. The prediction value sequence is presented as a semi-transparent trajectory in the monitoring screen.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it is based on the DCS screen data offline caching and emergency monitoring method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it is based on the DCS screen data offline caching and emergency monitoring method as described in any one of claims 1 to 7.

Images