CN103793346B - The method of the function of automatic control system, machine readable media and modification part - Google Patents

Abstract

An automatic control and monitoring system is provided including linkable plug-ins that can work in conjunction with each other to transform data or generate events. The resources of the automatic control and monitoring system can be defined polymorphically based on the common object model. Linkable plugins can be linked to utilize and/or affect any type of resource.

Description

Automatic control system, machine-readable medium, and method of modifying functionality of components

Cross References to Related Applications

This application is a non-provisional application of US Provisional Patent Application No. 61/559,020, filed November 11, 2011, entitled "Chainable Plugin Business Logic Through a Generalized Object Model," which is incorporated herein by reference.

Background technique

Embodiments of the present disclosure relate generally to the field of automatic control and monitoring systems. More specifically, embodiments of the present disclosure relate to a linkable plug-in architecture for automatic control and monitoring systems.

There is a wide range of applications for automatic control and monitoring systems, especially in industrial settings. Such applications may include power estimation of various actuators, such as valves, electric motors, etc., and data collection via sensors. A typical automation control and monitoring system may include one or more components such as: programming terminals, automation controllers, input/output (I/O) modules, and/or human machine interface (HMI) terminals.

A Human Machine Interface or "HMI" is commonly used to monitor or control various processes. The HMI can read from or write to specific registers so that they can reflect the operational status of various machines, sensors, processes, and the like. The interface can also write to registers and memory, so that they can control the function of the process to some extent. In a separate monitoring function, little or no actual control is performed. Similar devices are employed in many other settings, such as in automobiles, airplanes, commercial settings, and many other applications. In many applications, rather than communicating with a remote device or process, an interface may be operated in an independent manner.

In these interface devices, the objects used in the interface can be associated with different control, monitoring or any other parameters of the industrial automation device. Some of these objects may have a visual representation on the interface device, while other objects may not be visually represented but accessible by the user for configuration and programming. Users may desire to manipulate these objects, eg, by creating new objects, duplicating objects, editing objects, etc., to create and customize interfaces.

Each of the components in the automatic control and monitoring system can utilize status information for one or more objects of the control and monitoring system (eg, control programs, tags, module configurations, and HMI screens). Sometimes widgets can be used to modify the state information of an object. Therefore, a component may need to communicate a change of state to the control and monitoring system so that other components can learn of a state change of an object of the control and monitoring system. In fact there are cases where state changes may include adding or deleting certain objects within the control and monitoring system. For example, traditional methods of communicating the state of a control and monitoring system object include providing the entire state of the object to the control and monitoring system. It is now recognized that such an approach is sometimes inefficient, providing more information than necessary to describe the changing state of objects within the control and monitoring system. Providing the entire state of an object can lead to bandwidth inefficiencies in communicating state data and processing inefficiencies in consuming and using the data. Furthermore, it is now recognized that this method of providing full state data may in some cases increase the likelihood of inadvertently overwriting other state changes provided in the control and monitoring system.

Additionally, traditional approaches rely on centralized control and monitoring. For example, traditional control and monitoring systems rely on a centralized data model that describes the control system. Reliance on a centralized data model can lead to processing inefficiencies and increased reliance on components hosting the centralized data model, such as controllers.

Contents of the invention

Certain embodiments commensurate in scope with the originally claimed invention are outlined below. These embodiments are not intended to limit the scope of the claimed invention, but rather these embodiments are intended only to provide a brief summary of possible forms of the invention. Actually, the present invention may encompass various forms which may be similar to or different from the embodiments set forth below.

The present embodiment provides a novel method of communicating state changes of objects between components in an automatic control and monitoring system. Since state changes occur within the control and monitoring system, only changed data is communicated to other components within the control and monitoring system. For example, control and monitoring system objects may include control programs, tags, module controls, and graphics for HMI screens. When elements of these objects change, the changed elements may be provided to components that store state information of objects in a data-driven manner. By providing only the features that vary, rather than the full set of features for an object, you can significantly reduce the amount of data passed to the part. Furthermore, the full state of an object may not be required when the object is deleted. Instead, only an indication of deleted objects may be provided, thereby reducing the amount of data to be transferred if an object is deleted. Furthermore, providing changes in a data-driven manner may make the communication agnostic, or independent of specific programming techniques.

Furthermore, the present invention provides a novel method of applying communicated changes and/or distributed commands using execution engines distributed throughout the control and monitoring system to asynchronously execute commands based on changes. For example, one or more of the components of the control and monitoring system (eg, smart I/O devices, programming terminals, PLCs, and HMIs, etc.) may each include an embedded execution engine. The execution engine may be stored on a tangible, non-transitory, computer-readable medium of the component. When triggered (eg, by receiving changed state information), embedded execution engines on various components of the control and monitoring system may respond asynchronously based on triggers or predetermined execution times. For example, distributed commands may be user and/or system defined command scripts that react to state changes in one or more ways. By enabling execution of control logic by means of execution engines embedded on components of the control and monitoring system, more efficient processing can result. For example, this implementation scheme can better utilize multiple central processing unit (CPU) cores by distributing logic throughout the control and monitoring system.

Description of drawings

These and other features, aspects and advantages of the present embodiments will be better understood when the following detailed description is read with reference to the accompanying drawings, in which like numerals represent like parts throughout:

FIG. 1 is a general overview of the framework of portions of an automatic control and monitoring system according to certain aspects of the present invention;

Figure 2 is a schematic overview of an automatic control and monitoring system according to an embodiment of the present invention;

Figure 3 is an overview of some functional components in an interface and a programming terminal according to an embodiment of the present invention;

Figure 4 is an overview of certain views of elements of equipment or containers according to an embodiment of the invention;

5 is a diagram of the control and monitoring system of FIG. 1 illustrating the use of a persistent object model for communicating state changes, according to an embodiment;

Figure 6 shows the progression of state change communication between instrumentation of changes, arbitrators of changes, and audience members, according to an embodiment;

Fig. 7 shows the processing in the case that the state change is not completed according to an embodiment;

Fig. 8 shows the processing in case an external change is made during a pending edit, according to an embodiment;

Figure 9 illustrates a process for aborting pending changes, according to an embodiment;

Figure 10 illustrates a process for compressing pending changes into a set of changes, according to an embodiment;

Figure 11 illustrates an automatic control and monitoring system using a distributed execution engine to execute control commands, according to an embodiment;

Figure 12 illustrates a processing loop executed by an execution engine, according to an embodiment;

Figure 13 shows the process for scheduling commands according to an embodiment; and

Figure 14 shows an automatic control and monitoring system that uses linkable plug-ins to modify the functionality of the control and monitoring system.

detailed description

Typically, control and monitoring systems rely heavily on automatic controllers, such as programmable logic controllers (PLCs), and automatic controller programming (eg, PLC programming) to effect control and monitoring systems when state changes are communicated . Automatic controller programming relies heavily on event-based and/or schedule-based execution of tasks and/or logic (e.g., machine-readable instructions written in a programming language such as relay ladder logic) to implement changes to the control and monitoring system influences. Automatic controllers are often used to consume all input data, calculate and distribute output data, handle changes in data, and distribute data to components of the control and monitoring system. Unfortunately, such a heavy reliance on a centralized data model influenced and hosted by components of the control and monitoring system (eg, automation controllers and automation controller programming) leads to many inefficiencies. For example, as the number of scheduled and event-based tasks for a centralized model increases, performance degradation may occur since many additional changes to a single model may result. Furthermore, heavy use of a centralized model (e.g., via an automated controller) creates a more centralized approach to handling control logic, resulting in inefficient execution of control logic, single points of failure (e.g., when an automated controller fails, The entire control and monitoring system may fail) and may place a processing burden on the automatic controller.

According to this embodiment, the control and monitoring system can become more flexible by utilizing a distributed data model, distributed state change communication, and distributed command execution. For example, the present embodiments demonstrate a more robust and flexible automatic control and monitoring environment by providing increased collaboration capabilities, increased data redundancy, and processing load balancing throughout the control and monitoring system.

Robust Control and Surveillance System

A number of aspects, components, and processes will be described through the following discussion. By way of introduction, the overall systematic review aims to locate these innovations in this paper. FIG. 1 is a diagrammatic representation of a control and monitoring software framework 10 for an interface according to an embodiment of the present disclosure. Framework 10 facilitates building functional software by utilizing a module-based interconnection mechanism 12 that inherently supports dynamic operation and configuration. This dynamic manipulation and configuration capability facilitates effectively providing a feature-rich configuration environment for configurable interfaces. That is, as described below, individual device elements are configured as independently-operating codes that can be individually programmed, pre-written for use when in libraries, customize their functionality and appearance on screen, and interconnected to Provides information to users as well as control and monitoring functions.

Framework 10 includes two related software environments that may belong to a single system (eg, computer). Specifically, the runtime environment 14 enables an operator (e.g., a human user) to interact with the application, such as during runtime (e.g., during use of an interface, typically during interaction with or observation of the process in operation ) processing. The design-time environment 16 allows the designer to configure the interface and its components. For example, the system may graphically present operational information to an operator via the runtime environment 14 on a display (eg, a computer or interface device screen). Additionally, the system may include means for receiving operator input that may be detected and managed via the runtime environment 14 (eg, a keypad). The environments interact as described in detail below, in innovative ways to provide greatly enhanced interface usage and programming.

