Data processing method and device based on industrial automation monitoring system and medium

Abstract

The invention provides a data processing method and device based on an industrial automation monitoring system and a medium. The method comprises the following steps: receiving a drawing data request sent by a front end, and analyzing the drawing data request to obtain identification information of a target drawing; querying a timed pushing task associated with the target drawing according to the identification information; executing a timed pushing task according to the refresh cycle of the target drawing, wherein the timed pushing task comprises the steps of analyzing the target drawing to obtain drawing data source information and a conditional expression, acquiring original data of the target drawing by utilizing the drawing data source information, and calculating the conditional expression to generate a calculation result; and integrating the calculation result with the original data to obtain a target data packet, and pushing the target data packet to a front end through a corresponding communication channel. According to the invention, the utilization rate of network resources and the computing performance in a high-load scene can be improved.

Description

Technical Field

[0001] The present application relates to the field of industrial automation monitoring technology, and in particular to a data processing method, device and medium based on an industrial automation monitoring system. Background Art

[0002] With the development of industrial automation technology, industrial enterprises have an increasing demand for automated monitoring systems. Real-time monitoring, data push, and rule calculation have become the core functions of modern industrial automation monitoring systems. These functions involve large-scale data processing, real-time information transmission, and diverse business needs. However, existing technical solutions have many shortcomings when dealing with large-scale concurrent connections, high-frequency data push, and complex rule calculation.

[0003] Existing industrial automation monitoring systems generally adopt technical solutions based on Spring thread pool and WebSocket. Each client connection monitors a drawing. Spring starts an independent thread for each drawing, and regularly pushes real-time data and calculation results to the Web front end during the drawing refresh cycle. Although this solution can complete the data push task, there is a significant problem: each client connection needs to occupy a separate thread, which will cause a waste of IO resources in high-concurrency scenarios. Especially outside the drawing refresh cycle, the thread still occupies network IO resources, and other client connections cannot reuse existing threads, which leads to inefficient resource utilization of the system.

[0004] Current technical solutions mostly use the IK-Expression expression engine for rule configuration and real-time calculation. The IK-Expression engine has poor performance when processing a large number of rules, especially in a high-load environment, where calculation timeouts are more serious. In addition, the engine cannot cache compilation results, and each rule calculation requires recompiling the expression, which further wastes the system's computing resources and reduces computing efficiency. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a data processing method, device and medium based on an industrial automation monitoring system to solve the problems of network resource waste, low resource utilization and insufficient computing performance under high load scenarios existing in the prior art.

[0006] According to a first aspect of an embodiment of the present application, a data processing method based on an industrial automation monitoring system is provided, including: receiving a drawing data request sent by a front end, parsing the drawing data request, and obtaining identification information of a target drawing; querying a scheduled push task associated with the target drawing according to the identification information; executing the scheduled push task according to a refresh cycle of the target drawing, wherein the scheduled push task includes parsing the target drawing, obtaining drawing data source information and a conditional expression, obtaining the original data of the target drawing using the drawing data source information, and calculating the conditional expression to generate a calculation result; integrating the calculation result with the original data to obtain a target data packet, and pushing the target data packet to the front end through a corresponding communication channel.

[0007] According to a second aspect of an embodiment of the present application, a data processing device based on an industrial automation monitoring system is provided, comprising: a parsing module, configured to receive a drawing data request sent by a front end, parse the drawing data request, and obtain identification information of a target drawing; a query module, configured to query a scheduled push task associated with the target drawing according to the identification information; an execution module, configured to execute the scheduled push task according to a refresh cycle of the target drawing, wherein the scheduled push task comprises parsing the target drawing, obtaining drawing data source information and a conditional expression, obtaining the original data of the target drawing using the drawing data source information, and calculating the conditional expression to generate a calculation result; and a push module, configured to integrate the calculation result with the original data, obtain a target data packet, and push the target data packet to the front end through a corresponding communication channel.

[0008] According to a third aspect of an embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the computer program.

[0009] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0010] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0011] By receiving the drawing data request sent by the front end, parsing the drawing data request, and obtaining the identification information of the target drawing; according to the identification information, querying the scheduled push task associated with the target drawing; executing the scheduled push task according to the refresh cycle of the target drawing, wherein the scheduled push task includes parsing the target drawing, obtaining the drawing data source information and conditional expression, using the drawing data source information to obtain the original data of the target drawing, and calculating the conditional expression to generate the calculation result; integrating the calculation result with the original data to obtain the target data packet, and pushing the target data packet to the front end through the corresponding communication channel. This application can improve the utilization rate of network resources and the computing performance in high-load scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0013] Figure 1 It is a schematic diagram of the overall structure of the automated monitoring service system provided in the embodiment of the present application;

[0014] Figure 2 It is a schematic diagram of the business processing flow of the automated monitoring business system provided in an embodiment of the present application;

[0015] Figure 3 It is a flowchart of a data processing method based on an industrial automation monitoring system provided in an embodiment of the present application;

[0016] Figure 4 It is a structural schematic diagram of a data processing device based on an industrial automation monitoring system provided in an embodiment of the present application;

[0017] Figure 5 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0019] With the development of industrial automation technology, industrial enterprises have an increasing demand for automated monitoring systems. Real-time monitoring, data push and rule calculation have become the core functions of modern industrial automation monitoring systems. These functions involve large-scale data processing, real-time information transmission and diversified business needs. However, existing technical solutions have many shortcomings when dealing with large-scale concurrent connections, high-frequency data push and complex rule calculation.

[0020] Existing industrial automation monitoring systems generally adopt technical solutions based on Spring thread pool and WebSocket. Each client connection monitors a drawing. Spring starts an independent thread for each drawing, and regularly pushes real-time data and calculation results to the Web front end during the drawing refresh cycle. Although this solution can complete the data push task, there is a significant problem: each client connection needs to occupy a separate thread, which will cause a waste of IO resources in high-concurrency scenarios. Especially outside the drawing refresh cycle, the thread still occupies network IO resources, and other client connections cannot reuse existing threads, which leads to inefficient resource utilization of the system.

[0021] Current technical solutions mostly use the IK-Expression expression engine for rule configuration and real-time calculation. The IK-Expression engine has poor performance when processing a large number of rules, especially in a high-load environment, where calculation timeouts are more serious. In addition, the engine cannot cache compilation results, and each rule calculation requires recompiling the expression, which further wastes the system's computing resources and reduces computing efficiency.

[0022] Therefore, the prior art still has the following disadvantages:

[0023] Waste of network IO resources: Since each client connection needs to create a separate thread and thread resources cannot be shared, a lot of IO resources are wasted. In high concurrency situations, this approach is particularly inefficient and cannot fully utilize the system's processing power.

[0024] There is a performance bottleneck: The performance of the IK-Expression expression engine has a bottleneck in high-concurrency and complex rule calculation scenarios, and cannot meet the high requirements of the real-time monitoring system for calculation speed and response time. In addition, due to the lack of expression compilation cache, each calculation needs to be recompiled, wasting a lot of computing time and system resources.

[0025] In view of the above-mentioned defects of the prior art, this application provides a distributed implementation solution for conditional calculation and data push of industrial data. The purpose of this application is to solve the following two main technical problems:

