Object-oriented programmable controller

Abstract

An apparatus having a programmable processor and a memory for performing a plurality of user-selectable control functions includes a database for storing a plurality of items associated with each of the control functions. The items include, for each function, at least one procedure for performing an action associated with the control function and a specification of at least one state associated with the control function. The apparatus further includes software routines stored on the memory and adapted to be executed by the processor that facilitate selection of a procedure in the database, that access the database and cause performance of the selected procedure to achieve the state specified therein, and that monitor at least one resource associated with the action of the procedure and, based thereon, determine whether the specified state has been achieved.

Claims

What is claimed is:

1. A programmable apparatus for performing a plurality of user-selectable control functions, the apparatus comprising:

a. a database for storing a plurality of items associated with each of the control functions, the items including, for each function:

i. at least one procedure for performing a plurality of actions associated with the control function;

ii. a specification of at least one state associated with each procedure;

b. means facilitating selection of a procedure in the database;

c. means responsive to the selection for accessing the database and causing performance of the selected procedure to achieve the states specified therein; and

d. means for monitoring at least one resource associated with the actions of the procedure and, based thereon, determining whether the specified states have been achieved.

2. The apparatus of claim 1 wherein the performance means is responsive to executable instructions causing it to respond, in causing performance of the action, to the state determined by the monitoring means.

3. The apparatus of claim 1 wherein the items further include a list of resources associated with the action, the performance means being configured to establish control connections to the listed action resources to perform the action.

4. The apparatus of claim 1 wherein the items further include a list of resources associated with the state, the monitoring means being configured to establish monitoring connections to the listed state resources to determine the state.

5. The apparatus of claim 4 comprising:

a. an input/output module for connection to at least one input/output point on a controlled machine; and

b. a computer memory comprising a plurality of registers and flags for containing data associated associated with the action, the state resources including the at least one input/output point and the registers and flags.

6. The apparatus of claim 1 wherein the means facilitating selection and the means responsive to the selection comprise:

a. compiler;

b. a series of high-level instructions including instructions invoking the at least one procedure; and

c. a database manager, responsive to procedure-invoking instructions, for locating the at least one procedure;

the compiler compiling the high-level instructions and the procedure into a machine-executable run-time program.

7. The apparatus of claim 6, further comprising memory means for storing the run-time program.

8. The apparatus of claim 6, wherein the run-time program accesses, during execution, at least one state item by means of the database manager.

9. The apparatus of claim 6 wherein the items further include a template specifying at least one performance characteristic, the monitoring means evaluating the resource against the at least one performance characteristic during performance of the action, the run-time program accessing, during execution, at least one performance-characteristic item by means of the database manager.

10. The apparatus of claim 6 further comprising a programming interface for accepting the high-level instructions and the items, the programming interface communicating with the database manager so as to cause storage of the items in the database.

11. A programmable apparatus for performing a plurality of user-selectable control functions the apparatus comprising:

a. a database for storing a plurality of items associated with each of the control functions, the items including, for each function:

i. at least one procedure for performing an action associated with the control function;

ii. a specification of at least one state associated with the control function; and

iii. a template specifying at least one performance characteristic, the monitoring means evaluating the resource against the at least one performance characteristic during performance of the action;

b. means facilitating selection of an action in the database;

c. means responsive to the selection for accessing the database and causing performance of the selected action; and

d. means for monitoring a resource associated with the action and, based thereon, determining the state specified in the database.

12. The apparatus of claim 11, wherein:

a. the performance characteristic comprises a plurality of parameter limit value ranges; and

b. the template specifies a limit procedure associated with at one of the limit value ranges, the performance means causing performance of the limit procedure if the parameter value falls within the limit value range.

13. An apparatus having a programmable processor and a memory for performing a plurality of user-selectable control functions, the apparatus comprising:

a. a database for storing a plurality of items associated with each of the control functions, the items including, for each function:

i. at least one procedure for performing an action associated with the control function;

ii. a specification of at least one state associated with the control function;

b. a first software routine stored on the memory and adapted to be executed by the processor for facilitating selection of a procedure in the database;

c. a second software routine stored on the memory and adapted to be executed by the processor that responds to the selection for accessing the database and causing performance of the selected procedure to achieve the state specified therein; and

d. a third software routine stored on the memory and adapted to be executed by the processor for monitoring at least one resource associated with the action of the procedure and, based thereon, determining whether the specified state has been achieved.

14. The apparatus of claim 12 wherein the items further include historical parameter values associated with completions of the action or performances of the limit procedure.

15. The apparatus of claim 14 wherein the monitoring means is configured to dynamically update the historical parameter values upon completion of an action or performance of the limit procedure.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to process monitoring and control systems. More specifically, the present invention relates to programmable controllers for operating and monitoring processes and equipment.

2. Description of the Related Art

