HK1138653B - Viewing status system for human machine interface - Google Patents

Description

Viewing state system for human-computer interface

Technical Field

The present invention relates generally to the field of networked computerized industrial control and automation systems. More particularly, the present invention relates to a Human Machine Interface (HMI) employed in association with industrial control and automation systems for facilitating the observation of the status and operation of physical equipment and related information at a supervisory level. The HMI is typically connected to a lower level control unit, such as a programmable logic controller or a Distributed Control System (DCS). Such systems are also employed to collect and manage historical information relating to such processes and their associated outputs.

Background

Industry increasingly relies on highly automated data acquisition and control systems to ensure that industrial processes operate efficiently and reliably while reducing their overall production costs. Data collection begins when many sensors measure several conditions of an industrial process and report their measurements back to a data collection and control system. Such measurements take a wide variety of forms. For example, the measurements produced by the sensor/recorder include: temperature, pressure, pH, mass/volume flow of material, count of items passing through a particular machine/process, recorded inventory of packages waiting on the marine line, number of completed cycles, etc. Complex process management and control software tends to review input data associated with an industrial process, generate status reports and operational summaries, and in many cases respond to events/operator instructions by sending commands to actuators/controllers that modify the operation of at least a portion of the industrial process. The data generated by the sensors also allows the operator to perform a number of regulatory tasks, including: adjusting the process (e.g., specifying new set points) in response to changing external conditions (including costs of raw materials), detecting inefficient/non-optimal operating conditions and/or impending equipment failure, and taking remedial action, such as bringing equipment into and out of service when needed.

Typical industrial processes are extremely complex and the amount of information received is significantly greater than anyone can digest in its original form. For example, it is not objectionable to have thousands (analog/digital) of sensors and control units (e.g., valve actuators, motors, etc.) monitoring/controlling a multi-stage process within a plant. Sensors are of various types and report on various characteristics of the process. Their output also varies in the sense of their measurements, the amount of data sent per measurement and the frequency of their measurements. As to the latter, some of these sensor/control units take one or more measurements per second for accuracy and to enable fast response. When multiplied by thousands of sensors/control units, the large number of periodic readings results in so much data flowing into the control and manufacturing information management system as to require complex data management and process visualization techniques/applications.

There are highly advanced human-machine interface/process visualization systems that are linked to several data sources, such as the sensors and controllers introduced above. Such systems collect and digest (e.g., filter) the process data described above. The digested process data, in turn, drives a visualization application that presents/renders a graphical view of the process for observation by an operator. An example of such a system is the well-known Wonderware IN-Human Machine Interface (HMI) software systems for visualizing and controlling a wide variety of industrial process and manufacturing information. IN-The HMI process visualization application includes a set of graphical views of a particular process and its physical output. Each view in turn comprises one or more graphical elements. These graphical elements are potentially "animated" in the sense that their display state changes over time in response to the associated/linked data source. For example, the view of the refining process potentially includes a tank graphical element. The tank graphic element has a visual indicator showing the liquid level in the tank and the level indicator of the graphic element rises and falls in response to a data stream supplied by the tank level sensor indicating the liquid level in the tank. For observers, animated graphical images driven by changing process data values within the data stream, where the tank level indicator is only one example, are much easier to understand than the digital stream. The graphical image provided by the HMI application is also used to depict and facilitate modification of the current process settings. For this reason, process visualization systems such as IN-TOUCH have become an essential component of supervisory process control and manufacturing information systems.

In Wonderware's ARCHESTRA HMI and supervisory control environment, real plant floor equipment is modeled by a software element commonly referred to as Automation Object. In known ARCHESTRA-based systems, Automation objects that perform specific data acquisition and process representation tasks are defined as variables, scripts, alarms and historical behavior running on the application engine. Each of these portions of the Automation Object is referred to as an "aspect". The application engine executes several aspects of the maintained Automation Object cyclically. A more recent development in ARCHESTRA involves the introduction of graphical aspects in the automation objects held in the view engine (resulting in HMI objects). The graphical aspect supports configurable animations that link to readable/writable data associated with objects maintained in a global configuration database in the system.

ARCHESTRA relies on Message Exchange to support communication between objects, both within the native computer and between nodes on the network. Message Exchange supports/provides information about data quality, read status, write status of all information it delivers. It is important that the user knows the quality/status of the information driving the graphical element. For example, an unchanged graphics state may be the result of an interrupted connection or a frozen process state.

They are individually configured/defined in terms of configurable data quality and status that was supported in the past in the graph. In other products, a fixed subset of the total data quality and status information is supported. However, application developers cannot display predefined graphs that globally change/increase data quality and status.

Disclosure of Invention

The present invention addresses the need to provide a better way to implement data quality and status representation on an HMI for industrial automation and control systems by providing a centralized definition of data quality and status behavior. The centralized definition is then applied to each graphic element linked to the data value for which the state is maintained/provided.

A first aspect of the present invention relates to defining the data quality and status behavior in a centralized manner for a set of HMI graphics. The graphics are associated with the various objects either directly (graphical aspects of the automation object) or by association with graphics provided by a graphical toolbox. The HMI application employs the graphical representation to, for example, automate a process.

Centrally configured data quality and status indicators are incorporated throughout the HMI application, and even groups of HMI applications in the system, to inform the operator of the data quality and/or status of read/written data. Through the configuration interface, administrators have access to a centralized definition of data quality and status behavior for all objects maintained in a centralized configuration database for a system (e.g., Galaxy).

It is another feature of the present invention that the centrally configured data quality and status behaviors are automatically incorporated into the graphical elements at runtime. Furthermore, in the event that the centralized definition is changed, the modification is propagated through an automatic update mechanism to all affected graphical elements, regardless of their location on the network. These new behaviors are merged without interrupting any running HMI applications that have affected the graphical element (merely redrawing the changed graphical element).

