Variable debugging method, system and device of industrial configuration picture and storage medium

Abstract

The application discloses an industrial configuration picture variable debugging method, system and device and a storage medium, and relates to the technical field of industrial automation monitoring configuration software. The method comprises the following steps: defining a local variable in a picture level data structure of a configuration picture, wherein the local variable has a picture level scope which is only visible in the picture, and is independent of an engineering global variable table and a field device point; during picture running, receiving a variable binding request of a control, and dispatching the variable binding request to a corresponding namespace according to a variable type through a unified binding analysis outlet, wherein a value obtaining and value assigning request of the local variable is dispatched to a local numerical space which is isolated from a real device communication channel; and a device writing instruction triggered by a script logic and / or a control action of the configuration picture is limited to not acting on the local numerical space. The application realizes physical isolation of debugging simulation and device downloading in a configuration debugging process, and avoids pollution of a debugging variable to an engineering global namespace.

Description

Technical Field

[0001] This invention relates to the field of industrial automation monitoring configuration software technology, specifically to a method, system, computer equipment, and storage medium for debugging screen-level variables in industrial SCADA / HMI configuration software. Background Technology

[0002] In the field of industrial automation, SCADA (Supervisory Control and Data Acquisition) systems and HMI (Human Machine Interface) configuration software are widely used for real-time monitoring and equipment control on production lines. Configuration engineers use configuration software to create monitoring screens and bind graphical controls (such as dynamic elements, I / O fields, buttons, animations, etc.) to variables, thereby enabling real-time display of operating data and issuance of control commands.

[0003] Current mainstream SCADA / configuration software (such as Siemens' WinCC, Asia Control Technology's KingSCADA, etc.) generally adopt a two-tier architecture for variable management:

[0004] The first layer consists of external variables, used to bind data points of field devices such as PLCs and OPC servers, enabling real-time data exchange with physical devices through communication drivers. These variables require pre-establishing device communication connections and configuring the corresponding data addresses.

[0005] The second layer consists of internal variables, visible globally within the project and accessible to all screens, scripts, alarms, and archiving functions. Some configuration software provides local variables at the script level; for example, KingSCADA's internal local variables are used as intermediate variables only within a specific command language programming context. In WinCC's VBS scripts, variables can also be defined within screen scripts, but their scope is limited to the script execution context of the current screen.

[0006] The above variable system has the following shortcomings in engineering debugging scenarios: (i) Debugging variables rely on global space. When a configuration engineer needs to test the running effect of graphical controls or animations in a certain screen, since there is no variable storage space that is only valid within that screen, the engineer can only use global internal variables or connect to field devices for debugging. Since global internal variables are visible throughout the entire project, their value changes may be accidentally read or modified by other screens or scripts, which will interfere with the debugging results and make it impossible to complete the debugging loop independently within a single screen.

[0007] (ii) Debugging variables pollute the project's global namespace. Due to the lack of a storage area for temporary variables belonging only to a single screen, temporary variables created by engineers for different screens during debugging are all stored in the global variable table. In multi-engineer collaboration scenarios, temporary variables created by different personnel for different screens are prone to naming conflicts; after debugging is completed, the temporary variables scattered in the global variable table are difficult to identify and clean up one by one, increasing the burden of project management.

[0008] (iii) Debugging variables are easily mistakenly downloaded to field devices. In traditional configuration software, the write channel for global internal variables and the device download channel for external variables share the same data distribution path. When temporary variables used for debugging are stored in the global space, their value changes share the same write mechanism as formal device control commands. Debugging simulation operations may accidentally trigger device write commands, posing a risk that simulated values ​​during the debugging process may be mistakenly downloaded to field devices.

[0009] (iv) Loss of debugging data during screen migration. When a configuration screen needs to be exported from the current project and migrated to another project, if the screen depends on temporary variables stored in the global variable table during debugging, the screen file itself does not contain the definition information of these variables. The migrated screen cannot restore the debugging state due to the lack of corresponding variable definitions, and the debugging variables need to be recreated in the new project, which reduces the portability of the screen between different projects.