Runtime environment 14 includes or is provided with access to device elements 18 . Device elements 18 are software components that may include any accessible or configurable element in a software environment. For example, device elements 18 include software components managed by runtime environment 14, such as "ActiveX" controls or ".NET" components. "ActiveX" and ".NET" refer to object-oriented concepts, technologies, and tools. Such programming methods will generally be familiar to those skilled in the art. In this context, such criteria should be considered as examples only, and "element of equipment" should be understood to include any substantially similar component or self-compensating process that can operate as a quasi-independent element, sometimes referred to as for "object". Other standards and platforms exist for such elements, often supported by different companies or industry groups.

Because such equipment elements are fundamental to some of the concepts presented in this article, they are introduced briefly in order. Equipment elements usually include four characteristics: properties, methods, connections (or joints), and communication interfaces. In this context, a property is an attribute that can be adjusted, for example, to define the representation or image of an element in a screen view, its position on the screen, etc. Herein, a method is an executable function (sometimes referred to herein as an element's "functionality" or "state engine") and defines an operation to be performed by executing the element. In this context, a connection is a link between elements and can be used to cause data (read from or written to memory) to be sent to another element.

Specific examples of equipment elements 18 may include software buttons, timers, meters, PLC communication servers, visualizations (such as screens showing the status of components within an automatic control and monitoring system), and applications. In general, almost any recognizable function can be configured as such an element. Furthermore, as discussed below, such elements can communicate with each other to perform various display, monitoring operations and control functions. It should be noted that device element 18 does not require special constraints for supporting design patterns. And, while elements associated with images are very useful, especially for visualization, many elements may not have a visual representation, but may instead perform functions within the HMI, such as calculations, or even management and data exchange between other elements .

Runtime environment 14 typically operates using communications subsystem 20 . The communication subsystem 20 is adapted to interconnect the equipment elements 18 . In practice, communication subsystem 20 may be viewed as comprising a connection of equipment elements 18 . However, communications subsystem 20 may include a range of software, hardware, and firmware that transmits data to and receives data from external circuits, such as automated controllers, other computers, networks, satellites, sensors, actuators, and the like.

The runtime environment 14 generally operates using a behavioral subsystem 22 adapted to manage the behavior of the equipment elements 18 . For example, the responsibilities of behavioral subsystem 22 may include the following: placing and moving device elements, modifying device elements, aggregating device elements on swappable screens, saving and restoring screen layouts, managing security, saving and restoring connection lists, and The runtime environment 14 provides remote access. Also, in practice, such behavior may be referred to as part of each device element's profile (ie, "method" or "state engine").

Design-time environment 16 includes a pre-implementation of behavioral subsystem 22 that facilitates operating runtime environment 14 directly or indirectly without interfering with or impairing the behavior of runtime environment 14 . That is, the equipment element 18 can be designed and reconfigured even while the interface is operated. Behavior subsystem 22 extends access to runtime environment 14 via remote provisioning of design-time environment 16, such as in a conventional browser. Behavior subsystem 22 allows a designer to interact with and change aspects of the HMI's runtime environment 14 by providing the design-time environment 16 or aspects of the design-time environment 16 from the HMI to the programming terminal via a remote programming terminal aspect. For example, an HMI coupled to a laptop via a network may provide configuration capabilities to a user by providing a specific design-time environment 16 to the laptop via the network.

Details and examples of how to achieve this are provided below. In the current embodiment, the design-time environment 16 may be the product of a combination of Dynamic Hypertext Markup Language (DHTML) and Dynamic Server Pages (ASP) server scripting to provide dynamic content to a browser. ASP scripts are specially written code consisting of one or more scripts (ie, small embedded programs) that are processed on a server (eg, a Web server) before the page is sent to the user. Typically, in conventional applications, such scripts prompt the server to access data from and make changes in the database. Next, the script typically constructs or customizes the page before sending it to the requester. As discussed below, such scripts are used very differently in the present framework, for example to create visualizations without prior knowledge of the functionality of the device elements or their interrelationships.

Design-time environment 16 allows designers to make specialized implementations of behavioral subsystems 22 or interchangeable design-time models by facilitating changes to device elements. A specific example of a design-time implementation of the behavioral subsystem 22 includes a Web-based design-time environment 16 that extends access to the runtime environment 14 on the HMI via a TCP/IP connection between the HMI and the remote device. The web-based design-time environment 16 facilitates managing device elements without compromising operational performance or security. In one specialized implementation, the behavioral subsystem 22 gives the designer the ability to manipulate aspects of the runtime environment 14 using a web browser that can access the relevant interface or HMI. As noted above, and as described in detail below, this is accomplished using a combination of dynamic content, scripting, and configuration of device element properties.

FIG. 2 is a diagrammatic representation of a control and monitoring system 24 implementing the above-described framework, eg, for industrial automation, according to an embodiment of the present disclosure. System 24 includes HMI 26 adapted to interface with networked components and configuration equipment. System 24 is shown to include HMI 26 adapted to communicate with process 28 via control/monitoring device 30 (e.g., remote computer, automated controller, such as a programmable logic controller (PLC), or other controller). Component cooperation. HMI 26 may physically resemble existing hardware, such as panels, monitors, or stand-alone devices.

Cooperation between HMI 26 and components of process 28 may be facilitated through the use of any suitable network strategy. In practice, an industry standard network, such as DeviceNet, may be employed to enable data transfer. Such a network allows data exchange according to predefined protocols and may provide capabilities for operating networked elements. As noted above, while the present discussion refers to networked systems and systems incorporating controllers and other equipment, the HMI 26 and programming techniques described can be equally applied to non-networked components (e.g., GPS displays, gaming displays, cell phone displays, Tablet PC monitors, etc.) and for networked systems outside of industrial automation. For example, the arrangements and processes described below may be used in facility management, automotive and vehicle interfaces, computer numerical control (CNC) machines, point-of-sale (POS) systems, control interfaces for commercial markets (e.g., elevators, entrance systems), etc. , just to name a few examples.

The runtime or operating environment 14 managed and structured by the corresponding behavioral subsystems is stored and resides on the HMI 26 . For example, such a behavioral subsystem may be adapted to load an application configuration framework (eg, 10 ) from a storage location, such as during initial manufacture or setup of HMI 26 . When loaded, the stored application framework may be adapted to create screens and position user interface device elements (the actual images or graphical representations corresponding to the elements) in the screens. These application, screen, and user interface elements are various types of device elements. As described below, the HMI 26 includes stored applications that specify the layout and interaction of equipment elements. A web-based design-time environment 16 based on a runtime engine is also loaded and resides on the HMI 26 . The design-time environment 16 may be adapted to handle advanced features (eg, security management) for both the design-time environment and the runtime environment.

HMI 26 can be adapted to allow a user to interact with almost any process. For example, processes may include: compressor stations, oil refineries, batch operations for manufacturing food items, mechanized assembly lines, and the like. Accordingly, process 28 may include various operating components such as electric motors, valves, actuators, sensors, or a myriad of manufacturing, machining, material handling, and other applications. Additionally, process 28 may include control and monitoring equipment for adjusting process variables through automation and/or observation. The illustrated process 28 includes sensors 34 and actuators 36 . Sensors 34 may include any number of devices suitable for providing information about processing conditions. Actuator 36 may similarly include any number of devices adapted to perform mechanical action in response to input signals.

As shown, these sensors 34 and actuators 36 are in communication with a control/monitoring device 30 (eg, an automation controller) and may be assigned to specific addresses in the control/monitoring device 30 that are accessible by the HMI 26 . Sensors 34 and actuators 36 may communicate directly with HMI 26 . These devices can be used to operate processing equipment. In fact, they can be used in a process loop that is controlled and monitored by the control/monitoring device 30 and/or the HMI 26 . Such process loops may be initiated based on process input (eg, input from sensors 34 ) or direct input (eg, operator input received through HMI 26 ).

Server software on the interface allows viewing of the development environment, and direct reconfiguration of the interface (specifically device elements and their associated appearance and function) without the need for specialized viewing or configuration software. This benefit comes from the fact that the device elements and the design-time environment are themselves owned by the HMI 26 and are "provided" by the HMI 26 to a browser or other common viewer on the programming terminal 46 . In other words, the necessary support for external computer workstations (eg, laptops and desktops) can be reduced or eliminated. It should be noted that references to a "browser" for viewing and modifying the configuration of an interface are not limited to web browsers or any specific browser. The browser's reference intent is exemplary. Generally, the term "browser" is used herein to refer to software including any general-purpose viewer.

Through programming of device elements as described below, the HMI 26 may be considered to include instructions for presenting one or more screen views or visualizations and interact with them by reference to the screen views (e.g., buttons, position of touch screen, etc.) The device elements that are executed when the HMI 26 interacts. Screen views and device elements can be defined by any desired software or software package. For example, screen views and device elements may be invoked or executed by the operating system 38 . As described above, the device element according to the present embodiment may be an object conforming to the ".NET" or "ActiveX" standard. The operating system itself may be based on any suitable platform, such as Window CE, OS-X, etc. As referenced herein, device elements and tools support network services or technologies for sending data over a network (eg, the Internet). These device elements thus follow a set of rules regarding information sharing as described below. And is adapted for use by various scripting and programming languages. Such device elements enable provisioning of interactive content to external applications, such as LANs, WANs, Intranets, Extranets or even the World Wide Web. Thus, operating system 38 and various device elements facilitate dynamically configuring HMI 26 via browser 48 by allowing configuration access (eg, serving up) to browser 48 .

For example, such configuration accesses include accesses for instantiating device elements. In other words, new device elements can actually be created and executed from the browser 48 . Furthermore, it should be noted that the browser 48 does not require actual functional access. Indeed, in one embodiment, a request via the browser 48 results in a "draw" sequence of operations based on the functionality of the data and the content of the device element in the container, thereby allowing Representation of device elements and access to their configuration. This allows configuration via a remote workstation without requiring technical support for the remote workstation.

In addition to the operating system 38 and device elements as described above (and as described in more detail below), the HMI 26 includes an application or application layer 40 . An application that may itself include device elements facilitates accessing and obtaining information from various device elements of the HMI 26 . Specifically, the application 40 representation may be the first level in a multi-level device element enumerated for execution. In an actual implementation, the application 40 may include a user application in the form of an XML page. The user application then interacts with the user or operator, and with the designer, as described in more detail below.

Screen views and device elements can be described as independent executable software. In this implementation, screen views are defined by appropriate code written in a markup language (eg, hypertext markup language or HTML). Therefore, configuration of the graphic interface screen of the HMI 26 can be performed without using a conversion program. Additionally, by programming the device elements, screen views can be developed directly on the HMI 26 via resident server software (referred to as server 42 ) that makes the resident development environment available for remote access. Specifically, in one embodiment, representations of certain device elements (eg, ActiveX controls) are provided to the browser 48 without providing the software components themselves. Because the development or design-time environment can be accessed via the browser 48, the need to download changes to screens and update remote configuration software applications can be eliminated.

As noted above, device elements may include functionality by which they read from or write to specific memories or storage registers, typically in other devices (but also within the HMI). For example, a specific function may correspond to writing to or reading from a register 32 of the control/monitoring device 30 . In simple cases, for example, an object accesses a piece of data (eg, the state of a component as determined by a sensor), and generates output signals to write values corresponding to the states of different networked devices. As will be discussed in more detail below, such status information may be communicated via status delta 43 . For example, in the embodiment depicted in FIG. 2 , control/monitoring device 30 and HMI 26 may use status increment 43 to communicate status information. Additionally, programming terminal 46 may also use status increment 43 to communicate status information with control/monitoring device 30 and HMI 26 .

Of course, more complex functions can be configured. For example, in an industrial control and monitoring environment, such equipment elements can simulate the operation of a series of physical parts, such as momentary contact buttons, buttons with delayed outputs, switches, etc. A number of pre-programmed device elements are available for use with the HMI 26 . Such functional modules may be accessible via a network, or may reside on the HMI 26 , or on a separate device directly linked to the HMI 26 . In this way, the HMI provider or software provider can provide many possible building blocks from which screens and complex control and monitoring functions can be programmed. In fact, a library 44 of available equipment elements may reside on the HMI 26 to facilitate configuring the HMI 26, as described below. On-screen instructions may invoke device elements for performing desired functions based on operator input, and these instructions may be programmed as versions of pre-programmed elements. For example, an operator may provide initial input by touching a location on a touch screen or depressing a key on a keyboard. Then based on the on-screen instructions and the device elements associated with the instructions (eg, having a specific location trigger a call or execute a pre-configured device element), the desired function can be performed. Thus, an operator can interact with the process to generally change screen views, write to registers, or command the generation of other output or control signals. In a stand-alone implementation, interactions can be as simple as recalling or storing data, changing screens, etc.

For some HMIs with many such screens and a large number of device elements, one or more separate interface screens may be employed. Each device element, in turn, can be uniquely programmed to consider specific inputs, perform specific functions, and generate signals for specific outputs. As described below, multiple such device elements may be loaded and hosted in a single software "container" (eg, an ActiveX container).

The HMI 26 can be configured by interacting directly with the screen or panel of the HMI 26 itself (if one exists), but in many cases the configuration will be performed from the remote programming terminal 46 . Access to the resident repository 44 and/or the operating system 38 and applications 40 is provided directly, for example, via a browser 48 or similar application. In this implementation, no other special purpose software is required at programming terminal 46 . In effect, server 42 residing on HMI 26 may provide access to device elements in library 44 . By storing the device elements in the library 44 directly on the HMI 26, the risk of version conflicts etc. is eliminated or reduced. therefore. HMI 26 can be connected directly to programming terminal 46 , or HMI 26 can be accessed via an IP address (Internet Protocol address) assigned to HMI 26 .

Access control schemes can be used to limit the ability to change screen and device elements. For example, a password or user access status may be required to gain such access. Furthermore, in presently contemplated embodiments, programming terminal automatically recognizes HMI 26 or a terminal on which HMI 26 resides as a device coupled to programming terminal 46 (eg, like an external memory or drive). Thus, once connected to the programming terminal, the HMI 26 can simply be "recognized" as a device that can be accessed (providing the configuration screens and tools described below).

Once the device elements residing on HMI 26 are then accessible to programming terminal 46 , aspects of HMI 26 may be modified or updated directly on HMI 26 via a communication link from programming terminal 46 . For example, a user may wish to update a particular HMI graphic to provide data, such as historical data or trends related to information received from a newly installed sensor 34 . Furthermore, users may find it desirable or convenient to update HMI graphics representing such data in an offline mode (eg, without performing changes immediately). In this case, the user can link via the programming terminal 46 to the library 44 of available equipment elements and use it to modify the HMI graphics or functions in the development environment.

It should be noted that additional equipment elements may be added to library 44 . For example, if trending device elements are not resident on HMI 26 , the user may download such elements to HMI 26 from configuration library 50 resident on programming terminal 46 . Alternatively, a user may access trending device elements from accessible repository 52 via a network (eg, the Internet), either directly to HMI 26 or through programming terminal 46 . This can be particularly beneficial because new and improved equipment elements can be downloaded to the HMI 26 individually and on a regular basis, thereby eliminating the need for periodic releases of new conversion programs or HMI operating systems, or runtime or design-time In the case of environmental software, new functions are added. Development environments can be set up to link to such libraries. Furthermore, in embodiments where embedded code is used (e.g., operating system, server software, device objects, etc.), since the embedded code resides on the HMI 26, version conflicts with embedded code can be avoided and programming terminal software upgrades can be eliminated. necessity.

To track status information for one or more components of control and monitoring system 24 , components of control and monitoring system 24 may use a distributed data model representing various aspects of control and monitoring system 24 . For example, a distributed data model may enable multiple cached copies of the data model representing control and monitoring system 24 to exist within control and monitoring system 24 (e.g., in one or more of the components of control and monitoring system 24 places). As will be described in more detail below, the distributed data model can work in conjunction with incremental scripting and distributed command processing. Delta scripts may enable one or more components of the control and monitoring system 24 to determine changes in the state of the data model, generate delta scripts that contain only the changes to the data model and/or the entire data model, and provide the delta scripts to Other components of the control and monitoring system 24. Other components may consume the delta script and apply the data contained within the delta script to a cached copy of the local data model (eg, a distributed copy contained in one of the components of the control and monitoring system 24 ). Furthermore, as will be discussed in more detail below, certain components of the control and monitoring system 24 may utilize a distributed execution engine that enables distributed command processing. Such distributed command processing enables distributed components of the control and monitoring system 24 to process command execution based on events or schedules provided to the distributed components.

By using a distributed data model, distributed incremental communication (eg, via incremental scripting), and distributed command execution, the resulting control and monitoring system 24 can be more robust and flexible. For example, a distributed copy of the data model may be used to effect changes within the control and monitoring system 24 rather than depending on the centralized data model at the centralized control/monitoring device 30 . For example, HMI 26 may include a distributed copy of the data schema upon which changes are effected within HMI 26 , rather than relying on a centralized data model at control/monitoring device 30 to affect changes to HMI 26 . Additionally, HMI 26 may receive state deltas 43 (eg, via delta scripts) that are consumed by HMI 26 and that are local copies of the data model applied to the HMI by HMI 26 . Additionally, as will be described in more detail below, HMI 26 may include a local execution engine (e.g., an execution engine distributed to HMI 26) that is useful for executing commands provided to HMI 26 at HMI 26 of.

Furthermore, this functionality enables synchronized data storage to exist throughout the control and monitoring system 24 . These synchronized data stores may enable collaboration by enabling multiple users to make changes to a single data store to be synchronized with each of the other data stores. In addition, because the data store can cache a single copy of the control and monitoring system 24 data, offline modifications can be made. For example, by using data cached in one of the data stores, a user can make modifications to the control and monitoring system 24 even when the controller is unavailable. Modifications made by the user offline can be synchronized with the other data stores when the user comes back online (eg, with access to the processor). Thus, the user is able to provide changes to the control and monitoring system 24 in a more consistent and reliable manner.

For example, a user can make changes to tag definitions, metadata definitions, rename ^elements of the design, modify alarm settings, change data types, and/or modify Data logging condition. These user-submitted changes can be made into a local data store. When online, these changes can be propagated to other data stores within the control and monitoring system 24 , applying the changes throughout the system 24 . While offline, these changes may remain in the local data store, but may be synchronized once back online (eg, reconnected to the controller of the control and monitoring system 24). Through the automatic propagation of changes, redundant change entry can be avoided, thereby saving development labor. Furthermore, automatic renaming based propagation through the system 24 can reduce debugging and initialization. Furthermore, since these changes can originate throughout the system, it allows for flexible workflows when different users develop controllers and HMIs.

As described above, by distributing the data model, propagating changes to the distributed data model via delta scripts, and distributing command execution, the control and monitoring system 24 can be greatly improved over traditional control and monitoring systems. For example, clients of control and monitoring system 24 (eg, components requesting data for the data model of control and monitoring system 24 ) may be served by any of multiple copies of the data model distributed within control and monitoring system 24 . Control and monitoring system 24 may determine which replica to service a client based on one of a number of decision factors. For example, specific distributed data model replicas may be selected to serve data to clients based on performance efficiencies such as efficient network access (e.g., replicas close to the client, locally or on a network, or network access with maximum bandwidth, etc.) . Furthermore, processing considerations can also be used as phonemes for such decisions. For example, such a robust control and monitoring system 24 may enable data to be provided to clients using load balancing techniques. In one embodiment, data may be provided to clients from components that contain distributed copies of data models that are known or may provide fewer requests than other components of the control and monitoring system 24 . In one example, the control and monitoring system 24 may include two control/monitoring devices 30 (eg, 2 automatic controllers). The control and monitoring system 24 may predict or observe that the first control/monitoring device 30 receives more requests for data than the second control/monitoring device 30 . Accordingly, the control and monitoring system 24 may determine to service clients from the second control/monitoring device 30 to avoid overutilizing the first control/monitoring device 30 . Thus, control and monitoring system 24 may avoid flooding of control/monitoring device 30 by balancing requests based on the load of components within control and monitoring system 24 . In some embodiments, this may include feeding requests from a single component up to a threshold number or amount of data requested and moving to a flood source when the threshold is reached. In some embodiments, this may include substantially evenly distributing the load of requests or the amount of data when serving the data.

These capabilities may also benefit data redundancy in the control and monitoring system 24, in addition to providing distributed data models, delta scripts, and load balancing capabilities of the execution engines. For example, one or more components within control and monitoring system 24 may monitor one or more distributed copies of the data model. Once unstable replicas (eg, replicas that do not accurately represent the distributed model) are detected, unstable replicas can be replaced by stable replicas (eg, replicas that accurately represent the distributed model). A stable copy may be obtained from any of the other copies of the data model distributed in the control and monitoring system 24 determined to have a copy that accurately represents the data model.

In some embodiments, components of the control and monitoring system 24 may have access to a redundant pool that provides a valid copy of the distributed data model or a component of the control and monitoring system 24 that stores a valid copy of the distributed data model. Provide pointers. For example, when a client component requests data in the data model, it may have access to a redundant pool that communicates where the data can be obtained. As noted above, one or more components of the control and monitoring system 24 may monitor replicas of the data model to determine unstable replicas. When one or more unstable copies are detected, components of control and monitoring system 24 may remove pointers to the unstable copies or components of control and monitoring system 24 that store unstable copies. Therefore, unstable replicas are not accessible via the redundancy pool.

In some embodiments, as described above, after removing an unstable copy (or a component storing an unstable copy) from a redundancy pool, components of the control and monitoring system 24 may replace the unstable copy with a stable version. copy. After the unstable copy is replaced, components of the control and monitoring system 24 may rejoin the replacement stable version (or store the replacement stable version) back into the redundancy pool for future use.

To better illustrate the relationship between the design-time environment and the run-time environment, FIG. 3 provides a high-level flowchart representing the interaction between HMI 26 and programming terminal 46 . More details on this process are provided below. Typically, the platform for the HMI 26 and programming terminal 46 will include operating system or executive software 38, application software 40, and any communications software, microprocessors, network interfaces, input/output hardware, generic software libraries, database management , user interface software, etc. (not specifically shown in FIG. 3 ). In the illustrated embodiment, the design-time platform and the runtime platform interact within HMI 26 . The design-time platform provides a view for use as a design-time environment 16 to a desktop personal computer (e.g. running a suitable operating system 38 such as Windows XP, Windows Vista or Linux) and the runtime platform provides access via an operating system (e.g. Windows CE, Linux ) to work with the design-time platform. The design-time platform provides dynamic server content 54, while the runtime platform displays views on the HMI 26 itself (if a display is provided on the HMI 26). The design-time environment 16 is displayed in a browser 48 (eg, a Web browser or other general-purpose browser).

FIG. 3 shows at a very high level how design-time environment 16 interacts with operating system 38 , applications 40 and runtime environment 14 . Arrow 56 represents dynamic content exchange between HMI 26 and programming terminal 46 . Typically, interaction with the design-time environment 16 is the task of a designer 58 who initially configures HMI screens or visualizations, device elements and their functions and interactions, or who reconfigures such software. Runtime environment 14 typically interacts with design-time environment 16 directly on HMI 26 by operator 60 . It should be noted that when the design-time environment 16 has specific needs, in this embodiment this is largely dependent on the operating system 38 , applications 40 and runtime environment 14 . Design-time environment 16 and runtime environment 14 may utilize certain baseline technologies (eg, DHTML, HTML, HTTP, Dynamic Server Content, JavaScript, Web browsers) to operate in the design-time and runtime platforms, respectively. Although in the illustrated embodiment, runtime environment 14 and design-time environment 16 belong to separate platforms, in some embodiments, runtime environment 14 and design-time environment 16 may belong to the same platform. For example, a design-time platform and a runtime platform can be configured or considered as a single platform.

In one embodiment of the invention, a design-time Web implementation is utilized. As documented by Dynamic Server Content 54 in FIG. 3 and described below, the design-time Web implementation provides the ability to run on a design-time platform by using a Web browser (e.g., 48) with DHTML support from the HMI. The speed and flexibility of the software. DHTML is used for dynamic manipulation of Web content in a design-time environment 16 . Additionally, dynamic server content 54 is used in the HMI to bring dynamic web content to the design-time environment 16 . This dynamic client-server environment enables web browsers to emulate applications running on design-time platforms without requiring software compiled for processing.

FIG. 4 is a diagram illustrating one or more device elements in a design-time environment according to an embodiment of the present technology. The diagram includes interactions shown through the relationship between display 100 (eg, a screen for browser display), property editor 102 , and HMI 26 .

The design-time environment represented by configuration screen or display 100 includes static content 104 and dynamic content. Dynamic content includes images corresponding to any displayed or represented equipment elements 106 (eg, virtual on/off buttons, gauges). In one embodiment of the present technology, the image is specified by an image tag in HTML and is part of a JPEG file created by the HMI as described below. Static content 104 can be created by an Active Server Pages (ASP) server, or it can pre-exist in an HTML file. It should be noted that in some embodiments only designated designers are able to edit static content 104 .

The design-time environment represented by configuration screen or display 100 includes static content 104 and dynamic content. Dynamic content includes images corresponding to any displayed or represented equipment elements 106 (eg, virtual on/off buttons, gauges). In one embodiment of the present technology, the image is specified by an image tag in HTML and is part of a JPEG file created by the HMI as described below. Static content 104 can be created by an ASP server, or it can pre-exist in an HTML file. It should be noted that in some embodiments only designated designers are able to edit static content 104 .

In the representation of FIG. 4 , device element representation 106 is contained within view container 108 . As understood by those skilled in the art, a container generally defines a portion of a processing space that is opened and available to a particular device element. Accordingly, container 108 may correspond to a first view container that includes only elements viewable within the current screen. As discussed above, many such screens may be provided in the HMI. Other screens such as alternative control or interface screens may be provided in other view containers such as container 110 . Generally, in order to speed up the operation of the HMI (e.g., changing between screen views), these view containers are predefined and linked to each other by defining the individual equipment elements associated with or within which the representation of the equipment element is set. associated. The global container 112 may be defined to include all device elements required by the various view containers as well as other elements not represented in any view container. As shown in FIG. 4, therefore, the view container 108 includes a virtual button 106 that performs a "jog" function and is displayed by the representation in the first screen. The new container 110 includes several components such as a "Start" button 114, a "Stop" button 116, a virtual gauge 118, a digital readout 120, and the like. The global container 112 may then include all of these device elements for the various view containers, as well as any device elements 122 that are required for the operation of visible devices but are not themselves visible. These equipment elements can include elements that perform calculations, trending, communication, and many other functions.

FIG. 4 also shows attribute editor 102 in which a user can access various attributes of element 106 . As discussed above, element 106 may also include links and text associated with element 106 , which may also be configured by a user through an editor similar to attribute editor 102 .

In one embodiment, property editor 102 may communicate with HMI 26 via a query string residing in HMI 26 from a browser (e.g., browser 48 of FIG. 2 ) to server 96 (e.g., an HTTP server). interact. Server 96 cooperates with ASP server 98, which includes a module-based interconnect mechanism 12, such as a dynamic link library (DLL), to receive and respond to queries. DLLs allow executable routines to be stored as separate files that can be loaded when needed or referenced by the program. In the above example, when a call is received, the page is reloaded by the ASP server 98 and the initial parsing of the query string results in the evaluation of the move command. The server-side script then accesses the equipment element 18 represented by the image 106 to update its location attribute. The new attribute information is then updated on the page and the page is passed to the browser 48 .

communicate state changes

Now that the benefits of using a distributed data model with distributed state changes via incremental scripting and distributed command execution have been discussed, distributed state change notification is discussed in more detail below. As discussed above, FIG. 2 is a diagrammatic representation of an exemplary control and monitoring system 24 adapted to provide component status information using incremental scripts in accordance with embodiments of the present technology. As shown, control and monitoring system 24 may include one or more human-machine interfaces (HMIs) 26 and one or more control/monitoring devices 30 adapted to interface with components of process 28 . Control/monitoring device 30 may include one or more processors and data storage devices that facilitate performing tasks on control and monitoring system 24 (eg, process control, remote equipment monitoring, data acquisition, etc.). Additionally, programming terminal 46 may enable one or more users to configure properties of HMI 26 and/or control/monitoring device 30 .

In a control environment, the state of various objects of the control and monitoring system 24 (e.g., control programs, tags, module configurations, and HMI screens) can be stored in various components of the control and monitoring system 24 (e.g., programming terminals 46, control/ monitoring device 30, I/O module, and/or HMI terminal 26) in memory (eg, hard drive, read-only memory, and/or random access memory). Each of the components of the control and monitoring system 24 may operate independently in a loosely coupled, asynchronous fashion. Furthermore, components can be implemented in different programming technologies (eg, C++, Java, and/or C#). As changes are made to the state information of control environment objects, it may be necessary to synchronize this state information with state information residing on other components so that the components have a continuous understanding of the state of objects within the control and monitoring system 24 . According to this embodiment, in order to keep informed state information, automatic components that store state information may receive data called state deltas 43 (eg, state elements that have changed), and not receive state State element in the stored state information on each component of the information. For example, status delta 43 may include any data that has changed due to actions within control and monitoring system 24 . By providing state increments 43 instead of unchanged state information, an increase in efficiency can be observed. For example, in a conventional control and monitoring system 24 with 100 status elements, each of the 100 status elements may be provided to each component that stores status information for that object. By providing only status increments 43, components of the control and monitoring system 24 can only transmit data for elements that have changed. Therefore, if only one status element out of 100 status elements changes, the other 99 elements will not be transmitted, thereby reducing network traffic relative to conventional systems. Furthermore, providing only the state delta 43 may reduce the likelihood of inadvertently overwriting state change information generated elsewhere within the control and monitoring system 24 . For example, in the case of 100 state elements mentioned above, if all 100 state elements are transmitted to other parts, 99 unchanged elements may cause an override of a change made elsewhere to one of these 99 elements. Write. By providing only unchanged elements (eg, state delta 43), the above 99 unchanged elements can be unaffected by one element that has changed and communicates with other components.

Now that the use of state increments 24 has been discussed, FIG. 5 shows a control and monitoring system 24 including a persistent object model for communicating state changes between components of the control and monitoring system 24 . For example, the aforementioned components may include control/monitoring device 30 (eg, PLC), programming terminal providing project file 150 and components of control/monitoring device 30 and client 156 such as hosting persistent object model 152 and collaboration session 154 . As previously discussed, control/monitoring device 30 may be adapted to interface with components of process 28 (FIG. 1). Project file 150 may be a computer file output representing various attributes defined by control and monitoring system 24 and stored in memory (eg, hard drive) of programming terminal 46 (FIG. 1). The persistent object model 152 may be a representation of changes to state data in the control and monitoring system 24 in a persistent manner (e.g., by storing the state data in a non-volatile storage medium such as a hard drive). A computer model that keeps track of state data for one or more components. The persistent object model 152 can be used as a change communication authenticator such that all committed changes to the state of an object are stored and communicated through the persistent object model 152 . As discussed in more detail below, collaboration session 154 may be an interactive information exchange interface between components of control and monitoring system 24 that provides an environment for pending changes to be made (e.g., after a user chooses to commit some changes, These changes may simply be communicated to other components of the control and monitoring system 24). Client 156 may be any other component of control and monitoring system 24 that maintains state information of objects in memory, eg, a component that provides a representational view of an object.

In the illustrated embodiment, the components shown (control/monitoring device 30 providing collaboration session data 154, programming terminal providing updated project file 150, providing persistent object model 152 and control of collaboration session 154 Each of the /monitoring device 30, and the client 156) includes a data container 158 (eg, storage reserved for data). Data container 158 includes state elements 160 that define the state of one or more objects of control and monitoring system 24 . State elements 160 can be defined in a data-driven manner so that different technologies (eg, C++, Java, and/or C#) can use the data represented by state elements 160 . As previously discussed, it may be desirable to efficiently synchronize the state information stored in the various components of the control and monitoring system 24 . As one or more of the state elements 160 stored in the data container 158 changes, it may be necessary to synchronize the data elements 160 stored in other components.

As discussed above, the persistent object model 152 may be the designated authenticator when applying state changes between various components in the control and monitoring system 24 . Persistent object model 152 may include what is referred to as a golden copy 162 of state information for one or more objects in its data container 158 (as shown by cross-hatching). Golden copy 162 includes a copy of the status information that control and monitoring system 24 always considers to be correct. In other words, golden copy 162 is an authenticated copy of state information. Each piece of state information has its own golden copy 162, which may or may not reside in the control and monitoring system 24 (eg, on the same computer system) with other golden copies 162 of state information. If one or more state element changes are committed, the changed elements are provided to golden copy 162 in the form of delta scripts 170 which are updated based on the state element changes. The state element changes are then provided from the golden copy to other components within the control and monitoring system 24 via delta script 170 .

To effectuate state changes within data container 158, components of control and monitoring system 24 may play different roles. These roles may include change instrument 164 , change arbitrator 166 and audience 168 . A change instrument 164 (eg, a client providing a modified project file 150 through an editor in the current embodiment) sends a change request to a change arbiter 166 . The change instrument can verify the success of the change by receiving asynchronous change responses and/or error responses on the change request. A change arbitrator 166 (eg, the server hosting the persistent object model 42 ) queues incoming changes, processes the changes by executing the requested changes, makes other side-effect changes or discards the changes based on the request. Change arbitrator 166 may provide a change response to change instrumentation 164, post change notifications to audience 168 (e.g., clients 156 and/or control/monitoring devices 30 involved in collaboration session 154) when changes occur, and/or Or write changes 162 to the golden copy. Audiences 168 receive change notifications and use them to update their local copies of state information stored in their data containers 158 .

As previously discussed, the programming techniques used in the various components of the control and monitoring system 24 may not be uniform. For example, some components may use C++ while other components may use C# or Java. Thus, the state delta 43 of FIG. 2 set between the change instrument 164, the change arbiter 166, and the audience 168 can be set in a data-driven delta script 170 that is not dependent on a particular technology. Delta script 170 may describe object state changes in the form of create, update and/or delete (CRUD) data. Creation data may include some or all data that facilitates creation of the object (eg, for a rectangle, the rectangle's spatial position, width, and height). Default values can be used for any data not provided to create the request. The update data may include data that has been updated in the object (eg, for a rectangular shape with an updated spatial location, the update data may only include the new spatial location). The deletion data may identify (eg, describe its identifier) object state data that has been removed (eg, for a rectangle that has been removed, the deletion data may include the name of the rectangle to be deleted). In one example, if using the following C# pseudocode produces a change:

A data-driven incremental script might look like the following pseudo-XML example:

In alternative embodiments, it may not be necessary to include CreatorID or ParentID. However, these IDs are provided in the current embodiment to account for additional data that may be included in the change (eg, the identification of the entity making the change and/or the parent object under which the current object was created). Because data-driven incremental script 170 is agnostic or independent of a particular programming technique, incremental script 170 can be consumed by any other component of control and monitoring system 24 regardless of the programming technique used.

As shown in the examples above, in some embodiments delta script 170 may include more than one change. Thus, the delta script 170 provides a way to handle the entire set of changes with an all or nothing approach. For example, as shown above, included within the delta script are two sets of creation data for visualization on the display, one set for creating rectangular images and one set for creating circular images. If the creation of the circular image produces errors, the rectangular variation can be canceled out, which results in an all-or-nothing rule.

Delta script 170 may also include header information such as a change revision number, a timestamp when the change was committed, an identifier of the user who made the change, and/or a unique revision identifier, among others. The user's identifier may help in authenticating the source of the change. In addition, the delta script 170 includes an identifier of the object to which the change applies, the state element 160 that has changed, and the change value of the state element 160 . Since each of the state elements 160 will be the first consumer introduced into the delta script 170, the create data set may include the full state of the object (eg, all state elements 160).

Turning now to FIG. 6 , a progression 190 of status change communication between change instrument 164 , change arbitrator 166 , and audience members 168 is shown. In the current embodiment, audience 168 (eg, client 156 ) provides subscription request 192 to collaboration session 154 . Subscription request 192 may include a revision number for revision 194 of state information stored in audience member 168 . If the revision on the collaboration session 154 does not match the revision number sent in the subscription request 192, the collaboration session will issue a direct notification of the update required by the set of delta scripts 170 to bring the audience members 168 to the files stored in the collaboration session. Amendments in 154. For example, in panel A, client 156 issues subscription request 192 including revision 5. Collaboration session 154 is on revision 8, so delta scripts 170 for revisions 6, 7, and 8 are sent to client 156 . Client 156 can apply delta script 170 to its state, so as shown in panel B, the client updates to revision 8.

If change instrument 164 (eg, client or server providing updated program file 150) updates golden copy 162, collaboration session 154 and subscribing audience members (eg, client 156) should be notified of the change. As shown in panel B, when golden copy 162 is updated from revision 8 to revision 9 (e.g., via a change scheduled by sending an updated project file 150 from change instrument 164), change arbitrator 166 contributes to the collaboration session 154 provides a delta script 170 for revision 9. As shown in panel C, the collaboration session 154 applies the delta script 170 for revision 9 and is therefore updated to revision 9 . Delta script 170 is then disseminated to audience members 168 (eg, clients 156). Client 156 applies delta script 170 and updates to revision 9.

In some scenarios, audience members may require more delta scripts 170 than are stored in collaboration session 154 . For example, if the subscription request 192 was to be sent when the client 156 was at revision 2 and the collaboration session 154 only had delta scripts 170 for revisions 5 through 8, the client 156 would still need the delta scripts 170 for revisions 3 and 4 . If collaboration session 154 is missing the necessary delta script 170, it may request golden copy 162 to provide the required delta script 170. In some embodiments, golden copy 162 stores all delta scripts for each revision of an object's state information. However, in other embodiments, only a limited number of scripts will be stored (eg, the last 5, 10, 50, or 100 revisions of delta script 170). If the golden copy 162 can provide the necessary scripts, they can be propagated to the client 156 through the collaboration session 154 . However, if the necessary delta script fails to propagate, the audience member 168 may be notified (e.g., via an exception message) and/or reloaded with the entire set of elements associated with the current state information such that the audience member 168 is the latest. Furthermore, if an audience member 168 encounters an error applying one or more of the delta scripts 170, the audience member 168 is reloaded with the entire set of elements associated with the current state information. Also, in some cases, if a large number of delta scripts 170 will be required to update audience members 168, it may be more efficient or desirable to completely reload all state information than to apply state deltas. In some embodiments, if the number of delta scripts that need to be applied exceeds a maximum delta script threshold, audience members 168 are reloaded with the entire set of elements associated with current state information. The maximum delta script threshold may be customized based on a perceived number of delta scripts that would tend to make a full reload of state information more efficient than loading incremental delta scripts.

In some embodiments, control and monitoring system 24 may also include reverse increments. A reverse delta describes the changes necessary to roll back from the current revision to the previous revision. If applied, the reverse delta script rolls back the object's state information by one revision. This reverse delta script is applied to a data container (eg, data container 158 of FIG. 5 ) that includes the same number of revision numbers as the reverse delta script. The reverse delta script can be helpful in creating a "cancel" functionality for changes committed in the control and monitoring system 24, and can also be used to retract pending changes that have not been committed, as created in the collaboration session 154 before committing the changes of those changes.

Fig. 7 shows a cancellation scheme according to this embodiment. In panel A, an editing session of object 210 for revision 211 is initiated by a first client. The first client makes edits within the session to bring object 210 to pending revision 214 in panel B. The first client disconnects, and when disconnected, the second client undoes revisions 214 and 213, as shown in panel C. Then, the second client can make new changes 213 and 214 .

To prevent a first client from detecting that it is up-to-date based only on the revision number, each revision may be assigned an identifier such that the combination of the revision number and the identifier creates a unique identifier for that revision number. If a reverse delta script is applied to undo the changes, the canceled delta script can be preserved so that a "redo" function can be implemented. If a change is redone, the previous identifier for that revision is reused, since the delta script is reintroducing the same change that had previously been removed. However, if a new revision is made, a new revision identifier is used so that no component of the control and monitoring system 24 confuses the canceled revision with a new revision with the same number.

For example, each of the revisions in Figure 7 has an associated identifier. Revision 211 has identifier M, revision 212 has identifier R, original revision 213 has identifier T, and original revision 214 has identifier X. If revisions 214 and 213 are canceled, they are removed from pending revisions. If they are "cancelled", add them back to pending changes, regenerating revisions with the same identifiers T and X. However, in the current example, new changes are made, creating new revisions 213 and 214 with identifiers S and Y, respectively. Because they are completely new revisions, the identifiers S and Y are used to identify the above revisions. Once the first client comes back online and resubscribes for updates, there will be no doubt that it is not current because the final revision is 214-X and the current revision is 214-Y. In some embodiments, the first client may be updated by tracking the revision number and designator to find the edit path and updating the revision information accordingly. In another embodiment, if inconsistent revision number identifiers are found, the component is reloaded with the entire set of state information (eg, all state elements 160).

Changes may be made to the golden copy (eg, golden copy 162 in FIG. 6 ) outside of a collaboration session (eg, collaboration session 154 in FIG. 6 ) that is undergoing pending editing. FIG. 8 illustrates a scenario where pending edits are currently being made in collaboration session 154 while external changes are being made to golden copy 162 . As shown, a first pending change Δ1 is applied to revision 221-B of object 210 to generate revision 222-J. Additionally, the second pending change Δ2 and the third pending change Δ3 are used to generate revision 223-N and revision 224-D, respectively. Before committing the pending changes Δ1, Δ2 and Δ3, the external change Δ1' is applied by another component of the control and monitoring system 24 to the golden copy 162 currently at revision 221-B. If collaboration session 154 receives notification that a new revision 222 exists, collaboration session 154 retracts pending changes Δ3, Δ2, and Δ1 (to save them as future pending forward deltas). The collaboration session then applies the delta script for revision 222-H, and then applies pending changes Δ1, Δ2, and Δ3 that create revisions 223-R, 224-C, and 225-X, respectively. In some cases, pending changes Δ1, Δ2, and Δ3 may be amended to apply them after revision 222-H. In some embodiments, audience members who made pending changes in collaboration session 154 may be notified that pending changes are being applied to golden copy 162 overriding recent external changes.

In some cases, a user may desire to abort changes made in collaboration session 154 . FIG. 9 illustrates a process for pending changes in a collaborative session 154 for aborting. As shown in the current example, the user creates pending change Δ1 from revision 221-B, generating revision 222-J. Create pending change Δ2 from revision 222-J, resulting in revision 223-N. Additionally, pending change Δ3 is created from state 223-N, generating revision 224-D. The user may determine that changes are not necessary and/or desired and may cancel the changes (eg, by selecting the cancel button in programming terminal 46 of FIG. 2 ). To revert pending changes, components with pending state changes can apply reverse deltas for each pending change (eg, Δ3, Δ2, and Δ1) to preserve the original non-pending revision (eg, revision 221-B). Alternatively, components can simply reload all state information from golden copy 162 because golden copy 162 has the latest non-pending revision stored (eg, a revision that does not include pending changes). Thus, as shown in FIG. 9 , the collaboration session is left at revision 221 -B at time T1 , by back deltaing or reloading from golden copy 162 . Accordingly, a collaboration session may be used to undertake additional edits (eg, Δ4) from revision 221-B, generating a new revision 222-R at time T2.

In some cases, it may be beneficial to condense multiple pending changes into a single revision, rather than creating separate revisions for each of the pending changes. Figure 10 shows an example of combining some pending changes into a set of edits to generate fewer revisions. As shown, an editing session is opened at time T0. Apply pending changes to revision 221-B, resulting in revisions 222-J, 223-N, and 224-D. The pending changes may relate to changes made to common state elements (eg, each change may modify the spatial position of the rectangle on the display). For example, revision 222-J may place the rectangle in the center of the screen, revision 223-N may update the rectangle position to the upper left corner of the screen, and revision 224-D may update the position to the lower left corner of the screen. Thus, although several value changes are imposed, only an increment from the original value (e.g., Amendment 221-B) to the final value (e.g., the bottom left corner of the screen arrangement, as described in Amendment 224-D) may be required . Thus, intermediate revisions in collaboration session 154 may shrink down to a single revision on golden copy 162 . Thus, as shown at T2, pending changes Δ1, Δ2, and Δ3 are compressed and applied to revision 221-B, resulting in revision 222-R. In an embodiment where a component is configured to completely reload all state information when a conflicting identifier associated with a revision number is detected, when the component is notified that a revision 222-R is available (as shown at T3) , the component can override all state information for revision 222-R. As will be appreciated by those skilled in the art, this is just one of the forms of compression that can be used to combine deltas. The examples provided are not intended to limit compression techniques for pending changes.

Distributed command execution

Turning now to the discussion of how changes are applied within the control and monitoring system 24 once they are communicated, FIG. /output device 260 and dummy input/output (I/O) device 262) control and monitoring system 24. Intelligent I/O devices 260 may include a central processing unit (CPU) such that intelligent I/O devices 260 may execute logic based on data provided to them. Dumb I/O devices 262 may not include a CPU and thus may rely on a controller to apply logic to their inputs.

Execution engine 264 may be embedded within various components of control and monitoring system 24 capable of supporting an execution engine. In one example, an execution engine 264 is utilized to implement a component with a CPU. Execution engine 264 is capable of applying changes in control and monitoring system 24 (eg, state increment 43 ) to various components in which execution engine 264 is embedded. Execution engine 264 includes commands (eg, command script 266 ) and trigger conditions 268 . Command script 266 is executed by execution engine 264 when trigger condition 268 evaluates to true. For example, trigger condition 268 may evaluate to true if there is a change in the data value in control/monitoring device 30 (e.g., by increment script 170) and/or when the user interacts with the HMI 26. By distributing execution engines 264 throughout the various components of control and monitoring system 24, changes in control and monitoring system 24 may be handled more efficiently. For example, the processing capability of the CPU of each component may be utilized to execute the control logic required by the components of the control and monitoring system 24 . Additionally, command execution on various components of the control and monitoring system 24 may increase redundancy and/or provide a better location to execute commands than a centralized controller. For example, intelligent I/O device 260 is enabled in response to control and monitoring system 24 to execute logic specific to intelligent I/O device 260 without relying on control/monitoring device 30 .

As discussed above, some components (eg, dumb I/O devices 262 ) may not support an embedded execution engine 264 , or may support an execution engine 264 but not have an embedded execution engine 264 . These components may rely on other components (eg, control/monitoring device 30 ) to execute logic for components not embedded in execution engine 264 . For example, as shown in FIG. 11 , dumb I/O device 262 has no embedded execution engine 264 . In addition, the data is polled using conventional logic of the control/monitoring device 30 (eg, ladder logic (LL), functional block diagram (FBD), sequential function chart (SFC), etc.).

Commands (e.g., command script 266, relay ladder logic as defined by the user and/or system) may be stored on a tangible, non-volatile, computer-readable medium (e.g., hard drive, database, read-only memory, and/or random computer readable instructions (eg, objects) in memory) that are executed when a trigger condition occurs or at a scheduled time. For example, commands may be stored in data container 158 in FIG. 5 . Commands can inherit a base set of attributes and/or functionality from a command base class. Specific attributes and behaviors can be added to the base class to derive other command classes such as those for screen navigation and writing tag values, etc. In some embodiments, a command base class may include parameters, or parameter collections of parameter data name/value pairs that may be used for input and output. Additionally, the command base class may include a "done" property to indicate that the command has completed executing. The command base class can include an error attribute indicating that the command execution stopped due to an error. Additionally, the command base class may include a parent attribute that is used by the control and monitoring system 24 to determine who is responsible for storage cleanup of the command (eg, what entity should delete the command from the data container 158 after execution). The command base class can include a name attribute to identify the command. The name attribute can be used in the representation and trigger condition 268 so that the attribute of the command can trigger additional commands. The command base class may include a progress attribute to indicate the progress of the execution of the command, and may also have a timeout attribute to indicate that the execution of the command has timed out (eg, has not completed within the allotted time period). The command base class may include dispatch attributes that add the command to the appropriate thread of execution, as discussed in more detail below. Additionally, the command base class may include an execute attribute that contains the instruction to execute.

In some embodiments, commands may be compounded or put together. There are two basic forms of compounding: sequential command compounding and parallel command compounding. In sequential command composition, each command that is put together in a group is executed one at a time in the order given. One example of a useful sequential command compound could be a set of commands that 1) write to a tag to start tank filling, 2) wait for a specific tag value, and 3) change a graphics state element. The following is a pseudocode example of possible sequential command composition:

<Sequence>

<WriteTag ref="mytank"...>

<WaitFor trigger="mytank.fill==100"...>

<SetState ref="myTankDoneText" state="Done"/>

</Sequence>

In parallel command compounding, each command that is together in the compound executes at the same time. For example, the following write tag commands can be executed at the same start time:

In some embodiments, command composition may include a combination of sequential composition and parallel composition. E.g:

Turning now to FIG. 12, an embodiment of a frame loop 300 executed by an execution engine is provided. Frame loop 300 is a set of computer readable instructions executed with respect to a controlled period of time (eg, 30 times per second). The purpose of frame loop 300 is to react to data changes (eg, state increment 43 ) provided to execution engine 264 of FIG. 11 . As shown, frame loop 300 may evaluate the representation at block 302 . For example, data acquisition thread 303 may access status data of control and monitoring system 24 by providing presentation data (eg, the value of a data object) through data acquisition thread 303 . The frame loop evaluates a trigger condition (eg, trigger condition 268 in FIG. 11 ) at block 304 based on the evaluated expression. If any one of trigger conditions 268 evaluates to true based on the evaluated expressions, the command (eg, command script 266 in FIG. 11 ) associated with trigger condition 268 may be scheduled or executed. As discussed in more detail below, with respect to FIG. 13, certain commands may be executed within frame loop 300, and other commands may be executed in other threads or thread pools (e.g., user input thread 305 and thread pool 307). Scheduling and execution. Frame commands or commands scheduled to run in the frame cycle 300 may be executed at block 306 . Next, any transition updates (eg, computer readable instructions on how to change from one value to another) are performed at block 308 . One example of a transition update may include a graphical animation specifying a state change, eg, an animated arrow showing flow for an open valve, or an animated arrow fading out for the most recent state change of a graphical representation. Frame loop 300 may then provide the changes applied by the executed commands (eg, provide updated screen images and/or new data values).