Moreover, another aspect relates to the introduction of status graphic element types. To explore a specified data variable and display an image or icon indicating the quality or status of the data, the status graphical element is defined with its primary behavior configured in the centralized behavior definition.

Drawings

While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood by reference to the following detailed description taken in conjunction with the accompanying drawings of which:

FIG. 1 is a schematic diagram depicting an exemplary supervisory process control network including a multi-layered supervisory process control and manufacturing information application including a set of personal computers having view engines and associated with human-machine interface (HMI) application objects;

FIG. 2 depicts a multi-tiered object run (host) topology for running applications on platforms and engines within an exemplary system implementing the invention;

FIG. 3 depicts an exemplary set of view engine object custom primitive attributes;

FIG. 4 depicts an exemplary set of HMI application object custom primitive attributes;

5 a-5 e depict layout and screen display groups associated with dialog boxes for configuring a centralized definition of data quality and status behavior for displayed HMI graphical elements;

FIG. 6 provides an exemplary default set of icons associated with a status graphical drawing element and their corresponding quality/status triggers.

Detailed Description

The following description is based on several embodiments of the invention and should not be taken as limiting the invention with regard to alternative embodiments that are not explicitly described herein. For example, the present invention is incorporated within a supervisory process control and manufacturing information application development and runtime environment in which various data sources (e.g., process devices and associated logic) are represented by application objects. An example of such a system is described in detail in U.S. patent APPLICATION serial No. 10/179,668, supporting systems CONTROL AND management information APPLICATION HAVING A LAYERED, architechure, filed 2002 by reset et al, 24, 2002, the entire contents of which are incorporated herein by reference, including the contents AND teachings of any references identified/incorporated therein. However, as those skilled in the art will recognize, in view of the disclosed exemplary embodiments, the present invention is potentially applicable to a variety of alternative supervisory process control and manufacturing information application development and runtime environments.

The disclosure herein is primarily directed to an infrastructure and related methods for centrally managing HMI applications (such as IN-TOUCH applications) within a supervisory process control and manufacturing information application environment potentially including a number of networked HMI nodes running separate instances of previously defined HMI applications. The present disclosure includes a description of an HMI application encapsulated within a reusable HMI application template. Subsequently, an HMI application object is instantiated (instantiated) from the HMI application template and installed on the designated networked HMI node.

A second aspect of centrally managing HMI applications disclosed herein relates to propagating changes to symbols that make up portions of graphics of an HMI application template into a set of HMI application object templates. For example, the symbol templates are defined globally outside of the HMI application. The symbol graphics are incorporated into the HMI application template by reference to a centrally managed symbol template. Defining symbol graphics for HMI applications using symbol templates facilitates propagating changes to a symbol template down to all sub-symbol templates (using the cross-reference list described above) as well as all HMI application templates that are merged by referencing changed original and derived sub-symbol templates. Such relationships and propagation paths are further described herein below with reference to fig. 5.

A third aspect of centrally managing HMI applications disclosed herein relates to maintaining and graphically presenting the state of HMI objects through the IDE126 in various views (e.g., deployment, derivation, model, etc.) of the contents in the configuration database 124. Examples of current states include: check-in/check-out, deployed/undeployed (undeploy), and changed. Each of these exemplary states enables a user to make decisions regarding the distributed instance of the HMI application.

Yet another aspect of the disclosed centralized management layout is that a user can edit existing HMI application definitions (templates) from a remotely deployed configuration tool, such as an Integrated Development Environment (IDE) facility.

Referring to FIG. 1, a schematic diagram depicts the containment/hierarchical relationship of components within an exemplary distributed/networked supervisory process control environment. In this exemplary network, a plurality of computing hardware nodes (PCs 100, 120, 130, 132, 134) each run bootstrap software that hosts subsequently loaded platform objects and development tools, referred to herein as IDE facilities. Subsequently, the platform object instance is installed on these PCs. Only one platform object can be installed on each PC. These platform objects host and provide services to subsequently installed engine objects. These engine objects, in turn, potentially serve to house HMI, device integration, and application objects that are installed later. These engine objects are distinguished by their different service/hosting capabilities and the types of objects they host. For example, the view engine hosts HMI object instances while the application engine hosts device integration objects and application objects. The above-mentioned types of objects are further described herein below.

With continued reference to FIG. 1, multiple PCs 120, 130 and 134 run an integrated design and development tool (IDE 126 a-c). The IDE126 is employed by developers to configure and deploy several components of the supervisory process control and manufacturing information system, including application objects, to designated PC nodes connected to the engineering network 119. The IDE126 is a utility (potentially including multiple components), process control and manufacturing information application, including application objects and engines, from which it is defined, created and deployed to a variety of platforms/engines, including, for example, the application server PC 100. Developers of supervisory process control and manufacturing information applications implement a wide range of application design functions via the IDE126, including: entering new objects and template types, configuring new templates from existing templates, defining new application objects and deploying application objects to a host application engine (e.g., AppEngine1 on application server PC 100). The IDE126 is also where an HMI template incorporating a previously developed HMI application is defined and the final HMI object is instantiated and deployed to a target PC having a previously installed view engine (e.g., view engines 129a and 129 b).

The copy of the IDE126 operates on a set of object templates stored in a configuration database 124 (e.g., a galaxy database), where the names of the defined object templates are maintained in a global name table 125. The global name table 125 facilitates binding location independent object names to location derived handles, facilitating routing (route) of messages between objects within the system shown in FIG. 1. The configuration database 124 stores object data for configured application components as well as any code or documents associated with the configured objects. The configuration database 124 stores both base object templates and derived templates for the various objects shown in FIG. 1 (e.g., application engines, application objects, view engines, and HMI objects). An exemplary visualization HMI application object export and instance creation mode is described herein below with reference to FIG. 5. In the exemplary embodiment, configuration database 124 includes Microsoft's SQL Server.