[0010] Existing patent documents have proposed improvement solutions. Chinese patent document CN117539200A (Management Client, Screen Configuration Method, Electronic Device, and Storage Medium) reduces the workload of repeatedly configuring the same screen elements by setting a dynamic variable module in the management client and using control variables to switch each dynamic variable in the variable group to the target variable. However, the dynamic variables in this solution still belong to the global variable group, and their scope is not limited to a single screen. Therefore, dynamic variables created during debugging will still be stored in the global variable table, failing to solve the problems of debugging variables polluting the global namespace and debugging variables depending on the global space. Furthermore, this solution does not distinguish the variable writing channels; debugging simulation values ​​and device download instructions share the same write distribution path, making it impossible to avoid the risk of debugging variables being mistakenly downloaded to field devices.

[0011] Chinese patent document CN121704838A (SCADA System Interface Point Rerouting Method, System, Device, Medium, and Product) describes a method to decouple the screen logical point identifier from the device logical point identifier by configuring a variable redirection script in the HMI interface. This decouples the screen layer from the device layer and improves system scalability. However, the core of this solution lies in the rerouting of the binding relationship. The screen logical point identifier still points to the global variable table or device point, and no independent numerical storage space for debugging purposes is established within the screen. Therefore, debugging variables are still stored in the global namespace, debugging simulation operations and device write commands still share the same channel, and debugging data cannot be carried with the screen during screen migration.

[0012] In summary, existing technologies lack a screen-level temporary storage mechanism independent of the global variable table, forcing debug variables to rely solely on the global space, leading to namespace pollution and interference with the debugging environment. More seriously, because the variable writing channel and device download instructions share the same data distribution path in existing solutions, debug simulation values ​​are easily and mistakenly downloaded to field devices, posing a serious security risk. Furthermore, since variable definitions are not physically bound to the screen file itself, debug data cannot be synchronously transferred during screen migration. Summary of the Invention

[0013] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide a method, system, device and storage medium for variable debugging of industrial configuration screen.

[0014] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for adjusting variables in an industrial configuration screen, comprising: Define local variables in the screen-level data structure of the configuration screen. The local variables have a screen-level scope that is only visible in this screen and are independent of the project global variable table and field equipment locations. During screen operation, variable binding requests from controls are received, and the variable binding requests are assigned to the corresponding namespaces according to variable type through a unified binding resolution outlet. Among them, the value retrieval and assignment requests of local variables are assigned to local numerical spaces that are isolated from the communication channels of the real device. The device write instructions triggered by the script logic and / or control actions of the configuration screen are restricted to not operating on the local numerical space.

[0015] As a further improvement to the above technical solution: Defining local variables in the screen-level data structure of the configuration screen includes: creating an independent local variable storage area in the layout data of the screen, wherein the storage area is used to store the name, data type and initial value of the local variable; the local variable storage area is physically bound to the storage file of the screen and is independent of the storage path of the project global variable table.

[0016] The unified binding resolution exit point is the runtime control binding resolution function; the binding resolution function performs traffic distribution based on the mode identifier in the binding configuration: When the pattern identifier is a local variable, it returns a connection identifier and variable name pointing to the local numerical space; When the pattern identifier is an internal global variable, a connection identifier pointing to the global internal space is returned; When the mode identifier is an external device variable, a connection identifier pointing to the corresponding device communication channel is returned.

[0017] Runtime values ​​are distinguished by prefixed namespaces to differentiate between local variables, internal global variables, and external device variables; local variables use the `local:` prefix as the namespace identifier for the local value space, and the local variables, internal global variables, and external device variables are listed side-by-side and do not overlap with each other in the value mapping of the binding resolution exit.

[0018] The device write instruction is restricted to not operating on the local numerical space, including: when the data write distribution function detects that the write target points to the local numerical space, the write operation is short-circuited, and the write operation does not enter the download queue of the real communication driver.

[0019] The local variables are connected to the control binding system through the unified binding resolution exit. The dynamic coloring, range mapping, value-based graphics switching, and input / output field display functions of the control are applied to the local variables through the unified binding resolution exit.

[0020] The runtime values ​​of the local variables are not persistently stored in the project database; changes in the values ​​of the local variables do not trigger historical archive records or real-time alarm events; when the configuration screen is closed or refreshed, the values ​​of the local variables are reset to their initial values.

[0021] The local variable definitions are exported or imported along with the configuration screen.

