Methods and apparatus for controlling object appearance in a process control configuration system6754885
Abstract
The invention provides improved apparatus for configuring process, environmental, industrial and other control systems. Such apparatus employs "appearance" objects (or other data and/or programming constructs) defining the appearance of configurable system components in graphical editors or other views in which the components may be depicted. "Placeholder" objects (or other constructs) persist the location, size, color, or other aspects of appearance defined by an appearance object for a configurable component in views in which it is actually depicted. By way of example, a process control configuration apparatus according to this aspect of the invention uses "configurable" objects to define blocks, loops and other components of a process control system. Appearance objects provide (or reference) icons or representations indicating how the configurable objects are to be depicted, e.g., in a configuration editor. Placeholder objects are created for each configurable object that is placed in a configuration using that editor. The placeholder objects identify the sizes, locations, colors, etc., of the icons used in the editor to represent the configurable objects.
Claims
What is claimed is:
1. Apparatus for configuring a control system, the apparatus comprising:
a plurality of objects ("configurable" objects) each defining a configurable entity, where each configurable object is associated with a specified object type,
one or more objects ("appearance" objects) that identity an appearance of one or more types of configurable objects in one or more views in which those types of configurable objects may be depicted, where each view is associated with a specified view type,
a plurality of objects ("placeholder type" objects) that, together, define valid combinations of object types and view types, where each placeholder type object defines an appearance of objects of a specified object type in views of a specified view type in which objects of object type can be displayed,
a plurality of persistent documents, each representing a configuration of configurable objects in accord with a selected one of a plurality of views in which configurable objects may be depicted, the persistent document including one or more objects ("placeholder" objects), each placeholder object identifying the location and appearance of a respective configurable object in the selected view to which that persistent document pertains, each placeholder object identifying the appearance object for that respective configurable object identifying the appearance of that configurable object in that selected view,
logic that responds to a selected one of the persistent documents by depicting configurable objects whose configuration is represented in that selected persistent document in accord with locations identified by placeholder objects included in that persistent document and with appearances identified by the respective appearance objects identified by those placeholder objects.
2. Apparatus according to claim 1, comprising a configuration editor that invokes the logic to depict a configuration represented by the persistent document.
3. Apparatus according to claim 1, wherein an appearance object identifies a graphical representation of a configurable object.
4. Apparatus according to claim 1, wherein an appearance object identifies an icon representing a configurable object.
5. Apparatus according to claim 4, wherein an appearance object identifies textual information for a configurable object.
6. Apparatus according to claim 5, wherein the textual information includes any of a name and a type of configurable object.
7. Apparatus according to claim 1, wherein an appearance object includes one or more macros identifying any of a graphical representation and textual information for a configurable object.
8. Apparatus according to claim 7, wherein the macros have values obtained from the corresponding configurable object.
9. Apparatus according to claim 1, wherein an object represents an entity within any of (i) a controlled system, (ii) the control system, (iii) a control level hierarchy, and (iv) the apparatus for configuring the control system.
10. Apparatus according to claim 9, wherein an entity includes any of a field device, control processor, block, loop, compound, historian, object type category, object connection, parameter connection, display placeholder, graphical display entity, and report.
11. Apparatus for configuring a process control system, the apparatus comprising:
a plurality of objects ("configurable" objects) each defining a configurable entity in any of (i) a controlled process, (ii) the process control system, (iii) a control level hierarchy, and (iv) the apparatus for configuring the control system, where each configurable object is associated with a specified object type,
each configurable object being associated with one or more further objects ("appearance" objects) that identify an appearance of one or more types of configurable object in one or more views in which those types of configurable objects may be depicted, where each view is associated with a specified view type,
a plurality of objects ("placeholder type" objects) that, together, define valid combinations of object types and view types, where each placeholder type object defines an appearance of objects of a specified object type in views of a specified view type in which objects of object type can be displayed,
each configurable object being associated with one or more still further objects ("placeholder" objects), each identifying the location and appearance of a respective configurable object in a selected one of a plurality of views in which that configurable object may be depicted, each placeholder object identifying the appearance object for the associated configurable object for that selected view,
logic that responds to a placeholder object by depicting the associated configurable object in accord with the appearance identified by associated appearance object and in accord with any of the location, size, color and other aspect thereof identified by associated placeholder object.
12. Apparatus according to claim 11, comprising a persistent document representing a configuration of configurable objects in accord with a selected view, the persistent document including one or more placeholder objects.
13. Apparatus according to claim 12, comprising a configuration editor that invokes the logic to depict a configuration represented by the persistent document.
14. Apparatus according to claim 13, wherein an entity includes any of a liquid device, control processor, block, loop, compound, historian, object type category, object connection, parameter connection, display placeholder, graphical display entity, and report.
15. Apparatus according to claim 13, wherein an appearance object identifies an icon representing a configurable object.
16. Apparatus according to claim 14, wherein an appearance object identifies textual information for a configurable object.
17. Apparatus according to claim 13, wherein an appearance object includes one or more macros identifying any of a graphical representation and textual information for a configurable object.
18. Apparatus according to claim 17, wherein the macros have values obtained from the corresponding configurable object.
19. Apparatus for configuring a control system, the apparatus comprising:
a plurality of objects ("configurable" objects) each defining a configurable entity, where each configurable object is associated with a specified object type,
one or more objects ("appearance" objects) that identity an appearance of one or more types of configurable objects in one or more views in which those types of configurable objects may be depicted, where each view is associated with a specified view type,
a plurality of objects ("placeholder type" objects) that, together, define valid combinations of object types and view types, where each placeholder type object defines an appearance of objects of a specified object type in views of a specified view type in which objects of object type can be displayed,
a plurality of persistent documents representing a configuration of configurable objects in accord with a one of a plurality of selected views in which configurable objects may be depicted, the persistent document comprising
one or more objects ("placeholder" objects), each placeholder object identifying the location and appearance of a respective configurable object in the selected view to which that persistent document pertains, each placeholder object identifying the appearance object for that respective configurable object identifying the appearance of that configurable object in that selected view,
one or more connector graphics depicting relationships between configurable objects,
logic that responds to a selected one of the persistent document by depicting configurable objects whose configuration is represented in that selected persistent document in accord with locations identified by placeholder objects included in that persistent document and with appearances identified by the respective appearance objects identified by those placeholder objects.
20. Apparatus according to claim 19, comprising at least one object ("connection" object) identifying any of a parent/child relationship, a source/sink relationship, and other relationship between configurable objects.
21. Apparatus according to claim 20, wherein each connector graphic depicts a relationship identified by an associated connection object.
22. Apparatus according to claim 19, wherein each configurable object is associated with one or more parameters, each parameter identifying appearance objects associated with that configurable object.
23. Apparatus according to claim 22, wherein at least one object ("descendant" object) is defined as a descendant of another object ("ancestor" object) and is associated with one or more parameters of the ancestor object.
24. Apparatus according to claim 23, including functionality that facilitates definition, during configuration, of an object as a descendant of another object.
25. Apparatus according to claim 23, wherein a change during configuration to a parameter of an ancestor object being effective as to a descendant object with which that parameter is associated.
26. Apparatus according to claim 23, wherein a descendant object is associated with the parameters of the ancestor object from which it descends, and is associated with further parameters as consequence one or more parameters definitions contained in, or associated with, the descendant object.
27. Apparatus according to claim 23, wherein a parameter identifies information for maintaining the appearance of a configurable object in a persistent document.
28. Apparatus according to claim 27, wherein a parameter identifies a graphical representation of a configurable object.
29. Apparatus according to claim 27, wherein a parameter identifies an icon representing a configurable object.
30. Apparatus according to claim 29, wherein a parameter identifies textual information for a configurable object.
31. Apparatus according to claim 30, wherein the textual information includes any of a name and type of a configurable object.
32. Apparatus according to claim 27, wherein a parameter includes one or more macros identifying any of a graphical representation and textual information for a configurable object.
33. Apparatus according to claim 32, wherein the macros have values obtained from the corresponding configurable object.
34. Apparatus according to claim 27, wherein a parameter represents an entity within any of (i) a controlled system, (ii) the control system, (iii) a control level hierarchy, and (iv) the apparatus for configuring the control system.
35. Apparatus according to claim 34, wherein an entity includes any of a field device, control processor, block, loop, compound, historian, object type category, object connection, parameter connection, display placeholder, graphical display entity, and report.
36. A method for configuring a control system, the method comprising:
establishing a plurality of objects ("configurable" objects) each defining a configurable entity, where each configurable object is associated with a specified object type,
establishing one or more objects ("appearance" objects) that identity an appearance of one or more types of configurable objects in one or more views in which those types of configurable objects may be depicted, where each view is associated with a specified view type,
a plurality of objects ("placeholder type" objects) that, together, define valid combinations of object types and view types, where each placeholder type object defines an appearance of objects of a specified object type in views of a specified view type in which objects of object type can be displayed,
defining a plurality of persistent documents, each representing a configuration of configurable objects in accord with a selected one of a plurality of views in which configurable objects may be depicted, the persistent document including one or more objects ("placeholder" objects), each placeholder object identifying the location and appearance of a respective configurable object in the selected view to which that persistent document pertains, each placeholder object identifying the appearance object for that respective configurable object defining the appearance of that configurable object in that selected view,
invoking logic that responds to a selected one of the persistent documents by depicting configurable objects whose configuration is represented in that selected persistent document in accord with locations identified by placeholder objects included in that persistent document and with appearances identified by the respective appearance objects identified by those placeholder objects.
37. A method according to claim 36, comprising invoking the logic from a configuration editor in order to depict a configuration represented by the persistent document.
38. A method according to claim 36, comprising including in an appearance object a graphical representation of a configurable object.
39. A method according to claim 36, comprising including in an appearance object an icon representing a configurable object.
40. A method according to claim 39, comprising including in an appearance object textual information for a configurable object.
41. A method according to claim 40, wherein the textual information includes any of a name and a type of a configurable object.
42. A method according to claim 36, comprising including in an appearance object one or more macros identifying any of a graphical representation and textual information for a configurable object.
43. A method according to claim 42, comprising obtaining values for the macros from the corresponding configurable object.
44. A method according to claim 36, wherein an object represents an entity within any of (i) a controlled system, (ii) the control system, (iii) a control level hierarchy, and (iv) the method for configuring the control system.
45. A method according to claim 44, wherein an entity includes any of a field device, control processor, block, loop, compound, historian, object type category, object connection, parameter connection, display placeholder, graphical display entity, and report.
46. A method for configuring a process a control system, the method comprising:
establishing a plurality of objects ("configurable" objects) each defining a configurable entity in any of (i) a controlled process, (ii) the process control system, (iii) a control level hierarchy, and (iv) the method for configuring the control system, where each configurable object is associated with a specified object type,
associating each configurable object with one or more further types of objects ("appearance" objects) that identify an appearance of the associated configurable object in one or more views in which the configurable object may be depicted, where each view is associated with a specified view type,
a plurality of objects ("placeholder type" objects) that, together, define valid combinations of object types and view types, where each placeholder type object defines an appearance of objects of a specified object type in views of a specified view type in which objects of object type can be displayed,
associated each configurable object with one or more still further objects ("placeholder" objects), each identifying the location and appearance of a respective configurable object in a selected one of a plurality of views in which that configurable object may be depicted, each placeholder object identifying the appearance object for the associated configurable object for that selected view,
invoking logic that responds to a placeholder object by depicting the associated configurable object in accord with the appearance identified by associated appearance object and in accord with any of the location, size, color and other aspect thereof identified by associated placeholder object.
47. A method according to claim 46, comprising defining a persistent document representing a configuration of configurable objects in accord with a selected view, the persistent document including one or more placeholder objects.
48. A method according to claim 47, comprising invoking the logic from a configuration editor in order to depict a configuration represented by the persistent document.
49. A method according to claim 48, wherein an entity includes any of a field device, control processor, block, loop, compound, historian, object type category, object connection, parameter connection, display placeholder, graphical display entity, and report.
50. A method according to claim 49, comprising including in an appearance object textual information for a configurable object.
51. A method according to claim 48, comprising including in an appearance object an icon representing a configurable object.
52. A method according claim 48, comprising including in an appearance object one or more macros identifying any of a graphical representation and textual information for a configurable object.
53. A method according to claim 52, comprising obtaining values for the macros from the corresponding configurable object.
54. A method for configuring a control system, the method comprising:
establishing a plurality of objects ("configurable" objects) each defining a configurable entity, where each configurable object is associated with a specified object type,
establishing one or more objects ("appearance" objects) that identity an appearance of one or more types of configurable objects in one or more views in which those types of configurable objects may be depicted, where each view is associated with a specified view type,
a plurality of objects ("placeholder type" objects) that, together, define valid combinations of object types and view types, where each placeholder type object defines an appearance of objects of a specified object type in views of a specified view type in which objects of object type can be displayed,
defining a plurality of persistent documents representing a configuration of configurable objects in accord with a one of a plurality of selected views in which configurable objects may be depicted, the persistent document comprising
one or more objects ("placeholder" objects), each placeholder object identifying the location and appearance of a respective configurable object in the selected view to which that persistent document pertains, each placeholder object identifying the appearance object for that respective configurable object identifying the appearance of that configurable object in that selected view,
one or more connector graphics depicting relationships between configurable objects,
invoking logic that responds to a selected one of the persistent documents by depicting configurable objects whose configuration is represented in that selected persistent document in accord with locations identified by placeholder objects included in that persistent document and with appearances identified by the respective appearance objects identified by those placeholder objects.
55. A method according to claim 54, comprising at least one object ("connection" object) identifying any of a parent/child relationship, a source/sink relationship, and other relationship between configurable objects.
56. A method according to claim 55, wherein each connector graphic depicts a relationship identified by an associated connection object.
57. A method according to claim 54, wherein each configurable object is associated with one or more parameters, each parameter identifying appearance objects associated with that configurable object.
58. A method according to claim 57, wherein at least one object ("descendant" object) is defined as a descendant of another object ("ancestor" object) and is associated with one or more parameters o the ancestor object.
59. A method according to claim 58, including functionality that facilitates definition, during configuration, of an object as a descendant of another object.
60. A method according to claim 58, wherein a change during configuration to a parameter of an ancestor object being effective as to a descendant object with which that parameter is associated.
61. A method according to claim 58, wherein a descendant object associated with the parameters of the ancestor object from which it descends, and is associated with further parameters as consequence one or more parameters definitions contained in, or associated with, the descendant object.
62. A method according to claim 58, comprising including in a parameter information for maintaining the appearance of a configurable object in a persistent document.
63. A method according to claim 62, comprising including in a parameter information that identifies a graphical representation of a configurable object.
64. A method according to claim 62, comprising including in a parameter information that identifies an icon representing a configurable object.
65. A method according to claim 64, comprising including in a parameter information that identifies textual information for a configurable object.
66. A method according to claim 65, wherein the textual information includes any of a name and a type of a configurable object.
67. A method according to claim 62, wherein a parameter includes one or more macros identifying any of a graphical representation and textual information for a configurable object.
68. A method according to claim 67, comprising obtaining values for the macros from the corresponding configurable object.
69. A method according to claim 62, wherein a parameter represents an entity within any of (i) a controlled system, (ii) the control system, (iii) a control level hierarchy, and (iv) the method for configuring the control system.
70. A method according to claim 69, wherein an entity includes any of a field device, control processor, block, loop, compound, historian, object type category, object connection, parameter connection, display placeholder, graphical display entity, and report.
Description
BACKGROUND OF THE INVENTION
The invention pertains to control and, more particularly, to methods and apparatus for configuring control systems.
The terms "control" and "control systems" refer to the control of a device, process 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 parameters 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. 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, control devices, and controllers, the functions of which may overlap or be combined. Field devices include temperature, flow and other sensors that measure characteristics of the device, process or system being controlled. Control devices include valves, actuators, and the like, that control the device, process or system itself.
Controllers generate settings for the control devices based on measurements from the field devices. Controller operation is typically based on a "control algorithm" that maintains a controlled system at a desired level, or drives it to that level, by minimizing differences between the values measured by the sensors and, for example, a setpoint defined by the operator.
In a food processing plant, for example, a controller can be used to maintain soup stock at a simmer or low boil. This is done by comparing measurements of vapor pressure in the processing vessel with a desired set-point. If the vessel pressure is too low, the control algorithm may call for incrementally opening the heating gas valves, thereby, driving the pressure and boiling activity upwards. As the pressure approaches the desired set-point, the algorithm requires incrementally leveling the valves to maintain the roil of the boil.
Controllers may be networked or otherwise connected to other computing apparatus that facilitate monitoring or administration. The so-called S88 industry standard, described in Batch Control--Part 1: Models and Terminology (The International Society for Measurement and Control 1995), for example, defines a hierarchy of processing and control equipment ("equipment entities") that can be used to model and control an automated manufacturing process. At the lowest level of the hierarchy are control modules that directly manipulate field devices (e.g., opening and closing valves and, possibly, other control modules. At a higher level, equipment modules coordinate the functions control modules, as well as of other equipment modules, and may execute phases of the manufacturing process (such as setting controller constants and modes). "Units," at still a higher level of the hierarchy, coordinate the functions of equipment and control modules. Process cells orchestrate all processing activities required to produce a manufacturing batch, e.g., scheduling, preparing and monitoring equipment or resources, and so forth.
The principal function of controllers is executing control algorithms for the real-time monitoring and control of devices, processes or systems. They typically have neither the computing power nor user interfaces required to facilitate the design of a control algorithm. Instead, the art has developed configurators. These are typically general purpose computers (e.g., workstations) running software that permit an engineer or operator to graphically model a device, process or system and the desired strategy for controlling it. This includes enumerating field devices, control devices, controllers and other apparatus that will be used for control, specifying their interrelationships and the information that will be transferred among them, as well as detailing the calculations and methodology they will apply for purposes of control. Once modeling is complete and tested, the control algorithm is downloaded to the controllers.
One well known process control system configurator is that provided with the I/A Series.RTM. (hereinafter, "IAS" or "I/A") systems, marketed by the assignee hereof These provide a graphical interface (FoxCAE) permitting an engineer to model a process hierarchically and to define a control algorithm from that hierarchy. Multiple editors are provided for defining and modifying modules within the hierarchy.
Though prior art process control configuration systems, particularly, the IAS systems and others sold by the assignee hereof, have met wide acceptance in the industry, there remains room for improvement. Such is the case, for example, with respect to the configuration of complex control systems.
In this context, an object of the present invention is to provide improved methods and apparatus for control and, particularly, for configuring control systems. A related object of the invention is to provide methods and apparatus for configuring process control systems.
A further object of the invention is to provide such methods and apparatus as facilitate configuring large or complex control systems
Still yet a further object of the invention is to provide such methods and apparatus as can be used in configuring a range of control systems, whether hierarchical or not, whether pertaining to process control or otherwise.
SUMMARY OF THE INVENTION
The foregoing objects are among those attained by the invention which provides, in one aspect, improved apparatus for configuring process, environmental, industrial and other control systems. Such apparatus employ "appearance" objects (or other data and/or programming constructs) defining the appearance of configurable system components in graphical editors or other views in which the components may be depicted. "Placeholder" objects (or other constructs) persist the location, size, color, or other aspects of appearance defined by an appearance object in displays, reports, depictions, presentations and other view (collectively, hereinafter, "views") in which the corresponding configurable component is actually depicted.
By way of example, a process control configuration apparatus according to this aspect of the invention uses "configurable" objects to define blocks, loops and other components of a process control system. Appearance objects provide (or reference) icons or representations indicating how the configurable objects are to be depicted, e.g., in a configuration editor. Placeholder objects are created for each configurable object that is placed in a configuration using that editor.
The placeholder objects identify the sizes, locations, colors, etc., of the icons used in the editor to represent the configurable objects.
Further aspects of the invention provide a configuration apparatus as described above in which the appearance objects identify labels or other textual information, e.g., configurable object names or types, for display with icons or other appearance indictors in the appearance objects. According to related aspects of the invention, those labels, as well as the icons themselves, can be specified using macros. Thus, for example, an appearance object can include macro strings, such as "$NAME", "$TYPE", "$ICON", that are replaced subsequent to configuration, e.g., with a configurable object name, type and icon, respectively.
The invention provides, in other aspects, apparatus as described above in which each configurable object has one or more parameters that identify the appearance of that object in views in which it may appear. The parameters may refer to appearance objects (or other constructs) as described above or they may contain appearance information (e.g., icons and textual identifiers) themselves.
The configurable objects of such an apparatus can be associated with one another in a hierarchical relationship, such that at least one such object is a descendant of another. Descendants, according to this aspect of the invention, inherit parameters from their ancestors. Accordingly, icons or other appearance information identified in a "parent" configuration object is passed on to its children. Inherited information may be overridden, according to aspects of the invention.
Still further aspects of the invention provide apparatus as described above comprising persistent documents that contain placeholder objects. Each persistent document may represent a specific configuration, e.g., created by a specific editor and displayed in accord with a selected view. Thus, for example, the configuration of a process control system may be represented in several documents, each edited by control algorithm diagram editor, covering different portions of the system.
In addition to placeholder objects, the persistent document may contain connector graphics that depict relationships between configurable objects. In an apparatus used for configuring process control systems, such a graphic may indicate, for example, that one configurable object, e.g., representing an analog input block, is a source for another configurable object, e.g., representing a PID controller. Such connector graphics can represent peer-to-peer relationships (such as source/sink relationships), in addition to hierarchical relationships (such as parent/child relationships).
Further aspects of the invention provide apparatus as described above for configuring process control systems. In such apparatus, configurable objects can, for example, represent entities within any of (i) a controlled process, (ii) the process control system, (iii) the apparatus for configuring the process control system, (iv) a level in a control level hierarchy, such as the aforementioned S88 standard. Such entities include, by way of non-limiting example, field devices, control processors, blocks, loops, compounds, historians, object type category, display placeholders, graphical display entities, and reports.
Still further aspects of the invention provide methods paralleling the apparatus described above.
These and other aspects of the invention are evident in the drawings, the claims, and in the detailed description that follows.
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 digital data processing environment of the type in which the invention is practiced;
FIG. 2 depicts a process control system of the type with which the invention is practiced;
FIG. 3 depicts control algorithm configurator components in a system according to the invention;
FIG. 4 depicts component interaction in a system according to the invention;
FIG. 5 depicts an IDA framework object model in a system according to the invention;
FIG. 6 depicts an object model notation used in this application;
FIG. 7 depicts a parameterized object model in a system according to the invention;
FIG. 8 depicts parameter group inheritance in a system according to the invention;
FIG. 9 depicts a parameterized object example in a system according to the invention;
FIG. 10 depicts the creation of a parameter list in a system according to the invention;
FIG. 11 depicts a parameter definition editor in a system according to the invention;
FIG. 12 is a parameter editor example in a system according to the invention;
FIG. 13 depicts object types in a system according to the invention;
FIG. 14 depicts an object type hierarchy in a system according to the invention;
FIG. 15 depicts the creation of new object types in a system according to the invention;
FIG. 16 is a type awareness example in a system according to the invention;
FIG. 17 depicts a connection object model in a system according to the invention;
FIG. 18 depicts a parameterized object override endpoint triad in a system according to the invention;
FIG. 19 depicts an object connection type object model in a system according to the invention;
FIG. 20 is an example of simultaneous parent/child object connectivity in a system according to the invention;
FIG. 21 depicts a parameter connection type object model in a system according to the invention;
FIG. 22 is an example of simultaneous source/sink parameter connectivity in a system according to the invention;
FIGS. 23-25 are parent/child connectivity examples in a system according to the invention;
FIG. 26 is a source/sink connectivity example in a system according to the invention;
FIG. 27 depicts an appearance object model in a system according to the invention;
FIG. 28 is an appearance definition example in a system according to the invention;
FIG. 29A depicts a placeholders object model in a system according to the invention;
FIG. 29B depicts a combined appearance and placeholder object model in a system according to the invention.
FIG. 30 depicts a MFC document/view architecture in a system according to the invention;
FIG. 31 depicts an IDA application class architecture in a system according to the invention;
FIG. 32 depicts an IDA document architecture in a system according to the invention;
FIG. 33 depicts IDA hierarchy classes in a system according to the invention;
FIG. 34 depicts IDA view classes in a system according to the invention;
FIG. 35 depicts IDA frame classes in a system according to the invention;
FIG. 36 depicts a sheet templates object model in a system according to the invention;
FIG. 37 depicts a sample use of macros in sheet template in a system according to the invention;
FIG. 38 depicts a sheet template editor in a system according to the invention;
FIG. 39 depicts an IDA report manager object model in a system according to the invention;
FIG. 40 depicts the application of filter rules to POC in a system according to the invention;
FIG. 41 depicts a filter editor in a system according to the invention;
FIG. 42 depicts a composite report template editor in a system according to the invention;
FIG. 43 depicts a report editor in a system according to the invention;
FIG. 44 depicts organizational folders in a system according to the invention;
FIG. 45 depicts version control basic concepts in a system according to the invention;
FIG. 46 depicts an object check out in a system according to the invention;
FIG. 47 depicts an check in a system according to the invention;
FIG. 48 depicts a revision editor in a system according to the invention;
FIG. 49 depicts a create revision dialog box in a system according to the invention;
FIG. 50 depicts parameterized object versions in a system according to the invention;
FIG. 51 depicts a version control object model in a system according to the invention;
FIG. 52 depicts a version history in a system according to the invention;
FIG. 53 depicts an object compare utility in a system according to the invention;
FIG. 54 depicts an historical archive with playback macro in a system according to the invention;
FIG. 55 depicts performing a macro playback in a system according to the invention;
FIG. 56 depicts a sample audit trail report in a system according to the invention;
FIG. 57 depicts an undo manager object model in a system according to the invention;
FIG. 58 depicts an users and security object model in a system according to the invention;
FIG. 59 is an users and groups example in a system according to the invention;
FIG. 60 is a process area and assignable objects example in a system according to the invention;
FIG. 61 depicts a IDA permissions hierarchy in a system according to the invention;
FIG. 62 depicts a switch group/user capability in a system according to the invention;
FIG. 63 depicts managing groups in a system according to the invention;
FIG. 64 depicts assigning users to groups in a system according to the invention;
FIG. 65 depicts groups, object types and permissions in a system according to the invention;
FIG. 66 depicts managing process areas in a system according to the invention;
FIG. 67 depicts groups and process area permissions in a system according to the invention;
FIG. 68 depicts a system tree view in a system according to the invention;
FIG. 69 depicts a block definition editor in a system according to the invention;
FIG. 70 depicts a block definition classes in a system according to the invention;
FIG. 71 depicts a simple loop in a system according to the invention;
FIG. 72 depicts a composite block definition in a system according to the invention;
FIG. 73 depicts a composite block in loop in a system according to the invention;
FIG. 74 depicts an expanded composite block in loop in a system according to the invention;
FIG. 75 depicts a block with connections in a system according to the invention;
FIG. 76 depicts the anatomy of a block placeholder in a system according to the invention;
FIG. 77 depicts a block connection dialog in a system according to the invention;
FIG. 78 depicts template/definition internal connections in a system according to the invention;
FIG. 79 depicts template/definition exposed connections in a system according to the invention;
FIG. 80 depicts a parameter property sheet in a system according to the invention;
FIG. 81 depicts a composite block property sheet in a system according to the invention;
FIG. 82 depicts a parameter formula builder in a system according to the invention;
FIG. 83 depicts control object derivations in a system according to the invention;
FIG. 84 depicts a block object model in a system according to the invention;
FIG. 85 depicts a modifier block object model in a system according to the invention;
FIG. 86 depicts a modifier block parameter override precedence in a system according to the invention;
FIG. 87 depicts a composite block definition object model in a system according to the invention;
FIG. 88 depicts a loop template object model in a system according to the invention;
FIG. 89 depicts a simple loop object model in a system according to the invention;
FIG. 90 depicts a composite block object model in a system according to the invention;
FIG. 91 depicts a template derived loop object model in a system according to the invention;
FIG. 92 depicts object placeholder derivations in a system according to the invention;
FIG. 93 depicts persistent document object derivations in a system according to the invention;
FIG. 94 depicts a PLB to ladder relationship in a system according to the invention;
FIG. 95 depicts a ladder editor view in a system according to the invention;
FIG. 96 depicts ladder objects in a system according to the invention;
FIG. 97 depicts persistent document objects; in a system according to the invention;
FIG. 98 depicts a PLB block model in a system according to the invention;
FIG. 99 depicts a block execution scheduler editor in a system according to the invention;
FIG. 100 depicts a station statistics dialog in a system according to the invention;
FIG. 101 depicts a block execution editor object model in a system according to the invention;
FIG. 102 depicts a tag list data entry screen in a system according to the invention;
FIG. 103 depicts a tag list import from ASCII file in a system according to the invention;
FIG. 104 depicts a tag list export to ASCII file in a system according to the invention;
FIG. 105 depicts a tag list import/export from database table in a system according to the invention;
FIG. 106 depicts a tag list object model in a system according to the invention;
FIG. 107 depicts download target selection in a system according to the invention;
FIG. 108 depicts a download manager document object in a system according to the invention;
FIG. 109 depicts a download services object model in a system according to the invention;
FIG. 110 is an historian assignment overview in a system according to the invention;
FIG. 111 depicts an individual compound assignment in a system according to the invention;
FIG. 112 depicts an historian object model in a system according to the invention;
FIG. 113 depicts an enclosure group view in a system according to the invention;
FIG. 114 depicts an en closure loading view and tag assignment dialog in a system according to the invention;
FIG. 115 depicts an enclosure input/output termination view in a system according to the invention;
FIG. 116 depicts an enclosure loading model in a system according to the invention;
FIG. 117 depicts an enclosure definition detail model in a system according to the invention;
FIG. 118 depicts persistent document objects in a system according to the invention;
FIG. 119 depicts an IDA main application architecture in a system according to the invention;
FIG. 120 depicts a typical IDA generic editor frame in a system according to the invention;
FIG. 121 depicts IDA & OLE compound documents in a system according to the invention.
DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT
FIG. 1 depicts a digital data processing system of the type with which apparatus and methods according to the invention may be practiced. The illustrated system is particularly adapted for use in connection with process control, as discussed further below. However, those skilled in the art will appreciate that apparatus and methods according to the invention can be used in connection with other control systems. In this regard, processes 12A, 12B can represent any industrial, manufacturing, service, environmental or other process, device or system amenable to monitoring or control (hereinafter, collectively, "control").
The system of FIG. 1 includes a workstation 11 that is coupled to one or more controllers 10A, 10B on which reside process control systems for monitoring and/or controlling one or more processes 12A, 12B. These may represent independent processes or different aspects of the same or related processes. Moreover, the processes 12A, 12B may reside within a single plant, site or area, cell or unit or, conversely, they may dispersed among many plants, sites, areas, cell or units.
Workstation 11 represents an engineering workstation, personal computer, mainframe computer or other digital data processing device suitable for operation in accord with the methods described herein for purposes of modeling a control system and configuring controllers 10A, 10B or other control or controlled apparatus in accord with the teachings herein. In a preferred embodiment of the invention, workstation 11 is an engineering workstation or personal computer executing the Windows NT operating system. Though illustrated as being carried out on workstation 11, those skilled in the art will appreciate that the modeling and configuration functions described herein can be executed on suitably configured controllers 10A, 10B (e.g., those having sufficient processing power and interfaces to provide the graphical and other configuration functions described herein).
Server 16 represents an optional additional source of classes defining objects for modeling a control system and for configuring controllers 10A, 10B (or other control or controlled apparatus) in accord with the teachings herein. This can include, for example, a retail store, warehouse or other distribution point of CDROMs, diskettes or other magnetic medium on which such classes are stored. In a preferred embodiment, however, it represents a digital data processor that functions as a server, e.g., maintained by a manufacturer or other distributor, from which such classes can downloaded to workstation 11, e.g., as part of an e-commerce transaction, for configuration prior to downloading to controllers 10A, 10B.
Network 14 provides a communications medium permitting the downloading of control algorithms and other configuration information to controllers 10A, 10B, e.g., from workstation 11. It can also of provide a medium for uploading information from controllers 10A, 10B to those other digital data processors 11, 16. Still further, it can provide a medium for communications, real-time or otherwise, between the controllers 10A, 10B and other devices, e.g., workstation 11 and server 16. Though illustrated to represent a LAN, WAN, or global network (Internet), those skilled in the art will appreciate that element 14 may represent any medium or mechanism through which control algorithms and other information may be transported, electronically, physically or otherwise, to and from controllers 10A, 10B.
An exemplary control process 12A is illustrated in greater detail in FIG. 2. It shows a process including valve 18 that governs the rate of fluid flow to aeration tank 20 which, in turn, transfers the liquid to storage tank 22. Field devices, i.e., sensors 24 and 26, monitor the state of process 12A and, thereby, facilitate its control by process control system 28 operating on controller 10A. Thus, sensor 24 is disposed in or adjacent to tank 20 for measuring the temperature of fluid therein, while sensor 26 measures the flow of fluid from aeration tank 20 to storage tank 22.
FIG. 2 further illustrates a control algorithm 28 of the type that can be configured by methods and apparatus according to the invention. The algorithm 28 is exercised by controller 10A to control process 12A. The algorithm 28 includes blocks or other entities 29, 30, 32, that model field devices, control devices and other elements within process 12A and that monitor and/or control the states and interactions between those entities.
Entities 29, 30, 32 comprise software components which may include, by non-limiting example, source, intermediate or executable code, databases, of the type conventionally used in the art for operating controllers, field devices, control devices and other process control equipment. Referenced in this regard in the discussion below are software components, and process control systems in general, marketed as the I/A Series.RTM. systems (hereinafter, "IAS" or "I/A") available from the assignee hereof. Those skilled in the art will appreciate that methods and apparatus according to the invention can be used to model processes and configure control algorithms for use with other control systems, as well.
Described below is a system, alternately referred to as the IDA Control Algorithm Configurator, the Configurator, IDA, and the like, according to one embodiment of the invention for use modeling and configuring control processes. Referring to FIG. 3, the Configurator includes a Framework, a Database, a project manager and a set of editors. The Framework provides common resources, such as menus, toolbars, dialogs, and security services, used by the editors to manipulate, display and report configuration data stored in the IDA database. In one preferred practice of the invention, the IDA Control Algorithm Configurator and Framework are packaged as a single application. This software package can be installed on either a stand-alone PC, workstation (e.g., element 11 of FIG. 1) or other digital data processor, e.g., running Windows NT or any other suitable operating system.
The editors are used by the implementation creator to create and maintain standard control scheme definition objects distributed with the implementation and by users to create their own plant control schemes. The Project Manager allows the user to browse through the project configuration hierarchies and data. Interactions among the editors and the project manager/navigator are shown in FIG. 4.
The database forms part of an object oriented database management system (OODBMS), which may be any type commercially available in the marketplace. The database can be deployed in a client/server configuration with a single centralized database per plant servicing multiple clients, or otherwise. It resides on the workstation 11, e.g., or on a digital data processor coupled therewith.
Part 1 Framework Classes
1 IDA Framework Object Model
FIG. 5 presents the primary component parts of the overall IDA Framework object model. The model may be broken into two major areas:
1. Parameterized Objects.
2. Framework Services, which are provided in order to allow controlled access to those objects, and how they might be used to display, print and otherwise manipulate Parameterized Objects.
In the discussion that follows object classes and their various associations are represented in the manner shown in FIG. 6.
1.1 Objects and Parameters
Almost all objects in IDA are parameterized--i.e., their type is determined by the parameter set they support, and the data that these objects represent is contained within their associated parameters. Parameterized objects have the capability to inherit their parameter set from another Parameterized Object which acts as the definition for the new object. A Parameterized Object's definition is, itself, a Parameterized Object.
Using Parameters to define an object's type, and the data associated with it, provides the following capabilities:
Parameters represent data--they aren't compiled-in behavior.
Parameterized Objects support data inheritance--a Parameterized Object inherits its structure and default values from its defining object.
Any object can override the default value of various attributes of an associated Parameter. Referred to as parameter instantiation by exception, only the Parameter attributes that differ from their defaults are instantiated, and attached to the object.
Parameters associated with a Parameterized Object can also be changed by the application of a modifier object, effectively overriding the default value(s) of any matching Parameters.
A change to a Parameter in a Parameterized Object acting as a definition is reflected in all the Parameterized Objects that are derived from the defining Parameterized Object.
Parameterized Objects can extend their definition by adding additional Parameters.
Parameters are organized into groups, each group containing logically-related Parameters. Groups can be pre-defined and/or defined by the user.
Given the complex nature of Parameterized Objects and their parameter sets, a simple interface for the developer is provided in which it appears that a Parameterized Object consists of a self-contained, cohesive set of parameters when in reality, data inheritance, parameter overrides, and modifications are all acting together to determine final parameter values.
1.1.1 Object Model
The overall object model for Parameterized Objects, and Parameterized Object Collections is depicted in FIG. 7.
1.1.1.1 Parameterized Object
A Parameterized Object is a persistent object. The parameters associated with a Parameterized Object are both locally defined (as depicted in the object model) and inherited. The locally defined parameters are those defined by the Parameter Definition objects. The inherited parameters are those that are inherited through an association to another Parameterized Object typically serving as a definition.
A Parameterized Object has an ordered one-to-many association with the Parameter Definition object. This represents the set of locally defined parameters which "belong" to, and ultimately define, this object.
A Parameterized Object maintains a list of parameter overrides, in the form of Parameter Value and/or Parameter Override objects. Parameter Value objects are used to override the actual parameter value, and other important attributes such as high and low limits. Parameter Override objects are used to override all other editable parameter attributes. Only inherited parameters are overridden--locally defined parameters simply have the appropriate attribute value changed within the associated Parameter Definition.
A Parameterized Object has an association to another Parameterized Object from which it inherits parameters. It is a zero-or-one association, and is referred to as its Definition, or parent, Parameterized Object. If a Parameterized Object does not have a definition, then it is considered to be a root Parameterized Object. A root Parameterized Object defines all of its parameters, not relying on another object to inherit them from. If a Parameterized Object has a Definition Parameterized Object association, then the Parameterized Object is a derived Parameterized Object. The derived Parameterized Object gets its parameters by inheriting them from the defining object and by adding its own through local Parameter Definition associations.
A Parameterized Object maintains a list of other Parameterized Objects that inherit its parameters. A Parameterized Object whose parameters are inherited by other parameterized objects is referred to as a Definition, or parent, Parameterized Object. There is no limit as to the number of objects for which a Parameterized Object can act as a definition.
A Parameterized Object maintains an ordered list of Parameter Groups associated with it. This association gives the Parameterized Object an ordered set of labels to put on the tabs of the Parameterized Objects' property page tabs while being edited, or on tabs at the top of the Parameterized Object editor. Parameter Groups, in turn, maintain an association with zero or more Parameter Definitions.
The Parameter Definition order maintained by the Parameterized Object applies across all Parameter Groups that the parameters belong to. In other words, if parameter A comes before parameter B in the association between Parameterized Object and Parameter Definition, then A will preferably appear before B whenever the two parameters are displayed in the same group.
A Parameterized Object may be contained within a parameterized object collection object, which may be either a single- or multiple-collection instance of Parameterized Object collection. In turn, parameterized object collections may contain zero or more parameterized objects.
An instance of Parameterized Object may be associated with zero or more other Parameterized Objects that are referred to as Modifier Parameterized Objects. The Parameter Values in the Modifier Parameterized Objects are used to override the parameters of the Parameterized Object. An instance of a Parameterized Object can have zero or more of these modifiers to modify their parameters. If an object has more than one modifier, the modifications are made in the order that the modifier objects were applied, with the resulting overrides representing the accumulative effect of having applied all the modifications.
The Framework provides the method(s) necessary in order to determine the behavior of a modifier object. By default, the Parameter Values in the Modifier which aren't associated with any Parameter Definitions (local or inherited) of the object being modified are ignored. However, there may be circumstances under which a developer needs to have all Parameter Definitions applied to the object being modified, potentially adding new parameters to the object.
1.1.1.2 Parameterized Object Collection Classes
A Parameterized Object Collection is just that--a collection of one or more Parameterized Objects. Applications programs can add or delete elements from the collection, and iterate through it. Parameterized Object Collections have the ability to support multiple collections. For example, a loop could collect both blocks and connections, whereas a compound could have a separate collection of blocks for each control zone.
Consequently, the Parameterized Object Collection classes have been separated into two classes, each of which will be able to support many different collection types, which include Lists (insert after/before), Arrays (indexed access, and "null" locations), and possibly Maps (or Dictionaries). These collection classes are:
1. Single-Collection. Instances of this class contain a single collection, presented as a single ordered list of objects.
2. Multiple-Collection. Instances of this class contain multiple, named collections. These named collections are references to instances of collections (i.e., instances of the Contained Collections) which are managed by the Multiple-Collection instance. Each collection within a Multiple-Collection object can be a different type (for example, a list and an array).
1.1.1.3 Parameter Definition
The Parameter Definition object defines the values for the attributes in a parameter. Even though it is only directly associated with one Parameterized Object, it may indirectly belong to many other Parameterized Objects via the parameter inheritance mechanism described in the discussion on Parameterized Objects.
The parameter object consists of a set of attributes. The attribute set is compiled-in behavior, and the value of each attribute is changed as needed to satisfy the requirements of the associated Parameterized Object. A Parameter Definition does not exist alone, but only in the context of a Parameterized Object.
In the illustrated embodiment, the minimum attribute set for a Parameter Definition is as follows:
Name The unique identifier for accessing the parameter within a Parameterized Object. There cannot be more than one parameter in a Parameterized Object with the same name. This is the name used when downloading the parameter to a target machine.
Group A list of Parameter Groups which this parameter belongs to.
Label An internationalizable string used to label the Parameter in the user interface.
Data Specifies the data type of the Parameter. Integer, float, boolean, and
Type string are examples of a data type. Depending on implementation, the length of the data can be either an attribute of the data itself or of the Parameter Definition. Can also be implemented via sub-classes of Parameter Definition.
Behavior Specifies a set of behaviors the Parameter exhibits. Examples include whether the parameter could be edited or associated with another Parameter. This can be implemented as a bitmask.
Help Specifies internationalizable help associated with the particular Parameter Definition. The help consists of both a verbose and terse version. The verbose version is used by the help system and the terse version is used for such things as short messages and tool tips.
Edit Specifies a specific control type used to edit the value attribute
Control associated with the Parameter Definition. This edit control type is
Type used by any application editing this parameter, whether it is displayed in a property sheet, or in a spreadsheet format.
Range Specifies a range of valid values for the Value attribute.
Value Specifies the value of the Parameter. This value is type specific which is specified by the type attribute.
Formula Provides a placeholder to contain the user-provided formula for Parameter Definitions which have their Value attribute determined by a formula.
Format Specifies a C-printf type specification for displaying the value attribute.
The Parameter Definition object has a many-to-many association to the Parameter Group object. A Parameter Definition can belong to many groups, allowing the parameter to be displayed in multiple tabs on a Parameterized Object property sheet. The order of parameters within any Parameter Group is determined by the ordering maintained by the Parameterized Object.
The Parameter Definition object has a many-to-one association to the Parameterized Object. Although it may be inherited by several Parameterized Objects, a Parameter Definition belongs directly to (locally defined by) one and only one Parameterized Object. A Parameterized Object contains an ordered set of zero or more Parameter Definitions.
1.1.1.4 Parameter Value
An instance of the Parameter Value object is created whenever specific attributes of a Parameter Definition instance are overridden--namely, value, high range and low range. Any other attribute of a Parameter Definition which is overridden is specified by a Parameter Override object. It is important to note that a Parameter Value exists by exception only--in other words, it exists only if the associated Parameter Definition is overridden by a Parameterized Object located "down" the ancestral tree from the Parameterized Object where the Parameter Definition was originally defined. Overrides of a locally defined Parameter Definition simply replace the appropriate value within the Parameter Definition itself.
Parameter Value is associated with one, and only one, Parameter Definition, by name. Attributes of the same Parameter Definition, however, may be overridden by multiple Parameter Values when viewed in the context of the Parameterized Object hierarchy chain.
The final value of any parameter attribute is determined by traversing the Parameterized Object hierarchy back to the object's root, then sequentially applying overrides (and/or modifiers) appropriately going forward down the object's hierarchy chain.
Each Parameterized Object maintains a list of zero or more Parameter Value objects. This list represents the set of locally defined value overrides associated with this Parameterized Object.
1.1.1.5 Parameter Override
The Parameter Override object is used by a Parameterized Object to override attributes of inherited parameters other than value, high range, and low range. Attributes which are typically overridden using this object include which parameter groups a parameter belongs to, format, and help strings.
A Parameter Override object is derived from the Parameter Value class. As such, it inherits all the behavior and attributes of the Parameter Value class in terms of existing by exception only, and how the final value of attributes modified within a Parameter Definition are determined.
A Parameter Override has a "special" relationship to Parameter Groups, in that one of the attributes of a Parameter Definition is a string containing all of the names of the groups which that parameter belongs to. In this relationship, the same Parameter Override may specify many Parameter Groups. In turn, the same Parameter Group may be referenced by several Parameter Overrides, resulting in a many-to-many relationship. As with other relationships dealing with Parameter Values and Overrides, this one is resolved by parameter name.
1.1.1.6 Parameter Group
The parameter set that defines the structure of a Parameterized Object is segregated into named Parameter Groups. These groups are directly related to the tabs contained within the property sheet for the Parameterized Object when it is edited, as well as the tabs visible on the Parameterized Object editor. Each parameter defined in an object belongs to one or more Parameter Groups.
Parameterized Objects inherit their Parameter Groups in the same way they inherit Parameter Definitions. As depicted in FIG. 8, a Parameterized Object may add additional groups to the inherited list. The order of Parameter Groups, and the parameters within those groups, is also inherited, and is determined by the ordered list of parameters maintained by the Parameterized Object hierarchy chain.
In FIG. 8, an object Foxboro_PID is associated with two groups, A and B. Group A contains two parameters, X and Y, while Group B contains parameters M and N. A new object is created, using Foxboro_PID as it's definition object. A new group, C, has been defined for My_PID, which contains parameters W and X. A new parameter, Z, has been added to the inherited group, A.
When the object My_ID is edited, a property sheet with three tabs appears. The tabs are labeled A, B and C. If the user edits group A, parameters X, Y and Z are shown, in that order. Note that if a change is made to the value for parameter X, and switches to group C, the new value for X will be displayed.
The user can add new parameters (and define their order) to an inherited group, but not change the order of any of the inherited parameters contained in the group. All inherited parameters appear first on the property page, followed by the parameters which were added locally. Similarly, the user can add local groups, but cannot change the order of inherited groups when displayed on the property sheet. Local groups appear after inherited groups.
1.1.2 A Simple Parameterized Object Example
The example in FIG. 9 shows how a parameter set of a simple Parameterized Object is constructed. Parameterized object "Y" has an association to its definition "X", and is modified by "Z". A call to a method to retrieve on parameterized object "Y" (depicted as "GetParameters" in the example) results in the list of parameters as shown.
The Parameterized Object has the capability to construct a list of parameter objects that are associated with it. The parameter list for a Parameterized Object is composed from two sources: the parameters that are inherited (including all overrides and modifiers, possibly n levels up the parameter inheritance tree), and the parameters which have been defined locally. FIG. 10 shows a instance model of the objects involved in constructing a parameter list for a simple Parameterized Object.
Listed below are the steps that a Parameterized Object takes when it is asked for a list of its parameters. Take note of step 2, which causes recursive behavior in that the inheritance tree is traversed all the way to the root Parameterized Object. The root Parameterized Object constructs a parameter list, finishes all 5 steps outlined below, and then returns that list to the next Parameterized Object down, and so, until the original calling Parameterized Object gets a list from step two. It then finishes steps 2, 3, 4, and 5 and the list is complete.
Step Action
1 The application asks for the parameter list of a Parameterized Object.
2 If there is a definition object, traverse the inheritance tree in order to add its parameters to the list first (this continues back to the root definition object).
3 If there are any Parameter Value and/or Override associations, then apply those to their respective inherited parameters in the parameter list.
4 If there are any Parameter Definition associations, then add those new parameters to parameter list.
5 If there are any Modifier Parameterized Object associations, then apply their Parameter Definition associations as if they were Parameter Override associations to their respective parameters in the parameter list.
1.1.3 Framework User Interfaces for Parameterized Objects
Two user interfaces are supplied by the Framework for working with Parameterized Objects on a daily basis. The first user interface supplied by the Framework to manipulate Parameterized Objects is a generic Parameter Definition Editor, which could appear as shown in FIG. 11. The Parameter Definition Editor is an interface which allows Parameter Definitions to be created for a Parameterized Object. This interface will most likely be utilized by someone with administrative and/or supervisory capability.
FIG. 11 provides a depiction of the Parameter Definition Editor. The Framework automatically provides the menu and toolbar services which the editor may need, a tabbed tree pane (shown on the left side of the figure), and a generic view pane which the application programmer can use for just about anything--e.g., a graphical "canvas", or a grid control able to display data in a spreadsheet-like format.
The second user interface is a generic Parameter Property Sheet mechanism which is used whenever anyone needs to edit the Value attribute of a parameter on any object. The property sheet can appear as FIG. 12. When the user double-clicks on a Parameterized Object, or in some other way activates an editing session on a Parameterized Object, a property sheet is created and displayed by the Framework. The individual property pages within the sheet correspond to each Parameter Group found to be associated with the object being edited. Each page, in turn, displays only those parameters which have been associated to the corresponding Parameter Group.
The current values of each parameter in the group are displayed, providing the user with the ability to change the values of configurable parameters, possibly creating Parameter Override objects. The "look-and-feel" of each parameter value displayed on the property page is determined by the edit control type which was associated with the corresponding Parameter Definition.
Some parameter values (such as an entire sequence block) require something more sophisticated in order to edit it. In these cases, a button containing an ellipses ( . . . ) appear next to the field, and when pressed, display the appropriate editor. In the event that a Parameter value is derived from a user-specified formula, the formula is also displayed, and allowed to be changed, on the property page.
1.2 Object Types
All configurable objects have an associated classification, or type, which they inherently belong to. An object's type is used to classify what it is, and is used primarily to segregate objects into groupings of objects exhibiting similar appearance and behavior (e.g., an AW70 and AW51, although both application workstations, have different physical characteristics which necessitates distinguishing between them at configuration time. Thus, multiple instances of AW70's would each have a unique identifier in the configuration, but each would have a type of A W70).
As used here and hereinafter, the symbols Awxxx, where xxx is a number, identifies an applications workstation available from the assignee hereof, The Foxboro Company, or other digital data processing apparatus. The term FBM or symbol FBMxxx, where xxx is a number, identifies a field device available from The Foxboro Company, or other field device for use in process control. The term CP refers to a control processor or other digital data processing apparatus suited for that function.
The Framework provides methods to return an object's type to the application. This type information may be used for a number of reasons, including: preliminary lookup to see if two objects can establish a connection; satisfy a search which uses a type filter; display of type information on an object's placeholder.
The concept of type may be further abstracted into the concept of type category, which is a broader classification of type. Several object types may belong to the same category (e.g. an AW70 and AW51 both belong the category Application Workstation). All objects in the same category exhibit the same general behavior as that defined by that category. For example, an FBM would be an object type category, whereas an FBM02 and FBM04 are examples of specific object types.
Consequently, it is convenient to think of object types as being contained within a type hierarchy. Each branch in the hierarchy would correspond to an object type category, whereas the leaves, or endpoints, of each branch would correspond to specific object types. The remainder of this section will present the data model, with examples, of this type hierarchy for IDA.
1.2.1 Object Model
The object model used in the illustrated embodiment to support the concept of object types is shown in FIG. 13.
1.2.1.1 IDA Type
This abstract base class is used only as a placeholder for containing data and methods common to all "type-ish" classes. The only one shown in the illustration is Object Type, but this can be expanded to include other types such as Parameter Type, etc.
1.2.1.2 Object Type
An object's type is used to classify what it is--i.e., all objects of the same type have the same appearance, and behave identically, differentiated only by minimal differences in associated data (e.g. name, ID, etc.) which is used to uniquely identify them.
The Object Type class is hierarchical--the branches of the hierarchy represent type categories, with the leaves, or endpoints, of the hierarchy being actual object types with which objects are associated. Instances of Object Types are Parameterized Objects, and may only be directly associated to a single type category (i.e., a specific object type cannot belong to more than one type category). Note, however, that even though an object type can only be directly associated with one type category, it may indirectly be associated with several type categories depending upon where it is in the type hierarchy. Every instance of Object Type has a pointer back to its containing type category, regardless of whether it's acting as a simple object type, or a type category itself.
All instances in the Object Type hierarchy are able to act as collections of Typed Objects. That is, each Object Type is able to maintain a list of all Typed Objects which are directly associated with the type itself. For example, all instances of an AIN block will contain a pointer back to the AIN instance of Object Type. In turn, the AIN instance of Object Type will maintain a list of all instances of AIN blocks in the configuration. This containment is meant to be only one level deep--in other words, there is no need for I/A Block, the containing instance of AIN, to also maintain a list of all AIN blocks (although nothing in the design would prevent it, if desired).
Additionally, each instance of the Object Type hierarchy which serves as a reference for a Typed Object requires a definition reference to the defining Parameterized Object which defines that Typed Object. This relationship provides quick access to the definition object when a symbolic representation of that definition is dragged and dropped into a view. For example, if the user clicks and drags an AOUT definition (either from the System Hierarchy, or from a library template) to a view, then drops it, this relationship provides access to the Parameterized Object which actually defines an AOUT block so that it can be created quickly.
Since an Object Type which can be referenced by a Typed Object requires a reference to the defining Parameterized Object, only those instances in the Object Type hierarchy be used to serve as the collection point for those same types of objects as they are created. If an Object Type doesn't have a defining reference, is not a container of Typed Objects.
The Object Type class is an abstract class--no instances of Object Type may exist in the database. Subclasses of Object Type are the implementation-standard Object Type class, and the User-Defined Object Type class. The Object Type class contains those methods common between the two subclasses, e.g. methods used to support the hierarchical relationship(s) in the type hierarchy, the containment relationship to Typed Object class, and the reference to its associated definition Type Object instance.
Summarizing Relationships:
An instance of an Object Type is directly associated with one, and only one, other Object Type in the type hierarchy, and may represent either a type category, or an actual object type, depending upon where it resides in the hierarchy. For example, in the hierarchy Module->FBM->FBM04, object types Module and FBM represent type categories, and FBM04 represents an object type.
The Object Type class is an abstract class, and instances of this class cannot exist. An instance of an Object Type is preferably either a User-Defined Object Type, or a implementation-standard Object Type.
The Object Type class is hierarchical, with branches representing type categories, and leaves being object types. The hierarchy is restrictive--that is, an implementation-standard Object Type is preferably contained within a implementation-standard hierarchy, whereas a User-Defined Object Type can appear virtually anywhere in the hierarchy (but ultimately also contained within a implementation-standard type category).
Instances of the Object Type class contain a reference to their containing type category.
Instances of the Object Type class which can serve as a reference for a Typed Object maintain a list of all the Typed Objects of that same type which exist in the configuration.
Those same instances of the Object Type class maintain a reference to the Parameterized Object which is capable of acting as the defining object for creating Typed Objects of that type.
FIG. 14 depicts an example of how the object type hierarchy can appear in IDA. As mentioned previously, within the type hierarchy, branches form type categories, to which one or more object types belong. In the example shown in FIG. 14 are all examples of type categories. Within the category Block Types, AIN Block, AOUT Block, and PID Block are examples of implementation-standard object types, and User-X Block Types is an example of a user-defined object type.
1.2.1.3 Implementation-standard Object Type
All objects which can be typed inherently belong to one Object Type (or type category)--that is the implementation-standard Object Type. Additionally, these objects may also optionally be associated with a User-Defined Object Type.
Each instance of implementation-standard Object Type defined in the database may be specified as the inherent type for one or more configuration objects. All Implementation-standard Object Types have a direct association with a type category, which is preferably also be Implementation-standard. In other words, a Implementation-standard Object Type may not be associated with a user-defined type category.
All Implementation-standard Object Types have three additional attributes--they are: configurable--all instances of this object type are able to be configured in an I/A configuration; assignable--all instances of this object type are able to be assigned to a process area; and downloadable--able to be realized (as an entity) on a target platform. Whether an object type is configurable, assignable and/or downloadable is determined at the time the instance of the Implementation-standard Object Type is created.
Summarizing Relationships:
The Implementation-standard Object Type class is a subclass of Object Type.
An instance of a Implementation-standard Object Type is inherently associated with one or more instances of Typed Object (e.g., there can be many instances of an FBM04 in the configuration).
An instance of a Implementation-standard Object Type preferably belongs to a type category which is in the Implementation-standard Object Type hierarchy. In other words, going back along the type hierarchy chain from a Implementation-standard Object Type, one would only find Implementation-standard type categories.
When created, an instance of a Implementation-standard Object Type may be designated as needing to appear in the system hierarchy.
1.2.1.4 User-defined Object Type
Users may create their own, customized object types, which may be assigned to typed objects. The primary purpose of a User-Defined Object Type is to allow the user to create their own object classification system in the event that the set Implementation-standard Object Types doesn't satisfy all their needs.
Summarizing Relationships:
The User-Defined Object Type class is a subclass of Object Type.
An instance of a User-Defined Object Type may be associated with one or more instances of Typed Object (e.g., there can be many instances of User X Block Type 1 in the configuration). This relationship is strictly optional, and User-Defined Object Types may exist without ever having been referenced by an object.
An instance of a User-Defined Object Type may appear anywhere in the type hierarchy.
In other words, a User-Defined Object Type may be directly associated with either a Implementation-standard, or user-defined, type category.
When created, an instance of a User-Defined Object Type may be designated as needing to appear in the system hierarchy.
1.2.1.5 Typed Object
A Typed Object is a Parameterized Object which is able to be inserted into an I/A configuration, and is considered an integral part of the configuration, in such a way that the configuration would be considered incomplete without it. Examples of typed objects include CPs, FBMs, blocks, loops, and compounds. Objects such as graphical objects used to enhance documentation would not be considered Typed Objects.
Typed objects inherently have an associated Implementation-standard object type. The fact that an object is configurable is determined by whether or not its inherent object type is or not. Typed Objects may also have a User-Defined Object Type associated with them, although this relationship is optional.
One further restriction: at creation, a Typed Object is prevented from associating with an Object Type (and thereby prevented from being created), unless that Object Type also references an associated defining Parameterized Object which acts as the definition for the Typed Object being created. In an alternate embodiment, when a Typed Object is created and a reference made to its associated Object Type, if that Object Type doesn't have a reference to the defining Parameterized Object, it simply uses the one from the Typed Object itself.
Summarizing Relationships:
The Typed Object is a subclass of Parameterized Object.
An instance of a Typed Object has an inherent Implementation-standard Object Type associated with it, which the user cannot modify, or change. This object type determines whether or not the Parameterized Object is configurable, assignable to a process area, and/or downloadable to a target system.
An instance of a Typed Object may have an optional User-Defined Object Type associated with it. This association is in addition to the Implementation-standard Object Type.
There may be occasions where it would be desirable to change the type of an object, without having to delete the original object, then create an object of the correct type. One example of where this capability could be useful would be being able to change a station type after a configuration has already been created, and all associations and connections established (this happens often). An alternate embodiment accordingly, permits the type of an object to be dynamically charged.
1.2.1.6 Configuration
The Configuration class exists to serve as an entry point into the two primary hierarchies which comprise the configuration itself--the System Hierarchy, and the Plant Hierarchy. These two hierarchies are, however, by no means mutually exclusive. The primary method(s) and data incorporated in this class exist to serve the establishment and maintenance of hierarchical relationships. Other configuration-wide data and/or methods may also reside with this class.
1.2.1.7 System Hierarchy
The System Hierarchy represents those objects which are contained within the configuration, and are organized by various categories, primarily object type. There are potentially several subclasses of System Hierarchy objects in the System Hierarchy itself. However, for present purposes, only two of these subclasses are discussed:
Definition Hierarchy. This portion of the System Hierarchy deals with the display of definition objects, or those objects which act to define other Typed Objects (e.g., an AIN block definition). Within the Definition Hierarchy, definition objects may be organized in a number of libraries. These libraries are either implementation-standard or defined by the user.
Components Hierarchy. This portion of the System Hierarchy deals with the display of actual instances of configured objects, and may not, themselves, act as definition objects.
All other subclasses within the System Hierarchy simply represent another view of existing configuration components. For example, a Network Hierarchy could display a view of the configuration from a System Definition point of view, showing a hierarchy of networks, nodes, stations, FBMs and other hardware. Since the only grouping of configuration objects in the current design is by object type, these subclasses have to use the relationships specified in the Connections discussion in order to know what to display (i.e., by network, by location, etc.).
The primary reason that subclasses exist within the System Hierarchy is due to the differences in behavior when dealing with objects in each subclass. For example, the act of dragging and dropping an object from the definition portion of the System Hierarchy results in the creation of a Typed Object of the proper type, whereas when an object from the components portion of the System Hierarchy is dragged and dropped, it results in that object being copied and placed in the view, or connected to another object, depending upon where it was dropped.
The visible portion of the System Hierarchy tree control actually consists of two types of elements: actual instances of System Hierarchy objects (of which there are very few), and derived (non-persistent) instances of tree control objects. Actual instances of the System Hierarchy may reference one or more instances in the Object Type Hierarchy. This relationship provides the mechanism by which the majority of the visible System Hierarchy is constructed dynamically as elements are "exploded" by the user in the tree control.
1.2.1.8 Plant Hierarchy
The Plant Hierarchy also represents those objects which are contained within the configuration, but are organized by location, rather than by type. This hierarchy represents another view of already-existing configuration components, and may be constructed using a subclass of System Hierarchy.
1.2.2 Managing Object Types
The user can create a new instance of an Object Type by selecting "New" on a pulldown menu within the definition portion of the System Hierarchy. Alternatively, a "New.vertline.Object Type" menu selection is available on any IDA application. However the user chooses to perform this task, the action can result in the display of a dialog box similar to that in FIG. 15. In this example, the user enters the new Object Type, and provides a description for the new type.
Additionally, the user picks an already existing object type in the type hierarchy to act as its "template" type, or object type to be used to create from. The user can create a new object type from an existing one in two ways:
Copy. In this create method, the new object type is created by copying the existing object type, and is instantiated in the type hierarchy at the same level as the object type which was copied.
Derive. In this create method, the new object type is created by using an existing object type as its parent, thereby treating the old object type as a type category.
In order to finish creating the new object type, the user additionally specifies such things as:
Configurable. Specifies whether or not all objects associated with this object type are able to be configured in terms of security (i.e., a user's access to an object is determined by the user's group access to the object's type). If an object type is not configurable, objects created which are associated with that object type will not be affected by security mechanisms.
Downloadable. Specifies whether or not all objects associated with this object type are downloadable to a hardware target. Note that this option will be dimmed, and not available for selection if the object type being described is a User-Defined object type.
Assignable to System Hierarchy. Determines whether or not an object is visible within the System Hierarchy when the hierarchy is viewed from the tree control.
Assignable to Process Area. Determines whether or not an object associated with this object type can be assigned to a process area.
To edit an existing instance of an Object Type, a dialog similar to the one shown in FIG. 15 is displayed, already populated with the information dealing with this object type (i.e., the configurable, assignable and/or downloadable flags checkboxes are selected appropriately). When an object type is edited, the only things that can be changed are the object's description, and whether or not the object is configurable, assignable and/or downloadable. Some of the attribute and assignable selections may be disabled when the object type is displayed, depending upon the settings of the object type's containing category.
To delete an instance of an Object Type in the hierarchy, the user must preferably explicitly decide to remove it. If the object being deleted is a type category, the user is informed, and asked if they wish to continue--if they confirm the delete, then everything in the type hierarchy from the object type downward is removed.
1.3 Parameterized Object Connections
An IDA configuration consists not only of objects, but objects which are related to each other in a number of ways. These relationships may be physical (e.g. a serial connection between a serial printer and a station) or logical (e.g. a host relationship between an AP and a CP, or a collection point relationship between a block and an historian). These relationships are all called connections.
Establishing a connection actually requires two different levels of "hand-shaking" between the two objects involved. Consequently, the subject of connectivity is divided into two sections:
1. The first level represents the connectivity which is established between two objects. Although easy to envision (e.g. the connection between a block and a compound), there is no actual database association which is actually created at the object level.
2. The second level represents the connectivity which is established between two parameters. The database association is established at this level, and is the mechanism by which two objects establish a relationship.
1.3.1 Type Awareness
Any Parameterized Object in IDA has an inherent Implementation-standard object type. This object type, in turn, has a direct relationship to a single type category, but may be indirectly related to several type categories. the fact that AW70X is its inherent Implementation-standard object type. However, the instance is preferably also "aware" that it is also an AW70, NT Application Workstation, or control processor (here, identified as a "Z-Module," in reference to a control processor available from the assignee hereof, The Foxboro Company), going backward through the type hierarchy. This awareness may be used in a number of ways, particularly when a process is dealing with the concept of object types at different granularities. For instance, when dragging a specific serial printer across a representation of the AW70X mentioned above, the printer may not "know" that it can connect to an AW70X, but it may know that it could establish a connection to an NT Application Workstation. The Framework provides methods for allowing the application developer to "walk" the type hierarchy tree in order to obtain the direct, and all the indirect, type categories which a specific object type is related to.
1.3.2 Source/Sink vs. Parent/Child Relationships
A connection in IDA can describe a Source/Sink, or Parent/Child relationship between two objects. There are very subtle differences in the two types of relationships, but they are different enough to warrant separation of behavior. A Parent/Child relationship is typically used to model the relationship between two objects in a hierarchical, or containment relationship whereas a Source/Sink relationship is usually used in a peer-to-peer type of relationship. These differences are presented in the table below:
Relation Data Data Description
Parent Capacity Data represents the maximum combined "weight"
of the children which can be associated to that
object.
Child Weight Data represents the weight of a single instance of
the child object.
Source Min, Max Specifies the minimum and maximum number of
connections to other objects, or sinks, which can
be supported by that object. Supports the concept
of a "fan-out" capability.
Sink Min, Max Specifies the minimum and maximum number of
connections from other objects, or sources, which
can be supported by that object. Supports the
concept of a "fan-in" capability.
An example of a Parent/Child type relationship would be that of a CP to its connected FBMs. The CP acts as a parent in that it acts as a common control connection for all the FBMs which are physically connected to it. The CP is able to support a certain number of FBMs. Each FBM, in turn, acts as a child in that it relies on the CP to perform certain duties, and it contributes a specific weight toward the total capacity supported by the CP.
In both Parent/Child and Source/Sink connections, the concept of fan-in and fan-out is valid. A fan-out connection can be used to model a relationship in which the source (parent) object supports connections to one or more sinks (children) objects in the database. One example of such a connection type is a output (or "PNT") parameter on an AIN block and its associated output signal flows. The PNT parameter, acting as a source, would provide measurement values to one or more input parameters (conventionally referred as "MEAS" or "SPT") in other blocks, each input parameter acting as a sink.
1.3.3 Connection Object Model
FIG. 17 depicts the classes used in the illustrated embodiment to support connectivity at the object level. This shows the model used to support a source (parent) Parameterized Object, connecting to the sink (child) Parameterized Object. The model is not intended to suggest that two connectable parameters of the same object can't be connected together (i.e., the same Parameterized Object can be both source and sink at the same time). An example of when this might occur is a calculation output parameter (conventionally referred to as "BCALCO") parameter acting as calculation input parameter (conventionally referred to as "BCALCI") parameter in the same I/A block.
One aspect of the object model needs to be explained in order to understand it fully. When a Parameterized Object is created, no Parameter Override or Endpoint objects exist. The Override and Endpoint objects only get created whenever a Connection is about to be established. When a Connection is about to be established, the appropriate Parameter Override object and Endpoint object are instantiated, and as depicted in FIG. 18, these two objects each maintain a reference to their associated parameterized object, as well as to each other, allowing iteration over an object's connections from either direction.
1.3.3.1 Connection
A Connection contains the data and methods that defines a relationship, or link, between two Parameterized Objects (or more specifically, between two connectable parameters). In an I/A relationship, a connection could can be used to model the logical relationship between two blocks, or the host relationship between two stations, etc.
In order to take into account the complex relationships that a Connection can have with other classes (esp. Placeholder classes), a Connection is a Parameterized Object. This allows Connections to be primarily data driven, rather than compiled behavior, allowing the establishment of connections with new objects to be done in an easier fashion. For example, some Connections probably are not displayed in a graphical environment (such as the relationship between an historian and its associated historizable points). Whether or not to display a Connection is, preferably, parameter-driven.
A Connection in IDA can be a Parent/Child relationship, or a Source/Sink. In order to exist, a Connection preferably has exactly one Source (or Parent) Endpoint, and one Sink (or Child) Endpoint. However, the two endpoints may exist without a Connection having yet been established between them. As mentioned previously, the endpoints of the Connection will not be instantiated until the Connection itself is about to be established. Conversely, endpoint objects remain persistent even after the associated Connection has been removed.
Graphically, connections between two objects will be connected at the edge of the rectangular area representing each object. The system will also support connections connected to a point at the center of the object as well. Connections are represented by segmented polylines made up of alternating horizontal and vertical segments. The system also supports single segment lines representing an association.
Summarizing relationships: a Connection is a Parameterized Object; a Connection, if it exists, preferably has both a Source (or Parent) and a Sink (or Child) Endpoint. Note, however, that certain operations (e.g. selection state) deal with the Association, and only one (or none) of its associated Endpoints; a Connection has a relationship to an Association Placeholder.
1.3.3.2 Connection Endpoint
A Connection Endpoint is an abstract class from which all connection endpoints are derived. No instances of this class may exist by themselves. The Connection Endpoint contains a reference to the Parameter Override which is either the source (parent) or sink (child) parameter representing one end of a connection.
Connection Endpoints provide a mechanism for associating the connection to the object. The endpoints relate the Connection to the Parameter Override to (or from) which the Connection is attached. Endpoints also relate the Connection to the position (side/direction, or center) where the Connection is attached to the object. Each Connection Endpoint is described by two coordinates, the side of the object it is on, and the relative position of the endpoint along the side of the rectangle representing the parameterized object. This allows the endpoint to retain its relative position along the side, even if the object is resized.
Connection Endpoints only come into existence whenever a connection between any two objects (or parameters) is about to be established. Once the Framework approves the creation of the connection, it instantiates the endpoint class instances, along the associated parameter overrides, inserting a reference to the parameterized object in each.
Connection Endpoints have a direct relationship to a Point Placeholder, allowing a depiction of the endpoint itself to be displayed on the screen.
Summarizing Relationships:
The Connection Endpoint class is an abstract class, and no instances of it may exist in IDA. This class is further specialized into Source/Sink Endpoints, and Sink/Child Endpoints.
Each instance of a Connection Endpoint has a reference to a Point Placeholder.
1.3.3.3 Source/Parent Endpoint
A Source (or Parent) Endpoint is the endpoint which is specific to the source (or parent) end of the Connection between two Parameterized Objects, and is a simple sub-class of the abstract Connection Endpoint class. The Parameterized Object maintains a list of its Source/Parent Endpoints. The Source/Parent Endpoint can be the source of several connections, supporting "fan-out" connectivity. The Source/Parent Endpoint may exist without a Connection to a Sink/Child Endpoint.
Summarizing Relationships:
An instance of a Source/Parent Endpoint is associated with one, and only one, Parameterized Object. The Parameterized Object, in turn, maintains a list of all Source/Parent Endpoints associated with it.
Each instance of a Source/Parent Endpoint may be associated with one or more Connections. This supports the concept of a "fan-out" relationship, which is valid for both Parent/Child as well as Source/Sink type relationships.
Each instance of a Source/Parent Endpoint is directly related to the connectable Parameter Override it represents.
The Endpoint object can support the concept of a reference counter, which represents the number of connections currently associated with it.
1.3.3.4 Sink/Child Endpoint
A Sink (or Child) Endpoint is the endpoint which is specific to the sink (or child) end of the Connection between two Parameterized Objects, and is a simple sub-class of the abstract Connection Endpoint class. The Parameterized Object maintains a list of its Sink/Child Endpoints.
The Sink/Child Endpoint may only be the sink (child) of a single connection. The Sink/Child Endpoint may exist without a Connection to a Source/Parent Endpoint.
Summarizing Relationships:
A instance of a Sink/Child Endpoint is associated with one, and only one, Parameterized Object. The Parameterized Object, in turn, maintains a list of all Sink/Child Endpoints associated with it.
Each instance of a Sink/Child Endpoint may be associated with only one Connection.
Each instance of a Sink/Child Endpoint is directly related to the connectable Parameter Override it represents.
1.3.4 Object Connection Type Object Model
FIG. 19 depicts additional classes used in the illustrated embodiment to support connectivity at the object level.
1.3.4.1 Object Connection Type Specifier
The primary function of the Object Connection Type Specifier is to provide a list of Object Types to Parameterized Objects, allowing objects to be "extended" such that they encapsulate the behavior of an object in terms of being a parent/child, or source/sink. The Object Connection Type Specifier is an abstract class from which four basic object connection type specifiers are derived: parent, child, source and sink.
Each Object Connection Type Specifier is directly related to a Parameterized Object, and is used to help determine the nature of connectivity that the Parameterized Object is allowed to participate in. The same Parameterized Object can act simultaneously as a parent (or source) and a child (or sink). This gives rise to the one-to-many relationship between Parameterized Object and Object Connection Type Specifier shown in the model
In the example shown in FIG. 20, an Historian acts as a parent to all historized points associated with it, yet simultaneously acts as a child when discussed in terms of being associated with a software host. As used herein and throughout, a "historian" is a block or other functionality used to track parameter values during runtime operation of a process control system configured in accord with the teachings hereof. Each parameter so tracked is referred to as a "point," a "historized point," or the like. In the illustrated embodiment, the object type for a Historian is the same, no matter how many Object Connection Type Specifiers a Parameterized Object may be associated with.
Summarizing Relationships:
The Object Connection Type Specifier class is used to relate instances of Parameterized Objects with Object Types
Each instance of an Object Connection Type Specifier subclass is directly related to the Object Type it represents. The same Object Type may be associated with one or more Object Connection Type Specifiers.
Each instance of an Object Connection Type Specifier subclass is directly related to the Parameterized Object it represents. It is possible for the same Parameterized Object to be associated with more than one Object Connection Type Specifier.
Each instance of an Object Connection Type Specifier is referenced in one or more instances of the Object Connection Type class, with the added sense of whether or not the referenced specifier represents a source/parent, vs. sink/child in a potential connection.
1.3.4.2 Parent Object Connection Type Specifier
Parent Object Connection Type Specifiers extend the abstract Object Connection Type Specifier class to handle object types capable of fulfilling a parent role when connecting to another object. As such, they specify the capacity, or total weight, of all the child objects which they are capable of supporting, and provide other functionality used by a parent object.
Examples of a Parent Object Connection Type Specifier would include a CP which has the capacity to support 48 FBMs in an I/A fieldbus relationship, an AP which allows two serial printers to be connected via a serial connection, or an historian able to support 4000 collection points.
In a preferred embodiment, any object capable of playing a parent role keeps track of the total "weight" of the connections which have been established for each connection type it is able to support. This value can be associated with the parameter associated with the endpoint of a connection.
1.3.4.3 Child Object Connection Type Specifier
Child Object Connection Type Specifiers extend the abstract Object Connection Type Specifier class to handle object types capable of fulfilling a child role when connecting to another object. As such, they specify their weight which they will contribute to the total accumulative weight when connecting to a parent. Examples of Child Object Connection Type Specifiers include an FBM connecting to a CP, or a serial printer connected to an AP. Each connection causes the total accumulative weight for that connection type to be incremented by the child's weight. Prior to actually establishing a connection, the Framework checks to ensure that the weight supported by the parent object does not exceed its capacity for that connection type. If it does, the connection attempt will fail, and the application program will be informed that the pending connection is no longer feasible.
1.3.4.4 Parent/Child Object Connection Type Specifier Examples
The table below illustrates the data which needs to be considered at the object level for each valid parent/child connection--namely:
Capacity (This value specifies the total weight which the parent object type is able to support for the associated connection type); and
Weight (This value specifies the amount of capacity consumed whenever a child object of this type is attached to the parent).
Parent Connection
Object Type Capacity Type Child Object Type Weight
Historian 4000 Historian Historizable Point 1
CP40 48 Fieldbus FBM 1
AW70 2 Serial Serial Printer 1
IE32 4 Nest 1x8Cell 1
AP51 unlimited Software Host CP40 1
1.3.4.5 Source Object Connection Type Specifier
Source Object Connection Type Specifiers extends the abstract Object Connection Type Specifier class to handle object types capable of fulfilling a source role when connecting to another object. There are no additional data or methods beyond those provided by the Object Connection Type Specifier class. This subclass provides consistency and flexibility during implementation.
1.3.4.6 Sink Object Connection Type Specifier
A Sink Object Connection Type Specifier extends the abstract Object Connection Type Specifier class to handle object types capable of fulfilling a sink role when connecting to another object. There are no additional data or methods beyond those provided by the Object Connection Type Specifier class. The subclass provides consistency and flexibility during implementation.
1.3.4.7 Source/Sink Object Connection Type Specifier Examples
The table below illustrates the data which needs to be considered at the object level for each valid source/sink connection.
Source Object Type Connection Type Sink Object Type
AIN Block Connection PID
PID Block Connection AOUT
1.3.4.8 Object Connection Type
Instances of the Object Connection Type class provide a means of establishing the outermost layer of connectivity between any two objects. This class is used to describe the "legal" combinations of object types or type categories (i.e., Source/Sink vs. Parent/Child) which are able to form a connection. These connections can be physical (e.g. an electrical signal flow between a serial port and a serial device) or logical (e.g. a host relationship between an AP and a CP, or a collection point association between a block and an historian).
There are two relationships that each instance of an Object Connection Type has with the Object Connection Type Specifier class--one is used to specify the source (parent) type, and the other is to specify the sink (child) type. In this way, the Object Connection Type class acts as a join table, relating two object types to determine whether there is a potential connection possible. This class is therefore used as an initial "filter" to determine whether two objects are able to establish a connection before the more complex negotiation between two parameters is allowed to continue.
When examining instances of the Object Connection Type class to see if two object types can form a valid connection, the Framework may encounter more than one instance which satisfies the criteria. If this occurs, the user will have to manually resolve the ambiguity, and select the connection type being sought.
While making a determination as to whether two object types can connect together or not, the Framework takes into account the fact that instances of Object Connection Types may not go all the way "down" to the object type level, but may specify type categories instead. In this manner, for example, a specific type of serial printer could be specified as being able to be connected to all NT application workstations, rather than specific types of NT stations. The Framework takes into account type "awareness", which was discussed in a previous section, in order to accomplish this.
Summarizing Relationships:
Each instance derived from an Object Connection Type contains references to two Object Types--one for a Source (Parent) Object Type, the other for a Sink (Child) Object Type. These object types are paired together to determine whether a request to connect two objects together is "legal", or valid, depending upon what types of objects they are.
The Object Connection Type class contains methods which, when given two object types, allows the application developer to determine which object type is acting as the source (parent) object, and which one is acting as the sink (child) object.
In order to efficiently implement type "awareness", a bitmasking operation can be used, in which each unique type category, as well as object type, gets assigned a unique bitmask value. By "or'ing" all of the bitmasks together of all the type categories which an object belongs to, the matter of comparing an object's type bitmask with that of the types contained in each instance of the Object Connection Type class becomes a single operation, rather than a series of string compares.
1.3.5 Parameter Connection Type Object Model
FIG. 21 depicts the classes used in the illustrated embodiment to support connectivity at the parameter level. Note that the class structure presented in FIG. 21 closely parallels that of the object connection type object model presented in FIG. 19.
1.3.5.1 Parameter Type
The Parameter Type class is just that--a class used to describe all the various types of connectable parameters which can exist in I/A. Examples of Parameter Types includes serial ports, serial devices, analog input, analog output, historian hosts, and historizable points. Any "connectable" parameter in I/A preferably has an associated Parameter Type. Summarizing relationships:
A Parameter Type is a base class providing I/A with types of connectable parameters. No parameters will be allowed to be related to an endpoint in a Connection unless it is also represented by a Parameter Type found in an instance of this class.
Each Parameter Type may be associated with one or more Parameter Connection Type Specifiers, which provide additional information regarding connectability for that specific Parameter Type.
The Parameter Type class can be implemented as another type category in the Object Type hierarchy. In this manner, any code developed to deal with object types (esp. if implementing bitmask operations) may also be used to deal with parameter types.
1.3.5.2 Parameter Connection Type Specifier
The primary function of the Parameter Connection Type Specifier is to provide a list of Parameter Types to Parameter Definitions, and to fine-tune the "connectable-ness" of that Parameter Definition with the connection. The Parameter Connection Type Specifier class is an abstract class, from which four basic parameter connection type specifiers are derived: parent, child, source and sink.
Each Parameter Connection Type Specifier is directly related to one or more connectable Parameter Definitions, and is ultimately used to describe the nature of connection that the parameter is allowed to participate in. The parameter to act simultaneously as a parent/source, and a child/sink, thus the one to many relationship between Parameter Override and Parameter Connection Type Specifier.
In the example shown in FIG. 22, a MEAS parameter override acts as a source for other input parameters (e.g., a MEAS parameter in a REALM block), yet simultaneously acts as the sink when connected to a parameter such as a PNT parameter in an AIN block. Note that the parameter type "MEAS" is the same, no matter how many Parameter Connection Type Specifiers a parameter override may be associated with.
Summarizing Relationships:
The Parameter Connection Type Specifier class is used to relate instance of Parameter Overrides with Parameter Types.
Each instance of a Parameter Connection Type Specifier subclass is directly related to the Parameter Type it represents. The same Parameter Type may be associated with one or more Parameter Connection Type Specifiers.
Each instance of a Parameter Connection Type Specifier subclass is directly related to the Parameter Override it represents. It is possible for the same Parameter Override to be associated with more than one Parameter Connection Type Specifier.
Each instance of a Parameter Type Specifier is referenced in one or more instances of the Parameter Connection Type class, with the added sense of whether or note the referenced specifier represent a source/parent, vs. sink/child in a potential connection.
1.3.5.3 Parent Parameter Connection Type Specifier
Parent Parameter Connection Type Specifiers extends the abstract Parameter Connection Type Specifier class to handle parameters capable of fulfilling a parent role when connecting to another object. There are no additional data or methods beyond those provided by the Parameter Connection Type Specifier class. The subclass provides consistency and flexibility during implementation.
1.3.5.4 Child Parameter Connection Type Specifier
Child Parameter Connection Type Specifiers extends the abstract Parameter Connection Type Specifier class to handle parameters capable of fulfilling a child role when connecting to another object. There are no additional data or methods beyond those provided by the Parameter Connection Type Specifier class. The subclass provides consistency and flexibility during implementation.
1.3.5.5 Parent/Child Parameter Connection Type Specifier Examples
The table below presents some examples that have a parent/child relationship.
Parent Parameter Type Connection Type Child Parameter Type
Serial Port Serial Connection Serial Device
Historian Logical Historian Historizable Point
Parallel Port Parallel Connection Parallel Device
1.3.5.6 Source Parameter Connection Type Specifier
Source Parameter Connection Type Specifiers extend the abstract Parameter Connection Type Specifier class to handle source-type endpoints of a connection. As such, they will specify the minimum and maximum number of sinks with which they are able to establish a Connection. Examples of a Source Parameter Connection Type Specifier would be an I/O point in I/A, represented by the PNT parameter in a AIN block. The PNT parameter acts as the source for signals flowing to one or more input parameters.
1.3.5.7 Sink Parameter Connection Type Specifier
Sink Parameter Connection Type Specifiers extend the abstract Parameter Connection Type Specifier class to handle sink-type endpoints of an association. As such, they will specify the minimum and maximum number of sources with which they are able to establish a connection. An example in I/A of a Sink Parameter Connection Type Specifier would be a MEAS or SPT parameter in a PID block, either of which is able to receive signal input from another block.
1.3.5.8 Source/Sink Parameter Type Specifier Examples
The table below presents some examples which that have a source/sink relationship.
Source Parm Sink Parm
Type Min/Max Connection Type Min/Max
PNT 1/unlimited Block Connection MEAS 1/1
PNT 1/unlimited Block Connection SPT 0/1
BCALCO 1/1 Block Connection BCALCI 0/1
The "Min" data associated with a Sink represents an optional/required feature, with a zero (0) representing an optional connection, and a one (1) representing a required connection.
1.3.5.9 Parameter Connection Type
Instances of the Parameter Connection Type class represent the innermost layer of associativity between any two objects. This class is used to describe the "legal" combinations of parameter types which are able to form a connection. These connections can be physical (e.g. an electrical signal flow a serial port and a serial device) or logical (e.g. a collection point connection between a MEAS parameter and an historian).
There are two relationships that each instance of a Parameter Connection Type has with the Parameter Connection Type Specifier class--one is used to specify the source (parent) type, and the other is to specify the sink (child) type. In this way, the Parameter Connection Type class acts as a join table, relating two parameter types together to determine the connection endpoints. This class is therefore used as the final "filter" to determine whether two objects are able to establish a connection.
1.3.6 Establishing a Connection
The listing below represents the sequence of events which preferably occur before a Connection can be made between two parameters. This logic is used when an object is being "dragged" around the view, looking for a drop target. Additionally, this logic is valid whether the object being dragged is a potential Source/Parent in a relationship, or Sink/Child.
Level 1--Object to Object
Step Action Performed
1 Click and begin "dragging" object in view--cursor changes to a drag cursor.
2 Using the Object Connection Type Specifier of each object, check to see if there is any instances of the correct pairing in Object Connection Types.
3 If an instance in Object Connection Types is found, then change cursor to indicate that the drop target is potentially valid, otherwise perform no action. If valid, retain the sense of which object is now acting as Source(Parent), and which one is acting as the Sink(Child), as well as the type of Connection being sought.
If no instance is found, then cursor remains unchanged, and the user will not be allowed to drop the object.
Level 2--Parameter to Parameter (Perform only if Level 1 above passed)
Step Action Performed
4 Iterate through instances of the Parameter Connection Type class to find the proper Source (Parent) and Sink(Child) parameter types necessary to fulfill this connection. Note that there may potentially be several instances of the Parameter Connection Type class which satisfy the conditions imposed by the connection--keep track of all of them since we're not sure yet what parameters the objects have.
5 For the Source(Parent) object, find the proper Parameter Definition based on the Source(Parent) parameter type found in step (4) above.
6 Perform the same action for the Sink(Child) object parameter definition using the Sink(Child) parameter type which was paired with the Source(Parent) parameter type used in step (5) above.
7 Create the appropriate Parameter Override(s) with their associated Source(Parent) and Sink(Child) Endpoints (note that they may already exist from previous connection).
8 Create the instance of the Connection. If more than one connection is permissible, a preferred or default connection is automatically selected.
The final responsibility for establishing a connection between two objects rests with the methods responsible for negotiating the "handshake" between the two parameters. These methods check for adequate capacity on the source(parent) object, and establish the actual connection instance itself. This code resides with the source object or the sink object.
Parameter-level connections can be automatically established as described in steps 4-8 above. In addition, they can be established via direct operator intervention. Through a drag-and-drop operation, menu selection or otherwise, the operator identifies two parameters between which a connect |