[0026] 1. The first major technical problem to be solved is the waste of IO resources.

[0027] In the existing thread model, each client connection needs to create a separate thread, and threads cannot share resources, resulting in a large amount of IO resources being idle and wasted. Therefore, how to optimize the thread model and avoid resource waste is the primary technical problem of this application.

[0028] In this regard, this application uses netty+websocket technology. Netty uses the non-blocking Channel implementation of the Java NIO library, which can handle multiple client connections in a single thread; it processes the event loop through EventLoopGroup, and there is no need to create a new thread for each connection. This means that the application only needs to wait on a blocking object, and there is no need to create a separate thread for each connection. When a connection has new data to process, the operating system will notify the application, and the thread will return from the blocking state and start business processing.

[0029] The master-slave Reactor multithreading model can improve concurrent processing capabilities. Each connection can be processed in an independent thread, avoiding competition between threads. The Reactor multithreading mode can avoid blocking the main thread and improve the system's responsiveness. The Mainreactor thread is responsible for processing connection events, the Subreactor thread is responsible for distributing events, and specific task processing is completed by other worker threads. At the same time, when resources are sufficient, it can fully utilize the performance advantages of multi-core processors to improve system throughput.

[0030] 2. The second technical problem to be solved is the slow performance of the ik-expression expression engine.

[0031] The existing rule calculation engine (IK-Expression) has insufficient performance in high-load scenarios and cannot cope with the high concurrent calculation requirements of complex business rules. In addition, due to the lack of a compilation cache mechanism, repeated compilation leads to poor performance. It is necessary to improve the efficiency of rule calculation and avoid timeouts.

[0032] In this regard, this application uses the Aviator expression engine framework + thread pool implementation. Aviator is between heavyweight scripting languages ​​such as Groovy and ultra-lightweight expression engines such as IKExpression. Other evaluators generally run in an interpreted manner, while Aviator directly compiles the expression into Java bytecode and hands it over to the JVM for execution through reflection, which improves execution efficiency.

[0033] Aviator supports expression compilation caching. When monitoring drawings online, only one compilation is required. Aviator will cache the expression compilation result to JVM. The next time the expression is calculated, there is no need to compile it. The cached result can be used for calculation directly, which improves the calculation speed.

[0034] Using thread pool technology, 100 clients are monitored online on a single node. Each drawing contains 10,000 expressions, which are processed by 128 threads at the same time, with an average processing time of less than 500ms. No expression calculation timeout occurs.

[0035] First of all, before describing the technical solution of the present application in detail, the overall structure of the automated monitoring service system involved in the technical solution of the present application in an actual scenario is explained in conjunction with the accompanying drawings and embodiments. Figure 1 Schematic diagram of the overall structure of the automated monitoring service system provided in the embodiment of the present application. Figure 1 As shown, the automated monitoring business system may specifically include the following contents:

[0036] The automated monitoring business system of this application mainly optimizes the efficiency and scalability of the existing system through the layered architecture of the data push layer, data calculation layer and data source layer. Each layer has a clear division of responsibilities to facilitate the expansion, maintenance and decoupling of the system. The following is a detailed description of each layer:

[0037] 1. Data push layer

[0038] The data push layer is responsible for interacting with the front-end Web application. Its main function is to manage the WebSocket connection with the front-end and handle data push tasks. In actual applications, multiple clients may be online at the same time and need to view the relevant data of the drawing in real time. At this time, the data push layer establishes a continuous two-way connection with the front-end through the WebSocket protocol to ensure that the updated data can be pushed in real time when the data changes.

[0039] The data push layer is mainly used to manage the WebSocket connection between the front-end client and process the client's connection request and disconnection request.

[0040] Real-time data and calculation results are pushed regularly according to business needs. For each online client, the data push layer is responsible for maintaining the connection status of the client and related push tasks.

[0041] The scheduled execution of push tasks depends on the refresh cycle of the drawing and the scheduled task mechanism. The data push layer will ensure that the calculation results are pushed to the front end in time according to the configuration of the scheduled push tasks.

[0042] The advantage of the data push layer is that it uses a combination of the efficient Netty framework and the WebSocket protocol, which can reduce unnecessary thread creation in high-concurrency scenarios, avoid waste of IO resources, and improve the response efficiency and scalability of the system.

[0043] 2. Data computing layer

[0044] The data calculation layer is the core logic layer of the entire system, responsible for receiving drawing data requests from the front end, parsing drawing data, calculating conditional expressions, and integrating data to form the final target data packet. The data calculation layer implements the parsing of drawing data, the calculation of rules, and the integration of data, and provides calculation results for the data push layer.

[0045] The data calculation layer is mainly used to parse the relevant information of the drawing according to the drawing data requested by the front end, including the identification information of the drawing, data source information and calculation expression, etc. Based on the conditional expression set in the drawing, the data calculation layer uses the Aviator expression engine to perform fast calculations and integrate the calculation results with the original data obtained from the data source layer. After the calculation results and the original data are combined, the target data packet is generated and passed to the data push layer for push.

[0046] The data computing layer improves computing efficiency through multi-threading and the caching mechanism of the expression engine, especially when processing a large number of rule calculations, which can significantly reduce computing timeouts and performance bottlenecks.

[0047] 3. Data source layer

[0048] The data source layer provides support for raw data, mainly including real-time databases, historical databases, and relational databases. The responsibility of the data source layer is to provide the required raw data for the data computing layer and support different types of data sources (such as real-time monitoring data, historical data, and data from other business systems).

[0049] The data source layer is mainly used to obtain real-time monitoring data from the real-time database and provide dynamic raw data for drawing display. It provides historical database support for monitoring services that require historical data analysis or comparison. Through relational databases or external data interfaces, it provides data support related to business processes, such as production equipment information, process flow, etc.

[0050] The data source layer interacts with the data computing layer through standardized interfaces to ensure that data can flow seamlessly and maintain consistency.

[0051] In summary, through the above-mentioned layered architecture, the system can maintain efficient operation under high concurrency and large data volume, and ensure the optimization of data calculation, push tasks and resource utilization. Compared with the traditional solution based on Spring thread pool and IK-Expression expression engine, the solution of this application realizes efficient IO resource utilization and fast expression calculation by adopting Netty framework, Aviator expression engine and caching mechanism, thus meeting the high requirements of modern industrial automation monitoring system for real-time, scalability and computing efficiency.

[0052] Furthermore, based on Figure 1 The architecture of the automated monitoring business system shown illustrates the workflow of the automated monitoring business system of the present application. Figure 2 Schematic diagram of the business process flow of the automated monitoring business system provided in the embodiment of the present application. Figure 2 As shown, the business processing flow of the automatic monitoring business system may specifically include the following steps:

[0053] Step 1. The front end sends a drawing data request

[0054] The starting point of the process is that the front-end user initiates a drawing data request through the web interface. The user selects the drawing to be viewed on the front-end interface and sends the corresponding request. At this time, the front-end will send the drawing's identification information (such as the drawing's ID or unique identifier) ​​and related drawing parameters (such as refresh cycle, data source type, etc.) to the system.

