Methods and apparatus for object-based process control

Abstract

The provides improved control devices, systems and methods for operation thereof. These rely on control devices that provide virtual machine environments in which Java objects, or other such software constructs, are executed to implement control (e.g., to monitor and/or control a device, process or system). These objects define blocks which are the basic functional unit of the control. They also define the input, output and body parts from which blocks are formed, and the signals that are communicated between blocks. The objects also define nested and composite groupings of blocks used to control loops and higher-level control functions.

Claims

What is claimed is:

1. A control device comprising:

a virtual machine environment,

the virtual machine environment executing an object or other software construct (collectively, "object") that configures the control device to provide a control function,

the object communicating a datum with an entity that stores the datum, and

the object accessing the datum by reference to storage maintained in the entity.

2. The control device of claim 1, wherein

the virtual machine environment is a Java virtual machine, and

the object is a Java object.

3. The control device of claim 1, wherein the object accesses the datum via any of a pointer, an address, or a symbolic or other reference to storage maintained in the entity.

4. The control device of claim 3, wherein the object accesses the datum for purposes of any of getting or setting a value thereof.

5. The control device of claim 3, wherein the object does not maintain a copy of the datum.

6. The control device of any one of claims 1-5, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.

7. The control device of any one of claims 1-5, wherein the object configures the control device to provide any of sensing, actuation and other control functions.

8. The control device of any one of claims 1-5, wherein the object configures the control device to execute one or more control blocks.

9. The control device of claim 8, wherein one or more of the control blocks execute a control algorithm, provide input, and/or provide output.

10. The control device of any one of claims 1-5, wherein the device is any of a workstation, controller, control station, and a field device.

11. The control device of any one of claims 1-5 adapted for providing any of process, industrial, environmental or other control.

12. The control device of any one of claims 1-5, wherein the object comprises

one or more mandatory portions for which memory is allocated in the control device at the time of object creation,

and one or more optional parts for which memory space is allocated subsequent to object creation as needed.

13. The control device of any one of claims 1-5, comprising

a second object that executes in the virtual machine environment,

the object and the second object having input and output parts defined from subsets of a common set of input and output classes, respectively.

14. The control device of any one of claims 1-5, wherein the object configures the device to provide an analog input function with multiple inputs coupled to accept readings from multiple respective input devices and to generate an output based on one or more of those readings.

15. A control system comprising:

one or more control devices, each providing a virtual machine environment,

a plurality of objects executing in the one or more virtual machine environments,

the plurality of objects including a first object and a second object that communicate a datum with one another,

the first object maintaining a sole instance of the datum as between at least the first and second objects,

the second object accessing the datum by reference.

16. The control system of claim 15, wherein

the virtual machine environment maintained by the control devices is a Java virtual machine, and

the first object and the second object are Java objects.

17. The control system of claim 15, wherein the second object accesses the datum via any of a pointer, an address, or a symbolic or other reference to the instance of the datum maintained by the first object.

18. The control system of claim 17, wherein the second object accesses the datum for purposes of any of getting or setting a value thereof.

19. The control system of any one of claims 15-18, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.

20. The control system of any one of claims 15-18, wherein the first and second objects configure control devices on which they execute to provide any of sensing, actuation and other control functions.

21. The control system of any one of claims 15-18, wherein the first and second objects configure the one or more control devices on which they reside to execute control blocks.

22. The control system of claim 21, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.

23. The control system of any one of claims 15-18, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.

24. The control system of any one of claims 15-18 adapted for providing any of process, environmental or other control.

25. The control system of any one of claims 15-18, wherein at least one of the first and second object comprise

one or more mandatory portions for which memory is allocated in the control device at the time of object creation,

and one or more optional parts for which memory space is allocated subsequent to object creation as needed.

26. The control system of any one of claims 15-18, wherein the first and second objects have input and output parts defined from subsets of a common set of input and output classes, respectively.

27. The control system of any one of claims 15-18, wherein at least one of the first and second objects configures the device to provide an analog input function with multiple inputs coupled to accept readings from multiple respective input devices and to generate an output based on one or more of those readings.

28. A control system comprising:

one or more control devices, each providing a virtual machine environment,

a plurality of objects executing in the one or more virtual machine environments,

the plurality of objects including a first object and a second object between which a connection is established to communicate with one another one or more data contained in a data structure,

the first object maintaining a sole instance of the data structure and data contained therein as between at least the first and second objects,

the second object accessing data in the data structure by reference.

29. The control system of claim 28, wherein the data structure comprises a unidirectional variable able having

a measurement, a setpoint or other value, and

any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.

30. The control system of claim 29, wherein

the virtual machine environment maintained by the control devices is a Java virtual machine, and

the first object and the second objects are Java objects.

31. The control system of claim 29, wherein the second object accesses data in the data structure via any of a pointer, an address, or a symbolic or other reference to the instance of the data structure maintained by the first object.

32. The control system of claim 29, wherein the second object accesses the data structure for purposes of any of getting or setting a datum thereof.

33. The control system of claim 28, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.

34. The control system of claim 28, wherein the first and second objects configure control devices on which they execute to provide any of sensing, actuation and other control functions.

35. The control system of claim 28, wherein the first and second objects configure the one or more control devices on which they reside to execute control blocks.

36. The control system of claim 33, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.

37. The control system of claim 28, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.

38. The control system of claim 28 adapted for providing any of process, environmental or other control.

39. The control system of any one of claims 28-38, wherein the data structure comprises a bi-directional variable having

a forward-going measurement, setpoint or other value (collectively, "forward-going value"),

any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,

a back-going measurement, setpoint or other value (collectively, "back-going value"), and

any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).

40. A control system comprising:

one or more control devices, each providing a virtual machine environment,

a plurality of objects executing in the one or more virtual machine environments,

the plurality of objects including a first object that communicates a datum with a second object and a third object,

the first object maintaining a sole instance of the datum as between at least the first, second and third objects,

the second and third objects accessing the datum by reference.

41. A control system comprising:

one or more control devices, each providing a virtual machine environment,

a plurality of objects executing in the one or more virtual machine environments,

the plurality of objects including a first object with which connections are established by a second object and by a third object, each connection being for the transfer of data contained in a data structure,

the first object maintaining a sole instance of the data structure and data contained therein as between at least the first, second and third objects,

the second and third objects accessing data in the data structure by reference.

42. The control system of any one of claims 40-41, wherein the data structure comprises a bi-directional variable having

a forward-going measurement, setpoint or other value (collectively, "forward-going value"),

any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,

a back-going measurement, setpoint or other value (collectively, "back-going value"), and

any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).

43. A method of operating a control device comprising:

executing an object or other software construct (collectively, "object") on a virtual machine environment provided in the control device, the object configuring the control device to provide a control function,

communicating a datum between the object and an entity that stores the datum, the object accessing the datum by reference to storage maintained in the entity.

44. The method of claim 43, wherein the virtual machine environment is a Java virtual machine, and wherein the object is a Java object.

45. The method of claim 43, composing accessing the datum from the object via any of a pointer, an address, or a symbolic or other reference to storage maintained in the entity.

46. The method of claim 45, comprising accessing the datum for purposes of any of getting or setting a value thereof.

47. The method of claim 45, wherein the object does not maintain a copy of the datum.

48. The method of any one of claims 43-47, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.

49. The method of any one of claims 43-47, comprising executing the object to configure the control device to provide any of sensing, actuation and other control functions.

50. The method of any one of claims 43-47, wherein the executing step includes executing one or more control blocks associated with the object.

51. The method of claim 50, wherein one or more of the control blocks comprises a control algorithm, an input function, and/or an output function.

52. The method of any one of claims 43-47, wherein the device is any of a workstation, controller, control station, and a field device.

53. The method of any one of claims 43-47 adapted for providing any of process, industrial, environmental or other control.

54. A method of operating a control system comprising:

executing a plurality of objects in virtual machine environments provided on one or more control devices, the objects configuring the one or more devices to provide control functions,

communicating a datum between first and second ones of the plurality of objects,

maintaining in the first object a sole instance of the datum, as between at least the first and second objects, and

accessing by reference the datum with the second object.

55. The method of claim 54, wherein the virtual machine environment is a Java virtual machine, and the plurality of objects are Java objects.

56. The method of claim 54, wherein the accessing step includes accessing the datum via any of a pointer, an address, or a symbolic or other reference to the instance of the datum maintained by the first object.

57. The method of any one of claims 54-56, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.

58. The method of any one of claims 54-56, wherein the executing step includes executing at least the first and second objects to configure the control devices to provide any of sensing, actuation and other control functions.

59. The method of any one of claims 54-56, wherein the executing step includes executing one or more control blocks associated with the first and second objects.

60. The method of claim 59, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.

61. The method of any one of claims 54-56, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.

62. The method of any one of claims 54-56 adapted for providing any of process, environmental or other control.

63. A method of operating a control system, comprising:

executing a plurality of objects in virtual machine environments provided on one or more control devices, the objects configuring the one or more devices to provide control functions,

communicating one or more data contained in a data structure between first and second ones of the plurality of objects,

maintaining in the first object a sole instance of the data structure and data contained therein as between at least the first and second objects,

accessing by reference data in the data structure with the second object.

64. The method of claim 63, wherein the data structure comprises a unidirectional variable having

a measurement, a setpoint or other value, and

any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement setpoint or other value.

65. The method of claim 63, wherein the executing step includes executing at least the first and second objects to configure the control devices to provide any of sensing, actuation and other control functions.

66. The method of claim 63, wherein the executing step includes executing one or more control blocks associated with the first and second objects.

67. The method of claim 63, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.

68. The method of claim 63, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.

69. The method of claim 63 adapted for providing any of process, environmental or other control.

70. The method of any one of claims 63-69, wherein the data structure comprises a bi-directional variable having

a forward-going measurement, setpoint or other value (collectively, "forward-going value"),

any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,

a back-going measurement, setpoint or other value (collectively, "back-going value"), and

any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).

71. A method of operating a control system, comprising:

executing a plurality of objects in virtual machine environments provided on one or more control devices, the objects configuring the one or more devices to provide control functions,

communicating one or more data contained, in a data structure between first one of the objects and second and third ones of the objects,

maintaining in the first object a sole instance of the data structure and data contained therein as between at least the first, second and third objects,

accessing by reference data in the data structure with the second and third objects.

72. The method of claim 71, wherein the data structure comprises a bi-directional variable having

a forward-going measurement, setpoint or other value (collectively, "forward-going value"),

any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,

a back-going measurement, setpoint or other value (collectively, "back-going value"), and

any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).

Description

BACKGROUND OF THE INVENTION

The invention pertains to control and, more particularly, to methods and apparatus for implementing process and other control systems at lower cost, with greater flexibility and robustness.

The terms "control" and "control systems" refer to the control of a device or system by monitoring one or more of its characteristics. This is used to insure that output, processing, quality and/or efficiency remain within desired ranges over the course of time. In many control systems, digital data processing or other automated apparatus monitor a device, process or system and automatically adjust its operational parameters or variables. In other control systems, such apparatus monitor the device, process or system and display alarms or other indicia of its characteristics, leaving responsibility for adjustment to the operator.

