Method and device for automatically generating front-end diagnostic graph

Abstract

The invention discloses a method and device for automatically generating a front-end diagnostic graph, and the method comprises the steps: a diagnostic server automatically obtains equipment hardware configuration information through local monitoring software, and automatically generates a Web diagnostic graph based on a built-in diagnostic graph template library; the Web server receives and caches the diagnostic graph and responds to an access request of the client; the diagnosis server monitors the hardware configuration change and dynamically updates the diagnosis graph; and acquiring real-time data through a data subscription mechanism, and automatically generating and pushing alarm information based on an alarm rule base. According to the method, the diagnosis graph is converted from manual configuration to full-automatic generation, the configuration efficiency and accuracy are remarkably improved, the real-time performance of the system is guaranteed through local cache and an optimized data transmission mechanism, flexible expansion and non-intrusive deployment are supported by adopting a distributed architecture, and the real-time performance of the system is improved. The problems of low configuration efficiency, poor real-time performance and insufficient expansibility in the prior art are effectively solved.

Description

Technical Field

[0001] This application belongs to the field of industrial automation monitoring technology, specifically relating to a method and device for automatically generating front-end diagnostic diagrams. Background Technology

[0002] In the field of industrial automation, Distributed Control Systems (DCS) have become the core control architecture of modern industrial facilities, widely used in industries such as petrochemicals, power, metallurgy, and pharmaceuticals. Web browser-based remote monitoring and diagnostic functions are gradually becoming standard features of DCS systems, enabling operators to overcome geographical limitations and achieve real-time monitoring of equipment operating status through a unified visual interface. Currently, mainstream front-end diagnostic solutions require manual input of equipment information and binding of diagnostic tag numbers. While this meets basic front-end monitoring needs, it suffers from low configuration efficiency, is prone to errors, and struggles to adapt to dynamic production demands. When the production unit structure is adjusted or new equipment is added, the existing diagnostic system needs to be synchronously modified to display the latest information on the front end.

[0003] Currently, the main methods for generating front-end diagnostic diagrams in the field of industrial automation are as follows: CN103454515A discloses a graphical self-diagnosis system that uses pre-stored equipment drawings and a fault database to graphically mark faulty components. However, it requires manual pre-entry of basic graphic resources such as overall equipment drawings and installation location diagrams. When the equipment model changes, the drawing library needs to be manually updated again. CN119127162A proposes a web-based configuration software method based on a resource model, which enables the construction of a device monitoring interface by dragging and dropping components. However, the configuration process still relies on users manually setting parameters and associating them with components, and the resource model needs to be reconfigured when a new device is connected. CN118827317A designed a distributed alarm agent module to realize local storage and distribution of alarm information. CN120074758A improved the efficiency of industrial data transmission through coding optimization. However, neither of them involved automatic generation of diagnostic diagrams or front-end access acceleration mechanisms, and only made improvements to a single link.

[0004] Based on existing patents and practical application scenarios, current industrial monitoring systems still have the following core deficiencies in the diagnostic diagram generation and front-end interaction stages: 1. Low configuration efficiency: Existing solutions rely on manual input of equipment information, drawing of basic graphics, or manual drag-and-drop configuration. When new equipment is connected or production line is adjusted, drawings and parameters need to be manually updated again, with configuration time ranging from several hours to several days. Moreover, errors are easily introduced due to manual operation. 2. High front-end access response latency: Diagnostic graph data and real-time device data are stored in different modules. Each front-end access requires cross-service calls to generate graphs. When the number of devices exceeds thousands, the loading time often exceeds 10 seconds, affecting the timeliness of monitoring. 3. Insufficient system scalability: The existing system's technical architecture has obvious limitations. The diagnostic function is tightly coupled with a specific monitoring platform, making it difficult to deploy and expand as an independent service. Furthermore, most systems adopt a centralized architecture, which is difficult to adapt to the distributed monitoring needs of modern industrial CCR-FAR (Central Control Room-Field Analysis Room).

[0005] In conclusion, there is an urgent need for an innovative front-end monitoring system capable of automatically generating equipment diagnostic diagrams based on preset templates. This system can significantly improve configuration efficiency and reduce the risk of errors caused by manual intervention. Through automated solutions, enterprises can more efficiently manage the operation and maintenance of industrial equipment, thereby ensuring the continuity and stability of the production process. Summary of the Invention