The contents of the configuration database 124 are accessed via a configuration database engine 122, also known as a galaxy library. The configuration database engine 122 supports remote multi-user access via IDE126 copies through graphically presentable check-in/check-out status descriptors for each defined object in the configuration database 124. Configuration database engine 122 also supports the deployment of objects and software from a centralized source to other nodes in the system.

According to an illustrative embodiment, the data quality and state behavior definitions 123 are stored within a configuration database 124. From this centralized location, the global data distribution mechanism automatically passes new versions of the definition 123 to all runtime nodes without further user intervention. The definitions 123 that specify animated graphical behaviors in response to data states are shared within the entire group of nodes and HMI applications that fall within the scope of the configuration database 124, rather than being specific to any individual node or HMI application.

In this illustrative embodiment, configuration database engine 122 is hosted by configuration database platform 127. The configuration database platform 127 is generally the same as the other platforms installed on the PC in the system. However, the configuration database platform 127 is assigned a unique state (and corresponding name) within the system as the platform associated with the single active configuration database 124. Thus, the disclosed system includes a single centrally managed configuration database. In an alternative embodiment, multiple copies of the content in database 124 (e.g., read-only or backup copies of the content in database 124) are maintained on multiple nodes in the system. In this illustrative embodiment, configuration database platform 127 and hosted configuration database engine 122 perform the following specialized functions: data/software distribution, maintaining a global name table 125, resolving (using the name table 125) globally unique location-independent reference strings to location-derived handles (for message exchange), managing secure/restricted access to several resources in a multi-user environment, version management, centralized license management, and input/output object templates and instances.

The IDE126 supports a variety of configuration operations involving the configuration database 124. For example, an engineer uses the IDE126 (via the configuration database engine 122) to enter new object templates into the configuration database 124, configure the new object templates, and deploy the objects on designated PCs on the engineering network 119. As described above, multiple copies of the IDE126 residing on disparate network nodes can access and edit object definitions, including HMI application definitions and symbol definitions potentially incorporated in HMI application definitions (templates).

In the illustrative embodiment, a plurality of HMI object instances 128a-b are deployed on a plurality of hardware nodes (PCs 130 and 132). The HMI object instances 128a-b, described further herein below with reference to FIG. 4, provide graphical views/windows that represent the current state of a process/plant or portion thereof based on information obtained via device integration and application objects from devices/controllers resident on the plant floor network 115. A single view engine accommodates multiple disparate HMI object instances for multiple configured process/plant views driven by information provided by, for example, connected field devices or PLCs (e.g., PLC 112). In the exemplary embodiment, view engines 129a-b (described herein below with reference to FIG. 3) in a multi-layered supervisory process control and manufacturing information system architecture house HMI object instances 128 a-b. Although only a single HMI object instance is shown in FIG. 1 for each view engine, each view engine is capable of hosting multiple HMI object instances simultaneously.

The hosting relationship between HMI object instances 128 and corresponding view engines 129 facilitates access to certain services supported by the view engines 129. For example, the view engine 129 supports independent updating of hosted HMI object instances 128 (automatic change propagation upon corresponding template updates). At the same time, the view engine 129 caches (on the associated network node) displays associated with the HMI object instance 128.

Turning to the application server PC100 on the engineering network 119, in this illustrative embodiment, the data sources are presented, for example, in the form of application objects 105. The application objects 105 implement a variety of functions, including representing the state of process equipment and associated application logic. The application objects implement any of a variety of monitoring/control functions while at the application level of the distributed, multi-level supervisory process control and manufacturing application architecture shown. The device integration objects 106a and 106b at the application level, which are also in the hierarchy, represent data sources on the plant floor network, such as PLCs (PLC1), smart floor devices, and associated I/O networks (e.g., PLC1 network).

The application objects and device integration objects communicate with each other both locally (within a single personal computer) and through non-local communications using objects hosted on personal computers connected to the engineering network 119.

For example, application objects 105 are identified within a global name table 125 maintained by a configuration database 124 (e.g., a Wonderware galaxy library), the contents of which are made available to developers via, for example, IDE126 a-c and HMI object instances 128a-b (which, for example, incorporate IN-TOUCH applications and their associated displays). Thus, according to an embodiment of the present invention, a dynamic graphical view IN the form of an IN-TOUCH application for a plant/process is initially created using, for example, a WINDOWMAKER utility. The entire IN-TOUCH application is then incorporated into the HMI object template, including the necessary components for use IN the multi-tier application execution environment described herein. The resulting HMI object templates are stored/maintained/managed in the configuration database 124. Subsequently, subsequent derived versions of the base template remain as child templates and retain inheritance relationships with the parent HMI object template. The original and exported templates are available for distribution via the IDE126 to the appropriate nodes on the network 119 containing the previously installed view engines (e.g., view engine 129 a).

With continued reference to FIG. 1, the application server PC100 executes a multi-layered supervisory process control and manufacturing information application, including a first portion 104. The application portion 104 includes application objects 105 and device integration objects PLC1Network 106a and PLC 1106 b. The device integration object PLC1Network 106a facilitates configuration of a data access server (e.g., OPC DAServer 116). The device integration object PLC 1106 b acts as an OPC client, accessing data locations in a buffer of the OPC DAServer 116. The data access server 116 cooperatively with the device integration objects inputs and buffers data from external process control components, such as PLCs (e.g., PLC 1112) or other field devices (not depicted) on the plant floor network 115. Application engine 107 hosts application objects 105 and device integration objects 106a and 106 b. The application engine 107 hosts the regular/event-driven execution of hosted applications and device integration objects. The foregoing components of the hierarchical containment layout on PC100 are described herein below with reference to fig. 2.

