Methods and apparatus for accessing process control data

Methods, apparatus, and articles of manufacture for accessing process control data involve loading a client object and communicating a data access request from the client object to a real object configured to communicate with a server. The real object then communicates a query to the server based on the data access request and obtains process control data from the server in response to the query. The process control data is then mapped from a first data layout associated with a server schema to a second data layout associated with a client schema. The mapped process control data is then communicated to an application.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to processor control systems and, more particularly, to process control apparatus and methods for accessing process control data.

BACKGROUND

Process control systems, like those used in chemical, petroleum or other processes, typically include one or more centralized process controllers communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital, or combined analog/digital buses. The field devices, which may be, for example, valves, valve positioners, switches, and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine and then generates control signals that are sent over the buses or other communication lines to the field devices to control the operation of the process. Information from the field devices and the controllers may be made available to one or more applications executed by the operator workstation to enable an operator to perform desired functions with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.

During design phases and system operation, a system engineer must often access process control data to view, monitor, add, update, modify, etc. the process control data. For example, process control systems are typically configured using configuration applications that enable a system engineer, operator, user, etc. to define how each field device within a process control system should function for a particular process (e.g., a particular chemical production process). When a field device is added to a particular process or each time a change is made to the process, an engineer may generate a new control program or new configuration data or may update or modify an existing control program. Each process may use a large number of field devices, controllers, and/or other control devices and, thus, a control program may include a large amount of process control data. Some known process control systems provide editors or process control data viewers that enable users to monitor a process during operation and/or to view, create, and/or update control programs. Known process control data editors and viewers typically constrain a user to features that are provided by a process control software developer. For example, a process control software developer may survey its customers to determine desirable types of user interface controls and data access functionality. The user interface and data access features available to customers at the time process control software is released is then subject to the general demand by other customers to incorporate those features.

Customizing process control software on a customer-by-customer basis is often a relatively expensive and complex project. Specifically, if a customer requires specific or custom user interface or data access features, the customer needs to understand and modify the original process control software source code. In this case, a process control software vendor must provide many resources (e.g., software developers, system engineers, source code, etc.) to each customer that wishes to customize their software. In addition, the software vendor may require customers to purchase source code licenses or development licenses prior to delivering source code to the customers. Resources and/or licenses are often relatively expensive for the software vendor and/or customers. Also, by releasing certain source code, a vendor may be at risk if that source code includes trade secret, confidential, or otherwise competitively advantageous coding techniques.

SUMMARY

Example methods and systems for accessing process control system data are disclosed herein. In accordance with on example, a method for accessing process control data involves loading a client object and communicating a data access request from the client object to a real object configured to communicate with a server. The real object then communicates a query to the server based on the data access request and obtains process control data from the server in response to the query. The process control data is then mapped from a first data layout associated with a server schema to a second data layout associated with a client schema. The mapped process control data is then communicated to an application.

In accordance with another example, another method for accessing process control data involves loading first and second client objects in response to a user interface request. The first and second client objects are associated with accessing process control data organized based on a client schema. Real objects associated with the first and second client objects are then loaded. The first and second real objects are configured to obtain process control data organized based on a server schema. The process control data is then mapped from the server schema organization to the client schema organization and communicated to the first and second client objects. The process control data is then obtained by a first user interface associated with the first client object and a second user interface associated with the second client object.

In accordance with another example, a system for accessing process control data includes a pre-generated partial class and a user-generated partial class. The pre-generated partial class includes pre-generated class elements associated with accessing process control data. The user-generated partial class is associated with the pre-generated partial class and includes user-defined class elements that can access process control data via the pre-generated class elements. The system also includes a user interface that is configured to instantiate a client object based on the pre-generated partial class and the user-generated partial class. The user interface is also configured to access process control data based on the pre-generated and user-defined class elements. The system also includes a client model configured to load an object handle and a real object associated with the client object and communicate process control data between the client object and a server via the object handle and the real object.

DETAILED DESCRIPTION

Although the following discloses example systems including, among other components, software and/or firmware executed on hardware, it should be noted that such systems are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of these hardware, software, and firmware components could be embodied exclusively in hardware, exclusively in software, or in any combination of hardware and software. Accordingly, while the following describes example systems, persons of ordinary skill in the art will readily appreciate that the examples provided are not the only way to implement such systems.

In contrast to known systems that constrain end users to pre-defined features and functions for accessing and interacting with process control data, the example apparatus, methods, and articles of manufacture described herein may be used to access process control data in a process control system server using customizable data access tools that enable an end user to customize the manner in which a client application accesses, represents, and displays the process control data. Process control data typically includes any data or information associated with a control system, a process, material flows and compositions, control system equipment, field devices, and any operational displays that are used to operate, maintain, and diagnose an overall system. A process control system server is typically located at a process plant and is used to store process control data. To automate, manage, and configure a process control system a company typically uses process control system software (i.e., a process control system application) that runs on a process control system server and manages every operation associated with the process control system based on user-defined process control data. A user (e.g., a system engineer) may interact with (e.g., manage, view, modify, configure, etc.) process control data using client applications that exchange commands, requests, and process control data with a process control system application. The client applications can typically be installed and run on any workstation (i.e., any computer terminal) connected to a network to which the process control system server is also connected.

Whether developed by an end-user or by a software vendor that provides process control software to an end-user, traditional client applications are often developed at the same time as or in combination with process control system applications. Traditional client applications typically provide a fixed set of data access and data handling functions to which a user is limited for accessing, representing, and viewing process control data. Customizing the data access and data handling functions is often a complex and expensive process because it requires modifying the process control system application software, modifying the client application software, re-compiling all of the software, and re-testing all of the software.

The example methods, apparatus, and articles of manufacture described herein provide a client model data interface layer (e.g., the client model116ofFIG. 1) that provides a customizable client/server data interface through which a client application (e.g., the client application108ofFIG. 1) can exchange data with a process control system server (e.g., the process control system database server112). The client model116enables client applications to be abstracted from the process control system server112and portable between different process control system servers. The client model116includes core data access or data exchange functionality and a base set of data access and data handling functions that enable the client application108to communicate and interact with the process control system database server112and exchange process control data therewith. The client model116may be provided to an end user (e.g., a customer, a system engineer, etc.) in a software development kit (SDK) as a plurality of object code files, header files, source code files, etc. An end user may then develop client applications based on the client application SDK to interface with the process control system server to view, manage, and configure process control data. The end user may modify or add data access functions at any time and re-compile only the client application software each time without needing to modify the process control system application software.

As described in greater detail below, the client model116is implemented using partial classes associated with an object-oriented programming language. Partial classes are used to split, divide, or partition class types into two or more sections that can reside in two or more files. In this manner, a programmer may split or break up lengthy code into smaller sections or partition code based on functionality, frequency of use, or any other criteria. As described below, the partial classes can be used to separate pre-generated code from user-generated code. Corresponding partial classes may reside in any combination of object code and source code. Pre-generated code comprises pre-generated partial classes for the client model116that are developed during initial development of a process control system application software and compiled to generate client model object code that is delivered to an end user via, for example, a client application SDK as described above. User-generated code includes user-generated partial classes that correspond to the pre-generated partial classes and that are used to define custom functionality for a subsequently developed (e.g., an aftermarket) client application.

The end user may develop client application software by using only those functions provided in the client model object code or the end user may subsequently develop source code to define additional, user-defined data access functions to access, represent, and/or display process control data as desired by the end user. The user-defined data access functions are developed in user-generated partial classes may use any resources, elements, or functions defined in corresponding pre-generated partial classes of the client model object code. During compile time a compiler scans every file (e.g., every object file and source file) of a software project and cross links corresponding partial classes to form a complete class that defines every element, function, or aspect of that class. During execution, the client application108recognizes the combined corresponding partial classes as a complete class and, thus, enables user-defined data access functions to work with the client model116as if the user-defined data access functions were originally part of the client model object code.

The client model116also enables a user to define the process control data layout or how the process control data is represented when it is retrieved from a process control system database (e.g., the process control system database110ofFIG. 1). The process control system database110organizes process control data using tables, columns, records, entries, fields, etc. When the process control system database server112retrieves process control data from a process control system database, the server organizes the process control data according to a server schema. However, client applications often require the process control data to be organized, represented, or laid out differently so that the client applications can display the process control data as defined by a user. To facilitate accessing and displaying data via a client application, an end user may define a client schema for each client application during the design phase of that client application. During operation, the client model116may obtain process control data from the process control system database server110in a server schema organization or arrangement and rearrange the process control data from the server schema organization to a client schema organization or arrangement according to the user-defined client schema as described below in connection withFIGS. 13 through 30.