Present-day process control systems use instruments, control devices and communication systems to monitor and manipulate control elements, such as valves and switches, to maintain at selected target values one or more process variables, including temperature, pressure, flow and the like. The process variables are selected and controlled to achieve a desired process objective, such as attaining the safe and efficient operation of machines and equipment utilized in the process. Process control systems have widespread application in the automation of industrial processes such as, for example, the processes used in chemical, petroleum, and manufacturing industries.

Control of the process is often implemented using microprocessor-based controllers, computers or workstations which monitor the process by sending and receiving commands and data to hardware devices to control either a particular aspect of the process or the entire process as a whole. The specific process control functions that are implemented by software programs in these microprocessors, computers or workstations may be individually designed, modified, or changed through programming while requiring no modifications to the hardware. For example, an engineer might cause a program to be written to have the controller read a fluid level from a level sensor in a tank, compare the tank level with a predetermined desired level, and then open or close a feed valve based on whether the fluid level reading is lower or higher than the predetermined, desired level. The parameters are easily changed by displaying a selected view of the process and then by modifying the program using the selected view. The engineer typically changes parameters by displaying and modifying an engineer's view of the process.

In addition to executing control processes, software programs also monitor and display a view of the processes, providing feedback in the form of an operator's display or view regarding the status of particular processes. The monitoring software programs also signal an alarm when a problem occurs. Some programs display instructions or suggestions to an operator when a problem occurs. The operator who is responsible for the control process needs to view the process from his point of view. A display or console is typically provided as the interface between the microprocessor-based controller or computer performing the process control function and the operator and also between the programmer or engineer and the microprocessor-based controller or computer performing the process control function.

Systems that perform monitor, control, and feedback functions in process control environments are typically implemented by software written in high-level computer programming languages such as Basic, Fortran or C and executed on a computer or controller. These high-level languages, although effective for process control programming, are not usually used or understood by process engineers, maintenance engineers, control engineers, operators and supervisors. Higher level graphical display languages have been developed for such personnel, such as continuous function block and ladder logic. Thus, each of the engineers, maintenance personnel, operators, lab personnel and the like, require a graphical view of the elements of the process control system that enables them to view the system in terms relevant to their responsibilities.

For example, a process control program might be written in Fortran and require two inputs, calculate the average of the inputs and produce an output value equal to the average of the two inputs. This program could be termed the AVERAGE function and may be invoked and referenced through a graphical display for the control engineers. A typical graphical display may consist of a rectangular block having two inputs, one output, and a label designating the block as AVERAGE. A different program may be used to create a graphical representation of this same function for an operator to view the average value. Before the system is delivered to the customer, these software programs are placed into a library of predefined user selectable features and are identified by function blocks. A user may then invoke a function and select the predefined graphical representations to create different views for the operator, engineer, etc. by selecting one of a plurality of function blocks from the library for use in defining a process control solution rather than having to develop a completely new program in Fortran, for example.

A group of standardized functions, each designated by an associated function block, may be stored in a control library. A designer equipped with such a library can design process control solutions by interconnecting, on a computer display screen, various functions or elements selected with the function blocks to perform particular tasks. The microprocessor or computer associates each of the functions or elements defined by the function blocks with predefined templates stored in the library and relates each of the program functions or elements to each other according to the interconnections desired by the designer. Ideally, a designer can design an entire process control program using graphical views of predefined functions without ever writing one line of code in Fortran or other high-level programming language.

One problem associated with the use of graphical views for process control programming is that existing systems allow only the equipment manufacturer, not a user of this equipment, to create his own control functions, along with associated graphical views, or modify the predefined functions within the provided library. New process control functions are designed primarily by companies that sell design systems and not by the end users who may have a particular need for a function that is not a part of the standard set of functions supplied by the company. The standardized functions are contained within a control library furnished with the system to the end user. The end user must either utilize existing functions supplied with the design environment or rely on the company supplying the design environment to develop any desired particular customized function for them. If the designer is asked to modify the parameters of the engineer's view, then all other views using those parameters have to be rewritten and modified accordingly because the function program and view programs are often developed independently and are not part of an integrated development environment. Clearly, a such procedure is very cumbersome, expensive, and time-consuming.

Another problem with existing process control systems is a usage of centralized control, typically employing a central controller in a network, executing a program code that is customized for specialized user-defined control tasks. As a result, the process control systems are typically constrained to a particular size and difficult to adapt over time to arising needs. Similarly, conventional process control systems are inflexible in configuration, often requiring a complete software revision for the entire system when new devices are incorporated. Furthermore, the conventional process control systems tend to be expensive and usually perform on the functions initially identified by a user or a system designer that are only altered or reprogrammed to perform new functions by an expert who is familiar with the entire control system configuration and programming.

What is needed is a uniform or universal design environment that can easily be used, not only by a designer or manufacturer but also a user, to customize an existing solution to meet his specific needs for developing process control functions. What is further needed is a personal computer-based process control system that is easily implemented within substantially any size process and which is updated by users, without the aid of the control system designer, to perform new and different control functions.

SUMMARY OF THE INVENTION