As discussed above, frame loop 300 may run with respect to a controlled period of time (eg, 30 times per second). In some embodiments, frame cycle 300 execution may be adjusted by skipping a portion of frame cycle 300 at a given time interval. For example, assuming that the frame loop 300 runs 30 times per second, the frame loop 300 can be designed to run expression evaluation every third frame (block 302), and the trigger can be performed at every third frame starting from the second frame. is evaluated (block 304), and a transition update may be provided at every third frame beginning with the third frame (block 308). This provisioning (block 310 ) may be performed continuously at each frame, or may run optimally only when changes occur. Thus, each of the blocks can still be executed sequentially, but throttled to execute less frequently (eg, 1/3 frequency or 10 frames per second).

Furthermore, the frame rate may be modified based on the hardware on which execution engine 264 is running. For example, in some embodiments, if utilizing a less capable processor such as a The frame loop can run at 12 frames per second with an Atom-based system, 30 frames per second with an Atom-based system, and 60 frames per second with a desktop computer , while the frame loop can run at 24 frames per second if using a browser-based system. Additionally, transition options may allow for fewer transitions (eg, 1 every 6 frames) and/or may allow transitions to be provided less frequently (eg, not every frame) depending on the platform being used. Execution engine 264 may also be adapted to adjust frame loop 300 during runtime based on the determined execution times of various phases of frame loop 300 . For example, expression-heavy screens may require more expression evaluation time, and transition-heavy screens may require more transition processing/execution time.