[0022] A variable adjustment system for an industrial configuration screen, comprising: The screen editing module is used to create and manage local variables in the screen editor, and store the definitions of the local variables in the screen layout data structure; The binding parsing module is used to receive variable binding requests from controls during screen runtime and to distribute them into three categories: local variables, internal global variables, and external device variables through a unified parsing exit. The numerical space isolation module is used to maintain a local numerical storage space that is only valid for this screen and to intercept device write commands from script logic that point to the local numerical storage space.

[0023] A computer device includes a processor and a memory, the memory storing a computer program, the processor executing the computer program to implement the steps of the method described above.

[0024] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0025] Compared with the prior art, the advantages of the present invention are as follows: The variable debugging method for industrial configuration screens of this invention, firstly, because local variables are defined in screen-level data structures and independent of the global variable table, their storage and access paths are isolated from the global variable table, ensuring that changes to the values ​​of local variables do not affect any variables in the global namespace. Simultaneously, since local variables in different screens are stored in their respective screen data structures, changes to the values ​​of local variables in one screen will not affect the values ​​of variables with the same name in other screens. Therefore, debugging of controls within a single screen can be completed without creating temporary variables in the global variable table, avoiding pollution of the project's global namespace by debugging variables and mutual interference between different screen debugging environments.

[0026] Secondly, because control variable binding requests are dispatched through a unified binding resolution exit, and local variable value retrieval and assignment requests are dispatched to independent local value spaces, the control does not distinguish whether the bound variable originates from the local value space or other namespaces; all value retrieval and assignment operations are completed through this unified exit. Therefore, there is no need to develop separate control adaptation logic for local variables; existing control functionality can be applied equally to local variables, reducing the complexity of feature expansion.

[0027] Finally, because the device write commands triggered by script logic and / or control actions are restricted to not operating on local value spaces, changes to the values ​​of local variables will not trigger any write operations pointing to the field device. Therefore, the simulated assignment of local variables and the device download commands during debugging are physically separated at the channel level, fundamentally avoiding the risk of simulated debugging values ​​being mistakenly downloaded to the field device as real commands, thus improving the safety of the debugging process.

[0028] The variable debugging system for industrial configuration screens of this invention comprises three modules: a screen editing module that defines and stores local variables in the screen layout data structure; a binding and parsing module that dispatches control requests to the corresponding namespaces at runtime; and a value space isolation module that maintains a local value storage space valid only for the current screen and intercepts device write commands pointing to that space. These three modules work collaboratively to achieve isolation of local variable definition, storage, access, and writing at the system architecture level. Therefore, without modifying the existing control binding logic, a debugging variable storage space, valid only for the current screen and isolated from the device write channel, can be independently provided for each screen in the configuration system.

[0029] The technical effect of the computer device and computer-readable storage medium of the present invention is determined by the method performed, and therefore its effect is consistent with the variable debugging method of the industrial configuration screen of the present invention, which will not be described again here. Attached Figure Description

[0030] Figure 1 This is a flowchart illustrating the variable debugging method for an industrial configuration screen provided in an embodiment of the present invention.

[0031] Figure 2 This is a schematic diagram of the module structure of the variable debugging system for the industrial configuration screen provided in an embodiment of the present invention.

[0032] The labels in the diagram represent: 100. Screen editing module; 200. Binding and parsing module; 300. Numerical space isolation module. Detailed Implementation

[0033] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0034] Example 1: As Figure 1 As shown in the figure, this embodiment provides a variable debugging method for an industrial configuration screen, which includes the following steps: Step S101: Define local variables in the screen-level data structure of the configuration screen.

[0035] The configuration software's screen editor provides a local variable editing interface. Configuration engineers input the name, data type, initial value, and description of a local variable in this interface. After receiving this input, the screen editor creates a separate local variable storage area within the screen's layout data, storing the local variable's name, data type, initial value, and description in this storage area. As an optional implementation, the storage area can be a local variable array, where each element corresponds to the definition information of a local variable.

[0036] The local variable storage area is physically bound to the screen's storage file; that is, this storage area is saved along with the screen's storage file as part of the screen layout data. The local variable storage area is independent of the project's global variable table storage path, meaning that data in this storage area is not written to the project's global variable library. Therefore, a configuration screen becomes a self-contained unit carrying its own debugging data. When migrating screens or demonstrating independently, it does not rely on external global variable definitions. Configuration engineers can directly open the screen in a new environment and use local variables to drive control animations without connecting any field devices.