In this illustrative example, a request for data is submitted via the data access server 116 to retrieve data from the PLC 1112. The retrieved data is then used by the HMI object instances 128a and 128b to drive a graphical display representing, for example, the status of plant floor equipment. The data buffers of the data access server 116 are accessed (directly/indirectly) by various application-level objects executing on the personal computer 100, such as application objects 105, PLC1Network 106a, PLC 1106 b, and the like. Instances of application objects represent data sources and logic, including, for example, discrete devices, simulation devices, site references, events/triggers, production events, and so forth. In the exemplary embodiment, the information obtained/provided by application-level objects 105, 106a, and 106b is stored in a runtime (Historian) process information database (not shown). This data is then obtained by the HMI object instances 128a-b to drive the display state of the animated process graphic.

The data access server 116 is, for example, an OPC server. However, those skilled in the art will readily recognize the wide range of custom and standardized data formats/protocols potentially performed by the data access server 116. Furthermore, the example application-level device integration objects 106a and 106b represent the operation of the PLC network and the PLC itself by connecting to the data access server 116. However, the application-level objects (e.g., device integration and application objects) hosted by the application engine 107 comprise a virtually unlimited range of executable object classes that perform the desired supervisory control and data acquisition/integration functions in the context of supervisory process control and manufacturing information applications.

Supervisory process control and manufacturing information systems are potentially integrated with a variety of process/plant information sources via a variety of communication channels. An exemplary system comprising a multi-tier application (which includes portion 104) is communicatively coupled to PLC 1112. The PLC1, in turn, receives plant equipment status information via the plant floor network 115. In certain embodiments, PLC 112 comprises a node on an Ethernet LAN to which PC100 is connected. In other embodiments, PLC 112 is directly linked to a physical communication port on PC 100. In yet other alternative embodiments, PC100 receives data from field I/O modules that receive, for example, analog data from field devices operating in a distributed regulatory control system.

It should be noted that the system depicted in FIG. 1 and described above is merely an example of a system for supervisory process control and manufacturing information systems that includes a multi-layered hierarchical architecture. It should be further noted that FIG. 1 is presented as a logical view of the housing and/or containment interrelationships between installed components, including software and physical computing hardware. The system disclosed herein is adaptable to virtually any network topology. For example, the present invention may be applied to systems in which both a configuration utility and a supervisory process control visualization application run on a single computer system linked to a controlled process.

Turning to FIG. 2, a class diagram depicts a hierarchical containment layout of layered software, including computer-executable instructions, associated with a computer (e.g., PC 100) executing at least a portion of a supervisory process control and manufacturing information application. The computer executes an operating system 200, such as Microsoft Windows, at the lowest level of the hierarchy. Operating system 200 hosts a bootstrap object 202. The bootstrap object 202 is loaded onto the computer and activated in association with the boot process performed by the operating system 200. Hosting the platform class object 204 requires that the bootstrap object 202 be activated before the operation of the platform class object 204 is initiated. The bootstrap object 202 starts and stops the platform class object 204. The bootstrap object 202 also provides several services employed by the platform class object 204 to start and stop one or more engine objects 206 hosted by the platform class object 204.

The platform class object 204 houses one or more engine objects 206. In embodiments of the present invention, the platform class object 204 represents, for the one or more engine objects 206, a computer executing a particular operating system. The platform class objects 204 maintain a list of engine objects 206 deployed on the platform class objects 204, start and stop the engine objects 206, and restart the engine objects 206 when they crash. The platform class object 204 monitors the running state of the engine objects 206 and publishes state information to clients. The platform class object 204 includes a system management console diagnostic utility that allows diagnostic and management tasks to be performed on the computer system executing the platform class object 204. The platform class object 204 also provides several alarms to the distributed alarm subsystem.

The engine objects 206 house a set of application objects 210 that implement supervisory process control and/or manufacturing information collection functions associated with the application. The engine object 206 initiates the launching of all application objects 210. The engine objects 206 also schedule the execution of the application objects 210 with respect to each other with the help of the scheduler object 208. The engine object 206 registers the application object 210 with the scheduler object 208 for execution. Scheduler object 208 executes a number of application objects relative to other application objects according to a configuration specified by a corresponding one of engine objects 206. The engine objects 206 monitor the operation of the application objects 210 and place the failed objects in an isolated state. The engine objects 206 support checkpointing by saving/restoring changes to the runtime application by automation objects to a configuration file. The engine object 206 maintains a name binding service that binds several property references (e.g., tank1.value. pv) to the appropriate one of the application objects 210. The engine objects 206 perform similar functions with respect to the hosted device integration objects.

The engine objects 206 ultimately control how execution of associated ones of the application objects 210 will occur. However, once the engine object 206 determines the execution schedule for the application object 210, the real-time scheduling of its execution is controlled by the scheduler 208. The scheduler 208 supports an interface including methods register AutomationObject () and UregisterautomationObject (), enabling the engine object 206 to add/remove specific objects in the application object to/from the list of scheduled operations of the scheduler 208.

The application objects 210 include a wide range of objects that execute business logic that facilitates performing specific process control operations (e.g., actuating pumps, actuating valves) and/or information gathering/management functions (e.g., issuing alarms based on received field device output signal values) in an environment such as an industrial process control system. Examples of process control (automation) application objects include analog inputs, discrete devices, and PID loop objects. One type of application object 210 acts on data provided by a process control system, such as a PLC, via a device integration object (e.g., OPC DAServer 118). The function of the device integration objects, which are also hosted by the engine objects, is to provide a bridge/data path between the process control/manufacturing information source and the supervisory process control and manufacturing information application.