Now turning in detail toFIG. 1, a client/server architecture100includes a client machine102and a process control system machine104. The client machine102is generally used to view, modify, and manage any process control data associated with a process control system. The client machine102may be implemented using a computer, a workstation terminal, a portable computer, a laptop computer, a handheld personal digital assistant (PDA), or any other suitable processor system. The process control system machine104stores the process control data and automates and manages a process control system based on the process control data. The process control system machine104may be a workstation, a mainframe, a server, or any other suitable processor system (e.g., the example processor system3310ofFIG. 33) that is communicatively coupled to control devices in a process control system. The process control system machine104is configured to provide the process control data to the client machine102(or any other client machine configured to communicate with the process control system machine104) and is configured to modify, add, or update process control data as requested by the client machine102and/or control devices in a corresponding process control system.

The client machine102may be communicatively coupled to the process control system machine104via a communication network106. The communication network106may be, for example, a local area network (LAN) or a wide area network (WAN), and may be implemented using any suitable communication technology or combination of technologies such as, for example, Ethernet, IEEE 802.11, Bluetooth®, any digital or analog mobile communication system (i.e., a cellular communication system), digital subscriber line (DSL), any broadband communication system, etc.

The client machine102includes the client application108that enables a user to retrieve, view, manage, and store process control data. A user may install machine accessible instructions in the client machine102that implement the client application108and subsequently use the client application108to access stored process control data and/or real-time process control data. Stored process control data may include information associated with control device configuration parameters, process control data values measured at periodic intervals, historical measurement values, or any other values that may be stored for subsequent retrieval. In general, real-time process control data includes any process control data that is not stored, but instead generated or derived upon request. For example, real-time process control data may include process control data values that are measured, acquired, generated, or calculated in response to a data request from the client application108.

Stored process control data may be obtained from the process control system machine104. The process control system machine104includes a process control system database110that is configured to store process control data (e.g., stored process control data) and the process control system database server112that is communicatively coupled to the process control system database110. The process control system database server112is configured to communicate stored process control data between the process control system database110and the client application108.

The client machine102includes a runtime server114to provide real-time process control data. The runtime server114may be communicatively coupled to the network106and configured to obtain process control data from the database server112and/or directly from control devices in a process control system. For example, the runtime server114may derive real-time process control data based on one or more stored process control data by requesting process control data from the database server112and performing, for example, a mathematical operation or any other operation on the retrieved process control data. If the client application108requests a real-time measured process control data value (e.g., a temperature value, a pressure value, a flow rate value, etc.) associated with a control device, the runtime server114may communicate with that control device via the process control system machine104and/or the network106to retrieve the real-time measured process control data value.

The client application108includes the client model116and a user interface118. The client model116is communicatively coupled to the process control system machine104and the runtime server110and enables the client application108to communicate with the process control system machine104and the runtime server110to access stored process control data and real-time process control data. Specifically, the client model116provides data access functions that may be used by the client application108to access and exchange stored and real-time process control data. The data access functions include a base set of data access functions and may also include user-defined data access functions. As described in greater detail below in connection withFIG. 2, the base set of data access functions are provided via pre-generated partial classes and the user-defined data access functions are provided via user-generated partial classes that correspond to the pre-generated partial classes.

The user interface118is configured to generate a plurality of graphics-based and/or text-based user interface screens that may be used to access, view, manage, modify, update, etc. process control data. A user may specify during a design phase and/or during a runtime phase a display layout or display arrangement to be used by the user interface118to display the process control data. By way of example, the user interface118is shown as including a tree view interface120and a content view interface122. The tree view interface120may be used to display process control data in a hierarchical tree structure with expanding and collapsing portions to view less or more detail of selected control devices. The content view interface122may be used to display process control data overlayed onto a process control system diagram. For example, the content view interface122may display a plurality of control devices communicatively coupled to one another in a process control system diagram and display process control data adjacent to or on corresponding control devices. In this manner, a user may view process control data in the context of an entire process control system.

The client model116communicates process control data between the user interface118, the runtime server114, and the process control system database server114based on schemas, queries, and commands. A schema defines a particular data organization, arrangement, or data layout for how process control data should be represented. For example, a client schema defines the particular data arrangement or data layout used to represent process control data for the user interface118. The user interface118may be associated with a plurality of client schemas, each of which is used to arrange, organize, or represent different process control data. For example, one client schema may be used to represent pump control device data while another client schema may be used to represent property values that are common to a plurality of control devices while yet another client schema may be used to represent process control data associated with control devices in a particular plant area.

A server schema defines the particular data arrangement or data layout used to represent or arrange process control data for the process control system database server112and the runtime server114. The server schema for the process control system database server112may be different than a server schema for the runtime server114. However, in general, server schemas are typically used to represent, organize, or arrange data differently than client schemas. For example, server schemas may be used to represent all of the process control data associated with a process control system, while client schemas may be used to represent only specific portions or segments of that process control data.

The client model116is configured to convert or map process control data between server schemas and client schemas as described in detail below in connection withFIGS. 13 through 30. For example, in response to a data request query from the user interface118, the client model116converts or maps the process control data from a server schema to the client schema to arrange the process control data based on the client schema provided by the user interface118. The client model116may also convert or map modified or updated process control data from a client schema to a server schema in response to an update query from the user interface118.

Queries generated by the user interface118and/or the client model116may include data request queries and update queries. The data request queries are used to retrieve particular process control data and the update queries are used to modify or update process control data in, for example, the process control system database110. In response to receiving a query from the user interface118, the client model110determines whether the query is associated with stored or real-time process control data and communicates the query to the process control system database server112or the runtime server114accordingly. If the query includes portions associated with both stored and real-time process control data, the client model116may parse or divide the query into a real-time data query and a stored data query and communicate the queries to the servers112and114, respectively.

The commands may include machine accessible instructions that cause the servers112and114to retrieve, modify, and/or create process control data. For example, some commands may include instructions associated with accessing (e.g., retrieving, modifying, or creating) process control data in the process control system database110based on the queries and update queries. Additionally, some commands may include instructions that cause the runtime server114to measure or acquire process control data from a control device or cause the runtime server114to derive a process control data value (e.g., an average value, a filtered value, etc.) based on stored process control data.

FIG. 2is a detailed functional block diagram of the client model116and the user interface118ofFIG. 1. Specifically,FIG. 2depicts the manner in which partial classes are used during a runtime phase to exchange process control data between the user interface118, the client model116, and the servers112and114. The user interface118uses a plurality of client schemas (e.g., the plurality of client schema hierarchies ofFIGS. 14,17,20,23,26, and29) to address different process control data. By way of example, the user interface118is shown as including a first client schema object model202a, a second client schema object model202b, and a third client schema object model202c, each of which is associated with a respective one of a first, a second, and a third client schema. The user interface118also includes user I/O controls204that are configured to display process control data in user interface (UI) views (e.g., the tree view120and content view122ofFIG. 1) and to obtain user input associated with retrieving, displaying, and/or modifying process control data. The user I/O controls204may include, for example, textboxes, buttons, lists, data fields, etc. and may be implemented using any suitable control framework including, for example, the Microsoft® Avalon controls framework.

Each of the client schema object models202a-cincludes one or more pre-generated partial classes206and one or more user-generated partial classes208that enable accessing and handling process control data associated with a respective one of first, second, and third client schemas. Specifically, the pre-generated partial classes206include pre-defined class elements, while the user-generated partial classes108include user-defined class elements. Class elements may include data members, accessors, methods or functions, implementations, and/or any other class element known in the art, each of which may be designated as private, protected, or public. The class elements of the pre-generated partial classes206may be used to communicate with the process control system database server112(FIGS. 1 and 2) via real objects (e.g., the real objects216described below) as described in detail below in connection withFIG. 6. The class elements of the user-generated partial classes208may be configured to access data associated with the class elements of corresponding ones of the pre-generated partial classes206and may be configured to communicate with the process control system database server112via the class elements in the pre-generated partial classes206. As shown inFIG. 2, the user-generated partial classes108include user-defined functions210. Each complete class formed by corresponding ones of the partial classes206and208may be associated with different types of process control data. For instance, an example class may include data access and handling functions associated with a particular type of control device while another example class may include data access and handling functions associated with a particular process plant area or a particular process control subsystem. Yet another example class may include functions associated with mathematically and/or statistically processing (e.g., averaging, filtering, etc.) process control data.

During a development phase, for each client schema, an end user may select one or more pre-generated partial classes to create each of the pre-generated partial classes206. Also during the development phase, the end user may develop the user-defined functions210and create the user-generated partial classes208of each of the client schema object models202a-cby selecting one or more user-generated partial classes associated with the user-defined functions210.