Turning now to a discussion of how commands are scheduled for execution, FIG. 13 shows a process 320 for scheduling commands, according to an embodiment. When the trigger condition 268 is evaluated to be true at block 322, the scheduling process 320 begins. As previously discussed, there may be one or more commands associated with the trigger condition 268 . Depending on the type of command associated with trigger condition 268, process 320 may take one of two paths. The command can be either frame command 324 or thread command 326 . Frame commands 324 affect data on the main frame cycle 300 . Frame commands 324 may be added to frame command list 326 for execution on main frame cycle 300 . Frame commands 324 may then be executed on the main frame cycle 300 (block 306 in FIG. 12). Typically, these commands change data requiring a re-supply of the data. Accordingly, these commands may be executed prior to provisioning (block 310 in FIG. 12).

The thread command 326 is a command that does not access data in the memory space executed by the frame loop 300 . These commands can be freely scheduled on a different thread than the frame loop 300 . Thus, if trigger condition 268 evaluates to true for thread command 326 , the thread command is scheduled to run in thread pool 307 . By utilizing the thread pool 307 resources can be utilized more efficiently. For example, by keeping thread commands 326 off the frame loop 300 thread, the frame loop 300 is free to execute more important commands and/or commands that must run on the frame loop 300 .

Linkable plugin architecture

