SCADA web HMI system and HMI client

Abstract

The web browser (5) causes the communication thread (7) and the DOM update thread (6) to operate in parallel. When signal data having the same inherent identifier as the received signal data already exists in the cache area, the communication thread (7) overwrites the signal data stored in the cache area with the received signal data. When the communication thread (7) receives a signal data request event from the DOM update thread (6), it sends all the signal data stored in the cache area to the DOM update thread (6). The DOM update thread (6) updates the DOM for all the signal data. After the DOM is updated, the DOM update thread (6) sends the signal data request event to the communication thread and updates the display content of the display component displayed on the web browser (5) based on the updated DOM.

Description

Technical Field

[0001] The present invention relates to a SCADA web page HMI system and an HMI client. Background Art

[0002] SCADA (Supervisory Control and Data Acquisition) is a well-known mechanism for monitoring and controlling social infrastructure systems, such as steel rolling mills, power transmission and distribution systems, water and sewage systems, building management systems, and road systems.

[0003] SCADA is a type of industrial control system that performs computer-based system monitoring and process control. SCADA requires responsiveness (real-time performance) that matches the system's processing capabilities.

[0004] SCADA is usually composed of the following subsystems.

[0005] (1) HMI (Human Machine Interface)

[0006] HMI is a mechanism that presents data of a target process (monitoring target device) to an operator, allowing the operator to monitor and control the process. For example, Patent Document 1 discloses a SCADA HMI having an HMI screen that operates on a SCADA client.

[0007] (2) Monitoring and control system

[0008] The supervisory control system is composed of a Programmable Logic Controller (PLC), etc. The supervisory control system collects PLC data on the process and sends control commands to the process.

[0009] (3) Remote Input Output (RIO)

[0010] The remote input / output device is connected to sensors installed in the process, converts the sensor signals into digital data, and transmits the digital data to the monitoring and control system.

[0011] (4) Communication infrastructure

[0012] The communication infrastructure connects the supervisory control system with remote input and output devices.

[0013] Prior art literature

[0014] Patent Literature

[0015] Patent Document 1: Japanese Patent Application Laid-Open No. 2017-27211 Summary of the Invention

[0016] Problems to be solved by the invention

[0017] The client program of the HMI subsystem of Patent Document 1 is constructed from a program that depends on the machine environment. To reduce the cost of the SCADA HMI subsystem, the inventors of this application developed a browser-based SCADA HMI subsystem that is not dependent on the machine environment.

[0018] When a SCADA HMI subsystem is constructed using a web application that runs on a web browser, there are the following advantages.

[0019] (1) Since web browsers are installed in many terminal devices such as personal computers (PCs) and tablet PCs, various terminal devices can be used for the SCADA HMI subsystem.

[0020] (2) Web browsers have high-performance drawing capabilities and can easily embed highly interactive GUI functions such as animation.

[0021] The browser-based SCADA HMI subsystem has a web HMI server and an HMI client.

[0022] The web HMI server receives PLC data from the monitoring and control system. PLC data is categorized into alarm data and signal data. Alarm data, which indicates abnormalities in the monitored device and changes infrequently, is processed in a long-term cycle. Signal data, which indicates frequent changes in temperature, speed, and other indicators of the monitored device, is processed in a short-term cycle.

[0023] The HMI client executes a web browser, which receives alarm data and signal data from the web HMI server and displays a web page containing the data.

[0024] Typically, web applications running on a web browser update a data structure called the Document Object Model (DOM). The web browser then performs rendering based on the results of this DOM update. Therefore, the rendering process performed by the web browser is slower than native display processing, which directly uses the operating system's display interface.

[0025] By utilizing the functions of HTML5, it is also possible to use a rendering method such as WebGL for high-speed rendering. However, since the display logic becomes complicated, it is difficult to use WebGL for full display.