Control is used in a number of fields. Process control, for example, is typically employed in the manufacturing sector for process, repetitive and discrete manufactures, though, it also has wide application in utility and other service industries. Environmental control finds application in residential, commercial, institutional and industrial settings, where temperature and other environmental factors must be properly maintained. Control is also used in articles of manufacture, from toasters to aircraft, to monitor and control device operation.

Modern day control systems typically include a combination of field devices, controllers, workstations and other more powerful digital data processing apparatus, the functions of which may overlap or be combined. Field devices include temperature, flow and other sensors that measure characteristics of the subject device, process or system. They also include valves and other actuators that mechanically, electrically, magnetically, or otherwise effect the desired control.

Controllers generate settings for the actuator type field devices based on measurements from sensor type field devices. Controller operation is typically based on a "control algorithm" that maintains a controlled device at a desired level, or drives it to that level, by minimizing differences between the values measured values and, for example, a setpoint defined by the operator. Workstations, control stations and the like are typically used to configure and monitor the process as a whole. They are often also used to execute higher-levels of process control, e.g., coordinating groups of controllers and responding to alarm conditions occurring within them.

In an electric power plant, for example, a workstation coordinates controllers that actuate conveyors, valves, and the like, to move coal or other fuels to a combustion chamber. The workstation also configures and monitors the controllers that maintain the dampers that determine the level of combustion. The latter operate, for example, by comparing the temperature of the combustion chamber with a desired setpoint. If the chamber temperature is too low, the control algorithm may call for incrementally opening the dampers, thereby, increasing combustion activity and driving the temperature upwards. As the temperature approaches the desired setpoint, the algorithm incrementally levels the dampers to maintain the combustion level.

The design of control systems and specification of the control algorithms is typically performed using tools known as configurators. An exemplary such tool is provided with the I/A Series.RTM. (hereinafter, "IAS" or "I/A") systems, marketed by the assignee hereof. A graphical configurator, FoxCAE,.RTM. provided with those systems permits an engineer to model a process hierarchically and to define a control algorithm from that hierarchy. Once configuration is complete, the control algorithm is downloaded to the control devices. This may involve "compiling" the algorithm in order to convert it into code understood by the controllers and other control devices.

While prior art products such as the aforementioned ones by the Assignee hereof continue to meet success in the marketplace, there remains a need for advancement.

In view thereof, an object of this invention is to provide improved methods and apparatus for control. A related object is to provide such methods and apparatus as can be achieved with lower cost, greater flexibility and robustness.

Another object of the invention is to provide such methods and apparatus as facilitate the modeling of control processes by engineers and users alike.

A related object is to provide such methods and apparatus as facilitate the generation of higher-quality modeling software at lower cost and more widespread applicability.

A further object is to provide such methods and apparatus as can be used in process and other control systems.

SUMMARY OF THE INVENTION

The foregoing are among the objects attained by invention which provides, in one aspect, an improved control device for a process or other control system. The device provides a virtual machine environment in which Java objects, or other such software constructs, are executed to implement control (e.g., to monitor and/or control a device, process or system). These objects, referred to herein as process control objects (PCOs), define blocks, which are the basic functional unit of the control. They also define the input, output and body parts from which blocks are formed, and the signals that are communicated between blocks. PCOs also define nested and composite groupings of blocks used to control loops and higher-level control functions.

By way of non-limiting example, a control system with devices according to the invention can have a workstation and controllers, each providing a Java virtual machine (JVM) environment. Executing on the devices are Java PCOs embodying their respective control functions and signaling. Thus, PCOs executing in each controller monitor and control sensors and actuators under that controller's purview. PCOs executing in the workstation monitor and control the controllers themselves (as well, perhaps, as monitoring the outputs of some of the field devices). Intelligent field devices in the control system may also execute PCOs, thereby, further distributing the control function and taking up tasks otherwise handled by the controllers and workstation.

Referential Communication Between Process Control Entities

Further aspects of the invention provide control devices as described above in which individual data, such as measurements, setpoints or other values, are communicated block-type PCOs by reference. To this end, only one object of each pair of objects between which a given datum is communicated stores the datum itself, e.g., by non-limiting example, in a data structure referred to as below as a "variable." The other block maintains only a reference, i.e., a pointer, address, symbolic or other reference, to the datum. In order to access the sole instance of the datum as between at least those two blocks, the latter block interrogates--or, if permitted, sets the value of--the datum by using the pointer, address or other reference.

A given datum, according to further aspects of the invention, can be maintained in the block that is the logical and/or physical source of the measurement, setpoint or other value to which it pertains. For example, a PCO embodying an analog input (AIN) block maintains a data structure containing data measured by it. PCO blocks that use those measurements access that data structure and, thereby, the data, by reference.

The data structures embodying data can themselves be PCOs, e.g., by non-limiting example, instantiated from the "signal" class described in the detailed description, below. According to further aspects of the invention, in addition to storing specific measurements, setpoints or values (e.g., the "variables" described below), these data structures can maintain range, status, time stamps and/or other information pertaining to them.

Thus, for example, a "float" variable data structure in a PCO analog input block maintained in a thermocouple sensor device can have, in addition to a floating point value representing the temperature value measured by that device, range values representing permissible upper and lower values for the measured temperatures. It can also have status values representing signal quality (e.g., SEVA values of the type discussed elsewhere herein) and/or initialization state; limit status for signal limiting and connection status; timestamp values identifying when the value was last changed; among others. According to related aspects of the invention, the "limit status" can include a flag, e.g., a "publish" bit, indicating whether the subject datum has been communicated to other elements of the control system, e.g., by "publication."

An advantage of devices using PCOs that communicate data, i.e., establish "connections," in the manner described above is that they minimize the unnecessary duplication of data and the attendant cost of maintaining coherency. A further advantage is that they can more readily propagate variables and their attendant values, ranges, and so forth, throughout the system.

With respect to this latter point, a control system having devices as described above will typically implement a control scheme wherein a value generated (or measured) by single block is used by several downstream blocks. Thus, for example, a PCO block maintained by a thermocouple field device might be connected to a PCO control block executing in a controller that processes the thermocouple output to adjust a fuel intake valve. It might also be connected to a PCO control block executing in an intelligent field device that adjusts a damper level.

The use of data structures as described above facilitate establishing common values, ranges, and so forth, e.g., for the thermocouple output, among all of the PCO blocks that use connections. That information is stored only in the source PCO, e.g., the thermocouple PCO. Hence, the risk of data loss or misinterpretation resulting from lack of coherency is minimized, as is the risk of incorrect scaling and the like among the blocks participating in the connections.

Control devices as described above can, according to further aspects of the invention, maintain unilateral and/or bilateral connections for the information that they exchange. Unilateral connections utilize a data structure as described above to store a single "forward going" data value (or set of values), along with its attendant range, status, limit status, time and other related information. These are typically used, for example, in connections to/from sensors and actuators.

The control devices can also utilize PCOs that establish bilateral connections maintaining two data values (or sets of values), along with attendant range, status, limit status, time and other related information. These can be used, for example, in connections in which a forward going data value is dependent on a backward going one.

For example, a PCO functioning as a proportional integral derivative (PID) control block and executing in an intelligent actuator might provide the setpoint to a PCO executing as an analog output (AOUT) control block in that same actuator. A single data structure maintaining the AOUT setpoint can be stored in the PID, with the AOUT accessing it by reference. The PID requires feedback, such as the current valve position, in order initialize its output to avoid bumping that value at startup. The AOUT can provide that feedback, according to related aspects of the invention, by accessing the data structure by reference and storing a backward going data value (or feedback value) there. Similar bilateral communications are required between cascaded controllers where the output of one is the setpoint of another.

Control devices utilizing PCO that establish bilateral connections have additional advantages, including, eliminating the need to establish and ensure that forward-going and back-going values for each connection necessarily run between the same two blocks. In addition, they ensure that consistent range, status, limit status, time and other information concerning the forward-going and back-going values are shared by both PCO that are parties to the connection.

Process Control Entities with Mandatory and Optional Parts

Further aspects of the invention provide control devices as described above that include PCOs with mandatory parts for which memory space is allocated at the time of object creation (or instantiation) and with optional parts for which memory space is allocated only as needed. The optional parts can be added subsequent to creation, typically, for example, during configuration.

By way of example, an intelligent field device embodying a PCO according to the invention representing an analog input block (AIN) can have a mandatory input part for receiving, linearizing, filtering and scaling measurements. It can also have a mandatory output part for processing or switching and for making the result available to PCOs, e.g., embodying control algorithms. These mandatory parts are instantiated when the AIN PCO is first instantiated. Optional parts for the AIN PCO permit, inter alia, establishing alarm limits, defining a characterizer that linearizes an input measurement, defining filtering for an input measurement, and defining limits for output values, and to utilize potential emergency interlock output values. These optional parts can be instantiated, if at all, e.g., when the already-instantiated PCO is being configured.

The invention provides, in other aspects, control devices as described above in which the parts, whether optional or mandatory, are associated with block-type PCOs and are instantiated locally in relation to the respective blocks that contain them. Put another way, the parts are instantiated in the processes responsible for executing the PCO in which they are contained.

Further aspects of the invention provide control devices as described above in which mandatory parts of a PCO are instantiated in a declaration or a constructor method (e.g., a default constructor) of a class from which the PCO is instantiated. While optional parts can be instantiated by a constructor (e.g., other than the default constructor), they can also be instantiated by configurator following creation of the PCO.

Control device incorporating dynamically configurable PCOs, i.e., with mandatory and optional parts, as described herein are advantageous, for example, in that their constituent blocks provide all necessary input, output and/or processing behaviors, without dedicating memory or other resources to unused ones. Thus, the AIN PCO described in the example above can be selectively configured to allocate memory and processor resources to alarms and filters, yet, not to consume resources with optional features that will not be used, e.g., interlocks and characterizers. Moreover, such PCOs instill in their respective control devices (e.g., their respective control stations, work stations, controllers, or field devices) optional behaviors that execute as if "compiled in," yet, not requiring recompilation on configuration.

In addition to individual block-type PCOs that are dynamically configurable, further aspects of the invention provide control devices and systems with dynamically configurable composite PCOs. These are PCOs with mandatory constituent blocks for which memory space is allocated at the time of object creation (or instantiation) and with optional blocks for which memory space is allocated only as needed. The optional blocks are added at the time each composite PCO is created, e.g., during configuration, or later.

By way of example, a control system executing a PCO composite-type object representing a process control loop, can have a mandatory analog input block (AIN), a mandatory analog output (AOUT) block and a mandatory proportional-integral-derivative (PID) control block. Optional blocks for the composite PCO can provide for feedforward control. These can include, for example, an optional second AIN block, e.g., for detecting disturbances in the controlled process, as well as for an optional, feed forward control block that generates additional control values to facilitate disturbance compensation in the first (feedback), PID block.

Process Control System with Blocks Having Common Input and/or Output Sections

Still further aspects of the invention provide control systems and control devices as described above with block-type and composite-type PCOs that use standardized classes (or other definitional software constructs) to define input and output parts that receive and transmit information on behalf of the PCOs. The classes provide common interfaces between interconnected blocks, as well as insuring common processing of information by them.