Now that transformation communication and command execution within the control and monitoring system 24 has been discussed, data transformation through linkable plug-in functions is discussed next. As discussed above, control and monitoring system 24 may be a data-driven system with various types of resources that may be communicated between components of system 24 . A resource type may be a data classification that identifies what a resource is. Examples of these resource types may be tags, object data types, visualization screens, or any other user-definable object in system 24 . These resources can inherit functionality from each other, creating a highly dynamic type system. In other words, multiple resource types with different levels of granularity can exist within the system.

From time to time it may be desirable to make modifications to the components of the control and monitoring system 24 . For example, the design of control and monitoring system 24 and/or the manufacturer or user of the control software may desire to convert one type of data (or events associated with that data) into another type of data or events. These modifications could be added to the underlying machine-readable instructions defining the control and monitoring system 24, however, these modifications will likely require recompilation of the machine-readable instructions. Thus, components of the control and monitoring system 24 may enable the generation of plug-ins that can handle various resource types in the system 24 . A plug-in may be machine-readable code that is separate from the machine-readable code of the application and enables customization or augmentation of the application's functionality. Figure 14 provides a schematic diagram of one such system according to the present embodiment.

Similar to FIG. 1, the system 350 of FIG. 14 includes a controller 30, which represents a control and/or monitoring device. In operation, controller 30 monitors and controls process 28 via sensors 34 and actuators 36 . Additionally, system 350 includes HMI 26 , which includes services 352 for enabling human monitoring and/or control of various processes within system 350 . Programming terminal 46 in system 350 may enable one or more users to configure properties of HMI 26 and/or controller 30 .