[0037] Step S102: During screen runtime, receive variable binding requests from controls and dispatch the variable binding requests to the corresponding namespaces according to variable type through a unified binding resolution exit.

[0038] When the configuration screen loads and runs, if controls on the screen (including but not limited to dynamic elements, I / O fields, buttons, animated controls, etc.) need to obtain or display variable values, they send a variable binding request to the binding parsing module. This request contains binding configuration information, which includes at least the variable type identifier and the variable name.

[0039] The binding resolution module receives variable binding requests from all controls through a unified binding resolution exit (the `resolveBinding` function) and dispatches them according to the variable type identifier in the binding configuration: When a variable is identified as a local variable, the request will be dispatched to the local numeric space; When the variable type is identified as an internal global variable, the request will be dispatched to the global internal space; When the variable type is identified as an external device variable, the request will be dispatched to the corresponding device communication channel.

[0040] In this system, the requests for retrieving and assigning values ​​to local variables are dispatched to a local numerical space that is isolated from the communication channel of the actual device. In other words, the read and write operations of local variables only occur within the local numerical space and do not involve any communication interaction with the field device.

[0041] After local variables are connected to the control binding system through a unified binding resolution outlet, the dynamic coloring, range mapping, value-based graphic switching, and input / output field display functions of the controls all apply equally to the local variables through this unified binding resolution outlet. These functions do not require separate control adaptation logic to be developed for local variables; all existing control animation, linkage, and interactive functions apply to local variables without distinction.

[0042] Runtime values ​​are distinguished by prefixed namespaces to differentiate between local variables, internal global variables, and external device variables. Local variables use the `local:` prefix as their namespace identifier. Local variables, internal global variables, and external device variables are listed side-by-side in the binding resolution exit value mapping and do not overwrite each other. In other words, a change to a value in any namespace does not affect the value of a variable with the same name in other namespaces.

[0043] Step S103: The device write command triggered by the script logic and / or control actions of the configuration screen is restricted to not operating on the local numerical space.

[0044] When a script logic (such as a button click script, a timer script, etc.) or control action (such as an input confirmation operation in an I / O field) triggers a data write operation, the data write dispatch function (writeBindingValue function) first determines the type of the variable pointed to by the write target: If the target to be written points to a local numerical space, the write operation is directly short-circuited, and no device write command is generated; If the target to be written points to an internal global variable or an external device variable, the write operation is performed according to the normal procedure.

[0045] Specifically, when the data write dispatch function detects that the write target points to a local value space, it calls the local variable write function to write the value to be written to the corresponding variable in the local value space, and then returns directly. This write operation does not enter the download queue of the real communication driver and does not trigger a device write request.

[0046] With the above restrictions, changes in the values ​​of local variables will not trigger any write operations to field devices, thus achieving physical separation of debugging simulation values ​​and device download instructions at the channel level. This fundamentally avoids the simulation assignment of local variables during debugging being mistakenly treated as real instructions and downloaded to field devices.

[0047] Furthermore, the runtime values ​​of local variables are not persistently stored in the project database; changes in the values ​​of local variables do not trigger historical archive records or real-time alarm events; when the configuration screen is closed or refreshed, the values ​​of local variables are reset to the initial values ​​set at the time of definition. Therefore, local variables do not leave any residual data in the project after the debugging task is completed, eliminating the need for manual cleanup by configuration engineers.

[0048] Example 2: Figure 2 As shown, this embodiment provides a variable debugging system for an industrial configuration screen. The system includes: a screen editing module 100, a binding parsing module 200, and a numerical space isolation module 300.

[0049] The screen editing module 100 is used to create and manage local variables in the screen editor and store the definitions of local variables in the screen layout data structure. Specifically, the screen editing module provides a local variable editing interface, receives the local variable name, data type, initial value, and description information input by the configuration engineer, creates an independent local variable storage area in the screen layout data, and stores the above information in this storage area. The local variable storage area is physically bound to the screen storage file and is independent of the storage path of the project's global variable table. Therefore, the screen editing module ensures from the source that local variable definitions do not enter the global variable table, avoiding the problems of variable naming conflicts and the difficulty in cleaning up residual variables in multi-engineer collaborative scenarios.