[0026] Alarm data is processed in a long cycle, and the interval between data transmission is long. Therefore, the web application can execute the rendering process of the alarm data without delay ( Figure 14 On the other hand, signal data is processed in a short cycle, and the data transmission interval is short. Therefore, when a large amount of signal data is sent, the web application may not be able to complete the rendering process of the signal data within the transmission interval.

[0027] Furthermore, in the case where DOM update processing is continuously executed in order to process a large amount of signal data, there is no time left to execute the rendering processing by the web browser ( Figure 15 If the rendering process is not performed, the signal data will not be reflected on the physical screen. Therefore, the display of the signal data on the physical screen may be delayed.

[0028] The present invention is made to solve the above-mentioned problems and aims to provide a SCADA web HMI system and HMI client that can suppress data display delays in a web browser even when a large amount of signal data exceeding the display performance of the HMI client is received.

[0029] Means used to solve problems

[0030] In order to achieve the above-mentioned object, the SCADA web HMI system according to the present invention is constructed as follows.

[0031] A SCADA web HMI system includes a web HMI server and an HMI client. The web HMI server transmits signal data that associates a unique identifier identifying a display component associated with a monitored object with a signal value received from a programmable logic controller connected to the monitored object. The HMI client displays an HMI screen with the display component configured on a web browser. The HMI client receives the signal data from the web HMI server and modifies the display content of the display component in response to the received signal data.

[0032] The HMI client includes a memory, a processor, and a display. The memory stores a program and temporarily stores the signal data in a cache area. The processor is configured to execute the program to cause a communication thread and a DOM update thread to operate in parallel in the web browser. The display displays the web browser.

[0033] The communication thread executes a receiving process, a cache overwriting process, and a cache sending process. The receiving process periodically receives the signal data from the web HMI server. The cache overwriting process overwrites the signal data stored in the cache area with the received signal data if the inherent identifier contained in the received signal data is the same as the inherent identifier contained in the signal data stored in the cache area. The cache sending process, upon receiving a signal data request event from the DOM update thread, sends a DOM update request event containing all the signal data stored in the cache area to the DOM update thread.

[0034] The DOM update thread executes DOM update processing and drawing processing. Upon receiving the DOM update request event, the DOM update thread updates the DOM based on all of the signal data included in the DOM update request event. After updating the DOM, the DOM update thread sends the signal data request event to the communication thread. The drawing process updates the display content of the display component displayed on the web browser based on the updated DOM.

[0035] Preferably, the communication thread further performs the following sending and caching processes. The sending process sends the DOM update request event containing the received signal data to the DOM update thread when the DOM update thread is stopped. The caching process stores the received signal data in the cache area when the DOM update thread is executing. The cache overwrite process is performed during the caching process.

[0036] Effects of the Invention

[0037] According to the present invention, the web browser operates the communication thread and the DOM update thread in parallel, thereby enabling data reception processing and rendering processing to be executed asynchronously.

[0038] Since the communication thread overwrites the signal data with the same identifier when buffering the received signal data, it can thin out the data only for the latest signal data, thereby preventing the buffer from overflowing.

[0039] After the DOM update process completes, the DOM update thread sends a signal data request event to the communication thread. The communication thread receives the signal data request event and sends the next signal data to the DOM update thread. Therefore, the DOM update thread is prevented from obtaining the next signal data until the DOM update process completes. Therefore, the DOM update process is not executed continuously, and the drawing process can be executed each time the DOM update process completes.

[0040] Thus, according to the present invention, the amount of signal data thinning is minimized while appropriately executing rendering processing, thereby maximizing the display performance of the HMI client. Therefore, according to the present invention, even when a large amount of signal data is received that exceeds the display performance of the HMI client, delays in data display by the web browser can be reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 This is a block diagram for explaining the system configuration of SCADA according to the first embodiment of the present invention.

[0042] Figure 2 This diagram explains the relationship between display components and signal data displayed on a web browser.

[0043] Figure 3 This is a diagram for explaining an example of the data structure of signal data.

[0044] Figure 4 It will Figure 3 The data structure shown is an example expressed in JSON.

[0045] Figure 5 This is a diagram for explaining processing when the HMI client 4 receives signal data while the DOM update thread is stopped.

[0046] Figure 6 This is a diagram for explaining processing when the HMI client 4 receives signal data during the DOM update thread operation.

[0047] Figure 7 This is a flowchart showing the signal data reception process.

[0048] Figure 8 This is a flowchart for explaining the signal data buffering process performed by the communication processing unit.

[0049] Figure 9 This is a diagram showing an example of storing data in a signal buffer.

[0050] Figure 10 This is a diagram for explaining the process of the DOM update thread acquiring the signal data temporarily stored in the signal buffer.

[0051] Figure 11 This is a flowchart used to explain the processing of the DOM update thread.

[0052] Figure 12 This diagram explains the timing of the DOM update thread requesting signal data and the timing of the drawing process.

[0053] Figure 13This is a block diagram showing an example of the hardware configuration of a web HMI server and an HMI client.

[0054] Figure 14 This is a diagram showing an example of processing alarm data in a related art.

[0055] Figure 15 It is a diagram showing an example of signal data processing in the related art. DETAILED DESCRIPTION

[0056] The following describes embodiments of the present invention in detail with reference to the accompanying drawings. However, when reference is made to the number, quantity, amount, range, or other numerical values ​​of various elements in the embodiments described below, the present invention is not limited to such numerical values ​​unless otherwise specifically stated or clearly defined in principle. Furthermore, the structures and the like described in the embodiments described below are not necessarily essential to the present invention unless otherwise specifically stated or clearly defined in principle.

[0057] Implementation method 1.

[0058] <Overall Structure>

[0059] Figure 1 This is a block diagram for explaining the system configuration of SCADA according to the first embodiment of the present invention.

[0060] SCADA subsystems include a human-machine interface 1 (HMI 1), a SCADA web HMI system, a programmable logic controller 2 (PLC 2), a supervisory control system, a communications infrastructure (not shown), and a remote input / output (RIO) (not shown). SCADA is connected to monitored devices (not shown) via the PLC 2 or the RIO.

[0061] The description of the PLC 2, the communication infrastructure, and the RIO is omitted because they are already described in the background art. The monitored device is a device (including sensors and actuators) that constitutes a plant.

[0062] The HMI 1 includes a SCADA web HMI server device 3 (hereinafter referred to as a web HMI server 3 ) and at least one HMI client terminal 4 (hereinafter referred to as an HMI client 4 ).

[0063] The web HMI server 3 is connected to the PLC 2 and the HMI client 4. The HMI client 4 executes a web browser 5. The web browser 5 displays an HMI screen. The HMI screen is composed of at least one image on which a display component displaying the status of a monitored device is arranged.

[0064] <Web HMI Server>

[0065] The web HMI server 3 is described below. Figure 13 As shown, the web page system includes a processor 100a and a memory 100b. The memory 100b stores a program for causing the processor 100a to function as a web page system when executed by the processor 100a. The web page system includes a PLC data processing unit 31, an alarm data generation unit 32, a signal data generation unit 33, and a communication processing unit 34.

[0066] The PLC data processing unit 31 receives PLC data from the PLC 2. The PLC data includes the signal values ​​of the monitored device input and output. The PLC data is classified into data used as alarm data and data used as signal data. The PLC data used as alarm data is transmitted to the alarm data generation unit 32. The PLC data used as signal data is transmitted to the signal data generation unit 33.

[0067] The alarm data generation unit 32 generates alarm data based on the received PLC data. Specifically, the alarm data generation unit 32 assigns an alarm identifier to the received PLC data according to each alarm type (major fault / moderate fault / minor fault), and also assigns alarm attributes such as the alarm status (occurred / recovered, unconfirmed / confirmed) and the alarm occurrence time to generate the alarm data.

[0068] The alarm data generator 32 also reads definition information (alarm list 22, alarm group list 23) of the HMI client 4 that defines alarms to be displayed for each alarm group. Based on the definition information, information on the HMI client 4 that should display the alarm is added to the alarm data.

[0069] The alarm data generating unit 32 transmits the generated alarm data to the communication processing unit 34 .

[0070] Alarm data may be generated in large quantities at once, associated with a single fault, but it does not change frequently within a certain period of time. Therefore, alarm data is generated over a long period of time. The interval for sending data from the alarm data generation unit 32 to the communication processing unit 34 is, for example, approximately 8 seconds.

[0071] The signal data generation unit 33 generates signal data based on the received PLC data. Specifically, the signal data generation unit 33 first reads the definition information (device list 21) used to associate the unique identifiers that identify the display components configured on the HMI screen with the PLC data. The unique identifier is a combination of a graphic ID (graphic name) and a component ID (symbol name) and is unique within the system.

[0072] The signal data generation unit 33 generates signal data that associates the unique identifier of the display component configured on the HMI screen with the signal value of the PLC data. The signal data generation unit 33 sends the generated signal data to the communication processing unit 34.

[0073] The signal data is data with a relatively high frequency of change such as the temperature or speed of the monitored device, and is required to be displayed on the screen of the HMI client 4 in real time. Therefore, the signal data is processed in a shorter cycle compared to the alarm data. The data transmission interval from the signal data generation unit 33 to the communication processing unit 34 is about the same as the communication interval of the PLC data from the PLC 2 to the PLC data processing unit 31. For example, it is about 50 ms.

[0074] The communication processing unit 34 sends the received alarm data and signal data to the communication processing unit 41 of each HMI client 4 using WebSocket communication. The communication processing unit 34 only sends data associated with each HMI client 4 through the filtering process 35.

[0075] In this way, the web HMI server 3 sends signal data to the HMI client 4 that associates the unique identifier of the display component regarding the monitored device with the signal value received from the PLC 2 connected to the monitored device.

[0076] <HMI Client>

[0077] As will be described later, the HMI client 4 Figure 13 is shown to include a processor 200a and a memory 200b as shown. The memory 200b stores programs that, when executed by the processor 200a, are used to make the processor 100a function as a web browser 5 and programs that are used to function as a web application operating on the web browser 5.

[0078] The HMI client 4 displays the HMI screen with the display component configured thereon on the web browser 5. The HMI client 4 receives signal data from the web HMI server 3. The HMI client 4 changes the display content of the display component corresponding to the unique identifier of the received signal data according to the signal value of the received signal data.

[0079] The HMI client 4 makes the DOM update thread 6 responsible for event processing and rendering processing and the communication thread 7 responsible for communication processing operate in parallel in the web browser 5. Multithreading can be implemented by Web Worker.

[0080] The web browser 5 can execute the communication processing unit 41, the alarm data DOM update processing unit 42, the signal data DOM update processing unit 43, and the rendering processing unit 44.

[0081] The communication processing unit 41, the alarm data DOM update processing unit 42, and the signal data DOM update processing unit 43 are implemented by a web application running on the web browser 5. This web application is written in JavaScript.

[0082] The rendering processing unit 44 is realized by a renderer (rendering engine) that the web browser 5 has in advance.

[0083] The communication thread 7 executes the processing of the communication processing unit 41 .

[0084] The communication processing unit 41 periodically receives alarm data and signal data from the web HMI server 3 (receiving process). Signal data is received at a shorter period than alarm data. The communication processing unit 41 transmits the alarm data received from the web HMI server 3 to the alarm data DOM update processing unit 42. The communication processing unit 41 transmits the signal data received from the web HMI server 3 to the signal data DOM update processing unit 43.

[0085] The DOM update thread 6 executes the processes of the alarm data DOM update processing unit 42 , the signal data DOM update processing unit 43 , and the rendering processing unit 44 .

[0086] The alarm data DOM update processing unit 42 and the signal data DOM update processing unit 43 reflect the data received respectively on the DOM. The rendering processing unit 44 displays the data expanded in the DOM on the HMI screen.

[0087] Next, refer to Figures 2 to 4 , supplementary explanation of display components and signal data.

[0088] Figure 2 This is a diagram for explaining the relationship between display components displayed on the web browser 5 and signal data.

[0089] A plurality of display components (symbols) are arranged in the diagram displayed as a web page (HMI screen) on the web browser 5. The display components include, for example, a bar graph 24, a numerical display component 25, and a color label component 26. Signal data is associated with the display components.

[0090] Signal data types include integer, floating point, and logical. Bar graph 24 is a component associated with integer signal data. The length of the bar in bar graph 24 changes according to the signal value. Numerical display 25 is a component associated with floating point signal data. The value in the text box of numerical display 25 changes according to the signal value. Color label 26 is a component associated with logical signal data. The color of color label 26 changes according to the signal value.

[0091] Figure 3 This is a diagram showing an example of the data structure for signal data.

[0092] Signal data is assigned to the display components of each diagram. For each diagram constituting the HMI screen, a graphic ID is assigned. Multiple display components are specified in the diagram. For each display component, a component ID is specified. Signal data is data that associates an inherent identifier combining the graphic ID and the component ID with the signal value of the PLC data.

[0093] As Figure 3 shown, one signal value can be associated with multiple display components. Signal data has a list of inherent identifiers combining the graphic ID and the component ID. This list is called the component ID list. This data structure is generated by the signal data generation unit 33 of the web HMI server 3.

[0094] Next, refer to Figure 4 to illustrate an example of representing the data structure of signal data using a data description language. As one of the data description languages, JavaScript Object Notation (JSON) is known. Figure 4 This is Figure 3 an example of representing the data structure shown using JSON.

[0095] <Structure of the Features of the HMI Client>

[0096] Next, refer to Figures 5 to 12 to illustrate the structure of the features of the HMI client 4 according to this embodiment.

[0097] In order to prevent the display of signal data on the web browser 5 from being delayed even when a large amount of signal data is received, the communication thread and the DOM update thread of the HMI client 4 perform the processing described below.

[0098] As described in Figure 1 , the web browser 5 makes the communication thread 7 and the DOM update thread 6 operate in parallel and asynchronously executes the data acquisition process and the rendering process.

[0099] Figure 5 This is a diagram for illustrating the processing when the HMI client 4 receives signal data while the DOM update thread is stopped. When the processing of the DOM update thread 6 is stopped, the communication thread 7 sends a DOM update request event including the received signal data to the DOM update thread 6 (sending process).

[0100] Figure 6This diagram illustrates the processing performed when signal data is received by the HMI client 4 during the DOM update thread. While the DOM update thread 6 is executing, the communication thread 7 stores the received signal data in a buffer area (signal buffer) reserved in the memory 200b of the HMI client 4 (caching).

[0101] Figure 7 It is manifested in Figure 5 and Figure 6 Flowchart of the signal data reception processing described in .

[0102] In step S100 , the communication processing unit 41 receives signal data from the web HMI server 3 .

[0103] In step S110, the communication processing unit 41 determines whether the DOM update thread 6 is in operation. If the DOM update thread 6 is stopped, the communication processing unit 41 executes the process of step S120. On the other hand, if the DOM update thread 6 is in operation, the communication processing unit 41 executes the process of step S130.

[0104] In step S120 , the communication processing unit 41 transmits the received signal data to the DOM update thread 6 (transmission processing).

[0105] In step S130, the communication processing unit 41 executes a signal data buffering process ( Figure 8 )(Cache processing).

[0106] After the process of step S120 or S130 , the communication processing unit 41 ends the signal data reception process.

[0107] Figure 8 Is used to illustrate Figure 7 Flowchart of the signal data buffering process executed by the communication processing unit 41 in step S130.

[0108] In step S200 , the communication processing unit 41 obtains a component ID list associated with the signal data.

[0109] In steps S210 to S250 , the communication processing unit 41 executes the processing of loop A. The communication processing unit 41 executes the processing of steps S220 to S240 for each element of the component ID list.

[0110] In step S220 , the communication processing unit 41 determines whether signal data having the same unique identifier (combination of pattern ID and component ID) as the received signal data already exists in the signal buffer.

[0111] If it is determined in step S220 that the condition is not satisfied, the process proceeds to step S230.

[0112] On the other hand, when it is determined in step S220 that the condition is satisfied, the process proceeds to step S240.

[0113] In step S230 , the communication processing unit 41 creates an entry corresponding to the unique identifier (a combination of the pattern ID and the component ID) in the signal buffer, and then proceeds to step S240 .

[0114] In step S240 , the communication processing unit 41 sets the data type and signal value to the entry corresponding to the unique identifier in the signal buffer.

[0115] After executing steps S220 to S240 for all elements in the component ID list, the communication processing unit 41 terminates the signal data buffering process. In loop A, signal data received from the web HMI server 3 is stored in the signal buffer as signal data decomposed for each unique identifier.

[0116] As explained above, according to Figure 8 In the processing, when the inherent identifier contained in the received signal data is the same as the inherent identifier contained in the signal data stored in the signal cache, the communication thread 7 overwrites the signal data stored in the signal cache with the received signal data (cache overwrite processing).

[0117] Next, refer to Figure 9 , indicating repeated Figure 7 and Figure 8 An example of storing multiple signal data in a signal buffer for processing.

[0118] Figure 9 This is a diagram showing an example of how data is stored in the signal buffer. Figure 8 In the process shown, if the signal data has the same unique identifier as the received signal data, the signal value of the signal data in the signal buffer is overwritten. The signal data before overwriting is not used as data displayed on the HMI screen, but is thinned out.

[0119] The signal data temporarily stored in the signal buffer by the above-mentioned signal data buffering process is transmitted to the DOM update thread 6 in response to a request from the DOM update thread 6 .

[0120] Figure 10 This is a diagram for explaining a process in which the DOM update thread 6 acquires signal data temporarily stored in the signal buffer.

[0121] After completing the DOM update process on the current signal data, the DOM update thread 6 calls the communication thread 7 to request the signal data temporarily stored in the signal buffer to be sent. Specifically, a signal data request event is sent to the communication thread 7.

[0122] When the communication thread 7 receives a signal data request event from the DOM update thread 6, it sends the DOM update request event containing all signal data stored in the signal buffer to the DOM update thread 6 (buffer sending process). After sending, the communication thread 7 deletes the data temporarily stored in the signal buffer.

[0123] When receiving a DOM update request event, the DOM update thread 6 updates the DOM for all signal data included in the DOM update request event (DOM update processing).

[0124] Figure 11 This is a flowchart for explaining the processing of the DOM update thread 6.

[0125] In step S300 , the signal data DOM update processing unit 43 receives a DOM update request event from the communication thread.

[0126] In step S310 , the signal data DOM update processing unit 43 updates the DOM for all signal data included in the DOM update request event.

[0127] In step S320 , the signal data DOM update processing unit 43 sends a signal data request event to the communication thread 7 .

[0128] Figure 12 This is a diagram for explaining the timing of the DOM update thread 6 requesting signal data and the timing of the drawing process.

[0129] What is important in this system is that after completing the DOM update, the DOM update thread 6 calls the communication thread 7 to request the next signal data cached (signal data request event).

[0130] When the signal data request event is sent, the DOM update thread 6 executes the rendering process. The rendering process is the process of reflecting the data expanded into the DOM on the physical screen. The rendering processing unit 44 updates the display content of the display components displayed on the web browser 5 according to the updated DOM.

[0131] As described above, according to the SCADA web HMI system of this embodiment, the communication thread 7 overwrites signal data with the same identifier when buffering received signal data, thereby thinning out data only for the latest signal data. This can prevent buffer overflow.

[0132] After the DOM update process is complete, the DOM update thread 6 sends a signal data request event to the communication thread 7. Upon receiving the signal data request event, the communication thread 7 sends the next signal data to the DOM update thread 6. This prohibits the DOM update thread 6 from acquiring the next signal data until the DOM update process is complete. Consequently, the DOM update process is not executed continuously, and the drawing process can be executed each time the DOM update process is completed.

[0133] Thus, according to this embodiment, by appropriately executing the rendering process while minimizing the amount of signal data thinning, the display performance of the HMI client 4 can be maximized. Therefore, according to the present invention, even when a large amount of signal data exceeding the display performance of the HMI client 4 is received, delays in data display by the web browser 5 can be suppressed.

[0134] While the above description primarily addresses signal data, alarm data can also be processed similarly. The same processing as for signal data in the DOM update thread 6 and communication thread 7 applies to alarm data. The same processing as for the signal data DOM update processing unit 43 also applies to the alarm data DOM update processing unit 42.

[0135] Furthermore, in the above-described first embodiment, the memory 200 b may include a main memory and a buffer memory as a cache area, and the program may be stored in the main memory while the signal data may be stored in the buffer memory.

[0136] <Hardware Configuration Example>

[0137] Figure 13 This is a block diagram showing an example of the hardware configuration of the web HMI server 3 and the HMI client 4 .

[0138] Each of the aforementioned processes in the web HMI server 3 is implemented by a processing circuit. This processing circuit is comprised of at least one processor 100a, at least one memory 100b, a network interface 100c, an input interface 100d, and at least one display 100e. Processor 100a implements the various functions of the web HMI server 3 by executing various programs stored in memory 100b. Memory 100b includes ROM, RAM, a HDD, an SSD, and the like. Network interface 100c is connected to PLC 2 via a computer network and is capable of receiving PLC data. Network interface 100c is connected to HMI client 4 and is capable of transmitting alarm and signal data. Input interface 100d is an input device such as a keyboard, mouse, or touchpad.

[0139] Each of the aforementioned processes in the HMI client 4 is implemented by a processing circuit. This processing circuit is comprised of at least one processor 200a, at least one memory 200b, a network interface 200c, an input interface 200d, and at least one display 200e. The processor 200a implements the various functions of the HMI client 4 by executing various programs stored in the memory 200b. The memory 200b includes ROM, RAM, a HDD, an SSD, and the like. The network interface 200c is connected to the web HMI server 3 via a computer network and is capable of receiving alarm data and signal data. The input interface 200d is an input device such as a keyboard, mouse, or touchpad. Alternatively, the HMI client 4 may be a portable terminal such as a tablet computer. The display 200e displays a web browser 5.

[0140] As mentioned above, although embodiment of this invention was described, this invention is not limited to the said embodiment, It can be variously modified and implemented without departing from the range which concerns on this invention.

[0141] Description of labels

[0142] 1 Human-Machine Interface (HMI)

[0143] 2 Programmable Logic Controller (PLC)

[0144] 3 SCADA web HMI server device (web HMI server)

[0145] 4 HMI client terminals (HMI clients)

[0146] 5. Web browser

[0147] 6 DOM Update Thread

[0148] 7 Communication Threads

[0149] 21 Equipment List

[0150] 22 Alarm List

[0151] 23 Alarm Group List

[0152] 24 Bar graph

[0153] 25 Numerical display components

[0154] 26 Color Label Parts

[0155] 31 PLC data processing unit

[0156] 32 Alarm data generation unit

[0157] 33 Signal data generation unit

[0158] 34 Communication Processing Department

[0159] 35 Filtration

[0160] 41 Communication Processing Department

[0161] 42 Alarm data DOM update processing unit

[0162] 43 Signal data DOM update processing unit

[0163] 44 Drawing Processing Unit

[0164] 100a processor

[0165] 100b memory

[0166] 100c network interface

[0167] 100d input interface

[0168] 100e Monitor

[0169] 200a processor

[0170] 200b memory

[0171] 200c network interface

[0172] 200d input interface

[0173] 200e Monitor

Claims

1. A SCADA web HMI system having: The web HMI server transmits signal data associating a unique identifier identifying a display component associated with a monitored object with a signal value received from a programmable logic controller connected to the monitored object; as well as The HMI client displays the HMI screen configured with the above-mentioned display component on the web browser, receives the above-mentioned signal data from the above-mentioned web HMI server, and changes the display content of the above-mentioned display component corresponding to the received signal data; The above HMI client has: A memory for storing programs and temporarily storing the signal data in a cache area; a processor configured to cause a communication thread and a DOM update thread to operate in parallel in the web browser by executing the program; and a display, displaying the web browser; The above communication thread executes: Receiving and processing, periodically receiving the signal data from the web HMI server; a buffer overwriting process for overwriting the signal data stored in the buffer area with the received signal data when the unique identifier included in the received signal data is identical to the unique identifier included in the signal data stored in the buffer area; as well as Cache sending processing, when receiving a signal data request event from the DOM update thread, sending the DOM update request event containing all the signal data stored in the cache area to the DOM update thread; The above DOM update thread executes: DOM update processing, when receiving the above-mentioned DOM update request event, updating the DOM for all the above-mentioned signal data contained in the above-mentioned DOM update request event; as well as The drawing process sends the signal data request event to the communication thread after the DOM is updated, and updates the display content of the display component displayed on the web browser according to the updated DOM.

2. The SCADA webpage HMI system according to claim 1, wherein: The above communication thread executes: Sending processing, when the processing of the DOM update thread is stopped, sending the DOM update request event including the received signal data to the DOM update thread; as well as Cache processing, when the processing of the DOM update thread is being executed, storing the received signal data in the cache area; The cache overwriting process is performed during the cache process.

3. An HMI client that displays an HMI screen having a display component associated with a monitored object on a web browser, receives signal data that associates a unique identifier identifying the display component with a signal value associated with the monitored object, and changes display content of the display component corresponding to the received signal data, characterized in that: have: A memory for storing a program and temporarily storing the signal data in a buffer area; a processor configured to cause a communication thread and a DOM update thread to operate in parallel in the web browser by executing the program; and a display, displaying the web browser; The above communication thread executes: Receiving and processing, periodically receiving the signal data from the web HMI server; a buffer overwriting process for overwriting the signal data stored in the buffer area with the received signal data when the unique identifier included in the received signal data is identical to the unique identifier included in the signal data stored in the buffer area; as well as Cache sending processing, when receiving a signal data request event from the DOM update thread, sending the DOM update request event containing all the signal data stored in the cache area to the DOM update thread; The above DOM update thread executes: DOM update processing, when receiving the above-mentioned DOM update request event, updating the DOM for all the above-mentioned signal data contained in the above-mentioned DOM update request event; as well as The drawing process sends the signal data request event to the communication thread after the DOM is updated, and updates the display content of the display component displayed on the web browser according to the updated DOM.

4. The HMI client according to claim 3, wherein: The above communication thread executes: Sending processing, when the processing of the DOM update thread is stopped, sending the DOM update request event including the received signal data to the DOM update thread; as well as Cache processing, when the processing of the DOM update thread is being executed, storing the received signal data in the cache area; The cache overwriting process is performed during the cache process.

Images