[0055] The main operation involved in this step is that the front end sends the drawing request to the data push layer of the system through the WebSocket or HTTP protocol. The request contains parameter information of the target drawing (such as the drawing identification, data refresh cycle, etc.) for subsequent drawing parsing and data push tasks.

[0056] Step 2. The data push layer parses the drawing data request

[0057] After receiving the drawing request from the front end, the data push layer first parses the parameters in the request and extracts the identification information of the target drawing. This step matches the parameters in the drawing request with the stored drawing data to ensure that the identification information of the target drawing is accurate.

[0058] The main operation involved in this step is to parse the drawing identification information in the front-end request and extract all parameters related to the drawing. According to the drawing identification information, query whether there is a scheduled push task associated with it in the system. If it exists, jump to step 4; if not, create a new scheduled push task.

[0059] Step 3. Check whether the scheduled push task exists

[0060] According to the parsed target drawing identification information, the system queries whether there is a scheduled push task associated with the target drawing in the distributed cache. Scheduled push tasks are usually periodic tasks related to the drawing refresh cycle, expression calculation, and data push.

[0061] The main operation involved in this step is to query the distributed cache and check whether the target drawing already has a corresponding scheduled push task.

[0062] If the task does not exist, a new scheduled push task is created, and the configuration information of the task (including the identification of the drawing, refresh cycle, etc.) is stored in the cache to ensure that the new scheduled push task can be executed correctly.

[0063] If the task already exists, the current user session identifier is added to the session identifier set of the scheduled push task to ensure that subsequent push tasks can process requests from multiple clients at the same time.

[0064] Step 4. Analyze the target drawing to obtain the drawing data source information and calculation conditions

[0065] After receiving the drawing request, the data calculation layer begins to parse the drawing data source information and calculation expressions. At this time, the system extracts the drawing data source (such as real-time data source, historical data source, etc.) and conditional expressions (such as calculation formulas or data filtering rules) related to the target drawing based on the drawing identification information.

[0066] The main operation involved in this step is that the data calculation layer extracts data source information and conditional expressions from the target drawing. This information determines the subsequent data acquisition and calculation rules.

[0067] The data source information in the drawing will point to the corresponding data source layer (real-time library, historical library, relationship library, etc.). The data calculation layer obtains real-time or historical data from the data source layer based on this information. The conditional expression in the drawing defines how to process the acquired data, which may include arithmetic calculations, data filtering, merging, etc.

[0068] Step 5. Conditional expression calculation

[0069] Once the drawing data source information and conditional expressions are successfully extracted and obtained, the data calculation layer will use the efficient Aviator expression engine to calculate the conditional expressions. The Aviator expression engine compiles the conditional expressions into Java bytecode and passes them to the JVM for execution, greatly improving the calculation efficiency.

[0070] The main operations involved in this step are to use the Aviator expression engine to process conditional expressions and quickly calculate the results of the expressions.

[0071] During the first calculation, Aviator will compile the expression and cache the compiled result to improve the efficiency of subsequent calculations. The expression calculation process can be a dynamic calculation based on real-time data. The calculation result will be integrated with the original data to generate the final target data packet.

[0072] Step 6. Data integration and target data package generation

[0073] After the data calculation layer calculates the conditional expression results, it will then integrate the calculation results with the original data obtained from the data source layer. In this way, the system can provide complete real-time monitoring data, including original data and calculated results.

[0074] Integrate the calculation results and raw data to generate a target data package. The target data package contains all the data required for drawing presentation. The target data package usually includes real-time data, calculation results, and possible alarm or warning information.

[0075] Step 7. Push data to the front end via WebSocket

[0076] After the data integration is completed, the system will push the target data packet to the front-end interface through WebSocket. The front-end application will update the drawing display in real time according to the received data, showing the latest monitoring data and calculation results.

[0077] The main operation involved in this step is to transmit the target data packet to the front-end client through the WebSocket connection. The front-end updates the drawing display in real time to present the latest data and calculation results to the user.

[0078] Step 8. Reload and push triggered by user actions

[0079] In some cases, the user may choose to refresh or reload the drawing. At this time, the system will determine whether the drawing has changed by detecting the change in the MD5 value of the drawing. If the drawing has changed, the system will cancel the current scheduled push task and create a new scheduled push task based on the new drawing data.

[0080] The main operation involved in this step is that when the user refreshes the page, the data calculation layer will detect whether the MD5 value of the drawing has changed. If the MD5 value of the drawing has changed, the system will cancel the current scheduled push task and re-parse the new drawing data source information and conditional expression. Create a new scheduled push task and push the new data to the front end.

[0081] Through the above process, the system can ensure that the entire process from user requesting drawings to real-time data push runs efficiently, accurately and seamlessly. The above business process clearly explains how the system coordinates work between various steps such as receiving requests, calculating conditions, integrating data, and pushing results, thereby realizing real-time data display and efficient calculation of the automated monitoring system.

[0082] The contents of the technical solution of the present application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0083] Figure 3 1 is a flow chart of a data processing method based on an industrial automation monitoring system provided in an embodiment of the present application. Figure 3 As shown, the data processing method based on the industrial automation monitoring system may specifically include:

[0084] S301, receiving a drawing data request sent by the front end, parsing the drawing data request, and obtaining identification information of a target drawing;

[0085] S302, querying the scheduled push task associated with the target drawing according to the identification information;

[0086] S303, executing a scheduled push task according to the refresh cycle of the target drawing, wherein the scheduled push task includes parsing the target drawing, obtaining drawing data source information and a conditional expression, obtaining original data of the target drawing using the drawing data source information, and calculating the conditional expression to generate a calculation result;

[0087] S304, integrating the calculation result with the original data to obtain a target data packet, and pushing the target data packet to the front end through the corresponding communication channel.

[0088] In some embodiments, before receiving the drawing data request sent by the front end, the method further includes:

[0089] When the user previews the drawing online through the front end, the connection request sent by the front end is received and a communication connection with the front end is established;

[0090] A unique session ID is allocated to each front end according to the connection request, and a mapping relationship between the session ID and the front end, and between the session ID and the drawing is established.

[0091] Specifically, when a user previews a drawing online through the front-end system, the system first receives a connection request from the front-end. At this time, the front-end application initiates a connection request to the data push layer of the system through the WebSocket protocol. WebSocket connection is a full-duplex communication protocol that enables real-time two-way data transmission between the client and the server. In this step, the data push layer acts as a WebSocket server and listens for the connection request from the front-end. In some examples, the specific implementation method is:

[0092] The user selects the drawing to be viewed in the front-end interface and clicks "Online Preview". The front-end connects to the data push layer of the request system through Web Socket. The data push layer receives the connection request from the front-end, performs corresponding connection processing, and ensures that the WebSocket connection is successfully established.

[0093] Furthermore, once the connection request is successful, the system will assign a unique session ID to each front end. The session ID is used to uniquely identify a session between a client and the system and facilitates the subsequent drawing push task management. In some examples, the specific implementation method is:

[0094] The data push layer assigns a unique session identifier to each successfully connected front end, usually using a UUID (universally unique identifier) ​​or other unique identifier generation strategy. The session identifier information will be stored in the system's memory and mapped to the front end corresponding to the session for subsequent use.