As discussed above, there are many situations in which it may be desirable to add additional functionality to system 350 . For example, a user of system 350 may wish to enable customized machine-implemented instructions that are not available in HMI 26 and/or programming terminal 46 . Additionally, manufacturers of HMI 26 and/or programming terminal 46 may wish to implement new features without recreating the entire set of machine-readable instructions that define these components of system 350 . Thus, components (e.g., HMI 26 and/or programming terminal 46) may include machine-readable instructions for processing plug-ins, which may be defined as machine-readable code instructions other than instructions for HMI 26 and/or programming terminal 46. part. These plugins make it possible to modify the functionality of components without restarting the component.

As shown in FIG. 14, HMI 26 and programming terminal 46 are equipped with plug-in management systems 354 and 356, respectively. These plug-in management systems 354 and 356 may enable HMI 26 and programming terminal 46 to register plug-ins 358 and 360, respectively. By registering plug-ins 358 and 360, HMI 26 and programming terminal 46 are aware of and implement plug-in functionality. For example, plug-in 358 may include external security logic to be used in HMI 26 . A user or the manufacturer of HMI 26 may create plug-ins 358 and register plug-ins 358 with HMI 26 through plug-in management system 354 .

When registered with HMI 26 and/or programming terminal 46, plug-ins 358 and 360 can access services 352 and 355 of the components they are registered with. For example, HMI plug-in 358 can access services 352 of HMI 26 through services interface 364 . The programming terminal plug-in 360 can access the services 355 of the programming terminal 46 through the service interface 366 . In one embodiment, interfaces 364 and 366 may be application programming interfaces (APIs) that may receive interactive instructions from plug-ins 358 and 360 .