In accordance with one aspect of the invention, an apparatus having a programmable processor and a memory for performing a plurality of user-selectable control functions includes a database for storing a plurality of items associated with each of the control functions. The items may include, for each function, at least one procedure for performing an action associated with the control function and may further include a specification of at least one state associated with the control function. The apparatus may additionally include a first software routine stored on the memory and adapted to be executed by the processor for facilitating selection of a procedure in the database, a second software routine stored on the memory and adapted to be executed by the processor that responds to the selection for accessing the database and causing performance of the selected procedure to achieve the state specified therein, and a third software routine stored on the memory and adapted to be executed by the processor for monitoring at least one resource associated with the action of the procedure and, based thereon, determining whether the specified state has been achieved.

BRIEF DESCRIPTION OF THE DRAWINGS

The features of the invention believed to be novel are specifically set forth in the appended claims. However, the invention itself, both as to its structure and method of operation, may best be understood by referring to the following description and accompanying drawings.

FIG. 1 is a diagrammatic view of a process control system;

FIG. 2 is a schematic block diagram illustrating in greater detail a portion of the process control system of FIG. 1;

FIG. 3 is a schematic block diagram illustrating a workstation that provides the capability to create a new control template and the capability to modify an existing control;

FIG. 4 is a schematic block diagram illustrating the process control environment in a configuration implementation and a run-time implementation;

FIG. 5 is a block diagram illustrating a user interface that may be used with both configuration and run-time models of the process control environment of FIG. 4;

FIG. 6 is a block diagram depicting a hierarchical relationship among system objects of a configuration model;

FIG. 7 is a block diagram depicting a configuration architecture that operates within the hierarchical relationship illustrated in FIG. 6;

FIG. 8 is a block diagram illustrating an example of an elemental function block;

FIG. 9 is a block diagram illustrating an example of a composite function block;

FIG. 10 is a block diagram illustrating an example of a control module;

FIG. 11 is a block diagram illustrating a control module instance created in accordance with the control module depicted in FIG. 10;

FIG. 12 is a flow diagram depicting an example of execution of a control module at run-time;

FIG. 13 is a flow diagram depicting an example of a module at a highest layer of a control structure;

FIG. 14 is a block diagram depicting an object-oriented method for installing a process input/output (I/O) attribute block into a process input/output PIO device;

FIG. 15 is a block diagram depicting an object-oriented method for linking a control module input attribute to a PIO attribute;

FIG. 16 is a block diagram depicting an object-oriented method for linking a control module output attribute to a PIO attribute;

FIG. 17 is a block diagram depicting an object-oriented method for reading values of contained PIO attributes;

FIG. 18 is a block diagram illustrating an organization of information for an instrument signal tag;

FIG. 19 is a flow diagram illustrating a method for bootstrap loading a control system throughout a network in a process control environment;

FIG. 20 is an object communication diagram illustrating a technique for creating a device connection for an active, originating side of the connection;

FIG. 21 is an object communication diagram illustrating a technique for creating a device connection for a passive, listening side of the connection;

FIG. 22 is an object communication diagram illustrating a technique for sending request/response messages between devices;

FIG. 23 is an object communication diagram illustrating a technique for downloading a network configuration;

FIG. 24 is a screen presentation of a control studio object system;

FIGS. 25A-25F are screen presentations representing the illustration of a completed process control diagram to a node of a process control environment;

FIG. 26 is a block diagram illustrating the class hierarchy of control studio object system diagram view classes;

FIG. 27 is a block diagram illustrating the class hierarchy of control studio object system stencil classes;

FIGS. 28A and 28B illustrate a block diagram of the class hierarchy of control studio object lightweight classes that descend from class CObject;

FIG. 29 is a block diagram illustrating the class hierarchy of control studio object system connection classes that descend from class CObject;

FIG. 30 is a block diagram illustrating the class hierarchy of a diagram portion of the control studio object system drag and drop classes;

FIG. 31 is a block diagram illustrating the class hierarchy of control studio object system native drag and drop object classes;

FIGS. 32A-32E are flow diagrams illustrating a stencil drag and drop operation of a control studio object system;

FIGS. 33A-33D are flow diagrams illustrating a native drag and drop to a diagram portion of a control studio object system;

FIGS. 34A-34D are flow diagrams illustrating native cut, copy and paste operations in a diagram portion of a control studio object system; and

FIG. 35 is a flow diagram illustrating the operation of installing a diagram to a node.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to FIG. 1, a control system 1 is shown. In general, the system 1 includes a main processing device, such as personal computer 2, that is connected to a local area network (LAN) 3 via a local area network card. Although any local area network protocol may be used, a non-proprietary ethernet protocol is beneficial in many applications because it allows for communications with the local area network 3. The local area network 3 is dedicated to carrying control parameters, control data and other relevant information within the process control system 1. As such, the LAN 3 may be referred to as an area controlled network (ACN) 3. The ACN 3 may be connected to other LANs for sharing information and data via a hub or gateway without affecting the dedicated nature of ACN 3. In accordance with standard ethernet protocol, a plurality of physical devices may be connected to the ACN 3 at various "nodes." Each physical device connected to the ACN 3 is connected at a node and each node is separately addressable according the LAN protocol used to implement ACN 3.