In the exemplary embodiment, application object 210 includes an application interface that is accessed by engine object 206 and scheduler 208. The engine objects 206 access the application object interface to initialize application objects, start application objects, and close application objects. The scheduler 208 uses this application object interface to initiate scheduled execution of the corresponding application object.

Having described the relationships between the boot program, platform, engine, and application objects in an exemplary multi-level hierarchical arrangement supervisory process control and manufacturing information application, it should be noted that similar relationships exist for the objects that make up the multi-level architecture of an HMI application (see HMI application hierarchical architecture on PC2130 in FIG. 1).

Turning to FIG. 3, an exemplary set of attributes is identified for view engine object custom primitives that add basic engine functionality to facilitate hosting a designated one of a set of available HMI object instances that have been deployed to a PC (e.g., PC 130). The contents/functionality of the basic engine primitives are described in U.S. patent application Ser. No. 10/179,668 supporting processing AND managing INFORMATION system mapping HAVING A LAYERED ARCHITECTURE, filed 2002 by Resnick et al, 24, 6.2002, the entire contents of which are incorporated herein by reference. The view engine objects support basic engine functions such as deploy, undeploy, start and close. The view engine objects also support visualization application specific functionality as described further herein below. In the illustrative embodiment, the view engine objects are specialized engine object types that host only HMI object instances — as opposed to application engines that are capable of hosting a variety of application level objects, including device integration objects and application objects.

The view engine (e.g., view engine 129a) hosts and schedules execution of designated HMI object instances. The view engine supports a set of runtime operations with respect to the hosted HMI object instances according to a currently occupied view engine runtime state. When the view engine is in the startup state, the accommodated HMI objects are: initialized from a checkpoint, started by the view engine, registered with Message Exchange (or other suitable inter-object data communication service), and executed according to commands issued by a scheduler associated with the view engine. When the view engine enters a scan on or scan off state, the hosted HMI objects are notified of the view engine's new scan state. Furthermore, when the view engine enters a shutdown state, the hosted HMI objects are shutdown by its hosting engine.

In the exemplary embodiment, the view engine manages a list of HMI object instances deployed thereto. However, the view engine is not responsible for invoking execution of scripts or reading and writing related process data associated with HMI object instances. Instead, the execution scripts and administrative data subscriptions are delegated to HMI (e.g., IN-TOUCH) applications incorporated (embedded, packaged) IN the corresponding HMI object instances. Thus, in this illustrative embodiment, an otherwise standalone HMI application that cannot execute in the disclosed multi-tier hosting architecture depicted in FIG. 1 is incorporated in an HMI wrapper object to provide such capability. Thus, a stand-alone legacy HMI (IN-TOUCH) application can be seamlessly incorporated into a system implementing the object-based hierarchical architecture described herein above with reference to FIGS. 1 and 2.

As described above, the custom primitives of the view engine include a set of attributes associated with hosting HMI application objects. The set of attributes identified in FIG. 3 (described herein below) are intended to be exemplary and modified in accordance with an alternative embodiment of the present invention.

In this illustrative embodiment, it should be noted that these objects (e.g., platforms, engines, application objects, etc.) are defined in terms of a set of data points (referred to herein as "attributes"). Each attribute, in turn, potentially includes a configuration and several runtime handles that process the object according to the currently specified value of this attribute. In this exemplary embodiment, these handles are triggered events and will have the function of custom code. The handle of the configuration setting is an event that is triggered when the attribute is set using a configuration client (such as the IDE), and the handle of the runtime setting is triggered when the value of the attribute is set by the runtime client (such as IN-TOUCH).

When a specified HMI object template is specified for deployment to a view engine, the _ CreateViewApp attribute 300 creates a new HMI object instance. A reference to this new HMI object instance is added to a list of deployed HMI objects managed by this view engine.

A _ DeleteViewApp attribute 302 removes a previously deployed HMI object from a set of HMI objects currently deployed on the view engine. The corresponding reference to the HMI object is deleted from the list of deployed HMI objects on the view engine.

A _ StartHostedObjects attribute 308 begins running all deployed HMI objects on this view engine. The initial state of these HMI objects is based on values extracted from the checkpoint persistent store.

A _ StopHostedObjects attribute 310 begins closing all HMI object instances that the view engine currently hosts.

Turning to FIG. 4, attention is directed to an exemplary set of custom primitive attributes for an HMI application object. The HMI application object implements functionality associated with providing a graphical view portion of a distributed supervisory process control and manufacturing information application. The HMI application objects executing on the hosting view engine IN the hierarchical runtime environment described above manage the check-IN/out, editing, deployment, and runtime attribute monitoring of a merged HMI (IN-TOUCH) application, which IN turn provides a dynamic graphical view of the plant/process. The graphical state of the HMI application is driven by real-time data provided by, for example, plant equipment sensors, monitors, and controllers. Such information is extracted from the plant floor network via device integration and application objects executing on an application engine (described herein above with reference to FIG. 1). The HMI objects also support reference tags (MessageExchange) on application-level objects hosted by the application server through which dynamic process data is passed to the HMI application incorporated therein.

IN this illustrative example, HMI (e.g., IN-TOUCH) applications that execute scripts and manage data subscriptions are incorporated into (embedded/packaged IN) corresponding HMI application object templates and instances. Thus, in this illustrative embodiment, some otherwise independent HMI applications that cannot execute in the disclosed multi-layered containment architecture depicted in FIG. 1 are incorporated into some HMI application wrapper object that facilitates integrating (managing, running, etc.) HMI applications within a system employing the aforementioned housed hierarchical runtime environment. Thus, a stand-alone legacy HMI (IN-TOUCH) application can be seamlessly incorporated into a system implementing the object-based hierarchical architecture described herein above with reference to FIGS. 1 and 2.

