Preview mode for configuration logic

Abstract

The described technology enables plant personnel to avoid the time and labor-intensive processes associated with traditional design systems by enabling users to design, test, and "preview" control logic for controlling a process before downloading the control logic to a configuration database or process controller in a plant. This enables rapid testing and refinement of control logic during the design phase, avoiding the time-consuming iterative process of design, download to a database, propagation to a real-time controller, and testing on a physical controller. It also separates testing of the logic and non-logic aspects of a controller configuration, enabling a user to complete the design of control logic before downloading the configuration to a controller, where she only needs to test the non-logic aspects of the configuration.

Description

Technical Field

[0001] The present disclosure relates generally to process control environments and, more particularly, to a configuration system that enables a user to design, test, and "preview" control logic for controlling a process before downloading the control logic to a configuration database or process controllers in a plant. Background Art

[0002] Distributed process control systems, such as distributed or scalable process control systems for power generation, chemical, petroleum, or other processes, typically include one or more process controllers communicatively coupled to each other, to at least one host computer or operator workstation, and to one or more instruments or field devices via an analog, digital, or hybrid analog / digital bus via a process control network.

[0003] Field devices perform functions within a process or plant, such as opening or closing valves, connecting and disconnecting equipment, and measuring process parameters. Example field devices include valves, valve positioners, switches, and transmitters (e.g., devices that include sensors for measuring temperature, pressure, or flow rate; and transmitters that transmit the sensed temperature, pressure, and flow rate).

[0004] A process controller is typically located in a plant environment and receives signals indicative of process measurements made by field devices (or other information related to the field devices) and executes controller applications that run, for example, various control modules that make process control decisions, generate control signals based on the received information, and communicate with smart field devices (e.g., and Fieldbus field devices) in the control module or block coordination.

[0005] Execution of the control module causes the process controller to send control signals to the field devices via a communication link or signal path, thereby controlling the operation of at least a portion of a process plant or system (e.g., controlling at least a portion of one or more industrial processes running or executing within the plant or system). For example, a first set of controllers and field devices may control a first portion of a process controlled by the process plant or system, and a second set of controllers and field devices may control a second portion of the process.

[0006] Input / output (I / O) cards (sometimes referred to as "I / O devices" or "I / O modules") are also typically located in a factory environment and are typically communicatively arranged between a controller and one or more field devices to enable communication therebetween (e.g., by converting electrical signals into digital values, or vice versa). Typically, an I / O card serves as an intermediate node between a process controller and one or more field device inputs or outputs, which are configured for the same communication protocol or protocols as the communication protocol used by the I / O card. Specifically, field device inputs and outputs are typically configured for analog or discrete communication. In order to communicate with a field device, a controller typically requires an I / O card that is configured for the same type of input or output used by the field device. That is, for a field device configured to receive an analog control output signal (e.g., a 4-20mA signal), the controller requires an analog output (AO) I / O card to transmit the appropriate analog control output signal; and for a field device configured to transmit measurement results or other information via an analog signal, the controller typically requires an analog input (AI) card to receive the transmitted information. Similarly, for field devices configured to receive discrete control output signals, the controller requires a discrete output (DO) I / O card to transmit the appropriate discrete control output signals; and for field devices configured to transmit information via discrete control input signals, the controller requires a discrete input (DI) I / O card. Typically, each I / O card can connect to multiple field device inputs or outputs, where each communication link to a specific input or output is called a "channel." For example, a 120-channel DO I / O card can be communicatively connected to 120 different discrete field device inputs, enabling the controller to transmit discrete control output signals (via the DO I / O card) to the 120 different discrete field device inputs.

[0007] As used herein, field devices, controllers, and I / O devices are generally referred to as "process control devices" and are typically located, arranged, or installed in the field environment of a process control system or plant. A network formed by one or more controllers, field devices communicatively connected to the one or more controllers, and intermediate nodes that facilitate communication between the controllers and the field devices may be referred to as an "I / O network" or "I / O subsystem."

[0008] Information from the I / O network may be provided via a data highway or communications network ("process control network") to one or more other hardware devices, such as operator workstations, personal computers or computing devices, handheld devices, data historians, report generators, centralized databases, or other centralized management computing devices, typically located in a control room or other location away from the harsher field environment of the plant (e.g., in a back-end environment of a process plant).

[0009] Information transmitted over a process control network enables operators or maintenance personnel to perform desired functions with respect to a process via one or more hardware devices connected to the network. These hardware devices may run applications that enable operators to, for example, change settings for process control routines, modify the operation of control modules in process controllers or smart field devices, view the current state of a process or the state of a specific device in a process plant, view alarms generated by field devices and process controllers, simulate the operation of a process for the purpose of training personnel or testing process control software, diagnose problems or hardware failures in a process plant, and the like. The process control network or data highway used by the hardware devices, controllers, and field devices may include wired communication paths, wireless communication paths, or a combination of wired and wireless communication paths.

[0010] As an example, the DeltaV sold by Emerson Process Management TM The control system includes a plurality of applications stored in and executed by different devices located in different locations within the process plant. Configuration applications residing in one or more workstations or computing devices in the back-end environment of the process control system or plant enable users to create or change process control modules and download these process control modules to dedicated distributed controllers via data highways. Typically, these control modules are composed of communicatively interconnected function blocks, which are objects in an object-oriented programming protocol that (i) perform functions within the control scheme based on inputs to them and (ii) provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change an operator interface, which is used by a viewing application to display data to an operator and enable the operator to change settings within the process control routine, such as set points.

[0011] Each dedicated controller (and, in some cases, one or more field devices) stores and executes a corresponding controller application, which runs the control module assigned to and downloaded to that controller to implement the actual process control functions. A viewing application, which may be executed on one or more operator workstations (or on one or more remote computing devices communicatively connected to the operator workstations and the data highway), receives data from the controller application via the data highway and displays the data to a process control system designer, operator, or user using a user interface, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. A data historian application is typically stored in and executed by a data historian device, which collects and stores some or all of the data provided across the data highway, while a configuration database application may be executed in another computer connected to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located on the same workstation as the configuration application.

[0012] In addition to process controllers, I / O cards, and field devices, a typical process control system includes many other support devices that are also necessary for or related to process operations. These additional devices include, for example, power supply equipment, power generation and distribution equipment, rotating equipment such as turbines, and the like, which are located at many locations in a typical plant.

[0013] In addition, many process plants have other computers associated with them that execute applications related to business functions or maintenance functions. For example, some plants include computers that execute applications associated with ordering raw materials, replacement parts or equipment for the plant, applications related to forecasting sales and production needs, etc. Similarly, many process plants, especially those that use smart field devices, include applications for monitoring and maintaining equipment within the plant, whether these are process control and instrumentation equipment or other types of equipment. For example, the asset management solutions available from Emerson Process Management (AMS TM ) Suite Intelligent Device Manager or more generally AMS TM The application suite is capable of communicating with field devices and storing data about the field devices to determine and track the operational status of the field devices. An example of such a system is disclosed in U.S. Patent No. 5,960,214, entitled "Integrated Communication Network for use in a Field Device Management System." In some cases, the AMS TMApplication suites can be used to communicate with devices to change parameters within the devices, thereby enabling the devices to run applications themselves, such as self-calibration routines or self-diagnostic routines, to obtain information about the device's status or health. This information can be stored and used by maintenance personnel to monitor and maintain these devices. Similarly, other types of applications exist for monitoring other types of equipment, such as rotating equipment and power generation and supply equipment. These other applications are typically available to maintenance personnel and are used to monitor and maintain equipment within process plants.

[0014] However, in a typical plant or process, the functions associated with process control activities, equipment and equipment maintenance and monitoring activities, and business activities are separated both (i) in the locations where these activities occur and (ii) in the people who typically perform these activities. In addition, the different people involved in these different functions often use different tools, such as different applications running on different computers to perform different functions. In many cases, these different tools collect or use different types of data associated with or collected from different equipment in the process and are configured differently to collect the data they need. Exemplary roles in a process control environment include (i) process control operators, (ii) maintenance personnel, and (iii) configuration or control engineers.

[0015] Regarding process control operators, these individuals typically oversee the day-to-day operations of the process and are primarily responsible for ensuring the quality and continuity of process operations. Control operators typically influence the process by setting and changing set points within the process, adjusting loops within the process, scheduling process operations such as batch operations, and the like. These process control operators can use available tools to diagnose and correct process control problems within the process control system, including, for example, autotuners, loop analyzers, neural network systems, and the like. Process control operators also receive process variable information from the process via one or more process controllers, which provide the operator with information about process operations, including alarms generated within the process. This information can be provided to the process control operator via a standard user interface.

[0016] Regarding maintenance personnel, these personnel are primarily responsible for ensuring that the actual equipment in the process is operating efficiently and are responsible for repairing and replacing faulty equipment. Maintenance personnel use tools such as maintenance interfaces, the aforementioned AMS TM Application suite, as well as many other diagnostic tools that provide information about the operating status of process equipment. Maintenance personnel also schedule maintenance activities that may require shutting down parts of the plant. For many newer types of process equipment and equipment, often referred to as smart field devices, the devices themselves can include detection and diagnostic tools that automatically sense problems with the operation of the equipment and automatically report these problems to maintenance personnel via standard maintenance interfaces. For example, AMS TMApplications in the application suite report device status and diagnostic information to maintenance personnel and provide communications and other tools that enable maintenance personnel to determine what is happening in the equipment and access device information provided by the equipment. Typically, the maintenance interface and maintenance personnel are located away from the process control operator, although this is not always the case. For example, in some process plants, the process control operator can perform the duties of a maintenance personnel and vice versa, or different personnel responsible for these functions can use the same interface.

[0017] With respect to configuration engineers, these individuals typically define the control strategies and control routines implemented by controllers in a plant environment. During normal operation of the plant, one or more controllers implement the designed control routines in an automated or semi-automated manner. During normal operation, process control operators monitor the performance of various aspects of the plant while the control strategies defined by the configuration engineers are being implemented. If necessary, when performance begins to degrade, the operator can implement corrective controls (or, if necessary, shut down operations completely). In any case, exemplary responsibilities of a configuration engineer include: (i) designing a controller configuration including control routines using an engineering tool or configuration application, (ii) assigning the controller configuration to the controller, and (iii) uploading the controller configuration to a configuration database, where the controller configuration is ultimately propagated to the appropriate controllers.

[0018] In order to test or verify a draft controller configuration, it is typically necessary to save the draft configuration to the control system's configuration database and download it to other systems. Typically, it is not possible to test or verify any aspect of the control logic included in the controller configuration without saving the draft configuration and, for example, uploading the controller configuration to the configuration database and propagating the controller configuration to the appropriate controllers. Furthermore, generally speaking, testing and verification of control logic cannot typically be performed within the configuration application or engineering tool environment itself (particularly not when using, in whole or in part, actual process data collected by field devices associated with the designed control routines). Thus, verifying control logic is expensive (in terms of money and time) because for each incremental modification to the draft controller configuration, another complete cycle of saving, downloading, instantiating, and testing must be performed. Furthermore, testing and verifying control logic requires that the engineering tool and configuration database be connected to another system. Summary of the Invention

[0019] The described technology enables plant personnel to avoid the time- and labor-intensive processes associated with traditional design systems by enabling users to design, test, and "preview" control logic for controlling a process before downloading it to a configuration database or process controller in the plant. This enables rapid testing and improvement of control logic during the design phase, avoiding the time-consuming iterative process of designing, downloading to a database, propagating to a live controller, and testing on a physical controller. It also separates the testing of the logical and non-logical aspects of the controller configuration, enabling the user to complete the design of the control logic before downloading the configuration to the controller, where she only needs to test the non-logical aspects of the configuration.

[0020] Note that this summary is provided to introduce selected concepts that will be further described in the following detailed description. As explained in the detailed description, some embodiments may include features and advantages not described in this summary, and some embodiments may omit one or more features or advantages described in this summary. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Each of the figures described below illustrates one or more aspects of the disclosed system or method according to an embodiment.DETAILED DESCRIPTION Reference is made to the reference numerals included in the following figures.

[0022] Figure 1 An exemplary process plant, process control system, or process control environment is shown that includes a configuration tool that enables a user to design, test, and "preview" control logic (e.g., embodied by one or more control routines, modules, or programs) used to control a process before downloading the control logic to a configuration database or process controller in the plant.

[0023] Figure 2A Shown Figure 1 A block diagram of the configuration tool is shown, including a draft controller configuration that can be designed and tested using the configuration tool.

[0024] Figure 2B Shows the implementation of preview mode to test Figure 2A An exemplary method of configuring the logic of a draft controller is shown.

[0025] Figure 3 Shown Figure 2A Examples of process modules and control modules are shown in .

[0026] Figure 4 Shows that it can be used to design Figure 2A An example of a graphical configuration of a process module is shown.

[0027] Figure 5 Shows that you can use Figure 1An example control routine designed and previewed by the configuration tool is shown.

[0028] Figure 6 yes Figure 2A An exemplary wireframe of a logic configuration GUI shown in that may be presented by a configuration tool to facilitate designing controller configurations and logic for controller configurations.

[0029] Figure 7 is an exemplary screenshot of a logic configuration GUI in which a user interacts with a tab to open a palette of graphical templates that can be used to help build a controller configuration.

[0030] Figure 8 is an exemplary screen shot of the Logic Configuration GUI, including responses to Figure 7 The palette (pa) is launched by interacting with the tabs shown.

[0031] Figure 9 is an exemplary screenshot of a logic configuration GUI in which a user interacts with an element to launch a preview pane (not shown).

[0032] Figure 10 is an exemplary screen shot of a logic configuration GUI, wherein: (i) in response to a user and Figure 9 Interaction of the elements shown, showing the preview pane, and (ii) the user interacting with the graphical elements to inject test values ​​to be passed to the function block.