[0006] In view of the above-mentioned shortcomings and deficiencies of the prior art, this application provides a method and apparatus for automatic generation of front-end diagnostic diagrams, which realizes automatic generation, real-time updating and efficient access of diagnostic diagrams, and solves the problems of low configuration efficiency, poor real-time performance and insufficient scalability in the prior art.

[0007] To achieve the above objectives, this application adopts the following technical solution: a front-end-based automatic diagnostic diagram generation method, characterized in that it includes a Web server deployed in a central control room and at least one diagnostic server deployed in a field analysis room, the method comprising: The diagnostic server obtains the hardware configuration information of the device through local monitoring software, automatically generates a diagnostic diagram based on the built-in diagnostic diagram template library and the hardware configuration information, and pushes it to the Web server. The Web server receives the diagnostic diagram and stores it in its local cache. The web server responds to the diagnostic graph access request initiated by the client, retrieves and returns the corresponding diagnostic graph from the local cache; The diagnostic server monitors changes in the hardware configuration of the device. When a change is detected, it regenerates the diagnostic map and pushes it to the web server. The web server then updates the locally cached diagnostic map. The diagnostic server obtains real-time data of diagnostic tag numbers from the local cache system, and pushes it to the web server in batches after data optimization processing; The diagnostic service has a built-in alarm rule base, which automatically generates alarm information based on the real-time data and pushes it to the Web service. The Web service then forwards the alarm information to the client for visualization on the front-end interface.

[0008] Furthermore, the diagnostic diagram template library includes a device icon library, a device-icon mapping table, a visual layout configuration file, and an alarm rule library.

[0009] Furthermore, the step of regenerating the diagnostic map includes: Periodically query the local monitoring software for the hardware configuration version identifier; The obtained version identifier is compared with the version identifier cached locally; When version identifiers are inconsistent, the diagnostic diagram regeneration process is automatically triggered.

[0010] Furthermore, the step of the diagnostic server pushing real-time data to the web server includes: Real-time data of diagnostic tag numbers is received through a change push mechanism; All diagnostic tag numbers are centrally mapped to a unified cache area. It is pushed to the web server using a batch transmission mechanism.

[0011] Furthermore, the batch transmission mechanism includes: compressing the data using a data compression algorithm and encrypting the data packets using an encryption protocol.

[0012] Furthermore, the steps for generating the alarm information include: The alarm rule base includes a pre-configured correspondence between alarm conditions and alarm levels; The diagnostic service will match and calculate the received real-time data with the alarm conditions; When any alarm condition is met, an alarm message containing the alarm level, alarm source device, and trigger value is generated and pushed to the Web service.

[0013] Furthermore, upon receiving the alarm information, the web server does not cache it locally but immediately pushes the alarm information to the connected client for visual display; the visual display includes at least one of pop-up prompts, color indicators, and sound and light alerts.

[0014] This application also discloses another embodiment, a front-end diagnostic diagram automatic generation device, characterized in that it includes: At least one diagnostic server is deployed in the field analysis room and configured to acquire the hardware configuration information of the device through local monitoring software, automatically generate diagnostic diagrams based on the built-in diagnostic diagram template library, monitor changes in hardware configuration and regenerate diagnostic diagrams, subscribe to changes in diagnostic tag numbers and push them to the local monitoring software, and automatically generate alarm information based on real-time data. The web server, located in the central control room, is configured to receive and cache diagnostic diagrams sent by the diagnostic server, respond to diagnostic diagram access requests from clients, and forward alarm information to clients. The diagnostic server is connected to the web server via a network, and the web server communicates with the client via the HTTP protocol.

[0015] Furthermore, the diagnostic server includes: The configuration acquisition module is used to acquire hardware configuration information from local monitoring software; The diagnostic diagram generation module is used to generate diagnostic diagrams based on the diagnostic diagram template library and hardware configuration information. The version detection module is used to monitor hardware configuration changes and trigger diagnostic graph updates; The data subscription module is used to subscribe to push notifications of changes in diagnostic tag numbers; The alarm processing module is used to generate alarm information based on real-time data.