The partial classes206and208selected for the first client schema object model202amay be different from the partial classes206and208selected for the second client schema object model202b. For example, the partial classes206and208for the first client schema object model202amay be used to access process control data associated with control devices of a first process plant area while the partial classes206and208for the second client object model202bmay be used to access process control data associated with control devices of a second process plant area.

During a runtime phase, the partial classes206and208may be used to generate a plurality of client objects212for each of the client schema object models202a-c. The client objects212follow or correspond to the data arrangement or the data layout of the client schemas of a client application (e.g., the client application108ofFIG. 1). Each of the client objects212is of a class type defined by one of the partial classes206and208. Two or more of the client objects212of the same class type may be generated such as, for example, two objects of class type pump, each for a different physical pump control device in a process control system. In addition, two or more of the client objects212may be generated to access process control data associated with the same physical control device. Accesses to the process control data of the same physical control device by the two or more of the client objects212are arbitrated or handled in the client model116via real objects (e.g., the real objects216) as described below. The client objects212can be used to data-bind the user I/O controls204to real-time and stored process control data as described in detail below in connection withFIG. 9. By data binding the user I/O controls204to the process control data, the client objects212can generate data request queries and/or data update queries in response to user-input provided via the user I/O controls. As described above, the queries are used to retrieve or modify stored or real-time process control data. The client objects212can also update process control data values displayed via the user I/O controls204in response to data update events indicating that at least some process control data values in, for example, the process control system database210, have changed or have been modified.

The client model116includes a first plurality of object handles214a, a second plurality of object handles214b, and a third plurality of object handles214c. As shown inFIG. 2, each of the plurality of object handles214a-cis associated with a respective one of the client schema object models202a-c. The client model116also includes a plurality of real objects216. The real objects216follow or correspond to the data arrangement or the data layout of server schemas associated with the process control system database server112and/or the runtime server114ofFIG. 1. The object handles214a-care address references or base addresses that correspond to the locations of the real objects216in memory. During runtime, when one of the real objects216is created and stored on a memory heap, a corresponding handle in one of the handles214a-cis also created and stored on a memory stack. Each of the client objects212is associated with one of the real objects216and accesses process control data via that one of the real objects216by communicating data access requests, queries, update queries, and/or process control data to that real object via the object handle (e.g., one of the object handles214a-c) of that real object. The real objects216communicate queries and/or update queries to the process control system database server112in response to queries or update queries received from the client objects212. The real objects216obtain from the process control system database server112process control data organized or arranged based on a server schema (e.g., one of the server schema hierarchies ofFIGS. 14,17,20,23,26, and29). The client model116then maps, rearranges, or converts the process control data from a server schema organization to a client schema organization as described below in connection withFIGS. 13 through 29.

In some cases, two or more of the client objects212correspond to a particular one of the real objects216. For example, when two or more of the client objects212are constructed from the same class type to access the same process control data, a single one of the real objects216is created for those two or more of the client objects212. In this manner, one of the real objects216can arbitrate data access requests made to the same process control data by two or more of the client objects212.

FIGS. 3 and 4depict an example code configuration that may be used to share code between user-generated and pre-generated partial classes through inheritance.FIG. 3shows a pre-generated file302named ‘MODULE_GEN.CS’, a first user-generated file304named ‘MODULE_MANUAL.CS’, and a second user-generated file306named ‘MODULE_BASE.CS.’ The pre-generated file302defines partial classes in a namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’308, which contains a pre-generated public partial class of type ‘MODULE’310(i.e., the pre-generated public partial class ‘MODULE’310). The public partial class ‘MODULE’310may include class elements configured to communicate with the process control system database server112ofFIGS. 1 and 2. The public partial class ‘MODULE’310may be part of the pre-generated partial classes206ofFIG. 2.

The first user-generated file304uses a namespace ‘DELTAV.CONFIG.EXPLORER’312and partial class definitions in the namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’310. In the namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’310, the pre-generated public partial class ‘MODULE’310inherits the class elements of the user-generated class ‘MODULE_BASE’314. In this manner, the classes ‘MODULE’310and ‘MODULE_BASE’314can share or access each other's class elements. For example, class elements defined in the class ‘MODULE_BASE’314can communicate with the process control system database server112via class elements defined in the class ‘MODULE’310. The class ‘MODULE_BASE’314is defined in the second user-generated file306described below and may be part of the user-generated partial classes208ofFIG. 2.

The second user-generated file306includes source code that may be used to configure a client application (e.g., the client application108ofFIG. 1) to share source code between the pre-generated partial class ‘MODULE’310and the user-generated partial class ‘MODULE_BASE’314. In the second user-generated file306, the namespace ‘DELTAV.CONFIG.EXPLORER’312contains the implementation of application-specific methods for the user-generated partial class ‘MODULE_BASE’314. The application-specific methods of the user-generated ‘MODULE_BASE’314are inherited by the user-generated partial class ‘MODULE’310in the first user generated file304.

FIG. 4depicts an example runtime configuration used to share the source code ofFIG. 3between two different namespaces during a runtime phase.FIG. 4shows an instance of the namespace ‘DELTAV.CONFIG.EXPLORER’312, an instance of the namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’308, and an instance of a namespace ‘DELTAV.CONFIG.EXPLORER.CONTENT’402. Client objects of the partial class type ‘MODULE’310loaded or instantiated in either of the namespaces308or402can use source code or class elements defined in either the pre-generated file302or the user-generated file306.

The instance of the namespace ‘DELTAV.CONFIG.EXPLORER’312includes the class elements defined in the second user-generated file306(FIG. 3) for the user-generated partial class ‘MODULE_BASE’314. The instance of the namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’308includes a first ‘MODULE’ client object404of class type ‘MODULE’ (e.g., the partial class type ‘MODULE’310). The instance of the namespace ‘DELTAV.CONFIG.EPLORER.CONTENT’402includes a second ‘MODULE’ client object406, which is also of class type ‘MODULE’ (e.g., the partial class type ‘MODULE’310). Each of the client objects404and406includes a user-generated portion410(e.g., user-generated class elements) and a pre-generated portion412(e.g., pre-generated class elements). The user-generated portions410include class elements defined in the user-generated class ‘MODULE_BASE’310of the second user-generated file304. The pre-generated portions412include class elements defined in the user-generated partial type class ‘MODULE’310of the pre-generated file302.

FIG. 5depicts another example code configuration that may be used to share code between user-generated and pre-generated partial classes through aggregation. Pre-generated partial class code502includes the namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’308that contains the pre-generated partial class ‘MODULE’310. User-generated partial class code504includes the namespace ‘DELTAV.CONFIG.EXPLORER.HIERARCHY’312that contains the user-generated class ‘EXPLORER_MODULE’506. To share source code or class elements between the pre-generated partial class ‘MODULE’310and the user-generated class ‘EXPLORER_MODULE’506, the user-generated class ‘EXPLORER_MODULE’506defines a client object of type ‘MODULE’508(e.g., the partial class type ‘MODULE’310) that may be used by all of the class elements of the pre-generated partial class ‘MODULE’310defined in the pre-generated partial class code502.

FIG. 6depicts the relationships between pre-generated partial classes and real objects of a client application (e.g., the client application108ofFIG. 1) having two client schemas. A first client schema602uses a first plurality of pre-generated partial classes604and a second client schema606uses a second plurality of pre-generated partial classes608. The pre-generated partial classes604and608are substantially similar or identical to the pre-generated partial classes206ofFIG. 2. The client application108uses the two client schemas602and606to address different needs or different process control data. For example, the first client schema602is associated with modules under particular plant areas and the second client schema606is associated with alarms for a particular subsystem.

The client model116includes a first plurality of object handles610associated with the first client schema602and a second plurality of object handles612associated with the second client schema606. The object handles610and612are substantially similar or identical to the object handles214a-cofFIG. 2. The client model116builds or generates a separate group or tree of object handles for each of the client schemas602and606. The hierarchical relationship of the pre-generated partial classes in each of the pre-generated partial classes604and608is identical to the hierarchical relationships of the corresponding object handles610and612.

The client model116also includes a plurality of real objects614that are substantially similar or identical to the real objects216ofFIG. 2. The client application108communicates with the real objects614via client objects (e.g., the client objects212ofFIG. 2 and 710a-dofFIG. 7) associated with the pre-generated partial classes604and608. Specifically, client objects associated with the partial classes604and608access the real objects614via the object handles610and612.

When the client application108communicates a data access request (e.g., a query) from the first client schema602to the client model116, the client model116loads real objects (e.g., some of the real objects614) associated with the particular process control data (e.g., a particular plant area) with which the data access request is associated. When the client application108communicates a data access request (e.g., a query) from the second client schema606, the client model116loads all alarm attributes or properties of the ones of the real objects614associated with alarms for the particular subsystem with which the data access request is associated as shown inFIG. 6.