By way of example, PCO blocks executing on the workstations, controllers, intelligent field devices and other control devices in a control system according to the invention can have input and output parts instantiated from a common set of input and output classes, respectively. The PCOs can be of a variety of composite block types and individual block types, the latter including, for example, AnalogInput, AnalogOutput, PID, and Feedback Tuner. The common set of classes from which their input and output parts are instantiated include, according to one aspect of the invention and by way of non-limiting example, cascaded floating point input, cascaded floating point output, unidirectional boolean input, unidirectional boolean output.

According to related aspects of the invention, the input and output parts of the block PCOs are created from possibly overlapping subsets of classes selected from a common set of standardized classes. Thus, for example, PCOs that embody PID control blocks include input and output parts defined with standardized cascaded floating point input and cascaded floating point output classes. PCOs that embody "user" control blocks also use the standardized cascaded floating point output classes, though their input parts are defined using a different standardized class, to wit, the unidirectional floating point input class.

Further aspects of the invention provide control systems and control devices as described above wherein the input and output parts, themselves, use standardized classes to define objects that reflect, by way of non-limiting example, state, status, mode, and option assignments shared by the respective blocks and their parts, as well as to define information that is communicated between the blocks. In addition to providing common methods for setting and getting values, these classes define methods for linking variables (and their constituent parameters) to establish connections between blocks.

By way of example, the standardized cascaded floating point input part contained in the above-described PID control blocks can have constituent objects defined from a standardized "lrs" setpoint mode class that characterizes the setpoint source for an input part, e.g., whether it is set by an external block, by a supervisory task, or by the operator. By way of further example, the cascaded floating point output part of such a PID block can include a constituent objects defined from a standardized "mas" mode class that characterizes source of the outgoing signal generated by that output part, e.g., whether it is set by the block, a supervisory task or the operator.

A control device with a PCO block having input and output parts utilizing objects instantiated independent classes, such as the lrs and mas classes described above, can provide for the independent characterization of setpoints received and generated by the PCO. Thus, for example, the block can be set by an operator at runtime to provide for any of local, remote or supervisory setpoint input and, at the same time, for any of manual automatic and supervisory setpoint output. Moreover, the block can retain a setpoint value previously defined, e.g., before transition into manual or supervisory mode, to facilitate transition back to automatic mode.

Further related aspects of the invention provide control systems and control devices where the input, output, body and other parts use other standardized classes. These can include, by way of non-limiting example, a signal quality status class, a maintenance status class, a limit indication and linking/setting permissions class, among others.

The invention provides, in still further aspects, control systems and devices as described above in which memory is allocated for mandatory constituent portions of a part at the time of creation and in which memory is allocated for optional portions only as necessary, e.g., during configuration. These portions can include PCOs defined in accord with the aforementioned signal classes, as well as in accord with other classes that make up the parts.

According to further related aspects of the invention, that parts of PCO control blocks utilized in control systems and devices can have the mandatory constituent that include, by way of example, the aforementioned lrs and mas setpoint mode classes of the cascaded floating point input and output parts, respectively. Further mandatory classes of these parts can include, by way of further non-limiting example, a floating point variable class for containing the setpoints received or set by the input and output parts, respectively. Optional classes for these parts can include a limit class (defined as a "parts" class in the discussion below) used to define high and low setpoint values for the input and output parts that include the limit class.

Still further aspects of the invention provide control systems and devices as described above in which the block-type PCOs include body parts, in addition to input and output parts. The body parts can, for example, embody attributes and methods that are unique to the particular block class, in addition to standardized parts such as for feedback tuning and deadtime compensation.

Multi-Input Analog Input Block for Process Control System

Further aspects of the invention provide a control device with an analog input block (AIN) coupled to accept readings from multiple sensors or other input devices and to generate an output based on one or more of those readings. The analog input block, which can be a PCO as described above, can take a reading from each of the multiple sensors during each block processing cycle (BPC), e.g., each cycle during which the AIN is invoked (typically, along or in sequence with other blocks in a common control system).

Related aspects of the invention provide a control device configured as an AIN as described above that generates an output based on the multiple inputs every "block period," e.g., every period (typically multiple BPCs) in which the output of the AIN is updated. The output can be, by way of non-limiting example, minimum, maximum, median, weighted average (e.g., based on uncertainty values, such as SEVA, provided by the sensor as part of the variable data structure) or other selection or function of the multiple inputs.

Further related aspects of the invention provide a control device configured by a PCO as an AIN block as described above in which the input part of that block samples measurements received from its respective sensor every BPC, notwithstanding that the block period may run over several BPCs. Those measurements can be averaged with one another (e.g. by the input or body parts of the PCO), prior to being statistically compared or combined with the outputs of other input parts in the AIN.

Still further aspects of the invention provide a AIN PCO as described above having multiple input parts, each receiving, filtering, characterizing and/or otherwise processing a respective one of the measurements received by the AIN block. A control device in which such an AIN is embodied can dedicate memory space upon instantiation of the block or its subsequent configuration to only such input parts as are required by the particular implementation. Moreover, such a control device can apply independent filtering, characterizing or other functions to each of the inputs.

Further aspects of the invention provide control systems embodying one or more control devices as described above and/or utilizing PCOs as described above. Other aspects provide control devices and systems having individual ones of the features described above, alone or in combination with other ones of the features.

Yet other aspects of the invention provide methods of operating control devices and control systems paralleling the foregoing.

These and other aspects of the invention are evident in the attached drawings, and in the description and claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the invention may be attained by reference to the drawings, in which:

FIG. 1 depicts a process control system 10 of the type with which the invention is practiced;

FIG. 2 depicts the object model notation utilized in this disclosure;

FIG. 3 depicts a control and information collection class and object architecture in a control system according to the invention;

FIG. 4 depicts control and information collection signal, part, and block classes in a control system according to the invention;

FIG. 5 depicts input/output classes for intelligent and standard devices in a control system according to the invention;

FIG. 6 depicts control and information collection nested classes in a control system according to the invention;

FIG. 7 depicts an architecture for a typical block class in a control system according to the invention;

FIG. 8 shows examples of unidirectional and cascade input and output part classes in a control system according to the invention;

FIG. 9 depicts a loop composite class in a control system according to the invention;

FIG. 10 depicts a PLoop composite class in a control system according to the invention;

FIG. 11 depicts a cascade composite class in a control system according to the invention;

FIG. 12 depicts a TempProcess Composite class in a control system according to the invention;

FIG. 13 depicts Loops2 control and process objects in a control system according to the invention;

FIG. 14 depicts Loops2 control and process objects and details in a control system according to the invention;

FIG. 15 depicts TempCasc control and process objects in a control system according to the invention;

FIG. 16 depicts TempCasc control and process objects and details in a control system according to the invention;

FIG. 17 depicts cascade peer-to-peer communication in a control system according to the invention; and

FIG. 18 depicts variable and parameter transfer and rules in a control system according to the invention.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT

FIG. 1 depicts a process control system 10 of the type with which the invention is practiced. The system includes networked control devices that monitor and control a hypothetical mixing process 20 that utilizes mixing chamber 22, fluid inlets 24, 26, fluid outlet 28, paddle 30, cooler 32, and cooler inlet 34. Though illustrated and described below for use in connection with process control, those skilled in the art will appreciate that apparatus and methods according to the invention can be used in connection with any industrial, manufacturing, service, environmental or other process, device or system amenable to monitoring or control (hereinafter, collectively, "control").

The networked control devices include actuators, such as the valves depicted as controlling inlets and outlets 24-28 and 34. A further actuator is shown controlling paddle 30. These and other actuators utilized by the control system are constructed and operated in the conventional manner, as modified in accord with the teachings hereof. The actuators operate under control of respective field device controllers, labeled CTL, that are also constructed and operated in the conventional manner to provide initialization, signal conditioning and communications functions.

Rather than using separate controllers CTL, the actuators can be of the intelligent variety and can include integral microprocessors or other digital data processing apparatus for control, initialization, signal conditioning, communications and other control-related functions. For sake of convenience, the label CTL is used regardless of whether the control-related functionality is integral to the actuators (e.g., as in the case of intelligent actuators) or otherwise.

Illustrated sensor 29 monitors a temperature, level or other characteristic of fluid in chamber 22. The sensor 29, as well as other sensing apparatus utilized by the system, are constructed and operated in the conventional manner known in the art, as modified in accord with the teachings hereof. They can be coupled to the control network via a transmitter or other interface device INT that, too, is constructed and operated in the conventional manner, as modified by the teachings hereof. The interface devices facilitate initialization, signal conditioning and communications between the sensors and the control system. As above, one or more sensors can be of the intelligent variety, incorporating integral microprocessors or other digital data processing capabilities for initialization, signal conditioning, communications and other control-related functions. Here, too, the label INT is used in reference to the control-related functionality, regardless of whether embodied in an intelligent transmitter or otherwise.

The networked control devices include one or more controllers 36 that monitor and control respective aspects of the hypothetical mixing process in the conventional manner, as modified in accord with the teachings hereof. The controllers can comprise mainframe computers, workstations 40, personal computers 42, special-purpose hardware or other digital data processing apparatus capable of performing conventional monitoring and control functions. Preferred controllers are constructed and operated in the manner of the CP control processors commercially available from the assignee hereof, as modified in accord with the teachings herein.

The control system 10 includes elements that serve as user interfaces and that provide configuration and/or control functions, all in the conventional manner as modified in accord with the teachings hereof. Illustrated for these purposes are, for example, workstation 40 and personal (laptop) computer 42. These devices can provide configuration and control functions directly, as in the case of workstation 40, or in cooperation with server devices (not shown). Apparatus 36-42 can couple with one another directly, e.g., via bus or network connection (as illustrated below), or indirectly, e.g., via satellite, wireless connection or modem connection.

The devices 36-42, CTL and INT, collectively, referred to as "control" devices, are coupled for communications via a medium that permits at least selected ones of the devices to communicate with one another. To this end, in the illustrated embodiment those devices are coupled via one or more networks 48 that are, preferably, IP-based such as, by way non-limiting example, Ethernets. The network(s) can include, as indicated by the multiple segments shown in the drawing, multiple segments such as various wide and local area networks. They may also include high and/or low bandwidth components, such as phone lines, and low and/or high latency components, such as satellites networks.

In the preferred, illustrated embodiment, each of the control devices 36-42, CTL and INT, provides virtual machine environment for executing Java byte code (or other such intermediate code) in the form of Java applications, Java applets, Java servlets, or like constructs in other software languages that, for example, configures the respective device to provide monitoring and/or control (collectively, "control"), including, by way of non-limiting example, servicing sensors to provide inputs (analog or otherwise), servicing actuators to provide outputs, executing blocks (composite, individual or otherwise) that include a control algorithm and/or otherwise to participate in the control system.

By way of non-limiting example, the illustrated intelligent field devices can include low power processors, along with a random access memory, read-only memory, FlashRAM, and appropriate sensor/actuator interfaces. The processors of those devices can execute a real-time operating system, as well as a Java virtual machine (JVM). Process control blocks or entities in Java byte code execute in the JVMs to configure the respective field devices to perform process control functions, e.g., for analog input (AIN), analog output, proportional integral derivative (PID) control and so forth.