To establish a redundant system, it may be desirable to construct the ACN 3 from two or more ethernet systems so that the failure of a single ethernet or LAN system will not result in the failure of the entire system. When such redundant ethernets are used, the failure of one ethernet LAN can be detected and an alternate ethernet LAN can be mapped in to provide for the desired functionality of the ACN 3.

The main personal computer 2 (PC) forms a node on the ACN 3. The PC 2 may, for example, be a standard personal computer running a standard operating system such as Microsoft's Window NT system. The PC 2 is configured to generate, in response to user input commands, various control routines that are provided via the ACN 3 to one or more local controllers identified as elements 4 and 5, which implement the control strategy defined by the control routines selected and established in the PC 2. The PC 2 may also be configured to implement direct control routines on field devices such as pumps, valves, motors and the like via transmission across the ACN 3, rather than through local controllers 4 and 5.

Local controllers 4 and 5 receive control routines and other configuration data through the ACN 3 from the PC 2. The local controllers 4 and 5 then send signals of various types to various field devices (such as pumps, motors, regulator valves, etc.) 6 through 15, which implement and perform physical steps in the field to implement the control system established by the routines provided by the PC 2.

Two types of field devices may be connected to local controllers 4 and 5, including field devices 6 through 10 which are responsive to specific control protocol such as Fieldbus, Profibus and the like. As those in the art will appreciate, there are standard control protocols (e.g., Fieldbus) according to which specific protocol instructions are provided to protocol-friendly field devices (e.g., Fieldbus field devices) that will cause a controller located within the field device to implement a specific function corresponding to the protocol function. Accordingly, field devices 6 through 11 receive protocol specific (e.g., Fieldbus) control commands from either the local controllers 4 and 5 or the PC 2 to implement a field device specific function.

Also connected to local controllers 4 and 5 are non-protocol field devices 12 through 15, which are referred to as non-protocol devices because they do not include any local processing power and respond to direct control signals. Accordingly, field devices 12 through 15 are not capable of implementing functions that are defined by specific control protocols such as the Fieldbus control protocol.

Functionality is supplied to allow the non-protocol field devices 12 through 15 to operate as protocol-friendly (e.g., Fieldbus specific) devices 6 through 11. Additionally, this same functionality allows for the implementation of the protocol-specific control routines to be distributed between the local field devices 6 through 11, the local controllers 4 and 5 and the PC 2.

The distribution of protocol-specific control routines is illustrated in more detail in FIG. 2. FIG. 2 refers to one portion of the system shown in FIG. 1, specifically the PC 2, the ethernet 3, the local controller 4, a smart field device 6 and a non-smart field device 12, in greater detail.

The PC 2 includes program software routines for implementing standard functional routines of a standard control protocol such as the Fieldbus protocol. Accordingly, the PC 2 is programmed to receive Fieldbus commands and to implement all of the functional routines that a local field device having Fieldbus capabilities could implement. The ability and steps required to program the PC 2 to implement Fieldbus block functionality will be clearly apparent to one of ordinary skill in the art.

The local controller 4 is connected to the PC 2 by the ethernet 3. The local controller 4 includes a central processing unit connected to a random access memory, which provides control signals to configure the central processing unit to implement appropriate operational functions. A read only memory is connected to the random access memory and is programmed to include control routines that can configure the central processing unit to implement all of the functional routines of a standard control protocol such as Fieldbus. The PC 2 sends signals through the ethernet 3 to the local controller 4, which causes one, more or all of the programmer routines in the read only memory to be transferred to the random access memory to configure the CPU to implement one, more or all of the standard control protocol routines (such as the Fieldbus routines). The smart field device 6 includes a central processing unit that implements certain control functions, and if the smart field device 6 is, for example, a Fieldbus device, then the central processing unit associated with the smart field device 6 is capable of implementing all of the Fieldbus functionality requirements.

Because the local controller 4 has the ability to implement Fieldbus specific controls, the local controller 4 operates so that the non-protocol device 12 acts and is operated as a Fieldbus device. For example, if a control routine is running either in the PC 2 or on the CPU of the local controller 4, that control routine can implement and provide Fieldbus commands to the smart field device 6 and to the non-protocol device 12, which operate as a Fieldbus device. If the smart field device 6 is a Fieldbus device, then the smart field device 6 receives these commands and thereby implements the control functionality dictated by those commands. The non-protocol device 12, however, works in conjunction with the central processing unit of the local controller 4 to implement the Fieldbus requirements so that the local controller 4 in combination with the non-protocol field device 12 implements and operates Fieldbus commands.