The client application108controls the life time of the real objects614or the duration for which the real objects614are loaded. For example, if the client application118indicates that some of the real objects614should remain loaded, those objects will not be available for unloading. Typically, objects such as the real objects614are unloaded by a garbage collection routine that periodically detects real objects that a client application has designated as available for garbage collection or available for unloading. For example, if the client application118determines that some of the real objects614should be unloaded, those objects are designated as available for garbage collection. In this case, a subsequent garbage collection scan will result in unloading the ones of the real objects614flagged as available for garbage collection or not flagged as currently in use.

FIGS. 7 and 8depict data paths formed between the user interface108and the client model116ofFIGS. 1 and 2during a runtime phase. In particular,FIG. 7depicts data paths between the client objects212and the real objects216for a first user interface (UI) view702and a second UI view704InFIG. 7, the UI views702and704share a common client schema.FIG. 8depicts data paths between the client objects212and the real objects216where the first UI view702and the second UI view704each has its own client schema. The UI views702and704may be substantially similar or identical to the tree view120and/or the content view122ofFIG. 1.

As shown inFIGS. 7 and 8, the first and second UI views702and704belong to or are associated with a client application object706. Each of the UI views702and704accesses process control data via one or more of the real objects216. The real objects216are shown as having a parent real object ‘R’708athat loads a ‘ModuleLibrary’ real role708b. A role such as, for example, the ‘ModuleLibrary’ real role708b, exposes or provides access to a plurality of process control data associated with that role. For example, a role may provide access to process control data associated with a particular plant area or with a particular type of control device. The ‘ModuleLibrary’ real role708bloads a first real object ‘R1’708cand a second real object ‘R2’708din response to process control data requests from the UI views702and704. For example, the first real object708cmay be associated with a first control device while the second real object708dmay be associated with a second control device.

To access process control data via the real objects216, the UI views702and704load the client objects212to communicate with the real objects216. For example, as shown inFIG. 7, to access process control data associated with the ‘ModuleLibrary’ real role708b, the first UI view702loads a parent client object ‘O’710a. The parent client object ‘O’710areferences a parent object handle ‘H’712athat the parent client object710auses to access the parent real object ‘R’708avia a zeroth mask ‘M’714a. A mask such as, for example, the zeroth mask ‘M’714a, is configured to translate or map process control data from a data layout or arrangement of a server schema to data layout or arrangement of a client schema. For instance, the parent real object708amay be a library object that provides access to a plurality of process control data libraries. If the parent client object710ais configured to access only a subset of the plurality of library objects (e.g., the ‘ModuleLibrary’ real role708b) associated with the parent real object708a, the mask714atranslates or maps library access requests from the parent client object710ato the corresponding libraries in the parent real object708a. For example, a mask may include a plurality of pointers arranged in a layout that corresponds to a client schema and that point to or reference process control data in a real object.

The data paths are shown as a plurality of active and inactive data paths. A solid line represents a data path that is active or in use by one of the UI views702and704to access a particular object, handle, or mask. A dotted line represents a data path that is inactive or no longer in use by either of the UI views702or704. For example, initially the first UI view702causes the parent client object ‘O’710ato instantiate or load a first child client object ‘O1’710b. The first UI view702can use the first child client object710bto access process control data via the first real object708c. The first UI view702accesses the first child client object710bvia a first data path716, which is initially a solid line (not shown) to indicate an active or ‘in use’ data path. The first child client object710breferences a first handle ‘H1’712band accesses the first real object708cvia a first mask ‘M1’714b.

In addition, because the first and second UI views702and704share a common client schema, the second UI view704can also access the first real object708cvia the first child client object710b. As shown inFIG. 7, the second UI view704accesses the first child client object710bvia a second data path718. When the first UI view702finishes using the first child client object710b, the first data path716becomes inactive as shown inFIG. 7by a dotted line. If no other UI view of the client application706requires access to the first child client object710b, the client object710bbecomes available for garbage collection (e.g., available for unloading). However, because the second UI view704continues to access the first child client object710b, the data path718remains active as indicated inFIG. 7by a solid line, and the client object710bdoes not become available for garbage collection. Data paths720,722, and724from the first child client object710bto the first real object708calso remain active as indicated by solid lines.

When a client object is no longer used by any user interface of a client application, all of the data paths associated with that client object become inactive and the client object and a corresponding handle and mask are flagged as ready for garbage collection and are subsequently unloaded by the client model116. In addition, if the real object that was being accessed by that client object is no longer accessed by any other client object, that real object is also flagged as ready for garbage collection and is subsequently unloaded by the client model116. For example, a second child client object ‘O2’710cthat is initially instantiated or loaded for the first UI view702to access the second real object708dsubsequently becomes inactive and flagged as ready for garbage collection when it is no longer used by either of the UI views702or704. A second object handle714cand a second mask714calso become flagged as ready for garbage collection. In this case, all of the data paths associated with the second child client object710cbecome inactive as shown inFIG. 7by dotted lines. Although the client model116unloads the second child client object710c, the second object handle712c, and the second mask714c, the client model116may not unload the second real object708dif another child client object is still using or still requires access to the second real object708d.

After an instance of a particular client object is unloaded another instance of that client object may be loaded for any subsequent access to the process control data associated with that client object. For example, as shown inFIG. 7, after the second child client object710cis unloaded (e.g., unloaded during garbage collection), the first UI view702may cause the parent object710ato load or instantiate a second instance of the second child client object ‘O2′’710dto access the second real object708d.

InFIG. 8, each of the UI views702and704has its own separate client schema and accesses the real objects216using its own child client objects. For instance, the second UI view704instantiates or loads a client object ‘O1″’802, which is separate from all of the client objects used by the first UI interface702. The example method described below in connection withFIGS. 31A and 31Bmay be used to form communication paths between the UI views702and704and the real objects216shown inFIGS. 7 and 8.

FIG. 9is a block diagram depicting data binding between the user interface118ofFIGS. 1 and 2and a client object902that is substantially similar or identical to one of the client objects212ofFIG. 2. The user interface118inFIG. 9is shown by way of example as having first, second, and third user I/O controls904a,904b, and904cthat are substantially similar or identical to the user I/O controls204ofFIG. 2. For example, the user I/O controls904a-cmay be text boxes, list boxes, data fields, check boxes, etc. The client object902includes a user-generated class elements portion906and a pre-generated class elements portion908. Class elements of the user-generated elements portion906are defined in a user-generated partial class (e.g., one of the user-generated partial classes208ofFIG. 2) and class elements of the pre-generated class elements portion908are defined in a pre-generated partial class (e.g., one of the pre-generated partial classes206ofFIG. 2). A plurality of properties910a-910edescribed below are created based on the class elements of the user-generated and pre-generated portions906and908.

The user-generated portion906includes a PROPERTY_A element910aand a PROPERTY_B element910b. The pre-generated portion908includes a PROPERTY_C element910c, a PROPERTY_D element910d, and a PROPERTY_E element910e. The property elements910c-eare used to retrieve stored process control data from the process control system database110. The PROPERTY_A element910ais associated with the PROPERTY_C element910cand derives a value based on the PROPERTY_C element910c. The client object902includes a private hash table912shown inFIG. 9that includes the mappings or associations between user-generated elements (e.g., the property elements910aand910b) and pre-generated elements (e.g., the property elements910c-e). The private hash table912may be referenced or accessed via a variable or pointer of type ‘HashTable’ that is private to the object912. The association between the PROPERTY_A element910aand the PROPERTY_C element910cis shown in row914of the private hash table912.

The user I/O controls904a-care data bound to PROPTERY_A element910a, PROPERTY_D element910d, and PROPERTY_E element910e, respectively. Data binding the user I/O controls904a-cin this manner causes the client application108to communicate data values between the user I/O controls904a-cand their respective ones of the elements910a,910d, and910eeach time any of those data values are updated. For example, as described in greater detail below in connection withFIG. 32, the process control system database server112and the client model116may exchange update information (e.g., ‘UpdateNotification’ events and lists of questionable or dirty objects) regarding process control data that has been modified in the process control system database server110. In this manner, the client object902may determine whether any of the modified process control data is associated with any of its property elements910c-d, which are used to access stored process control data and, if so, updates the values of each of the property elements910c-dfor which a process control data value was modified. The client object902may then use the private hash table912to update the values of any of the user-generated properties (e.g., the properties910aand910b) that are associated with or use any of the property elements910c-dfor which process control data has been modified.

To update the values of the data bound user I/O controls904a-cthe client model116parses update information received via an update notification event to generate a ‘PropertyChanged’ event for any user-generated or pre-generated property for which process control data has been modified. The ‘PropertyChanged’ event then causes the data bound user I/O controls904a-cto obtain modified process control data from a respective one of the properties910a-eand update the values of the I/O controls904a-c.

