Operator station operating system and control method

Abstract

This application discloses an operator station operation system and control method. The system includes: a client, used to receive data acquisition requests from users through a standard browser; and to send the data acquisition request to a web front-end service on the server; the web front-end service is used to send data acquisition requests to a web back-end service on the server; the web back-end service is used to respond to the data acquisition request, perform data collection, file access, and cluster management processing, obtain data acquisition results, and send the data acquisition results back to the web front-end service. Thus, the web front-end service can render and display the operator station screen in the client's standard browser based on the data acquisition results obtained from the web back-end service, using a compiled language (such as C++). By deploying all installation files on the server, centralized management of deployment files is achieved, and the client does not need to deploy any files; it only needs a standard browser to access the web version of the operator station screen over the network.

Description

Technical Field

[0001] This application relates to the field of nuclear power technology, and in particular to an operator station operation system and control method. Background Technology

[0002] To ensure the safe operation of equipment at nuclear power plants, real-time monitoring of the equipment is necessary. The operator station is a crucial interface for information exchange between nuclear power plant equipment and operators, reflecting the real-time operating status of the equipment and providing a basis for operators to take appropriate measures.

[0003] Currently, to ensure timely and accurate display of the operational status of nuclear power plant equipment, operator stations typically employ a multi-terminal, independent deployment approach. Operator station software is developed based on WinForms or Qt frameworks and runs as desktop applications on terminals running operating systems such as Windows or Linux. This necessitates the deployment of a large number of terminals; for example, the main control room of just one nuclear power plant unit may require dozens of operator stations. Because each terminal operates independently, each deployment and software upgrade requires individual checks on all nodes, failing to meet agile operation and maintenance requirements and reducing deployment efficiency. Furthermore, the number of terminal nodes cannot be dynamically added or removed; adding new operator station nodes requires repeated software installation and configuration, further reducing scalability. Additionally, the client's strong dependence on local CPU / GPU performance and operating system leads to hardware binding issues and poor cross-platform compatibility. Summary of the Invention

[0004] In view of the above problems, this application provides an operator station operating system and control method, which can deploy all installation files on the server side, eliminating the need for clients to deploy any files. Clients only need a standard browser to access the web-based operator station screen via the network. This achieves centralized management of deployment files, and updates to the configuration screen only need to be performed on the server side, with immediate effects on the client side. High-availability cluster support is also provided, ensuring operational continuity through server-side load balancing and session persistence. The specific solution is as follows:

[0005] In a first aspect, embodiments of this application provide an operator station operation system, the system comprising: a client and a server; the server comprising a web front-end service and a web back-end service;

[0006] The client is configured to receive data acquisition requests from users through a standard browser and send the data acquisition requests to the web front-end service in the server.

[0007] The web front-end service is used to send the data acquisition request to the web back-end service; and based on the data acquisition result obtained from the web back-end service, to render and display the operator station screen in the client's standard browser using a compiled language;

[0008] The web backend service is used to respond to the data acquisition request, perform data collection, file access and cluster management processing, obtain the data acquisition result, and send the data acquisition result to the web frontend service.

[0009] In one possible implementation, the data communication method of the operator station operating system is based on an event-driven model design.

[0010] In one possible implementation, after the operator station operating system starts the software, it simultaneously starts an interface refresh thread and a data refresh thread; the data acquisition process in the data refresh thread and the UI screen refresh process in the interface refresh thread are decoupled.

[0011] In one possible implementation, the web front-end service includes a data cache;

[0012] The web front-end service is also used to respond to the data retrieval request by searching for the required data from the data cache as the data retrieval result.

[0013] In one possible implementation, the web front-end service is used to send the data acquisition request to the web back-end service, specifically including:

[0014] The web front-end service is used to send the data retrieval request to the web back-end service via HTTP API or WebSocket data interaction.

[0015] In one possible implementation, the web front-end service is used to send the data acquisition request to the web back-end service; and based on the data acquisition result obtained from the web back-end service, to render and display the operator station screen in the client's standard browser using a compiled language, specifically including:

[0016] The web front-end service is used to send the data acquisition request to the web back-end service; and based on the data acquisition result obtained from the web back-end service, to write the operator station business logic using C++ language and Qt framework; then to cross-compile the C++ code into WebAssembly binary instruction format using the Emscripten toolchain; and finally, to render and display the operator station screen in the client's standard browser using the generated file along with JavaScript glue code and HTML entry file.

[0017] In one possible implementation, the server further includes a load balancer.

[0018] The load balancing server is used to distribute data acquisition requests to different servers according to a preset weight ratio, thereby realizing cluster management of the servers; the data acquisition request is an HTTP request or a WebSocket connection; the load balancing server is configured in a primary / backup mode.

[0019] Secondly, embodiments of this application provide a method for controlling an operator station operating system, the method being used to control the operator station operating system as described in the first aspect above, the method comprising:

[0020] The client receives data retrieval requests from users through a standard browser and sends the data retrieval requests to the web front-end service on the server.

[0021] The data retrieval request is sent from the web front-end service to the web back-end service.

[0022] In response to the data acquisition request, data collection, file access and cluster management are performed through the Web backend service to obtain the data acquisition result, and the data acquisition result is sent to the Web frontend service.

[0023] Using a web front-end service, based on the data acquisition results, the operator station screen is rendered and displayed in the client's standard browser using a compiled language.

[0024] Thirdly, embodiments of this application also provide an operator station operation system control device, including: a processor, a memory, and a system bus;

[0025] The processor and the memory are connected via the system bus;

[0026] The memory is used to store one or more programs, the one or more programs including instructions, which, when executed by the processor, cause the processor to perform any of the above-described operator station operation system control methods.

[0027] Fourthly, embodiments of this application also provide a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform any of the above-described operator station operation system control methods.

[0028] Fifthly, embodiments of this application also provide a computer program product, which, when run on a terminal device, causes the terminal device to execute any one of the above-described operator station operation system control methods.

[0029] This application provides an operator station operation system and control method. The system includes a client and a server. The server includes a web front-end service and a web back-end service. The client is used to receive a data acquisition request from a user through a standard browser and send the data acquisition request to the web front-end service on the server. The web front-end service is used to send the data acquisition request to the web back-end service. The web back-end service is used to respond to the data acquisition request by performing data collection, file access, and cluster management processing to obtain the data acquisition result and send the data acquisition result to the web front-end service. Thus, the web front-end service can render and display the operator station screen in the client's standard browser based on the data acquisition result obtained from the web back-end service using a compiled language (such as C++).

[0030] As can be seen, because this application pre-deploys all installation files on the server, the client does not need to deploy any files; it only requires a standard browser to access the web-based operator station screen via the network. This achieves centralized management of deployment files, and updates to the configuration screen only need to be performed on the server, with immediate effects on the client. Furthermore, it provides high-availability cluster support, ensuring operational continuity through server-side load balancing and session persistence. Attached Figure Description

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

[0032] Figure 1 A structural diagram of an operator station operation system provided in this application embodiment;

[0033] Figure 2 A schematic diagram of the communication process based on the event-driven model provided in this application embodiment;

[0034] Figure 3 This is a schematic diagram illustrating the process of retrieving required data from a data cache, provided in an embodiment of this application.

[0035] Figure 4 A schematic diagram illustrating the communication process between the Web front-end service and the Web back-end service provided in the embodiments of this application;

[0036] Figure 5 A schematic diagram illustrating the high availability implementation process of the server cluster provided in this application embodiment;

[0037] Figure 6 A flowchart illustrating an operator station operation system control method provided in this application embodiment;

[0038] Figure 7 This is a schematic diagram of the structure of an operator station operation system control device provided in an embodiment of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] In existing nuclear power plant digital control systems (Distributed Control Systems, DCS), the operator station is the core of human-machine interaction. It directly faces the on-site operators and its main functions are to monitor the unit's operating status in real time in the form of text, graphics, sound and light, intelligently manage hierarchical alarms, remotely control and intervene, trace historical data and trends, and perform system diagnosis and maintenance.