[0033] Figure 11 is an exemplary screenshot of a logic configuration GUI in which a user interacts with a graphical element via a cursor to launch a preview pane for an object corresponding to the graphical element.

[0034] Figure 12 is an exemplary screenshot of the logic configuration GUI showing a user interacting with fields via a cursor to inject test values.

[0035] Figure 13 is an exemplary screenshot of the logic configuration GUI in which a user is interacting with a tab to launch a pane for viewing test values ​​used in a test control routine.

[0036] Figure 14 is an example screenshot of the Logic Configuration GUI, including the Figure 13 The pane that is launched after the tab interaction shown.

[0037] Figure 15 yes Figure 2A An exemplary screenshot of a graphical configuration GUI that may be presented by a configuration tool to facilitate designing process modules and process module GUIs is shown, illustrating a user interacting with an element to initiate a preview pane.

[0038] Figure 16 is an exemplary screen shot of the graphical configuration GUI, including the following: Figure 15 The preview pane that is launched by interacting with the element shown.

[0039] Figure 17 is an exemplary screenshot of the graphical configuration GUI showing a user injecting test values ​​for operating parameters through graphical interaction with the canvas area of ​​the GUI.

[0040] Figure 18 1601 is an exemplary screenshot of a graphical configuration GUI in which a user injects test values ​​for operational parameters by interacting with fields included in preview pane 1601 .

[0041] Figure 19 is an exemplary screenshot of a graphical configuration GUI in which a user interacts with a field for binding a tag, causing the GUI to (i) highlight a graphic representing the device to which the tag is bound, and (ii) display a preview pane showing information related to the object to which the tag is bound (e.g., a pump with the tag “P-137A”).

[0042] Figure 20 is an exemplary screenshot of the graph configuration GUI in which a user interacts with a field for an unbound label, causing the GUI to display a preview pane showing information about the unbound graph. DETAILED DESCRIPTION

[0043] In the past, configuration engineers would use a software such as Control Studio sold by Emerson Process Management. TMto design a controller configuration that includes control logic for controlling a process. To test the designed control logic, the user downloads the controller configuration to the control system's configuration database. The controller configuration is then propagated from the database to the appropriate real-time process controller. The engineer then places the controller in a safe mode (e.g., simulating inputs, clearing outputs, or placing it in manual mode; debug mode, etc.), and various inputs are provided to the controller, and the corresponding controller outputs are evaluated, allowing the engineer to monitor the performance of the draft control logic. When the control logic has less than ideal performance, the engineer will return to the design tool, modify the controller configuration, download the configuration to the database, have the database propagate the configuration to the controller, configure the controller for testing, and again evaluate the performance of the control logic. Throughout this incremental process, in conjunction with testing the logic of the controller configuration, the engineer can also test and evaluate the non-logical aspects of the configuration. For example, engineers can test real-time behavior such as: resource usage (e.g., how much CPU and memory the logic consumes); how long it takes a block or module configured by the controller to execute; whether the block or module runs on time; communication delay (or lack of communication delay) between blocks or modules (e.g., particularly between blocks or modules at different controllers); the timing of the entire signal cycle, including the length of time it takes for a first signal to travel from an input device (e.g., carrying a measurement) and arrive at a control routine at the controller (e.g., executing the logic configured by the controller); the length of time it takes for the logic or control routine to execute and generate a second signal (e.g., carrying a control command) after receiving the first signal; and the length of time between sending the second signal from the control routine and receiving the second signal at the output device. Engineers will repeat this cycle as incremental changes are needed to refine the control logic.

[0044] Here, plant personnel can avoid the time- and labor-intensive processes associated with traditional design systems by using the configuration system described herein to design, test, and "preview" control logic for controlling a process before downloading it to a configuration database or process controller in the plant. This enables rapid testing and improvement of control logic during the design phase, avoiding the time-consuming iterative process of designing, downloading to a database, propagating to a live controller, and testing on a physical controller. It also separates the testing of the logical and non-logical aspects of the controller configuration, enabling the user to complete the design of the control logic before downloading the configuration to the controller, where she only needs to test the non-logical aspects of the configuration.

[0045] Exemplary Process Control Environment

[0046] Figure 1An exemplary process plant, process control system, or process control environment 5 is shown that includes a configuration tool 101 that enables a user to design, test, and “preview” control logic (e.g., implemented by one or more control routines, modules, or programs) used to control a process before downloading the control logic to a configuration database or process controller in the plant.

[0047] Process plant 5 control can be referred to as a process having one or more "process outputs" that characterize the process state (e.g., tank level, flow rate, material temperature, etc.) and one or more "process inputs" (e.g., various environmental conditions and states of actuators, manipulation of which can cause the process output to change). Figure 1 The process plant or control system 5 includes a field environment 122 (e.g., "process plant site 122") and a backend environment 125, each of which is communicatively connected via a process control trunk or data highway 10. The trunk 10 (sometimes referred to as "link 10" or "network 10") may include one or more wired or wireless communication links and may be implemented using any desired or suitable communication protocol, such as the Ethernet protocol.

[0048] At the top (such as Figure 1 ), the on-site environment 122 includes physical components (e.g., process control devices, networks, network elements, etc.) that are arranged, installed, and interconnected to operate during runtime to control the process. For example, the on-site environment 122 includes the I / O network 6. Generally, components of the I / O network 6 are located, arranged, or otherwise included in the on-site environment 122 of the process plant 5. Generally speaking, in the on-site environment 122 of the process plant 5, raw materials are received and processed using the physical components arranged therein to produce one or more products.

[0049] In contrast, the backend environment 125 of the process plant 5 includes various components, such as computing devices, operator workstations, databases or repositories, etc., that are shielded or protected from the harsh conditions and materials of the field environment 122. In some configurations, the various computing devices, databases, and other components and devices included in the backend environment 125 of the process plant 5 may be physically located in different physical locations, some of which may be local to the process plant 5 and some of which may be remote.

[0050] Factory 5 on-site environment 122

[0051] As described above, the field environment 122 includes one or more I / O networks, such as I / O network 6, each of which includes: (i) one or more controllers, (ii) one or more field devices communicatively connected to the one or more controllers, and (iii) one or more intermediate nodes (e.g., I / O cards or modules) that facilitate communication between the controllers and the field devices.

[0052] Typically, at least one field device performs a physical function (e.g., opens or closes a valve, raises or lowers a temperature, takes a measurement, senses a condition, etc.) to control the operation of a process implemented in the process plant 5. A field device can be considered a device that manipulates a process input (e.g., valve position or pump status) or measures a process output (e.g., tank level, flow rate, pressure, temperature, etc.). Some types of field devices communicate with a controller via an I / O device (sometimes referred to as an "I / O card"). Process controllers, field devices, and I / O cards can be configured for wired or wireless communication. Any number and combination of wired and wireless process controllers, field devices, and I / O devices can be included in a process plant environment or system 5.

[0053] For example, the field environment 122 includes an I / O network 6 that includes a process controller 11 communicatively connected to a set of wired field devices 15-22 via an I / O card 26 and an I / O card 28. The field environment 122 also includes a wireless network 70 that includes a set of wireless field devices 40-46 coupled to the controller 11 (e.g., via a wireless gateway 35 and the network 10). The wireless network 70 may be part of the I / O network 6, or may be Figure 1 A portion of the I / O network not shown (and may include Figure 1 controller or I / O card not shown).

[0054] In some configurations, the controller 11 may be communicatively connected to the wireless gateway 35 using one or more communication networks other than the backbone 10, such as by using any number of other wired or wireless communication links supporting one or more communication protocols, such as Wi-Fi or other IEEE 802.11 compliant wireless local area network protocols, mobile communication protocols (e.g., WiMAX, LTE, or other ITU-R compliant protocols), Profibus, Fieldbus, etc.

[0055] Process Controller 11

[0056] The controller 11 may be a DeltaV sold by Emerson Process Management. TMA controller that can use at least some of the field devices 15-22 and 40-46 to implement a batch process or a continuous process. In addition to being communicatively connected to the process control data highway 10, the controller 11 also uses communication with, for example, standard 4-20 mA devices, I / O cards 26, 28, or any intelligent communication protocol (e.g., Fieldbus protocol, protocol, Any desired hardware and software associated with the field devices 15-22 and 40-46 is communicatively connected to at least some of the field devices 15-22 and 40-46. Figure 1 In the embodiment, the controller 11, the field devices 15-22 and the I / O cards 26 and 28 are wired devices, and the field devices 40-46 are wireless field devices. Of course, the wired field devices 15-22 and the wireless field devices 40-46 can conform to any other desired standard or protocol, such as any wired or wireless protocol, including any standard or protocol developed in the future.

[0057] The process controller 11 includes a processor 30 that implements or oversees one or more process control routines 38 (e.g., stored in memory 32). A "control routine" (sometimes referred to as a "control module") is a set of instructions executable by a processor (e.g., of the controller 11) for performing one or more operations to provide or implement online control of at least a portion of a process. Generally speaking, a control routine can be understood as software configured to implement a particular control strategy. A control routine can be saved to memory, for example, as one or more routines, applications, software modules, or programs. A control routine can reference a device object to communicate with a field device corresponding to the device object. A control routine can be composed of function blocks, each of which is a portion or subroutine of the entire control routine. Each control routine can operate in conjunction with other control routines and function blocks to implement a control routine or process control loop within a process plant. Although the Fieldbus protocol and the DeltaV system protocol use control routines and function blocks designed and implemented using an object-oriented programming protocol, control modules may be designed using any desired control programming scheme, including, for example, sequential function blocks, ladder logic, etc., and are not limited to design and implementation using function blocks or any other specific programming technique (unless otherwise noted).

[0058] Returning to the controller 11, the processor 30 is configured to communicate with the field devices 15-22 and 40-46, as well as with other nodes communicatively connected to the controller 11. Note that any control routine or module described herein can have portions thereof implemented or executed by different controllers or other devices, if desired. Similarly, the control routine or module 38 described herein to be implemented within the process control system 5 can take any form, including software, firmware, hardware, etc. The control routine can be implemented in any desired software format, such as using object-oriented programming, ladder logic, sequential function charts, function block diagrams, or any other software programming language or design paradigm. The control routine 38 can be stored in any desired type of memory 32, such as random access memory (RAM) or read-only memory (ROM). Similarly, the control routine 38 can be hard-coded into, for example, one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), or any other hardware or firmware elements. Simply put, the controller 11 can be configured to implement the control strategy or control routine in any desired manner.

[0059] Note that the process controlled by the controller 11 (and any other controller) can be characterized by "process variables." Process inputs, process outputs, controlled variables, manipulated variables, disturbance variables, and setpoints are all exemplary process variables. A "process output" can be considered a process variable that represents the existing state of the process, and a "process input" can be considered a process variable that represents various conditions, settings, equipment, signals, and other information that may affect the performance of the process. The controller 11 can receive measurements of one or more process outputs as "control inputs" and can transmit one or more "control outputs" as control signals (which can be considered process inputs) that are configured to manipulate the state of the equipment to drive the process output to a desired state.

[0060] Example "process outputs" may include tank levels, flow rates, material temperatures, pipe and tank pressures, the current status of various valves, pumps, and other equipment, etc. Process outputs are often measured and monitored to evaluate the performance of the process and to inform how process inputs should be manipulated to manipulate the process output to a desired state.

[0061] Exemplary "process inputs" may include the state of the raw materials being processed, environmental conditions, the state of equipment in the plant (such as actuators (whose manipulation can cause the process output to change)), settings of equipment (such as the operating settings of valves), etc. The state of any one or more process inputs may affect how the process is performed. Note that process outputs and process inputs are not necessarily mutually exclusive. For example, valve CV001 may have a position of 50% open, which can be understood as the current condition of the process and thus as a process output. However, the valve position can affect other process outputs (such as flow rate) and can be measured (for example, to verify whether it reaches the desired position after being commanded to move to the desired position). Therefore, the valve position can also be understood as a process input.

[0062] As described above, exemplary process variables include controlled variables, manipulated variables, disturbance variables, and set points. A "controlled variable" is a process variable (e.g., tank level) that a controller or control routine attempts to control indirectly by adjusting a "manipulated variable" (e.g., the inlet valve for a tank). The control routine can adjust the manipulated variable to drive the controlled variable to a desired set point. A "set point" represents a desired value for the controlled variable. The set point can be set automatically by the controller based on the control routine, or it can be set manually by an operator.

[0063] Returning to the controller 11, when the controller's processor 30 executes one or more control routines, the controller transmits a control signal (i.e., a control output) to the field device, which control signal carries a command or value generated based on: (i) one or more received control inputs (e.g., one or more received signals representing measurements of process outputs obtained by the field device), and (ii) logic that implements the one or more control routines using the values ​​of the control inputs as inputs. A control routine can be defined by one or more software units (e.g., function blocks). Specifically, the controller 11 can implement a control strategy using function blocks, where each function block is an object or other portion (e.g., a subroutine) of an entire control routine. The controller 11 can operate in conjunction with function blocks implemented by other devices (e.g., other controllers or field devices) to implement a process control loop within the process control system 5.

[0064] Note that the term "control loop" generally refers to a subsystem of a process control system used to implement control of a specific aspect of a process. A control loop includes the physical and logical components required to control a controlled variable (often referred to simply as a process variable or PV). For example, the physical components may include (i) a sensor for measuring the PV (e.g., included in a first field device measuring tank level), (ii) a final control element (or FCE) that can be adjusted to manipulate the process variable (e.g., a second field device such as a valve), and (iii) a controller (e.g., controller 11) configured to adjust the FCE. The logical components may include a control routine at the controller that, based on measurements received at the controller, drives a control signal to cause an actuator (e.g., a valve actuator) to adjust the FCE (e.g., a valve). In the given example, the valve position can be considered the manipulated variable (MV), which can be adjusted to drive the PV to a set point. Control loops can be used in a variety of situations. As an example, a process control system may include a control loop for controlling the water level in a tank. A process control system may include hundreds or thousands of control loops to control a large number of process variables.