The client object902may also use the update information to populate a dirty hash table916. The dirty hash table916is referenced via a variable or pointer of type ‘HashTable’ and is private to the object902. The dirty hash table916is used to store dirty or questionable object handles for a client application (e.g., the client application108ofFIG. 1). The dirty object handles are provided in the update information and indicate that process control data for some client objects has been in the process control system database110. The client application108may use a ‘PopulateDirtyHashTable’ function to populate the dirty hash table916with the dirty object handles. For example, the ‘PopulateDirtyHashTable’ function first receives update information from the update notification event and then parses the update information and populates the dirty hash table916with the dirty handles.

FIG. 10depicts example server schema XML source code1000that defines an example server schema. The server schema XML source code1000is stored in the process control system database server112and defines the arrangement or layout used to represent process control data by the process control system database server112. The server schema XML source code1000contains class type definitions and enumeration definitions. Each class type has a name and contains a number of properties, roles, and commands. Each property has a name and data type.

A role has a name and the class type(s) it contains. A contained base type for items in a role is declared in a role element. Specific class subtypes are nested within the role element. Each contained class type is marked whether it can be created by a client application (e.g., the client application108ofFIG. 1) via a command. A class type definition also contains commands that can be executed via command scripts obtained from, for example, the client application108. Each command has a name and defines its parameters and return type.

As shown inFIG. 10, the server schema XML source code1000specifies a type named ‘ControlModule’ (line1002). The type name ‘ControlModule’ (line1002) contains a property named ‘detailDisplayName’ of data type string (line1004) and a role named ‘Blocks’ of destination type ‘BlockBase’ (line1006). The role name ‘Blocks’ (line1006) contains a type named ‘ModelUsage’ that can be created by the client application108(line1008). The type name ‘ModelUsage’ (line1008) contains a plurality of creation parameters (lines1010and1012) that are created when the client application108loads or instantiates an object of type ‘ModelUsage’. The type name ‘ControlModule’ (line1002) also contains a command named ‘renameTo’ of return type void (line1014). The command name ‘renameTo’ (line1014) contains a parameter named ‘newName’ of data type string (line1016).

The server schema XML source code1000also specifies an enumeration definition. Specifically, the server schema XML source code1000includes an enum named ‘DbeAttributeType’ (line1018). The enum name ‘DbeAttributeType’ (line1018) contains a plurality of items that include an entry named ‘Float’ (line1020) and an entry named ‘FloatWithStatus’ (line1022).

An enumeration can be reference in the data type field of a property. For example, a type named ‘Attribute’ (line1024) contains a property named ‘attributeType’ of data type ‘DbeAttributeType’ (line1026), which corresponds to the enum name ‘DbeAttributeType’ (line1018).

FIG. 11is example XML source code1100that is returned by the process control system database server112to the client model116in response to a query submitted by the client model116. Specifically, the example XML source code1100is returned in response to the query Site.PlantAreas [name=‘AREA_A’](index).Modules(name). As shown inFIG. 11, the results in the XML source code1100includes a ModelRole named ‘PlantAreas’ (line1102). The ModelRole name ‘PlantAreas’ (line1102) contains a PlantArea named ‘AREA_A’ (line1104). The PlantArea name ‘AREA_A’ (line1104) contains a property index (line1106) that is set equal to zero and a ModelRole named ‘Models’ (line1108). The ModelRole name ‘Modules’ (line1108) contains a plurality of modules and a corresponding property for each. For example, the ModelRole name ‘Modules’ (line1108) contains a ModuleInstanceBase named ‘EM1’ (line1110), which contains a property named ‘EM1’ (line1112).

FIG. 12depicts example client schema XML source code1200that may be used to map process control data from a server schema (e.g., the server schema XML source code1000ofFIG. 10or one of the server schema hierarchies described below in connection withFIGS. 14,17,20,23,26, and29) to a client schema (e.g., one of the client schema hierarchies described below in connection withFIGS. 14,17,20,23,26, and29). A client schema defines types of properties, roles, and commands in a substantially similar manner as a server schema defines types. For each type, property, and role, client schema XML source code (e.g., the client schema XML source code1200) indicates a mapping into a server schema so that the client model116(FIG. 1) can rearrange or map process control data between a client schema and a server schema.

As shown inFIG. 12, a type named ‘Module’ in a client schema is mapped to a type named ‘Module’ in a server schema (line1202). In this case, the type named ‘Module’ in the client schema is also named ‘Module’ in the server schema. However, a type name in a client schema may map to a type name in a server schema having a different name. For example, a type name ‘ModuleOne’ may map to a type name ‘ModuleTwo.’

A properties element (line1204) may contain one or more property elements. Each property element defines one or more client properties of the client type and contains the name of each client property, the domain with which the client property is associated and the mapping to a server schema. As shown inFIG. 12, a property named ‘desc’ is associated with the database domain (e.g., the property corresponds to stored process control data that is stored in the process control system database110) and is mapped to a property named ‘description’ in a server schema (line1206). A property named ‘rtValue’ is associated with the runtime domain (e.g., the property corresponds to real-time process control data that can be obtained from the runtime server114ofFIG. 1) and is mapped to a property named ‘ST’ in a server schema (line1208). The property mappings are relative to the containing type. For example, if the containing type is ‘Module’, which is within the containing type ‘Site’, the query generated to retrieve the ‘desc’ property for MOD_X is Site.Modules[name=‘MOD_X’] (description).

A roles element (line1210) contains one or more Role elements. Each Role element defines a client role associated a client type and contains the name of the client role, the domain with which the client role is associated, the mapping used to get the client role, and the type of the objects of the client role. As shown inFIG. 12, the roles element (line1210) contains a role named ‘attributes’ that is associated with the database domain (e.g., the role corresponds to stored process control data that is stored in the process control system database110) and is mapped to a role named ‘Attributes’ in a server schema (line1212). The role mappings are relative to the containing type. For example, if the containing type is ‘Module’, which is contained within a containing type ‘Site’, the query generated to retrieve the ‘attributes’ role for MOD_X is Site.Modules[name=‘MOD_X’].Attributes.

FIGS. 13 through 29depict example user interfaces, schema mapping configurations, and example XML source code that may be used to map class elements such as objects and roles from a server schema that resides on a server (e.g., the process control system database server112or the runtime server114ofFIG. 1) to a client schema that resides in a client application (e.g., the client application108ofFIG. 1). The mapping configurations described below may be implemented by the client model116to abstract a client application from process control system servers. By mapping class elements from a server schema to a client schema via the client model116, a client application may be configured to be communicatively coupled to and work with a plurality of servers. Further, developing client applications based on the client model116using schema mapping configurations as described below enables a plurality of applications, each having particular process control data requirements, to be communicatively coupled to and work with a process control system server.

FIG. 13depicts an example user interface1300that represents an object and the roles contained therein. The example user interface1300shows a unit module ‘AREA_A’1302as one complete object. However, in the process control system database110(FIG. 1), the unit module ‘AREA_A’1302is stored as two separate objects. A first object contains the behavior of the unit module ‘AREA_A’1302and the second object contains module container behavior that defines how other modules can be nested within the unit module ‘AREA_A’1302.

FIG. 14is a detailed block diagram depicting a mapping configuration1400between a client schema and a server schema to generate the example user interface1300ofFIG. 13. The mapping configuration1400may be implemented by the client model116(FIG. 1). Specifically,FIG. 14shows a server schema hierarchy1402, a client schema hierarchy1404, and a client model hierarchy1406in a one-to-one mapping configuration. The server schema hierarchy1402indicates the distinction between a server object of type ‘Unit’1408and a server object of type ‘UnitModule’1410as stored in the process control system database110(FIG. 1). The hierarchy of the client model hierarchy1406follows, is substantially similar to, or is identical to the hierarchy of the server schema hierarchy1402. The client schema hierarchy1404represents only those objects and roles of interest from the server schema hierarchy1402by using masks1410a,1410b, and1410cthat provide pointers into the client model hierarchy1406.

The server schema hierarchy1402includes a server object of type ‘AREA’1412that contains a server role of type ‘Units’1414. The server role ‘Units’1414leads to the server object ‘Unit’1408that contains a server role of type ‘UnitModule’1418and a server role of type ‘Modules’1420. The server role ‘UnitModule’1418leads to the server object ‘UnitModule’1410and the server role ‘Modules’1420leads to a server object of type ‘Module’1422.

The client schema hierarchy1404includes a client object of type ‘AREA’1424that contains a client role of type ‘UnitModules’1426. The client role ‘UnitModules’1426leads to a client object of type ‘UnitModules’1428that contains a client role of type ‘Modules’1430. The client role ‘Modules’1430leads to a client object of type ‘Module’1432. The client objects and client roles are mapped to the server objects and server roles via real objects and roles of the client model hierarchy1406and the masks1410a-cas described below in connection withFIG. 15.