[0041] Currently, to ensure timely and accurate display of nuclear power plant equipment operating status, operator stations typically employ a multi-terminal independent deployment approach. Operator station software is developed based on WinForms or Qt frameworks and runs as a desktop application on computer terminals running operating systems such as Windows or Linux. During deployment, a dedicated software installation package needs to be installed on each terminal computer. Then, the engineer station uses a file transfer protocol (FTP) to sequentially download the configured screen files and engineering data files to all operator station nodes. Each operator station node independently parses the screen files and engineering data files, establishing a connection with the server via TCP / IP or other proprietary protocols to obtain production data. This deployment method has at least the following four shortcomings:

[0042] (1) High deployment and maintenance costs: All terminals need to be installed and maintained one by one, and configuration updates require manual intervention for each node, which is time-consuming, labor-intensive and prone to errors.

[0043] (2) Poor cross-platform compatibility: Traditional desktop applications rely on specific operating system environments and are difficult to run flexibly on mobile terminals, different operating systems or diskless workstations.

[0044] (3) Low resource utilization: Each client runs independently and cannot utilize the server's computing resources for unified management and load balancing.

[0045] (4) Slow fault recovery: When a single node fails, it often requires on-site handling and lacks a seamless switching mechanism.

[0046] To address these shortcomings, this application provides an operator station operation system, comprising a client and a server. The server includes a web front-end service and a web back-end service. The client receives data acquisition requests from users through a standard browser and sends these requests to the web front-end service on the server. The web front-end service sends data acquisition requests to the web back-end service. In response to the data acquisition requests, the web back-end service performs data collection, file access, and cluster management processing to obtain data acquisition results, and sends these results back to the web front-end service. Thus, the web front-end service can render and display the operator station screen in the client's standard browser using a compiled language (such as C++) based on the data acquisition results obtained from the web back-end service.

[0047] As can be seen, because this application pre-deploys all installation files (such as all static resources (HTML, JS, Wasm, images) and backend services) on the server, the client does not need to deploy any files. A standard browser is sufficient to access the web-based operator station screen via the network and obtain the latest version of the complete operator station functionality. That is, the client browser can automatically pull and parse the latest configuration data upon startup, realizing an agile operation and maintenance mechanism of "one update, instant effect across the entire network." This achieves centralized management of deployment files, and updates to the configuration screen only need to be performed on the server side, with immediate effect on the client. Furthermore, it provides high-availability cluster support, ensuring operational continuity through server-side load balancing and session persistence.

[0048] See Figure 1This is a structural diagram of an operator station operating system provided in this embodiment. The system adopts a standard B / S (Browser / Server) architecture, specifically including: client 101 and server 102 (including Web front-end service 1021 and Web back-end service 1022). It implements a mechanism of "centralized management by server 102 and zero installation by client 101," ensuring that configuration screen and logic updates only need to be executed once on server 102, and all client 101 browser access takes effect immediately, thereby significantly reducing maintenance complexity. It overcomes the shortcomings of existing technologies that require independent installation of dedicated software on each terminal and updating configuration files one by one, resulting in time-consuming, labor-intensive, and error-prone maintenance, thus improving software deployment and upgrade efficiency.

[0049] The client 101 is used to receive data acquisition requests from users through a standard browser (referring to a browser that strictly follows the Web standards (such as HTML5, CSS3, WebGL, etc.) set by international standards organizations to parse and render web pages); and send the data acquisition request to the Web front-end service 1021 in the server 102.

[0050] This allows the operator station software to run seamlessly on any terminal device equipped with a standard browser, breaking hardware limitations and supporting flexible access via wireless networks. It solves the problems of high availability and seamless failover in the event of a single node failure. It also overcomes the limitations of existing desktop applications that cannot run flexibly on diskless workstations, mobile terminals, or different operating systems (such as Linux, macOS, and Android), thus resolving the strong dependence of the operator station system on specific operating systems and hardware environments.

[0051] It should be noted that this application does not limit the language type of the data acquisition request; for example, the data acquisition request can be Chinese text or English text. This application also does not limit the length of the data acquisition request; that is, the data acquisition request can be sentence text (i.e., a collection of words) or passage text (i.e., a collection of sentences). Furthermore, this application does not limit the content of the data acquisition request; for example, the data acquisition request can be "query reactor power," "query the trend of a certain parameter over a past period," or "query currently triggered or historical alarm information, including alarm items, parameter values, and setting values," etc.