[0065] Returning to the function blocks that may be implemented at the controller 11, control-based function blocks typically perform one of the following: (i) an input function, such as that associated with a transmitter, sensor, or other process parameter measurement device (sometimes referred to as an "input block"); (ii) a control function, such as that associated with a control routine that implements PID, fuzzy logic, etc. (sometimes referred to as a "control block"); or (iii) an output function, controlling the operation of some device (e.g., a valve) to perform some physical function within the process control system 5 (sometimes referred to as an "output block"). Of course, hybrid and other types of function blocks exist.

[0066] The function blocks may be stored in and executed by the controller 11, which is typically the case when these function blocks are used for standard 4-20 mA devices and devices such as When the device is or is associated with some type of intelligent field device, or the function block can be stored in and implemented by the field device itself, this can be The one or more control routines 38 may implement one or more control loops that are executed by executing one or more function blocks.

[0067] Wired field devices 15-22 and I / O cards 26 and 28

[0068] The wired field devices 15-22 may be any type of device, such as sensors, valves, transmitters, positioners, etc., and the I / O cards 26 and 28 may be any type of process control I / O device conforming to any desired communication or controller protocol. Figure 1In the example, the field devices 15-18 are standard 4-20 mA devices or devices that communicate with the I / O card 26 via analog lines or combined analog and digital lines. devices, while the field devices 19-22 are smart devices, e.g. Fieldbus field devices, their use The Fieldbus communication protocol communicates over the digital bus with the I / O card 28. Additionally or alternatively, in some embodiments, at least some of the wired field devices 15-22 or at least some of the I / O cards 26, 28 communicate with the controller 11 using the process control data highway 10 or by using other suitable control system protocols (e.g., Profibus, DeviceNet, Foundation Fieldbus, ControlNet, Modbus, HART, etc.).

[0069] Wireless field devices 40-46

[0070] exist Figure 1 In the wireless field devices 40-46, wireless protocols such as The wireless field devices 40-46 may communicate directly with one or more other devices or nodes of the wireless network 70 that are also configured to communicate wirelessly (e.g., using the wireless protocol or another wireless protocol). To communicate with one or more other nodes that are not configured to communicate wirelessly, the wireless field devices 40-46 may use a wireless gateway 35 that is connected to the process control data highway 10 or to another process control communication network. The wireless gateway 35 provides access to the various wireless devices 40-58 of the wireless communication network 70. In particular, the wireless gateway 35 provides communication coupling between the wireless devices 40-58, the wired devices 11-28, or other nodes or devices of the process control plant 5. For example, the wireless gateway 35 may provide communication coupling by using the process control data highway 10 or by using one or more other communication networks of the process plant 5.

[0071] Similar to the wired field devices 15-22, the wireless field devices 40-46 of the wireless network 70 perform physical control functions within the process plant 5, such as opening or closing a valve or taking a measurement of a process parameter. However, the wireless field devices 40-46 are configured to communicate using the wireless protocol of the network 70. Thus, the wireless field devices 40-46, the wireless gateway 35, and the other wireless nodes 52-58 of the wireless network 70 are producers and consumers of wireless communication packets.

[0072] In some configurations of the process plant 5, the wireless network 70 includes non-wireless devices. For example, Figure 1middle, Figure 1 Field device 48 is a conventional 4-20mA device, while field device 50 is a wired To communicate within the network 70, the field devices 48 and 50 are connected to the wireless communication network 70 via wireless adapters 52a, 52b. The wireless adapters 52a, 52b support wireless protocols such as WirelessHART and may also support protocols such as Fieldbus, PROFIBUS, DeviceNet, etc. In addition, in some configurations, the wireless network 70 may include one or more network access points 55a, 55b, which may be separate physical devices in wired communication with the wireless gateway 35, or may be provided as an integrated device with the wireless gateway 35. The wireless network 70 may also include one or more routers 58 to forward packets from one wireless device to another within the wireless communication network 70. Figure 1 In FIG. 1 , wireless devices 40 - 46 and 52 - 58 communicate with each other and with wireless gateway 35 via wireless links 60 of wireless communication network 70 or via process control data highway 10 .

[0073] Factory 5 Backend Environment 125

[0074] As described above, the backend environment 125 includes various components, such as computing devices, operator workstations, databases or repositories, etc., which are generally shielded or protected from the harsh conditions and materials of the field environment 122. The backend environment 125 may include any one or more of the following, each of which may be communicatively connected to the data highway 10: (i) one or more operator workstations 71; (ii) a configuration application 72a and a configuration database 72b; (iii) a data historian application 73a and a data historian database 73b; (iv) one or more other wireless access points 74 for communicating with other devices using other wireless protocols; and (v) one or more gateways 76, 78 to systems external to the immediate process control system 5.

[0075] Operator Workstation 71

[0076] A user (eg, an operator) can use the operator workstation 71 to view and monitor the runtime operation of the process plant 5 via the GUI, and to take any diagnostic, corrective, maintenance, or other actions that may be required. Tool 101 can be used to design the GUI provided by the workstation 71 .

[0077] At least some of the operator workstations 71 may be located in various protected areas in or near the plant 5 , and in some cases, at least some of the operator workstations 71 may be remotely located, but still communicatively coupled to the plant 5 .

[0078] The operator workstation 71 may be a wired or wireless computing device and may be a dedicated or multi-purpose device. For example, in some embodiments, the application, routine, or collection of specially configured circuits (e.g., ASICs) that implement the functionality provided by the workstation 71 may be implemented by any appropriately configured computing device or collection of computing devices (e.g., a desktop computer, a laptop computer, a mobile device such as a phone or tablet, a client / server system, etc.) that can access the network 10 and may include a user interface having input components (e.g., a mouse, a keyboard, a touch sensor, hardware buttons, an audio sensor for voice input, a camera or motion sensor for gesture input, etc.) and output components (e.g., a display, a speaker, etc.) that enables a user of the workstation 71 to monitor runtime parameters, change runtime parameters, or perform or monitor diagnostic, corrective, or maintenance operations.

[0079] Data history library 73a and database 73b

[0080] The data historian application 73a collects some or all of the data provided via the data highway 10 and historizes or stores the collected data in a historian database 73b for long-term storage. The data historian application 73a and the historian database 73b can be centralized and can have a single logical appearance to the process control system 5 (e.g., they can appear as a single application or application suite), although multiple instances of the data historian application 73a can execute simultaneously within the process control system 5 and the data historian 73b can be implemented across multiple physical data storage devices. Each instance of the data historian application 73a can be implemented on any suitable computing device or collection of computing devices (e.g., a desktop computer or workstation, a laptop computer, a mobile device such as a phone or tablet, a client / server system, etc.), which can include a user interface having input components (e.g., a mouse, keyboard, touch sensor, hardware buttons, audio sensor for voice input, camera or motion sensor for gesture input, etc.) and output components (e.g., a display, speakers, etc.).

[0081] Wireless Access Point 74

[0082] One or more other wireless access points 74 enable devices in the backend environment 125 (and sometimes in the field environment 122) to communicate with other devices using wireless protocols, such as Wi-Fi or other wireless local area network protocols compliant with IEEE 802.11, mobile communication protocols (such as WiMAX (Worldwide Interoperability for Microwave Access), LTE (Long Term Evolution) or other ITU-R (International Telecommunication Union Radiocommunication Sector) compliant protocols), short wavelength radio communications (such as near field communication (NFC) and Bluetooth), or other wireless communication protocols.

[0083] Typically, such a wireless access point 74 allows a handheld or other portable computing device (e.g., a user interface device 75) to communicate over a corresponding wireless process control communication network that is distinct from and supports a different wireless protocol than the wireless network 70. For example, the wireless or portable user interface device 75 may be a mobile workstation or diagnostic test device (e.g., an instance of one of the operator workstations 71) used by an operator in the process plant 5. In some cases, in addition to the portable computing device, one or more process control devices (e.g., the controller 11, field devices 15-22, or wireless devices 35, 40-58) also communicate using the wireless protocol supported by the access point 74.

[0084] Gateways 76 and 78

[0085] The gateways 76 and 78 can interface with systems external to the current process control system 5. Typically, such systems are consumers or providers of information generated or manipulated by the process control system 5. For example, the process control plant 5 can include a gateway node 76 to communicatively connect the current process plant 5 to another process plant. Additionally or alternatively, the process control plant 5 can include a gateway node 78 to communicatively connect the current process plant 5 to an external public or private system, such as a laboratory system (e.g., a laboratory information management system or LIMS), an operator rounds database, a material handling system, a maintenance management system, a product inventory control system, a production scheduling system, a weather data system, a shipping and handling system, a packaging system, the Internet, another provider's process control system, or other external system.

[0086] Configuration application 72a and database 72b

[0087] Continue to refer Figure 1, a configuration application 72a and a configuration database 72b (collectively, the "configuration system 72") may be used to configure certain aspects of the plant 5. Various instances of the configuration application 72a may be executed on one or more computing devices (not shown) to enable a user to create or change process control modules and download these modules to the controller 11 via the data highway 10, as well as to enable a user to create or change an operator interface through which an operator can view data and change data settings within a process control routine (e.g., an interface provided by the workstation 71).

[0088] Typically, but not necessarily, the user interface of the configuration system 72 is different from the operator workstation 71 because configuration and development engineers use the user interface of the configuration system 72 regardless of whether the plant 5 is operating in real time, while operators use the operator workstation 71 during real-time operation of the process plant 5 (also interchangeably referred to herein as "runtime" operation of the process plant 5).

[0089] Each instance of the configuration application 72a can be implemented on any suitable computing device or collection of computing devices (e.g., a desktop computer or workstation, a laptop computer, a mobile device such as a phone or tablet computer, a client / server system, etc.), which may include a user interface having input components (e.g., a mouse, a keyboard, a touch sensor, hardware buttons, an audio sensor for voice input, a camera or motion sensor for gesture input, etc.) and output components (e.g., a display, speakers, etc.).

[0090] In operation, the configuration database 72b stores controller configurations used by controllers in the plant 5, process modules representing various areas or units of the plant 5, or user interfaces created (eg, configured) by a user.

[0091] Generally speaking, the phrase "process module" refers to a collection of data, instructions, or some combination thereof, representing a collection of process control elements or components (e.g., equipment such as field devices, tanks, pipes, etc.) included in a specific area or unit of a plant. For example, a plant may include a "tap water" unit that receives city water, stores it in a tank, and distributes it to other areas of the plant as needed while maintaining a desired tank level. The process module for the "tap water" unit may include data identifying the equipment in the unit (e.g., the tank, inlet and outlet pumps, valves, tank level indicators, etc.); data indicating how each component is connected (e.g., indicating that valve "CV013" is the inlet valve upstream of the tank between the tank and the water supply, indicating that it can be opened or closed to manipulate the flow of water into the tank); control routines for controlling various aspects of the unit (e.g., for opening the water supply to fill the tank when the liquid level reaches a certain minimum level); and so on. In some cases, a process module includes or references equipment objects, where each equipment object represents an actual equipment component in the plant. Some people may find it helpful to think of a process module as a blueprint for a plant unit. The described system may include a process module GUI that facilitates designing the configuration of these blueprints (ie, process modules) and the corresponding physical devices (ie, process modules) in the units represented by the blueprints.

[0092] Returning to the configuration system 72, similar to the data historian application 73a and database 73b, the configuration application 72a and configuration database 72b can be centralized and can have a single logical appearance to the process control system 5, although multiple instances of the configuration application 72a can be executed simultaneously within the process control system 5. In addition, the configuration database 72b can be implemented across multiple physical data storage devices. Thus, the configuration application 72a, the configuration database 72b, and the user interface thereto (not shown) comprise the configuration or development system 72 for controlling or displaying modules.

[0093] In further operation, configuration system 72 enables creation, assignment, and storage of logical identifiers for components in field environment 122. Logical identifiers may be referenced by control modules and devices implemented in plant 5 to interact with the components (and associated signals) assigned to the logical identifiers.

[0094] For example, one or more devices in a plant may each have an assigned "device tag" or "DT." A device tag (sometimes referred to as a "field device tag") is a logical entity that identifies a particular field device. Generally speaking, a device tag is used to logically associate or assign an input or output block of a control module to a particular field device. Once a device tag is associated with a particular I / O port or I / O channel, the field device becomes bound to the block. This process control system I / O binding may occur automatically based on sensing of the I / O or field device. Additionally or alternatively, this binding may occur during configuration of the process control module (e.g., by a user).

[0095] In addition, one or more signals transmitted or received by devices in the plant can each have an assigned "signal tag", which is sometimes referred to as a "device signal tag" or "DST". In some cases, DST only needs to be implemented for devices that transmit or receive more than a single signal. Collectively, DT and DST can be simply referred to as "tags", "system tags" or "system identifiers". In many cases, a logical identifier has an associated value or set of values, each of which represents a specific variable value (e.g., a measurement result) or command. In general, tags can be used by the process plant 5 in the field environment 122 and the backend environment 125 to uniquely identify the associated device or signal. Thus, control routines can reference the tags and associated values ​​to implement control of the plant.

[0096] To illustrate, for a given field device, the configuration database 72b may store information that maps or binds a logical identifier or tag to a specific hardware address or I / O channel. A hardware address may identify a specific controller, a specific I / O card connected to a specific controller, or a specific address for connecting a specific I / O card to an I / O channel of a field device. In some cases, this mapping or binding may be stored at the controller 11, the user interface device 75, the operator workstation 71, or any other desired device (e.g., any device that needs to resolve a logical identifier). After a tag is bound to a hardware address or I / O channel, it is considered "assigned."