By way of further non-limiting example, the controllers, workstations, control stations and other digital data processor-based control devices can include larger, more powerful central processing units, along with on-board memory (e.g., RAM, ROM, FlashRAM), mass storage, sensor/actuator interfaces, as necessary, conventionaloperating systems and JVMs, and so forth. The JVMs on these more powerful devices permit them to perform a still wider range of control functions, e.g., to monitor control larger scale plant operations.

A further appreciation of the hardware and software environment provided by system 10 may be attained by reference to commonly-assigned, co-pending U.S. patent application Ser. No. 09/591,604, and to counterpart PCT Application Serial No. PCT/US 00/15860, both filed Jun. 9, 2000, entitled METHODS AND APPARATUS FOR CONTROL USING CONTROL DEVICES THAT PROVIDE A VIRTUAL MACHINE ENVIRONMENT AND THAT COMMUNICATE VIA AN IP NETWORK, The teachings of these applications are incorporated herein by reference.

Described below are aspects of the operation of the aforementioned control devices 36-42, CTL and INT, and, more generally, of the control system 10 deriving from execution on the devices of Java applications, applets, servlets (or other such software constructs) to implement control. These objects, referred to herein as process control objects (PCOs), define blocks which are the basic functional unit of the control. They also define the input, output and body parts from which blocks are formed, and the signals that are communicated between blocks. PCOs also define nested and composite groupings of blocks used to control loops and higher-level control functions.

The Advantages of PCOs

As evident in the discussion above and in the pages that follow Process Control Objects facilitate the development, implementation and maintenance of control systems, additionally, maximizing their flexibility of configuration and robustness. PCOs also facilitate the introduction of new control objects and enhancements without affecting the running system, in addition to enabling on-line modification and upgrade of objects. Control systems utilizing PCOs are, moreover, portable: control classes, written once, can run everywhere. The systems are also scaleable.

By way of both review and introduction, control systems implemented with PCOs implement optional parts and functionality separately from mandatory parts, thus, minimizing consumption of undue resources. Their use of separate input and output parts speeds implementation, while permitting the input and output sides of each block to be independently configured and operated.

The PCO control architecture provides standardized input and output part classes used in all blocks. Input and output part classes provide initialization, anti-windup, cascade handling, local/remote/supervisory switching, manual/auto/supervisory switching, standardized variable naming, input and output multiplicative and additive feedforward, output selection (limiting with an override controller). In addition optional parts for the input and output classes furnish alarming, limiting, filtering, feedforward, characterization, and interlock. Architecturally the input and output part classes provide standard interfaces between interconnected blocks.

PCOs provide a framework where interconnected block and nested classes are aggregated to create higher level nested classes, which are then used to create object instances. These higher nested instance include, for example, all control for a process unit, all information collection for a process unit, and so forth. Information is stored at its source, permitting other objects to reference it, e.g., via implicit pointers, addresses, symbolic references, or the like, in order to obtain specific datum (such as measurements) and information pertaining to it. For objects residing in remote stations the source passes the referenced information to proxy objects residing in those stations.

In a control system implemented using PCOs, scaling is done at the source and transmitted to the sink(s) when it changes. For example, in a cascaded controller, the local, remote, and supervisory setpoints obtain scaling from the measurement input. A cascade output obtains scaling from its back-calculated input. In general, cascade scaling information flows upstream. An analog output object has no measurement, therefore the scaling of its remote setpoint and back-calculated output is either entered locally or obtained from the downstream field device.

Other aspects of a control implementation using PCOs is that it permits the creation of object classes for required inter-block signals to communicate values with signal (SEVA) quality status, cascade handling (bumpless initialization and anti-windup) logic, and permissions for connection, setting, and configuration. Moreover, it makes automatically the backward interconnection for cascaded blocks.

Object Model Notation

FIG. 2 shows the notation for object and class diagrams used in this patent application. Those skilled in the art will appreciate that this is a subset of the standard Rumbaugh notation.

Architecture of Process Control Classes

This section describes the overall architecture for Process Control Objects and introduces the signal, part, block, nested, and composite classes and objects.

Signal Object

A signal object is an object that is implemented as a component of a block or a part object, and its name includes the name of its block object. It is located locally in relation to the block object that contains it. A signal object is an instance of a signal class. Signal objects contain the information communicated between blocks or inserted into blocks as constants. These objects also provide methods to be used by users and tasks for setting and getting values and for linking and unlinking parameters and variables.

Signal Classes

Signal Classes are classes that provide signal objects as defined above.

Part Object

A part object is an object that is implemented as a component of a block or another part object, and its name includes the name of its block object. It is located locally in relation to the block object that contains it. A part object is an instance of a part class. Input and output part objects contain or reference float, boolean, or integer signal objects, which enable unidirectional and cascade communication between blocks. Some part classes provide objects for optional functionality such as alarm, limit, and filter, which can be components of the input and output part objects or blocks.

Part Classes

Part Classes are classes that provide part objects as defined above.

Block Object

A block object is an instance of a block class and provides a base level of functionality. It is the lowest level object, which can be implemented as an independent object with a network-wide unique name. A block object is made up of input part objects, a body, and output part objects. The input and output parts are independent of the body and enable unidirectional and cascade communication between blocks. The body contains the attributes and methods that are unique to the particular block class. In addition the body may contain optional parts such as feedback tuner, feedforward tuner, and deadtime. AnalogInput, AdvancedPID, and AnalogOutput are examples of block objects. Typically, block objects are used to create a hierarchy of nested objects.

Block Classes

Block Classes are classes that provide block objects as defined above.

Nested Object

A nested object is an instance of a nested class and is a component of possibly interconnected block and nested objects. Replication of a control solution is achieved with multiple instances of a nested class. Each object instance can be implemented as an independent object with a network-wide unique tag name. An example of a nested class is a loop class, name it Loop, which contains the AnalogInput, AdvancedPID, and AnalogOutput block classes with appropriate connections achieved by linking the input and output parts of the blocks. Class Loop can then be used to create many instances of loop composite objects. A second level nested class can be created by nesting together the AnalogInput and AdvancedPID block classes and the Loop class with appropriate connections to create a cascade class, name it Cascade. Class Cascade can then be used to create many instances of cascade composite objects.

Nested Classes

Nested Classes are classes that provide nested objects as defined above.

Composite Object or Composite

A composite object is an instance of a nested class implemented as an independent object with a network-wide unique name. For example instances of class Loop or Cascade with network-wide unique names are composite objects.

Composite Class

A composite class is a nested class whose object instances are implemented as independent objects with a network-wide unique name, that is, composite objects. When class Loop is used to create instances with network-wide unique names it is a composite class. However, the same class Loop when used as a component of the Cascade class is a component class, while class Cascade is a composite class.

FIG. 3 shows the architecture for the Process Control Objects (PCO). Square boxes indicate classes, while rounded ones indicate object instances (objects). The Signal Classes, shown with vertical lines, provide signal classes to the part and block classes, for example the float parameter and float variable classes.

The Part Classes, shown shaded, provide mandatory and optional part classes to the block classes, for example the uni-directional and cascade float input and output classes. The optional part classes also provide optional part classes to the mandatory part classes.

The Block Classes are typically used to create component and composite classes, which are then used to create many instances of composite objects (composites).

A tag name is an arbitrary string.

Predefined (Implementation-Standard) Control Classes

FIG. 4 shows the signal, part, and block classes for control and information collection in more detail. In particular it shows the inheritance hierarchy and aggregation of the part and block classes for control and information collection.

Class names start with a capital letter, while names for objects, attributes, and methods start with small letters with additional words concatenated to the first word starting with capital letters. This is the recommended practice by many authors and developers and is followed in this document.

The clear rectangular boxes indicate block classes, for example, AnalogInput class. The shaded rectangular boxes indicate part classes, for example, Alarm and FloatVariable classes. The boxes with the diagonal lines indicate signal classes, for example, boolean and float parameters and variables.

FIG. 5 shows the InputOutput classes for intelligent and standard devices, which are indicated by boxes filled with dots. The boxes with dotted lines indicate classes from FIG. 4. The InputOutput classes are parts of the UniDirFloatInput and CascFloatOutput classes for analog inputs and analog outputs, respectively.

FIG. 6 illustrates the aggregation of control block classes to create many levels of nested classes. The inheritance hierarchy and aggregation classes for control part and block objects shown in FIG. 4 furnishes the control block classes used to create nested classes.

As shown in the figure, the objects of class ControlNestedLevel1 contain block objects. In particular, they contain combinations of two or more (indicated by 2+) block objects. The objects of class ControlNestedLevel2, contain combinations of one or more (indicated by 1+) ControlNestedLevel1 objects, and optionally zero or more block objects. A level 2 control nested object must contain at least one level 1 control nested object.

Following this procedure, nesting can be generalized to N levels. Each higher level control nested object contains at least one control nested object from the level below it, and optionally, zero or more objects from any other levels as well as zero or more block objects.

This is how the composite classes of FIG. 3 are created and then used to create many instances of composite objects as required.

FIG. 7 shows the architecture for a typical block class. The Input Parts contain the parts and references for unidirectional and cascade variables. The input parts can also contain optional parts such as filter and alarm. The Output Parts contain parts and references for unidirectional and cascade variables. The output parts can also contain optional parts such as limit and alarm. The Body contains the attributes and methods that are unique to the particular block class. It can also contain optional parts such as feedback tuner and deadtime.

FIG. 8 provides examples of unidirectional and cascade input and output parts. More particularly, FIG. 8(a) shows the unidirectional part UniDirInput. The variable in comes from a source and there is no backward communication as indicated by the single incoming arrow. The variable pv can be a source for many sinks and there is no backward communication as indicated by the single outgoing arrow.

FIG. 8(b) shows the cascade part CascadeInput. The cascade part enables uni-directional and bi-directional communications. The variables in, fdFwd, pv, sp, and deviation are uni-directional as indicated by the single arrow. Variables remSP and supvSP are bi-directional as indicated by the double arrow.

Similarly, FIGS. 8(c) and (d) shows the uni-directional part UniDirOutput and the cascade part CascadeInput, respectively.

The Input and Output parts are instances of the part classes that are shown in the Control and Information Class structure of FIG. 4 and they are separate and independent from the Body of the typical block class. This enables inter-operability between components by connecting the output variable of an output part to the input variable of an input part.

When either the output part of the source block or the input part of the sink block is uni-directional, the communication between them is unidirectional (one-way) from the source to the sink. For example, the value and status of the output part's variable is passed by reference to the input part's variable.

When both the output part of the source block and the input part of the sink block are cascade, the communication between them is also cascade. That is from the source to the sink for both the forward value and status, and from the sink to the source for both the back value and status. In this case the sink component is connected to the source component and the source component is connected to the sink component. A single linkage of the sink to the source connects both the forward and back signals.

Control applications use both unidirectional and cascade connections. Consider, for example, heating cold water in a heat exchanger by condensing steam. The cold water flows through the tubes of the heat exchanger and steam flows through the shell of the heat exchanger. The objective is to heat the water to a desired temperature using cascade control, whereby the temperature controller sets the setpoint of the steam flow controller. The temperature controller uses the hot water temperature measurement, while the steam flow controller uses the steam flow measurement. The steam flow controller delivers the required steam by throttling the steam valve.