[0052] The server-side component 102 (including Web front-end service 1021 and Web back-end service 1022) can be designed as a single unit or a cluster. Web front-end service 1021 is responsible for screen display and user interaction, while Web back-end service 1022 is responsible for data acquisition and control. System security and complex calculations are handled by Web back-end service 1022. Client 101 communicates with Web front-end service 1021 and Web back-end service 1022 through standardized interfaces, achieving a loosely coupled, highly cohesive B / S architecture.

[0053] Specifically, Web front-end service 1021 is the interface layer for direct user interaction. Users can connect to Web front-end service 1021 through their client's browser to submit data retrieval requests. Web front-end service 1021 then sends the data retrieval request to Web back-end service 1022. Based on the data retrieval results obtained from the Web back-end service, the operator station screen is rendered and displayed in the client's standard browser using a compiled language (such as C++). This is mainly used for screen display and dynamic logic processing to achieve human-computer interaction. For Web front-end service 1021, its core is to adopt the Qt for WebAssembly technology route. The operator station business logic (application) is written using the C++ language and Qt framework, and then the C++ code is cross-compiled into WebAssembly (.wasm) binary instruction format (which can be represented as a "module") through the Emscripten toolchain. This module is embedded in a lightweight HTML page and loaded and initialized in the browser by JavaScript glue code. The final generated file, together with the JavaScript glue code and the HTML entry file, can then be used to render and display the operator station screen in the client's standard browser. This achieves near-native execution speed for screen rendering, dynamic logic calculations, and user interaction in the browser.

[0054] This approach allows for execution environments based on compiled languages ​​(such as C++) that run directly in the browser, achieving the smoothness and real-time performance of native desktop applications in standard browsers. This overcomes the stuttering, frame drops, and response delays caused by the low execution efficiency of interpreted languages ​​and garbage collection mechanisms in existing JavaScript / HTML5-based B / S solutions when handling large-scale dynamic primitives, high-frequency real-time data refreshes, and complex graphics calculations in nuclear power plants. It also solves the execution efficiency bottleneck of industrial-grade high-performance graphics rendering in a web environment.

[0055] like Figure 1As shown, the Web backend service 1022 primarily responds to data acquisition requests sent by the Web frontend service 1021, performs data collection, file access, and cluster management, obtains the data acquisition results, and sends these results back to the Web frontend service for display on the user screen. The Web backend service 1022 is an independently deployable, resident memory service process. It does not directly interact with the user but acts as a bridge between the Web frontend service 1021 and the L2 server, undertaking the core tasks of data acquisition, file services, and business coordination. Among these, as... Figure 1 As shown, the Web front-end service 1021 and the Web back-end service 1022 can communicate with each other via HTTP or WebSocket.

[0056] It should be noted that, in order to endow the system with powerful capabilities of high concurrency, high availability, easy scalability and asynchronous processing, an optional implementation method is to design the data communication method of the operator station running system based on an event-driven model.

[0057] Specifically, in this implementation, such as Figure 2 As shown, the operator station operating system is designed as an event-driven model. Components communicate through the generation and transmission of events. One component can notify other components by sending signals (events), and other components can respond to these events by connecting signals and slots (event handling functions). To enable screen configuration in the graphical configuration software and run in the operator station environment, Qt's scripting engine (QJSEngine) is used to achieve collaborative processing between C++ code and JavaScript scripts. When the screen and its built-in scripts are loaded, all graphic elements in the screen are exposed as global objects in the JavaScript runtime environment (QJSEngine) to which the screen belongs. This allows for the control logic and functions to be controlled via scripts.

[0058] For example, in a "high-level tank alarm" scenario, the operator station screen includes a "tank" element and an "alarm indicator" element. When the system is running, the C++ side is responsible for collecting real-time level data and injecting the tank and alarm indicator elements as global objects into the QJSEngine JavaScript runtime environment. When the tank level changes, the C++ object emits a signal carrying the current level value. The JavaScript script running in QJSEngine listens for this signal through a pre-established connection and automatically triggers the event handler function. Inside the event handler function, the script determines whether the level exceeds the safety threshold. If it does, it calls a method of the alarm indicator object to make it turn red and flash; if it is normal, it returns to green. The event handler function can be adjusted through configuration.