[0097] Additional Examples of Device 5

[0098] although Figure 1 Only a single controller 11 is shown, along with a limited number of (i) field devices 15-22 and 40-46, (ii) wireless gateway 35, (iii) wireless adapter 52, (iv) access point 55, (v) router 58, and (vi) wireless process control communication network 70, but Figure 1Any number of controllers 11 may be included in a process control plant or system 5 , and any controller 11 may communicate with any number of wired or wireless devices and networks 15 - 22 , 40 - 46 , 35 , 52 , 55 , 58 , and 70 to control a process in the plant 5 .

[0099] Configuration Tools 101

[0100] Figure 2A Shown Figure 1 A block diagram of the configuration tool 101 is shown, including a draft controller configuration 222 that can be designed and tested using the configuration tool. Advantageously, a set of logic 223 for the draft controller configuration 222 can be tested and iteratively improved within the tool 101 before being finalized and downloaded to the configuration database 72b and the real-time device 202 (e.g., the controller 11 or any other suitable operating device in the plant 5).

[0101] Components of Configuration Tool 101

[0102] The configuration tool 101 includes an electronic device 205 and one or more databases that store: (i) templates 213 for equipment objects representing various types of equipment in the plant (e.g., pumps, valves, tanks, flow / level / pressure / temperature indicators, etc.), each having a graphic that can be dragged and dropped onto a canvas area of ​​a graphical configuration GUI 212 and configured to represent a specific device (e.g., virtual or physical) and linked to other graphics 213 to create (a) a process module 224 representing an area in the plant, or (b) a process module GUI 226 (representing the process module 224) that can be used by an operator to monitor the operation of an area of ​​the plant during runtime; (ii) templates 215 for function blocks that can be dragged and dropped onto a canvas area of ​​a logic configuration GUI 210 to create logic 223 of a controller configuration 222 to be implemented by one or more controllers; and (iii) one or more preview parameters 217 for configuring how the configuration 222 is tested. The configuration tool 101 may be communicatively coupled to a configuration database 72b, which may store: one or more controller configurations 242; one or more process modules 244; one or more process module GUIs 246; and one or more tag bindings 248.

[0103] The electronic device 205 is an electronic computing device that includes a memory 205a, a processor 205b, and a communication interface 205c, each of which can be communicatively connected to a system bus (not shown) of the device 205. The communication interface 205c can include multiple interfaces, such as (i) one or more network interface cards or "NICs" (e.g., wireless cards or wired cards) for coupling the device 205 to external nodes or devices, and (ii) one or more input / output ("I / O") interfaces for coupling the device 205 to one or more devices or modules configured to relay user input to the device 205 or provide output to the device 205 in a form that can be used by one or more users. For example, the I / O interface 205c of the device 205 can be communicatively coupled to one or more UI components 205d, including one or more input components 205e and one or more output components 205f. An exemplary output component 205f is a display, which can be any suitable component or device configured to display information in pictorial or visual form (e.g., using LED, LCD, or CRT technology), and can include a screen (which can be touch-sensitive in some instances), a projector, or any other output device capable of providing visual output. An input component 205e can be any suitable component or sensor that can be actuated or interacted with to provide input to the device 205, and can include a hardware actuator that is mechanically actuated to provide input (e.g., a key, button, etc.) or a sensor that is actuated by detecting changes in an electromagnetic field (e.g., a capacitive or resistive touch sensor that can be integrated with the display 205f to form a touch screen).

[0104] The memory 205a of the device 205 includes (i) a configuration routine 206 for designing and testing controller configurations, (ii) a draft controller configuration 222 that can be assigned to and ultimately uploaded to the controller, (iii) a draft process module 224 representing an area of ​​the plant 5, and (iv) a draft process module GUI 226 configured to enable an operator to monitor and control the process module 224 represented by the GUI 226. First, the configuration routine 206 (sometimes referred to as a "tool 206" or "module 206") is a set of instructions that, when executed, causes the device 205 to (i) display the logic configuration GUI 210 or the graphical configuration GUI 212, and (ii) use the sandbox 208 to test logic developed via one of the GUIs 210 / 212. Second, a draft controller configuration 222 is a controller configuration that can be designed, tested, and edited using routine 206 and includes (i) logic modules 223 (which can be any suitable set of instructions; control routines; applications, etc.) and (ii) non-logic modules 225. Third, a draft process module 224 is a process module that can be designed using routine 206. Fourth, a draft process module GUI 226 is a process module GUI that can be designed using routine 206. Any one or more of modules 208-212 can be a module or component of routine 206, or can be a relatively independent module or component that can be called or launched by routine 206.

[0105] Generally speaking, the draft process module 224 is a collection of data, instructions, or some combination thereof that represents a particular area or unit of the plant 5, including the equipment (e.g., field devices, tanks, piping, etc.) in that particular area or unit. Typically, the process module GUI 226 is a graphical operator interface that depicts the equipment included in the area or unit represented by the process module 224. Some may find it helpful to think of the process module 224 as a blueprint for an area of ​​the plant and the process module GUI 226 as an interface for designing the blueprint (i.e., the module 224) and the corresponding physical unit.

[0106] Routine 206 is a set of machine-readable instructions (e.g., a software module, application, or routine) that, when executed by processor 205b, causes device 205 to provide a graphical user interface (GUI) for interacting with tool 101. In some instances, device 205 may interact with a server (not shown) to receive data or instructions for providing the GUI. Routine 206 may be a dedicated application for configuration tool 101, or may be an application that is not specifically dedicated to configuration tool 101 (e.g., a web browser).

[0107] The sandbox 208 is a set of machine-readable instructions (e.g., a software module, application, or routine) that, when executed by the processor 205 b, causes the device 205 to implement a test environment for the logic 223 of the configuration 222. The sandbox 208 may include a software emulation of the controller (e.g., the controller 11) for which the configuration 222 is being designed, as well as software emulations of one or more field devices that may be coupled to the intended controller. Note that, in an embodiment, anything executed within the sandbox 208 has no effect outside of the sandbox 208 (i.e., execution will have no effect on the operation of the plant 5).

[0108] Exemplary Operation of Tool 101

[0109] In operation, the tool 101 can: (i) provide a logic configuration GUI 210 that enables a user to design and modify a configuration 222, including logic 223; (ii) test the logic 223 in the sandbox 208, upload the configuration 222 to the database 72 (where it is stored as a final configuration 242 and ultimately propagated to the real-time device 202); and (iii) display the GUI 212 that enables a user to design a process module 224 and a corresponding GUI 226 for the process module 224. Note that the tool 101 can implement a "preview mode" associated with the GUI 210 or the GUI 222 that enables a user to (i) view and modify one or more of the preview parameters 217 to test the logic 223 of the configuration 222; and (ii) test the logic 223 using the sandbox 208.

[0110] The preview parameters 217 may include process variables received or transmitted by the draft controller configuration 22 , logic parameters that affect the implementation of the logic 223 (eg, a proportional term, an integral term, or a derivative term), or any other suitable parameters.

[0111] Example preview parameters 217 may include injection state parameters for one or more variables of a block. The injection state indicates whether the associated variable should use a value fed to it from a real-time device or upstream block or a value manually set by the user (e.g., to test the response of the block and logic 223). As an example, an analog input (AI) block for a temperature indicator may have an injection state indicator that indicates whether the block should use a real-time temperature measured in the field or a test value for the temperature manually provided by the user. Similarly, various status or alarm parameters of a block (e.g., adjustment parameters such as gain, reset, rate, etc.) may also be overwritten with manual values.

[0112] Figure 2B Shows the implementation of preview mode to test Figure 2AAn exemplary method 280 is shown for configuring the logic 223 of the configuration 222. The method 280 may be implemented in whole or in part by the system configuration tool 101 (eg, by the device 205). The method 280 may be stored in memory as one or more instructions or routines.

[0113] The method 280 begins at block 282 when the tool 101 provides a GUI (e.g., GUI 210) for designing a draft controller configuration. The GUI can include one or more areas, including (i) input block templates (e.g., AI or DI blocks, which are configured to receive a value from a field device linked to the block and forward the value to any other linked blocks); (ii) function block templates (e.g., PID blocks that implement various functions); and (iii) output block templates (e.g., AO or DO blocks, which are configured to receive a value or command from a block and cause the controller to transmit a signal carrying the value or command to a field device linked to the block). These template blocks can be dragged and dropped into the canvas area of ​​the GUI, where they can be linked and configured to define the logic 223 of the controller configuration 222.

[0114] At block 284 , the tool 101 detects a user interaction (eg, via UI component 205 d ) that defines the logic 223 . As described above, the user interaction may be a user dragging and dropping a block template 215 onto the canvas area where it is linked and configured to define the logic 223 .

[0115] At block 286 , the tool 101 stores the draft controller configuration 222 with the logic 223 to memory.

[0116] At block 288, tool 101 implements logic 223 in sandbox 208. Block 288 can occur in response to a user interacting with a graphical element of GUI 210 (e.g., a button for starting testing). During testing, a user can override the values ​​fed to a given block of logic 223 (e.g., by another block or by a real-time device) by "injecting" values ​​manually set by the user. The user can inject values ​​to analyze the response of the block and logic 223 (e.g., by injecting abnormal values, by triggering an alarm, by setting a faulty device state, etc.).

[0117] At block 290, tool 101 determines whether the user wants to continue modifying logic 223 or save logic 223 as a final draft. Generally speaking, if the user wants to modify logic 223 while testing, the method can return to step 286. That is, the user can return to the canvas area of ​​GUI 210 to modify logic 223 (e.g., by adding or removing blocks, or by adjusting one or more parameters that define the behavior of the blocks, such as the proportional, integral, or derivative values ​​of a PID block). After testing logic 223, the user can interact with a button or other GUI element to stop testing and return to editing. If desired, the user can edit logic 223 while executing logic 223 in sandbox 208.

[0118] When the user completes designing and testing logic 223, tool 101 can detect user input representing a command to finalize draft controller configuration 222. For example, device 205 can detect user interaction with any suitable GUI element configured to receive such a command. The GUI element can be a button labeled "Finalize Configuration," "Save Configuration," "Upload Configuration to Configuration Database," "Upload Configuration to Assigned Controllers," etc.

[0119] At block 292, the tool 101 may transmit the draft configuration 222 to the database 72b, where it is saved as the final controller configuration 252. The database 72b may then propagate the configuration 242 to the appropriate real-time devices (eg, to the controller 11).

[0120] Exemplary Control Modules, Process Modules, and Process Module GUIs

[0121] Figure 3 Shown Figure 2A 300 of the process module 244 and control module 243 shown in FIG. The control module 243 can be designed via the GUI 210 and used in a "preview mode" Figure 2A The sandbox 208 is shown for testing. Similarly, the process module 244 can be designed via the GUI 212.

[0122] The process module 244 includes a valve object 301 representing a control valve CV1; a tank object 303 representing a tank T1; a valve object 305 representing a valve CV2; and a level transmitter object 307 representing a level transmitter LT1. Each of the objects 301-307 may include parameters describing or corresponding to the device it represents (e.g., a unique tag identifying the appropriate device, such as "CV1"; status or diagnostic parameters for the represented device; a description of the device (e.g., a tank inlet valve); a physical location (e.g., GPS coordinates); valve wetted parts (i.e., parts in contact with the process); a material (e.g., steel); etc.).

[0123] The control module / routine / logic 243 represents the logic for controlling the tank filling process and may be referred to as a control routine or application. Module 243 includes an AI block 321, which is associated with the level transmitter LT1; a PID block 323, which includes logic for operating on the value passed to the PID block 323 (representing the tank level) (e.g., a value between 0% and 100%); and an AO block 323, which is associated with the control valve CV1.

[0124] In operation, LT1 measures the liquid level (e.g., in the tank) and transmits a signal to a controller implementing module 243 (e.g., controller 11) or an I / O card coupled to the controller. Based on the signal, AI block 321 generates a value representing the liquid level. For example, the controller may receive a 4-20 mA signal representing a range from 0% full to 100% full. Based on this signal (e.g., 12 mA), AI block 321 generates a corresponding value (e.g., 50%) and transmits this value to PID block 323. Based on the logic implemented by PID block 323, PID block 323 may transmit a command to AO block 235 to adjust the position of valve CV1 to achieve the desired setpoint liquid level (e.g., if the tank level should be 65%, the valve may need to be opened further). AO block 325 receives this command and causes the controller implementing AO block 325 to transmit a signal (e.g., 4-20 mA) to the actuator of valve CV1 to adjust the valve in a manner consistent with the command (e.g., further open the valve).

[0125] Advantageously, a user can design a control module 243 using the system 101 and can iteratively test the logic of the control module 243 until the control module 243 achieves desired results in response to various conditions. The user can do this without having to upload the control module 243 to the configuration database 72b, without having to propagate the module 243 to a real-time controller, and without having to test the logic on the real-time controller.

[0126] Figure 4 Shows that it can be used to design Figure 2A An example of a graphical configuration GUI 212 of a process module GUI 246 (which may be used as an operator interface) is shown. Note that Figure 4 The GUI 246 shown in FIG. 2 is merely an example—the GUI 246 may take different forms depending on the implementation and on the process control unit it represents.

[0127] The graphical configuration GUI 212 includes: (i) a library area 405 including one or more graphics representing template equipment objects 213 (e.g., a valve template, a pump template, a tank template, a flow indicator template, a pipe template, etc.), and (ii) a canvas area 401 in which a user may create a process module or a process module GUI, such as the GUI 246. The GUI 246 includes a plurality of graphics 421-427 representing equipment in the unit represented by the GUI 246.