This is an example of cascade control, that is, the output of the temperature controller is cascaded to the setpoint of the steam flow controller. Consider the case where the operator opens the cascade by placing the steam flow controller on local control, and sets the steam flow setpoint herself, thereby disabling the temperature controller from doing so. When the operator closes the cascade and transfers control to the temperature controller there is going to be a "bump" in the steam flow unless the temperature controller output was initialized to the value of the steam flow local setpoint at the time of transfer.

This is precisely accomplished with the cascade connection. In normal cascade control the output of the temperature controller is connected to the setpoint of the steam flow controller. The forward value and status of the steam flow controller setpoint are the value and status of the temperature controller output to which it is connected. Also the back value and status of the temperature controller output are the back value and status of the steam flow controller remote setpoint to which it is connected.

When the cascade has been open for a period of time and the operator transfers control to the temperature controller by switching the steam flow controller from local to remote, the temperature controller knows this from its output's back status from the steam flow controller setpoint. At this time the temperature controller initializes and computes the value of its forward output to be the output back value, which the steam flow controller sets equal to its local setpoint value at the time of transfer. From then on normal cascade control commences again and the temperature controller manipulates the steam flow setpoint to drive the actual water temperature to the desired value, as determined by the value of the temperature controller setpoint.

Signal Classes

The signal classes are contained in the Signals package, described below. A package contains a number of Java files and each Java file contains one and only one class. Objects from Signals classes contain the information communicated between linked blocks or inserted into blocks as constants. These classes also provide methods to be used by users and tasks for setting and getting values and for linking and unlinking parameters and variables. The Signals package also contains an interface for shared constants, and a mode class, which is used by cascade input parts for local/remote/supervisory switching and by cascade output parts for manual/auto/supervisory/interlock switching.

The signal classes include the following: BoolParameter, BoolVariable, FloatParameter, FloatRange, FloatVariable, IntParameter, IntRange, IntVariable, Mode, ObjList. Parameter and Variable are abstract classes passing common methods and attributes through inheritance to the individual XxxParameter and XxxVariable classes.

Part Classes

The part classes are contained in the Parts package. A Part must be contained in a block or other part contained in a block. Each block may have one or more input parts, a body, and one or more output parts. Input and output Part classes contain or reference FloatVariable, BoolVariable, or IntVariable signals, which enable uni-directional or cascade communication between blocks. Some part classes provide objects for optional functionality such as alarm, limit, and filter and they can be components of input and output part objects or blocks.

An unused optional part has a null reference. The configurator must instantiate an optional part before it can be used or its parameters set.

The parts classes include the following: Alarm, BoolFilter, Characterizer, CascBoolInput, CascBoolOutput, CascFloatInput, CascFloatOutput, CasclntInput, CascIntOutput, Deadtime, Failsafe, FeedForward, Filter, InfoBuffer, IntFilter, Interlock, Limit, LinearFlow, PIDParameters, Ramp, TimeCount, UniDirBoolInput, UniDirBoolOutput, UniDirFloatInput, UniDirFloatOutput, UniDirIntInput, UniDirIntOutput, Zone,

InputOutput Classes

The InputOutput classes are contained in the InputOutput package. The InputOutput classes are parts of the UniDirFloatInput and CasFloatOutput classes for analog inputs and analog outputs, respectively. They are optional parts with a default null reference. The configurator must instantiate them before they can be used or their parameters set.

The InputOutput Classes provide the interface to input and output signals using the Java Native Interface (JNI), which provides Java classes with native methods.

Block Classes

The block classes are contained in the Blocks package. The block classes provide block object instances, which can be implemented as independent objects with network-wide unique names. Typically, block classes are used to provide component classes for composite classes, which are then used to create many instances of composite objects.

FIG. 7 shows the architecture for a typical block class. The Input Parts contain the parts for uni-directional and cascade variables. The input parts can also contain optional parts such as filter and alarm. The Output Parts contain the parts for uni-directional and cascade variables. The output parts can also contain optional parts such as limit and alarm. The Body contains the attributes and methods that are unique to the particular block class. It can also contain optional parts such as feedback tuner and deadtime.

The Input and Output parts are instances of the part classes and are separate and independent from the Body of the typical block class. This enables inter-operability between components by connecting the output variable of an output part to the input variable of an input part.

The configurator must instantiate a block and its mandatory and selected optional parts before it can be used or its parameters set.

Block is a parent class (superclass) to all block classes including the UserBlock class and its attributes and methods are inherited by all block classes. The UserBlock is a parent class to the Arithmetic and UserDefined classes and its attributes and methods are inherited by them. The following two sections provide a detailed functional description of the Block and UserBlock classes.

Block Class

Overview

Block is an abstract class that contains data and methods common to all blocks. It implements the Constants and Runnable interfaces. Options, mode, and status are conveyed with packed Booleans. Bit-mask definitions are contained in the Constants interface, which is inherited by most classes.

A part class, which provides a common function, may be contained in several block classes or other part classes. An optional part may be instantiated at configure time. If it is not configured, it has a "null" value in the container object.

The run method of each block is called each bpc. Its output is updated each period at a specified phase. The bpc is a configured float number in seconds, an integer number of milliseconds, preferably an integer multiple of 0.1 seconds. The nominal period is an integer number of bpcs less than or equal to the configured float blockPeriod, but at least one bpc. The execute method determines when each block updates its output based on its configured blockperiod and phase. The actual period is based on the time since the start of the last execution.

An output variable object is stored in an output part of its source block object. An input variable object of a block's input part may be linked (connected) to the output variable object by setting the input variable object equal to the output variable object. This is done at configure time with the output variable object's linkTo method, which checks for permissions.

Output variables are instances of the FloatVariable, BooleanVariable, or IntVariable classes. These contain a forw and may contain a back parameter object which are instances of the FloatParameter, Boolean Parameter, or IntParameter classes. Each of the parameter classes contains a value and two status bytes. The status bytes provide SEnsor VAlidation (SEVA) quality indications, cascade handling bits, downstream limit bits, and permissions. The parameter classes have getStatus, getValue, setValue, linkTo, and unlink methods to be used by users and tasks. The Variable classes contain alarmSum and maintenance status. The FloatVariable also contains linkTo, ack, and getAlarm methods, a range object, and the SEVA `uncertainty `. Both source and sink have access to the members of a linked Variable object.

There are two types of input objects. One is an instance of the UniDirFloatInput class, the other is an instance of the CascadeFloatInput class. The UniDirFloatInput class accepts one input variable object. It may contain charac and filter objects, used to precondition the input variable prior to its use in the block algorithm. It outputs the pv variable. The CascadeFloatInput class inherits from the UniDirFloatInput class and also receives local, remote, supervisory, and feedforward input variables in addition to the measurement input variable. It outputs pv and deviation. The CascadeFloatInput class does the local, remote, supervisory mode switching and cascade handling for bumpless transfer and initialization. It also may contain a setpoint limit object, a local setpoint ramp object, a deviation alarm object, and an additive or multiplicative fdFwd object.

There are also two types of output objects. One is an instance of the UniDirFloatOutput class, the other is an instance of the CascFloatOutput class. The UniDirFloatOutput class provides one output variable object and receives manual and supervisory input variable objects. It provides auto, manual, supervisory mode switching and may provide an output `limit` object and two output alarm objects. The CascFloatOutput inherits from the CascFloatOutput class. It also provides bumpless mode transfer and initialization. It may contain an additive or multiplicative fdFwd object and a limit object.

Attributes

tag object instance tag, a string.

description object instance description, a string.

type object instance type, a string

blockperiod is the time in seconds between output updates, float, default 0.5.

phase object instance phase, a double integer, default is 0.

Methods

run Arguments: none.

Executes object instance when invoked.

Returns: none.

UserBlock Class

Overview

An object from the UserBlock class has parts from the UniDirBoolInput, IntInput, and UniDirFloatInput classes, parts from the CascBoolOutput, CascIntOutput, and CascFloatOutput classes, and output mode parts from the Mode class.

Initialization, bumpless auto/manual/supervisory switching, and antiwindup protection are automatically provided when the user program calculates its outputFloat[i].out.forw.value by adding an incremental change to its outputFloat[i].out.back.value. Toggled booleans are treated similarly. The number of inputs, outputs, and modes are specified as the constructor arguments in the above order.

Methods from the FloatParameter, IntParameter and BoolParameter classes can be used to getValue( ), setValue( ), and getStatus( ). Methods from the FloatVariable and BooleanVariable classes can be used to getAlarm( ) and ack( ). Methods from the Mode class can be used to getMode( ) and setMode( ). Definitions of status and modes are in the Constants interface.

Attributes

inputBool is an optional array of BooleanInput parts.

outputBool is an optional array of CascBoolOutput parts.

inputFloat is an optional array of UniDirFloatInput parts.

outputFloat is an optional array of CascFloatOutput parts.

numberFloatOut number of float outputFloats specified as constructor argument.

mode is an optional array of Mode parts.

seed=100001 is an int seed number for generating the uniform (0,1) probability Distribution. Different seed numbers generate different, and statistically independent distributions.

Methods

run

Arguments: none

Called each time step to run the block.

Returns: none

runMethod contains the user written code.

Arguments: none

Called by run method

Returns: none

ranUniform

Arguments: none.

Computes uniform random number when invoked.

Returns: random number uniformly distributed between 0 and 1,

ranGauss

Arguments: none.

Computes Gausian random number when invoked.

Returns: random number distributed normally, with mean=0 and standard deviation (.delta.)=1.0, also known as the Gaussian distribution.

Composite Classes

FIG. 5 shows the implementation of composite classes in general. This section describes a library of the Nested superclass and composite classes.

Nested

Overview

Nested is an abstract class containing Strings for nested classes. It implements the Constants and Runnable interfaces. The config method prepares a comp list of its runnable components. The run method calls the run method of each composite and block on the comp list.

Attributes

tag_desc is a String composite user tag

description is a String composite brief description.

type is a String identifying the composte class.

offOn is a boolean that allows its components to run when true. Its default is false.

Methods

config

Arguments: none.

Returns: none.

run

Arguments: none.

Returns: none

Loop

Overview

Loop is a user defined nested class. It contains config and run methods, which are called by the main method.

FIG. 9 shows the Loop composite class, which contains the AnalogInput, AdvancedPID, and AnalogOutput classes connected as shown. Each time the Loop class is used to create a Loop composite object it also creates an instance of ain, pid, and aout. Each Loop composite object is created with the default attributes of the ain, pid, and aout, however, the default attributes can be overridden.

Attributes

ain is an instance of AnalogInput class.

pid is an instance of AdvancedPID class.

aout is an instance of AnalogOutput class.

comp is a ObjList of Runnable objects.

sp is the alias for the pid setpoint, a FloatParameter

pv is the alias for the pid process variable, a FloatParameter

out is the alias for the pid output, a FloatParameter

Attributes from Superclass

tag user specified Loop tag, a String

description "Secondary", a String.

type "Loop", a String.

Methods

Methods from Superclass

Config

Arguments: none.

Returns: none.

run

Arguments: none.

Returns: none

PLoop

Overview

PLoop is a user defined nested class. It contains config and run methods, which are called by the Configure class.