[0095] Furthermore, the system binds the front-end to the corresponding WebSocket connection through the session identifier, ensuring that each front-end request can be correctly processed and the drawing data can be pushed in real time. At the same time, for the convenience of management, the system will also establish a mapping relationship between the session identifier and the requested target drawing, ensuring that each session can be associated with a specific drawing. In some examples, the specific implementation method is:

[0096] Bind the session ID to the front-end WebSocket connection to form a one-to-one mapping relationship. In the system's session management module, record the correspondence between the session ID and the front-end WebSocket connection. At the same time, the system associates the session ID with the drawing ID information requested by the user to ensure that the data processed by each session is associated with the drawing requested.

[0097] Furthermore, in actual applications, multiple users may preview different drawings online at the same time. The system needs to be able to process connection requests from multiple clients concurrently, and each connection needs to maintain an independent session identifier and its corresponding drawing information. To this end, the data push layer uses a thread pool or event loop mechanism (such as using the Netty framework) to handle multiple concurrent connections to ensure that the system has sufficient concurrency and response speed. In some examples, the specific implementation method is:

[0098] When multiple users are online at the same time, each user will initiate an independent connection request through WebSocket, and the data push layer will assign a unique session identifier to each connection. The data push layer associates each connection request with the drawing information requested by the user, and generates an independent scheduled push task for each user's request.

[0099] Furthermore, the lifecycle management of session identifiers is critical to system stability. The system needs to ensure that session information is cleaned up and resources are released in a timely manner when the session ends. Generally, when the user closes the browser or actively disconnects, the system will clean up the session identifier and associated data based on the WebSocket disconnect event. In some examples, the specific implementation method is:

[0100] When the front-end is disconnected, the data push layer will monitor the WebSocket disconnection event. The system will clean up the mapping relationship between the session identifier and the front-end and drawings according to the disconnection event and release related resources. At the same time, the system will stop the scheduled push task corresponding to the session to prevent invalid tasks from occupying system resources.

[0101] Through the method of the above embodiment, the automated monitoring service system of the present application can efficiently manage the connection requests of multiple front-end users and assign an independent session identifier to each user. Each session identifier can be associated with a specific drawing and a scheduled push task, ensuring that the system can support drawing preview and real-time data push for concurrent users. This design avoids the waste of resources caused by creating an independent thread for each connection in traditional technology, and improves the resource utilization and processing efficiency of the system.

[0102] In some embodiments, parsing the drawing data request to obtain identification information of the target drawing includes:

[0103] Receive a drawing data request sent by the front end, wherein the drawing data request includes relevant parameters of the target drawing, extract parameter information of the target drawing from the drawing data request; parse the parameter information of the target drawing to obtain identification information of the target drawing.

[0104] Specifically, the front-end application establishes a connection with the data push layer of the system through WebSocket. When the user chooses to preview a drawing on the front-end, the front-end sends a request containing drawing-related parameters to inform the data push layer of the data request information for the drawing. The request contains the unique identifier of the drawing (such as the drawing number, drawing version, etc.) and other information related to the drawing (such as the drawing refresh cycle, required data type, etc.).

[0105] For example, the user selects the drawing to be viewed on the front-end interface and triggers a drawing data request. The front-end sends the drawing data request to the data push layer through WebSocket. The data request content includes the identification information of the target drawing, the drawing refresh cycle, the data calculation conditions, etc. The data push layer of the system parses the relevant information of the drawing request through the received WebSocket message.

[0106] Furthermore, after receiving the drawing data request, the data push layer first parses the request content. The request content is usually a message containing JSON format data, which contains the drawing parameter information (such as drawing ID, drawing version, required data source type, refresh cycle, etc.). The system will extract the specific parameter information of the target drawing from this request.

[0107] For example, the system parses the JSON message body in the received drawing data request and extracts the drawing identifier (such as drawing ID, version information, etc.). Through the parsed information, the data push layer obtains the relevant parameters of the target drawing, such as refresh cycle, data source type, calculation rules, etc. If the drawing data request also contains other business parameters (such as user permission information, etc.), these will also be extracted for subsequent calculation and push.

[0108] Furthermore, after parsing the parameter information in the drawing data request, the system will further process these parameters to obtain the unique identification information of the target drawing. The identification information of the target drawing is a unique ID used to identify the drawing within the system. It can be a drawing number, drawing path, or other identifiers related to the drawing. This identification information will be used for subsequent operations such as drawing data query and scheduled push task management.

[0109] For example, based on the extracted drawing parameters, the identification information of the target drawing is constructed. For example, if the drawing parameters contain the drawing ID and version information, the system will generate a unique identification of the target drawing through this information. The generated drawing identification information will be used to query the scheduled push tasks, data source information, and related calculation rules related to the drawing.

[0110] Furthermore, in order to efficiently process drawing data requests from multiple front-end users, this system uses the Netty framework to manage WebSocket connections through its event-driven non-blocking I / O model. Netty enables the system to process multiple connections in parallel within a single thread without creating a separate thread for each connection. This greatly improves the performance of the system and reduces the waste of thread resources.

[0111] For example, Netty's event loop mechanism distributes requests to different processing threads through the Reactor model. The main thread is responsible for receiving connections and distributing events, while multiple worker threads are responsible for handling specific business logic. Each connection is assigned to an event loop thread (EventLoop), which is responsible for receiving and processing all events of the connection (such as drawing data requests, message push, etc.).

[0112] Furthermore, in order to improve the concurrent processing capability, the system uses thread pool technology. Whenever a drawing data request is received from the front end, Netty passes the request to the worker thread for processing, and the thread pool is responsible for scheduling tasks between multiple threads. Each request will be assigned to an idle thread for processing. The use of thread pool can effectively improve the concurrent processing capability of the system and avoid the performance overhead caused by frequent creation and destruction of threads.

[0113] For example, when the front-end sends a drawing data request, Netty distributes the request to the worker thread in the thread pool for processing through its event loop mechanism. After receiving the request, the worker thread in the thread pool starts to process the request, including parsing drawing parameters, querying data sources, calculating expressions, and other operations. During the processing, the thread pool ensures that there will be no thread starvation or blocking, ensuring that each request can be responded to in the shortest possible time.

[0114] In actual applications, the system needs to process drawing data requests from multiple front-end users at the same time. To this end, the data push layer uses Netty's non-blocking I / O model and thread pool technology to efficiently manage multiple We bSocket connections and ensure independent processing of each request.

[0115] For example, when multiple users request different drawings at the same time, Netty allocates an independent event loop thread for each WebSocket connection. The event loop thread hands each request to a worker thread in the thread pool for processing. The worker threads in the thread pool process requests from different users in parallel. The processing flow of each request includes: parsing the drawing data request, extracting the drawing identification information, querying the relevant data source, calculating the conditional expression, and pushing the calculation results to the front end.

[0116] Through the method of the above embodiment, combined with Netty's non-blocking I / O model and thread pool technology, the present application can efficiently process drawing data requests from multiple front-end users. After receiving the request, the system extracts the identification information of the target drawing by parsing the drawing parameters in the request, and uses an efficient event-driven mechanism and thread pool technology for concurrent processing, thereby improving the system's concurrent processing capability and response speed, and avoiding the performance bottleneck caused by frequent thread creation in traditional technologies.