In addition to allowing the non-protocol device 12 to act and operate as a Fieldbus device, the described aspect allows for the distribution of Fieldbus control routines throughout the system 1. For example, to the extent that a control routine initially requests the smart field device 6 to implement more than one Fieldbus control routine, the system 1 allows for control to be divided between the local controller 4 and the local controller 5 so that a portion of the Fieldbus control routines are implemented by local controller 5 and other Fieldbus routines are implemented by the use of the Fieldbus routines stored on local controller 4. The division of Fieldbus routine implementation may allow for more sophisticated and faster control and more efficient utilization of the overall processing power of the system 1. Still further, the fact that the PC 2 has the ability to implement Fieldbus control routines, the Fieldbus routines are further distributed between the local controller 4 and the PC 2. In this manner, the system 1 allows the PC 2 to implement one or all of the Fieldbus routines for a particular control algorithm. Still further, the system 1 allows for the implementation of Fieldbus controls within a non-Fieldbus device connected directly to the ethernet 3 through use of the Fieldbus control routines stored on the PC 2 in the same manner that Fieldbus routines are implemented within the non-Fieldbus device 12 through use on the Fieldbus routines stored on the local controller 4.

FIG. 3 illustrates a process control environment 100 for implementing a digital control system, process controller or the like. The process control environment 100 includes an operator workstation 102 and an engineering workstation 106 electrically interconnected by a local area network (LAN) 108, or other known communication link, that transfers and receives data and control signals among the various workstations, and a plurality of controller/multiplexers 110. The workstations 102 and 106 are, for example, computers that conform to the IBM compatible architecture and are shown connected by the LAN 108 to a plurality of the controller/multiplexers 110, which electrically interface between the workstations 102 and 106 and a plurality of processes 112. The LAN 108 may include a single workstation connected directly to a controller/multiplexer 110 or, alternatively, may include a plurality of workstations, for example the two workstations 102 and 106, and many controller/multiplexers 110 depending upon the purposes and requirements of the process control environment 100. In some embodiments, a single process controller/multiplexer 110 controls several different processes 112 or, alternatively, may control a portion of a single process.

In the process control environment 100, a process control strategy is developed by creating a software control solution on the engineering workstation 106, for example, and transferring the solution via the LAN 108 to the operator workstation 102, lab workstation 104, and to the controller/multiplexer 110 for execution. The operator workstation 102 supplies interface displays to the control/monitor strategy implemented within the controller/multiplexer 110 and communicates to one or more of the controller/multiplexers 110 to view the processes 112 and to change control attribute values according to the requirements of the designed solution. The processes 112 are formed from one or more field devices, which may be smart field devices or conventional (non-smart) field devices. In addition, the operator workstation 102 communicates visual and audio feedback to the operator regarding the status and conditions of the controlled processes 112.

The engineering workstation 106 includes a processor 116, a display 115, and one or more input/output or user-interface device 118 such as a keyboard, light pen and the like. The engineering workstation 106 also includes a memory 117, which includes both volatile and non-volatile memory. The memory 117 includes a control program that executes on the processor 116 to implement control operations and functions of the process control environment 100 and also includes a control template system 120 and a control studio object system 130. The operator workstation 102, and other workstations (not shown) within the process control environment 100, include at least one central processing unit (not shown) which is electrically connected to a display (not shown) and a user-interface device (not shown) to allow interaction between a user and the processor.

The process control environment 100 also includes a template generator 124 and a control template library 123 which, in combination, form the control template system 120. A control template is defined as a grouping of attribute functions that are used to control a process and the methodology used for a particular process control function.

The control template system 120 includes the control template library 123, which communicates with the template generator 124 and which contains data representing sets of predefined or existing control template functions for use in process control programs. The control template functions are the templates that generally come with the system from the system designer to the user. The template generator 124 is an interface that advantageously allows a user to create new control template functions or modify existing control template functions. The created and modified template functions are selectively stored in the control template library 123.

The template generator 124 includes an attributes and methods language generator 126 and a graphics generator 128. The attributes and methods language generator 126 supplies display screens that allow the user to define a plurality of attribute functions associated with the creation of a new control template function or modification of a particular existing control template function, such as inputs, outputs, and other attributes, as well as providing display screens for enabling the user to select methods or programs that perform the new or modified function for the particular control template. The graphics generator 128 furnishes a user capability to design graphical views to be associated with particular control templates. A user utilizes the data stored by the attributes and methods language generator 126 and the graphics generator 128 to completely define the attributes, methods, and graphical views for a control template. The data representing the created control template function is generally stored in the control template library 123 and is subsequently available for selection and usage by an engineer for the design of process control solutions.

The control studio object system 130 provides a user friendly interface that allows a user to create, modify, use, and delete basic building blocks of a diagram, called stencil items, palette items or templates. The control studio object system 130 may be understood by a user who has no previous experience in manipulating the basic building blocks of the template generator 124. The control studio object system 130 and, specifically, the stencil portion of the control studio object system 130 interacts with the template generator 120.