The client model hierarchy1406includes a plurality of real objects and real roles that are arranged substantially similarly or identically to the server schema hierarchy1402. The client model hierarchy1406includes a real object of type ‘AREA_A’1434that corresponds to the server object ‘AREA’1412. The real object ‘AREA_A’1434contains a real role of type ‘Units’1436that corresponds to the server role ‘Units’1414. The real role ‘Units’1436leads to a real object of type ‘ABC’1438that corresponds to the server object ‘Unit’1408. The real object ‘ABC’1438contains a real role of type ‘UnitModule’1440that corresponds to the server role ‘UnitModule1418and a real role of type ‘Module’1442that corresponds to the server role ‘Modules’1420. The real role ‘UnitModule’1440leads to a real object ‘ABC’1444that corresponds to the server object ‘UnitModule’1410. The role ‘Module’1442leads to a real object ‘SSS’1446that corresponds to the server object ‘Module’1422.

FIG. 15depicts example XML source code1500that may be used to generate the mappings from the server schema hierarchy1402to the client schema hierarchy1404ofFIG. 14. The XML source code1500shows that the client object ‘AREA’1424(FIG. 14) is mapped to the server object ‘AREA’1412(FIG. 14) (line1502). To map the client object ‘AREA’1424to the server object ‘AREA’1412, the client model116maps the real object ‘AREA_A’1434to the client object ‘AREA’1424via the mask ‘AREA_A’1410a. In this manner, the client object ‘AREA’1424accesses the server object ‘AREA’1412via the real object ‘AREA_A’1434as if the client object ‘AREA’1424were directly accessing the server object ‘AREA’1412.

The client object ‘AREA’1424contains the client role ‘UnitModules’1426(FIG. 14) that is mapped to the server role ‘Units’1414(FIG. 14) and that leads to the client object ‘UnitModules’1428(FIG. 14) (line1504). A client object in the client schema hierarchy1404can have the same name as a server object in the server schema hierarchy1402even if the client object does not map to the same named server object. For example, the client object ‘UnitModules’1428is mapped to the server object ‘Unit’1408(FIG. 14) (line1506). In this case, the client model116maps the client object ‘UnitModules’1428to the real object ‘ABC’1438via the mask‘ABC’1410b.

The client object ‘UnitModules’1428contains a property named ‘scanRate’ that is mapped to a ‘scanRate’ property of the server object ‘UnitModules’1410(i.e., ‘UnitModule(scanRate)’) (line1508). In this case, the client model116maps the ‘scanRate’ of the real object ‘ABC’1444to the ‘scanRate’ property of the client object ‘UnitModule’1428via the mask ‘ABC’1410b. By mapping the ‘scanRate’ property of the real object ‘ABC’1444to the ‘scanRate’ property of the client object ‘UnitModule’1428via the mask ‘ABC’1410b, the client model116traverses the server role ‘UnitModule’1418(FIG. 14) from the server object ‘Unit’1408to map the ‘scanRate’ property of the client object ‘UnitModules’1428to the ‘scanRate’ property of the server object ‘UnitModules’1410.

The object ‘UnitModules’1420contains the client role ‘Modules’1430(FIG. 14) that is mapped to the server role ‘Modules’1420(FIG. 14) and leads to the client object ‘Module’1432(FIG. 14) (line1510).

FIG. 16depicts an example user interface1600that represents a composite function block ‘PT_COMP’1602containing a function block and two attributes. As shown in the user interface1600, the composite function block ‘PT_COMP’1602includes a unified list1604of items that contains a function block ‘CALC1’1606, an attribute ‘ABS_PRESS_CF’1608, and an attribute ‘ABS_TEMP_CF’1610. If a user chooses to display a unified list of objects, the client model116may be configured to map a client role to two or more server roles. As described below in connection withFIG. 17, in a server schema (e.g., the server schema hierarchy1702ofFIG. 17) the object corresponding to the function block ‘CALC1’1606is associated with a different server role than the objects corresponding to the attribute ‘ABS_PRESS_CF’1608and the attribute ‘ABS_TEMP_CF’1610. However, in a client schema (e.g., the client schema hierarchy1704ofFIG. 17), the objects corresponding to the function block ‘CALC1’1604, the attribute ‘ABS_PRESS_CF’1606, and the attribute ‘ABS_TEMP_CF’1608are all represented as being part of the same client role.

FIG. 17is a detailed block diagram depicting a mapping configuration1700between a server schema hierarchy1702and a client schema hierarchy1704that maps a single client role to a plurality of server roles to generate the example user interface1600ofFIG. 16. The mapping described in the mapping configuration may be performed by the client model116(FIG. 1). The mapping configuration1700maps the client schema hierarchy1704to the server schema hierarchy1702via a client model hierarchy1706and a plurality of masks1708a-d. The server schema hierarchy1702includes a server object of type ‘Composite Function Block’1710containing two server roles: a server role of type ‘Blocks’1712and a server role of type ‘Attributes’1714. The server role ‘Blocks’1712leads to a client object of type ‘BlockUsage’1716and the server role ‘Attributes’1714leads to a client object of type ‘AttributeDefinitions’1718. As shown, the client model hierarchy1706follows the server schema hierarchy1702.

The client schema hierarchy1704includes a client object of type ‘Composite’1720that contains a client role of type ‘Children’1722. The client role ‘Children’1722leads to a client object of type ‘Block’1724and a client object of type ‘Attribute’1726.

FIG. 18depicts example XML source code1800that may be used to generate the mappings from the server schema hierarchy1702to the client schema hierarchy1704ofFIG. 17. The XML source code1800maps the client object ‘Composite’1720(FIG. 17) to the server object ‘Composite Function Block’1710(FIG. 17) (line1802). The client role ‘Children’1722contained within the client object ‘Composite’1720(line1804) maps to two server roles. In particular, the client role ‘Children’1722maps to the server role ‘Blocks’1712(line1806) and to the server role ‘Attributes’1714(line1808). For the mapping to the server role ‘Blocks’1712, the client role ‘Children’1722leads to the client object ‘Block’1724(line1806). For the mapping to the server role ‘Attributes’1714, the client role ‘Children’1722leads to the client object ‘Attribute’1726(line1808). The client role ‘Block’1724maps to the server object ‘BlockUsage’1716(line1810) and the client role ‘Attribute’1726maps to the server object ‘AttributeDefinition’1718(line1812).

FIG. 19depicts an example user interface1900that represents a plurality of different control devices within a particular plant area ‘AREA_A’1902. Specifically, the plant area ‘AREA_A’1902includes a ‘LIC-549’ control device1904, a ‘PLM1’ control device1906, and an ‘EM1’ control device1908. As described below in connection withFIGS. 20 and 21, the control devices1904,1906, and1908are represented in a client schema (e.g., the client schema hierarchy2004ofFIG. 20) as three separate client roles that are mapped to a single server role in a server schema (e.g., the server schema hierarchy2002ofFIG. 20).

FIG. 20is a detailed block diagram depicting a mapping configuration2000between a server schema hierarchy2002and a client schema hierarchy2004that maps a plurality of client roles to a single server role to generate the example user interface1900ofFIG. 19. The mapping configuration2000maps the client schema hierarchy2004to the server schema hierarchy2002via a client model hierarchy2006and a plurality of masks2008a-d. The server schema hierarchy2002includes a server object of type ‘Area’2010that contains a server role of type ‘Modules’2012. The server role ‘Modules’2012leads to a server object of type ‘Phase Logic Module’2014, a server object of type ‘Equipment Module’2016, and a server object of type ‘Control Module’2018. The client model hierarchy2006includes a real object of type ‘PLM1’2020, a real object of type ‘EM1’2022, and a real object of type ‘LIC-459’2024that correspond to the server object ‘Phase Logic Module’2014, the server object ‘Equipment Module’2016, and the server object ‘Control Module’2018, respectively. The real object ‘PLM1’2020, the real object ‘EM1’2022, and the real object ‘LIC-459’2024also correspond respectively to the ‘LIC-549’ control device1904, the ‘PLM1’ control device1906, and the ‘EM1’ control device1908shown in the user interface1900.

The client schema hierarchy2004includes a client object of type ‘Area’2026that leads to a client role of type ‘ControlModules’2028, a client role of type ‘PhaseLogicModules’2030, and a client role of type ‘EquipmentModules’2032. The client role ‘ControlModules’2028leads to a client object of type ‘Control Module’2034. The client role ‘PhaseLogicModules’2030leads to a client object of type ‘Phase Logic Module’2036. The client role ‘EquipmentModule’2032leads to a client object of type ‘Equipment Module’2038.