The aforementioned HMI wrapper object comprises a custom primitive that includes a set of attributes related to execution of an HMI application within a containment environment supported by the view engine. The set of attributes identified in fig. 4 (introduced herein below) are intended to be exemplary and differ according to alternative embodiments of the present invention.

The _ VisualElementReferenceList attribute 400 contains a list of all visual elements (e.g., symbols) assigned to an HMI application object.

A _ VisualElementReferenceStatusList attribute 402 specifies the current state of each symbol allocated to an HMI application object. This status can be used to convey a variety of status for symbols contained within the HMI application object including, for example, displaying when a symbol has been deleted from the HMI application object.

The DeploymentInProgress attribute 404 is set to true when HMI application files associated with an HMI application object are synchronized with the configuration database 124.

An _ UndeployNotify attribute 406 specifies whether the HMI application object can be undeployed.

A _ StartSyncronization attribute 408 is set to true to notify an HMI application object that transfer of HMI application files for an application associated with the HMI application object should begin to a node on which the HMI application object is deployed.

A _ SyncStatus attribute 410 indicates the status of an HMI application passing to a node where the associated HMI application is deployed.

The _ NameSpace attribute 412 contains information about parameter tags that are part of the HMI application associated with the HMI application object. The _ NameSpace attribute 412 is used to support browsing of HMI application tags within an attribute browser.

The _ shutdown notify attribute 414 is written just prior to closing the associated HMI application editor to ensure that the in-progress synchronization method completes before the editing process allows closing.

At the beginning of the editing session, a _ beginnamotoring attribute 416 is written when the HMI application editor starts to ensure that this HMI application object is loaded and verified correctly.

The lastmodefielded attribute 418 specifies the last time the version number of the HMI application was modified.

For example, this HMI application object exhibits a runtime behavior summarized in the description below. When executing the HMI application object (under the direction of the hosting view engine), logic incorporated in the HMI application object determines whether the incorporated HMI application within the HMI application object needs to be passed from the configuration database 124. If a transfer needs to be initiated, the transfer is initiated by the view engine at the next scan of the HMI object.

Synchronization can occur at any time after the HMI application object is launched. The HMI application object initiates synchronization of the HMI application with the source application. If the pending synchronization operation is complete, then the HMI object sets an attribute in the configuration database 124 to indicate that the transfer is complete. According to embodiments of the present invention, synchronizing applications may include updating encapsulated HMI applications or individual symbol objects incorporated within an updated HMI application within the configuration database 124. In the case of updating an HMI application, only application files within the configuration database 124 that are different from files currently on a node having an HMI application object instance incorporating the HMI application are transferred from the configuration database 124.

According to an exemplary embodiment, a global centralized management interface supported by the IDE126 is provided by way of example in FIGS. 5a-e to define such primary HMI application data quality and status behavior within an HMI application graph displaying such status information incorporated therein. The specified behavior when active will override any natively defined behavior on the deployed HMI application graph. As described above with reference to fig. 1, the quality and status behavior definitions 123 are maintained in the configuration database 124 along with other centrally managed configuration information.

Within the IDE126 configuration environment, a user (subject to check-in/out status) accesses data quality and status behavior definitions 123 from any node on the network running this IDE 126. In the exemplary embodiment, a user requests to edit data quality and state definitions 123 stored in database 124. If the definition 123 has not been checked out and the user logged into the IDE has the appropriate permissions, then access is provided via a dialog box supported by the IDE126 (see, e.g., dialog box 500 in FIG. 5 a). When the user edits definition 123, its state is "checked out". When the user closes the dialog box to edit the definition 123, the check-in copy of this definition is updated (if necessary) and the status changes to "checked-in".

In this exemplary embodiment, dialog box 500 is divided into the following main areas: enable/disable quality display 502, quality and status override options 504, configuration area 506, and command area 508. Enable/disable quality display 502 turns on/off alternate behavior stored in the checked-in version of definition 123. Quality and status override options 504 display a list of statuses/qualities and properties specified for each. Configuration area 506 contains detailed configuration options for selecting quality/status from options 504. The command area 508 presents the measures to be performed with respect to the definition of dialog access. Each of these regions is further described herein below with reference to fig. 5 b-e.

Referring primarily to FIG. 5b, the user globally enables/disables the configured alternate behavior via enable/disable button 512.

Referring to FIG. 5c, an exemplary set of configurable data qualities and status types is presented to the user for the purpose of specifying alternative animation behavior. This list is associated with information supported by the MessageExchange messaging protocol incorporated in the exemplary system. The exemplary two-dimensional grid 514 lists the supported data quality/status and the set of available display properties (columns) used to convey the quality/status conditions (e.g., text-Ts, fill-Fs, line-Ls, status primitives (icon groups) -St, and outlines-Ol). The user selects any number of available display characteristics (none, some, or all) for each listed data quality/status. In this illustrative example, icon-based "state primitive" display characteristics are specified for each listed data quality/state case. If the supported alternate display characteristics are not specified for a listed quality/status (e.g., "disqualified"), then no action will be taken with respect to the display characteristics when the associated quality/status is true. The qualities/conditions listed in the exemplary embodiment include:

1. off-grade quality-data cannot be used. Mapping to an OPC failed state.

2. Uncertain quality-data is suspect but can be used (e.g., manual replacement of data). Mapping to an OPC uncertain state.

3. Initialization quality-data is not yet available but will soon be available. Mapping to an OPC failed state with an initialized sub-state.

4. Communication error read status-request failure due to communication error with the target AutomationObject; or in the case of DeviceIntegrationObjects, a request fails due to a communication error with the target device.

5. Configuration error read status-the request fails due to an error in the configuration. In the case of DeviceIntegrationObjects, the request fails due to an unqualified entry name or other illegal configuration of the object or server.