[0016] Furthermore, the web server includes: The cache management module is used to store and manage diagnostic graphs sent by the diagnostic server. The access service module is used to respond to the client's diagnostic graph access request, retrieve the corresponding diagnostic graph from the local cache and return it; The alarm forwarding module is used to forward alarm information to the client.

[0017] The beneficial effects of this application are: 1. Achieve high efficiency and automation: By automatically parsing and generating templates of device configuration information, it completely replaces tedious and error-prone manual configuration, significantly shortens deployment time, and fundamentally eliminates human error.

[0018] 2. Ensure excellent real-time performance: By adopting a triple mechanism of change push, batch compression transmission and local caching, the entire link from data collection to front-end display is connected, which greatly reduces network load and access latency, and ensures that diagnostic data and alarm information can be synchronized to the front-end interface in seconds.

[0019] 3. Supports flexible expansion: Based on a distributed architecture and non-intrusive plug-in design, the system can be easily expanded and quickly deployed without affecting existing production systems, while ensuring the security of the control network through encryption and isolation mechanisms. Attached Figure Description

[0020] This application is described with reference to the following figures: Figure 1 This paper presents a system architecture diagram of the front-end diagnostic diagram automatic generation method of this application; Figure 2 The flowchart of the method for automatically generating front-end diagnostic diagrams in this application is shown; Figure 3 This application shows a timing diagram automatically generated from a diagnostic diagram. Figure 4 The timing diagram of the client access process in this application is shown; Figure 5 This application shows a timing diagram for the synchronous update of diagnostic diagrams; Figure 6 The timing diagram for the diagnostic alarm of this application is shown. Detailed Implementation

[0021] To better explain and facilitate understanding of the present invention, it is described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described below are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other; for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0022] As the background technology indicates, in the field of industrial control, web browser-based device diagnostic functions have broken through geographical limitations and achieved real-time monitoring of device operating status by establishing a unified visual interface. However, the currently adopted solutions generally suffer from core defects such as low configuration efficiency and poor adaptability, high front-end access response latency, fragmented technical solutions, and highly intrusive deployment.

[0023] To address the above problems, this application provides a front-end-based method for automatically generating diagnostic diagrams, such as... Figure 1 As shown, this includes a web server located in the central control room and at least one diagnostic server located in the field analysis room. Furthermore, a firewall is typically deployed between the diagnostic server and the web server to achieve secure isolation between the control network and the information network. Through innovative designs such as fully automated configuration and dynamic adaptation, an access acceleration architecture of "field diagnostic service + central web service," multi-stage collaborative optimization, and non-intrusive deployment, this approach overcomes the shortcomings of existing technologies in configuration efficiency, access speed, and system compatibility, providing a new technical path for industrial web-based monitoring. Specific methods are as follows... Figure 2 As shown, it includes: S100: The diagnostic server obtains the hardware configuration information of the device through local monitoring software, automatically generates a diagnostic diagram based on the built-in diagnostic diagram template library and the hardware configuration information, and pushes it to the Web server. The Web server receives the diagnostic diagram and stores it in the local cache.

[0024] The diagnostic diagram template library includes: Device Icon Library: In diagnostic diagrams, different devices are visualized using preset dedicated icons. The system has a complete pre-built device icon library. The icons typically match the actual appearance of the devices, making the diagnostic diagram interface more intuitive and easier to understand.

[0025] Device-Icon Mapping Table: The template includes a pre-defined mapping table between device types and icons. The diagnostic service can quickly locate and load device icon files based on this table. This mapping mechanism enables rapid construction of diagnostic maps through the correspondence between device types and icon files.

[0026] Visual layout configuration file: The visual layout rules determine the overall structure of the diagnostic diagram. The diagnostic service can automatically generate the diagnostic diagram by following these rules without manual intervention.

[0027] Alarm Rule Library: The diagnostic template library contains preset alarm generation rules. The system will automatically generate alarm information based on these rules and display it through a web page. In addition, users can customize and modify alarm generation rules.

[0028] The steps for automatically generating diagnostic charts, such as... Figure 3 As shown, it includes: S101: After the diagnostic service starts, it automatically loads the local diagnostic template library to prepare resources for generating diagnostic diagrams.