[0128] In operation, a user can drag one or more graphics 213 into the canvas area 401, where she can bind the object to a specific tag (and thus bind the object to the device corresponding to the tag). The user can also link the objects in the canvas area to define a process module (e.g., module 244) and a GUI 246 representing the process module. As described above, the GUI 246 includes graphics 421-427, which correspond to the objects 301-307 (and therefore correspond to the devices represented by the objects 301-307).

[0129] Figure 5 An exemplary control routine 500 that can be designed and previewed using configuration tool 101 is shown. Control routine 500 includes four blocks: an analog input (AI) block 502, an AI block 504, a control block 506, and an AO block 508. Depending on the implementation, AI blocks 502 and 504 can represent analog signals received via I / O channels (e.g., from field devices) by a controller implementing routine 500 or an I / O card coupled to the controller. For example, AI block 504 can be bound to a first device signal tag (DST) that identifies a specific AI I / O channel on a first I / O card, and the value provided by AI block 504 can therefore be driven by the value of a signal on the specific AI I / O channel (e.g., a 4-20 mA signal provided by a flow transmitter field device representing measured flow). Similarly, AO block 508 can represent an analog signal that will be transmitted by a controller implementing routine 500 via an I / O channel (e.g., to a field device) or to an I / O card coupled to the controller. For illustration, the AO block 508 can be bound to a second DST that identifies a specific AO I / O channel at a second IO card. Thus, a value fed to the AO block 508 can cause the second I / O card to drive a signal on a specific AO I / O channel based on the value received at the AO block 508 (e.g., the value can cause the second I / O card to drive a 4-20 mA signal to a valve field device via the AO I / O channel to control the position of the valve).

[0130] In general, a designer creates routine 500 by dragging and dropping graphics representing template control blocks 215 from a library area of ​​GUI 210 onto a canvas area of ​​GUI 210 to create blocks 502-508, connecting blocks 502-508 as desired, and setting parameters to configure blocks 502-508 so that labels or signals can be linked or bound to one or more of blocks 502-508, if desired, and so that desired functionality can be configured for one or more of blocks 502-508, if desired.

[0131] Although the control routine 500 provides analog outputs based on a set of analog inputs, it should be understood that the control routines implemented by the controller 11 or other controllers in the plant 5 can provide any suitable number of analog or digital outputs based on any suitable number of analog or digital inputs. The inputs to the control function blocks and control routines used in the plant 5 can be parameter values ​​received from field devices (e.g., via analog input blocks or discrete input blocks), or parameter values ​​received from other control function blocks or other control routines. Similarly, the outputs provided by the control function blocks and control routines implemented by the controllers in the plant 5 can be parameter values ​​or commands provided as inputs to other control routines or blocks (e.g., discrete or analog output blocks that provide parameters or commands to field devices, control function blocks such as PID blocks or discrete control blocks, etc.). Although the control routine 500 includes a PID function block 506, it should be understood that the control routines created using the system 101 and implemented in the plant 5 can use other types of control function blocks.

[0132] In any case, a designer can design routine 500 and other control routines implemented by the controllers described herein using system 101. Specifically, a designer can design a routine by adding visual representations of the blocks he or she wants to include in the routine to a "canvas area," interacting with the visual representations to configure parameters and logic associated with the blocks (e.g., by clicking on the visual representation to launch a drop-down menu that enables such configuration), and establishing connections between the inputs and outputs of the blocks to thereby define the flow of information between the blocks and thereby facilitate design of the logic of the broader control routine.

[0133] For example, with specific reference to control routine 500, a designer can drag a generic PID block template (not shown) onto the canvas area to instantiate Figure 5512 ). A PID function block 506 is shown in FIG. At a high level, a PID block includes logic for driving a process variable (PV) or controlled variable (CV) (e.g., the temperature level of a fluid in a tank) to a desired level or set point (SP) by manipulating a manipulated variable (MV), such as the valve position of a control valve on an inlet hot water line. The generic PID block template is configured to: (i) calculate an error 514 between a set point 512 and a measured process variable 514; and (ii) apply a proportional term 518, an integral term 520, and / or a derivative term 522 to the error 516 to produce an output value 526. Generally speaking, the output value 526 represents the additional change in MV required to move the PV 514 closer to the set point. As an example, the PID block may gradually open a valve over time to avoid overshooting the SP 512, and may therefore rely on feedback from the measured PV 514 to incrementally command the valve to open more and more (or open less and less as the PV 514 approaches the SP 512). When the error 514 is zero, the output 526 will be zero, indicating that no further changes are needed to achieve the desired SP 512 .

[0134] When a designer instantiates function block 506, she may configure parameters 518-522 to affect the behavior of function block 506. For example, the designer may change one or more of terms 518-522 to cause block 506 to reach SP 512 more aggressively at a higher risk of overshooting SP 512 and developing oscillations, or may change one or more of the terms to cause the controlled variable to reach SP 512 at a slower and more conservative rate that is less likely to cause overshoot and / or oscillations.

[0135] Input blocks 502 and 504 can be instantiated by dragging and dropping template AI blocks onto the canvas area and binding each of them to a label. For example, a designer can bind AI block 504 to a system label (e.g., TI-093) that is unique to a field device measuring a PV (e.g., temperature) that the designer wishes to use as measured PV 514 for PID block 506. The user can then draw a link between AI block 504 and PV 514 of function block 506 so that AI block 504 feeds PV 514. System labels can be similarly bound to AI block 502. In some cases, the designer can use a label representing a variable that can be changed by the user (e.g., to adjust a setpoint). In some cases, the designer can use the output of a second function block, thereby implementing cascade control, rather than using AI block 502 as an input to SP 112.

[0136] Finally, the output block 508 can be instantiated by dragging and dropping the template AO block onto the canvas area and binding it to a label (e.g., a label unique to the control valve described previously). The designer can then link the output 526 to the block 508 so that the PID block 506 feeds the AO block 508.

[0137] The control system 5 may include a number of other module templates configured to use specific routines or logic configured to derive outputs, as well as other control routines developed by linking one or more input blocks, control blocks, or output blocks created from the templates.

[0138] Exemplary Logic Configuration GUI

[0139] Figure 6-14 An exemplary wireframe or screenshot of a logic configuration GUI is shown that may be presented by configuration tool 101 to facilitate designing a controller configuration (e.g., configuration 242) and logic for the controller configuration (e.g., logic 223, logic 243, and control routine 500 shown in Figures 2, 3, and 5).

[0140] Figure 6 An exemplary wireframe 600 of the logic configuration GUI 210 is shown, which may be presented by the configuration tool 101 to facilitate designing a controller configuration (e.g., configuration 242) and logic therefor (e.g., logic 223, logic 243, and control routine 500 shown in Figures 2, 3, and 5).

[0141] Figure 6 The GUI 210 shown in FIG. 2 includes a navigation area 601 , a canvas area 603 , a preview area 605 , a toolbar 607 , a tab bar 609 , and a title bar 611 . The canvas area 603 includes an input block area 621 , a control block area 623 , and an output block area 625 .

[0142] The navigation area 601 typically displays a file hierarchy with which a user can interact to select a control routine to design or configure. The hierarchy may indicate the associated controllers, units, regions, or plants to which a given control routine is assigned. In some instances, the navigation area 601 instead becomes or displays a library area that can be launched by interacting with an element in the GUI 210 (e.g., a toolbar 607 or an element in the canvas area 601). In other instances, the library area may be located elsewhere within the GUI 210. For example, Figure 8 An example 800 is shown including a library area 801 between a navigation area 601 and a canvas area 603 .

[0143] The library area (e.g., library area 601) displayed by GUI 210 typically includes a list of template function blocks (e.g., Figure 2A215). The template function blocks 215 may include template input blocks (e.g., template AI and DI blocks), template control blocks, or template output blocks (e.g., template AO and DO blocks). Examples of template control blocks include template PID blocks, arithmetic blocks, integrator blocks (INT), input selector (ISEL) blocks, signal characterizer (SGCR) blocks, internal model control (IMC) blocks, or any other blocks representing a specific model (e.g., an adaptive control model, a neural network model, etc.), a specific algorithm, a specific logic set, or a specific function.

[0144] Return to Figure 6 , the canvas area 603 generally represents a design area in which a user may place one or more graphical representation templates 215, wherein the user may (i) interact with the placed graphics to instantiate the graphics or otherwise cause the graphics to represent specific functional blocks (e.g., by binding input or output blocks to signal labels), and (ii) link the placed graphics to define control routines (e.g., Figure 2A and Figure 3 ). For example, a user can design control routine 243 by: (i) dragging an AI block template and an AO block template from the library area into canvas area 603 to create AI block 321 and AO block 325, and interacting with blocks 321 and 325 to bind them to unique tags representing the signal transmitted by the LT1 transmitter and the signal received by the CV1 valve, respectively; (ii) dragging a PID block template from area 601 into canvas area 603 to create PID block 323 (e.g., and interacting with the graphic to set or modify various parameters of block 323, such as the proportional term or the integral term); and (iii) linking the output of AI block 321 to the input of PID block 323, and linking the output of PID block 323 to the input of AO block 325.

[0145] During preview mode, canvas area 603 may display values ​​near the lines connecting the blocks to indicate the values ​​being passed from the first block to the second block. For example, system 101 may initiate preview mode while displaying control module 243 in canvas area 603. Thus, canvas area 603 may display a first value being passed from AI block 321 to PID block 323, and a second value being passed from PID block 323 to AO block 325, where the first value represents the tank level measured by the LT1 indicator (e.g., 55% full) and the second value represents the command to the CV1 valve (e.g., a command to adjust CV1 to 65% open). If desired, the user can interact with any of these displayed values ​​to "inject" a new manual value. For example, the user can interact with the first value showing 55% to change it to 45%. This causes PID block 323 to receive the manually injected value instead of the actual measured value. A similar process may occur with respect to the second value being passed to AO block 325. This injection of manual values ​​allows the user to test the logic of control routine 243 while designing it. For example, if changing one of the fill values ​​causes valve CV1 to adjust to a position that overfills the tank or allows the tank level to drop below a minimum level, the user can redesign routine 243 to avoid the undesirable behavior (e.g., by adding or removing blocks, by changing the settings of control blocks such as PID block 323, etc.).

[0146] To help make it easier to identify the type of blocks in a designed control routine, when a user drags a template from the library area to the canvas area 603, the system 101 can automatically place input blocks in the input area 621, control blocks in the control area 623, and output blocks in the area 625. In some examples, the areas 621-625 are not explicitly designated by visible lines. In other examples, the lines that distinguish the areas 621 through 625 are visible.