FIG. 21depicts example XML source code2100that may be used to generate the role mappings from the server schema hierarchy2002to the client schema hierarchy2004ofFIG. 20. As shown in the XML source code2100, the client role ‘ControlModules’2028is mapped to the server role ‘Modules’2006(line2102). Also, the client role ‘PhaseLogicModules’2030is mapped to the server role ‘Modules’2006(line2104). Additionally, the client role ‘EquipmentModules’2032is mapped to the server role ‘Modules’2006(line2106).

FIG. 22depicts an example user interface2200that may be used to selectively display items associated with a control device. For example, the user interface2200shows a ‘CH01’ control device2202and displays only one property, a property ‘CTLR1C01CH01’2204, associated with the ‘CH01’ control device2202even though the ‘CH01’ control device2202is associated with at least two properties in a server schema (e.g., the server schema hierarchy2302ofFIG. 23). As described in greater detail below, a client schema (e.g., the client schema hierarchy2304ofFIG. 23) may be mapped to a subset of server objects in a server schema (e.g., the server schema hierarchy2302) so that a client application (e.g., the client application108ofFIG. 1) displays only that subset of objects as shown in the user interface2200.

FIG. 23is a detailed block diagram depicting a mapping configuration2300between a server schema hierarchy2302and a client schema hierarchy2304that maps a client object to a subset of server objects to generate the example user interface2200ofFIG. 22. A client model hierarchy2306includes a real object of type ‘CTLRC01CH01’2308that corresponds to the property ‘CTLR1C01CH01’2204ofFIG. 22. The server schema hierarchy2302includes a server object of type ‘Device’2310and a server object of type ‘DST’2312. The client schema hierarchy2304includes a client object of type ‘DST’2314. As indicated in example XML source code2400ofFIG. 24, the client object ‘DST’2314is mapped to the server object ‘DST’2312(line2402). The client object ‘DST’2314is mapped to the server object ‘DST’2312via the real object ‘CTLRC01CH01’2308and a mask ‘CTLR1C01CH01’2316.

FIG. 25depicts an example user interface2500that may be used to insert additional items into a control device view even though the additional items are not part of a server schema for that control device. The user interface2500includes a ‘CTLR1’ control device2502that is shown as having an ‘Assigned Modules’ item2504and a ‘TIC-205’ item2506. As described below in connection withFIG. 26, a server schema (e.g., the server schema2602ofFIG. 26) does not include a server object that corresponds to the ‘Assigned Modules’ item2504. Instead, a client object corresponding to the ‘Assigned Modules’ item2504is inserted into a client schema (e.g., the client schema2604ofFIG. 26).

FIG. 26is a detailed block diagram depicting a mapping configuration2600between a server schema hierarchy2602and a client schema hierarchy2604that inserts a client object into the client schema hierarchy2602. Each of the server schema hierarchy2602and a client model hierarchy2606includes a single object. Specifically, the server schema hierarchy2602includes a server object of type ‘Module’2608and the client model hierarchy2606includes a real object of type ‘TIC-201’2610that corresponds to the server object ‘Module’2608and the ‘TIC-205’ item2506(FIG. 25). The client schema hierarchy2604includes a client object ‘Module’2612that corresponds to the server and client model objects2608and2610. In addition, a client application (e.g., the client application108ofFIG. 1) has inserted a client object of type ‘AssignedModules’2614.

FIG. 27depicts example XML source code2700for inserting the client object ‘AssignedModules’2614(FIG. 26) into the client schema hierarchy2604(FIG. 26). Specifically, to create the client object ‘Assigned Modules’2614, the example XML source code2700specifies that a client role of type ‘AssignedModules’2616(FIG. 26) has no server schema mapping (e.g., Role name=‘AssignedModules’ mapping=‘ ’) and that the client role ‘AssignedModules’2616leads to the client object ‘AssignedModules’2614(line2702). To insert the client object ‘AssignedModules’2614into the client schema hierarchy2604, the example XML source code2700specifies that the client object ‘AssignedModules’2614is pseudo mapped to a server object of type ‘Controller’2618(e.g., a parent object of the server schema hierarchy2602) (line2704). The client object ‘AssignedModules’2614contains a client role of type ‘Modules’2620(FIG. 26) that is mapped to a server role of type ‘AssignedModules’2622(FIG. 26) (line2706).

FIG. 28depicts an example user interface2800that may be used to display items for which real-time process control data can be obtained via a command. The user interface2800includes a fieldbus port ‘P01’2802that contains control devices from which real-time process control data can be obtained via the runtime server114(FIG. 1). Specifically, the fieldbus port ‘P01’2802contains ‘Decomissioned Fieldbus Devices’2804, which includes a control device ‘D1’2806. The control device ‘D1’2806is implemented in a client schema (e.g., the client schema hierarchy2902ofFIG. 29) as a command as described below in connection withFIG. 29.

FIG. 29is a detailed block diagram depicting a mapping configuration that implements a client role as a command. A client schema hierarchy2902includes a client role of type ‘Devices’2904that is implemented as a command. The client role ‘Devices’2904may be used to obtain real-time process control data from the runtime server114ofFIG. 1. Example XML source code3000ofFIG. 30specifies that a client of object type ‘DecommissionedDevices’2906(FIG. 29) (line30ofFIG. 30) contains the client role ‘Devices’2904(FIG. 29). The example XML source code3000also specifies that the client role ‘Devices’2904is implemented using command instructions stored in a file ‘commands.dll’ (e.g., assembly=‘commands.dll’) and that the specific command that implements the client role ‘Devices’2904is ‘GetDecomissionedDevices’ (line3004). The client role ‘Devices’2904leads to a client object of type ‘FieldbusDevices’2908(FIG. 29) (line3004ofFIG. 30), which has no mapping into a server schema hierarchy2910(FIG. 29) (line2006ofFIG. 30).

FIGS. 31A,31B, and32illustrate flowcharts representative of example machine readable and executable instructions for implementing the example client application108, the example client model116, and the example user interface118ofFIGS. 1 and 2. In these examples, the machine readable instructions comprise a program for execution by a processor such as the processor3312shown in the example processor system3310ofFIG. 33. The program may be embodied in software stored on a tangible medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or a memory associated with the processor3312and/or embodied in firmware or dedicated hardware in a well-known manner. For example, any or all of structures within the example client application108, the example client model116, and the example user interface118ofFIGS. 1 and 2could be implemented by software, hardware, and/or firmware. Further, although the example program is described with reference to the flowcharts illustrated inFIGS. 31A,31B, and32, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example client application108, the example client model116, and the example user interface118ofFIGS. 1 and 2may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

FIGS. 31A and 31Bdepict flow diagrams of example methods that may be used to provide a client application (e.g., the client application108ofFIG. 1) access to real objects (e.g., the real objects216ofFIGS. 2,7, and8) via client objects (e.g., the client objects212ofFIGS. 2,7, and8) during a runtime phase. Initially, the client application108references first and second UI views (e.g., the first and second UI views702and704ofFIG. 7) (block3102). The first UI view702then requests access to a real parent object (e.g., the parent real object ‘R’708aofFIG. 7) via a parent client object (e.g., the parent client object ‘O’710aofFIG. 7) and corresponding parent object handle and mask (e.g., the parent object handle ‘H’712aand the zeroth mask ‘M’714aofFIG. 7) (block3104). For example, the first UI view702can issue a call to use the parent client object ‘O’710a. The parent client object ‘O’710acan then respond by referencing the parent object handle ‘H’712a, which in turn references the zeroth mask ‘M’714a. The mask reference ‘M’714athen references the parent real object ‘R’708aand a communication path is established between the first UI view702and the parent real object ‘R’708aas shown inFIG. 7.

The first UI view702then causes the parent real object ‘R’708ato load a real role (e.g., the ‘ModuleLibrary’ real role708bofFIG. 7) (block3106). For example, the first UI view702calls a load role on the parent client object ‘O’710aand passes the role name ‘ModuleLibrary’. The parent client object ‘O’710athen fetches the real role from the parent object handle ‘H’712aand the parent object handle ‘H’712acauses the zeroth mask ‘M’714ato load the ‘ModuleLibrary’ real role708b.

The parent real object ‘R’708athen loads the first and second real objects708cand708dunder the ‘ModuleLibrary’ real role708b(block3108). The zeroth mask ‘M’714athen creates masks (e.g., the first and second masks714aand714bofFIG. 7) for the first and second real objects708cand708dand returns the masks to the parent object handle ‘H’712a(block3110). The parent object handle ‘H’712athen creates object handles (e.g., the second object handles712band712cofFIG. 7) for the first and second masks714band714cand returns the object handles to the parent client object ‘O’710a(block3112).