6. Operating a false write state-a request fails due to an illegal operator action. In the case of DeviceIntegrationObjects, the request fails due to illegal operator actions. For example, when a device is currently in a mode of operation that does not allow its modification, an attempt is made to write an entry in the device, or an attempt is made to write an unacceptable value to the target device.

7. Software bug write status-request fails due to an internal software bug.

8. Secure wrongful write state-a request failure due to insufficient secure access rights.

9. Warning of write status-this only applies to several groups. An operation that completes successfully but has some sort of warning condition, such as clamping the value.

10. Pending write state-request has entered queue but not completed. This is not an error condition but indicates that an operation is in progress. The mxcategoryppending state is a transient state and persists indefinitely.

Turning to FIG. 5d, an exemplary layout is depicted for facilitating user input (for selected data qualities/states from a list in grid 514) of configurable characteristics of globally implemented animation behavior via configuration area 506. The status field 520 contains the name of the currently selected status/quality. The preview area 522 is automatically updated as the dialog box is navigated between fields. A preview of the configuration will be displayed when the replacement values are configured. When the reset to default button 524 is selected, all values are reset to the default values for the currently selected quality/state. With respect to the configuration field 526, clicking on the image selects a standard file open dialog box to be opened. The file may be one of the following standard image types: BMP, GIF, JPG (jpeg), TIF (tiff), PNG, ICO, EMF and WFM. Once an image is selected, the image is updated. Clicking on the color selection opens a standard color dialog. Once a selection is selected, the color selection is updated.

For a selected data quality/state, the following styles may be configured via configuration area 506 as runtime replacement values for each state listed in grid 514 and described herein above, respectively.

1. Text-this will apply to all text boxes, text labels, radio buttons, check boxes, edit boxes, combo boxes, and list box drawing elements with configured animations. Each of the following options can be enabled or disabled, respectively.

a. Character font

b. Colour(s)

c. Flicker (flicker)

2. Fill-this will apply to all closed drawn elements (ellipses, rectangles, rounded rectangles, polygons, buttons, closed curves, pie charts, or branches) that support fill color and have a configured animation. Each of the following options can be enabled or disabled, respectively.

a. Colour(s)

b. Flicker (flicker)

3. Line-this will apply to all drawing elements (lines, H/V lines, ellipses, rectangles, rounded rectangles, polylines, polygons, buttons, curves, closed curves, arcs, pie charts, or branches) that support line color and have a configured animation. Each of the following options can be enabled or disabled, respectively.

a. Wire type

b. Depth of depth

c. Colour(s)

d. Flicker (flicker)

4. Status graphic-this will apply to all status graphic elements (see e.g. fig. 6). Each of the following options can be enabled or disabled, respectively.

a. Line color

b. Wire type

c. Depth of line

d. Filling color

e. Image of a person

f. Transparent color of image

g. Image style

h. Image alignment

5. Outline-this is a line that will be drawn around all the graphic elements with the configured animation. The entire "profile" functionality can be disabled as a whole.

a. Color of outline

b. Contour line type

c. Depth of contour

d. Contour flicker

Referring to FIG. 5e, the command area 508 provides a standard set of "confirm" and "cancel" buttons to accept or discard the current set of changes associated with this dialog session. The preview legend button launches a new dialog box that graphically displays the appearance of the currently configured replacement.

Status graphic drawing element

Turning to FIG. 6, according to an exemplary embodiment, the state graphical drawing elements are provided in other graphical elements (e.g., lines, boxes, text boxes, etc.) on the HMI editor toolbar. However, unlike these purely graphical primitives, the state graphical drawing elements include a configurable set of icons (see, e.g., the default set of icons of FIG. 6) and animations corresponding to a variety of data quality/state conditions of the user-configured data source. The displayed icons and/or animations represent the quality/status of the data associated with the graphic to which the status graphic drawing element (e.g., icon) has been attached. In the exemplary embodiment, the status graphic drawing element appears on the sidebar along with other drawing elements of the HMI editor (e.g., WindowMaker). After selecting the status graphical drawing element tool with a mouse or other graphical interface pointing device, the user clicks and drags a rectangle (representing the location of the status graphical drawing element) on the canvas to place the status graphical drawing element. During configuration, the status graphic will display the normal graphic as a location occupant because it appears on the toolbox (since there may be no status before run-time).

Once the data quality/status graphical element has been placed on the canvas of the HMI view editor, the user accesses other available configurable features of the status graphical element by opening the animation editor. The state graphic has a predefined animation with the following two tags:

1. graph-all graphic elements linked to data on the current canvas will be displayed. The user may not select, select one or many of the elements to associate with the status graphic rendering element.

2. Expression-this tag will allow the user to directly enter an expression, which will contain a reference to the data.

Data points linked into the associated graph or explicitly called out in the expression are evaluated at runtime to determine what state and quality behavior (if any) will apply to this state graphical element.

Runtime execution of quality and state behaviors

Because the runtime viewer (e.g., WindowViewer) displays some graphics and enables quality and status behavior, any data point in the associated animation will assume a dedicated behavior that has been configured when it assumes one of the states listed above in the configurable state area. However, the following animations, when active, will cancel the graphically applicable quality and status behavior:

1. visibility animation-if this element is not currently visible because of visibility animation, then quality and status behavior will not be displayed.

2. Disable animation-if an element currently causes animation activity to be disabled, all user interaction animations will be excluded from the quality and status assessment (user input, horizontal slider, vertical slider, button, or script).

3. Animations are disabled-each animation can be configured to be disabled separately. When a particular animation type is disabled, all data points configured in the animation will not be added to the quality and status assessment.