As discussed above, resources 162 may be communicated between components of system 350 . Resource 162 may be an object created as a polymorphic chain. Polymorphism relates to the ability of objects to have a common interface (eg, that of a function) even though they are of different types. Additionally, polymorphic chains can mean that different types of resources derive from each other. In a simple example, resources 162 may appear in system 350 having the shape, rectangle, and square types. A rectangle type can be derived from a shape type, and a square type can be derived from a rectangle type. Furthermore, these resources 162 may be defined by a generic object model or a model that does not distinguish recipients from other request parameters. Because these resource types are defined by a common object model, data access and transformation of resources 162 can be generalized without distinguishing transformation recipients from other parameters associated with resources 162 . Thus, plug-in management systems 354 and 356 can be enabled to access and use data anywhere in the polymorphic chain. For example, a plug-in that resizes the resource 162 can be used to resize rectangles and squares. This can be done through a series of plugins that can be linked together to handle specific resource types. For example, plug-in management systems 354 and/or 356 may determine an appropriate subset of linkable plug-ins to process a particular resource 162 based on a generic object model path defining resource 162 . In some embodiments, plug-ins can specify specific types of resources that they handle. Plug-in management systems 354 and/or 356 may determine the appropriate chaining (eg, the proper set and proper order of plug-ins) needed to implement the functionality.

The number of features that can be implemented through linkable plug-ins is very large. Because plug-ins are chainable, signatures can be generated for nearly all resource types that appear in system 350, regardless of where in the polymorphic chain the resource type can be found. Furthermore, plug-ins can be designed to add functionality before, during and/or after creation and/or deletion of resources. Thus, a very dynamic collection of plugins capable of handling many resource types can be achieved.

While only certain features of the invention have been shown and described herein, many modifications and changes will occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.

Claims (19)

1. a kind of automatic control system, including：

One or more parts, it includes being configured to relative with one or more individual part by following operation processing Answer can chain connector insert management system：

Determine it is multiple it is available can the processing of chain connector specific plug-in resource type；

Determine it is the multiple it is available can be in chain connector two or more it is available can chain connector appropriate chain, it is described two Or more it is available can chain connector when linked via it is different can chain connector resource type realize one can chain patch The function of part, wherein the appropriate chain include the multiple available can be in chain connector described two or more it is available can chain Connector, for realize for it is one can chain connector resource type function appropriate order；

Wherein, it is described can chain connector include it is polymorphic can chain connector, it is described it is polymorphic can chain connector include can handle it is polymorphic The shared interface for multiple resource types that chain defines；And

Wherein, the appropriate chain include it is described it is polymorphic can chain connector, so as to the multiple using being defined by the polymorphic chain A resource type in resource type.

2. automatic control system according to claim 1, wherein, one or more part includes man-machine interface.

3. automatic control system according to claim 2, wherein, one or more part includes program terminal.

4. automatic control system according to claim 1, wherein, the resource type includes control program, label, data It is at least one in type, module configuration or man-machine interface screen.

5. automatic control system according to claim 1, wherein, the insert management system is configured to weigh Can chain connector described in the case of newly starting one or more part.

6. automatic control system according to claim 1, wherein, the resource type is determined according to common object model Justice.

7. automatic control system according to claim 6, wherein, the insert management system is configured to：It is determined that it is based on The common object model handle required for the resource type can chain connector appropriate subset.

8. automatic control system according to claim 1, wherein, the insert management system is configured to can described in registration Chain connector.

9. automatic control system according to claim 1, wherein, it is described can chain connector be configured to：Connect by business Mouth conducts interviews to one or more business of one or more part.

10. automatic control system according to claim 9, wherein, the business interface includes API.

11. a kind of tangible nonvolatile machine-readable media, is stored thereon with for automatically controlling the part with monitoring system Can chain connector, it is described can chain connector include：

Machine readable code, it includes carrying out the instruction of following processing：

Described automatically control is conducted interviews with the business of the part of monitoring system；

Resource data or event are obtained from the business；

Automatically controlled and change data, generation event or progress both change data and generation event in monitoring system described； And

In the proper sequence can chain connector by described in based on the data, the event or both the data and the event With other can chain connector linked, with produce two or more can chain connector appropriate chain；

Wherein, the appropriate chain via it is different can chain connector resource type realize one can chain connector function, and The appropriate chain include described two or more it is available can chain connector, for realize for it is one can chain connector Resource type function appropriate order；

Wherein, it is described can chain connector include it is polymorphic can chain connector, it is described it is polymorphic can chain connector include can handle it is polymorphic The shared interface for multiple resource types that chain defines；And

Wherein, the appropriate chain include it is described it is polymorphic can chain connector, so as to the multiple using being defined by the polymorphic chain A resource type in resource type.

12. tangible nonvolatile machine-readable media according to claim 11, wherein, it is described can chain connector include The machine readable instructions created by the manufacturer of the part.

13. tangible nonvolatile machine-readable media according to claim 11, wherein, it is described can chain connector include The machine readable instructions created by the user of the part.

14. tangible nonvolatile machine-readable media according to claim 11, wherein, the instruction linked Including based on the common object model for defining the resource data or event the instruction that is linked.

15. tangible nonvolatile machine-readable media according to claim 11, including carry out the instruction of following processing：

Before establishing resource, just in establishing resource or after creating resource, change the data, generate the event or Carry out changing the data and generate both described events.

16. tangible nonvolatile machine-readable media according to claim 11, including carry out the instruction of following processing：

Before resource is deleted, when deleting resource or after deleting resource, change the data, generate the event or Carry out changing the data and generate both described events.

17. a kind of method for being used to modify to the function of the part of automatic supervision and control system, including：

Can chain connector to the component registration；

To it is described can chain connector resource data or event are provided；And

Based on it is described can chain connector come change the resource data or generation additional events；

Wherein, in the proper sequence will described in can chain connector with it is other can chain connector link can to produce two or more The appropriate chain and the conversion resource data or the generation additional events of chain connector, the appropriate chain can chain via difference The resource type of connector realize one can chain connector function, and the appropriate chain include described two or more can With can chain connector, for realize for it is one can chain connector resource type function appropriate order；

Wherein, it is described can chain connector include it is polymorphic can chain connector, it is described it is polymorphic can chain connector include can handle it is polymorphic The shared interface for multiple resource types that chain defines；And

Wherein, the appropriate chain include it is described it is polymorphic can chain connector, so as to the multiple using being defined by the polymorphic chain A resource type in resource type.

18. according to the method for claim 17, including determine to the following subset for handling other useful plug-in units：It is based on The common object model of the resource data or event is defined to change the resource data or the generation additional events.

19. according to the method for claim 18, including the subset of other plug-in units is linked, to cause State the subsets of other plug-in units with it is described can the combination of chain connector can handle any class in the common object model The resource data or event of type.