FIG. 10 shows the Ploop (Primary Loop) composite class, which contains the AnalogInput and AdvancedPID classes connected as shown. Each time the PLoop composite class is used to create a PLoop composite object it also creates an instance of ain and pid. Each PLoop composite object is created with the default attributes of ain and pid, however, the default attributes can be overridden.

Attributes

ain is an instance of AnalogInput class.

pid is an instance of AdvancedPID class.

comp is a ObjList of Runnable objects.

sp is the alias for the pid setpoint, a FloatParameter

pv is the alias for the pid process variable, a FloatParameter

out is the alias for the pid output, a FloatParameter

Attributes from Superclass

tag user specified Ploop tag, a String

description "Primary", a String.

type "Ploop", a String.

Methods from Superclass

config specifies internal default values and connections.

Arguments: none.

Returns: none.

run schedules and runs contained components when run is called.

Arguments: none.

Returns: none

Cascade

Overview

Cascade is a user defined nested class. It contains config and run methods, which are called by the Configure class.

FIG. 11 shows the Cascade composite class, which contains the Ploop and Loop composite classes connected as shown.

Attributes

Pri is an instance of the Ploop class.

sec is an instance of the Loop class.

comp is a ObjList of Runnable objects.

attributes from superclass

tag user specified Cascade tag, a String

description "TempCascade", a String.

type "TempCascade", a String.

Methods from Superclass

config specifies internal default values and connections.

Arguments: none.

Returns: none.

run schedules and runs contained components when run is called.

Arguments: none.

Returns: none

User Composite Classes

The user composite classes are examples of classes that would be created by a user in the same way as the composite classes discussed above. In addition users can create their own subclasses under the superclass UserBlock shown in FIG. 4.

The remainder of this section describes the TempProcess composite class, which is used to create instances that simulate a process, which provides temperature and flow measurements.

TempProcess

Overview

FIG. 12 shows the TempProcess user composite class, which contains two ProcessSim classes connected as shown. Each time the TempProcess composite class is used to create a TempProcess composite object it also creates an instance of flow and temp. Each TempProcess composite class is created with the default attributes of flowOut and tempOut, however, the default attributes can be overridden. The flow process is a one time step delay (0.5 sec.) and the temperature process is a 10 sec. delay.

Attributes

flow is a ProcessSim block with 1 input.

temp is a ProcessSim block with 1 input.

comp is a ObjList of Runnable objects.

FlowOut is the output of the flow process, a FloatVariable.

TempOut is the output of the temp process, a FloatVariable.

Attributes from Superclass

tag user specified TempProcess tag, a String

description is the String "Temperature Process".

type is the String "TempProcess".

Methods

config specifies internal default values and connections.

Arguments: none.

Returns: none.

run schedules and runs contained components when run is called.

Arguments: none.

Returns: none

Supv

Overview

Supv is a user defined class derived from the UserBlock class. It contains a run method. It has one floatOut and no inputs. It contains the controller parameters and ramps its output, used as the supervisory setpoint of the temperature controller.

Attributes

parTC is a PlDParameters part that contains parameters for the temperature controller.

ParFC is a PlDParameters part that contains parameters for the flow controller.

Attributes from Superclass

tag user specified Supv tag, a String

description is the String "Supervisory Setpoint".

type is the String "Supv".

Methods from Superclass

run

Arguments: none

Called each time step to run the block.

Returns: none

runMethod contains the user written code.

Arguments: none

Called by run method

Returns: none

Process Control Application Classes

The Block, Composite, and UserComposite classes can be used to create many object instances, which are simply referred to as composite objects or composites. An application instantiates and configures the composite objects using the config method and then executes them using the run method. The config method prepares a comp list of its runnable composites. The run method calls the run method of each composite on the comp list. The following two sections present the Loops2 and TempCasc applications.

Loops2

The Loops2 application illustrates composite objects for control and process simulation, which are made up of block objects.

Overview

FIG. 13 shows the Loops2 control composite objects and the process composite object, while FIG. 8.4.1-2 shows the same composites in detail. Application Loops2 uses the config method to instantiate (configure) composite objects s21, tl21, fl21, and pr21 and the run method to schedule them for execution.

Composite object s21 (Supervisor 21) is an instance of the Supv block class described in Sec. 8.3.2. It acts as a supervisory component and its output s21.out sets the temperature setpoint tl21.sp of Temp Loop tl21.

Composite object tl21 is an instance of the PLoop component class shown in FIG. 10 and is a single loop made up of block instances ain, and pid. Temp Loop 21 compares the temperature measurement value tl21.pv to the temperature setpoint tl21.sp and computes tl21.out, which sets the required steam flow setpoint fl21.sp

Composite object fl21 (Flow Loop 21) is an instance of the Loop composite class shown in FIG. 9 and is a single loop made up of block instances ain, pid, and aout. Flow Loop 21 compares the steam flow measurement value fl21.pv to the required steam flow setpoint fl21.sp and computes the required steam valve position fl21.out, which sets process variable pr21.pv

Composite object pr21 (Process 21) is an instance of the TempProcess composite class shown in FIG. 8.3.1-1 and simulates the temperature process. Process 21 uses process variable pr21.pv and computes the resulting steam flow fl21.pv and temperature tl21.pv.

Object ic21 is an instance of the InfoCollect block class. Object ic21 collects the date/time, value, and status for 10 (configurable) samples of tl21.pv, tl21.sp, fl21.pv, fl21.sp, and fl21.out. Each of these objects is double-buffered and when one buffer fills it switches to the other, which it overwrites.

Attributes

s21 is a Supv block.

tl21V1 is version 1 of a Ploop composite.

tl21 is an alias for a Ploop composite.

tl21V2 is version 2 of a Ploop composite

fl21 is a Loop composite.

pr21 is a TempProcess composite.

ic21 is an InfoCollect block.

comp is a ObjList of Runnable objects.

Methods

config overrides default values and makes external connections.

Arguments: none.

Returns: none.

run schedules Loop2 objects and calls their run methods.

Arguments: none.

Returns: none

TempCasc

The TempCasc application illustrates the cascade composite object for control, which is made up of component (composite) objects, while the process composite is made up of block objects.

Overview

FIG. 13 shows the TempCascade composite object and process, while FIG. FIG. 14 shows the same components in detail. Application TempCasc uses the config method to instantiate composite objects s21, tc21 and pr21, and the run method to schedule them for execution.

Composite object s21 (Supervisor 21) is an instance of the Supv block class described in Sec. 8.3.2. It acts as a supervisory component and its output s21.out sets the temperature setpoint tc21.sp of Temp Loop tc21.

Composite object Temp Cascade 21, tc21, is an instance of the Cascade composite class shown in FIG. 8.2.5-3 and is a cascade loop made up of Ploop instance pri, and Loop instance sec.

Temp Cascade 21, tc21, uses measurement values tc21.pv1 and tc21.pv2 and temperature setpoint tc21.sp and computes the required steam valve position out21.

Composite object pr21 (Process 21) is an instance of the TempProcess component class shown in FIG. 8.3.1-1 and simulates the temperature process. Process 21 uses process variable pr21.pv and computes the resulting steam flow fl21.pv and temperature tl21.pv.

Object ic21 is an instance of the InfoCollect block class. Object ic21 collects the date/time, value, and status for 10 (configurable) samples of tc21.sp, tc21.pv1, tc21.pv2, and fl21.out. Each of these objects is double-buffered and when one buffer fills it switches to the other, which it overwrites.

Attributes

s21 is a Supv block.

tc21 is a Cascade composite.

pr21 is a TempProcess composite.

comp is a ObjList of Runnable objects.

Methods

Config overrides default values and makes external connections.

Arguments: none.

Returns: none.

Run schedules TempCasc objects and calls their run methods.

Arguments: none.

Returns: none

Information Collection Objects

The purpose of information objects is to collect information for date/time, bool, int, and float parameters, alarmSum, and modes.

The purpose of InfoCollect objects is to collect a specified number of samples for the date/time, value, and status of a specified number of bool and float parameters, alarmsSum, and mode. The samples are collected in two buffers. When one buffer fills data storage is switched to the other.

An object from the InfoCollect class has paramBool parts from the BoolParameter class, paramInt parts from the IntParameter class, paramFloat parts from the FloatParameter class, actual mode parts from the Mode class, and alarmSum short integers.

Methods from the source FloatParameter and BoolParameter classes can be used to linkTo( ).

An object from the Event class may have a paramBool part from the BoolParameter class, paramInt parts from the IntParameter class, aparamFloat part from the FloatParameter class, an actual mode part from the Mode class, and an alarmSum short integer.

Methods from the BoolParameter, IntParameter, and FloatVariable classes can be used to linkTo( ).

Configuration

All parts that a block or part may use are declared. Mandatory parts are instantiated in the declaration or constructor, while optional parts are not. If optional parts are used, they are instantiated by the configurator. An arbitrary number of a specific part type is specified as an argument of the container's constructor method. For example, see the Supv class derived from the UserBlock in Loops2. An example of an optional part class is Filter, which is used in the CascFloatInput class.

Block classes are the lowest level classes that can be used as component classes that are optionally interconnected to create composite classes. Of course the composite classes can contain not only block classes but also other composite (component) classes, and so on. The block classes and their mandatory and optional part, signal, and inputOutput classes contain default values for each attribute.

Configuration of Composite Classes

Java code is written and compiled to create a new composite class. An already existing composite class can be instantiated and the resulting composite object can be customized to suit the application without compiling.

The code for a new composite contains name declarations of component blocks and composites. Its constructor method preferably contains calls to the component's constructor methods. A block object that may have multiple part objects from the same part class requires that the number of such part objects be specified as an argument in the block's constructor. This number may be passed from a containing composite constructor's argument.

A config method can be written that makes the internal variable and parameter connections between components and overrides default parameter value and option assignments. Connections are made and broken with linkTo and Unlink methods of the source parameter or variable. The linkto method will not succeed if the sink parameter or variable is already linked. A bidirectional cascade variable connection is made or broken with a single linkTo or Unlink method.

Each component composite's config method is called before overriding its assignments. This method may be used to instantiate new optional part objects and override their defaults. Each component block or composite is added to the composite's comp list in the order in which they are to execute.

A run method must be written. This calls in sequence the run method of each component block and composite.

After compilation any number of new composite objects can be created from this composite class in the same way as standard composite objects can be created from its library class.

The following are examples of composite classes: Loop, Ploop, Cascade, TempProcess.

Configuration of Block and Composite Object Instances

The block classes, the composite classes, and the user composite classes can be used to configure as many block and composite object instances as desired without recompiling provided there is a capable configure process.

Examples of block and composite object instances: Loops2 and TempCasc.

Configuration without Compilation

A control system implemented with PCOs as described above can be configured without compilation. To this end, the following steps can be performed:

Create a configuration object which contains configured PCO objects including parameter values, initial target mode and all connections among various blocks necessary for a closed-loop control.

Download the configuration object to the field device.

Create an object file based on the configuration object.

Start PCO execution from the object file.

Change connections among PCO blocks on the fly by invoking a remote method.

Transfer PCO parameters or variables from a client (host) to a server (field device) together with a string identifying the blocks and related PCO parts and signals.

Add and remove new blocks on the fly. New blocks are instantiated in the device and added into the runList. Connections to the new blocks are made on the fly as well.