The process control environment 100 is implemented using an object-oriented framework. An object-oriented framework uses object-oriented concepts such as class hierarchies, object states and object behavior. These concepts, which are discussed below, are well known in the art. The present object-oriented framework is written using the object-oriented C++ programming language, which is also well-known in the art.

The building block of an object-oriented framework is an object. An object is defined by a state and a behavior. The state of an object is set forth by fields of the object and the behavior of an object is set forth by methods of the object. Each object is an instance of a class, which provides a template for the object. A class defines zero or more fields and zero or more methods.

Fields are data structures that contain information defining object data or a portion of the state of an object. Objects that are instances of the same class have the same fields. However, the particular information contained within the fields of the objects can vary from object to object. Each field can contain information that is direct, such as an integer value, or indirect, such as a reference to another object.

A method is a collection of computer instructions which can be executed in the processor 116 by computer system software. The instructions of a method are executed, i.e., the method is performed, when software requests that the object for which the method is defined perform the method. A method can be performed by any object that is a member of the class that includes the method. The particular object performing the method is the responder or the responding object. When performing the method, the responder consumes one or more arguments, i.e., input data, and produces zero or one result, i.e., an object returned as output data. The methods for a particular object define the behavior of that object.

Classes of an object-oriented framework are organized in a class hierarchy. In a class hierarchy, a class inherits the fields and methods that are defined by the superclasses of that class. Additionally, the fields and methods defined by a class are inherited by any subclasses of the class. That is, an instance of a subclass includes the fields defined by the superclass and can perform the methods defined by the superclass. Accordingly, when a method of an object is called, the method that is accessed may be defined in the class of which the object is a member or in any one of the superclasses of the class of which the object is a member. When a method of an object is called, process control environment 100 selects the method to run by examining the class of the object and, if necessary, any superclasses of the object.

A subclass may override or supersede a method definition which is inherited from a superclass to enhance or change the behavior of the subclass. However, a subclass may not supersede the signature of the method. The signature of a method includes the method's identifier, the number and type of arguments, whether a result is returned and, if so, the type of the result. The subclass supersedes an inherited method definition by redefining the computer instructions which are carried out in performance of the method.

Classes which are capable of having instances are concrete classes. Classes which cannot have instances are abstract classes. Abstract classes may define fields and methods which are inherited by subclasses of the abstract classes. The subclasses of an abstract class may be other abstract classes; however, ultimately, within the class hierarchy, the subclasses are concrete classes.

All classes disclosed herein, except for mix-in classes which are described below, are subclasses of a class, Object. Thus, each class that is described herein and which is not a mix-in class inherits the methods and fields of class Object, which is a base class within the Microsoft Foundation class framework.

The process control environment 100 exists in a configuration model or configuration implementation 210 and a run-time model or run-time implementation 220 shown in FIG. 4. In the configuration implementation 210, the component devices, objects, interconnections and interrelationships within the process control environment 100 are defined. In the run-time implementation 220, operations of the various component devices, objects, interconnections and interrelationships are performed. The configuration implementation 210 and the run-time implementation 220 are interconnected through an ASCII based download language. The download language creates system objects according to definitions supplied by a user and creates instances (described in detail below) from the supplied definitions.

Specifically, a completely configured device table relating to each device is downloaded to all Workstations on startup and when the device table is changed. Device Tables are elements of the configuration database that are local to devices and, in combination, define part of the configuration implementation 210. A device table contains information associated with a device within the process control environment 100. Information items in a device table include a device ID, a device name, a device type, a process control network (PCN) network number, an area control network (ACN) segment number, a simplex/redundant communication flag, a controller media access control (MAC) address, a comment field, a primary internet protocol (IP) address, a primary subnet mask, a secondary IP address and a secondary subnet mask.

For controller/multiplexers 110, a downloaded device table only includes data for devices for which the controller/multiplexer 110 is to initiate communications based on remote module data configured and used in the specific controller/multiplexer 10. The device table is downloaded to the controller/multiplexer 110 when other configuration data is downloaded. In addition to downloading definitions, the download language also uploads instances and instance values. The configuration implementation 210 is activated to execute in the run-time implementation 220 using an installation procedure.

The process control environment 100 includes multiple subsystems with several of the subsystems having both a configuration and a run-time implementation. For example, a process graphic subsystem 230 supplies user-defined views and operator interfacing to the architecture of the process control environment 100. The process graphic subsystem 230 has a process graphic editor 232, a part of the configuration implementation 210, a process graphic viewer 234, and a portion of the run-time implementation 220. The process graphic editor 232 is connected to the process graphic viewer 234 by an intersubsystem interface 236 in the download language. The process control environment 100 also includes a control subsystem 240, which configures and installs control modules and equipment modules in a definition and module editor 242 and which executes the control modules and the equipment modules in a run-time controller 244. The definition and module editor 242 operates within the configuration implementation 210 and the run-time controller 244 operates within the run-time implementation 220 to supply continuous and sequencing control functions. The definition and module editor 242 is connected to the run-time controller 244 by an intersubsystem interface 246 in the download language. The multiple subsystems within the process control environment 100 are interconnected by a subsystem interface 250.