[0117] In some embodiments, querying the scheduled push task associated with the target drawing according to the identification information includes:

[0118] According to the identification information of the target drawing, the distributed cache is queried to determine whether there is a scheduled push task associated with the target drawing in the distributed cache;

[0119] If the scheduled push task does not exist in the distributed cache, a new scheduled push task is created, and an association relationship between the identification information and the new scheduled push task is established in the distributed cache;

[0120] If there is a scheduled push task in the distributed cache, the current session ID is added to the session ID set associated with the target drawing.

[0121] Specifically, after receiving the drawing data request sent by the front end, the system first extracts the identification information of the target drawing from the request (such as drawing ID, version number, etc.). The data push layer uses this identification information to query whether there is a scheduled push task associated with the target drawing in the distributed cache.

[0122] For example, in some examples, the system receives a drawing data request sent by the front end, and parses out identification information of the target drawing (such as drawing ID, drawing version, etc.).

[0123] The data push layer queries the distributed cache system (such as Redis) based on the target drawing identification information to see whether there is a scheduled push task associated with the target drawing.

[0124] When querying, the system uses the identification information of the target drawing as the key and tries to find the corresponding scheduled push task in the distributed cache. If there is no push task for the drawing in the cache, the system will create a new scheduled push task; if it exists, it will jump to the next step to process the existing task.

[0125] Furthermore, if there is no scheduled push task associated with the target drawing in the distributed cache, the system will create a new scheduled push task and associate the task with the identification information of the target drawing. Subsequently, the system will save the newly created scheduled push task in the distributed cache and establish a mapping relationship between the identification information of the target drawing and the new task.

[0126] For example, in some examples, the system creates a new scheduled push task based on the identification information of the target drawing. The task includes configuration information such as the drawing refresh cycle, calculation rules, and push method.

[0127] After creating a new scheduled push task, the system saves the task in the distributed cache, using the target drawing's identification information as the key and the new task information as the value.

[0128] An association between the target drawing identification information and the scheduled push task is established in the cache to ensure that the task can be correctly found the next time it is queried.

[0129] Furthermore, if there is already a scheduled push task associated with the target drawing in the distributed cache, the system will update the session ID set of the task based on the current session ID. Whenever a new front-end session requests drawing data, the system will add the current session ID to the session ID set of the existing scheduled push task, ensuring that multiple front-end sessions can share the same scheduled push task.

[0130] For example, in some examples, the system searches the distributed cache for a scheduled push task based on the target drawing ID information. If the task already exists, the system obtains the session ID set of the task (for example, using Map<Drawing ID, Set <sessionid>>Structural storage of drawings and session identifiers). Add the current session identifier (sessionId) to the session identifier set of the task. Ensure that the system can push real-time data to the correct front-end session based on the session identifier set each time a query is made.

[0131] In this embodiment, the data push layer uses Map<Drawing ID, Set <sessionid>> structure to manage the relationship between drawings and session identifiers. The key role of this data structure is to efficiently maintain multiple session identifiers associated with each drawing and ensure the scalability and efficiency of the system through distributed caching. In some examples, the specific implementation is as follows:

[0132] When the system is initialized, an empty Map<Drawing ID, Set <sessionid>> object. Whenever a drawing data request is received, the system will use the identification information of the target drawing to check whether a corresponding session identification set already exists in the Map.

[0133] When a new front-end session requests drawing data, the system will check whether the target drawing already has a scheduled push task. If it does, the current session ID is added to Set <sessionid>In the collection; if it does not exist, create a new scheduled push task and initialize a new Set <sessionid>gather.

[0134] After each modification of the session identifier set, the system will save the updated task information back to the distributed cache to ensure data consistency.

[0135] Through the method of the present embodiment described above, combined with the relationship between the distributed cache management target drawing and the scheduled push task, the system can effectively manage the requests of multiple front-end sessions for the same drawing. <sessionid>>Data structure, the system can ensure that the scheduled push task of each drawing is shared with multiple front-end sessions, avoiding the overhead of repeatedly creating scheduled tasks, while improving the scalability and processing efficiency of the system.

[0136] In some embodiments, parsing the target drawing to obtain drawing data source information and conditional expressions includes:

[0137] According to the identification information of the target drawing, the drawing definition data associated with the target drawing is obtained from the system storage; the drawing definition data is parsed, the drawing data source information and conditional expressions related to the target drawing are extracted, and the drawing data source information and conditional expressions are stored in the distributed cache.

[0138] Specifically, the system first receives a drawing data request from the front end. The request carries the identification information of the target drawing (such as the drawing ID). The data push layer communicates with the front end through WebSocket and parses the drawing identification information in the request.

[0139] Furthermore, according to the identification information of the target drawing, the data computing layer obtains the definition data of the target drawing by querying the system storage (such as a database). The drawing definition data includes the structural information, data source configuration, expression rules, etc. of the drawing.

[0140] The drawing definition data may be stored in a dedicated drawing definition library, including, for example, the drawing ID, name, refresh cycle, conditional expression, and data source configuration information associated with the drawing.

[0141] Furthermore, the data computing layer parses the drawing definition data to extract the drawing data source information and conditional expressions. In some examples, the drawing data source information includes but is not limited to:

[0142] Real-time data source: points to a real-time data warehouse or database, providing data at the current moment.

[0143] Historical data source: Provides a historical data access interface, allowing historical data to be queried by time range.

[0144] Relationship data source: Relationship data between devices, sensors, or other objects in the drawing, such as device status, sensor parameters, etc.

[0145] Furthermore, after parsing is completed, the system stores the data source information and conditional expressions of the drawing in a distributed cache (such as Redis). In this way, subsequent scheduled tasks and drawing data push processes can efficiently access these cached data without having to reload and parse from the system storage every time.

[0146] In some examples, the storage structure may use the drawing ID as a key and save the data source information and conditional expression of the drawing as values, for example, Map<drawing ID, (data source information, conditional expression)>.

[0147] In practical applications, in order to improve the system's response speed and concurrent processing capabilities, this embodiment uses a distributed cache (such as Redis) to store the conditional expressions and data source information of the drawings. In this way, the system does not need to reload the drawing definition data from the storage database every time, which greatly reduces the time for data loading and improves the execution efficiency of scheduled tasks.

[0148] In addition, this embodiment also provides a cache update mechanism. When the drawing definition data changes (such as the drawing conditional expression update, data source configuration update, etc.), the system will promptly update the data in the cache to ensure that the data in the cache is always consistent with the drawing definition data.

[0149] This embodiment also supports concurrent processing, and the data computing layer supports high-concurrency requests. When multiple users monitor the same drawing online at the same time, the system can quickly process each scheduled task in parallel to ensure that each user can obtain the latest status of the drawing in a timely manner.

[0150] Through the above-mentioned method of this embodiment, combined with the distributed cache and scheduled task mechanism, the system can efficiently parse the target drawing and extract its data source information and conditional expressions. This method not only avoids the overhead of reloading and parsing the drawing definition data each time the scheduled task is executed, but also supports large-scale concurrent data push. The storage and caching mechanism of data source information further improves the system's response speed and data processing efficiency, ensuring that the real-time monitoring business system can run stably and efficiently in a complex industrial environment.