For some graphics, another aspect of runtime execution of configured data quality and state behavior is to handle multiple active states-animations that result in conflicts. In the exemplary embodiment, the animation displayed is determined by the severity/priority of the state. For example, a rectangular graphic element is configured to have more than one data point associated with its animation. It would then be possible for this rectangular graphical element to have more than one configured state active at the same time. For any single element, only one of the configured quality and status behaviors is displayed at a time. The priority determines which of a plurality of active states applies. In the exemplary embodiment, the following priority order is used to select (high to low) from among the plurality of data states: communication errors, configuration errors, hang-ups, operational errors, software errors, security errors, warnings, failures, uncertainties, and initializations.

The order of the listed states in the replacement list area 504 determines the order of priority (with the non-conforming quality data being highest). For example, if a rectangular element has one point of unacceptable quality and another point of configuration error, both states have been configured to the rectangular element, then only configuration error behavior is actively displayed.

Moreover, some of the supported data qualities/states represent information about a certain point in time and do not persist indefinitely. These states show a minimum hold period of 20 seconds and then if this state no longer exists, this value will return to the current state. This ensures that all quality/status failures will be displayed to the user for at least 20 seconds.

Another aspect of the data quality and status behavior configuration schema described herein is the updating of configured behaviors as definitions 123 change. In the exemplary embodiment, centrally defined data quality and state behavior definitions 123 maintained in configuration database 124 are propagated to all nodes within the system (e.g., galaxy). Changes to the configured data quality and state behavior definitions 123 are automatically communicated without request from the affected workstations using the configuration database 123 and global data update functionality supported by the database engine 122. Furthermore, the definition is updated without deploying any objects or shutting down the running HMI application. The affected graph will be redrawn with updated, globally applied, alternate data quality and state behavior definitions after receiving these changes.

In view of the many possible embodiments to which the principles of this disclosed system may be applied, it should be understood that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those skilled in the art will appreciate that certain elements of the illustrated embodiments shown in software stored as computer-executable instructions on a computer-readable medium may be implemented by hardware and vice versa and that the illustrated embodiments can be modified in arrangement and detail without departing from the spirit of the invention. Accordingly, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.

Claims (18)

1. A networked computer system for facilitating centralized management of configuration and propagation of data quality and state behavior of graphical elements within a human-machine interface application that may be distributed across multiple nodes of the system, the networked computer system comprising:

a first computer node comprising a configuration database that maintains global data quality and state behavior definitions in a central configuration store;

a second computer node comprising a definition editor having a user interface, the definition editor comprising means for supporting specification of data quality and status behaviors defined in the global data quality and status behavior definition; and

wherein the first computer node further comprises means for defining a distribution mechanism for propagating changes to the global data quality and state behavior definitions to a set of workstations on a network executing a human machine interface application, wherein the human machine interface application comprises a graph associated with data having an associated quality and state.

2. The networked computer system of claim 1 further comprising status graphic element data quality and status display characteristics, wherein said definition editor comprises means for configuring status graphic elements for specified data sources.

3. The networked computer system of claim 2 wherein said status graphical element comprises a set of icons corresponding to a set of supported data qualities and statuses.

4. The networked computer system of claim 1 wherein changes to global data quality and state behavior definitions are communicated without a request from a workstation affected by said changes.

5. The networked computer system of claim 1 wherein the workstation includes means for redrawing the affected graphics in response to receiving changes to the global data quality and state behavior definitions.

6. The networked computer system of claim 1 wherein said definition editor comprises means for presenting an editor dialog graphical user interface on a workstation that includes a global enable control that, when selected, causes said global data quality and status behavior definition to replace a non-global data quality and status behavior.

7. The networked computer system of claim 1 wherein said definition editor comprises means for presenting an editor dialog graphical user interface on a workstation that includes a list of supported data quality and status types.

8. The networked computer system of claim 1 wherein said definition editor comprises means for presenting an editor dialog graphical user interface on a workstation including a configurable list of display characteristics for communicating data quality or status.

9. The networked computer system of claim 8 wherein said editor dialog graphical user interface includes a display characteristics editor box for configuring specific display characteristics from said configurable list of display characteristics.

10. A method for configuring and propagating data state behavior of graphical elements within a human-machine interface application that may be distributed across multiple nodes of a networked computer system, the method comprising:

maintaining global data quality and state behavior definitions in a central configuration store using a configuration database on a first computer node;

providing a definition editor having a user interface on a second computer node, the definition editor supporting specification of data quality and status behaviors defined within the global data quality and status behavior definition; and

wherein the first computer node further comprises means for defining a distribution mechanism and the method comprises the further step of propagating changes to the global data quality and state behavior definition with the defined distribution mechanism to a set of workstations on a network executing a human interface application, wherein the human interface application comprises a graph associated with data having an associated quality and state.

11. The method of claim 10, further comprising configuring, by the definition editor, status graphic element data quality and status display characteristics for a specified data source.

12. The method of claim 11, wherein the status graphical element comprises a set of icons corresponding to a set of supported data qualities and statuses.

13. The method of claim 10, wherein said propagating step includes communicating changes to said global data quality and state behavior definitions without requiring requests from workstations affected by said changes.

14. The method of claim 10, further comprising redrawing the affected graph in response to receiving changes to the global data quality and state behavior definitions.

15. The method of claim 10, further comprising the steps of: presenting, by the definition editor, an editor dialog graphical user interface on the workstation that includes a global enablement control, the global data quality and status behavior definition being caused to replace a non-global data quality and status behavior upon selection of the global enablement control.

16. The method of claim 10, further comprising the steps of: through the definition editor, an editor dialog graphical user interface is presented on the workstation that includes a list of supported data quality and status types.

17. The method of claim 10, further comprising the steps of: through the definition editor, an editor dialog graphical user interface is presented on a workstation that includes a list of configurable display characteristics for communicating data quality or status.

18. The method of claim 17, wherein the editor dialog graphical user interface includes a display characteristics editor box for configuring a particular display characteristic from the configurable list of display characteristics.