Enable PCO optional parts on the fly.

Checkpoint on demand.

Upload an object file into the configurator.

A general RMI RemoteInterface is designed to make all on-line operations listed above possible. The methods in this RemoteInterface provide a useful framework for further development. In particular, several common methods are provided to deal with the following important issues:

Access PCO Parameters and Variables via a string name and an object. The string name follows the naming convention outlined in this document.

Make connections between blocks by invoking a remote method. Sink and source of arrays can be connected by a single remote method call.

Enable any PCO optional parts of any PCO blocks by invoking a single remote method.

The implementation of these methods utilizes the Java Reflection package which is included in Java 1.1.

IEC 1131-3

The IEC 1131-3 specification requires that its Sequential Function Charts and the three different languages namely, Structured Text, Ladder Logic, and Function Blocks work in concert, that is, a user can intermix them and create a control strategy. An example is the creation of a task using Structured Test which invokes the in-line code execution of a Ladder(s) or a Function Block(s).

Referring to FIG. 4 the IEC 1131-3 functionality (Sequential Function Charts, Structured Text, Ladder Logic, and Function Blocks) is shown as a subclass(s) under the UserBlock class. The UserBlock class provides the inputs and outputs as defined by the PCO to all its subclasses, thus enabling interconnection between PCO and IEC 1131-3 objects. The IEC 1131-3 configurator then can produce Java bytecode directly, or can compile source code of another language such as structured text into Java bytecode.

Execution Environment

Process Conrol Objects are preferably run as Java applications (though, they can be run as Java applets, servlets, or the like), with each composite and block object having its own run method, which is called by the run method of the next higher level composite object. Scheduling of a thread is preferably also done in Java, though it can be performed elsewise. For example, a real-time operating system can be used for scheduling, though, it is preferably not hardware specific. The sleep interval until the next run start is determined by adding the Block Processing Cycle (BPC) time to the present desired run start time and subtracting the current time (in milliseconds).

Each thread preferably has its own object set and run methods. When device is powered up, it starts a PCO application shell. The application shell itself is a Java application. Once it gets started, it runs until device is powered down or rebooted. After the application shell starts, it periodically checks for messages sent from a host running the configurator. In the illustrated embodiment, it understands three types of messages, FileCreation, Commit and Checkpoint.

FileCreation

This message is sent when the OK button is pressed. Once this message is received, the application shell serializes the configuration object to a file in the local file system of the device.

Commit

This message is sent when the Commit button is pressed. Once this message is received, the application shell does the following:

(1) Load the object file from the file system with the file name given in the message;

(2) Loop through the HashTable built in configuration object to identify all blocks;

(3) Make the block objects available to the remote object;

(4) Start a control thread which executes each object in the runList.

Checkpoint

This message is sent when the Checkpoint button is pressed. Once this message is received, the application shell serializes the current configuration object into a file in the local file system. This file is the checkpoint file which can be transferred to any computer via FTP.

Verification and Validation

Verification and validation of control blocks can be implemented in the manner described in copending, commonly assigned U.S. patent application Ser. No. 09/345,215, filed Jun. 30, 1999, and its counterpart PCT Application Serial No. US00/16152, filed Jun. 9, 2000, both entitled Process Control and Method with Auto-Updating, the teachings of which are incorporated herein by reference,

Platform Communications

Intra-Platform Communication

A cascaded FloatVariable, IntVariable or BoolVariable requires that some of its fields (subobjects) be communicated downstream (forw, alarmSum, uncertainty, maintenance) and others upstream (back, range). All unidirectional variable fields are communicated downstream. Intra-platform communication is done by reference. Variables are stored in an output part of the upstream block and linked to the downstream block with a linkTo( ) method called at configure time. There is also an unLink( ) method that can be called to reconfigure.

Objects are not moved from place-to-place within a platform. Input and output signals are instances of the xxVariable class. Variable linking is discussed above. "Constants" such as a gain or time constant are instances of the FloatParameter class. A FloatParameter can be linked to a forw or back parameter of a FloatVariable with a linkTo( ) method. Each Parameter (such as forw and back) has two status bytes, one is enumerated providing SEVA (clear/blind etc. instead of good/bad) status and cascade status, the other a packed Boolean containing limit bits and linking and setting permission status bits.

Cascade Peer-to-Peer Communication

Block-to-block input-output Variable connections within a station are made by reference. Although the data resides in the upstream block, either block may be the source for a particular attribute. Thus in a cascade (one-to-one) connection, the forw Parameter (value, status, limStatus) and alarmSum are set by the upstream block and the back Parameter and Range are set by the downstream block. The upstream block sets all of the unidirectional Variable attributes.

When the upstream and downstream blocks are in different stations, both unidirectional and bidirectional communication is more complicated. A copy (proxy) of the Variable (or Parameter) that resides in the upstream block must also exist in the downstream block. A cascade Variable must be split into its forward- and back-propagated Parameters. If push (publish-subscribe) communications are used, the source station needs a publish list of the source object references and a source String names (topics). The sink object needs a subscribe list of the sink object references (proxies) and source object String names (topics).

FIG. 17 shows an example of cascade peer-to-peer communication. The cascade control loop consists of AIN1 and PID1 that make up the temperature loop TL1 and AIN2 and PID2 that make up flow loop FL2. TL1 is in device NCAP1 and FL2 is in device NCAP2. In the forward direction from PID1 to PID2, output OUT of PID1 sets the remote setpoint RSP of PID2. In the backward direction from PID2 to PID1, output BACK of PID2 sets the BACK of PID1.

Each device has a Publisher and a Subscriber list and a CommsAPI. Each publisher and subscriber list contains references and topics. The topics are strings indicated in quotes.

Consider the communication in the forward direction from PID1 to PID2. Publisher1 shows reference PID1.OUT, which points to the actual parameter object OUT that needs to be transferred to its subscriber(s) and its corresponding topic "PID1.OUT". This topic is subscibed to by Subscriber2, which shows topic "PID1.OUT" and reference PID1Proxy.RSP. This reference points to the actual parameter proxy object PID1Proxy.RSP where the required parameter object is transferred to. Controller PID2 references this object and uses it when it executes.

Now consider the communication in the back direction from PID2 to PID1. Publisher2 shows reference PID1Proxy.BACK, which points to the actual parameter object that needs to be transferred to its subscriber(s) and its corresponding topic "PID1.BACK". This topic is subscibed to by Subscriber1, which shows topic "PID1.BACK" and reference PID1.BACK. This reference points to the actual parameter object BACK where the required parameter object is transferred to.

PCO Object Based Transfer

There are two types of communications transfer cascade and unidirectional.

Cascade transfer for peer-to-peer inter-platform communication requires transfer of parameters (value, status, limStatus, time). The previous section provides an example of transfer of parameters for cascade transfer.

Unidirectional transfer for peer-to-peer inter-platform communication requires transfer of variables (forw parameter, range, uncertainty, maintenance, alarmSum).

Object transfer as opposed to fundamental data type allows more information to be transferred in each message, therefore fewer messages and a smaller lookup table. Periodic transfers can be done using publish-subscribe services. One-to-one event driven transfers can be done with client-server services.

Peer-to-peer requires transfer of parameters (value, status, limStatus, time) for cascade transfer or variables (forw parameter, range, uncertainty, maintenance, alarmSum) for unidirectional transfer. Assuming publish-subscribe, each published object must have a unique string name that the subscribing device can recognize.

Operator display requires a trend object (setpoint, measurement, output forw parameters and input and output modes). Publish-subscribe may be used for this also. User setpoint, output, and mode changes can be transmitted using RMI.

Block details require transfer of an object containing the part parameters on each open window each time one changes. Settable changes can be transmitted using RMI.

Configuration requires the streaming of a PCO configuration or checkpoint file. Also it is necessary to be able to invoke remote methods with object arguments.

A historian can receive InfoCollect buffer objects.

FIG. 18 provides a summary of the variable and parameter transfer and rules.

Discussion

Blocks structured with a body and one or more input and output parts. Each cascade input part supports local/remote/supervisory switching, setpoint limiting, matched characterization, additive or multiplicative feedforward (bias or ratio setpoint), pv (process variable) output, measurement (in) filtering, deviation 9pv-sp), alarming, and support for bumpless initialization and antiwindup recovery from downstream limiting. Each output part supports manual/auto, supervisory switching, output limiting and alarming, additive or multiplicative feedforward, and bumpless initialization and antiwindup recovery from downstream limiting.

Variables are alarmed at their source and alarm status is communicated to sinks as part of the variable. Range is specified at a measurement source and communicated to sinks as part of the variable. Cascaded range is transmitted upstream. Blocks are the lowest level objects that are recognized at the system level. Each block and its parts must reside in a single station or device. Composites may span stations or devices.

Parts Classes

This section describes the part classes, which are contained in the Parts package. A Part must be contained in a block or other part contained in a block. Each block may have one or more input parts, a body, and one or more output parts. Input and output Part classes contain or reference either FloatVariable, BoolVariable, or IntVariable signals which enable uni-directional or bi-directional communication between blocks.

An unused optional part has a null reference. The configurator must instantiate an optional part before it can be used or its parameters set.

UniDirFloatInput

Overview

UniDirFloatInput is a measurement path input interface part that initializes and applies charactization, and filtering to its in signal.

Attributes

in is a reference to a FloatVariable source. in.forw.value is in eng. units.

charac is a reference to an optional signal Characterizer. charac.xPt[i] and charac.yPt[i] are breakpoint coordinates, float values.

filter is a reference to an optional signal Filter.

options is a packed boolean byte with:

I_O in is provided from device and point

device is the String name of an i/o device that is the source of in.

point is an integer used to identify an i/o address within the device.

pv is a Float Variable output representing the processed in value.

gain is a FloatParameter that multiplies pv.

dtime is a reference to an optional Deadtime part.

Methods for Developer

UniDirFloatInput (constructor)

Arguments: none.

Returns: none.

startup

Arguments: none

tests span.

Returns: true if ready to run.

CascFloatInput

Overview

CascFloatInput is an input interface part that provides initialization, local/remote/supervisory switching, optional setpoint limiting, optional local or supervisory setpoint ramping, optional deviation alarming, and an optional multiplicative or additive feedforward input.

Its internal methods are called by its container block.

startup( ) Called when out-of-service, returns true if ready to run.

inHandle( ) Sets back values and status, processes in.

locRemTarget( ) Determines the internal target mode.

devHandle(period) Handles setpoint and deviation.

initialize( ) Provides bumpless mode transitions.

modeHandle( ) Provides functionality for active mode.

limitStatus(lim) Propagates limit bits to back.status.

Attributes

remSP is an optional reference to the source of the remote setpoint FloatVariable.

supvSP is an optional reference to the source of the supervisory setpoint, a FloatVariable.

lrs is the setpoint local/remote/supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:

O_S Block is out of service

INITIALIZE Transition actual mode enables bumpless transfer to target mode

LOCAL Operator or set method can set sp.

REMOTE External block (remSP) sets setpoint.

SUPER Supervisory task (supvSP) sets setpoint.

LINKED Permitted attribute indicates target connected to external source.

fdFwd is an optional reference to the source of a Feedforward object.