[0050] The binding parsing module 200 receives variable binding requests from controls during runtime and distributes them into three categories—local variables, internal global variables, and external device variables—through a unified parsing outlet. Specifically, the binding parsing module receives variable binding requests from all controls through a unified binding parsing outlet and distributes the requests to the corresponding namespaces based on the mode identifier in the binding configuration: local variables are assigned to the local namespace, internal global variables to the global namespace, and external device variables to the corresponding device communication channel. As a single value aggregation point, the binding parsing module makes newly added local variable types completely transparent to upper-level controls, eliminating the need for controls to be aware of the source type of the bound variables.

[0051] The numerical space isolation module 300 maintains a local numerical storage space that is valid only for the current screen and intercepts device write commands from script logic that point to this local numerical storage space. Specifically, the numerical space isolation module maintains an independent local numerical storage space for the current screen at runtime. This space uses the `local:` prefix as its namespace identifier and is isolated from the global internal space and external device space. When the data write distribution function detects that the write target points to this local numerical storage space, the numerical space isolation module short-circuits the write operation, preventing it from entering the download queue of the real communication driver. Thus, physical isolation between debugging simulation and device download is achieved at the system architecture level, improving the security of the debugging process.

[0052] Example 3: This example provides a computer device, including a processor and a memory. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the variable debugging method for the industrial configuration screen as described in any of the above method embodiments.

[0053] Example 4: This example provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the steps of the variable debugging method for the industrial configuration screen as described in any of the above method embodiments.

[0054] Computer-readable storage media can be any tangible medium capable of storing computer programs, including but not limited to: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0055] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for adjusting variables in an industrial configuration screen, characterized in that, include: Define local variables in the screen-level data structure of the configuration screen. The local variables have a screen-level scope that is only visible in this screen and are independent of the project global variable table and field equipment locations. During screen operation, variable binding requests from controls are received, and the variable binding requests are assigned to the corresponding namespaces according to variable type through a unified binding resolution outlet. Among them, the value retrieval and assignment requests of local variables are assigned to local numerical spaces that are isolated from the communication channels of the real device. The device write instructions triggered by the script logic and / or control actions of the configuration screen are restricted to not acting on the local numerical space. Defining local variables in the screen-level data structure of the configuration screen includes: creating an independent local variable storage area in the layout data of the screen, wherein the storage area is used to store the name, data type and initial value of the local variable; the local variable storage area is physically bound to the storage file of the screen and is independent of the storage path of the project global variable table; The unified binding resolution exit point is the runtime control binding resolution function; the binding resolution function performs traffic distribution based on the mode identifier in the binding configuration: When the pattern identifier is a local variable, it returns a connection identifier and variable name pointing to the local numerical space; When the pattern identifier is an internal global variable, a connection identifier pointing to the global internal space is returned; When the mode identifier is an external device variable, a connection identifier pointing to the corresponding device communication channel is returned; Runtime values ​​are distinguished by prefixed namespaces to differentiate between local variables, internal global variables, and external device variables; local variables use the local: prefix as the namespace identifier for the local value space, and the local variables, internal global variables, and external device variables are listed side by side and do not overlap with each other in the value mapping of the binding resolution exit; The device write command is restricted to not operating on the local numerical space, including: when the data write distribution function detects that the write target points to the local numerical space, the write operation is short-circuited, and the write operation does not enter the download queue of the real communication driver.

2. The variable debugging method for industrial configuration screens according to claim 1, characterized in that, The local variables are connected to the control binding system through the unified binding resolution exit. The dynamic coloring, range mapping, value-based graphics switching, and input / output field display functions of the control are applied to the local variables through the unified binding resolution exit.

3. The variable debugging method for industrial configuration screens according to claim 1, characterized in that: The runtime values ​​of the local variables are not persistently stored in the project database; changes in the values ​​of the local variables do not trigger historical archive records or real-time alarm events; when the configuration screen is closed or refreshed, the values ​​of the local variables are reset to their initial values.

4. The variable debugging method for industrial configuration screens according to claim 1, characterized in that, The local variable definitions are exported or imported along with the configuration screen.

5. A computer device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 4.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 4.

Images