[0029] S102: The diagnostic service automatically obtains the hardware configuration information of all current devices by calling the application API interface provided by the local monitoring software or by directly reading its configuration archive file.

[0030] The hardware configuration information includes: a list of devices, device types, topological connections between devices, and communication addresses, etc.

[0031] S103: The system iterates through the acquired device list, and for each device, queries the "device-icon mapping table" based on its device type to find the corresponding icon. Simultaneously, based on the visual layout rules and the topological connections between devices in the hardware configuration information, the system determines the initial position of each device icon on the canvas and the connection relationships between devices.

[0032] S104: Draw sequentially on the specified canvas according to the layout rules: Device icon: Place an icon loaded from the icon library in the calculated location.

[0033] Connecting lines: Connect related device icons with lines according to the topology.

[0034] Data binding area: A dynamic text area is reserved next to the device icon to display real-time data (such as pressure, temperature) and status (such as running, stopped).

[0035] Finally, the graphics rendering engine outputs a complete, interactive diagnostic graph in a web format.

[0036] S105: The diagnostic server pushes the newly generated diagnostic graph to the web service deployed in the central control room (CCR). Upon receiving the graph, the web service stores it in its local cache and records its version identifier.

[0037] This template-based design standardizes the diagnostic chart generation process while supporting flexible style adjustments, ensuring effective visualization of diagnostic information. This template-based design not only simplifies the diagnostic chart generation process but also ensures consistency in chart format. Furthermore, combined with the local caching mechanism of the web service, it avoids the repeated generation of identical charts, significantly improving the visualization efficiency of diagnostic information and system response speed.

[0038] S200: The web server responds to the diagnostic graph access request initiated by the client, retrieves and returns the corresponding diagnostic graph from the local cache.

[0039] like Figure 4 As shown, the web server continuously listens for client access requests through a network port. When a user initiates an access request for the target diagnostic map on the client side, the web server quickly identifies the unique identifier of the target diagnostic map in the request and retrieves the corresponding diagnostic map in its local cache. This can be done quickly by using a hash table or a database lookup table to find the target diagnostic map with the unique identifier. The unique identifier contains unique information about the field device, such as its communication address, enabling rapid location of the target device's diagnostic map.

[0040] If the web server cannot find the target diagnostic map during the search process, it sends an error message to the client, indicating that the diagnostic map is abnormal and needs maintenance. Otherwise, it directly sends the target diagnostic map from its local cache to the client for display.

[0041] By caching diagnostic graphs locally on the web server, the network communication and real-time generation calculations between the web server and the backend diagnostic server are eliminated, significantly reducing response time and providing a smooth user experience. The availability of the web server is no longer heavily dependent on the real-time status of the diagnostic service; even if a diagnostic service is temporarily offline, users can still access historical diagnostic graphs as long as the graphs are in the cache. Furthermore, this method clarifies that the web service's responsibility is to "provide access services" rather than "generate diagnostic graphs." The generation and updating of diagnostic graphs are handled by the diagnostic service through a proactive push mechanism, with each fulfilling its specific function, resulting in a clear architecture.

[0042] S300: The diagnostic server monitors changes in the hardware configuration of the device. When a change is detected, it regenerates the diagnostic map and pushes it to the web server. The web server then updates the locally cached diagnostic map.

[0043] like Figure 5As shown, the system periodically queries the local monitoring software for the hardware configuration version identifier. The diagnostic server has a built-in timed task scheduler that triggers the automatic update process of the diagnostic diagram according to a preset task cycle.

[0044] The obtained version identifier is compared with the version identifier cached locally. After the diagnostic server initiates the diagnostic diagram update process, it sends a hardware configuration query request to the connected monitoring software to obtain the latest hardware configuration information of the field devices and compares it with the previous hardware configuration information stored locally.

[0045] If the version numbers are the same, the update process will be terminated.

[0046] If the version numbers are different, the diagnostic diagram update process is triggered, and the S100's automatic diagnostic diagram generation process is executed again. After receiving the diagnostic diagram pushed by the diagnostic server again, the web server stores the regenerated diagnostic diagram in its local cache and records its version identifier. At the same time, based on the unique identifier in the diagnostic diagram, the old version of the diagnostic diagram in the local cache is deleted to ensure that when responding to the diagnostic diagram access request initiated by the client, only the latest version of the diagnostic diagram exists in the local cache.