[0059] In this way, through the aforementioned communication mechanism, the C++ and JavaScript sides can flexibly handle UI interaction and business logic via events. This design not only achieves complete decoupling between the underlying data and the upper-level interface, but also endows the operator station with strong dynamic expansion capabilities, making screen configuration and logic control more flexible.

[0060] Another alternative implementation is a concurrent model where the UI refresh thread and data refresh thread are separated. The data thread is responsible for asynchronously acquiring real-time data via WebSocket and updating it to the front-end memory cache, while the UI thread independently reads data from the cache and renders it; the two do not block each other. In other words, after the operator station system starts, the UI refresh thread and data refresh thread can be started in parallel; the data acquisition process in the data refresh thread and the UI refresh process in the UI refresh thread are decoupled.

[0061] Specifically, in this implementation, the attributes of graphic elements in the screen can be bound to a variable to achieve dynamic logic. When the value of this variable changes, the graphic element attributes are automatically modified. After the software starts, two threads are launched: a UI refresh thread and a data refresh thread. The UI refresh thread periodically reads the attribute values ​​from the graphic element attribute database and then re-renders them to the screen. The data refresh thread accesses the real-time data server through the network interface of the data service layer and stores the acquired real-time point values ​​in the data cache. The screen does not directly access the data server but reads data from the data cache. This decouples data acquisition and UI refresh, preventing UI lag due to waiting for data.

[0062] As can be seen, this data-driven screen update method implemented in the WebAssembly environment not only includes establishing a front-end data cache, but also periodically synchronizing data from the server to the cache through an independent thread, and the interface rendering thread directly reading attribute values ​​from the local cache to redraw primitives, thereby eliminating the impact of network I / O wait on UI frame rate.

[0063] Furthermore, it should be noted that, as the operator station serves as the interface for human-computer interaction, it has high real-time requirements. As an optional implementation, this application also sets up a data cache in the web front-end service. This cache is designed to retrieve the required data from the data cache in response to data retrieval requests, serving as the data retrieval result. This improves data access speed, reduces the frequency of server access, and thus improves the overall data refresh efficiency of the operator station. This achieves the goal of reducing latency and maintaining data consistency.

[0064] Specifically, in this implementation, such as Figure 3As shown, initially, the data cache and requested data items are empty. When a user submits a data retrieval request through the standard browser in the client, the system first checks the data cache for the required data. If the data is found, it is read from the cache and returned to the user directly through the client's standard browser. If the data cache does not contain the data, a data retrieval request is sent to the server (specifically, a data retrieval request is sent to the Web backend service, which then sends a data retrieval request to the (L2) server to obtain the required data). Simultaneously, the requested data item is added to the requested data items in the data cache. The data returned by the server (specifically, by the Web backend service) is stored in the data cache and returned to the user through the client's standard browser. When the requested data items in the data cache are not empty, data is periodically requested from the server, and the data cache is updated. Furthermore, if no new requests are made for a particular item within a certain timeframe, that item is deleted to avoid prolonged requests for invalid data and to save system resource overhead.

[0065] This implements an intelligent data request management algorithm. The system dynamically maintains a "list of requested data items," initiates network requests only when the cache is missing, and automatically removes subscriptions for data items that have not been accessed for a long time, reducing invalid network traffic, thereby reducing server load and improving data consistency.

[0066] Additionally, it should be noted that because Webassembly programs run in a secure sandbox mode within a browser environment, they cannot directly access external interfaces or read / write files. These functionalities must be handled by a backend web service. Therefore, this application designs two data interaction methods—HTTP API and WebSocket—for communication between the web frontend service and the web backend service, tailored to different application scenarios. This allows the web frontend service to send data retrieval requests to the web backend service via HTTP API or WebSocket, and to retrieve the data retrieval results from the web backend service through the corresponding interaction method. Figure 4 As shown.

[0067] The HTTP API is used for logging, reading configuration files, etc. When a screen is opened and logging occurs, the web frontend service sends a data retrieval request to the web backend service via the HTTP interface. The web backend service receives the request and processes it accordingly based on the request type. It is a request-response communication protocol. It uses non-persistent connections, requiring a new TCP connection to be established for each request. It is suitable for applications with small data volumes and infrequent updates.