The configuration implementation 210 and the run-time implementation 220 interface to a master database 260 to support access to common data structures. Various local (non-master) databases 262 interface to the master database 260, for example, to transfer configuration data from the master database 260 to the local databases 262 as directed by a user. Part of the master database 260 is a persistent database 270 which is an object that transcends time so that the database continues to exist after the creator of the database no longer exists and transcends space so that the database is removable to an address space that is different from the address space at which the database was created. The entire configuration implementation 210 is stored in the persistent database 270. The master database 260 and the local databases 262 are accessible so that documentation of configurations, statistics and diagnostics are available for documentation purposes.

The run-time implementation 220 interfaces to the persistent database 270 and the local databases 262 to access data structures formed by the configuration implementation 210. In particular, the run-time implementation 220 fetches selected equipment modules, displays and the like from the local databases 262 and the persistent database 270. The run-time implementation 220 interfaces to other subsystems to install definitions, thereby installing objects that are used to create instances when the definitions do not yet exist, instantiating run-time instances, and transferring information from various source to destination objects.

Referring to FIG. 5, a block diagram illustrates a user interface 300 that may be used with both the configuration and run-time models of the process control environment 100. Part of the user interface 300 is the Explorer.TM. 310, which is an interfacing program defined under the Windows NT.TM. operating system and which features a device-based configuration approach. Another part of the user interface 306 is a module definition editor 320 for interfacing to the process control environment 100.

The Explorer.TM. 310 is operated by a user to select, construct and operate a configuration. In addition, the Explorer.TM. 310 supplies an initial state for navigating across various tools and processors in a network. A user controls the Explorer.TM. 310 to access libraries, areas, process control equipment and security operations. FIG. 5 illustrates the relationship between various tools that may be accessed by a task operating within the process control environment 100 and the relationship between components of the process control environment 100 such as libraries, areas, process control equipment and security. For example, when a user selects a "show tags" function from within an area, a "tag list builder" is displayed, showing a list of control and I/O flags. From the tag list builder, the user can use an "add tag" function to add a module to a list, thereby invoking a "module editor."

Referring to FIG. 6, a schematic block diagram illustrates a hierarchical relationship among system objects of a configuration model 400. The configuration model 400 includes many configuration aspects including control, I/O, process graphics, process equipment, alarms, history and events. The configuration model 400 also includes a device description and network topology layout.

The configuration model hierarchy 400 may be used by a particular set of users to visualize system object relationships and locations and to communicate or navigate maintenance information among various system objects. For example, one configuration model hierarchy 400, specifically a physical plant hierarchy, may be used by maintenance engineers and technicians to visualize physical plant relationships and locations and to communicate or navigate maintenance information among various instruments and equipment in a physical plant. An embodiment of a configuration model hierarchy 400 that forms a physical plant hierarchy supports a subset of the SP88 physical equipment standard hierarchy and includes a configuration model site 410, one or more physical plant areas 420, equipment modules 430 and control modules 440.

The configuration model hierarchy 400 is defined for a single process site 410, which is divided into one or more named physical plant areas 420 that are defined within the configuration model hierarchy 400. The physical plant areas 420 optionally contain tagged modules, each of which is uniquely instantiated within the configuration model hierarchy 400. A physical plant area 420 optionally contains one or more equipment modules 430 and each equipment module 430 optionally contains other equipment modules 430 control modules 440 and function blocks. An equipment module 430 includes and is controlled by a control template that is created according to one of a number of different graphical process control programming languages including continuous function block, ladder logic, or sequential function charting (SFC). The configuration model hierarchy 400 optionally contains one or more control modules 440. A control module 440 is contained in an object such as a physical plant area 420, an equipment module 430 or another control module 440. A control module 440 optionally contains objects such as other control modules 440 or function blocks.

The system objects that are implemented in the multiple hierarchical systems are arranged into a plurality of subsystems including control, process I/O, control system hardware, redundancy management, event/alarm management, history services, process graphics, diagnostics presentation, user environment, management organization and field management system (FMS) subsystems. The control subsystem includes routines for configuring, installing and executing control modules and equipment modules. The process I/O subsystem is a uniform interface to devices including HART (highway addressable remote transducer), Fieldbus, conventional I/O and other input/output systems. The control system hardware subsystem defines a control system topology, devices within the topology and capabilities and functions of the devices. The control system hardware subsystem also includes objects and data structures for accessing device level information indicative of status and diagnostics.

Referring to FIG. 7, a schematic block diagram shows a configuration architecture 500 that operates within the configuration model hierarchy 400 illustrated in FIG. 6. The configuration architecture 500 includes several objects and classes at multiple levels of abstraction. At an organizational level of abstraction 510, the configuration architecture 500 includes a site class 512 which contains "named" objects and classes within the configuration architecture 500; Named objects and classes are definitions, display components such as screens and graphics, and other items. The named objects and classes include function blocks, user accounts, modules, plant areas, events, libraries and other site-wide information. Examples of named items are block definitions, equipment module definitions, control module definitions, plant area names and the like.