[0047] By using a timed task scheduler, the diagnostic diagram update process is triggered periodically, ensuring that the diagnostic diagrams seen by front-end users are 100% synchronized with the actual hardware configuration in the backend, without any manual intervention. This achieves truly unattended operation and maintenance, perfectly adapting to dynamic production environments. Furthermore, through version number comparison, the diagnostic diagram regeneration process is triggered only when the configuration information of field devices changes, avoiding frequent retrieval of complete configuration data and regeneration of diagnostic diagrams, thus significantly saving network and computing resources.

[0048] S400: The diagnostic server retrieves real-time diagnostic tag number data from the local cache system, performs data optimization processing, and then pushes it in batches to the web server. The specific steps are as follows: Figure 6 As shown, it includes: S401: Receives real-time data of diagnostic tag numbers via a change push mechanism. The local monitoring system uses a change push mechanism, eliminating the need to wait for polling from the diagnostic server. By collecting the values ​​of diagnostic tag numbers in real time, the local monitoring system will immediately and proactively push the new value of any subscribed diagnostic tag number to the diagnostic server once the value changes (e.g., the temperature changes from 100°C to 101°C).

[0049] S402: Centrally map all diagnostic tag number data to a unified cache area. The diagnostic server allocates a cache area in memory, such as a circular buffer or mapping table, and each diagnostic tag number is calculated based on the device address offset and configured with a fixed storage location in the cache area. Whenever a new tag number value is received, the diagnostic server directly writes it to the corresponding location in the cache area, overwriting the old value. This operation is performed only in memory and directly overwrites the old value of the same diagnostic tag number, avoiding frequent disk I / O operations.

[0050] S403: Pushes data to the Web server via batch transmission. The diagnostic server receives real-time diagnostic tag number data pushed by the local monitoring system according to the change push mechanism, maps the latest real-time data to the corresponding location in the cache area, and does not directly push it to the Web server. Instead, it uses a timer to trigger data push at regular intervals, pushing all changed data in the cache area to the Web server at once, while unchanging data is not pushed, reducing unnecessary data pushes. Furthermore, during system startup and the initial connection establishment, the generated real-time diagnostic tag number data is directly pushed via batch transmission, enabling the Web server to obtain the real-time data of the field device diagnostic tag numbers as soon as possible. This avoids system failures caused by abnormal system restarts or the loss of critical change data packets followed by a restart if the field diagnostic tag number data remains unchanged, preventing the system from obtaining real-time device information in a timely manner.

[0051] Furthermore, the batch transmission mechanism includes: compressing data using data compression algorithms, such as lossless compression algorithms like GZIP, to compress data within the buffer area, significantly reducing data packet size; and encrypting data packets using encryption protocols, such as strong encryption algorithms (like AES-256) to encrypt the compressed data packets, ensuring that data is effectively protected from leakage or tampering when crossing firewalls in control and information networks.

[0052] S500: The diagnostic service has a built-in alarm rule base. Based on the real-time data, it automatically generates alarm information and pushes it to the Web service. The Web service then forwards the alarm information to the client for visualization on the front-end interface. The alarm rule base is pre-configured with alarm conditions and alarm levels, including alarm types such as diagnostic service offline, controller offline, I / O card offline, and device parameter exceeding limits. When the diagnostic server receives real-time diagnostic data pushed by the local monitoring software, it matches and calculates against the built-in alarm rule base, filters out the alarm rules corresponding to the data, and determines the alarm result. If the real-time data meets the alarm range of the alarm rule base, such as controller offline (heartbeat signal loss > 10s), I / O card failure (collected value is consistently invalid), or key parameter exceeding limits (e.g., abnormal reactor pressure exceeding the maximum pressure limit), alarm information containing the alarm level, alarm source device, and trigger value is immediately generated and pushed to the Web server. Because the alarm information is a high-priority alarm, it is directly pushed to the Web server after generation and does not participate in the batch, compression, or timed push process of ordinary real-time data, ensuring extremely low alarm latency.