[0068] WebSocket is used to retrieve server data, etc. After the software starts, the web front-end service establishes a persistent connection with the web back-end service through WebSocket, and allows the web back-end service to actively push data to the web front-end service. It is suitable for large-volume or high-frequency data communication with high real-time requirements.

[0069] Furthermore, to improve the data processing efficiency of the operator station operating system, a highly available server cluster can be used to ensure operational continuity through server-side load balancing and session persistence. Specifically, one optional implementation is to configure a load balancer on the server side to distribute data retrieval requests to different servers according to a preset weight ratio, thereby achieving cluster management of the servers. The data retrieval requests can be HTTP requests or WebSocket connections; and the load balancer can be configured in a primary / backup mode to ensure service continuity.

[0070] In this implementation, such as Figure 5 As shown, multiple web application servers and load balancers can be deployed on the server side as needed (i.e., configured in primary / backup mode), providing a virtual IP address to the client. The load balancer deploys Nginx to implement reverse proxy functionality, distributing data retrieval requests (such as HTTP requests and WebSocket connections) from client browsers to different web application servers according to preset weight ratios (each web application server in the cluster deploys a complete web front-end service and a web back-end service). A Keepalived service is also deployed to monitor the health status of the load balancer (Nginx) itself in real time. Verification rules are defined by writing verification scripts, and when a node fails, it is automatically removed from the service list. To improve system fault tolerance, the load balancer is configured in primary / backup mode. When the primary load balancer fails, the virtual IP address automatically migrates to the backup server, achieving "seamless failover" and ensuring service continuity. Furthermore, each web application server deploys complete web front-end and web back-end services, capable of independently responding to and processing data retrieval requests (such as HTTP requests and WebSocket connections) from client browsers, completing tasks such as business logic processing, data collection, configuration file reading and writing, and logging. Depending on the business load, horizontal scaling can be achieved by increasing the number of web application servers, ensuring the system maintains high efficiency and stability even under high concurrency scenarios.

[0071] This high-availability architecture based on server-side clustering and load balancing enables automatic removal of faulty nodes and virtual IP migration, ensuring that operator stations can maintain continuous monitoring and control capabilities even in the event of partial server failures or network fluctuations, thus guaranteeing the safe operation of the nuclear power plant. This solves the problems of single-point failures causing operational interruptions and the lack of automatic fault tolerance and load balancing mechanisms in traditional architectures.

[0072] As can be seen, this application employs an Nginx reverse proxy combined with a Keepalived master-slave failover mechanism to construct a multi-node web application server cluster. By monitoring node status in real time through health check scripts, automatic fault removal and virtual IP migration are achieved, enabling dynamic distribution of HTTP / WebSocket connections, automatic isolation of faulty nodes, and uninterrupted service migration, thereby ensuring service continuity.

[0073] In summary, this embodiment provides an operator station operation system, including a client and a server; the server includes a web front-end service and a web back-end service; wherein, the client is used to receive a data acquisition request from a user through a standard browser and send the data acquisition request to the web front-end service in the server; the web front-end service is used to send the data acquisition request to the web back-end service; the web back-end service is used to respond to the data acquisition request, perform data collection, file access and cluster management processing, obtain the data acquisition result, and send the data acquisition result to the web front-end service. In this way, the web front-end service can render and display the operator station screen in the client's standard browser based on the data acquisition result obtained from the web back-end service, using a compiled language (such as C++).

[0074] As can be seen, because this application pre-deploys all installation files on the server, the client does not need to deploy any files; it only requires a standard browser to access the web-based operator station screen via the network. This achieves centralized management of deployment files, and updates to the configuration screen only need to be performed on the server, with immediate effects on the client. Furthermore, it provides high-availability cluster support, ensuring operational continuity through server-side load balancing and session persistence.

[0075] See Figure 6 This is a flowchart illustrating an operator station operation system control method provided in this embodiment. This method can be used to control systems such as... Figure 1 The operator station operating system shown includes the following steps:

[0076] S601: Receives data retrieval requests from users through a standard browser on the client side; and sends the data retrieval requests to the web front-end service on the server side.