The parent client object ‘O’710athen instantiates the first and second child client objects710band710c(FIG. 7) and references each of the child client objects710a-bto a corresponding object handle (block3114). Specifically, the first child client object710bis referenced to the first object handle712band the second child client object710cis referenced to the second object handle712c. The first UI view702then references the first and second child client objects710band710c(block3116), which forms a communication path between the first UI view702and the first and second real objects708cand708das shown inFIG. 7.

As shown inFIG. 31B, the second UI view then requests access to the first real object708c(block3118). The client model116then determines if the first and second views702and704share a client schema (e.g., one of the client schema hierarchiesFIGS. 14,17,20,23,26, and29) (block3120). If the UI views702and704do share a client schema, the first UI view702passes the first child client object710bto the second user view704(block3122). In this case, as shown inFIG. 7, a data path is established between the second UI view704and the first child client object710band the data path between the first UI view702and the first child client object710bis inactivated because the first UI view702no longer references the first child client object710b.

If the first and second UI views702and704do not share a client schema, the first UI view702passes to the second UI view704a server path corresponding to the first child client object710b(block3124). The second UI view704then passes the server path to the client model116and issues a request the client model116to look up an item on the server path (block3126). The client model116then creates a third mask804(FIG. 8) and a third object handle806(FIG. 8) that reference the first real object708c(block3128). The second UI view704then receives from the client model116the third object handle804(FIG. 8) (block3130). The second UI view704then instantiates the third child client object804(FIG. 8) (block3132). The third child client object804then references the third object handle804(block3134). A communication path is then formed between the second UI view704and the first real object708cas shown inFIG. 8. When the first UI view702is finished accessing the first real object708c, the client model indicates that the first child client object710b, the first object handle712b, and the first mask714bare unused or inactive and ready for garbage collection (block3136).

After the client model116indicates which client objects, handles, and masks are ready for garbage collection or after the first UI view702passes the first child client object710bto the second UI view704at block3122, the client model116determines if the first UI view704needs to access the first real object708cagain (block3138). If the first UI view704does need to access the first real object708cagain, then control is passed back to block3104(FIG. 31A) and the operations described above in connection with blocks3104through3116are repeated to establish a communication path between the first UI view702and the first real object708c. In this case, as shown inFIG. 7, a communication path from the first UI view702to the first real object708cis established via a second instance of the first client child object ‘O1′’710e, a second instance if the first object handle ‘H1′’712d, and a second instance of the first mask ‘M1′’714d. If the client model116determines at block3138that the first UI view702does not need to access the first real object708cagain, then the process is ended.

FIG. 32is an example method that may be used to update modified process control data in client objects (e.g., the client object902ofFIG. 9). Initially, the client model116(FIG. 1) obtains an update notification event (block3202). The client model116receives the update notification event from the process control system database server112and/or the process control system database110. For example, when stored process control data is modified in the process control system database110, the process control system database110issues an update notification event (e.g., an ‘UpdateNotification’ event) and a list of questionable real objects or dirty real objects (e.g., some of the real objects216ofFIGS. 2 and 7associated with process control data modified in the database110). In response to the ‘UpdateNotification’ event, the client model116identifies one or more questionable client objects (e.g., some of the client objects212ofFIGS. 2 and 7) corresponding to the questionable real objects provided to the client model110via the ‘UpdateNotification’ event (block3204). The client model116then communicates a list of questionable client objects to a client application (e.g., the client application108ofFIG. 1) (block3206) via, for example, a ‘QuestionableUpdateNotification’ event. The list of questionable client objects may include the handles or identifications of each of the questionable client objects.

The client application108then receives the list of questionable client objects from the client model116and populates a dirty hash table (e.g., the dirty hash table916ofFIG. 9) based on the list of questionable client objects (block3208). For example, pre-generated partial classes (e.g., the pre-generated partial classes206ofFIG. 2) of the client application108may include a method or event that monitors for the ‘QuestionableUpdateNotification’ event and the list of questionable client objects. The client application108then notifies any visible UI views (e.g., the UI views702and704ofFIG. 7or the UI view118ofFIG. 9) that an update notification event has been received (block3210). For example, to decrease the amount of time required to update process control data that is visible to a user, the client application108may not notify any UI views that are minimized on a user interface display. The visible UI views then determine if any of their client objects are dirty based on the dirty hash table916(block3212). For example, the client objects of the visible UI views determine if any of their handles or identifications correspond to the handles or identifications of the questionable client objects in the dirty hash table916.

The visible UI views then flag any used object handles that are in the dirty hash table916(block3214). For example, if the UI view118is still using the client object902and an object handle corresponding to the client object902is in the dirty hash table916, the object902flags its corresponding object handle in the dirty hash table916to indicate that the client object902is still ‘in use’ and is, thus, not ready for garbage collection. Any object handles in the dirty hash table916that are not flagged are designated or specified as inactive or unused and available for garbage collection. The client model116then removes or unloads all inactive or unused dirty object handles (block3216). For example, the client model116may use a garbage collection routine to remove or unload all dirty object handles that are listed in the dirty hash table916, but that are not flagged as being used or active.

The client model116then retrieves updated or modified process control data for the dirty object handles that are flagged as used in the dirty hash table916(block3218). For example, the client model116generates a query corresponding to the process control data of the ‘in use’ dirty objects and communicates the query to the process control system database server112(FIG. 1). The process control system database server112then retrieves the modified process control data from the process control system database110and returns the modified process control data to the client model116.

The client model116then converts the updated or modified process control data from a server schema to a client schema (block3220). For example, the client model116may use any of the mapping configurations described above in connection withFIGS. 14,17,20,23,26, and29to convert or map the modified process control data from the server schema (e.g., one of the server schemas hierarchies ofFIGS. 14,17,20,23,26, and29) to the client schemas (e.g., one of the client schema hierarchies ofFIGS. 14,17,20,23,26, and29).

The client model116then determines which process control data values that are currently loaded for the questionable client objects are different from the received modified process control data and communicates only the modified process control data that is different (e.g., data that has actually changed) to the client application (block3222). In this manner, the client model116does not have to communicate to the client application108any process control data that is indicated as modified but that in actuality has not changed from the process control data currently loaded in the client application108. The client application108then issues an update notification to client objects associated with used dirty object handles and for which modified process control data was received from the client model116(block3224). For example, the client application108may issue an update notification to the client object902(FIG. 9) and pass modified process control data associated with any of the PROPERTY_C element910c, the PROPERTY_D element910d, and the PROPERTY_E element910e(FIG. 9). Each client object then updates its data (block3226) based on the received modified process control data. For example, the client object902may update the values of the elements910c,910d, and910ebased on the received modified process control data.

FIG. 33is a block diagram of an example processor system that may be used to implement the example apparatus, methods, and articles of manufacture described herein. As shown inFIG. 33, the processor system3310includes a processor3312that is coupled to an interconnection bus3314. The processor3312includes a register set or register space3316, which is depicted inFIG. 33as being entirely on-chip, but which could alternatively be located entirely or partially off-chip and directly coupled to the processor3312via dedicated electrical connections and/or via the interconnection bus3314. The processor3312may be any suitable processor, processing unit or microprocessor. Although not shown inFIG. 33, the system3310may be a multi-processor system and, thus, may include one or more additional processors that are identical or similar to the processor3312and that are communicatively coupled to the interconnection bus3314.

The processor3312ofFIG. 33is coupled to a chipset3318, which includes a memory controller3320and an input/output (I/O) controller3322. As is well known, a chipset typically provides I/O and memory management functions as well as a plurality of general purpose and/or special purpose registers, timers, etc. that are accessible or used by one or more processors coupled to the chipset3318. The memory controller3320performs functions that enable the processor3312(or processors if there are multiple processors) to access a system memory3324and a mass storage memory3325.

The system memory3324may include any desired type of volatile and/or non-volatile memory such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. The mass storage memory3325may include any desired type of mass storage device including hard disk drives, optical drives, tape storage devices, etc.

The I/O controller3322performs functions that enable the processor3312to communicate with peripheral input/output (I/O) devices3326and3328and a network interface3330via an I/O bus3332. The I/O devices3326and3328may be any desired type of I/O device such as, for example, a keyboard, a video display or monitor, a mouse, etc. The network interface3330may be, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.11 device, a DSL modem, a cable modem, a cellular modem, etc. that enables the processor system3310to communicate with another processor system.

While the memory controller3320and the I/O controller3322are depicted inFIG. 33as separate functional blocks within the chipset3318, the functions performed by these blocks may be integrated within a single semiconductor circuit or may be implemented using two or more separate integrated circuits.

Although certain methods, apparatus, and articles of manufacture have been described herein, the scope of coverage of this patent is not limited thereto. To the contrary, this patent covers all methods, apparatus, and articles of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.