[0053] Upon receiving alarm information, the web server does not cache or store the alarm information locally to avoid latency caused by database read / write operations. Instead, the web server uses its WebSocket long-lived connection with all online client browsers to broadcast the received alarm information to all relevant clients in real time, where it is then visualized. By directly forwarding alarm information without storage, the web server reduces memory usage, improves real-time alarm information, and lowers latency. Visualization can take the form of at least one of pop-up notifications, color-coded alerts, or audible and visual warnings. Based on the urgency of the alarm, it is visualized on all clients connected to the web server. Different levels of urgency are displayed using at least one visualization method. Particularly serious alarms can be displayed using a combination of forced pop-up notifications, color-coded alerts, and audible and visual warnings on the client's visual interface, ensuring operators can promptly detect and address the alarms.

[0054] In summary, the beneficial effects of the method of the present invention are as follows: 1. Achieve high efficiency and automation: By automatically parsing and generating templates of device configuration information, it completely replaces tedious and error-prone manual configuration, significantly shortens deployment time, and fundamentally eliminates human error.

[0055] 2. Ensure excellent real-time performance: By adopting a triple mechanism of change push, batch compression transmission and local caching, the entire link from data collection to front-end display is connected, which greatly reduces network load and access latency, and ensures that diagnostic data and alarm information can be synchronized to the front-end interface in seconds.

[0056] 3. Supports flexible expansion: Based on a distributed architecture and non-intrusive plug-in design, the system can be easily expanded and quickly deployed without affecting existing production systems, while ensuring the security of the control network through encryption and isolation mechanisms.

[0057] Another embodiment of the present invention, this application also discloses another implementation method, a front-end diagnostic diagram automatic generation device, characterized in that it includes: At least one diagnostic server is deployed in the field analysis room and configured to acquire the hardware configuration information of the device through local monitoring software, automatically generate diagnostic diagrams based on the built-in diagnostic diagram template library, monitor changes in hardware configuration and regenerate diagnostic diagrams, subscribe to changes in diagnostic tag numbers and push them to the local monitoring software, and automatically generate alarm information based on real-time data. The web server, located in the central control room, is configured to receive and cache diagnostic diagrams sent by the diagnostic server, respond to diagnostic diagram access requests from clients, and forward alarm information to clients. The diagnostic server is connected to the web server via a network, and the web server communicates with the client via the HTTP protocol.

[0058] Furthermore, the diagnostic server includes: The configuration acquisition module is used to acquire hardware configuration information from local monitoring software; The diagnostic diagram generation module is used to generate diagnostic diagrams based on the diagnostic diagram template library and hardware configuration information. The version detection module is used to monitor hardware configuration changes and trigger diagnostic graph updates; The data subscription module is used to subscribe to push notifications of changes in diagnostic tag numbers; The alarm processing module is used to generate alarm information based on real-time data.

[0059] Furthermore, the web server includes: The cache management module is used to store and manage diagnostic graphs sent by the diagnostic server. The access service module is used to respond to the client's diagnostic graph access request, retrieve the corresponding diagnostic graph from the local cache and return it; The alarm forwarding module is used to forward alarm information to the client.

[0060] This device adopts a distributed architecture, consisting of a diagnostic server deployed in the field analysis room and a web server deployed in the central control room. The diagnostic server automatically parses the device's hardware configuration information, generates diagnostic diagrams based on a built-in template library, and monitors device changes; the web server is responsible for caching diagnostic diagrams and responding to client access. Through the configuration acquisition module and the automatic diagnostic diagram generation module, the diagnostic server has achieved a significant improvement in configuration efficiency and a substantial reduction in human error rate. The device, through data subscription, batch compressed transmission, and local caching mechanisms, has transformed diagnostic diagrams from manual configuration to fully automatic generation, significantly improving configuration efficiency, system real-time performance, and security. It also supports non-intrusive deployment and flexible expansion, effectively solving the technical problems of low configuration efficiency, high access latency, and insufficient scalability in traditional systems.

[0061] It should be noted that any reference numerals placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The words "a" or "an" preceding a component do not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. The use of the terms first, second, third, etc., is for convenience only and does not indicate any order. These terms can be understood as part of the component names.