[0151] In some embodiments, the conditional expression is calculated to generate a calculation result, including:

[0152] Processing the conditional expression of the target drawing using a predetermined expression calculation engine so as to compile the conditional expression into bytecodes, and sending the bytecodes to the virtual machine for execution;

[0153] The compiled result of the conditional expression is cached, and calculation is performed based on the conditional expression and the original data of the target drawing to generate a calculation result associated with the target drawing.

[0154] Specifically, the system receives a conditional expression of a target drawing. The conditional expression may be an expression used to determine the state of a device, calculate a data trend, or perform some business logic. For example, a conditional expression may be "if temperature > 100 and pressure < 50, then trigger an alarm."

[0155] Furthermore, the system selects the Aviator expression engine (hereinafter referred to as "Aviator") to process the conditional expression. Aviator is an efficient and lightweight expression engine that can compile expressions into bytecodes and execute them through the JVM, thereby greatly improving computing efficiency. Aviator performs calculations through the JVM's reflection mechanism, avoiding the execution performance bottleneck of traditional interpreted languages.

[0156] Furthermore, the system uses Aviator to compile the conditional expression into Java bytecode. For example, the specific implementation is as follows:

[0157] Aviator first parses the conditional expression and converts it into an abstract syntax tree (AST), then optimizes and transforms the AST. The optimized AST is compiled into Java bytecode. The compiled bytecode can be directly executed by the JVM, greatly reducing the computational overhead.

[0158] Furthermore, in order to avoid recompiling the conditional expression for each calculation, the system stores the compiled bytecode in a cache (such as Redis). The cache key is the hash value or drawing ID of the conditional expression, and the value is the bytecode object. When the conditional expression has not changed, subsequent calculations will directly obtain the compiled bytecode from the cache, avoiding the performance waste of repeated compilation.

[0159] Furthermore, when the system needs to perform conditional expression calculation, it first obtains the bytecode of the conditional expression from the cache. If the bytecode already exists and is valid, the system directly passes it to the JVM for execution.

[0160] The calculation of the conditional expression depends on the original data of the target drawing. The system obtains the real-time data, historical data and relational data related to the target drawing from the data source and passes them to the bytecode execution engine as input parameters.

[0161] JVM executes bytecode through reflection mechanism, processes drawing data and calculates results. For example, the conditional expression "if temperature > 100 and pressure < 50, then trigger an alarm" will perform judgment based on the real-time temperature and pressure values ​​passed in, and return a Boolean value (such as True for alarm and False for normal).

[0162] Furthermore, after the calculation is completed, the system generates output results related to the target drawing according to the calculation results. For example, in some examples, if the conditional expression calculation result is True, the system triggers an alarm state and pushes the alarm information to the front end. If the conditional expression calculation result is False, the system continues to push data updates in normal state. The system pushes the calculation results to the front end through WebSocket for display, and provides real-time feedback on the drawing status.

[0163] In order to further improve the performance of the system, especially in high-concurrency scenarios, the system uses a cache mechanism when executing conditional expression calculations. The conditional expressions and calculation results of each drawing will be cached to avoid repeated calculations.

[0164] For example, when executing for the first time, i.e., calculating for the first time, the system compiles the conditional expression into bytecode and stores it in the cache. The bytecode is stored in the cache and is associated with the drawing ID or expression hash value. When the same drawing or conditional expression does not change, the system directly takes the bytecode from the cache to perform the calculation, saving compilation time and computing resources.

[0165] Since Aviator supports bytecode caching, only the bytecode in the cache needs to be loaded for each calculation, and the system avoids the performance loss caused by recompiling conditional expressions each time. This optimization greatly improves the computing efficiency of the system, especially when processing a large number of rules, and can significantly reduce latency and resource consumption.

[0166] The system can also process the calculation tasks of multiple drawings in parallel through multi-threading or thread pool to improve the system throughput. For example, the calculation task of each drawing can be assigned to an independent thread pool, and multiple threads can calculate the conditional expressions of different drawings at the same time, further improving the responsiveness of the system.

[0167] In some scenarios, users may need to modify the conditional expression of a drawing. For example, the user modifies the alarm rules or business logic in the drawing. The system will receive the updated conditional expression and recompile it into bytecode through Aviator.

[0168] The system will update the bytecode in the cache to ensure that the bytecode in the cache is consistent with the latest conditional expression. At this time, the cache key will be updated to the new expression hash value, and the old bytecode will be cleared.

[0169] Furthermore, the system implements an expiration policy for cached data. In order to prevent cached data from expiring or becoming invalid, the system sets a regular cleanup mechanism, such as regularly clearing unaccessed cached data or clearing part of the cached data according to the set maximum cache quantity. This can maintain the cache's efficiency and memory utilization.

[0170] This embodiment greatly improves the efficiency of conditional expression calculation by using the Aviator expression engine to compile conditional expressions into bytecodes. By caching the compiled bytecodes, the system can avoid repeated compilation each time it is executed, improving the calculation efficiency, especially in a high-concurrency environment. At the same time, the application of the cache mechanism and the cache update strategy also ensure that the system can still run efficiently when the conditional expression changes, further improving the performance and scalability of the system.

[0171] In some embodiments, the process of integrating the calculation result with the original data to obtain the target data packet and pushing the target data packet to the front end through the corresponding communication channel may include the following:

[0172] After the system completes the calculation of the drawing data, the calculation results (such as conditional expression calculation results, real-time data processing results, etc.) will be integrated with the relevant original data (such as basic data obtained from the real-time library, historical library, and relationship library) into a push data package.

[0173] In some examples, the data integration method can be dynamically adjusted according to the definition and requirements of the drawing. Usually, the integration results are stored in a structured format (such as JSON) to facilitate subsequent push and front-end parsing.

[0174] Each drawing corresponds to a sessionIdSet collection, which stores the session identifiers (sessionId) of all users who are viewing the drawing. The data push layer obtains the session information of all users who participate in viewing the drawing by traversing the sessionIdSet collection.

[0175] In an example scenario, when multiple users view the same drawing online at the same time, each user's front-end interface will establish an independent WebSocket connection. The sessionIdSet collection stores the session identifiers of all these WebSocket connections, and the system uses these identifiers to determine which users need to receive push data on drawing updates.

[0176] For each sessionId, the system will query the corresponding WebSocket connection channel through the session identifier. For example, the data push layer will search for the WebSocket communication channel connected to the session based on the session identifier sessionId.

[0177] If the sessionId is valid and the corresponding WebSocket connection exists, the system can push data through the connection. If the sessionId does not exist or has expired, the system will skip the session.

[0178] Furthermore, after confirming a valid WebSocket connection, the system sends a data push package to the front-end user through the Web Socket channel. The push data package contains the integrated calculation results and original data, and the front-end can update the drawings in real time after receiving it.

[0179] The pushed data packet can be in JSON format, containing the latest status of the drawing, calculation results, and real-time data that needs to be displayed. For example, the drawing may show the current status of a device (such as "normal", "fault") or the latest value of a sensor (such as "temperature: 25℃").