[0077] In this embodiment, as Figure 1 In the operator station system of the B / S architecture shown, users can submit data acquisition requests (such as "querying the trend of a parameter over a period of time") through a standard browser in any client 101 (such as a mobile phone, tablet computer, or client n) using voice or text input. After receiving the data acquisition request from the user through the standard browser in client 101, the data acquisition request can be sent to the Web front-end service 1021 in server 102 to execute the subsequent step S602.

[0078] S602: Send a data retrieval request to the Web backend service through the Web frontend service.

[0079] In this embodiment, after receiving the data acquisition request from the user through the standard browser in the client 101 in step S601, the web front-end service 1021 can further use data interaction methods such as HTTP API or WebSocket to send the data acquisition request to the web back-end service 1022 to execute the subsequent step S603.

[0080] S603: In response to a data acquisition request, perform data collection, file access, and cluster management processing through the Web backend service to obtain the data acquisition results, and send the data acquisition results to the Web frontend service.

[0081] In this embodiment, after receiving a data acquisition request sent by the Web front-end service 1021 through data interaction methods such as HTTP API or WebSocket in step S602, in response to the data acquisition request, the Web back-end service 1022 can connect to the (L2) server to perform data collection, file access and cluster management processing, obtain the data acquisition result, and send the data acquisition result to the Web front-end service 1021 to execute the subsequent step S604.

[0082] S604: Utilizing a web front-end service, based on the data acquisition results, the operator station screen is rendered and displayed in the client's standard browser using a compiled language.

[0083] In this embodiment, after sending the data acquisition result to the Web front-end service 1021 in step S603, the Web front-end service can further be used to render and display the operator station screen in the client's standard browser based on the data acquisition result and compiled languages ​​such as C++.

[0084] It should be noted that the detailed combination function and implementation process of each component in the operator station operation system can be found in the above system embodiment, and will not be repeated here.

[0085] Thus, by executing the above steps S601-S604, the following is achieved: Figure 1 The effective control of the operator station operating system shown, compared to existing operator stations, can achieve beneficial effects including but not limited to the following four points:

[0086] (1) Operation and maintenance efficiency is significantly improved, enabling agile delivery.

[0087] Existing technologies require manual intervention on dozens or even hundreds of terminals for each upgrade at operator stations, taking hours and being prone to errors. This application, however, achieves "one-time server-side update, instant plant-wide effect." Configuration modifications or software upgrades only require server-side operations; the client simply refreshes the page to complete the update. This reduces maintenance time from hours to minutes, completely eliminating the cost and risk of deploying to each terminal individually.

[0088] (2) Truly cross-platform and zero-dependency, with extremely strong terminal adaptability.

[0089] Existing technologies heavily rely on specific Windows / Linux environments and local runtime libraries, making them unusable on tablets, mobile phones, or diskless workstations. This application, however, requires no plugins or local environment installation; it runs with just a standard browser, supports multiple terminals including PCs, tablets, and mobile phones, and can even be accessed via wireless networks, greatly enhancing system flexibility and emergency response capabilities.

[0090] (3) Performance comparable to native, breaking through the Web performance bottleneck.

[0091] Existing technologies often experience lag when processing complex scenes from nuclear power plants. This application utilizes WebAssembly technology, enabling C++ code and other code to execute in a browser at near-native machine code speeds. Combined with a decoupled design for data acquisition and UI refresh, as well as a data caching design, it meets the stringent real-time requirements of nuclear power plants.

[0092] (4) High availability and elastic expansion, resulting in higher system reliability.

[0093] In existing technologies, a single node failure often renders the terminal unusable. This application, however, achieves multi-node redundancy through server-side clustering and load balancing. When a server fails, the system automatically switches traffic to a healthy node without the user noticing. Simultaneously, it supports dynamically adding server nodes based on load, easily handling high-concurrency scenarios, thereby significantly improving the overall reliability and disaster recovery capabilities of the system.

[0094] Furthermore, embodiments of this application also provide an operator station operation system control device, including: a processor, a memory, and a system bus;

[0095] The processor and the memory are connected via the system bus;

[0096] The memory is used to store one or more programs, the one or more programs including instructions, which, when executed by the processor, cause the processor to perform any of the above-described implementations of the operator station operation system control method.