[0062] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0063] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the claims should be interpreted to include both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0064] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, then this invention should also include these modifications and variations.

Claims

1. A method for automatically generating front-end diagnostic diagrams, characterized in that, The method includes a web server located in a central control room and at least one diagnostic server located in a field analysis room. The diagnostic server obtains the hardware configuration information of the device through local monitoring software, automatically generates a diagnostic diagram based on the built-in diagnostic diagram template library and the hardware configuration information, and pushes it to the Web server. The Web server receives the diagnostic diagram and stores it in its local cache. The web server responds to the diagnostic graph access request initiated by the client, retrieves and returns the corresponding diagnostic graph from the local cache; The diagnostic server monitors changes in the hardware configuration of the device. When a change is detected, it regenerates the diagnostic map and pushes it to the web server. The web server then updates the locally cached diagnostic map. The diagnostic server obtains real-time data of diagnostic tag numbers from the local cache system, and pushes it to the web server in batches after data optimization processing; The diagnostic service has a built-in alarm rule base, which automatically generates alarm information based on the real-time data and pushes it to the Web service. The Web service then forwards the alarm information to the client for visualization on the front-end interface.

2. The method according to claim 1, characterized in that, The diagnostic diagram template library includes a device icon library, a device-icon mapping table, a visual layout configuration file, and an alarm rule library.

3. The method according to claim 1, characterized in that, The steps for regenerating the diagnostic map include: Periodically query the local monitoring software for the hardware configuration version identifier; The obtained version identifier is compared with the version identifier cached locally; When version identifiers are inconsistent, the diagnostic diagram regeneration process is automatically triggered.

4. The method according to claim 1, characterized in that, The steps of the diagnostic server pushing real-time data to the web server include: Real-time data of diagnostic tag numbers is received through a change push mechanism; All diagnostic tag numbers are centrally mapped to a unified cache area. It is pushed to the web server using a batch transmission mechanism.

5. The method according to claim 4, characterized in that, The batch transmission mechanism includes: compressing the data using a data compression algorithm and encrypting the data packets using an encryption protocol.

6. The method according to claim 1, characterized in that, The steps for generating the alarm information include: The alarm rule base includes a pre-configured correspondence between alarm conditions and alarm levels; The diagnostic service will match and calculate the received real-time data with the alarm conditions; When any alarm condition is met, an alarm message containing the alarm level, alarm source device, and trigger value is generated and pushed to the Web service.

7. The method according to claim 1, characterized in that, Upon receiving the alarm information, the web server does not cache it locally but immediately pushes the alarm information to the connected client for visual display; the visual display includes at least one of pop-up prompts, color indicators, and sound and light alerts.

8. A front-end diagnostic diagram automatic generation device, characterized in that, include: At least one diagnostic server is deployed in the field analysis room and configured to acquire the hardware configuration information of the device through local monitoring software, automatically generate diagnostic diagrams based on the built-in diagnostic diagram template library, monitor changes in hardware configuration and regenerate diagnostic diagrams, subscribe to changes in diagnostic tag numbers and push them to the local monitoring software, and automatically generate alarm information based on real-time data. The web server, located in the central control room, is configured to receive and cache diagnostic diagrams sent by the diagnostic server, respond to diagnostic diagram access requests from clients, and forward alarm information to clients. The diagnostic server is connected to the web server via a network, and the web server communicates with the client via the HTTP protocol.

9. The apparatus according to claim 8, characterized in that, The diagnostic server includes: The configuration acquisition module is used to acquire hardware configuration information from local monitoring software; The diagnostic diagram generation module is used to generate diagnostic diagrams based on the diagnostic diagram template library and hardware configuration information. The version detection module is used to monitor hardware configuration changes and trigger diagnostic graph updates; The data subscription module is used to subscribe to push notifications of changes in diagnostic tag numbers; The alarm processing module is used to generate alarm information based on real-time data.

10. The apparatus according to claim 8, characterized in that, The web server includes: The cache management module is used to store and manage diagnostic graphs sent by the diagnostic server. The access service module is used to respond to the client's diagnostic graph access request, retrieve the corresponding diagnostic graph from the local cache and return it; The alarm forwarding module is used to forward alarm information to the client.

Images