[0180] The frequency and content of data push are dynamically adjusted according to the drawing refresh cycle and the design requirements of the drawing. The system will determine the push interval based on the different refresh cycles of the drawing (such as every second, every minute or every hour).

[0181] If multiple users preview the same drawing online at the same time, the data push layer will perform the same push operation on each session ID and send the target data packet to the browser or device of each front-end user through their respective WebSocket connections.

[0182] For example, if five users are viewing a drawing at the same time, the system will push the same drawing update data to these five users through five WebSocket connections, ensuring that all users viewing the drawing receive the same real-time data and update information.

[0183] After the data push is completed, the system will update the status of the push task according to the drawing push strategy. If the data push of the current drawing is completed, the system will set the next push task according to the scheduled cycle, or continue to maintain the data push status according to the user's needs.

[0184] In some embodiments, after pushing the target data packet to the front end through the corresponding communication channel, the method further includes:

[0185] When the user reloads the drawing, the drawing reload request sent by the user through the front end is received, and the updated drawing information is obtained according to the drawing reload request;

[0186] Parse the updated drawing information and determine whether the drawing content has changed based on the hash value corresponding to the updated drawing information;

[0187] When it is determined that the drawing content has changed, the scheduled push task associated with the current drawing is canceled, and a new scheduled push task is created based on the updated drawing information, and the new scheduled push task is executed according to the refresh cycle of the current drawing.

[0188] Specifically, when a user requests to reload a drawing through a front-end interface (such as a web browser or a mobile application), the front-end sends a drawing reload request to the system. The request contains the identification information of the drawing (such as the drawing ID, drawing version number, etc.), and is used to identify the target drawing to be reloaded.

[0189] Furthermore, after receiving the drawing reload request sent by the front end, the data push layer of the system first queries the system storage or database according to the drawing identification information to obtain the latest version of the drawing information. The updated drawing information may include the drawing's graphic content, structure, defined data source, conditional expressions, etc.

[0190] Furthermore, the system parses the updated drawing information and extracts key data related to the drawing, such as the MD5 value of the drawing, the drawing data source, the conditional expression, etc.

[0191] The system determines whether the drawing has changed by calculating the MD5 value of the drawing content. The MD5 value is the unique identifier of the drawing content, and any slight change in the drawing content will cause a change in the MD5 value.

[0192] Furthermore, the system compares the MD5 value of the updated drawing with the MD5 value of the currently running drawing. If the MD5 value changes, it means that the drawing content has been updated. At this point, the system believes that the drawing content has changed and needs to readjust the scheduled push tasks related to the drawing.

[0193] When the drawing MD5 value matches, that is, the MD5 value has not changed, no operation is required and the system continues to use the current scheduled task.

[0194] When the drawing MD5 value does not match, that is, the MD5 value changes, go to the next step, cancel the current scheduled push task, and create a new scheduled task.

[0195] Furthermore, when it is determined that the drawing content has changed, the system will cancel the scheduled push task associated with the old drawing. This operation finds the scheduled task associated with the current drawing and ends or pauses the execution of the task to free up resources and prepare for the creation of new tasks. For example, the system will check the status of the scheduled push task to ensure that all tasks associated with the old drawing are cleared.

[0196] Furthermore, the system creates a new scheduled push task based on the updated drawing information (such as the MD5 value of the drawing, refresh cycle, data source, etc.). The new scheduled task will be executed regularly at predetermined time intervals according to the drawing refresh cycle to ensure that the front end obtains the latest drawing data and calculation results.

[0197] The system obtains the refresh cycle information from the drawing definition and sets a new scheduled task execution frequency. For example, if the drawing refresh cycle is 5 seconds, the system will execute the data push task every 5 seconds.

[0198] Furthermore, after creating a new scheduled push task, the system will re-parse the updated drawing and extract the conditional expressions and data source information in the drawing. At this time, the system will query the required real-time data and basic data from the relevant data source (such as the real-time library, historical library, or relationship library) based on the new drawing information, and use it as input for calculation. For example, if there is real-time temperature, humidity, or other sensor data in the drawing, the system will obtain this data from the real-time data source.

[0199] Furthermore, the system performs calculations based on the updated drawing definition, conditional expressions and real-time data, and generates calculation results related to the drawing. The calculation results can be data updates, alarm information or status changes.

[0200] After the calculation is completed, the system pushes the results to the front end through WebSocket or other communication protocols to update the displayed information on the drawing in real time.

[0201] Furthermore, after receiving the data push, the front end updates the display content of the drawing according to the calculation results, such as displaying the new device status, updating the data chart, or displaying the alarm information.

[0202] This embodiment ensures that the drawing data displayed on the user interface is always up to date by receiving drawing reload requests, determining drawing content changes, and dynamically adjusting scheduled push tasks. It also improves the performance and real-time nature of the system through efficient scheduled task management and real-time data query. This technical solution effectively solves the problem of data push task management after drawing content updates, and ensures the efficient operation of the automated monitoring business system.

[0203] According to the technical solution provided by the above-mentioned embodiment of the present application, the technical solution of the present application has at least the following advantages:

[0204] First of all, from a technical point of view, the above-mentioned layered architecture can adapt to various changes in subsequent business needs. For example, in the future, when deployed on a machine with higher hardware configuration, you only need to increase the number of Netty boss threads and worker threads to achieve faster page response speed and business throughput. If you receive a demand to implement real-time alarm push in the future, you only need to subscribe to the alarm service in the data computing layer, and the alarm service will push the real-time alarm, and the data computing layer will push it to the front end after integration. In this way, only the data computing layer needs to be moved. If the real-time library fails, it will not affect the business operation of the data computing layer and the data push layer. Empty data will still be pushed to the Web front end. After the real-time library returns to normal, the drawing preview returns to normal.

[0205] Secondly, from the perspective of economic benefits, the above technical solution can achieve the following: first, a single node can support 100 clients for online monitoring. Each drawing contains 10,000 expressions, which are processed by 128 threads at the same time, with an average time of less than 500ms. No expression calculation timeout occurs. Second, by improving resource utilization, users can save deployment costs and software costs. It also helps enterprises improve production efficiency and enhance their market competitiveness.

[0206] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0207] Figure 4 Schematic diagram of the structure of the data processing device based on the industrial automation monitoring system provided by the embodiment of the present application. Figure 4 As shown, the data processing device based on the industrial automation monitoring system includes:

[0208] The parsing module 401 is configured to receive the drawing data request sent by the front end, parse the drawing data request, and obtain the identification information of the target drawing;

[0209] A query module 402 is configured to query the scheduled push task associated with the target drawing according to the identification information;

[0210] The execution module 403 is configured to execute the scheduled push task according to the refresh cycle of the target drawing, wherein the scheduled push task includes parsing the target drawing, obtaining the drawing data source information and the conditional expression, obtaining the original data of the target drawing by using the drawing data source information, and calculating the conditional expression to generate a calculation result;

[0211] The push module 404 is configured to integrate the calculation result with the original data to obtain a target data packet, and push the target data packet to the front end through the corresponding communication channel.