[0097] refer to Figure 7 The diagram illustrates a structural schematic suitable for implementing the operator station operation system control device in the embodiments of this application. The operator station operation system control device in the embodiments of this application may include, but is not limited to, terminals, cloud platforms, servers, and server clusters. Figure 7 The operator station operating system control device shown is merely an example of an electronic device and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0098] like Figure 7 As shown, the operator station operating system control device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. When the operator station operating system control device is powered on, the RAM 703 also stores various programs and data required for device operation. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0099] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 708 including, for example, memory cards, hard drives, etc.; and communication devices 709. Communication device 709 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 The operator station operating system control equipment with various devices is shown; however, it should be understood that implementation or possession of all the devices shown is not required. More or fewer devices may be implemented or possessed alternatively.

[0100] Furthermore, embodiments of this application also provide a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to perform any of the above-described implementations of the operator station operation system control method.

[0101] Furthermore, this application also provides a computer program product, which, when run on a terminal device, causes the terminal device to execute any of the above-described implementation methods of the operator station operation system control method.

[0102] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a media gateway, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0103] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0104] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0105] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An operator station operation system, characterized in that, The system includes: a client and a server; the server includes a web front-end service and a web back-end service. The client is configured to receive data acquisition requests from users through a standard browser and send the data acquisition requests to the web front-end service in the server. The web front-end service is used to send the data acquisition request to the web back-end service; and based on the data acquisition result obtained from the web back-end service, to render and display the operator station screen in the client's standard browser using a compiled language; The web backend service is used to respond to the data acquisition request, perform data collection, file access and cluster management processing, obtain the data acquisition result, and send the data acquisition result to the web frontend service.

2. The system according to claim 1, characterized in that, The data communication method of the operator station operating system is based on the event-driven model design.

3. The system according to claim 1, characterized in that, After the operator station operating system starts the software, it simultaneously starts the interface refresh thread and the data refresh thread; the data acquisition process in the data refresh thread and the UI screen refresh process in the interface refresh thread are decoupled.

4. The system according to claim 1, characterized in that, The web front-end service includes data caching; The web front-end service is also used to respond to the data retrieval request by searching for the required data from the data cache as the data retrieval result.

5. The system according to claim 4, characterized in that, The web front-end service is used to send the data acquisition request to the web back-end service, specifically including: The web front-end service is used to send the data retrieval request to the web back-end service via HTTP API or WebSocket data interaction.

6. The system according to any one of claims 1-5, characterized in that, The web front-end service is used to send the data acquisition request to the web back-end service; and based on the data acquisition result obtained from the web back-end service, to render and display the operator station screen in the client's standard browser using a compiled language, specifically including: The web front-end service is used to send the data acquisition request to the web back-end service; and based on the data acquisition result obtained from the web back-end service, to write the operator station business logic using C++ language and Qt framework; then to cross-compile the C++ code into WebAssembly binary instruction format using the Emscripten toolchain; and finally, to render and display the operator station screen in the client's standard browser using the generated file along with JavaScript glue code and HTML entry file.

7. The system according to any one of claims 1-5, characterized in that, The server also includes: a load balancer; The load balancing server is used to distribute data acquisition requests to different servers according to a preset weight ratio, thereby realizing cluster management of the servers; the data acquisition request is an HTTP request or a WebSocket connection; the load balancing server is configured in a primary / backup mode.

8. A control method for an operator station operation system, characterized in that, The control method employs the operator station operation system as described in any one of claims 1 to 6, and the method includes: The client receives data retrieval requests from users through a standard browser and sends the data retrieval requests to the web front-end service on the server. The data retrieval request is sent from the web front-end service to the web back-end service. In response to the data acquisition request, data collection, file access and cluster management are performed through the Web backend service to obtain the data acquisition result, and the data acquisition result is sent to the Web frontend service. Using a web front-end service, based on the data acquisition results, the operator station screen is rendered and displayed in the client's standard browser using a compiled language.

9. A control device for an operator station operating system, characterized in that, include: Processor, memory, system bus; The processor and the memory are connected via the system bus; The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform the method of claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a terminal device, cause the terminal device to perform the method of claim 8.

Images