[0147] continue Figure 6 , the preview area 605 can display information related to one or more blocks shown in the canvas area 603 (e.g., in response to a user's interaction with a block in the canvas area 603). The displayed information may include one or more process values ​​passed or received by the block, a label bound to the block, scaling parameters, linearization parameters, various operational or diagnostic parameters, etc. The user can interact with the displayed information to inject a manual value to replace the currently displayed value (e.g., a value received via a signal from a field device).

[0148] Toolbar 607 may display various interactive elements that cause system 101 to perform actions. For example, toolbar 607 may include a "Preview" button that launches preview area 605. Toolbar 607 may include an "Online" button that deactivates all manual values ​​that have been injected into the displayed control routine and causes canvas area 603 to display online values ​​passed between blocks.

[0149] Tab bar 609 displays tabs for displaying one or more windows of canvas area 603 , with each tab representing a different control routine.

[0150] Title bar 611 may include elements that enable system 101 to undo or redo previous activities, or to access various options associated with system 101 and GUI 210 .

[0151] In some instances, one or more of elements 601-625 may be collapsible or hidden at any given time. For example, in some instances, preview area 605 may be manually or automatically deactivated at certain times or based on certain triggers. For example, a user may interact with an "exit" element (e.g., located in the upper right of area 605) to hide or deactivate area 605. This may cause canvas area 603 to expand to occupy the area previously occupied by area 605. Similarly, when areas 601-623 are hidden or deactivated, a user may activate any one or more of areas 601-623. For example, toolbar 607 may include a "preview mode" button or element that causes area 605 to be activated.

[0152] Note that GUI 210 may be configured differently depending on the implementation and may not include any one or more of elements 601-623 if desired. Additionally, depending on the implementation, GUI 210 may include elements or areas not shown. Figure 7-14 Each of the diagrams shows a screenshot of the GUI 210, which includes Figure 6 Unless directly relevant to the following discussion, these same or similar components / regions may not be labeled with reference numerals.

[0153] Figure 7 An exemplary screenshot 700 of the GUI 210 is shown in which a user interacts with tab 701 to open a palette of graphical templates that can be used to help build a controller configuration. Note that the screenshot 700 includes Figure 6 The same areas and elements 601-625 are shown.

[0154] Screenshot 700 also shows an exemplary routine 710 in canvas area 603 that the user can edit. Routine 710 includes input block 711, control blocks 713 and 715, and output blocks 717 and 719. A collection of fields 721-727 displays parameter values ​​passed between blocks. For example, field 721 displays the value of a parameter passed from input block 711 to control block 713. If desired, the user can interact with field 721 (e.g., by clicking or double-clicking) to initiate manual mode, in which the user can cause a user-defined value to be passed to block 713 instead of the value output by block 711 (e.g., which may correspond to an actual measurement result obtained by a field device corresponding to block 711). This may be helpful if the user is interested in how test routine 710 responds to receiving a series of different input values ​​from block 711.

[0155] In operation, a user may interact with element 701 (eg, a tab) to launch a library area or palette displaying various template function blocks, which the user may drag into the canvas area 603 and configure. Figure 8 An exemplary palette that may be displayed in response to interaction with element 701 is shown in FIG.

[0156] Figure 8 An exemplary screen shot 800 of the GUI 210 is shown, including a screen shot 800 of the GUI 210 in response to Figure 7 701. The option panel 801 is launched by interacting with the tab 701 shown. The option panel 801 includes a plurality of function block templates 803, including a PID template (including template logic for implementing PID control), a Splitter template (this is used for "split range control"; the Splitter function block takes a single input and calculates two outputs; this allows an integrating (e.g., PID) controller to drive both outputs without saturation when one or both outputs are limited), and a Signal Generator template.

[0157] If necessary, the option board 801 may also include input function blocks (such as AI and DI blocks), output function blocks (such as AO and DO blocks), and Figure 8 At some point, the user may wish to initiate a "preview mode" in which a preview pane is shown to display test or preview data associated with the configuration of routine 701. Figure 9 An exemplary technique for launching a preview pane is shown in .

[0158] Figure 9 An exemplary screenshot 900 of the GUI 210 is shown in which a user interacts with element 901 to launch a preview pane (not shown). Figure 9As shown, before the user's interaction, the GUI 210 may show an information pane 903 related to an object in the canvas (e.g., an object with which the user has interacted). For example, in this case, the information pane 903 includes information related to the object also in the canvas. Figure 7 713 (in this case, TIC-13807). Note that TIC stands for "Temperature Indicating Controller." In any case, interacting with element 901 can cause system 101 to display information related to the PID block 713 shown in FIG. Figure 10 The preview pane shown is similar to the preview pane.

[0159] Figure 10 An exemplary screenshot 1000 of the GUI 210 is shown, wherein: (i) in response to a user and Figure 9 , showing the interaction of element 901 , preview pane 1001 is displayed, and (ii) the user is interacting with graphical element 723 to inject a test value to be passed to block 715 .

[0160] Preview pane 1001 may display information related to routine 701 in addition to or in lieu of displaying information related to one or more blocks that make up routine 701. For example, in this case, routine or module 701 has a unique identifier or label "TIC-13807." Figure 10 The label is displayed in field 1010. Preview pane 1001 may include fields that display other information about routine 710, including a title field 1011 (not yet configured here; this can be user-friendly text that plant operators would prefer to see in their runtime GUI (e.g., a faceplate) instead of, or in addition to, the label (e.g., TIC-13807); an exemplary title is "Tower Bottom Temperature"); a description field 1013 (not yet configured); a process type field 1015 (not yet configured; for example, "Temperature Control"); a run frequency field 1017 (set to 1 second in this case); and a controller assignment field 1019 (in this example, routine 701 has not yet been assigned to a controller, so field 1019 is empty).

[0161] Figure 11 An exemplary screenshot 1100 of the GUI 210 is shown in which a user interacts with the graphical element 711 via a cursor 1101 to launch a preview pane for an object corresponding to the graphical element 711 . Figure 12 An exemplary preview pane 1201 is shown in FIG.

[0162] Figure 12 An exemplary screenshot 1200 of the GUI 210 is shown, which illustrates the following example: Figure 11 The element 711 shown interacts with the preview pane 1201 provided. Figure 12 A user is shown interacting with field 1203 via cursor 1205 to inject a test value into the input represented by field 1203 .

[0163] Figure 13 An exemplary screenshot 1300 of the GUI 210 is shown in which a user is interacting with tab 1301 to launch a pane (not shown) for viewing test values ​​used in the control routine shown in the test GUI 210 . Figure 14 An exemplary test value pane 1401 is shown in FIG.

[0164] Figure 14 An exemplary screenshot 1400 of the GUI 210 is shown, including a screen shot of the user and Figure 13 Pane 1401 is launched after interaction with tab 1301 as shown.

[0165] Exemplary Graphical Configuration GUI

[0166] Figure 15-20 An exemplary screenshot of a graphical configuration GUI is shown that may be presented by the configuration tool 101 to facilitate designing process modules (e.g., Figure 2A 224 and 244) and an operator GUI representing the process modules (e.g., Figure 2A and Figure 4 GUIs 212 and 246 shown).

[0167] Figure 15 The graphical configuration GUI 212 is shown (also in Figure 2A ) is shown in an exemplary screen shot 1500 that may be presented by the configuration tool 101 to facilitate designing process modules and process module GUIs. As described above, a process module GUI (e.g., Figure 2A The GUI 244 shown in FIG. 244 may be displayed as an operator display during operation to facilitate operator monitoring and control of the process modules shown by the process module GUI.

[0168] The first area 1501 can be a canvas area in which a user places and connects various elements or graphics 1531-1537 to define a process module GUI 1530 (and, potentially, a corresponding process module). Here, the GUI 1530 includes: (i) a level indicator graphic 1531 configured to display the level measured by the corresponding level indicator and the set point for the level; (ii) a valve graphic 1533 that can display the status of the corresponding valve (e.g., by color); (iii) a pump graphic 1535 that can display the status of the corresponding pump (e.g., by color); and (iv) a tank graphic 1537 that can display the status of the corresponding tank (e.g., the level measured by the level indicator).

[0169] The second area 1511 may be a "label information area" configured to display information about labels (e.g., unique identifiers) bound to components represented by the graphics shown in the canvas area 1501. For graphics that have not yet been bound to any specific device, a field in area 1511 may indicate that these graphics are "unbound elements."

[0170] Third area 1513 may be a "configuration area" where a user may configure information specific to any of the graphics 1531-1537 placed in canvas area 1501. For example, a user may click on graphic 1535 to cause tool 101 to display interactive fields in configuration area 1513 for editing information about graphic 1535 or the device represented by graphic 1535 (e.g., pump "P-137A" in this case). As an example, a user may interact with the fields shown in area 1513 to edit the colors of various sub-elements in graphic 1535 (e.g., the body color and the center color). If desired, the colors may be context-specific. That is, a user may edit the properties of graphic 1535 so that, when GUI 1530 is displayed, the colors of the sub-elements of graphic 1535 depend on the values ​​of one or more parameters (e.g., representing the status of pump P-137A, such as whether the pump is running, has become running, is not running, or has failed, etc.).

[0171] Continue to refer Figure 15 , a cursor 1551 is shown interacting with a "Preview" button 1550 included in the toolbar 1517. Interacting with the button 1550 may cause the tool 101 to display a preview pane 1601, an example of which is shown in FIG. Figure 16 Shown in.

[0172] Steering Figure 16 , shows an exemplary screen shot 1600 of the GUI 212, including a screen shot 1600 of the GUI 212 in response to a user's interaction with the Figure 151550 is shown. The preview pane 1601 is activated by interacting with the element 1550 shown. The preview pane 1601 may include one or more fields that display the values ​​of operating parameters. Exemplary operating parameters include alarm parameters, interlock parameters, health parameters (e.g., health index), and operator parameters. Operator parameters may include parameters related to the device being represented and related to the operator or the operator's primary task. Exemplary operator parameters include current state; fault state; first exit parameter (which indicates which interlock trip condition is initiated first); interlock state (e.g., showing whether the interlock is in operation or not); mode parameter indicating whether the device is in automatic mode (i.e., controlled by associated logic or control routine) or manual mode (i.e., controlled by the operator); "permit active" parameter (e.g., indicating a permissive condition that prohibits transitioning from a passive state to an active state - an interlock can force a transition from active to passive); set point parameter (e.g., passive vs. active for a pump); and shutdown state.

[0173] The user can inject a test value for any operating parameter, thereby overriding a value measured by a field device (e.g., a measured temperature, pressure, flow, etc.) or a value set by a control routine. Exemplary values ​​set by a control routine include an output value passed from a first block to a second block (e.g., a set point, a proportional term, an integral term, or any other suitable value) or an output value passed to a field device (e.g., an output value from an AO or DO block). The user can inject test values ​​in a variety of ways. For example, as described below, the user can inject test values ​​by directly interacting with the graphics shown in the canvas area (e.g., Figure 17 ) or by interacting with the preview pane shown next to the canvas area (as Figure 18 as shown) to inject test values.

[0174] Figure 17 An exemplary screenshot 1700 of the GUI 212 is shown in which a user injects a test value for an operating parameter by interacting with the graphic 1531 via a cursor 1701. The graphic 1531 may include one or more interactive fields with which the user may interact to inject the test value. For example, the graphic 1531 includes (i) a "PV" field that displays the measured process variable (in this case, the measured liquid level of 24 inches); (ii) a "SP" field that displays the value of the set point for the measured liquid level (here, 24 inches, indicating that the process has reached a steady state); and (iii) an "OUT" field that displays a color (which may represent the state of the liquid level indicator represented by the graphic 1531; in some embodiments, the color is not bound to the state). Note that the set point in the "SP" field may be determined by a control routine or logic (e.g., Figure 2A The logic 223 or 243 shown in Figure 5 The routine 500 shown in Figure 7710, etc.). Depending on the implementation, the logic for setting the setpoints may be implemented by a controller in the plant 5 during normal operation or during test operation, or by a virtual controller in a test environment. In some cases, the setpoints are set by an operator rather than by a control routine. In any case, a user can inject test values ​​to override any one or more of these values.

[0175] Figure 18 An exemplary screenshot 1800 of GUI 212 is shown in which a user injects a test value for an operating parameter by interacting with a field 1801 included in preview pane 1601. After clicking on field 1801, a drop-down menu may appear including an element labeled "Inject Test Value" or similar. The user may click on this element, and tool 101 may respond by enabling the user to change the value in field 1801. If desired, a drop-down menu may appear including the value the user can inject. This action may be particularly desirable when field 1801 represents a state with a preset number of different potential states. In some instances, the user may simply provide a desired value (e.g., by typing, by interacting with a number shown on the screen, by speaking the desired value, by manipulating a bar or scrolling to adjust the value, etc.).

[0176] Figure 19 An exemplary screenshot 1900 of the GUI 212 is shown in which a user interacts with a field 1901 for binding a tag, causing the GUI 212 to (i) highlight a graphic 1535 representing the device to which the tag is bound, and (ii) display a preview pane 1905 in area 1513 showing information about the object to which the tag is bound (e.g., a pump with the tag “P-137A”).

[0177] Figure 20 An exemplary screenshot 2000 of the GUI 212 is shown in which a user interacts with a field 2001 for an unbound label, causing the GUI 212 to display a preview pane 2003 in area 1513 showing information related to the unbound graphic. For example, in this case, the GUI 212 shows that the liquid level graphic 1537 is not bound to a label. In this case, the liquid level graphic 1537 is configured to be bound to an analog control function block (e.g., a PID block). Because the graphic 1537 is not bound to a label, the tool 101 generates a default control block with pre-injected values. The user can interact with any of the fields shown in the preview pane 2003 to edit the injection values ​​associated with the graphic 1537 and the generated default control block. If desired, the user can also bind the graphic 1537 to an existing control block, which can cause the fields in the preview pane 2003 to be populated with the parameter values ​​used by the bound control block.

[0178] Other considerations

[0179] Described below are various aspects, apparatuses, systems, components, devices, methods, and techniques for managing discrete process control elements (eg, discrete devices, discrete communication channels, discrete signals, etc.) in a control system 5 and for intelligently debugging the discrete elements.

[0180] As described above, the techniques described herein help plant personnel avoid the time- and labor-intensive processes associated with traditional design systems for process control systems. By using the configuration tool 101, users can design, test, and "preview" control logic for controlling a process before downloading it to a configuration database or process controller in the plant. This enables rapid testing and improvement of control logic during the design phase, avoiding the time-consuming iterative process of designing, downloading to a database, propagating to a real-time controller, and testing on a physical controller. The configuration tool 101 also separates the testing of the control logic of the controller configuration from the testing of the non-logical aspects of the controller configuration, enabling users to complete the design of the control logic before downloading the configuration to the controller. Advantageously, after downloading the designed and tested controller configuration to the controller, the user only needs to test the non-logical aspects of the configuration before implementing the controller configuration on a real-time process in normal operation.

[0181] When implemented in software, any of the applications, services, and engines described herein may be stored in any tangible, non-transitory computer-readable memory, such as on a magnetic disk, a laser disk, a solid-state memory device, a molecular memory storage device, or other storage medium, in RAM or ROM of a computer or processor, or the like. Although the example systems disclosed herein are disclosed as including software and / or firmware and other components executed on hardware, it should be noted that such systems are merely illustrative and should not be considered restrictive. For example, it is contemplated that any or all of these hardware, software, and firmware components may be implemented exclusively in hardware, exclusively in software, or in any combination of hardware and software. Thus, although the example systems described herein are described as being implemented in software executed on a processor of one or more computer devices, it will be readily understood by those of ordinary skill in the art that the examples provided are not the only way to implement such systems.

[0182] With particular reference to method 200, the functionality described may be performed in whole or in part by Figure 1Each of the described methods may be implemented by a set of circuits that are permanently or semi-permanently configured (e.g., an ASIC or FPGA) to perform the logical functions of the corresponding method, or at least temporarily configured (e.g., one or more processors and a set of instructions or routines representing the logical functions and stored in a memory) to perform the logical functions of the corresponding method.

[0183] Therefore, although the present invention has been described with reference to specific examples, these examples are intended to illustrate rather than limit the present invention, and it will be apparent to those skilled in the art that changes, additions, or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the present invention. Furthermore, although the foregoing text sets forth a detailed description of many different embodiments, it should be understood that the scope of this patent is defined by the text of the claims appended hereto and their equivalents. This detailed description should be construed as exemplary only and does not describe every possible embodiment, as describing every possible embodiment would be impractical, if not impossible.

[0184] Throughout the specification, multiple instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are shown and described as separate operations, in some embodiments one or more of the individual operations may be performed simultaneously.

[0185] As used herein, any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

[0186] As used herein, the terms "comprises," "includes," "has," or any other variations thereof are intended to encompass non-exclusive inclusion. For example, a process, method, article, or apparatus that includes a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, unless expressly stated to the contrary, "or" refers to an inclusive or and not an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or exists) and B is false (or does not exist), A is false (or does not exist) and B is true (or exists), and both A and B are true (or exist).

[0187] In addition, the use of "a" or "an" to describe elements and components of the embodiments herein should be understood to include one or at least one. The singular also includes the plural unless it is obvious that it is otherwise indicated.

[0188] In various embodiments, the hardware systems described herein can be implemented mechanically or electronically. For example, a hardware system can include dedicated circuits or logic that are permanently configured (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC) to perform certain operations). A hardware system can also include programmable logic or circuits (e.g., as contained within a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. It should be understood that the decision to implement a hardware system mechanically, in a dedicated and permanently configured circuit, or in a temporarily configured circuit (e.g., configured by software) may be driven by cost and time considerations.

[0189] Furthermore, the patent claims at the end of this document are not intended to be interpreted under 35 U.S.C. §112(f) unless conventional means-plus-function language is expressly recited, such as "means for" or "step for" language expressly recited in a claim. At least some aspects of the systems and methods described herein relate to improvements to computer functionality and to improving the functionality of conventional computers.

[0190] Common terms and phrases

[0191] Throughout this specification, some of the following terms and phrases are used.

[0192] Application. See Routine.

[0193] Communication Interfaces. Some of the described devices or systems include "communication interfaces" (sometimes referred to as "network interfaces"). For example, device 205 shown in Figure 2 includes communication interface 205c. Each of the described communication interfaces enables the system of which it is a part to (i) send information or data to other systems or components, or (ii) receive information or data from other systems or components. When a communication interface is or includes an interface that is configured to enable the system to couple to a peripheral device or component such as one of the UI components 205d shown in Figure 2 (e.g., a keyboard, monitor, external hard drive, etc.), the interface may be referred to as a "peripheral interface" or "I / O interface" (see "I / O interface"). In some instances, one or more of the described communication interfaces may be used to establish a direct connection to another system (e.g., via RF such as Bluetooth or via a cable such as a USB or CAT / Ethernet cable). If desired, each of the described communication interfaces enables the system of which it is a part to connect to the system of which it is a part via a link. Figure 1 The network 10 is shown, or any other suitable network (eg, a personal area network (PAN), a local area network (LAN), or a wide area network (WAN)).

[0194] If desired, each described communication interface can include (i) circuitry capable of connecting to a wired link that transmits electrical or optical signals to another device (e.g., via a coaxial cable or fiber optic cable) and communicating with the other device, or (ii) circuitry capable of wireless communication (e.g., short-range or long-range communication) via electromagnetic signals such as radio frequency (RF) signals. In addition, in some instances, references to "communication interfaces" can refer to multiple interfaces for communicating with components or systems external to the system. For example, in some instances, the described communication interfaces can refer to a group of communication interfaces including: one or more wired communication interfaces, one or more wireless communication interfaces, one or more I / O or peripheral interfaces, or some combination thereof. The described communication interfaces and systems can conform to any one or more suitable communication protocols, standards, or technologies, such as those described herein.

[0195] Communication Protocols. In this specification, communication protocols, standards, and technologies may be collectively referred to as "communication protocols." Exemplary communication protocols, standards, or technologies that may be used by the described systems include those that facilitate communication via nanoscale networks, near-field networks, personal area networks ("PANs"), local area networks ("LANs"), backbone networks, metropolitan area networks ("MANs"), wide area networks ("WANs"), internet area networks ("IANs"), or the Internet.

[0196] Exemplary near-field network protocols and standards include typical radio frequency identification ("RFID") standards or protocols and near-field communication ("NFC") protocols or standards. Exemplary PAN protocols and standards include 6LoWPAN, Bluetooth (i.e., a wireless standard for exchanging data between two devices using radio waves in the range of approximately 2.4 to 2.485 GHz), IEEE 802.15.4-2006, ZigBee, Thread protocol, Ultra-Wideband ("UWB"), Universal Serial Bus ("USB") and Wireless USB, and ANT+. Exemplary LAN protocols and standards include the 802.11 protocol and other high-frequency protocols / systems for wireless communication in frequency bands in the range of approximately 1 GHz-60 GHz (e.g., including the 900 MHz, 2.4 GHz, 3.6 GHz, 5 GHz, or 60 GHz bands), as well as standards for suitable cables such as coaxial cables and fiber optic cables. Exemplary technologies for facilitating wireless WANs include those used for LANs, as well as 2G (e.g., GPRS and EDGE), 3G (e.g., UMTS and CDMA2000), 4G (e.g., LTE and WiMax), and 5G (e.g., IMT-2020) technologies. Note that the Internet can be considered a WAN.

[0197] Other communication protocols and standards that system 5 may use include BitTorrent, Bluetooth Bootstrap Protocol (“BOOTP”), Domain Name System (“DNS”), Dynamic Host Configuration Protocol (“DHCP”), Ethernet, File Transfer Protocol (“FTP”), Hypertext Transfer Protocol (“HTTP”), infrared communication standards (e.g., IrDA or IrSimple), Transmission Control Protocol / Internet Protocol (“TCP / IP”) (e.g., any protocol used in each TCP / IP layer), Real-time Transport Protocol (“RTP”), Real Time Streaming Protocol (“RTSP”), Simple Mail Transfer Protocol (“SMTP”), Simple Network Management Protocol (“SNMP”), Simple Network Time Protocol (“SNTP”), Secure Shell Protocol (“SSH”), and any other communication protocols or standards, or any combination thereof.

[0198] Communication Link. Unless otherwise specified, a "communication link" or "link" is a path or medium connecting two or more nodes. A link can be a physical link or a logical link. A physical link is an interface or medium over which information is transmitted and can be wired or wireless in nature. Exemplary physical links include (i) wired links, such as cables with conductors for transmitting electrical energy or fiber optic connections for transmitting light, and (ii) wireless links, such as wireless electromagnetic signals that carry information via changes made to one or more properties of electromagnetic waves.

[0199] As described above, a wireless link may be a wireless electromagnetic signal that carries information via changes made to one or more properties of an electromagnetic wave. The wireless electromagnetic signal may be a microwave or radio wave and may be referred to as a radio frequency or "RF" signal.

[0200] A logical link between two or more nodes represents an abstraction of the underlying physical link or intermediate node connecting the two or more nodes. For example, two or more nodes can be logically coupled via a logical link. A logical link can be established via any combination of physical links and intermediate nodes (e.g., routers, switches, or other networking devices).

[0201] A link is sometimes referred to as a "communication channel." In wireless communication systems, the term "communication channel" (or just "channel") generally refers to a specific frequency or frequency band. A carrier signal (or carrier) can be transmitted at a specific frequency or within a specific frequency band of a channel. In some instances, multiple signals can be transmitted on a single frequency band / channel. For example, signals can sometimes be transmitted simultaneously on a single frequency band / channel via different sub-bands or sub-channels. As another example, signals can sometimes be transmitted on the same frequency band by assigning time slots during which the corresponding transmitter and receiver use the frequency band in question.

[0202] Computer. Generally speaking, a computer or computing device is a programmable machine with two main characteristics. That is, it responds to an instruction set and can execute a pre-recorded instruction list (e.g., a program or routine) in a well-defined manner. A computer according to the present disclosure is a device with a processor and a memory. For the purposes of the present disclosure, the example of a computer includes a server host, a personal computer (e.g., a desktop computer, a notebook computer, a netbook), a mobile communication device (such as a mobile "smart" phone), and a device that provides functionality to obtain instructions from a process or participate in a process through internal components or to an external computer, server, or global communication network (such as the Internet), which is then delivered to other system components. In some embodiments, device 205 may be referred to as a computer.

[0203] Database. In general, a "database" is an organized collection of data that is typically stored and accessed electronically from a computer system. In general, any suitable data store may be referred to as a "database." The present disclosure may describe one or more databases for storing information related to various aspects of the present disclosure. The information stored on a database may, for example, relate to private subscribers, content providers, hosts, security providers, etc. A server (which may or may not be hosted on the same computer as the database) may act as an intermediary between a database and a client by providing data from the database to the client or enabling the client to write data to the database. One of ordinary skill in the art will understand that any reference to a "database" may refer to multiple databases, each of which may be linked to each other.

[0204] Display device. In general, the term "display device" or "display" refers to an electronic visual display device that provides visual output in the form of images, text, or video. In general, a display device can be any display, screen, monitor, or projector suitable for displaying visual output (e.g., images or video output). Exemplary displays include LED screens, LCD screens, CRT screens, projectors, head-up displays, smartwatch displays, head-mounted displays (e.g., VR goggles), etc.

[0205] Graphical User Interface (GUI). See User Interface.

[0206] Input / output (I / O) interface. Generally speaking, the I / O interface of a computer system is a hardware component (e.g., an I / O controller mounted on a motherboard) that communicatively connects one or more processors of the computer system to one or more input or output devices, such as UI devices or peripheral devices. For example, the I / O interface can couple the UI component 205d to other components of the device 205. The I / O interface can receive input and output requests from the system processor, and can then send device-specific control signals to the controlled device based on the requests. The I / O interface can also receive data, requests, or commands from the connected device, and then send these data, requests, or commands to the system processor. The I / O interface is sometimes referred to as a device controller. The software on the system that interacts with the device controller and enables the device controller to control a specific device or otherwise communicate with a specific device is generally referred to as a "device driver."

[0207] Memory and Computer-Readable Media. Generally speaking, as used herein, the phrases "memory" or "memory device" refer to a system or device that includes a computer-readable medium or media ("CRM"). "CRM" refers to media that can be accessed by an associated computing system to place, hold, or retrieve information (e.g., data, computer-readable instructions, program modules, applications, routines, etc.). Note that "CRM" refers to media that are non-transitory in nature and does not refer to intangible, transitory signals such as radio waves.

[0208] The CRM may be implemented using any technology, device, or group of devices included in or in communication with the relevant computing system. The CRM may include volatile or non-volatile media, and removable or non-removable media. The CRM may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store information and can be accessed by the computing system. The CRM can be communicatively coupled to a system bus, thereby enabling communication between the CRM and other systems or components coupled to the system bus. In some embodiments, the CRM can be coupled to the system bus via a memory interface (e.g., a memory controller). The memory interface is a circuit that manages the flow of data between the CRM and the system bus.

[0209] Module. When used in the context of a software system, the term "module" generally refers to an application, routine, or collection of executable instructions. See also "routine." In some instances, the term "module" refers to a component of a physical system (e.g., a car includes multiple modules such as an engine, transmission, brakes, etc.). The context in which the term is used will clarify whether the "module" refers to a software component or a non-software component.

[0210] Network. As used herein and unless otherwise specified, the term "network," when used in the context of a system or device that transmits information or data, refers to a collection of nodes (e.g., devices or systems capable of sending, receiving, or forwarding information) and links connected to enable telecommunications between the nodes.

[0211] The network can include dedicated routers, switches or hubs responsible for forwarding directional traffic between nodes, and optionally, dedicated devices responsible for configuring and managing the network. Some or all nodes can also be suitable for use as routers to guide the traffic sent between other network devices. Network devices can be interconnected in a wired or wireless manner, and network devices can have different routing and transmission capabilities. For example, a dedicated router may be able to carry out high-capacity transmission, while some nodes may be able to send and receive relatively few traffic in the same time period. In addition, the connections between the nodes on the network can have different throughput capabilities and different attenuation characteristics. For example, due to the differences in the physical limitations inherent in the medium, fiber optic cables can provide bandwidths several orders of magnitude higher than wireless links. The network can include a network or subnetwork, such as a local area network (LAN) or a wide area network (WAN).

[0212] Node. Generally speaking, the term "node" refers to a connection point, redistribution point, or communication endpoint. A node can be any device or system (e.g., a computer system) that can send, receive, or forward information. For example, an end device or end system that originates or ultimately receives a message is a node. Intermediary devices that receive and forward messages (e.g., between two end devices) are also generally considered "nodes."

[0213] Object. Generally speaking, the term "object," when used in the context of a software system, refers to a variable, data structure, function, method, instance of a class or template, or some combination thereof. An object can typically be referenced by a unique or relatively unique identifier.

[0214] Processor. The various operations of the exemplary methods described herein may be performed, at least in part, by one or more processors. In general, the terms "processor" and "microprocessor" are used interchangeably, each referring to a computer processor configured to retrieve and execute instructions stored to a memory. By executing these instructions, the (one or more) processors may perform various operations or functions defined by the instructions. Depending on the particular embodiment, the processor may be temporarily configured (e.g., by instructions or software) or permanently configured to perform the relevant operations or functions (e.g., a processor for an application-specific integrated circuit or ASIC). The processor may be part of a chipset, which may also include, for example, a memory controller or an I / O controller. A chipset is a collection of electronic components in an integrated circuit that is typically configured to provide I / O and memory management functions as well as a plurality of general or special registers, timers, and the like. In general, one or more of the described processors may be communicatively coupled to other components (such as memory devices and I / O devices) via a system bus.

[0215] The execution of certain operations may be distributed among one or more processors, not only residing within a single machine, but also deployed across multiple machines. In some exemplary embodiments, one or more processors may be located in a single location (e.g., in a home environment, an office environment, or as a server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0216] Words such as “process,” “calculate,” “compute,” “determine,” “present,” “display,” and the like may refer to the action or process of a machine (e.g., a computer) that manipulates or transforms data represented as physical (e.g., electronic, magnetic, or optical) quantities within one or more memories (e.g., volatile memory, non-volatile memory, or a combination thereof), registers, or other machine components that receive, store, transmit, or display information.

[0217] Routines. Unless otherwise noted, a “routine,” “module,” or “application” described in this disclosure refers to a set of computer-readable instructions that may be stored on a CRM. For example, routine 206 shown in FIG2 may be a set of instructions residing on a CRM in memory 205 a. Typically, a CRM stores computer-readable code (“code”) representing or corresponding to instructions, and the code is adapted to be executed by a processor to facilitate the functionality described as being represented by or associated with the routine or application. Each routine or application may be implemented via a stand-alone executable file, a suite or package of executable files, one or more non-executable files used by the executable file or program, or some combination thereof. In some instances, unless otherwise noted, one or more of the described routines may be hard-coded into one or more EPROMs, EEPROMs, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other hardware or firmware elements.

[0218] Each routine may be represented by code implemented in any desired language, such as source code (e.g., interpretable for execution or compilable to lower-level code), object code, bytecode, machine code, microcode, etc. The code may be written in any suitable programming or scripting language (e.g., C, C++, Java, Actionscript, Objective-C, Javascript, CSS, Python, XML, Swift, Ruby, Elixir, Rust, Scala, or others).

[0219] Server. In general, a server is a program or set of routines that manages network resources or services to provide functionality to other programs or devices, referred to as "clients." A server is typically hosted by a host computer, and the host computer itself may be referred to as a "server." Exemplary servers include database servers, file servers, mail servers, print servers, web servers, game servers, and application servers. A server can be dedicated (e.g., where the software and hardware are dedicated exclusively or almost exclusively to server functions) or virtual (e.g., where the server is hosted by a virtual machine on a physical machine, and / or where the server shares the hardware or software resources of a single machine with another operating system).

[0220] User Interface (UI). Generally speaking, a user interface refers to the components of a computer system through which a user interacts with the computer system. UI components can be hardware, software, or some combination thereof, and can include UI input components, UI output components, or some combination thereof. UI components can be coupled to the system via an I / O interface.

[0221] Examples of the described UI output components include: (i) visual output components, such as lights (e.g., LEDs) and electronic displays (e.g., LCDs, LEDs, CRTs, plasmas, projection displays, heads-up displays, etc.), (ii) audio output components, such as speakers, and (iii) motion generation components, such as motors that provide tactile feedback.

[0222] Examples of the described UI input components include: (i) mechanical or electrical components for detecting physical or touch input, such as hardware actuators (e.g., those used for "hard" buttons found on keyboards, mice, tablets, or phones, etc.) or electrical sensors (e.g., resistive or capacitive touch sensors); (ii) audio sensors (e.g., microphones) for detecting audio input (e.g., voice commands); (iii) image sensors such as those found in cameras for detecting image or video input (e.g., enabling facial recognition input or gesture input without requiring the user to touch the device); and (iv) motion sensors (e.g., accelerometers, gyroscopes, etc.) for detecting motion of the computer system itself (e.g., enabling a user to provide input by rotating or otherwise moving the computer system).

[0223] Some systems provide a graphical user interface (GUI) through a UI output component such as an electronic display. Generally speaking, a GUI is generated via a routine and enables a user to interact with indicators and other graphical elements displayed on the electronic display. Generally speaking, the graphical elements of a GUI can be output elements (i.e., convey some information to the user), control elements (i.e., the user can "interact" to cause the system to perform an action), or both (e.g., an icon can include an image representing a browser and can be interacted with to launch the browser).

[0224] Exemplary GUI control elements include buttons (e.g., radio buttons, check boxes, etc.), sliders, list boxes, spinner elements, drop-down lists, menus, menu bars, toolbars, interactive icons, text boxes, windows that can be moved or minimized and maximized, and the like.

[0225] Generally speaking, a window is an area on a screen that displays information, and its content is displayed independently of the rest of the screen. Typically, a menu is a list of selectable options that a user can select to execute a corresponding command (e.g., expand a menu and display additional options, generate a new window, etc.). Typically, an icon is a small image that represents an object such as a file, application, web page, or command. Users can typically interact with an icon (e.g., by pressing or clicking once or twice) to execute a command, open a document, or run an application.

Claims

1. A configuration system comprising: one or more field devices; a process controller coupled to the one or more field devices; A user interface device is coupled to the process controller, the user interface device being configured to: displaying a GUI for designing a controller configuration, the GUI comprising a canvas area; detecting user input indicative of a user placing a set of graphical representations of function blocks in the canvas area; generating a draft control routine for a draft controller configuration, wherein the draft control routine includes a plurality of function blocks corresponding to the set of graphical representations, each of the plurality of function blocks including: (i) at least one input for receiving an input value from a parameter set, from one of the one or more field devices, or from one of the other function blocks via the GUI; and (ii) at least one output for transmitting an output value to one of the one or more field devices or to one of the other function blocks; A preview mode is implemented by: (i) configuring at least one of the plurality of function blocks to receive a control input from one of the one or more field devices; (ii) executing the draft control routine in a sandbox environment; and (iii) displaying one or more values ​​of one or more parameters used or affected by the draft control routine to enable the user to monitor the draft control routine during execution; and In response to detecting a user interaction with an element of the GUI indicating that the draft controller configuration is finalized: transmitting the draft controller configuration including the draft control routine so that the process controller can receive the draft controller configuration and be configured to operate according to the draft controller configuration.

2. The system according to claim 1, wherein: The user interface device is further configured to: (i) detecting user input representing a command to inject a new value into an input or output of a function block in the draft control routine; and (ii) injecting the new value by overwriting the current value carried by the input or output, so that the input or output carries the new value instead.

3. The system according to claim 1, wherein: The user interface device is further configured to: When the draft control routine is executed, one or more logic parameters of the control logic implemented by the plurality of function blocks are modified based on user input.

4. The system according to claim 3, wherein: The user interface device is configured to modify the one or more logic parameters during the preview mode when the draft control routine is executed.

5. The system according to claim 1, wherein: The user interface device is configured to transmit the draft controller configuration by transmitting the draft controller configuration to a configuration database, wherein the draft controller configuration is propagated from the configuration database to the process controller.

6. The system according to claim 1, wherein: The user interface device is further configured to: downloading a current controller configuration from the process controller, the current controller configuration including a current control routine; The second preview mode is implemented by: (i) executing the current control routine; and (ii) displaying values ​​of one or more parameters used by the current control routine to enable monitoring of the current control routine during execution and to enable comparison with the draft control routine.

7. The system according to claim 1, wherein: The process controller is a first process controller from a plurality of controllers; wherein the user interface device is further configured to detect user input indicating that the draft controller configuration should be assigned to the first process controller; In response to detecting the user input indicating that the draft controller configuration should be assigned to the first process controller: assigning the draft controller configuration to the first process controller.

8. A method for previewing control logic, comprising: displaying a GUI for designing a controller configuration at a user interface device, the GUI comprising a canvas area; detecting, at the user interface device, a user input indicative of placing a set of graphical representations of functional blocks in the canvas area; generating, by the user interface device, a draft control routine for a draft controller configuration for a process controller, wherein the draft control routine includes a plurality of function blocks corresponding to the set of graphical representations, each of the plurality of function blocks including: (i) at least one input for receiving an input value from a field device or from one of the other function blocks; and (ii) at least one output for transmitting an output value to the field device or to one of the other function blocks; A preview mode is implemented by: (i) configuring at least one of the plurality of function blocks to receive a control input from a field device; (ii) executing the draft control routine in a sandbox environment; and (iii) displaying values ​​of one or more parameters used or affected by the draft control routine to enable monitoring of the draft control routine during execution; and In response to detecting a user interaction with an element of the GUI indicating that the draft controller configuration is finalized: transmitting the draft controller configuration including the draft control routine so that the process controller can receive the draft controller configuration and be configured to operate according to the draft controller configuration.

9. The method according to claim 8, further comprising: (i) detecting user input representing a command to inject a new value into an input or output of a function block in the draft control routine; as well as (ii) injecting the new value by overwriting the current value carried by the input or output, so that the input or output carries the new value instead.

10. The method according to claim 8, further comprising: When the draft control routine is executed, one or more logic parameters of the control logic implemented by the plurality of function blocks are modified based on user input.

11. The method according to claim 10, wherein: Modifying the one or more logic parameters includes modifying the one or more logic parameters during the preview mode when the draft control routine is executed.

12. The method according to claim 8, wherein The user interface device is configured to transmit the draft controller configuration by transmitting the draft controller configuration to a configuration database, wherein the draft controller configuration is propagated from the configuration database to the process controller.

13. The method according to claim 8, further comprising: A second preview mode is implemented by (i) executing a current control routine of a current controller configuration downloaded from the process controller, and (ii) displaying values ​​of one or more parameters used by the current control routine to enable monitoring of the current control routine during execution and to enable comparison with the draft control routine.

14. The method according to claim 8, wherein The process controller is a first process controller from a plurality of controllers, and wherein the method further comprises; detecting user input instructing the draft controller configuration to be assigned to the first process controller; In response to detecting the user input indicating that the draft controller configuration should be assigned to the first process controller: assigning the draft controller configuration to the first process controller.

15. A configuration system comprising: one or more field devices; a process controller coupled to the set of field devices; A user interface device is coupled to the process controller, the user interface device being configured to: displaying a GUI for designing a controller configuration, the GUI comprising a canvas area; detecting user input indicative of a user placing a set of graphical representations of function blocks in the canvas area; generating a draft control routine for a draft controller configuration, wherein the draft control routine includes a plurality of functional blocks corresponding to the set of graphical representations, the plurality of functional blocks including: (i) an input block configured to receive a control input value for a control input and forward the control input value; (ii) one or more control blocks linked to the input block and configured to: (a) receiving the control input value forwarded from the input block, and (b) transmitting a control output value for a control output, wherein the control output value is set to a calculated value calculated by applying control logic to the control input value; and (iii) an output block linked to the one or more control blocks and configured to receive the control output value transmitted by the one or more control blocks and forward the control output value; A preview mode is implemented by: (i) configuring the input block to set the value for the control input to a real-time value obtained by a particular field device of the one or more field devices; and (ii) executing the control logic of the one or more control blocks in a sandbox environment; and (iii) displaying one or more values ​​of one or more parameters used or affected by the draft control routine to enable monitoring of the draft control routine during execution of the control logic; and In response to receiving user input, the draft controller configuration including the draft control routine is transmitted so that the process controller can receive the draft controller configuration and be configured to operate according to the draft controller configuration.

16. The system according to claim 15, wherein: The user interface device is further configured to: (i) receiving user input representing a command to inject a new value for the control input; and (ii) injecting the new value by configuring the input block or the one or more control blocks to set the control input value to the new value instead of the real-time value obtained by the field device.

17. The system according to claim 15, wherein: The user interface device is further configured to: (i) receiving user input representing a command to inject a new value for the control output; and (ii) injecting the new value by configuring the one or more control blocks or the output block to set the control output value to the new value instead of the calculated value.

18. The system according to claim 15, wherein: The particular field device is a first field device, and wherein the output block is configured to forward the control output value to a second field device of the one or more field devices.

19. The system of claim 15, wherein: The user interface device is further configured to: One or more logic parameters of the control logic implemented by the one or more control blocks are modified based on user input.

20. The system of claim 19, wherein: The user interface device is configured to modify the one or more logic parameters during the preview mode when the control routine is executed.

21. The system of claim 15, wherein: The user interface device is configured to transmit the draft controller configuration by transmitting the draft controller configuration to a configuration database, wherein the draft controller configuration is propagated from the configuration database to the process controller.

22. The system of claim 15, wherein: The user interface device is further configured to: downloading a current controller configuration from the process controller, the current controller configuration including a current control routine; A second preview mode is achieved by (i) executing the current control routine, and (ii) displaying values ​​of one or more parameters used by the current control routine to enable monitoring of the current control routine during execution and to enable comparison with the draft control routine.

23. A method for previewing control logic, comprising: displaying a GUI for designing a controller configuration, the GUI comprising a canvas area; detecting user input indicative of a user placing a set of graphical representations of function blocks in the canvas area; generating a draft control routine for a draft controller configuration, wherein the draft control routine includes a plurality of functional blocks corresponding to the set of graphical representations, the plurality of functional blocks including: (i) an input block configured to receive a control input value for a control input and forward the control input value; (ii) one or more control blocks linked to the input block and configured to: (a) receiving the control input value forwarded from the input block, and (b) transmitting a control output value for a control output, wherein the control output value is set to a calculated value calculated by applying control logic to the control input value; and (iii) an output block linked to the one or more control blocks and configured to receive the control output value transmitted by the one or more control blocks and forward the control output value; A preview mode is implemented by: (i) configuring the input block to set the value for the control input to a real-time value obtained by a particular field device; and (ii) executing the control logic of the one or more control blocks in an environment local to a user interface device; and (iii) displaying one or more values ​​of one or more parameters used or affected by the draft control routine to enable monitoring of the draft control routine during execution of the control logic; and In response to receiving user input, the draft controller configuration including the draft control routine is transmitted so that a process controller can receive the draft controller configuration and be configured to operate according to the draft controller configuration.

24. The method according to claim 23, further comprising: (i) receiving user input representing a command to inject a new value for the control input; as well as (ii) injecting the new value by configuring the input block or the one or more control blocks to set the control input value to the new value instead of the real-time value obtained by the field device.

25. The method according to claim 23, wherein The particular field device is a first field device, and wherein the output block is configured to forward the control output value to a second field device.

26. The method of claim 23, transmitting the draft controller configuration comprising: The draft controller configuration is communicated to a configuration database, wherein the draft controller configuration is propagated from the configuration database to the process controller.

27. The method of claim 23, further comprising: downloading a current controller configuration from the process controller, the current controller configuration including a current control routine; A second preview mode is implemented by (i) executing a current control routine for a current controller configuration downloaded from the process controller, and (ii) displaying values ​​of one or more parameters used by the current control routine to enable monitoring of the current control routine during execution and to enable comparison with the draft control routine.

Images