[0212] In some embodiments, Figure 4 Before receiving the drawing data request sent by the front end, the establishment module 405 receives the connection request sent by the front end and establishes a communication connection with the front end when the user previews the drawing online through the front end; assigns a unique session identifier to each front end according to the connection request, and establishes a mapping relationship between the session identifier and the front end, and between the session identifier and the drawing.

[0213] In some embodiments, Figure 4 The parsing module 401 receives a drawing data request sent by the front end, wherein the drawing data request includes relevant parameters of a target drawing, extracts parameter information of the target drawing from the drawing data request, and parses the parameter information of the target drawing to obtain identification information of the target drawing.

[0214] In some embodiments, Figure 4 The query module 402 queries the distributed cache according to the identification information of the target drawing to determine whether there is a scheduled push task associated with the target drawing in the distributed cache; if there is no scheduled push task in the distributed cache, a new scheduled push task is created, and an association relationship between the identification information and the new scheduled push task is established in the distributed cache; if there is a scheduled push task in the distributed cache, the current session identifier is added to the session identifier set associated with the target drawing.

[0215] In some embodiments, Figure 4 The execution module 403 obtains the drawing definition data associated with the target drawing from the system storage according to the identification information of the target drawing; parses the drawing definition data, extracts the drawing data source information and conditional expressions related to the target drawing, and stores the drawing data source information and conditional expressions in the distributed cache.

[0216] In some embodiments, Figure 4 The execution module 403 uses a predetermined expression calculation engine to process the conditional expression of the target drawing so as to compile the conditional expression into bytecode and send the bytecode to the virtual machine for execution; caches the compiled result of the conditional expression, and performs calculation based on the conditional expression and the original data of the target drawing to generate a calculation result associated with the target drawing.

[0217] In some embodiments, Figure 4 After the execution module 403 pushes the target data packet to the front end through the corresponding communication channel, when the user reloads the drawing, it receives a drawing reloading request sent by the user through the front end, and obtains updated drawing information according to the drawing reloading request; parses the updated drawing information, and determines whether the drawing content has changed according to the hash value corresponding to the updated drawing information; when it is determined that the drawing content has changed, cancels the scheduled push task associated with the current drawing, creates a new scheduled push task based on the updated drawing information, and executes the new scheduled push task according to the refresh cycle of the current drawing.

[0218] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0219] Figure 5 Schematic diagram of an electronic device 5 provided in an embodiment of the present application. Figure 5 As shown, the electronic device 5 of this embodiment includes: a processor 501, a memory 502, and a computer program 503 stored in the memory 502 and executable on the processor 501. When the processor 501 executes the computer program 503, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 501 executes the computer program 503, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0220] The electronic device 5 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 5 may include, but is not limited to, a processor 501 and a memory 502. Those skilled in the art will appreciate that Figure 5 The electronic device 5 is merely an example and does not limit the electronic device 5 , and may include more or less components than those shown in the figure, or different components.

[0221] The processor 501 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0222] The memory 502 may be an internal storage unit of the electronic device 5, for example, a hard disk or memory of the electronic device 5. The memory 502 may also be an external storage device of the electronic device 5, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 5. The memory 502 may also include both an internal storage unit of the electronic device 5 and an external storage device. The memory 502 is used to store computer programs and other programs and data required by the electronic device.

[0223] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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 above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units.

[0224] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. Computer-readable storage media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0225] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.< / sessionid> < / sessionid> < / sessionid> < / sessionid> < / sessionid> < / sessionid>

Claims

1. A data processing method based on an industrial automation monitoring system, characterized in that: include: Receiving a drawing data request sent by the front end, parsing the drawing data request, and obtaining identification information of the target drawing; According to the identification information, query the scheduled push task associated with the target drawing; Executing the scheduled push task according to the refresh cycle of the target drawing, wherein the scheduled push task includes parsing the target drawing to obtain drawing data source information and a conditional expression, obtaining original data of the target drawing using the drawing data source information, and calculating the conditional expression to generate a calculation result; The calculation result is integrated with the original data to obtain a target data packet, and the target data packet is pushed to the front end through a corresponding communication channel.

2. The method according to claim 1, characterized in that Before receiving the drawing data request sent by the front end, the method further includes: When the user previews the drawing online through the front end, a connection request sent by the front end is received, and a communication connection with the front end is established; A unique session identifier is allocated to each front end according to the connection request, and a mapping relationship between the session identifier and the front end, and between the session identifier and the drawing is established.

3. The method according to claim 1, characterized in that The step of parsing the drawing data request to obtain identification information of the target drawing includes: Receive a drawing data request sent by the front end, wherein the drawing data request includes relevant parameters of the target drawing, extract parameter information of the target drawing from the drawing data request; parse the parameter information of the target drawing to obtain identification information of the target drawing.

4. The method according to claim 1, characterized in that: The querying, according to the identification information, of a scheduled push task associated with the target drawing includes: According to the identification information of the target drawing, query the distributed cache to determine whether there is a scheduled push task associated with the target drawing in the distributed cache; If the scheduled push task does not exist in the distributed cache, a new scheduled push task is created, and an association relationship between the identification information and the new scheduled push task is established in the distributed cache; If the scheduled push task exists in the distributed cache, the current session identifier is added to the session identifier set associated with the target drawing.

5. The method according to claim 1, characterized in that The target drawing is parsed to obtain drawing data source information and conditional expressions, including: According to the identification information of the target drawing, the drawing definition data associated with the target drawing is obtained from the system storage; the drawing definition data is parsed, the drawing data source information and the conditional expression related to the target drawing are extracted, and the drawing data source information and the conditional expression are stored in the distributed cache.

6. The method according to claim 1, characterized in that The calculating the conditional expression to generate a calculation result includes: Processing the conditional expression of the target drawing using a predetermined expression calculation engine so as to compile the conditional expression into bytecodes, and sending the bytecodes to a virtual machine for execution; The compiled result of the conditional expression is cached, and calculation is performed based on the conditional expression and the original data of the target drawing to generate a calculation result associated with the target drawing.

7. The method according to claim 1, characterized in that After pushing the target data packet to the front end through the corresponding communication channel, the method further includes: When the user reloads the drawing, a drawing reloading request sent by the user through the front end is received, and updated drawing information is obtained according to the drawing reloading request; Parsing the updated drawing information, and determining whether the drawing content has changed according to the hash value corresponding to the updated drawing information; When it is determined that the drawing content has changed, the scheduled push task associated with the current drawing is canceled, and a new scheduled push task is created based on the updated drawing information, and the new scheduled push task is executed according to the refresh cycle of the current drawing.

8. A data processing device based on an industrial automation monitoring system, characterized in that: include: The parsing module is configured to receive the drawing data request sent by the front end, parse the drawing data request, and obtain the identification information of the target drawing; A query module, configured to query the scheduled push task associated with the target drawing according to the identification information; an execution module, configured to execute the scheduled push task according to the refresh cycle of the target drawing, wherein the scheduled push task includes parsing the target drawing to obtain drawing data source information and a conditional expression, obtaining the original data of the target drawing using the drawing data source information, and calculating the conditional expression to generate a calculation result; The push module is configured to integrate the calculation result with the original data to obtain a target data packet, and push the target data packet to the front end through a corresponding communication channel.

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 computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images