At a primitive level of abstraction 520, the configuration architecture 500 includes primitives that define the interfaces to functions within the configuration architecture 500, including hard-coded functions such as "+." The primitive level of abstraction 520 includes the classes of functions 522 and parameters 524. The functions 522 are operational functions at the lowest level of abstraction in the configuration architecture 500 and are typically coded in the C or C++ languages. In one embodiment of the configuration architecture 500, the full set of implemented function blocks 522 are primitives. Objects and classes at the primitive level of abstraction 520 are defined throughout the site class 512. The parameters 524 are classes and objects at the lowest level of abstraction in the configuration architecture. The parameters 524 include integer numbers, real numbers, vectors, arrays and the like. Attribute values are mapped into the parameters 524 for usage within the function blocks 522. In one embodiment, the function blocks 522 at the primitive level of abstraction 520 include the function block primitives listed in TABLE 1, as follows:

                             TABLE I
                         Function Blocks
    Action           Handles simple assignment statements using a defined
                    expression capability
    ADD             Simple Add function with extensible inputs
    AI              FF Standard Analog Input
    AI Lite         A scaled back version of the FF analog input
    AI HART         The FF Standard Analog Input with some extra ability
                    to handle HART devices
    AND             Simple And function with extensible inputs
    AO              FF Standard Analog Output (From FF standard
                    specification)
    Arithmetic      FF Standard Arithmetic Block (From FF standard
                    specification)
    BDE_TRIGGER     Simple bi-directional edge trigger
    BIASGAIN        FF Standard Bias/Gain (From FF standard
                    specification)
    CALC/LOGIC      Advanced calculation and logic block that has its own
                    language as well as the ability to handle simple ST
                    (1131). It has extensible inputs, extensible outputs,
                    and the ability to create temporary variables
    Condition       Handles simple condition statements using a defined
                    expression capability
    Counter         Simple up/down counter that handles several different
                    Accumulation methods
    CTLSEL          FF Standard Control Selector (From FF standard
                    specification)
    DI              FF Standard Discrete Input (From FF standard
                    specification)
    DI Lite         A scaled back version of the FF discrete input
    DIVIDE          Simple Divide
    DO              FF Standard Discrete Output (From FF standard
                    specification)
    DT              FF Standard Deadtime with advanced control research
                    implemented (From FF standard specification)
    DtoI            A boolean fan in that converts up to 16 discrete inputs
                    to a 16-bit integer value and that has some special
                    abilities for capturing input patterns
    FILT            Simple filter
    H/L MON LIMIT   Simple high/low signal monitor and limiter
    INTEGRATOR      FF Standard Integrator block (From FF standard
                    specification)
    ItoD            Boolean fan-out that takes a 16-bit integer and
                    translates it into 16 discrete outputs
    L/L             FF Standard Lead-Lag with 2 additional types of
                    equations to select (From FF standard specification)
    LOOP            An I/O and control block with the abilities of AI, PID,
                    and AO rolled into one block
    LOOPD           An I/O and control block with the abilities of DI,
                    Device Control, and DO rolled into one block
    MAN             FF Standard Manual Loader (From FF standard
                    specification)
    MULTIPLEX       Simple multiplexor with extensible inputs
    MULTIPLY        Simple multiply with extensible inputs.
    NDE_TRIGGER     Simple negative edge trigger
    NOT             Simple not
    OFF_DELAY       Simple off-delay timer
    ON_DELAY        Simple on-delay timer
    OR              Simple logical or with extensible inputs
    P/PD            FF Standard P/PD (From FF standard specification)
    PDE_TRIGGER     Simple positive directional edge trigger
    PERIOD          Simple monitor that triggers when an input is true for
                    a specified period
    PI              FF Standard Pulse Input (From FF standard
                    specification)
    PID             FF Standard PID with many additions including the
                    ability to choose algorithm type, form, and structure
                    (From FF standard specification)
    RAMP            Simple ramp generator
    RATELIM         Simple rate limiter generator
    RATIO           FF Standard Ratio block (From FF standard
                    specification)
    RETENTIVE       Simple retentive timer
    RS              Simple reset dominant flip-flop
    RUNAVE          Simple running average calculator
    SCALER          Simple scaler
    SIGGEN          Generates square waves, sine waves, random waves,
                    or any combination of the three
    SIGNALCHAR      FF Standard Signal Characterizer (From FF standard
                    specification)
    SIGSEL          Simple signal selector
    SPLITTER        FF Standard Splitter (From FF standard specification)
    SR              Simple set dominant flip-flop
    SUBTRACT        Simple subtract block
    TP              Simple timed pulse block
    TRANSFER        Simple transfer block
    XOR             Simple exclusive or block