fdFwd.ff is a reference to the source of a FloatVariable.

fdFwd.gain is a FloatParameter gain applied to fdFwd.ff

ramp is an optional reference to the source of a Ramp object.

ramp.rateDn is a positive FloatParameter specifying the rate down.

ramp.rateUp is a positive FloatParameter specifying the rate up.

ramp.target is a FloatParameter that contains the termination value.

ramp.trigger is a BoolParameter that starts the ramp.

limit is an optional reference to the source of a setpoint Limit object.

limit.hi is the high limit, FloatParameter

limit.lo is the low limit, FloatParameter

alarmDevi is an optional reference to the source of a deviation Alarm object.

alarmDev.hi is the high alarm limit a FloatParameter.

alarmDev.lo is the low alarm limit, a FloatParameter.

alarmDev.hys is the alarm hysteresis, a FloatParameter.

alarmDev.delay is an optional alarm delay in seconds, a FloatParameter

alarmDev.noAck is a boolean, alarm requires no acknowledge if true.

sp is a FloatVariable representing the current setpoint. In the LOCAL mode sp can be set

deviation is a FloatVariable output representing in--sp. It can be alarmed.

Attributes from Super Class

in is a reference to a FloatVariable source. inforw.value is in eng. units.

charac is a reference to an optional signal Characterizer.

charac.xPt[i] and charac.yPt[i] are breakpoint coordinates, float values.

filter is a reference to an optional signal Filter.

options is a packed boolean byte with bits assigned as:

SP_PV_TRK_MAN Setpoint tracks PV when output is manually set.

SP_DN_UNCER Setpoint is decreased by the uncertainty.

SP_UP_UNCER Setpoint is increased by the uncertainty.

MULT_FF Feedforward is multiplicative, else it is additive.

device is the String name of an i/o device that is the source of in.

point is an integer used to identify an i/o address within the device.

pv is a Float Variable output representing the processed in value.

Methods for Developer

CascFloatInput (constructor)

Arguments: none.

Instantiates sp and deviation.

Returns: none.

startup

Arguments: none.

Called when out-of-service.

Returns: true if ready to run.

inHandle

Arguments: none.

Sets back values and status, processes in and feedforward.

Returns: none.

locRemTarget

Arguments: none.

Determines the internal target mode.

Returns: none.

devHandl

Arguments: period is the time since the last update in seconds, a double.

Handles setpoint and deviation.

Returns: none

initialize

Arguments: none.

Provides bumpless mode transitions

Returns: none.

modeHandle

Arguments: none.

Provides functionality for active mode.

Returns: none.

limitStatus

Arguments: lim holds limit bits to be propagated upstream, an integer.

Propagates limit bits to back.status.

Returns: none.

UniDirFloatOutput

Overview

UniDirFloatOutput is an output interface part that provides auto/manual/supervisory switching, optional out limiting, optional out alarming, and an optional multiplicative or additive feedforward input.

Its methods are called by its container block.

startup( ) Called when out-of-service, returns true if ready to run.

manAutoTarget( ) Determines the internal target mode.

modehandle(period) Provides functionality for active mode.

Attributes

fdFwd is an optional reference to the source of a Feedforward object.

fdFwd.ff is a reference to the source of a FloatVariable.

wd.gain is a FloatParameter gain applied tofdFwd.ff.

supvOut is an optional reference to the source of the supervisory output, a FloatVariable.

mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:

O_S Block is out of service

INITIALIZE Transition actual mode enables bumpless transfer to target mode

MANUAL Operator or set method can set out.

AUTO Block algorithm sets out.

SUPER Supervisory task (supvSP) sets setpoint.

LINKED Permitted attribute indicates target connected to external source.

INTERLOCK interlock.in sets out when interlock.trigger is true.

options is a packed boolean byte with bits assigned as:

LIM_MAN Limits are applied to manual output.

ALM_MAN Alarming is applied to a manual output.

MAN_START Block returns from out-of-service in MANUAL mode.

MULT_FF Feedforward is multiplicative, else it is additive.

ALARM_BLURRED Block alarm triggered by BLURRED signal status.

I_O out is provided to device and point.

limit is an optional reference to the source of an out Limit object.

limit.hi is the high limit, FloatParameter

limit.lo is the low limit, FloatParameter

alarmHi is an optional reference to the source of an out Alarm object.

alarmHi.hi is the high alarm limit, a FloatParameter.

alarmHi.lo is the low alarm limit, a FloatParameter.

alarmHi.hys is the alarm hysteresis, a FloatParameter.

alarmHi.delay is an optional alarm delay in seconds, a FloatParameter

alarmHi.noAck is a boolean, alarm requires no acknowledge if true.

alarmHiHi is an optional reference to the source of an out Alarm object.

alarmHiHi.hi is the high alarm limit, a FloatParameter.

alarmHiHi.lo is the low alarm limit, a FloatParameter.

alarmHiHi.hys is the alarm hysteresis, a FloatParameter.

alarmHiHi.delay is an optional alarm delay in seconds, a FloatParameter

alarmHiHi.noAck is a boolean, alarm requires no acknowledge if true.

interlock is an optional object used to invoke an override of the current Mode.

interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode.

interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false.

interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.

device is the String name of an i/o device that is the sink of out.

point is an integer used to identify an i/o address within the device.

out is a FloatVariable representing the current output. In the MANUAL mode out can be set

fbk is the integral feedback input, a FloatParameter, which is connected by default to out.back if it is connected externally, otherwise to out.forw.

Methods for Developer

UniDirFloatOutput (constructor)

Arguments: none.

Instantiates out.

Returns: none.

startup

Arguments: none.

Attributes from Super Class

FdFwd is an optional reference to the source of a Feedforward object.

fdFwd.ff is a reference to the source of a FloatVariable.

fdFwd.gain is a FloatParameter gain applied to fdFwd.ff.

supvOut is an optional reference to the source of the supervisory output, a FloatVariable.

mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:

O_S Block is out of service

INITIALIZE Transition actual mode enables bumpless transfer to target mode

MANUAL Operator or set method can set out.

AUTO Block algorithm sets out.

SUPER Supervisory task (supvSP) sets setpoint.

LINKED Permitted attribute indicates target connected to external source.

INTERLOCK interlock.in sets out when interlock.trigger is true.

options is a packed boolean byte with bits assigned as:

LIM_MAN Limits are applied to manual output

ALM_MAN Alarming is applied to a manual output.

MAN_START Block returns from out-of-service in MANUAL mode.

MULT_FF Feedforward is multiplicative, else it is additive.

ALARM_BLURRED Block alarm triggered by BLURRED signal status.

limit is a reference to the source of an out Limit object.

limit.hi is the high limit, FloatParameter

limit.lo is the low limit, FloatParameter

alarmHi is an optional reference to the source of an out Alarm object.

alarmHiHi is an optional reference to the source of an out Alarm object.

alarmHiHi.hi is the high alarm limit, a FloatParameter.

alarmHiHi.lo is the low alarm limit, a FloatParameter.

alarmHiHi.hys is the alarm hysteresis, a FloatParameter.

alarmHiHi.delay is an optional alarm delay in seconds, a FloatParameter

alarmHiHi.noAck is a boolean, alarm requires no acknowledge if true.

interlock is an optional object used to invoke an override of the current Mode.

interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode.

interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false.

interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.

device is the String name of an i/o device that is the sink of out.

point is an integer used to identify an i/o address within the device.

out is a FloatVariable representing the current output. In the MANUAL mode out can be set

Methods for Developer

CascFloatOutput (constructor)

Arguments: none.

Instantiates out and limit.

Returns: none.

manAutoTarget

Arguments: none.

Determines the internal target mode

Returns: none.

bkCalc

Arguments: none.

Compensates integral feedback for feedforwards.

Returns: none.

initialize

Arguments: none.

Provides bumpless mode transitions.

Returns: none.

Methods from Super Class

startup

Arguments: none.

Called when out-of-service, returns true if ready to run.

Returns: none.

modeHandle

Arguments: period is the time since the last update in seconds, a double.

Provides functionality for active mode.

Returns: none.

Alarm

Overview

Alarm is an optional part for all outputs. Its float method is func(x,type,period) where type is true for HH and LL, false for HI and LO. Its boolean method is func(x,period). Alarm reporting can be delayed if the optional delay parameter is not null or inhibited if inhib is true.

Attributes

hi is the high alarm limit, a FloatParameter.

lo is the low alarm limit, a FloatParameter.

hys is the alarm hysteresis, a FloatParameter.

lim is the boolean alarm state, a BoolParameter.

lim is an optional output, true if alarm is active, a BoolParameter.

delay is an optional alarm delay in seconds, a FloatParameter.

noAck is a boolean, alarm requires no acknowledge if true.

inhib is a boolean, inhibits alarm if true.

Methods for Developer

Alarm (constructor)

Arguments: none, signifying a float alarm.

Returns: none.

Alarm (constructor)

Arguments: r is a FloatRange.object used to set the alarm limits.

Returns: none.

Alarm (constructor)

Arguments: b is a boolean signifying a boolean alarm.

Returns: none.

func

Arguments: x is the alarmed BoolVariable.

period is the time since the last update in seconds, a double blurAl

Returns: none.

func

Arguments: x is the alarmed BoolVariable.

period is the time since the last update in seconds, a double blurAl

Returns: none.

Characterizer

Overview

Characterizer is an optional part class used in the CascFloatInput part, UniDirFloatInput part, LinearFlow part, and ProcessSim block classes. Its method is y=func(x). The number of breakpoints is specified as the constructor argument.

Attributes

xPt[i] and yPt[i] are breakpoint coordinates, float values.

Methods for Developer

Characterizer (constructor)

Arguments: nPt is an int number of (xPt, yPt) break points.

Returns: none.

Func

Arguments: u. is the input to the function, a double (x if forw is true).

Forw is true if u=x, v=y, else u=y, v=x.

Returns: v is the output of the function, a double (y if forw is true)

FeedForward

Overview

Feedforward is an optional part class used in CascFloatInput, CascFloatOutput, and UniDirFloatOutput classes. It provides multiplicative or additive compensation for the input. Its methods are f=forwFunc(f, mult, out) and b=backFunc(b,mult), where mult and out are booleans indicating if true that the compensation is multiplicative and applied to output respectively.

Attributes

ff is a reference to the source of a FloatVariable.

Gain is a FloatParameter gain applied to ff

Methods for Developer

Feedforward (constructor)

Arguments: none.

Returns: none.

ForwFunc

Arguments: sig is the internal pre feedforward out.forw.value, a double.

mult is true if feedforward is multiplicative.

out is true if the feedforward is an output part. Then a multiplicative feedforward is normalized with its high-range value.

Returns: the prelimited out forw.value, a double.

backFunc

Arguments: sig=fbk.value, a double.

mult is true if feedforward is multiplicative.

Returns: the back-calculated internal fbk, a double.

Filter

Overview

Filter is a part class used in the CascFloatInput part, UniDirFloatInput part, and ProcessSim block classes. Its method is y=func(x,period). It is initialized with init(X). ##EQU1##

Attributes

FTime is the filter time in seconds, a FloatParameter.

lead is the lead time in seconds, a FloatParameter.

fType specifies the filter denomiator type,