US 6,510,352 B1Grant
Methods and apparatus for object-based process control
Issue Date:2003-01-21
•72 Claims
•18 Drawing Sheets
Abstract
The provides improved control devices, systems and methods for operation thereof. These rely on control devices that provide virtual machine environments in which Java objects, or other such software constructs, are executed to implement control (e.g., to monitor and/or control a device, process or system). These objects define blocks which are the basic functional unit of the control. They also define the input, output and body parts from which blocks are formed, and the signals that are communicated between blocks. The objects also define nested and composite groupings of blocks used to control loops and higher-level control functions.
Metadata
Assignee
- The Foxboro Company
Inventors
- Paul C. Badavas
- Peter D. Hansen
Application Information
Application Number:US 09/627,466
Filing Date:2000-07-28
Priority Date:1999-07-29
Art Unit:7
Classifications
IPC:
G05B 1101
Field of Search:
700 19700 18700 20700 48700 49700 50700 51700 52717 1717 9717 10717 11709 1709100709103
Patent Drawings (18 sheets)
Description
[0002] This application claims the benefit of priority of U.S. Patent Application Serial No. 60/146,406, filed Jul. 29, 1999, entitled Process Control Objects, as well as of U.S. Patent Application Serial No. 60/149,276, filed Aug. 17, 1999, entitled Methods and Apparatus for Process Control (“AutoArchitecture”), the teachings of all of the foregoing of which are incorporated herein by reference.
Background of the Invention
[0003] The invention pertains to control and, more particularly, to methods and apparatus for implementing process and other control systems at lower cost, with greater flexibility and robustness.
[0004] The terms “control” and “control systems” refer to the control of a device or system by monitoring one or more of its characteristics. This is used to insure that output, processing, quality and/or efficiency remain within desired ranges over the course of time. In many control systems, digital data processing or other automated apparatus monitor a device, process or system and automatically adjust its operational parameters or variables. In other control systems, such apparatus monitor the device, process or system and display alarms or other indicia of its characteristics, leaving responsibility for adjustment to the operator.
[0005] 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.
[0006] Modern day control systems typically include a combination of field devices, controllers, workstations and other more powerful digital data processing apparatus, the functions of which may overlap or be combined. Field devices include temperature, flow and other sensors that measure characteristics of the subject device, process or system. They also include valves and other actuators that mechanically, electrically, magnetically, or otherwise effect the desired control.
[0007] Controllers generate settings for the actuator type field devices based on measurements from sensor type field devices. Controller operation is typically based on a “control algorithm” that maintains a controlled device at a desired level, or drives it to that level, by minimizing differences between the values measured values and, for example, a setpoint defined by the operator. Workstations, control stations and the like are typically used to configure and monitor the process as a whole. They are often also used to execute higher-levels of process control, e.g., coordinating groups of controllers and responding to alarm conditions occurring within them.
[0008] In an electric power plant, for example, a workstation coordinates controllers that actuate conveyors, valves, and the like, to move coal or other fuels to a combustion chamber. The workstation also configures and monitors the controllers that maintain the dampers that determine the level of combustion. The latter operate, for example, by comparing the temperature of the combustion chamber with a desired setpoint. If the chamber temperature is too low, the control algorithm may call for incrementally opening the dampers, thereby, increasing combustion activity and driving the temperature upwards. As the temperature approaches the desired setpoint, the algorithm incrementally levels the dampers to maintain the combustion level.
[0009] The design of control systems and specification of the control algorithms is typically performed using tools known as configurators. An exemplary such tool is provided with the I/A Series® (hereinafter, “IAS” or “I/A”) systems, marketed by the assignee hereof. A graphical configurator, FoxCAE,® provided with those systems permits an engineer to model a process hierarchically and to define a control algorithm from that hierarchy. Once configuration is complete, the control algorithm is downloaded to the control devices. This may involve “compiling” the algorithm in order to convert it into code understood by the controllers and other control devices.
[0010] While prior art products such as the aforementioned ones by the Assignee hereof continue to meet success in the marketplace, there remains a need for advancement.
[0011] In view thereof, an object of this invention is to provide improved methods and apparatus for control. A related object is to provide such methods and apparatus as can be achieved with lower cost, greater flexibility and robustness.
[0012] Another object of the invention is to provide such methods and apparatus as facilitate the modeling of control processes by engineers and users alike.
[0013] A related object is to provide such methods and apparatus as facilitate the generation of higher-quality modeling software at lower cost and more widespread applicability.
[0014] A further object is to provide such methods and apparatus as can be used in process and other control systems.
Summary of the Invention
[0015] The foregoing are among the objects attained by invention which provides, in one aspect, an improved control device for a process or other control system. The device provides a virtual machine environment in which Java objects, or other such software constructs, are executed to implement control (e.g., to monitor and/or control a device, process or system). These objects, referred to herein as process control objects (PCOs), define blocks, which are the basic functional unit of the control. They also define the input, output and body parts from which blocks are formed, and the signals that are communicated between blocks. PCOs also define nested and composite groupings of blocks used to control loops and higher-level control functions.
[0016] By way of non-limiting example, a control system with devices according to the invention can have a workstation and controllers, each providing a Java virtual machine (JVM) environment. Executing on the devices are Java PCOs embodying their respective control functions and signaling. Thus, PCOs executing in each controller monitor and control sensors and actuators under that controller's purview. PCOs executing in the workstation monitor and control the controllers themselves (as well, perhaps, as monitoring the outputs of some of the field devices). Intelligent field devices in the control system may also execute PCOs, thereby, further distributing the control function and taking up tasks otherwise handled by the controllers and workstation.
[0017] Referential Communication Between Process Control Entities
[0018] Further aspects of the invention provide control devices as described above in which individual data, such as measurements, setpoints or other values, are communicated block-type PCOs by reference. To this end, only one object of each pair of objects between which a given datum is communicated stores the datum itself, e.g., by non-limiting example, in a data structure referred to as below as a “variable.” The other block maintains only a reference, i.e., a pointer, address, symbolic or other reference, to the datum. In order to access the sole instance of the datum as between at least those two blocks, the latter block interrogates—or, if permitted, sets the value of—the datum by using the pointer, address or other reference.
[0019] A given datum, according to further aspects of the invention, can be maintained in the block that is the logical and/or physical source of the measurement, setpoint or other value to which it pertains. For example, a PCO embodying an analog input (AIN) block maintains a data structure containing data measured by it. PCO blocks that use those measurements access that data structure and, thereby, the data, by reference.
[0020] The data structures embodying data can themselves be PCOs, e.g., by non-limiting example, instantiated from the “signal” class described in the detailed description, below. According to further aspects of the invention, in addition to storing specific measurements, setpoints or values (e.g., the “variables” described below), these data structures can maintain range, status, time stamps and/or other information pertaining to them.
[0021] Thus, for example, a “float” variable data structure in a PCO analog input block maintained in a thermocouple sensor device can have, in addition to a floating point value representing the temperature value measured by that device, range values representing permissible upper and lower values for the measured temperatures. It can also have status values representing signal quality (e.g., SEVA values of the type discussed elsewhere herein) and/or initialization state; limit status for signal limiting and connection status; timestamp values identifying when the value was last changed; among others. According to related aspects of the invention, the “limit status” can include a flag, e.g., a “publish” bit, indicating whether the subject datum has been communicated to other elements of the control system, e.g., by “publication.”
[0022] An advantage of devices using PCOs that communicate data, i.e., establish “connections,” in the manner described above is that they minimize the unnecessary duplication of data and the attendant cost of maintaining coherency. A further advantage is that they can more readily propagate variables and their attendant values, ranges, and so forth, throughout the system.
[0023] With respect to this latter point, a control system having devices as described above will typically implement a control scheme wherein a value generated (or measured) by single block is used by several downstream blocks. Thus, for example, a PCO block maintained by a thermocouple field device might be connected to a PCO control block executing in a controller that processes the thermocouple output to adjust a fuel intake valve. It might also be connected to a PCO control block executing in an intelligent field device that adjusts a damper level.
[0024] The use of data structures as described above facilitate establishing common values, ranges, and so forth, e.g., for the thermocouple output, among all of the PCO blocks that use connections. That information is stored only in the source PCO, e.g., the thermocouple PCO. Hence, the risk of data loss or misinterpretation resulting from lack of coherency is minimized, as is the risk of incorrect scaling and the like among the blocks participating in the connections.
[0025] Control devices as described above can, according to further aspects of the invention, maintain unilateral and/or bilateral connections for the information that they exchange. Unilateral connections utilize a data structure as described above to store a single “forward going” data value (or set of values), along with its attendant range, status, limit status, time and other related information. These are typically used, for example, in connections to/from sensors and actuators.
[0026] The control devices can also utilize PCOs that establish bilateral connections maintaining two data values (or sets of values), along with attendant range, status, limit status, time and other related information. These can be used, for example, in connections in which a forward going data value is dependent on a backward going one.
[0027] For example, a PCO functioning as a proportional integral derivative (PID) control block and executing in an intelligent actuator might provide the setpoint to a PCO executing as an analog output (AOUT) control block in that same actuator. A single data structure maintaining the AOUT setpoint can be stored in the PID, with the AOUT accessing it by reference. The PID requires feedback, such as the current valve position, in order initialize its output to avoid bumping that value at startup. The AOUT can provide that feedback, according to related aspects of the invention, by accessing the data structure by reference and storing a backward going data value (or feedback value) there. Similar bilateral communications are required between cascaded controllers where the output of one is the setpoint of another.
[0028] Control devices utilizing PCO that establish bilateral connections have additional advantages, including, eliminating the need to establish and ensure that forward-going and back-going values for each connection necessarily run between the same two blocks. In addition, they ensure that consistent range, status, limit status, time and other information concerning the forward-going and back-going values are shared by both PCO that are parties to the connection.
[0029] Process Control Entities with Mandatory and Optional Parts
[0030] Further aspects of the invention provide control devices as described above that include PCOs with mandatory parts for which memory space is allocated at the time of object creation (or instantiation) and with optional parts for which memory space is allocated only as needed. The optional parts can be added subsequent to creation, typically, for example, during configuration.
[0031] By way of example, an intelligent field device embodying a PCO according to the invention representing an analog input block (AIN) can have a mandatory input part for receiving, linearizing, filtering and scaling measurements. It can also have a mandatory output part for processing or switching and for making the result available to PCOs, e.g., embodying control algorithms. These mandatory parts are instantiated when the AIN PCO is first instantiated. Optional parts for the AIN PCO permit, inter alia, establishing alarm limits, defining a characterizer that linearizes an input measurement, defining filtering for an input measurement, and defining limits for output values, and to utilize potential emergency interlock output values. These optional parts can be instantiated, if at all, e.g., when the already-instantiated PCO is being configured.
[0032] The invention provides, in other aspects, control devices as described above in which the parts, whether optional or mandatory, are associated with block-type PCOs and are instantiated locally in relation to the respective blocks that contain them. Put another way, the parts are instantiated in the processes responsible for executing the PCO in which they are contained.
[0033] Further aspects of the invention provide control devices as described above in which mandatory parts of a PCO are instantiated in a declaration or a constructor method (e.g., a default constructor) of a class from which the PCO is instantiated. While optional parts can be instantiated by a constructor (e.g., other than the default constructor), they can also be instantiated by configurator following creation of the PCO.
[0034] Control device incorporating dynamically configurable PCOs, i.e., with mandatory and optional parts, as described herein are advantageous, for example, in that their constituent blocks provide all necessary input, output and/or processing behaviors, without dedicating memory or other resources to unused ones. Thus, the AIN PCO described in the example above can be selectively configured to allocate memory and processor resources to alarms and filters, yet, not to consume resources with optional features that will not be used, e.g., interlocks and characterizers. Moreover, such PCOs instill in their respective control devices (e.g., their respective control stations, work stations, controllers, or field devices) optional behaviors that execute as if “compiled in,” yet, not requiring recompilation on configuration.
[0035] In addition to individual block-type PCOs that are dynamically configurable, further aspects of the invention provide control devices and systems with dynamically configurable composite PCOs. These are PCOs with mandatory constituent blocks for which memory space is allocated at the time of object creation (or instantiation) and with optional blocks for which memory space is allocated only as needed. The optional blocks are added at the time each composite PCO is created, e.g., during configuration, or later.
[0036] By way of example, a control system executing a PCO composite-type object representing a process control loop, can have a mandatory analog input block (AIN), a mandatory analog output (AOUT) block and a mandatory proportional-integral-derivative (PID) control block. Optional blocks for the composite PCO can provide for feedforward control. These can include, for example, an optional second AIN block, e.g., for detecting disturbances in the controlled process, as well as for an optional, feed forward control block that generates additional control values to facilitate disturbance compensation in the first (feedback), PID block.
[0037] Process Control System with Blocks Having Common Input and/or Output Sections
[0038] Still further aspects of the invention provide control systems and control devices as described above with block-type and composite-type PCOs that use standardized classes (or other definitional software constructs) to define input and output parts that receive and transmit information on behalf of the PCOs. The classes provide common interfaces between interconnected blocks, as well as insuring common processing of information by them.
[0039] By way of example, PCO blocks executing on the workstations, controllers, intelligent field devices and other control devices in a control system according to the invention can have input and output parts instantiated from a common set of input and output classes, respectively. The PCOs can be of a variety of composite block types and individual block types, the latter including, for example, AnalogInput, AnalogOutput, PID, and Feedback Tuner. The common set of classes from which their input and output parts are instantiated include, according to one aspect of the invention and by way of non-limiting example, cascaded floating point input, cascaded floating point output, unidirectional boolean input, unidirectional boolean output.
[0040] According to related aspects of the invention, the input and output parts of the block PCOs are created from possibly overlapping subsets of classes selected from a common set of standardized classes. Thus, for example, PCOs that embody PID control blocks include input and output parts defined with standardized cascaded floating point input and cascaded floating point output classes. PCOs that embody “user” control blocks also use the standardized cascaded floating point output classes, though their input parts are defined using a different standardized class, to wit, the unidirectional floating point input class.
[0041] Further aspects of the invention provide control systems and control devices as described above wherein the input and output parts, themselves, use standardized classes to define objects that reflect, by way of non-limiting example, state, status, mode, and option assignments shared by the respective blocks and their parts, as well as to define information that is communicated between the blocks. In addition to providing common methods for setting and getting values, these classes define methods for linking variables (and their constituent parameters) to establish connections between blocks.
[0042] By way of example, the standardized cascaded floating point input part contained in the above-described PID control blocks can have constituent objects defined from a standardized “lrs” setpoint mode class that characterizes the setpoint source for an input part, e.g., whether it is set by an external block, by a supervisory task, or by the operator. By way of further example, the cascaded floating point output part of such a PID block can include a constituent objects defined from a standardized “mas” mode class that characterizes source of the outgoing signal generated by that output part, e.g., whether it is set by the block, a supervisory task or the operator.
[0043] A control device with a PCO block having input and output parts utilizing objects instantiated independent classes, such as the lrs and mas classes described above, can provide for the independent characterization of setpoints received and generated by the PCO. Thus, for example, the block can be set by an operator at runtime to provide for any of local, remote or supervisory setpoint input and, at the same time, for any of manual automatic and supervisory setpoint output. Moreover, the block can retain a setpoint value previously defined, e.g., before transition into manual or supervisory mode, to facilitate transition back to automatic mode.
[0044] Further related aspects of the invention provide control systems and control devices where the input, output, body and other parts use other standardized classes. These can include, by way of non-limiting example, a signal quality status class, a maintenance status class, a limit indication and linking/setting permissions class, among others.
[0045] The invention provides, in still further aspects, control systems and devices as described above in which memory is allocated for mandatory constituent portions of a part at the time of creation and in which memory is allocated for optional portions only as necessary, e.g., during configuration. These portions can include PCOs defined in accord with the aforementioned signal classes, as well as in accord with other classes that make up the parts.
[0046] According to further related aspects of the invention, that parts of PCO control blocks utilized in control systems and devices can have the mandatory constituent that include, by way of example, the aforementioned lrs and mas setpoint mode classes of the cascaded floating point input and output parts, respectively. Further mandatory classes of these parts can include, by way of further non-limiting example, a floating point variable class for containing the setpoints received or set by the input and output parts, respectively. Optional classes for these parts can include a limit class (defined as a “parts” class in the discussion below) used to define high and low setpoint values for the input and output parts that include the limit class.
[0047] Still further aspects of the invention provide control systems and devices as described above in which the block-type PCOs include body parts, in addition to input and output parts. The body parts can, for example, embody attributes and methods that are unique to the particular block class, in addition to standardized parts such as for feedback tuning and deadtime compensation.
[0048] Multi-Input Analog Input Block for Process Control System
[0049] Further aspects of the invention provide a control device with an analog input block (AIN) coupled to accept readings from multiple sensors or other input devices and to generate an output based on one or more of those readings. The analog input block, which can be a PCO as described above, can take a reading from each of the multiple sensors during each block processing cycle (BPC), e.g., each cycle during which the AIN is invoked (typically, along or in sequence with other blocks in a common control system).
[0050] Related aspects of the invention provide a control device configured as an AIN as described above that generates an output based on the multiple inputs every “block period,” e.g., every period (typically multiple BPCs) in which the output of the AIN is updated. The output can be, by way of non-limiting example, minimum, maximum, median, weighted average (e.g., based on uncertainty values, such as SEVA, provided by the sensor as part of the variable data structure) or other selection or function of the multiple inputs.
[0051] Further related aspects of the invention provide a control device configured by a PCO as an AIN block as described above in which the input part of that block samples measurements received from its respective sensor every BPC, notwithstanding that the block period may run over several BPCs. Those measurements can be averaged with one another (e.g. by the input or body parts of the PCO), prior to being statistically compared or combined with the outputs of other input parts in the AIN.
[0052] Still further aspects of the invention provide a AIN PCO as described above having multiple input parts, each receiving, filtering, characterizing and/or otherwise processing a respective one of the measurements received by the AIN block. A control device in which such an AIN is embodied can dedicate memory space upon instantiation of the block or its subsequent configuration to only such input parts as are required by the particular implementation. Moreover, such a control device can apply independent filtering, characterizing or other functions to each of the inputs.
[0053] Further aspects of the invention provide control systems embodying one or more control devices as described above and/or utilizing PCOs as described above. Other aspects provide control devices and systems having individual ones of the features described above, alone or in combination with other ones of the features.
[0054] Yet other aspects of the invention provide methods of operating control devices and control systems paralleling the foregoing.
[0055] These and other aspects of the invention are evident in the attached drawings, and in the description and claims that follow.
Brief Description of the Drawings
[0056] A more complete understanding of the invention may be attained by reference to the drawings, in which:
[0057] FIG. 1 depicts a process control system 10 of the type with which the invention is practiced;
[0058] FIG. 2 depicts the object model notation utilized in this disclosure;
[0059] FIG. 3 depicts a control and information collection class and object architecture in a control system according to the invention;
[0060] FIG. 4 depicts control and information collection signal, part, and block classes in a control system according to the invention;
[0061] FIG. 5 depicts input/output classes for intelligent and standard devices in a control system according to the invention;
[0062] FIG. 6 depicts control and information collection nested classes in a control system according to the invention;
[0063] FIG. 7 depicts an architecture for a typical block class in a control system according to the invention;
[0064] FIG. 8 shows examples of unidirectional and cascade input and output part classes in a control system according to the invention;
[0065] FIG. 9 depicts a loop composite class in a control system according to the invention;
[0066] FIG. 10 depicts a PLoop composite class in a control system according to the invention;
[0067] FIG. 11 depicts a cascade composite class in a control system according to the invention;
[0068] FIG. 12 depicts a TempProcess Composite class in a control system according to the invention;
[0069] FIG. 13 depicts Loops2 control and process objects in a control system according to the invention;
[0070] FIG. 14 depicts Loops2 control and process objects and details in a control system according to the invention;
[0071] FIG. 15 depicts TempCasc control and process objects in a control system according to the invention;
[0072] FIG. 16 depicts TempCasc control and process objects and details in a control system according to the invention;
[0073] FIG. 17 depicts cascade peer-to-peer communication in a control system according to the invention; and
[0074] FIG. 18 depicts variable and parameter transfer and rules in a control system according to the invention.
Detailed Description of the Illustrated Embodiment
[0075] FIG. 1 depicts a process control system 10 of the type with which the invention is practiced. The system includes networked control devices that monitor and control a hypothetical mixing process 20 that utilizes mixing chamber 22, fluid inlets 24, 26, fluid outlet 28, paddle 30, cooler 32, and cooler inlet 34. Though illustrated and described below for use in connection with process control, those skilled in the art will appreciate that apparatus and methods according to the invention can be used in connection with any industrial, manufacturing, service, environmental or other process, device or system amenable to monitoring or control (hereinafter, collectively, “control”).
[0076] The networked control devices include actuators, such as the valves depicted as controlling inlets and outlets 24-28 and 34. A further actuator is shown controlling paddle 30. These and other actuators utilized by the control system are constructed and operated in the conventional manner, as modified in accord with the teachings hereof. The actuators operate under control of respective field device controllers, labeled CTL, that are also constructed and operated in the conventional manner to provide initialization, signal conditioning and communications functions.
[0077] Rather than using separate controllers CTL, the actuators can be of the intelligent variety and can include integral microprocessors or other digital data processing apparatus for control, initialization, signal conditioning, communications and other control-related functions. For sake of convenience, the label CTL is used regardless of whether the control-related functionality is integral to the actuators (e.g., as in the case of intelligent actuators) or otherwise.
[0078] Illustrated sensor 29 monitors a temperature, level or other characteristic of fluid in chamber 22. The sensor 29, as well as other sensing apparatus utilized by the system, are constructed and operated in the conventional manner known in the art, as modified in accord with the teachings hereof. They can be coupled to the control network via a transmitter or other interface device INT that, too, is constructed and operated in the conventional manner, as modified by the teachings hereof. The interface devices facilitate initialization, signal conditioning and communications between the sensors and the control system. As above, one or more sensors can be of the intelligent variety, incorporating integral microprocessors or other digital data processing capabilities for initialization, signal conditioning, communications and other control-related functions. Here, too, the label INT is used in reference to the control-related functionality, regardless of whether embodied in an intelligent transmitter or otherwise.
[0079] The networked control devices include one or more controllers 36 that monitor and control respective aspects of the hypothetical mixing process in the conventional manner, as modified in accord with the teachings hereof. The controllers can comprise mainframe computers, workstations 40, personal computers 42, special-purpose hardware or other digital data processing apparatus capable of performing conventional monitoring and control functions. Preferred controllers are constructed and operated in the manner of the CP control processors commercially available from the assignee hereof, as modified in accord with the teachings herein.
[0080] The control system 10 includes elements that serve as user interfaces and that provide configuration and/or control functions, all in the conventional manner as modified in accord with the teachings hereof. Illustrated for these purposes are, for example, workstation 40 and personal (laptop) computer 42. These devices can provide configuration and control functions directly, as in the case of workstation 40, or in cooperation with server devices (not shown). Apparatus 36-42 can couple with one another directly, e.g., via bus or network connection (as illustrated below), or indirectly, e.g., via satellite, wireless connection or modem connection.
[0081] The devices 36-42, CTL and INT, collectively, referred to as “control” devices, are coupled for communications via a medium that permits at least selected ones of the devices to communicate with one another. To this end, in the illustrated embodiment those devices are coupled via one or more networks 48 that are, preferably, IP-based such as, by way non-limiting example, Ethernets. The network(s) can include, as indicated by the multiple segments shown in the drawing, multiple segments such as various wide and local area networks. They may also include high and/or low bandwidth components, such as phone lines, and low and/or high latency components, such as satellites networks.
[0082] In the preferred, illustrated embodiment, each of the control devices 36-42, CTL and INT, provides virtual machine environment for executing Java byte code (or other such intermediate code) in the form of Java applications, Java applets, Java servlets, or like constructs in other software languages that, for example, configures the respective device to provide monitoring and/or control (collectively, “control”), including, by way of non-limiting example, servicing sensors to provide inputs (analog or otherwise), servicing actuators to provide outputs, executing blocks (composite, individual or otherwise) that include a control algorithm and/or otherwise to participate in the control system.
[0083] By way of non-limiting example, the illustrated intelligent field devices can include low power processors, along with a random access memory, read-only memory, FlashRAM, and appropriate sensor/actuator interfaces. The processors of those devices can execute a real-time operating system, as well as a Java virtual machine (JVM). Process control blocks or entities in Java byte code execute in the JVMs to configure the respective field devices to perform process control functions, e.g., for analog input (AIN), analog output, proportional integral derivative (PID) control and so forth.
[0084] By way of further non-limiting example, the controllers, workstations, control stations and other digital data processor-based control devices can include larger, more powerful central processing units, along with on-board memory (e.g., RAM, ROM, FlashRAM), mass storage, sensor/actuator interfaces, as necessary, conventionaloperating systems and JVMs, and so forth. The JVMs on these more powerful devices permit them to perform a still wider range of control functions, e.g., to monitor control larger scale plant operations.
[0085] A further appreciation of the hardware and software environment provided by system 10 may be attained by reference to commonly-assigned, co-pending U.S. patent application Ser. No. 09/591,604, and to counterpart PCT Application Serial No. PCT/US 00/15860, both filed Jun. 9, 2000, entitled METHODS AND APPARATUS FOR CONTROL USING CONTROL DEVICES THAT PROVIDE A VIRTUAL MACHINE ENVIRONMENT AND THAT COMMUNICATE VIA AN IP NETWORK, The teachings of these applications are incorporated herein by reference.
[0086] Described below are aspects of the operation of the aforementioned control devices 36-42, CTL and INT, and, more generally, of the control system 10 deriving from execution on the devices of Java applications, applets, servlets (or other such software constructs) to implement control. These objects, referred to herein as process control objects (PCOs), define blocks which are the basic functional unit of the control. They also define the input, output and body parts from which blocks are formed, and the signals that are communicated between blocks. PCOs also define nested and composite groupings of blocks used to control loops and higher-level control functions.
[0087] The Advantages of PCOs
[0088] As evident in the discussion above and in the pages that follow Process Control Objects facilitate the development, implementation and maintenance of control systems, additionally, maximizing their flexibility of configuration and robustness. PCOs also facilitate the introduction of new control objects and enhancements without affecting the running system, in addition to enabling on-line modification and upgrade of objects. Control systems utilizing PCOs are, moreover, portable: control classes, written once, can run everywhere. The systems are also scaleable.
[0089] By way of both review and introduction, control systems implemented with PCOs implement optional parts and functionality separately from mandatory parts, thus, minimizing consumption of undue resources. Their use of separate input and output parts speeds implementation, while permitting the input and output sides of each block to be independently configured and operated.
[0090] The PCO control architecture provides standardized input and output part classes used in all blocks. Input and output part classes provide initialization, anti-windup, cascade handling, local/remote/supervisory switching, manual/auto/supervisory switching, standardized variable naming, input and output multiplicative and additive feedforward, output selection (limiting with an override controller). In addition optional parts for the input and output classes furnish alarming, limiting, filtering, feedforward, characterization, and interlock. Architecturally the input and output part classes provide standard interfaces between interconnected blocks.
[0091] PCOs provide a framework where interconnected block and nested classes are aggregated to create higher level nested classes, which are then used to create object instances. These higher nested instance include, for example, all control for a process unit, all information collection for a process unit, and so forth. Information is stored at its source, permitting other objects to reference it, e.g., via implicit pointers, addresses, symbolic references, or the like, in order to obtain specific datum (such as measurements) and information pertaining to it. For objects residing in remote stations the source passes the referenced information to proxy objects residing in those stations.
[0092] In a control system implemented using PCOs, scaling is done at the source and transmitted to the sink(s) when it changes. For example, in a cascaded controller, the local, remote, and supervisory setpoints obtain scaling from the measurement input. A cascade output obtains scaling from its back-calculated input. In general, cascade scaling information flows upstream. An analog output object has no measurement, therefore the scaling of its remote setpoint and back-calculated output is either entered locally or obtained from the downstream field device.
[0093] Other aspects of a control implementation using PCOs is that it permits the creation of object classes for required inter-block signals to communicate values with signal (SEVA) quality status, cascade handling (bumpless initialization and anti-windup) logic, and permissions for connection, setting, and configuration. Moreover, it makes automatically the backward interconnection for cascaded blocks.
[0094] Object Model Notation
[0095] FIG. 2 shows the notation for object and class diagrams used in this patent application. Those skilled in the art will appreciate that this is a subset of the standard Rumbaugh notation.
[0096] Architecture of Process Control Classes
[0097] This section describes the overall architecture for Process Control Objects and introduces the signal, part, block, nested, and composite classes and objects.
[0098] Signal Object
[0099] A signal object is an object that is implemented as a component of a block or a part object, and its name includes the name of its block object. It is located locally in relation to the block object that contains it. A signal object is an instance of a signal class. Signal objects contain the information communicated between blocks or inserted into blocks as constants. These objects also provide methods to be used by users and tasks for setting and getting values and for linking and unlinking parameters and variables.
[0100] Signal Classes
[0101] Signal Classes are classes that provide signal objects as defined above.
[0102] Part Object
[0103] A part object is an object that is implemented as a component of a block or another part object, and its name includes the name of its block object. It is located locally in relation to the block object that contains it. A part object is an instance of a part class. Input and output part objects contain or reference float, boolean, or integer signal objects, which enable unidirectional and cascade communication between blocks. Some part classes provide objects for optional functionality such as alarm, limit, and filter, which can be components of the input and output part objects or blocks.
[0104] Part Classes
[0105] Part Classes are classes that provide part objects as defined above.
[0106] Block Object
[0107] A block object is an instance of a block class and provides a base level of functionality. It is the lowest level object, which can be implemented as an independent object with a network-wide unique name. A block object is made up of input part objects, a body, and output part objects. The input and output parts are independent of the body and enable unidirectional and cascade communication between blocks. The body contains the attributes and methods that are unique to the particular block class. In addition the body may contain optional parts such as feedback tuner, feedforward tuner, and deadtime. AnalogInput, AdvancedPID, and AnalogOutput are examples of block objects. Typically, block objects are used to create a hierarchy of nested objects.
[0108] Block Classes
[0109] Block Classes are classes that provide block objects as defined above.
[0110] Nested Object
[0111] A nested object is an instance of a nested class and is a component of possibly interconnected block and nested objects. Replication of a control solution is achieved with multiple instances of a nested class. Each object instance can be implemented as an independent object with a network-wide unique tag name. An example of a nested class is a loop class, name it Loop, which contains the AnalogInput, AdvancedPID, and AnalogOutput block classes with appropriate connections achieved by linking the input and output parts of the blocks. Class Loop can then be used to create many instances of loop composite objects. A second level nested class can be created by nesting together the AnalogInput and AdvancedPID block classes and the Loop class with appropriate connections to create a cascade class, name it Cascade. Class Cascade can then be used to create many instances of cascade composite objects.
[0112] Nested Classes
[0113] Nested Classes are classes that provide nested objects as defined above.
[0114] Composite Object or Composite
[0115] A composite object is an instance of a nested class implemented as an independent object with a network-wide unique name. For example instances of class Loop or Cascade with network-wide unique names are composite objects.
[0116] Composite Class
[0117] A composite class is a nested class whose object instances are implemented as independent objects with a network-wide unique name, that is, composite objects. When class Loop is used to create instances with network-wide unique names it is a composite class. However, the same class Loop when used as a component of the Cascade class is a component class, while class Cascade is a composite class.
[0118] FIG. 3 shows the architecture for the Process Control Objects (PCO). Square boxes indicate classes, while rounded ones indicate object instances (objects). The Signal Classes, shown with vertical lines, provide signal classes to the part and block classes, for example the float parameter and float variable classes.
[0119] The Part Classes, shown shaded, provide mandatory and optional part classes to the block classes, for example the uni-directional and cascade float input and output classes. The optional part classes also provide optional part classes to the mandatory part classes.
[0120] The Block Classes are typically used to create component and composite classes, which are then used to create many instances of composite objects (composites).
[0121] A tag name is an arbitrary string.
[0122] Predefined (Implementation-Standard) Control Classes
[0123] FIG. 4 shows the signal, part, and block classes for control and information collection in more detail. In particular it shows the inheritance hierarchy and aggregation of the part and block classes for control and information collection.
[0124] Class names start with a capital letter, while names for objects, attributes, and methods start with small letters with additional words concatenated to the first word starting with capital letters. This is the recommended practice by many authors and developers and is followed in this document.
[0125] The clear rectangular boxes indicate block classes, for example, AnalogInput class. The shaded rectangular boxes indicate part classes, for example, Alarm and FloatVariable classes. The boxes with the diagonal lines indicate signal classes, for example, boolean and float parameters and variables.
[0126] FIG. 5 shows the InputOutput classes for intelligent and standard devices, which are indicated by boxes filled with dots. The boxes with dotted lines indicate classes from FIG. 4. The InputOutput classes are parts of the UniDirFloatInput and CascFloatOutput classes for analog inputs and analog outputs, respectively.
[0127] FIG. 6 illustrates the aggregation of control block classes to create many levels of nested classes. The inheritance hierarchy and aggregation classes for control part and block objects shown in FIG. 4 furnishes the control block classes used to create nested classes.
[0128] As shown in the figure, the objects of class ControlNestedLevel1 contain block objects. In particular, they contain combinations of two or more (indicated by 2+) block objects. The objects of class ControlNestedLevel2, contain combinations of one or more (indicated by 1+) ControlNestedLevel1 objects, and optionally zero or more block objects. A level 2 control nested object must contain at least one level 1 control nested object.
[0129] Following this procedure, nesting can be generalized to N levels. Each higher level control nested object contains at least one control nested object from the level below it, and optionally, zero or more objects from any other levels as well as zero or more block objects.
[0130] This is how the composite classes of FIG. 3 are created and then used to create many instances of composite objects as required.
[0131] FIG. 7 shows the architecture for a typical block class. The Input Parts contain the parts and references for unidirectional and cascade variables. The input parts can also contain optional parts such as filter and alarm. The Output Parts contain parts and references for unidirectional and cascade variables. The output parts can also contain optional parts such as limit and alarm. The Body contains the attributes and methods that are unique to the particular block class. It can also contain optional parts such as feedback tuner and deadtime.
[0132] FIG. 8 provides examples of unidirectional and cascade input and output parts. More particularly, FIG. 8(a) shows the unidirectional part UniDirInput. The variable in comes from a source and there is no backward communication as indicated by the single incoming arrow. The variable pv can be a source for many sinks and there is no backward communication as indicated by the single outgoing arrow.
[0133] FIG. 8(b) shows the cascade part CascadeInput. The cascade part enables uni-directional and bi-directional communications. The variables in, fdFwd, pv, sp, and deviation are uni-directional as indicated by the single arrow. Variables remSP and supvSP are bi-directional as indicated by the double arrow.
[0134] Similarly, FIGS. 8(c) and (d) shows the uni-directional part UniDirOutput and the cascade part CascadeInput, respectively.
[0135] The Input and Output parts are instances of the part classes that are shown in the Control and Information Class structure of FIG. 4 and they are separate and independent from the Body of the typical block class. This enables inter-operability between components by connecting the output variable of an output part to the input variable of an input part.
[0136] When either the output part of the source block or the input part of the sink block is uni-directional, the communication between them is unidirectional (one-way) from the source to the sink. For example, the value and status of the output part's variable is passed by reference to the input part's variable.
[0137] When both the output part of the source block and the input part of the sink block are cascade, the communication between them is also cascade. That is from the source to the sink for both the forward value and status, and from the sink to the source for both the back value and status. In this case the sink component is connected to the source component and the source component is connected to the sink component. A single linkage of the sink to the source connects both the forward and back signals.
[0138] Control applications use both unidirectional and cascade connections. Consider, for example, heating cold water in a heat exchanger by condensing steam. The cold water flows through the tubes of the heat exchanger and steam flows through the shell of the heat exchanger. The objective is to heat the water to a desired temperature using cascade control, whereby the temperature controller sets the setpoint of the steam flow controller. The temperature controller uses the hot water temperature measurement, while the steam flow controller uses the steam flow measurement. The steam flow controller delivers the required steam by throttling the steam valve.
[0139] This is an example of cascade control, that is, the output of the temperature controller is cascaded to the setpoint of the steam flow controller. Consider the case where the operator opens the cascade by placing the steam flow controller on local control, and sets the steam flow setpoint herself, thereby disabling the temperature controller from doing so. When the operator closes the cascade and transfers control to the temperature controller there is going to be a “bump” in the steam flow unless the temperature controller output was initialized to the value of the steam flow local setpoint at the time of transfer.
[0140] This is precisely accomplished with the cascade connection. In normal cascade control the output of the temperature controller is connected to the setpoint of the steam flow controller. The forward value and status of the steam flow controller setpoint are the value and status of the temperature controller output to which it is connected. Also the back value and status of the temperature controller output are the back value and status of the steam flow controller remote setpoint to which it is connected.
[0141] When the cascade has been open for a period of time and the operator transfers control to the temperature controller by switching the steam flow controller from local to remote, the temperature controller knows this from its output's back status from the steam flow controller setpoint. At this time the temperature controller initializes and computes the value of its forward output to be the output back value, which the steam flow controller sets equal to its local setpoint value at the time of transfer. From then on normal cascade control commences again and the temperature controller manipulates the steam flow setpoint to drive the actual water temperature to the desired value, as determined by the value of the temperature controller setpoint.
[0142] Signal Classes
[0143] The signal classes are contained in the Signals package, described below. A package contains a number of Java files and each Java file contains one and only one class. Objects from Signals classes contain the information communicated between linked blocks or inserted into blocks as constants. These classes also provide methods to be used by users and tasks for setting and getting values and for linking and unlinking parameters and variables. The Signals package also contains an interface for shared constants, and a mode class, which is used by cascade input parts for local/remote/supervisory switching and by cascade output parts for manual/auto/supervisory/interlock switching.
[0144] The signal classes include the following: BoolParameter, BoolVariable, FloatParameter, FloatRange, FloatVariable, IntParameter, IntRange, IntVariable, Mode, ObjList. Parameter and Variable are abstract classes passing common methods and attributes through inheritance to the individual XxxParameter and XxxVariable classes.
[0145] Part Classes
[0146] The part classes are contained in the Parts package. A Part must be contained in a block or other part contained in a block. Each block may have one or more input parts, a body, and one or more output parts. Input and output Part classes contain or reference FloatVariable, BoolVariable, or IntVariable signals, which enable uni-directional or cascade communication between blocks. Some part classes provide objects for optional functionality such as alarm, limit, and filter and they can be components of input and output part objects or blocks.
[0147] An unused optional part has a null reference. The configurator must instantiate an optional part before it can be used or its parameters set.
[0148] The parts classes include the following: Alarm, BoolFilter, Characterizer, CascBoolInput, CascBoolOutput, CascFloatInput, CascFloatOutput, CasclntInput, CascIntOutput, Deadtime, Failsafe, FeedForward, Filter, InfoBuffer, IntFilter, Interlock, Limit, LinearFlow, PIDParameters, Ramp, TimeCount, UniDirBoolInput, UniDirBoolOutput, UniDirFloatInput, UniDirFloatOutput, UniDirIntInput, UniDirIntOutput, Zone,
[0149] InputOutput Classes
[0150] The InputOutput classes are contained in the InputOutput package. The InputOutput classes are parts of the UniDirFloatInput and CasFloatOutput classes for analog inputs and analog outputs, respectively. They are optional parts with a default null reference. The configurator must instantiate them before they can be used or their parameters set.
[0151] The InputOutput Classes provide the interface to input and output signals using the Java Native Interface (JNI), which provides Java classes with native methods.
[0152] Block Classes
[0153] The block classes are contained in the Blocks package. The block classes provide block object instances, which can be implemented as independent objects with network-wide unique names. Typically, block classes are used to provide component classes for composite classes, which are then used to create many instances of composite objects.
[0154] FIG. 7 shows the architecture for a typical block class. The Input Parts contain the parts for uni-directional and cascade variables. The input parts can also contain optional parts such as filter and alarm. The Output Parts contain the parts for uni-directional and cascade variables. The output parts can also contain optional parts such as limit and alarm. The Body contains the attributes and methods that are unique to the particular block class. It can also contain optional parts such as feedback tuner and deadtime.
[0155] The Input and Output parts are instances of the part classes and are separate and independent from the Body of the typical block class. This enables inter-operability between components by connecting the output variable of an output part to the input variable of an input part.
[0156] The configurator must instantiate a block and its mandatory and selected optional parts before it can be used or its parameters set.
[0157] Block is a parent class (superclass) to all block classes including the UserBlock class and its attributes and methods are inherited by all block classes. The UserBlock is a parent class to the Arithmetic and UserDefined classes and its attributes and methods are inherited by them. The following two sections provide a detailed functional description of the Block and UserBlock classes.
[0158] Block Class
[0159] Overview
[0160] Block is an abstract class that contains data and methods common to all blocks. It implements the Constants and Runnable interfaces. Options, mode, and status are conveyed with packed Booleans. Bit-mask definitions are contained in the Constants interface, which is inherited by most classes.
[0161] A part class, which provides a common function, may be contained in several block classes or other part classes. An optional part may be instantiated at configure time. If it is not configured, it has a “null” value in the container object.
[0162] The run method of each block is called each bpc. Its output is updated each period at a specified phase. The bpc is a configured float number in seconds, an integer number of milliseconds, preferably an integer multiple of 0.1 seconds. The nominal period is an integer number of bpcs less than or equal to the configured float blockPeriod, but at least one bpc. The execute method determines when each block updates its output based on its configured blockperiod and phase. The actual period is based on the time since the start of the last execution.
[0163] An output variable object is stored in an output part of its source block object. An input variable object of a block's input part may be linked (connected) to the output variable object by setting the input variable object equal to the output variable object. This is done at configure time with the output variable object's linkTo method, which checks for permissions.
[0164] Output variables are instances of the FloatVariable, BooleanVariable, or IntVariable classes. These contain a forw and may contain a back parameter object which are instances of the FloatParameter, Boolean Parameter, or IntParameter classes. Each of the parameter classes contains a value and two status bytes. The status bytes provide SEnsor VAlidation (SEVA) quality indications, cascade handling bits, downstream limit bits, and permissions. The parameter classes have getStatus, getValue, setValue, linkTo, and unlink methods to be used by users and tasks. The Variable classes contain alarmSum and maintenance status. The FloatVariable also contains linkTo, ack, and getAlarm methods, a range object, and the SEVA ‘uncertainty ’. Both source and sink have access to the members of a linked Variable object.
[0165] There are two types of input objects. One is an instance of the UniDirFloatInput class, the other is an instance of the CascadeFloatInput class. The UniDirFloatInput class accepts one input variable object. It may contain charac and filter objects, used to precondition the input variable prior to its use in the block algorithm. It outputs the pv variable. The CascadeFloatInput class inherits from the UniDirFloatInput class and also receives local, remote, supervisory, and feedforward input variables in addition to the measurement input variable. It outputs pv and deviation. The CascadeFloatInput class does the local, remote, supervisory mode switching and cascade handling for bumpless transfer and initialization. It also may contain a setpoint limit object, a local setpoint ramp object, a deviation alarm object, and an additive or multiplicative fdFwd object.
[0166] There are also two types of output objects. One is an instance of the UniDirFloatOutput class, the other is an instance of the CascFloatOutput class. The UniDirFloatOutput class provides one output variable object and receives manual and supervisory input variable objects. It provides auto, manual, supervisory mode switching and may provide an output ‘limit’ object and two output alarm objects. The CascFloatOutput inherits from the CascFloatOutput class. It also provides bumpless mode transfer and initialization. It may contain an additive or multiplicative fdFwd object and a limit object.
[0167] Attributes
[0168] tag object instance tag, a string.
[0169] description object instance description, a string.
[0170] type object instance type, a string
[0171] blockperiod is the time in seconds between output updates, float, default 0.5.
[0172] phase object instance phase, a double integer, default is 0.
[0173] Methods
[0174] run Arguments: none.
[0175] Executes object instance when invoked.
[0176] Returns: none.
[0177] UserBlock Class
[0178] Overview
[0179] An object from the UserBlock class has parts from the UniDirBoolInput, IntInput, and UniDirFloatInput classes, parts from the CascBoolOutput, CascIntOutput, and CascFloatOutput classes, and output mode parts from the Mode class.
[0180] Initialization, bumpless auto/manual/supervisory switching, and antiwindup protection are automatically provided when the user program calculates its outputFloat[i].out.forw.value by adding an incremental change to its outputFloat[i].out.back.value. Toggled booleans are treated similarly. The number of inputs, outputs, and modes are specified as the constructor arguments in the above order.
[0181] Methods from the FloatParameter, IntParameter and BoolParameter classes can be used to getValue( ), setValue( ), and getStatus( ). Methods from the FloatVariable and BooleanVariable classes can be used to getAlarm( ) and ack( ). Methods from the Mode class can be used to getMode( ) and setMode( ). Definitions of status and modes are in the Constants interface.
[0182] Attributes
[0183] inputBool is an optional array of BooleanInput parts.
[0184] outputBool is an optional array of CascBoolOutput parts.
[0185] inputFloat is an optional array of UniDirFloatInput parts.
[0186] outputFloat is an optional array of CascFloatOutput parts.
[0187] numberFloatOut number of float outputFloats specified as constructor argument.
[0188] mode is an optional array of Mode parts.
[0189] seed=100001 is an int seed number for generating the uniform (0,1) probability Distribution. Different seed numbers generate different, and statistically independent distributions.
[0190] Methods
[0191] run
[0192] Arguments: none
[0193] Called each time step to run the block.
[0194] Returns: none
[0195] runMethod contains the user written code.
[0196] Arguments: none
[0197] Called by run method
[0198] Returns: none
[0199] ranUniform
[0200] Arguments: none.
[0201] Computes uniform random number when invoked.
[0202] Returns: random number uniformly distributed between 0 and 1,
[0203] ranGauss
[0204] Arguments: none.
[0205] Computes Gausian random number when invoked.
[0206] Returns: random number distributed normally, with mean=0 and standard deviation (δ)=1.0, also known as the Gaussian distribution.
[0207] Composite Classes
[0208] FIG. 5 shows the implementation of composite classes in general. This section describes a library of the Nested superclass and composite classes.
[0209] Nested
[0210] Overview
[0211] Nested is an abstract class containing Strings for nested classes. It implements the Constants and Runnable interfaces. The config method prepares a comp list of its runnable components. The run method calls the run method of each composite and block on the comp list.
[0212] Attributes
[0213] tag_desc is a String composite user tag
[0214] description is a String composite brief description.
[0215] type is a String identifying the composte class.
[0216] offOn is a boolean that allows its components to run when true. Its default is false.
[0217] Methods
[0218] config
[0219] Arguments: none.
[0220] Returns: none.
[0221] run
[0222] Arguments: none.
[0223] Returns: none
[0224] Loop
[0225] Overview
[0226] Loop is a user defined nested class. It contains config and run methods, which are called by the main method.
[0227] FIG. 9 shows the Loop composite class, which contains the AnalogInput, AdvancedPID, and AnalogOutput classes connected as shown. Each time the Loop class is used to create a Loop composite object it also creates an instance of ain, pid, and aout. Each Loop composite object is created with the default attributes of the ain, pid, and aout, however, the default attributes can be overridden.
[0228] Attributes
[0229] ain is an instance of AnalogInput class.
[0230] pid is an instance of AdvancedPID class.
[0231] aout is an instance of AnalogOutput class.
[0232] comp is a ObjList of Runnable objects.
[0233] sp is the alias for the pid setpoint, a FloatParameter
[0234] pv is the alias for the pid process variable, a FloatParameter
[0235] out is the alias for the pid output, a FloatParameter
[0236] Attributes from Superclass
[0237] tag user specified Loop tag, a String
[0238] description “Secondary”, a String.
[0239] type “Loop”, a String.
[0240] Methods
[0241] Methods from Superclass
[0242] Config
[0243] Arguments: none.
[0244] Returns: none.
[0245] run
[0246] Arguments: none.
[0247] Returns: none
[0248] PLoop
[0249] Overview
[0250] PLoop is a user defined nested class. It contains config and run methods, which are called by the Configure class.
[0251] FIG. 10 shows the Ploop (Primary Loop) composite class, which contains the AnalogInput and AdvancedPID classes connected as shown. Each time the PLoop composite class is used to create a PLoop composite object it also creates an instance of ain and pid. Each PLoop composite object is created with the default attributes of ain and pid, however, the default attributes can be overridden.
[0252] Attributes
[0253] ain is an instance of AnalogInput class.
[0254] pid is an instance of AdvancedPID class.
[0255] comp is a ObjList of Runnable objects.
[0256] sp is the alias for the pid setpoint, a FloatParameter
[0257] pv is the alias for the pid process variable, a FloatParameter
[0258] out is the alias for the pid output, a FloatParameter
[0259] Attributes from Superclass
[0260] tag user specified Ploop tag, a String
[0261] description “Primary”, a String.
[0262] type “Ploop”, a String.
[0263] Methods from Superclass
[0264] config specifies internal default values and connections.
[0265] Arguments: none.
[0266] Returns: none.
[0267] run schedules and runs contained components when run is called.
[0268] Arguments: none.
[0269] Returns: none
[0270] Cascade
[0271] Overview
[0272] Cascade is a user defined nested class. It contains config and run methods, which are called by the Configure class.
[0273] FIG. 11 shows the Cascade composite class, which contains the Ploop and Loop composite classes connected as shown.
[0274] Attributes
[0275] Pri is an instance of the Ploop class.
[0276] sec is an instance of the Loop class.
[0277] comp is a ObjList of Runnable objects.
[0278] attributes from superclass
[0279] tag user specified Cascade tag, a String
[0280] description “TempCascade”, a String.
[0281] type “TempCascade”, a String.
[0282] Methods from Superclass
[0283] config specifies internal default values and connections.
[0284] Arguments: none.
[0285] Returns: none.
[0286] run schedules and runs contained components when run is called.
[0287] Arguments: none.
[0288] Returns: none
[0289] User Composite Classes
[0290] The user composite classes are examples of classes that would be created by a user in the same way as the composite classes discussed above. In addition users can create their own subclasses under the superclass UserBlock shown in FIG. 4.
[0291] The remainder of this section describes the TempProcess composite class, which is used to create instances that simulate a process, which provides temperature and flow measurements.
[0292] TempProcess
[0293] Overview
[0294] FIG. 12 shows the TempProcess user composite class, which contains two ProcessSim classes connected as shown. Each time the TempProcess composite class is used to create a TempProcess composite object it also creates an instance of flow and temp. Each TempProcess composite class is created with the default attributes of flowOut and tempOut, however, the default attributes can be overridden. The flow process is a one time step delay (0.5 sec.) and the temperature process is a 10 sec. delay.
[0295] Attributes
[0296] flow is a ProcessSim block with 1 input.
[0297] temp is a ProcessSim block with 1 input.
[0298] comp is a ObjList of Runnable objects.
[0299] FlowOut is the output of the flow process, a FloatVariable.
[0300] TempOut is the output of the temp process, a FloatVariable.
[0301] Attributes from Superclass
[0302] tag user specified TempProcess tag, a String
[0303] description is the String “Temperature Process”.
[0304] type is the String “TempProcess”.
[0305] Methods
[0306] config specifies internal default values and connections.
[0307] Arguments: none.
[0308] Returns: none.
[0309] run schedules and runs contained components when run is called.
[0310] Arguments: none.
[0311] Returns: none
[0312] Supv
[0313] Overview
[0314] Supv is a user defined class derived from the UserBlock class. It contains a run method. It has one floatOut and no inputs. It contains the controller parameters and ramps its output, used as the supervisory setpoint of the temperature controller.
[0315] Attributes
[0316] parTC is a PlDParameters part that contains parameters for the temperature controller.
[0317] ParFC is a PlDParameters part that contains parameters for the flow controller.
[0318] Attributes from Superclass
[0319] tag user specified Supv tag, a String
[0320] description is the String “Supervisory Setpoint”.
[0321] type is the String “Supv”.
[0322] Methods from Superclass
[0323] run
[0324] Arguments: none
[0325] Called each time step to run the block.
[0326] Returns: none
[0327] runMethod contains the user written code.
[0328] Arguments: none
[0329] Called by run method
[0330] Returns: none
[0331] Process Control Application Classes
[0332] The Block, Composite, and UserComposite classes can be used to create many object instances, which are simply referred to as composite objects or composites. An application instantiates and configures the composite objects using the config method and then executes them using the run method. The config method prepares a comp list of its runnable composites. The run method calls the run method of each composite on the comp list. The following two sections present the Loops2 and TempCasc applications.
[0333] Loops2
[0334] The Loops2 application illustrates composite objects for control and process simulation, which are made up of block objects.
[0335] Overview
[0336] FIG. 13 shows the Loops2 control composite objects and the process composite object, while FIG. 8.4.1-2 shows the same composites in detail. Application Loops2 uses the config method to instantiate (configure) composite objects s21, tl21, fl21, and pr21 and the run method to schedule them for execution.
[0337] Composite object s21 (Supervisor 21) is an instance of the Supv block class described in Sec. 8.3.2. It acts as a supervisory component and its output s21.out sets the temperature setpoint tl21.sp of Temp Loop tl21.
[0338] Composite object tl21 is an instance of the PLoop component class shown in FIG. 10 and is a single loop made up of block instances ain, and pid. Temp Loop 21 compares the temperature measurement value tl21.pv to the temperature setpoint tl21.sp and computes tl21.out, which sets the required steam flow setpoint fl21.sp
[0339] Composite object fl21 (Flow Loop 21) is an instance of the Loop composite class shown in FIG. 9 and is a single loop made up of block instances ain, pid, and aout. Flow Loop 21 compares the steam flow measurement value fl21.pv to the required steam flow setpoint fl21.sp and computes the required steam valve position fl21.out, which sets process variable pr21.pv
[0340] Composite object pr21 (Process 21) is an instance of the TempProcess composite class shown in FIG. 8.3.1-1 and simulates the temperature process. Process 21 uses process variable pr21.pv and computes the resulting steam flow fl21.pv and temperature tl21.pv.
[0341] Object ic21 is an instance of the InfoCollect block class. Object ic21 collects the date/time, value, and status for 10 (configurable) samples of tl21.pv, tl21.sp, fl21.pv, fl21.sp, and fl21.out. Each of these objects is double-buffered and when one buffer fills it switches to the other, which it overwrites.
[0342] Attributes
[0343] s21 is a Supv block.
[0344] tl21V1 is version 1 of a Ploop composite.
[0345] tl21 is an alias for a Ploop composite.
[0346] tl21V2 is version 2 of a Ploop composite
[0347] fl21 is a Loop composite.
[0348] pr21 is a TempProcess composite.
[0349] ic21 is an InfoCollect block.
[0350] comp is a ObjList of Runnable objects.
[0351] Methods
[0352] config overrides default values and makes external connections.
[0353] Arguments: none.
[0354] Returns: none.
[0355] run schedules Loop2 objects and calls their run methods.
[0356] Arguments: none.
[0357] Returns: none
[0358] TempCasc
[0359] The TempCasc application illustrates the cascade composite object for control, which is made up of component (composite) objects, while the process composite is made up of block objects.
[0360] Overview
[0361] FIG. 13 shows the TempCascade composite object and process, while FIG. FIG. 14 shows the same components in detail. Application TempCasc uses the config method to instantiate composite objects s21, tc21 and pr21, and the run method to schedule them for execution.
[0362] Composite object s21 (Supervisor 21) is an instance of the Supv block class described in Sec. 8.3.2. It acts as a supervisory component and its output s21.out sets the temperature setpoint tc21.sp of Temp Loop tc21.
[0363] Composite object Temp Cascade 21, tc21, is an instance of the Cascade composite class shown in FIG. 8.2.5-3 and is a cascade loop made up of Ploop instance pri, and Loop instance sec.
[0364] Temp Cascade 21, tc21, uses measurement values tc21.pv1 and tc21.pv2 and temperature setpoint tc21.sp and computes the required steam valve position out21.
[0365] Composite object pr21 (Process 21) is an instance of the TempProcess component class shown in FIG. 8.3.1-1 and simulates the temperature process. Process 21 uses process variable pr21.pv and computes the resulting steam flow fl21.pv and temperature tl21.pv.
[0366] Object ic21 is an instance of the InfoCollect block class. Object ic21 collects the date/time, value, and status for 10 (configurable) samples of tc21.sp, tc21.pv1, tc21.pv2, and fl21.out. Each of these objects is double-buffered and when one buffer fills it switches to the other, which it overwrites.
[0367] Attributes
[0368] s21 is a Supv block.
[0369] tc21 is a Cascade composite.
[0370] pr21 is a TempProcess composite.
[0371] comp is a ObjList of Runnable objects.
[0372] Methods
[0373] Config overrides default values and makes external connections.
[0374] Arguments: none.
[0375] Returns: none.
[0376] Run schedules TempCasc objects and calls their run methods.
[0377] Arguments: none.
[0378] Returns: none
[0379] Information Collection Objects
[0380] The purpose of information objects is to collect information for date/time, bool, int, and float parameters, alarmSum, and modes.
[0381] The purpose of InfoCollect objects is to collect a specified number of samples for the date/time, value, and status of a specified number of bool and float parameters, alarmsSum, and mode. The samples are collected in two buffers. When one buffer fills data storage is switched to the other.
[0382] An object from the InfoCollect class has paramBool parts from the BoolParameter class, paramInt parts from the IntParameter class, paramFloat parts from the FloatParameter class, actual mode parts from the Mode class, and alarmSum short integers.
[0383] Methods from the source FloatParameter and BoolParameter classes can be used to linkTo( ).
[0384] An object from the Event class may have a paramBool part from the BoolParameter class, paramInt parts from the IntParameter class, aparamFloat part from the FloatParameter class, an actual mode part from the Mode class, and an alarmSum short integer.
[0385] Methods from the BoolParameter, IntParameter, and FloatVariable classes can be used to linkTo( ).
[0386] Configuration
[0387] All parts that a block or part may use are declared. Mandatory parts are instantiated in the declaration or constructor, while optional parts are not. If optional parts are used, they are instantiated by the configurator. An arbitrary number of a specific part type is specified as an argument of the container's constructor method. For example, see the Supv class derived from the UserBlock in Loops2. An example of an optional part class is Filter, which is used in the CascFloatInput class.
[0388] Block classes are the lowest level classes that can be used as component classes that are optionally interconnected to create composite classes. Of course the composite classes can contain not only block classes but also other composite (component) classes, and so on. The block classes and their mandatory and optional part, signal, and inputOutput classes contain default values for each attribute.
[0389] Configuration of Composite Classes
[0390] Java code is written and compiled to create a new composite class. An already existing composite class can be instantiated and the resulting composite object can be customized to suit the application without compiling.
[0391] The code for a new composite contains name declarations of component blocks and composites. Its constructor method preferably contains calls to the component's constructor methods. A block object that may have multiple part objects from the same part class requires that the number of such part objects be specified as an argument in the block's constructor. This number may be passed from a containing composite constructor's argument.
[0392] A config method can be written that makes the internal variable and parameter connections between components and overrides default parameter value and option assignments. Connections are made and broken with linkTo and Unlink methods of the source parameter or variable. The linkto method will not succeed if the sink parameter or variable is already linked. A bidirectional cascade variable connection is made or broken with a single linkTo or Unlink method.
[0393] Each component composite's config method is called before overriding its assignments. This method may be used to instantiate new optional part objects and override their defaults. Each component block or composite is added to the composite's comp list in the order in which they are to execute.
[0394] A run method must be written. This calls in sequence the run method of each component block and composite.
[0395] After compilation any number of new composite objects can be created from this composite class in the same way as standard composite objects can be created from its library class.
[0396] The following are examples of composite classes: Loop, Ploop, Cascade, TempProcess.
[0397] Configuration of Block and Composite Object Instances
[0398] The block classes, the composite classes, and the user composite classes can be used to configure as many block and composite object instances as desired without recompiling provided there is a capable configure process.
[0399] Examples of block and composite object instances: Loops2 and TempCasc.
[0400] Configuration without Compilation
[0401] A control system implemented with PCOs as described above can be configured without compilation. To this end, the following steps can be performed:
[0402] Create a configuration object which contains configured PCO objects including parameter values, initial target mode and all connections among various blocks necessary for a closed-loop control.
[0403] Download the configuration object to the field device.
[0404] Create an object file based on the configuration object.
[0405] Start PCO execution from the object file.
[0406] Change connections among PCO blocks on the fly by invoking a remote method.
[0407] Transfer PCO parameters or variables from a client (host) to a server (field device) together with a string identifying the blocks and related PCO parts and signals.
[0408] Add and remove new blocks on the fly. New blocks are instantiated in the device and added into the runList. Connections to the new blocks are made on the fly as well.
[0409] Enable PCO optional parts on the fly.
[0410] Checkpoint on demand.
[0411] Upload an object file into the configurator.
[0412] A general RMI RemoteInterface is designed to make all on-line operations listed above possible. The methods in this RemoteInterface provide a useful framework for further development. In particular, several common methods are provided to deal with the following important issues:
[0413] Access PCO Parameters and Variables via a string name and an object. The string name follows the naming convention outlined in this document.
[0414] Make connections between blocks by invoking a remote method. Sink and source of arrays can be connected by a single remote method call.
[0415] Enable any PCO optional parts of any PCO blocks by invoking a single remote method.
[0416] The implementation of these methods utilizes the Java Reflection package which is included in Java 1.1.
[0417] IEC 1131-3
[0418] The IEC 1131-3 specification requires that its Sequential Function Charts and the three different languages namely, Structured Text, Ladder Logic, and Function Blocks work in concert, that is, a user can intermix them and create a control strategy. An example is the creation of a task using Structured Test which invokes the in-line code execution of a Ladder(s) or a Function Block(s).
[0419] Referring to FIG. 4 the IEC 1131-3 functionality (Sequential Function Charts, Structured Text, Ladder Logic, and Function Blocks) is shown as a subclass(s) under the UserBlock class. The UserBlock class provides the inputs and outputs as defined by the PCO to all its subclasses, thus enabling interconnection between PCO and IEC 1131-3 objects. The IEC 1131-3 configurator then can produce Java bytecode directly, or can compile source code of another language such as structured text into Java bytecode.
[0420] Execution Environment
[0421] Process Conrol Objects are preferably run as Java applications (though, they can be run as Java applets, servlets, or the like), with each composite and block object having its own run method, which is called by the run method of the next higher level composite object. Scheduling of a thread is preferably also done in Java, though it can be performed elsewise. For example, a real-time operating system can be used for scheduling, though, it is preferably not hardware specific. The sleep interval until the next run start is determined by adding the Block Processing Cycle (BPC) time to the present desired run start time and subtracting the current time (in milliseconds).
[0422] Each thread preferably has its own object set and run methods. When device is powered up, it starts a PCO application shell. The application shell itself is a Java application. Once it gets started, it runs until device is powered down or rebooted. After the application shell starts, it periodically checks for messages sent from a host running the configurator. In the illustrated embodiment, it understands three types of messages, FileCreation, Commit and Checkpoint.
[0423] FileCreation
[0424] This message is sent when the OK button is pressed. Once this message is received, the application shell serializes the configuration object to a file in the local file system of the device.
[0425] Commit
[0426] This message is sent when the Commit button is pressed. Once this message is received, the application shell does the following:
[0427] (1) Load the object file from the file system with the file name given in the message;
[0428] (2) Loop through the HashTable built in configuration object to identify all blocks;
[0429] (3) Make the block objects available to the remote object;
[0430] (4) Start a control thread which executes each object in the runList.
[0431] Checkpoint
[0432] This message is sent when the Checkpoint button is pressed. Once this message is received, the application shell serializes the current configuration object into a file in the local file system. This file is the checkpoint file which can be transferred to any computer via FTP.
[0433] Verification and Validation
[0434] Verification and validation of control blocks can be implemented in the manner described in copending, commonly assigned U.S. patent application Ser. No. 09/345,215, filed Jun. 30, 1999, and its counterpart PCT Application Serial No. US00/16152, filed Jun. 9, 2000, both entitled Process Control and Method with Auto-Updating, the teachings of which are incorporated herein by reference,
[0435] Platform Communications
[0436] Intra-Platform Communication
[0437] A cascaded FloatVariable, IntVariable or BoolVariable requires that some of its fields (subobjects) be communicated downstream (forw, alarmSum, uncertainty, maintenance) and others upstream (back, range). All unidirectional variable fields are communicated downstream. Intra-platform communication is done by reference. Variables are stored in an output part of the upstream block and linked to the downstream block with a linkTo( ) method called at configure time. There is also an unLink( ) method that can be called to reconfigure.
[0438] Objects are not moved from place-to-place within a platform. Input and output signals are instances of the xxVariable class. Variable linking is discussed above. “Constants” such as a gain or time constant are instances of the FloatParameter class. A FloatParameter can be linked to a forw or back parameter of a FloatVariable with a linkTo( ) method. Each Parameter (such as forw and back) has two status bytes, one is enumerated providing SEVA (clear/blind etc. instead of good/bad) status and cascade status, the other a packed Boolean containing limit bits and linking and setting permission status bits.
[0439] Cascade Peer-to-Peer Communication
[0440] Block-to-block input-output Variable connections within a station are made by reference. Although the data resides in the upstream block, either block may be the source for a particular attribute. Thus in a cascade (one-to-one) connection, the forw Parameter (value, status, limStatus) and alarmSum are set by the upstream block and the back Parameter and Range are set by the downstream block. The upstream block sets all of the unidirectional Variable attributes.
[0441] When the upstream and downstream blocks are in different stations, both unidirectional and bidirectional communication is more complicated. A copy (proxy) of the Variable (or Parameter) that resides in the upstream block must also exist in the downstream block. A cascade Variable must be split into its forward- and back-propagated Parameters. If push (publish-subscribe) communications are used, the source station needs a publish list of the source object references and a source String names (topics). The sink object needs a subscribe list of the sink object references (proxies) and source object String names (topics).
[0442] FIG. 17 shows an example of cascade peer-to-peer communication. The cascade control loop consists of AIN1 and PID1 that make up the temperature loop TL1 and AIN2 and PID2 that make up flow loop FL2. TL1 is in device NCAP1 and FL2 is in device NCAP2. In the forward direction from PID1 to PID2, output OUT of PID1 sets the remote setpoint RSP of PID2. In the backward direction from PID2 to PID1, output BACK of PID2 sets the BACK of PID1.
[0443] Each device has a Publisher and a Subscriber list and a CommsAPI. Each publisher and subscriber list contains references and topics. The topics are strings indicated in quotes.
[0444] Consider the communication in the forward direction from PID1 to PID2. Publisher1 shows reference PID1.OUT, which points to the actual parameter object OUT that needs to be transferred to its subscriber(s) and its corresponding topic “PID1.OUT”. This topic is subscibed to by Subscriber2, which shows topic “PID1.OUT” and reference PID1Proxy.RSP. This reference points to the actual parameter proxy object PID1Proxy.RSP where the required parameter object is transferred to. Controller PID2 references this object and uses it when it executes.
[0445] Now consider the communication in the back direction from PID2 to PID1. Publisher2 shows reference PID1Proxy.BACK, which points to the actual parameter object that needs to be transferred to its subscriber(s) and its corresponding topic “PID1.BACK”. This topic is subscibed to by Subscriber1, which shows topic “PID1.BACK” and reference PID1.BACK. This reference points to the actual parameter object BACK where the required parameter object is transferred to.
[0446] PCO Object Based Transfer
[0447] There are two types of communications transfer cascade and unidirectional.
[0448] Cascade transfer for peer-to-peer inter-platform communication requires transfer of parameters (value, status, limStatus, time). The previous section provides an example of transfer of parameters for cascade transfer.
[0449] Unidirectional transfer for peer-to-peer inter-platform communication requires transfer of variables (forw parameter, range, uncertainty, maintenance, alarmSum).
[0450] Object transfer as opposed to fundamental data type allows more information to be transferred in each message, therefore fewer messages and a smaller lookup table. Periodic transfers can be done using publish-subscribe services. One-to-one event driven transfers can be done with client-server services.
[0451] Peer-to-peer requires transfer of parameters (value, status, limStatus, time) for cascade transfer or variables (forw parameter, range, uncertainty, maintenance, alarmSum) for unidirectional transfer. Assuming publish-subscribe, each published object must have a unique string name that the subscribing device can recognize.
[0452] Operator display requires a trend object (setpoint, measurement, output forw parameters and input and output modes). Publish-subscribe may be used for this also. User setpoint, output, and mode changes can be transmitted using RMI.
[0453] Block details require transfer of an object containing the part parameters on each open window each time one changes. Settable changes can be transmitted using RMI.
[0454] Configuration requires the streaming of a PCO configuration or checkpoint file. Also it is necessary to be able to invoke remote methods with object arguments.
[0455] A historian can receive InfoCollect buffer objects.
[0456] FIG. 18 provides a summary of the variable and parameter transfer and rules.
[0457] Discussion
[0458] Blocks structured with a body and one or more input and output parts. Each cascade input part supports local/remote/supervisory switching, setpoint limiting, matched characterization, additive or multiplicative feedforward (bias or ratio setpoint), pv (process variable) output, measurement (in) filtering, deviation 9pv-sp), alarming, and support for bumpless initialization and antiwindup recovery from downstream limiting. Each output part supports manual/auto, supervisory switching, output limiting and alarming, additive or multiplicative feedforward, and bumpless initialization and antiwindup recovery from downstream limiting.
[0459] Variables are alarmed at their source and alarm status is communicated to sinks as part of the variable. Range is specified at a measurement source and communicated to sinks as part of the variable. Cascaded range is transmitted upstream. Blocks are the lowest level objects that are recognized at the system level. Each block and its parts must reside in a single station or device. Composites may span stations or devices.
[0460] Parts Classes
[0461] This section describes the part classes, which are contained in the Parts package. A Part must be contained in a block or other part contained in a block. Each block may have one or more input parts, a body, and one or more output parts. Input and output Part classes contain or reference either FloatVariable, BoolVariable, or IntVariable signals which enable uni-directional or bi-directional communication between blocks.
[0462] An unused optional part has a null reference. The configurator must instantiate an optional part before it can be used or its parameters set.
[0463] UniDirFloatInput
[0464] Overview
[0465] UniDirFloatInput is a measurement path input interface part that initializes and applies charactization, and filtering to its in signal.
[0466] Attributes
[0467] in is a reference to a FloatVariable source. in.forw.value is in eng. units.
[0468] charac is a reference to an optional signal Characterizer. charac.xPt[i] and charac.yPt[i] are breakpoint coordinates, float values.
[0469] filter is a reference to an optional signal Filter.
[0470] options is a packed boolean byte with:
[0471] I_O in is provided from device and point
[0472] device is the String name of an i/o device that is the source of in.
[0473] point is an integer used to identify an i/o address within the device.
[0474] pv is a Float Variable output representing the processed in value.
[0475] gain is a FloatParameter that multiplies pv.
[0476] dtime is a reference to an optional Deadtime part.
[0477] Methods for Developer
[0478] UniDirFloatInput (constructor)
[0479] Arguments: none.
[0480] Returns: none.
[0481] startup
[0482] Arguments: none
[0483] tests span.
[0484] Returns: true if ready to run.
[0485] CascFloatInput
[0486] Overview
[0487] CascFloatInput is an input interface part that provides initialization, local/remote/supervisory switching, optional setpoint limiting, optional local or supervisory setpoint ramping, optional deviation alarming, and an optional multiplicative or additive feedforward input.
[0488] Its internal methods are called by its container block.
[0489] startup( ) Called when out-of-service, returns true if ready to run.
[0490] inHandle( ) Sets back values and status, processes in.
[0491] locRemTarget( ) Determines the internal target mode.
[0492] devHandle(period) Handles setpoint and deviation.
[0493] initialize( ) Provides bumpless mode transitions.
[0494] modeHandle( ) Provides functionality for active mode.
[0495] limitStatus(lim) Propagates limit bits to back.status.
[0496] Attributes
[0497] remSP is an optional reference to the source of the remote setpoint FloatVariable.
[0498] supvSP is an optional reference to the source of the supervisory setpoint, a FloatVariable.
[0499] lrs is the setpoint local/remote/supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[0500] O_S Block is out of service
[0501] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[0502] LOCAL Operator or set method can set sp.
[0503] REMOTE External block (remSP) sets setpoint.
[0504] SUPER Supervisory task (supvSP) sets setpoint.
[0505] LINKED Permitted attribute indicates target connected to external source.
[0506] fdFwd is an optional reference to the source of a Feedforward object.
[0507] fdFwd.ff is a reference to the source of a FloatVariable.
[0508] fdFwd.gain is a FloatParameter gain applied to fdFwd.ff
[0509] ramp is an optional reference to the source of a Ramp object.
[0510] ramp.rateDn is a positive FloatParameter specifying the rate down.
[0511] ramp.rateUp is a positive FloatParameter specifying the rate up.
[0512] ramp.target is a FloatParameter that contains the termination value.
[0513] ramp.trigger is a BoolParameter that starts the ramp.
[0514] limit is an optional reference to the source of a setpoint Limit object.
[0515] limit.hi is the high limit, FloatParameter
[0516] limit.lo is the low limit, FloatParameter
[0517] alarmDevi is an optional reference to the source of a deviation Alarm object.
[0518] alarmDev.hi is the high alarm limit a FloatParameter.
[0519] alarmDev.lo is the low alarm limit, a FloatParameter.
[0520] alarmDev.hys is the alarm hysteresis, a FloatParameter.
[0521] alarmDev.delay is an optional alarm delay in seconds, a FloatParameter
[0522] alarmDev.noAck is a boolean, alarm requires no acknowledge if true.
[0523] sp is a FloatVariable representing the current setpoint. In the LOCAL mode sp can be set
[0524] deviation is a FloatVariable output representing in—sp. It can be alarmed.
[0525] Attributes from Super Class
[0526] in is a reference to a FloatVariable source. inforw.value is in eng. units.
[0527] charac is a reference to an optional signal Characterizer.
[0528] charac.xPt[i] and charac.yPt[i] are breakpoint coordinates, float values.
[0529] filter is a reference to an optional signal Filter.
[0530] options is a packed boolean byte with bits assigned as:
[0531] SP_PV_TRK_MAN Setpoint tracks PV when output is manually set.
[0532] SP_DN_UNCER Setpoint is decreased by the uncertainty.
[0533] SP_UP_UNCER Setpoint is increased by the uncertainty.
[0534] MULT_FF Feedforward is multiplicative, else it is additive.
[0535] device is the String name of an i/o device that is the source of in.
[0536] point is an integer used to identify an i/o address within the device.
[0537] pv is a Float Variable output representing the processed in value.
[0538] Methods for Developer
[0539] CascFloatInput (constructor)
[0540] Arguments: none.
[0541] Instantiates sp and deviation.
[0542] Returns: none.
[0543] startup
[0544] Arguments: none.
[0545] Called when out-of-service.
[0546] Returns: true if ready to run.
[0547] inHandle
[0548] Arguments: none.
[0549] Sets back values and status, processes in and feedforward.
[0550] Returns: none.
[0551] locRemTarget
[0552] Arguments: none.
[0553] Determines the internal target mode.
[0554] Returns: none.
[0555] devHandl
[0556] Arguments: period is the time since the last update in seconds, a double.
[0557] Handles setpoint and deviation.
[0558] Returns: none
[0559] initialize
[0560] Arguments: none.
[0561] Provides bumpless mode transitions
[0562] Returns: none.
[0563] modeHandle
[0564] Arguments: none.
[0565] Provides functionality for active mode.
[0566] Returns: none.
[0567] limitStatus
[0568] Arguments: lim holds limit bits to be propagated upstream, an integer.
[0569] Propagates limit bits to back.status.
[0570] Returns: none.
[0571] UniDirFloatOutput
[0572] Overview
[0573] UniDirFloatOutput is an output interface part that provides auto/manual/supervisory switching, optional out limiting, optional out alarming, and an optional multiplicative or additive feedforward input.
[0574] Its methods are called by its container block.
[0575] startup( ) Called when out-of-service, returns true if ready to run.
[0576] manAutoTarget( ) Determines the internal target mode.
[0577] modehandle(period) Provides functionality for active mode.
[0578] Attributes
[0579] fdFwd is an optional reference to the source of a Feedforward object.
[0580] fdFwd.ff is a reference to the source of a FloatVariable.
[0581] wd.gain is a FloatParameter gain applied tofdFwd.ff.
[0582] supvOut is an optional reference to the source of the supervisory output, a FloatVariable.
[0583] mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[0584] O_S Block is out of service
[0585] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[0586] MANUAL Operator or set method can set out.
[0587] AUTO Block algorithm sets out.
[0588] SUPER Supervisory task (supvSP) sets setpoint.
[0589] LINKED Permitted attribute indicates target connected to external source.
[0590] INTERLOCK interlock.in sets out when interlock.trigger is true.
[0591] options is a packed boolean byte with bits assigned as:
[0592] LIM_MAN Limits are applied to manual output.
[0593] ALM_MAN Alarming is applied to a manual output.
[0594] MAN_START Block returns from out-of-service in MANUAL mode.
[0595] MULT_FF Feedforward is multiplicative, else it is additive.
[0596] ALARM_BLURRED Block alarm triggered by BLURRED signal status.
[0597] I_O out is provided to device and point.
[0598] limit is an optional reference to the source of an out Limit object.
[0599] limit.hi is the high limit, FloatParameter
[0600] limit.lo is the low limit, FloatParameter
[0601] alarmHi is an optional reference to the source of an out Alarm object.
[0602] alarmHi.hi is the high alarm limit, a FloatParameter.
[0603] alarmHi.lo is the low alarm limit, a FloatParameter.
[0604] alarmHi.hys is the alarm hysteresis, a FloatParameter.
[0605] alarmHi.delay is an optional alarm delay in seconds, a FloatParameter
[0606] alarmHi.noAck is a boolean, alarm requires no acknowledge if true.
[0607] alarmHiHi is an optional reference to the source of an out Alarm object.
[0608] alarmHiHi.hi is the high alarm limit, a FloatParameter.
[0609] alarmHiHi.lo is the low alarm limit, a FloatParameter.
[0610] alarmHiHi.hys is the alarm hysteresis, a FloatParameter.
[0611] alarmHiHi.delay is an optional alarm delay in seconds, a FloatParameter
[0612] alarmHiHi.noAck is a boolean, alarm requires no acknowledge if true.
[0613] interlock is an optional object used to invoke an override of the current Mode.
[0614] interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode.
[0615] interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false.
[0616] interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.
[0617] device is the String name of an i/o device that is the sink of out.
[0618] point is an integer used to identify an i/o address within the device.
[0619] out is a FloatVariable representing the current output. In the MANUAL mode out can be set
[0620] fbk is the integral feedback input, a FloatParameter, which is connected by default to out.back if it is connected externally, otherwise to out.forw.
[0621] Methods for Developer
[0622] UniDirFloatOutput (constructor)
[0623] Arguments: none.
[0624] Instantiates out.
[0625] Returns: none.
[0626] startup
[0627] Arguments: none.
[0628] Attributes from Super Class
[0629] FdFwd is an optional reference to the source of a Feedforward object.
[0630] fdFwd.ff is a reference to the source of a FloatVariable.
[0631] fdFwd.gain is a FloatParameter gain applied to fdFwd.ff.
[0632] supvOut is an optional reference to the source of the supervisory output, a FloatVariable.
[0633] mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[0634] O_S Block is out of service
[0635] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[0636] MANUAL Operator or set method can set out.
[0637] AUTO Block algorithm sets out.
[0638] SUPER Supervisory task (supvSP) sets setpoint.
[0639] LINKED Permitted attribute indicates target connected to external source.
[0640] INTERLOCK interlock.in sets out when interlock.trigger is true.
[0641] options is a packed boolean byte with bits assigned as:
[0642] LIM_MAN Limits are applied to manual output
[0643] ALM_MAN Alarming is applied to a manual output.
[0644] MAN_START Block returns from out-of-service in MANUAL mode.
[0645] MULT_FF Feedforward is multiplicative, else it is additive.
[0646] ALARM_BLURRED Block alarm triggered by BLURRED signal status.
[0647] limit is a reference to the source of an out Limit object.
[0648] limit.hi is the high limit, FloatParameter
[0649] limit.lo is the low limit, FloatParameter
[0650] alarmHi is an optional reference to the source of an out Alarm object.
[0651] alarmHiHi is an optional reference to the source of an out Alarm object.
[0652] alarmHiHi.hi is the high alarm limit, a FloatParameter.
[0653] alarmHiHi.lo is the low alarm limit, a FloatParameter.
[0654] alarmHiHi.hys is the alarm hysteresis, a FloatParameter.
[0655] alarmHiHi.delay is an optional alarm delay in seconds, a FloatParameter
[0656] alarmHiHi.noAck is a boolean, alarm requires no acknowledge if true.
[0657] interlock is an optional object used to invoke an override of the current Mode.
[0658] interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode.
[0659] interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false.
[0660] interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.
[0661] device is the String name of an i/o device that is the sink of out.
[0662] point is an integer used to identify an i/o address within the device.
[0663] out is a FloatVariable representing the current output. In the MANUAL mode out can be set
[0664] Methods for Developer
[0665] CascFloatOutput (constructor)
[0666] Arguments: none.
[0667] Instantiates out and limit.
[0668] Returns: none.
[0669] manAutoTarget
[0670] Arguments: none.
[0671] Determines the internal target mode
[0672] Returns: none.
[0673] bkCalc
[0674] Arguments: none.
[0675] Compensates integral feedback for feedforwards.
[0676] Returns: none.
[0677] initialize
[0678] Arguments: none.
[0679] Provides bumpless mode transitions.
[0680] Returns: none.
[0681] Methods from Super Class
[0682] startup
[0683] Arguments: none.
[0684] Called when out-of-service, returns true if ready to run.
[0685] Returns: none.
[0686] modeHandle
[0687] Arguments: period is the time since the last update in seconds, a double.
[0688] Provides functionality for active mode.
[0689] Returns: none.
[0690] Alarm
[0691] Overview
[0692] Alarm is an optional part for all outputs. Its float method is func(x,type,period) where type is true for HH and LL, false for HI and LO. Its boolean method is func(x,period). Alarm reporting can be delayed if the optional delay parameter is not null or inhibited if inhib is true.
[0693] Attributes
[0694] hi is the high alarm limit, a FloatParameter.
[0695] lo is the low alarm limit, a FloatParameter.
[0696] hys is the alarm hysteresis, a FloatParameter.
[0697] lim is the boolean alarm state, a BoolParameter.
[0698] lim is an optional output, true if alarm is active, a BoolParameter.
[0699] delay is an optional alarm delay in seconds, a FloatParameter.
[0700] noAck is a boolean, alarm requires no acknowledge if true.
[0701] inhib is a boolean, inhibits alarm if true.
[0702] Methods for Developer
[0703] Alarm (constructor)
[0704] Arguments: none, signifying a float alarm.
[0705] Returns: none.
[0706] Alarm (constructor)
[0707] Arguments: r is a FloatRange.object used to set the alarm limits.
[0708] Returns: none.
[0709] Alarm (constructor)
[0710] Arguments: b is a boolean signifying a boolean alarm.
[0711] Returns: none.
[0712] func
[0713] Arguments: x is the alarmed BoolVariable.
[0714] period is the time since the last update in seconds, a double blurAl
[0715] Returns: none.
[0716] func
[0717] Arguments: x is the alarmed BoolVariable.
[0718] period is the time since the last update in seconds, a double blurAl
[0719] Returns: none.
[0720] Characterizer
[0721] Overview
[0722] Characterizer is an optional part class used in the CascFloatInput part, UniDirFloatInput part, LinearFlow part, and ProcessSim block classes. Its method is y=func(x). The number of breakpoints is specified as the constructor argument.
[0723] Attributes
[0724] xPt[i] and yPt[i] are breakpoint coordinates, float values.
[0725] Methods for Developer
[0726] Characterizer (constructor)
[0727] Arguments: nPt is an int number of (xPt, yPt) break points.
[0728] Returns: none.
[0729] Func
[0730] Arguments: u. is the input to the function, a double (x if forw is true).
[0731] Forw is true if u=x, v=y, else u=y, v=x.
[0732] Returns: v is the output of the function, a double (y if forw is true)
[0733] FeedForward
[0734] Overview
[0735] Feedforward is an optional part class used in CascFloatInput, CascFloatOutput, and UniDirFloatOutput classes. It provides multiplicative or additive compensation for the input. Its methods are f=forwFunc(f, mult, out) and b=backFunc(b,mult), where mult and out are booleans indicating if true that the compensation is multiplicative and applied to output respectively.
[0736] Attributes
[0737] ff is a reference to the source of a FloatVariable.
[0738] Gain is a FloatParameter gain applied to ff
[0739] Methods for Developer
[0740] Feedforward (constructor)
[0741] Arguments: none.
[0742] Returns: none.
[0743] ForwFunc
[0744] Arguments: sig is the internal pre feedforward out.forw.value, a double.
[0745] mult is true if feedforward is multiplicative.
[0746] out is true if the feedforward is an output part. Then a multiplicative feedforward is normalized with its high-range value.
[0747] Returns: the prelimited out forw.value, a double.
[0748] backFunc
[0749] Arguments: sig=fbk.value, a double.
[0750] mult is true if feedforward is multiplicative.
[0751] Returns: the back-calculated internal fbk, a double.
[0752] Filter
[0753] Overview
[0754] Filter is a part class used in the CascFloatInput part, UniDirFloatInput part, and ProcessSim block classes. Its method is y=func(x,period). It is initialized with init(X).
[0755] Attributes
[0756] FTime is the filter time in seconds, a FloatParameter.
[0757] lead is the lead time in seconds, a FloatParameter.
[0758] fType specifies the filter denomiator type, a FloatParameter. ½ Butterworth, ⅓ Averaging, ¼ Two-Lag, 0 One-Lag
[0759] y is the low-pass filtered output, a double.
[0760] v is the band-pass filtered output, a double.
[0761] Methods for Developer
[0762] Filter (constructor)
[0763] Arguments: none.
[0764] Instantiates fTime to 0., fType to 0.5, and lead to 0.
[0765] Returns: none.
[0766] init
[0767] Arguments: x is the filter input, a double
[0768] Initializes the filter output to equal its input.
[0769] Returns: none.
[0770] func
[0771] Arguments: x is the filter input, a double.
[0772] period is the time since the last update in seconds, a double
[0773] Returns: the filter output, a double.
[0774] Limit
[0775] Overview
[0776] Limit is a part class applied to the setpoint in the CascFloatInput, and to the out of a CascFloatOutput, and UniDirFloatOutput classes. Its method is x=func(x). The high limit cannot be less than the low limit. Neither limit may be more than 2% beyond the range limits.
[0777] Attributes
[0778] hi is a reference to a FloatVariable containing the high limit.
[0779] lo is a reference to a FloatVariable containing the low limit.
[0780] Methods for Developer
[0781] Limit (constructor)
[0782] Arguments: none.
[0783] Instantiates hi and lo.
[0784] Returns: none.
[0785] func
[0786] Arguments: x is the FloatVariable to be limited.
[0787] Returns: none.
[0788] Ramp
[0789] Overview
[0790] Ramp is an optional part class applied to the local setpoint in the CascFloatInput class. It provides a triggered ramp function with the method y=func(x,period).
[0791] Attributes
[0792] rateDn is a positive FloatParameter specifying the rate down.
[0793] rateUp is a positive FloatParameter specifying the rate up.
[0794] target is a FloatParameter that contains the termination value.
[0795] trigger is a BoolParameter that starts the ramp.
[0796] Methods for Developer
[0797] Ramp(constructor)(boolean link)
[0798] Arguments: none.
[0799] Returns: none.
[0800] Ramp(constructor)
[0801] Arguments: none.
[0802] Returns: none.
[0803] func
[0804] Arguments: spt is the input to the ramp, a double.
[0805] period is the time since the last update in seconds, a double.
[0806] Returns: the ramp result, a double.
[0807] UniDirBoolInput
[0808] Overview
[0809] UniDirBoolInput is a measurement path input interface part that initializes to its in signal.
[0810] Attributes
[0811] in is a reference to a BoolVariable source.
[0812] filter is a reference to an optional signal Filter.
[0813] options is a packed boolean byte with:
[0814] I_O in is provided from device and point
[0815] device is the String name of an I/O device that is the source of in.
[0816] point is an integer used to identify an I/O address within the device.
[0817] pv is a BoolVariable output representing the processed in value.
[0818] Methods for Developer
[0819] UniDirFloatInput (constructor)
[0820] Arguments: none.
[0821] Returns: none.
[0822] startup
[0823] Arguments: none
[0824] Returns: true if ready to run.
[0825] CascBoolInput
[0826] Overview
[0827] CascBoolInput is an input interface part that provides initialization and local/remote/supervisory switching.
[0828] Its internal methods are called by its container block.
[0829] startup( ) Called when out-of-service, returns true if ready to run.
[0830] inHandle( ) Sets back values and status, processes in.
[0831] locRemTarget( ) Determines the internal target mode.
[0832] devHandle(period) Handles setpoint and deviation.
[0833] initialize( ) Provides bumpless mode transitions.
[0834] modeHandle( ) Provides functionality for active mode.
[0835] Attributes
[0836] remSP is an optional reference to the source of the remote setpoint BoolVariable.
[0837] supvSP is an optional reference to the source of the supervisory setpoint, a BoolVariable.
[0838] lrs is the setpoint local/remote/supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[0839] O_S Block is out of service
[0840] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[0841] LOCAL Operator or set method can set sp.
[0842] REMOTE External block (remSP) sets setpoint.
[0843] SUPER Supervisory task (supvSP) sets setpoint.
[0844] LINKED Permitted attribute indicates target connected to external source.
[0845] sp is a BoolVariable representing the current setpoint. In the LOCAL mode sp can be set
[0846] filter is a reference to an optional signal BoolFilter.
[0847] options is a packed boolean byte with bits assigned as:
[0848] pv is a IntVariable output representing the processed in value.
[0849] Methods for Developer
[0850] CascBoolInput(constructor)
[0851] Arguments: none.
[0852] Returns: none.
[0853] startup
[0854] Arguments: none.
[0855] Called when out-of-service.
[0856] Returns: true if ready to run.
[0857] inHandle
[0858] Arguments: none.
[0859] Sets back values and status.
[0860] Returns: none.
[0861] locRemTarget
[0862] Arguments: none.
[0863] Determines the internal target mode.
[0864] Returns: none.
[0865] devHandl
[0866] Arguments: none.
[0867] Handles setpoint.
[0868] Returns: none
[0869] initialize
[0870] Arguments: none.
[0871] Provides bumpless mode transitions
[0872] Returns: none.
[0873] modeHandle
[0874] Arguments: none.
[0875] Provides functionality for active mode.
[0876] Returns: none.
[0877] UniDirBoolOutput
[0878] Overview
[0879] UniDirBoolOutput is an output interface part that provides auto/manual/supervisory switching.
[0880] Its methods are called by its container block.
[0881] startup( ) Called when out-of-service, returns true if ready to run.
[0882] manAutoTarget( ) Determines the internal target mode.
[0883] modehandle(period) Provides functionality for active mode.
[0884] Attributes
[0885] supvOut is an optional reference to the source of the supervisory output, a BoolVariable.
[0886] mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[0887] O_S Block is out of service
[0888] INITLALIZE Transition actual mode enables bumpless transfer to target mode
[0889] MANUAL Operator or set method can set out.
[0890] AUTO Block algorithm sets out.
[0891] SUPER Supervisory task (supvSP) sets setpoint.
[0892] LINKED Permitted attribute indicates target connected to external source.
[0893] INTERLOCK interlock.in sets out when interlock trigger is true.
[0894] options is a packed boolean byte with bits assigned as: ALARM_BLURRED Block alarm triggered by BLURRED signal status.
[0895] I_O out is provided to device and point.
[0896] alarm is an optional reference to the source of an out Alarm object.
[0897] alarmHi.hi is the high alarm limit, a FloatParameter.
[0898] alarmHi.lo is the low alarm limit, a FloatParameter.
[0899] alarmhi.hys is the alarm hysteresis, a FloatParameter.
[0900] alarmHi.delay is an optional alarm delay in seconds, a
[0901] FloatParameter
[0902] alarmHi.noAck is a boolean, alarm requires no acknowledge if true.
[0903] interlock is an optional object used to invoke an override of the current Mode.
[0904] interlock trigger is a BoolParameter used to invoke INTERLOCK Mode.
[0905] interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false. interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.
[0906] device is the String name of an I/O device that is the sink of out.
[0907] point is an integer used to identify an I/O address within the device.
[0908] out is a BoolVariable representing the current output. In the MANUAL mode out can be set.
[0909] Methods for Developer
[0910] UniDirBoolOutput (constructor)
[0911] Arguments: none.
[0912] Instantiates out.
[0913] Returns: none.
[0914] startup
[0915] Arguments: none.
[0916] Called when out-of-service, returns true if ready to run.
[0917] Returns: none.
[0918] manAutoTarget
[0919] Arguments: none.
[0920] Determines the internal target mode
[0921] Returns: none.
[0922] modehandle
[0923] Arguments: period is the time since the last update in seconds, a double.
[0924] Provides functionality for active mode.
[0925] Returns: none.
[0926] CascBoolOutput
[0927] Overview
[0928] CascBoolOutput is an output interface part that provides initialization, auto/manual/supervisory switching.
[0929] Its methods are called by its container block.
[0930] startup( ) Called when out-of-service, returns true if ready to run.
[0931] manAutoTarget( ) Determines the internal target mode.
[0932] bkCalc( ) Set the backword values.
[0933] initialize( ) Provides bumpless mode transitions.
[0934] modeHandle(period) Provides functionality for active mode.
[0935] Attributes
[0936] out0 is a BoolVariable representing the first output. In the MANUAL mode out0 can be set.
[0937] out1 is a BoolVariable representing the second output. In the MANUAL mode out1 can be set.
[0938] point0 is an integer used to identify the I/O address of out0.
[0939] point1 is an integer used to identify the I/O address of out1.
[0940] Attributes from Super Class
[0941] supvOut is an optional reference to the source of the supervisory output, a BoolVariable.
[0942] mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[0943] O_S Block is out of service
[0944] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[0945] MANUAL Operator or set method can set out.
[0946] AUTO Block algorithm sets out.
[0947] SUPER Supervisory task (supvSP) sets setpoint.
[0948] LINKED Permitted attribute indicates target connected to external source.
[0949] INTERLOCK interlock.in sets out when interlock.trigger is true.
[0950] alarm is an optional reference to the source of an out Alarm object.
[0951] alarmHi.hi is the high alarm limit, a FloatParameter.
[0952] alarmHi.lo is the low alarm limit, a FloatParameter.
[0953] alarmHi.hys is the alarm hysteresis, a FloatParameter.
[0954] alarmHi.delay is an optional alarm delay in seconds, a FloatParameter
[0955] alarmHi.noAck is a boolean, alarm requires no acknowledge if true.
[0956] interlock is an optional object used to invoke an override of the current Mode.
[0957] interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode. interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false. interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.
[0958] device is the Sting name of an I/O device that is the sink of out.
[0959] point is an integer used to identify an I/O address within the device.
[0960] out is a BoolVariable. It is assigned to out0, the first output.
[0961] Methods for Developer
[0962] CascBoolOutput (constructor)
[0963] Arguments: none.
[0964] Instantiates out0 and out1.
[0965] Returns: none.
[0966] manAutoTarget
[0967] Arguments: none.
[0968] Determines the internal target mode
[0969] Returns: none.
[0970] bkCalc
[0971] Arguments: none.
[0972] Set the backword values for out0 and out1.
[0973] Returns: none.
[0974] initialize
[0975] Arguments: none.
[0976] Provides bumpless mode transitions.
[0977] Returns: none.
[0978] Methods from Super Class
[0979] startup
[0980] Arguments: none.
[0981] Called when out-of-service, returns true if ready to run.
[0982] Returns: none.
[0983] modeHandle
[0984] Arguments: period is the time since the last update in seconds, a double.
[0985] Provides functionality for active mode.
[0986] Returns: none.
[0987] BoolFilter
[0988] Overview
[0989] BoolFilter is a part class used in classes such as DeviceControl and Logic. Its method is y=func(x, period). It is initialized with init( ) to y=0 each time the input changes state.
[0990] Attributes
[0991] fTime is the filter time in seconds, a FloatParameter.
[0992] Methods for Developer
[0993] BoolFilter(constructor)
[0994] Arguments: none.
[0995] Returns: none.
[0996] init
[0997] Arguments: x is the filter input, a double
[0998] Initializes the filter output to its input.
[0999] Returns: none.
[1000] func
[1001] Arguments: x is the filter input, a double.
[1002] period is the time since the last update in seconds, a double
[1003] Returns: the filter output, a boolean.
[1004] UniDirIntInput
[1005] Overview
[1006] UniDirIntInput is a measurement path input interface part that initializes to its in signal.
[1007] Attributes
[1008] in is a reference to a IntVariable source.
[1009] filter is a reference to an optional signal IntFilter.
[1010] options is a packed boolean byte with:
[1011] I_O in is provided from device and point
[1012] device is the String name of an I/O device that is the source of in.
[1013] point is an integer used to identify an I/O address within the device.
[1014] pv is a IntVariable output representing the processed in value.
[1015] Methods for Developer
[1016] UniDirIntInput (constructor)
[1017] Arguments: none.
[1018] Returns: none.
[1019] startup
[1020] Arguments: none
[1021] Returns: true if ready to run.
[1022] CascIntInput
[1023] Overview
[1024] CascIntInput is an input interface part that provides initialization and local/remote/supervisory switching.
[1025] Its internal methods are called by its container block.
[1026] startup( ) Called when out-of-service, returns true if ready to run.
[1027] inHandle( ) Sets back values and status, processes in.
[1028] locRemTarget( ) Determines the internal target mode.
[1029] devHandle(period) Handles setpoint and deviation.
[1030] initialize( ) Provides bumpless mode transitions.
[1031] modeHandle( ) Provides functionality for active mode.
[1032] Attributes
[1033] remSP is an optional reference to the source of the remote setpoint IntVariable.
[1034] supvSP is an optional reference to the source of the supervisory setpoint, a IntVariable.
[1035] Irs is the setpoint local/remote/supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[1036] O_S Block is out of service
[1037] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[1038] LOCAL Operator or set method can set sp.
[1039] REMOTE External block (remSP) sets setpoint.
[1040] SUPER Supervisory task (supvSP) sets setpoint.
[1041] LINKED Permitted attribute indicates target connected to external source.
[1042] sp is a IntVariable representing the current setpoint. In the LOCAL mode sp can be set
[1043] pv is a IntVariable output representing the processed in value.
[1044] Methods for Developer
[1045] CascBoolInput(constructor)
[1046] Arguments: none.
[1047] Returns: none.
[1048] startup
[1049] Arguments: none.
[1050] Called when out-of-service.
[1051] Returns: true if ready to run.
[1052] inHandle
[1053] Arguments: none.
[1054] Sets back values and status.
[1055] Returns: none.
[1056] locRemTarget
[1057] Arguments: none.
[1058] Determines the internal target mode.
[1059] Returns: none.
[1060] devHandl
[1061] Arguments: none.
[1062] Handles setpoint.
[1063] Returns: none
[1064] initialize
[1065] Arguments: none.
[1066] Provides bumpless mode transitions
[1067] Returns: none.
[1068] modeHandle
[1069] Arguments: none.
[1070] Provides functionality for active mode.
[1071] Returns: none.
[1072] UniDirIntOutput
[1073] Overview
[1074] UniDirIntOutput is an output interface part that provides auto/manual/supervisory switching.
[1075] Its methods are called by its container block.
[1076] startup( ) Called when out-of-service, returns true if ready to run.
[1077] manAutoTarget( ) Determines the internal target mode.
[1078] modeHandle(period) Provides functionality for active mode.
[1079] Attributes
[1080] supvOut is an optional reference to the source of the supervisory output, a IntVariable.
[1081] mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[1082] O_S Block is out of service
[1083] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[1084] MANUAL Operator or set method can set out.
[1085] AUTO Block algorithm sets out.
[1086] SUPER Supervisory task (supvSP) sets setpoint.
[1087] LINKED Permitted attribute indicates target connected to external source.
[1088] INTERLOCK interlock.in sets out when interlock.trigger is true.
[1089] options is a packed boolean byte with bits assigned as:
[1090] MAN_START Block returns from out-of-service in MANUAL mode.
[1091] ALARM_BLURRED Block alarm triggered by BLURRED signal status.
[1092] I_O out is provided to device and point.
[1093] alarm is an optional reference to the source of an out Alarm object.
[1094] alarmHi.hi is the high alarm limit, a FloatParameter.
[1095] alarmHi.lo is the low alarm limit, a FloatParameter.
[1096] alarmHi.hys is the alarm hysteresis, a FloatParameter.
[1097] alarmHi.delay is an optional alarm delay in seconds, a FloatParameter
[1098] alarmHi.noAck is a boolean, alarm requires no acknowledge if true.
[1099] interlock is an optional object used to invoke an override of the current Mode.
[1100] interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode. interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false. interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.
[1101] device is the String name of an I/O device that is the sink of out.
[1102] point is an integer used to identify an i/o address within the device.
[1103] out is a IntVariable representing the current output. In the MANUAL mode out can be set.
[1104] Methods for Developer
[1105] UniDirBoolOutput (constructor)
[1106] Arguments: none.
[1107] Instantiates out.
[1108] Returns: none.
[1109] startup
[1110] Arguments: none.
[1111] Called when out-of-service, returns true if ready to run.
[1112] Returns: none.
[1113] manAutoTarget
[1114] Arguments: none.
[1115] Determines the internal target mode
[1116] Returns: none.
[1117] modeHandle
[1118] Arguments: period is the time since the last update in seconds, a double.
[1119] Provides functionality for active mode.
[1120] Returns: none.
[1121] CascIntOutput
[1122] Overview
[1123] CascIntOutput is an output interface part that provides initialization and auto/manual/supervisory switching.
[1124] Its methods are called by its container block.
[1125] startup( ) Called when out-of-service, returns true if ready to run.
[1126] manAutoTarget( ) Determines the internal target mode.
[1127] bkCalc( ) Set the backword values.
[1128] initialize( ) Provides bumpless mode transitions.
[1129] modeHandle(period) Provides functionality for active mode.
[1130] Attributes
[1131] point is an integer used to identify address of out.
[1132] Attributes from Super Class
[1133] supvOut is an optional reference to the source of the supervisory output, a IntVariable.
[1134] mas is the output manual-auto-supervisory Mode having target, actual, permitted, and last packed boolean bytes whose bits are:
[1135] O_S Block is out of service
[1136] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[1137] MANUAL Operator or set method can set out.
[1138] AUTO Block algorithm sets out.
[1139] SUPER Supervisory task (supvSP) sets setpoint.
[1140] LINKED Permitted attribute indicates target connected to external source.
[1141] INTERLOCK.interlock in sets out when interlock.trigger is true.
[1142] alarm is an optional reference to the source of an out Alarm object.
[1143] alarmDev.hi is the high alarm limit, a FloatParameter.
[1144] alarmDev.lo is the low alarm limit, a FloatParameter.
[1145] alarmDev.hys is the alarm hysteresis, a FloatParameter.
[1146] alarmDev.delay is an optional alarm delay in seconds, a FloatParameter
[1147] alarmDev.noAck is a boolean, alarm requires no acknowledge if true.
[1148] interlock is an optional object used to invoke an override of the current Mode.
[1149] interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode. interlock.reset is a BoolParameter used to return to normal Mode, provided interlock.trigger is false. interlock.in is a FloatParameter that sets out in the INTERLOCK Mode.
[1150] device is the String name of an I/O device that is the sink of out.
[1151] point is an integer used to identify an I/O address within the device.
[1152] out is a IntVariable representing the current output. In the MANUAL mode out can be set.
[1153] Methods for Developer
[1154] CascBoolOutput (constructor)
[1155] Arguments: none.
[1156] Instantiates out.
[1157] Returns: none.
[1158] manAutoTarget
[1159] Arguments: none.
[1160] Determines the internal target mode
[1161] Returns: none.
[1162] bkCalc
[1163] Arguments: none.
[1164] Set the backword values for out.
[1165] Returns: none.
[1166] initialize
[1167] Arguments: none.
[1168] Provides bumpless mode transitions.
[1169] Returns: none.
[1170] Methods from Super Class
[1171] startup
[1172] Arguments: none.
[1173] Called when out-of-service, returns true if ready to run.
[1174] Returns: none.
[1175] modeHandle
[1176] Arguments: period is the time since the last update in seconds, a double.
[1177] Provides functionality for active mode.
[1178] Returns: none.
[1179] IntFilter
[1180] Overview
[1181] IntFilter is a part class used in the DiscreteInput class. Its method is y=func(x,period). It is initialized with init(to y=1 each time the input changes state.
[1182] Attributes
[1183] fTime is the filter time in seconds, a FloatParameter.
[1184] Methods for Developer
[1185] BoolFilter(constructor)
[1186] Arguments: none.
[1187] Returns: none.
[1188] init
[1189] Arguments: x is the filter input, a double
[1190] Initializes the filter output to equal its input.
[1191] Returns: none.
[1192] func
[1193] Arguments: x is the filter input, a double.
[1194] period is the time since the last update in seconds, a double
[1195] Returns: the filter output, a boolean.
[1196] PIDParameters
[1197] Overview
[1198] PIDParameters is an optional part class containing tuning parameters used in the AdvancedPID class.
[1199] Attributes
[1200] PGain is the nondimensional prpoortional gain, a FloatParameter.
[1201] integral is the integral time in seconds, a FloatParameter.
[1202] derivative is the derivative time in seconds, a FloatParameter.
[1203] relGain is the nondimensional relative gain on setpoint, a FloatParameter.
[1204] dtime is the optional deadtime in seconds, a FloatParameter
[1205] ftime is the measurement filter time in seconds, a FloatParameter.
[1206] bypass is an optional BoolParameter, if true the controller is bypassed.
[1207] zone is an optional object from the Zone class, used to position a region of low gain where the control error is small.
[1208] sampleReady is a BoolParameter indicating that a new measurement value is available. Its default value is true.
[1209] options is a packed-boolean byte with the following assignments:
| IFS_IF_BAD_RSP | initiates failsafe if remoteSP is BLIND | |
| IFS_IF_BAD_IN | initiates failsafe if in is BLIND | |
| INCOPT | increasing in causes out to increase. | |
| PD | no controller integral action. | |
| I_ONLY | only controller integral action. | |
| PASS_RANGE | the range is passed to the setpoint. | |
[1210] Methods for Developer
[1211] PIDParameters (constructor)
[1212] Arguments: none.
[1213] Instantiates pGain, integral, derivative, and relGain.
[1214] Returns: none.
[1215] Deadtime
[1216] Overview
[1217] Deadtime is a part class used in the AdvancedPID and ProcessSim classes. Its method y=func(x,period) implements a bucket-brigade delay line. The number of buckets is specified as the constructor argument.
[1218] Attributes
[1219] dt is the deadtime in seconds, a FloatParameter.
[1220] Methods for Developer
[1221] Deadtime( ) (constructor)
[1222] Arguments: none.
[1223] Instantiates dt, uses 10 buckets.
[1224] Returns: none.
[1225] Deadtime (constructor)
[1226] Arguments: numBuckets is the number of buckets, an int.
[1227] Instantiates dt.
[1228] Returns: none.
[1229] hold
[1230] Arguments: none
[1231] Returns: none.
[1232] init
[1233] Arguments: x
[1234] Initializes the delayed signal to equal input x.
[1235] Returns: none.
[1236] func
[1237] Arguments: x
[1238] period is the time since the last update in seconds, a double.
[1239] Returns: the value of the delayed signal, a double.
[1240] Zone
[1241] Overview
[1242] Zone is a part class used in the AdvancedPID class. It is a three segment characterizer used as a nonlinear noise filter and in pH control. Its method is y=func(x).
[1243] Attributes
[1244] hi is the upper control error breakpoint in percent of in span, a FloatParameter.
[1245] lo is the lower control error breakpoint in percent of in span, a FloatParameter.
[1246] Methods for Developer
[1247] Zone (constructor)
[1248] Arguments: none.
[1249] Instantiates hi, lo, and k.
[1250] Returns: none.
[1251] func
[1252] Arguments: x is the input signal, a double.
[1253] Returns: the Zone output signal, a double.
[1254] FailSafe
[1255] Overview
[1256] FailSafe is a part class used by AnalogOutput and Logic classes.
[1257] Attributes
[1258] fsTime fsTimeis a FloatParameter wait time in seconds before failsafe is activated.
[1259] var var is the FloatParameter that sets the valve target when failsafe is active.
[1260] bool is the value of a BoolParameter that sets out when failsafe is active.
[1261] Methods for Developer
[1262] Failsafe (constructor)
[1263] Arguments: none.
[1264] Returns: none.
[1265] LinearFlow
[1266] Overview
[1267] LinearFlow is an optional part used to cause the out Variable of an AnalogOutput block to be a valve position target that will make valve flow linear with the AnalogOutput setpoint. Its methods
[1268] are x=forw(v) and v=back(x). The parameter 0<=beta<=1 is defined as:
[1269] Valve pressures at max opening: p1, p2
[1270] Supply pressures: ps, pa
[1271] 0<=v<=1 is normalized flow
[1272] 0<=y<=1 is normalized valve flow area
[1273] 0<=x<=1 is normalized valve stem position.
[1274] Maximum liquid power is delivered to the load when beta is ⅓ and v=1.
[1275] Then the ratio of max-to-min slopes dv/dy is 5.2. The pressure drop correction is:
[1276] x=func(y,true)
[1277] Attributes
[1278] beta is the pressure drop ratio, a FloatParameter.
[1279] turndown is (max flow area)/(min flow area) for an equql-percentage valve, an optional FloatParameter.
[1280] charac is an optional object of the Characterizer class providing normalized stroke vs. normalized area in the forward direction.
[1281] Methods for Developer
[1282] LinearFlow (constructor)
[1283] Arguments: none.
[1284] Returns: none.
[1285] forw
[1286] Arguments: the normalized target flow, a double.
[1287] Returns: the normalized target valve position, a double.
[1288] back
[1289] Arguments: the normalized actual valve position, a double.
[1290] Returns: the normalized back-calculated flow, a double.
[1291] InfoBuffer
[1292] Overview
[1293] InfoBuffer is a part class used by the InfoCollect class. Its method func implements double buffering with a bucket-brigade delay line for each parameter stored. The number of buckets (time steps) is specified as a constructor argument.
[1294] Attributes
[1295] xTime[buf][step] is an array of time stamp in milliseconds since Jan. 1, 1970, a long.
[1296] xFloat[buf][step][nFP] is an optional array of FloatParameter value floats.
[1297] xFStatus[buf][step][nBP] is an optional array of FloatParameter status bytes.
[1298] xBool[buf][step][nBP] is an optional array of BoolParameter values.
[1299] xBStatus[buf][step][nBP] is an optional array of BoolParameter status bytes.
[1300] xMode[buf][step][nM] is an optional array of Mode actual bytes.
[1301] xAlarm[buf][step][nAl] is an optional array of AlarmSum shorts.
[1302] Methods for Developer
[1303] InfoBuffer(constructor)
[1304] Arguments: x is the time stamp, a long.
[1305] NumSteps is the length of the buffer, an int.
[1306] Returns: none.
[1307] InfoBuffer(constructor)
[1308] Arguments: x is an array of FloatParameters.
[1309] nP is the number of FloatParameters
[1310] NumSteps is the length of the buffer, an int.
[1311] Returns: none.
[1312] InfoBuffer(constructor)
[1313] Arguments: x is an array of BoolParameters.
[1314] nP is the number of BoolParameters
[1315] NumSteps is the length of the buffer, an int.
[1316] Returns: none.
[1317] InfoBuffer(constructor)
[1318] Arguments: x is an array of Modes.
[1319] nP is the number of Modes.
[1320] NumSteps is the length of the buffer, an int.
[1321] Returns: none.
[1322] InfoBuffer(constructor)
[1323] Arguments: x is an array of bytes.
[1324] nP is the number of bytes
[1325] NumSteps is the length of the buffer, an int.
[1326] Returns: none.
[1327] func
[1328] Arguments: buf is number of the buffer, an int
[1329] step is the position in the buffer, an int.
[1330] x is the time stamp, a long.
[1331] Returns: none.
[1332] func
[1333] Arguments: buf is number of the buffer, an int.
[1334] step is the position in the buffer, an int.
[1335] x is an array of FloatParameters.
[1336] Returns: none.
[1337] func
[1338] Arguments: buf is number of the buffer, an int.
[1339] step is the position in the buffer, an int.
[1340] x is an array of BoolParameters.
[1341] Returns: none.
[1342] func
[1343] Arguments: buf is number of the buffer, an int.
[1344] step is the position in the buffer, an int.
[1345] x is an array of Modes.
[1346] Returns: none.
[1347] func
[1348] Arguments: buf is number of the buffer, an int.
[1349] step is the position in the buffer, an int.
[1350] x is an array of shorts.
[1351] Returns: none.
[1352] TimeCount
[1353] Overview
[1354] TimeCount is a part class that performs a timer function. Method func returns true when time reaches pre-specified time value.
[1355] Attributes
[1356] tTime is the time in seconds, a FloatParameter.
[1357] timeElapsed is the time elapsed since timer starts, a double.
[1358] statusFlag indicates whether timer is running or stopped.
[1359] Methods for Developer
[1360] TimeCount (constructor)
[1361] Arguments: countUp, a boolean. Timer counts up from 0 if countUp is true; counts down from tTime otherwise.
[1362] Instantiates tTime, a FloatParameter.
[1363] Returns: none.
[1364] init
[1365] Arguments: none.
[1366] Initializes the timer. It should be called before timer starts.
[1367] Returns: none.
[1368] func
[1369] Arguments: period is the time since the last update in seconds, a double.
[1370] Updates the timer.
[1371] Returns: none.
[1372] stop
[1373] Arguments: none.
[1374] Stops the timer. It should be called when the timer is going to stop.
[1375] Returns: none.
[1376] getTime
[1377] Arguments: none.
[1378] Gets the time elapsed since timer starts.
[1379] Returns: elapsed time, a double.
[1380] Interlock
[1381] Overview
[1382] Interlock is an optional part class used to invoke an override of the current out Variable.
[1383] Attributes
[1384] interlock.trigger is a BoolParameter used to invoke INTERLOCK Mode.
[1385] interlock.reset is a BoolParameter used to return to normal Mode.
[1386] interlock.in is a FloatParameter or BoolParameter that sets out in the INTERLOCK Mode.
[1387] Methods for Developer
[1388] None.
[1389] Discussion of Parts Classes
[1390] Parts are optional or mandatory parts of blocks, providing optional functionality or functionality shared by many blocks. Generally, each block has one or more input parts, a body, and one or more output parts. Exceptions are InfoCollect, Event, and IOInterface blocks.
[1391] input (-Input) and output (-Output) parts may be of the unidirectional (UniDir-) or cascade (Casc-) types and may be for float (-Float-), boolean (-Bool-), or short (16 bit) integer (-Int-) value data types.
[1392] Unidirectional inputs and outputs are used in blocks, such as AnalogInput and ProcessSim, located in a measurement signal path. Dynamic elements in these blocks are initialized to steady-state corresponding to the current in value.
[1393] A unidirectional or cascade output part provides manual, auto, supervisory mode switching to select the source of the out variable. Before the mode switch the auto signal may be modified by an additive or multiplicative feedforward (unidirectional) source. After the mode switch the output is limited (optional in manual) and may be alarmed (optional in manual). In a cascade output part the out limits are each bidirectional variables that can be connected from a bidirectional out variable of another AdvancedPID block to implement a constraint or override. Each output part has an interlock input that when triggered overrides the out variable from other sources.
[1394] A cascade input part provides local/remote/supervisory mode switching to select the setpoint sp (bidirectional) source. The local setpoint may be ramped, the setpoint limited and modified by an additive or multiplicative feedforward (unidirectional) source. If the cascade part has an in (unidirectional measurement) signal, both it and the signal in the setpoint path may be linearized with matched functions before being passed to the block body. Then the signal in the measurement path is filtered (quadratic Butterworth).The cascade input part has two unidirectional output variables, pv and deviation. When the block has an in, as in an AdvancedPID block, it is passed to the pv. When it doesn't, as in an AnalogOutput block, pv is back calculated from a signal passed from the body. In either case deviation, which may be alarmed, is the difference between pv and sp.
[1395] Signals Classes
[1396] This section describes the signal classes, which are contained in the Signals package. Objects from Signals classes contain the information communicated between linked blocks or inserted into blocks as constants. These classes also provide methods to be used by users and tasks for setting and getting values and for linking and unlinking parameters and variables. The Signals package also contains an interface class for shared constants.
[1397] Constants
[1398] Overview
[1399] Constants is an interface containing state, status, mode, and option assignments shared by all blocks and their parts.
[1400] Attributes
[1401] Manual, auto, supervisory (mas) output modes are:
[1402] O_S Block is out of service.
[1403] INITIALIZE Transition actual mode enables bumpless transfer to target mode.
[1404] MANUAL Operator or set method can set output.
[1405] AUTO Block algorithm sets output.
[1406] SUPER Supervisory task sets output.
[1407] LINKED Permitted attribute indicating Mode target is connected to external source.
[1408] INTERLOCK Interlock sets output, actual mode is enabled by trigger, disabled by reset.
[1409] Local, remote, supervisory (lrs) setpoint modes are:
[1410] O_S Block is out of service
[1411] INITIALIZE Transition actual mode enables bumpless transfer to target mode
[1412] LOCAL Operator or set method can set setpoint.
[1413] REMOTE External block sets setpoint.
[1414] SUPER Supervisory task sets setpoint.
[1415] LINKED Permitted attribute indicates mode target connected to external source.
[1416] Signal quality status has the following (SEVA) ranked values:
[1417] CLEAR Signal is valid, on-line, and within spec.
[1418] CLOSE_CAS status is used to close cascade connection.
[1419] INIT status is used to open cascade connection.
[1420] BLURRED Signal is degraded, uncertainty is increased.
[1421] DAZZLED Signal is temporarily invalid, replaced by an estimate.
[1422] BLIND Signal is permanently invalid, replaced by an estimate.
[1423] FAILSAFEstatus indicates valve is forced to failsafe position.
[1424] OFFLINE Source is out of service.
[1425] Device maintenance status has the following (SEVA) ranked values:
[1426] NOMINAL Maintenance is not needed.
[1427] ON_TEST Device is in test or calibration mode.
[1428] LOW_PRIORITY Minor fault has been detected, quality status is BLURRED.
[1429] HIGH_PRIORITY Major fault has been detected, quality status is BLIND.
[1430] CRITICAL Critical fault detected, jeopardizing safety.
[1431] UNCHECKED maintenance reporting is not supported.
[1432] Limit indication and linking and setting permissions are contained in a packed Boolean status:
[1433] LIM_LO Signal is at its low limit.
[1434] LIM_HI Signal is at its high limit.
[1435] CONSTANT Signal is manually set.
[1436] CASCADE Signal is cascade connected.
[1437] UNSETABLE Signal can not be set. It is linked and not MANUAL or LOCAL
[1438] LINKED Signal is already linked, it cannot be connected to two sources.
[1439] LINK_NOSET Signal can not be set or linked.
[1440] NON_NEG Signal is prevented from having a negative value.
[1441] NOT_MEDIAN Signal is determined not to be the median signal.
[1442] Input part options include:
[1443] SP_PV_TRK_MAN Setpoint tracks PV when output is manually set.
[1444] SP_DN_UNCER Setpoint is decreased by the uncertainty.
[1445] SP_UP_UNCER Setpoint is increased by the uncertainty.
[1446] MULT_FF Feedforward is multiplicative, else it is additive.
[1447] I_O in is provided from device and point
[1448] Output part options include:
[1449] LIM_MAN Limits are applied to MANUAL output.
[1450] ALM_MAN Alarming is applied to a MANUAL output.
[1451] MAN_START Block returns from out-of-service in MANUAL mode.
[1452] MULT_FF Feedforward is multiplicative, else it is additive.
[1453] ALARM_BLURRED Block alarm triggered by BLURRED signal status.
[1454] I_O out is provided to device and point.
[1455] Feedback tuner states are;
[1456] PRETUNE Pretune is active. Controller must be in MANUAL.
[1457] OFF Tuner is off or not connected.
[1458] HOLD Selftune is suspended but stored tuning sets are used.
[1459] QUIET The loop is undisturbed, no error-peak search is in progress.
| LOCATE_1 | Error peak 1 is sought. | |
| LOCATE_2 | Error peak 2 is sought. | |
| LOCATE_3 | Error peak 3 is sought. | |
| LOCATE_4 | Error peak 4 is sought. | |
[1460] WAIT Tuning update is waiting for an output peak search to complete.
[1461] SETTLE Selftune is testing for error settling before returning to QUIET.
[1462] The feedforward tuner states are:
[1463] OFF Tuner is off or not connected.
[1464] HOLD Feedforward tuning is suspended and stored tuning sets are used.
[1465] QUIET The loop is undisturbed, no moment integration is in progress.
[1466] UNMEAS An error upset is detected before a load upset.
[1467] MEAS A load upset is detected while QUIET.
[1468] SIGNIF When MEAS, the control error exceeds the threshold
[1469] CNFIRM When SIGNIF, the feedback tuner finds peak 1.
[1470] WAIT There is no wait time before compensation update.
[1471] SETTLE The error is tested for settling before returning to QUIET.
[1472] The alarmSum states are:
[1473] LL_ACT Low-tow alarm is active.
[1474] LO_ACT Low alarm is active.
[1475] HI_ACT High-high alarm is active.
[1476] HH_ACT High alarm is active.
[1477] B_ACT Boolean alarm is active.
[1478] BLK_ACT Block alarm is active.
[1479] LL_UNACK Low-low alarm is unacknowledged.
[1480] LO_UNACK Low alarm is unacknowledged.
[1481] HI_UNACK High-high alarm is unacknowledged.
[1482] HH_UNACK High alarm is unacknowledged.
[1483] B_UNACK Boolean alarm is unacknowledged.
[1484] BLK_UNACK Block alarm is unacknowledged.
[1485] UNACK Set to false to acknowledge all of these alarms.
[1486] Mode
[1487] Overview
[1488] The cascade input parts use the Mode class for local-remote-supervisory (lrs) switching. The output parts use the Mode class for manual-auto-supervisory (mas) switching.
[1489] Attributes
[1490] The Mode class has four byte attributes whose bit assignments are assigned by the Constants interface:
[1491] target requested mode; one bit is set, default O_S bit set.
[1492] actual currently active mode; one bit is set, default O_S bit set.
[1493] permitted allowed modes; several bits may be set, default all bits are set.
[1494] last the last mode both requested and active; one bit is set, default O_S bit set.
[1495] Methods
[1496] getMode
[1497] Arguments: none.
[1498] Returns: active mode.
[1499] setMode
[1500] Arguments: desired mode.
[1501] If the mode is not linked
[1502] target mode is set to desired mode.
[1503] Returns: true
[1504] Else:
[1505] target mode is not changed.
[1506] Returns: false
[1507] linkTo Called from source
[1508] Arguments: sink reference.
[1509] If the sink is not linked
[1510] Source and sink are linked.
[1511] Returns: source reference
[1512] Else:
[1513] Returns: unchanged sink reference
[1514] unlink Called from source
[1515] Arguments: new sink reference.
[1516] Source and sink are unlinked
[1517] Returns: instantiates new sink object with existing target, actual, permitted (not linked), and last.
[1518] Parameter
[1519] Overview
[1520] Parameter is an abstract class providing features common to FloatParameter, BoolParameter, and IntParameter.
[1521] Attributes
[1522] status (SEVA ranked) signal quality status, enumerated byte.
[1523] limStatus Limit indication and link and set permissions, packed boolean byte.
[1524] source source is a String name.
[1525] time timestamp, a long integer msec. since 1970
[1526] Methods
[1527] getStatus
[1528] Arguments: none.
[1529] Returns: signal quality status.
[1530] FloatParameter
[1531] Overview
[1532] A block's or part's continuous tuning parameters are instances of the FloatParameter class.
[1533] It inherits from the Parameter class. The FloatParameter contains floating-point value and two status bytes. The value of an unlinked parameter may be set with the set Value method. A source for a linked parameter may be the forw or back part source block's out variable. It is linked (connected) by its linkTo method with a reference for the sink block's parameter.
[1534] Attributes
[1535] value floating point signal value.
[1536] Attributes from Super Class
[1537] status (SEVA ranked) signal quality status, enumerated byte.
[1538] limStatus Limit indication and link and set permissions, packed boolean byte.
[1539] source source is a String name.
[1540] time timestamp, a long integer msec. since 1970
[1541] Methods
[1542] linkTo Called from source
[1543] Arguments: sink reference, source name.
[1544] If the sink is not linked
[1545] Source and sink are linked.
[1546] The source name is assigned
[1547] Returns: source reference
[1548] Else:
[1549] Returns: unchanged sink reference
[1550] unlink Called from source
[1551] Arguments: sink reference.
[1552] Source and sink are unlinked
[1553] Returns: instantiates new sink object with existing value and clear status.
[1554] getValue
[1555] Arguments: none.
[1556] Returns: value.
[1557] setValue
[1558] Arguments: desired value.
[1559] If the mode is not unsetable:
[1560] value is set to desired value.
[1561] Returns: true
[1562] Else:
[1563] value is not changed.
[1564] Returns: false
[1565] Methods from Super Class
[1566] getStatus
[1567] Arguments: none.
[1568] Returns: signal quality status.
[1569] FloatRange
[1570] Overview
[1571] The FloatRange class contains the high and low range limits and their units. A range object is contained in a FloatVariable. Range information is entered at the signal source and propagated downstream with a unidirectional connection and upstream with a bidirectional (cascade) connection.
[1572] Attributes
[1573] hi high range limit in engineering units, float, default is 100.
[1574] low range limit in engineering units, float, default 0.
[1575] units engineering units, String, default %.
[1576] delta is a communication threshold, a float value in engineering units, default 0.
[1577] Variable
[1578] Overview
[1579] Variable is an abstract class providing features common to Float Variable, Bool Variable, and Int Variable.
[1580] Attributes
[1581] alarmSum active and unacknowledged alarms, packed Boolean short.
[1582] maintenance SEVA ranked maintenance status, enumerated byte.
[1583] source source is a String name.
[1584] Methods
[1585] ack
[1586] Arguments: none.
[1587] All alarms are acknowledged.
[1588] Returns: none.
[1589] getAlarmHI
[1590] Arguments: none.
[1591] If high alarm is active:
[1592] Returns: true.
[1593] Else
[1594] Returns false.
[1595] getAlarmHH
[1596] Arguments: none.
[1597] If high-high alarm is active:
[1598] Returns: true.
[1599] Else
[1600] Returns false.
[1601] getAlarmLO
[1602] Arguments: none.
[1603] If low alarm is active:
[1604] Returns: true.
[1605] Else
[1606] Returns false
[1607] getAlarmLL
[1608] Arguments: none.
[1609] If low-low alarm is active:
[1610] Returns: true.
[1611] Else
[1612] Returns false.
[1613] getAlarmBLK
[1614] Arguments: none.
[1615] If block alarm is active:
[1616] Returns: true.
[1617] Else
[1618] Returns false.
[1619] getAlarmB
[1620] Arguments: none.
[1621] If boolean alarm is active:
[1622] Returns: true.
[1623] Else
[1624] Returns false.
[1625] FloatVariable
[1626] Overview
[1627] A block output or input signal is an instance of the FloatVariable class. It inherits from Variable and is usually contained in the source block's output part and linked (connected) by its linkTo method with a reference for the sink block's variable. A cascade connection, such as primary-out to secondary-remoteSP, is bidirectional. A FloatParameter (forw) is set by the primary. Another FloatParameter (back) is set by the.secondary. Both parameters and other entities are contained in the FloatVariable class. A connection from an AnalogInput's out to an AdvancedPID's in is uni-directional. It's FloatVariable has a forw parameter but no back parameter. The FloatVariable also conveys uncertainty, range, and maintenance information, backwards for a cascade connection and forwards for a uni-directional connection. Alarm summary information is conveyed forwards.
[1628] Attributes
[1629] forw forward propagated FloatParameter, value (eu), status, limStatus.
[1630] back backward propagated FloatParameter, value (eu), status, limStatus.
[1631] range high, low range limits in engineering units (eu), FloatRange class.
[1632] uncertainty SEVA uncertainty, float value (eu).
[1633] Attributes from Super Class
[1634] alarmSum active and unacknowledged alarms, packed Boolean short.
[1635] maintenance SEVA ranked maintenance status, enumerated byte.
[1636] source source is a String name.
[1637] Methods
[1638] linkTo Called from forw source
[1639] Arguments: forw sink reference, source name.
[1640] If the forw sink is not linked
[1641] Source and sink are linked.
[1642] The source name is assigned.
[1643] Returns: forw source reference
[1644] Else:
[1645] Returns: unchanged forw sink reference
[1646] Unlink Called from forw source
[1647] Arguments: forw sink reference.
[1648] CASCADE or 0.
[1649] Source and sink are unlinked
[1650] Returns: instantiates new sink object.
[1651] Methods from Super Class
[1652] ack
[1653] Arguments: none.
[1654] All alarms are acknowledged.
[1655] Returns: none.
[1656] getAlarmHI
[1657] Arguments: none.
[1658] If high alarm is active:
[1659] Returns: true.
[1660] Else
[1661] Returns false.
[1662] getAlarmHH
[1663] Arguments: none.
[1664] If high-high alarm is active:
[1665] Returns: true.
[1666] Else
[1667] Returns false.
[1668] getAlarmLO
[1669] Arguments: none.
[1670] If low alarm is active:
[1671] Returns: true.
[1672] Else
[1673] Returns false.
[1674] getAlarmLL
[1675] Arguments: none.
[1676] If low-low alarm is active:
[1677] Returns: true.
[1678] Else
[1679] Returns false.
[1680] getAlarmBLK
[1681] Arguments: none.
[1682] If block alarm is active:
[1683] Returns: true.
[1684] Else
[1685] Returns false.
[1686] BoolParameter
[1687] Overview
[1688] A block's or part's binary parameters are instances of the BoolParameter class. It inherits from the Parameter class. The BoolParameter contains boolean value and two status bytes. The value of an unlinked parameter may be set with the setValue method. A source for a linked parameter may be the forw or back part source block's out variable. It is linked (connected) by its linkTo method with a reference for the sink block's parameter.
[1689] Attributes
[1690] value boolean signal value.
[1691] Attributes from Super Class
[1692] status (SEVA ranked) signal quality status, enumerated byte.
[1693] limStatus limit indication and link and set permissions, packed Boolean byte.
[1694] source source is a String name.
[1695] time timestamp, a long integer msec. since 1970
[1696] Methods
[1697] linkTo Called from source
[1698] Arguments: sink reference, source name.
[1699] If the sink is not linked.
[1700] Source and sink are linked.
[1701] The source name is assigned
[1702] Returns: source reference.
[1703] Else:
[1704] Returns: unchanged sink reference.
[1705] unlink Called from source
[1706] Arguments: sink reference.
[1707] Source and sink are unlinked
[1708] Returns: instantiates new sink object with existing value and clear status.
[1709] getValue
[1710] Arguments: none.
[1711] Returns: value.
[1712] setValue
[1713] Arguments: desired value.
[1714] If the parameter is not unsetable:
[1715] value is set to desired value.
[1716] Returns: true
[1717] Else:
[1718] value is not changed.
[1719] Returns: false
[1720] Methods from Super Class
[1721] getStatus
[1722] Arguments: none.
[1723] Returns: signal quality status.
[1724] BooleanVariable
[1725] Overview
[1726] A block's binary output or input signal is an instance of the BoolVariable class. It inherits from Variable and is usually contained in the source blocs output part and linked (connected) by its linkTo method with a reference for the sink block's variable. A cascade connection, such as primary-out to secondary-remoteSP, is bidirectional. A BoolParameter (forw) is set by the primary. Another BoolParameter (back) is set by the secondary. Both parameters and other entities are contained in the BoolVariable class. The BoolVariable also conveys the maintenance information, backwards for a cascade connection and forwards for a unidirectional connection. Alarm summary information is conveyed forwards.
[1727] Attributes
[1728] forw forward propagated BoolParameter, value (eu), status, limStatus.
[1729] back backward propagated BoolParameter, value (eu), status, limStatus.
[1730] Attributes from Super Class
[1731] alarmSum active and unacknowledged alarms, packed boolean short.
[1732] maintenance SEVA ranked maintenance status, enumerated byte.
[1733] source source is a String name.
[1734] Methods
[1735] linkTo Called from forw source
[1736] Arguments: forw sink reference, source name.
[1737] If the forw sink is not linked
[1738] Source and sink are linked.
[1739] The source name is assigned.
[1740] Returns: forw source reference
[1741] Else:
[1742] Returns: unchanged forw sink reference
[1743] unlink Called from forw source
[1744] Arguments: forw sink reference
[1745] CASCADE or 0
[1746] Source and sink are unlinked
[1747] Returns: instantiates new sink object.
[1748] Methods from Super Class
[1749] ack
[1750] Arguments: none.
[1751] The boolean alarm is acknowledged.
[1752] Returns: none.
[1753] getAlarm
[1754] Arguments: none.
[1755] If boolean alarm is active:
[1756] Returns: true.
[1757] Else
[1758] Returns false.
[1759] getAlarmBLK
[1760] Arguments: none.
[1761] If block alarm is active:
[1762] Returns: true.
[1763] Else
[1764] Returns false.
[1765] IntParameter
[1766] Overview
[1767] A block's or part's integer parameters are instances of the IntParameter class. It inherits from the Parameter class. The IntParameter contains integer value and two status bytes. The value of an unlinked parameter may be set with the setValue method. A source for a linked parameter may be the forw or back part source block's out variable. It is linked (connected) by its linkTo method with a reference for the sink block's parameter.
[1768] Attributes
[1769] value integer signal value.
[1770] Attributes from Super Class
[1771] status (SEVA ranked) signal quality status, enumerated byte.
[1772] limStatus limit indication and link and set permissions, packed Boolean byte.
[1773] source source is a String name.
[1774] time timestamp, a long integer msec. since 1970
[1775] Methods
[1776] linkTo Called from source
[1777] Arguments: sink reference, source name.
[1778] If the sink is not linked
[1779] Source and sink are linked.
[1780] The source name is assigned.
[1781] Returns: source reference.
[1782] Else:
[1783] Returns: unchanged sink reference.
[1784] unlink Called from source
[1785] Arguments: sink reference.
[1786] Source and sink are unlinked
[1787] Returns: new sink reference with existing value and clear status.
[1788] getValue
[1789] Arguments: none.
[1790] Returns: value.
[1791] setValue
[1792] Arguments: desired value.
[1793] If the parameter is not unsetable:
[1794] value is set to desired value.
[1795] Returns: true
[1796] Else:
[1797] value is not changed.
[1798] Returns: false
[1799] Methods from Super Class
[1800] getStatus
[1801] Arguments: none.
[1802] Returns: signal quality status.
[1803] IntRange
[1804] Overview
[1805] The IntRange class contains the high and low range limits. A range object is contained in an IntVariable. Range information is entered at the signal source and propagated downstream with a unidirectional connection and upstream with a bidirectional (cascade) connection.
[1806] Attributes
[1807] hi high range limit in integer, default is 1.
[1808] lo low range limit in integer, default is 0.
[1809] IntVariable
[1810] Overview
[1811] A block's integer output or input signal is an instance of the IntVariable class. It inherits from Variable and is usually contained in the source block's output part and linked (connected) by its linkTo method with a reference for the sink block's variable. A cascade connection, such as primary-out to secondary-remoteSP, is bidirectional. An IntParameter (forw) is set by the primary. Another IntParameter (back) is set by the secondary. Both parameters and other entities are contained in the IntVariable class. The IntVariable also conveys range, and maintenance information, backwards for a cascade connection and forwards for a unidirectional connection. Alarm summary information is conveyed forwards.
[1812] Attributes
[1813] forw forward propagated BoolParameter, value (eu), status, limStatus.
[1814] back backward propagated BoolParameter, value (eu), status, limStatus.
[1815] range high, low range limits in engineering units (eu), IntRange class.
[1816] Attributes from Super Class
[1817] alarmSum active and unacknowledged alarms, packed Boolean short.
[1818] maintenance SEVA ranked maintenance status, enumerated byte.
[1819] source source is a String name.
[1820] Methods
[1821] linkTo Called from forw source
[1822] Arguments: forw sink reference, source name.
[1823] If the forw sink is not linked
[1824] Source and sink are linked.
[1825] The source name is assigned.
[1826] Returns: forw source reference
[1827] Else:
[1828] Returns: unchanged forw sink reference
[1829] unlink Called from forw source
[1830] Arguments: forw sink reference, CASCADE or 0
[1831] Source and sink are unlinked
[1832] Returns: instantiates new sink object.
[1833] Methods from Super Class
[1834] ack
[1835] Arguments: none.
[1836] All alarms are acknowledged.
[1837] Returns: none.
[1838] getAlarmHI
[1839] Arguments: none.
[1840] If high alarm is active:
[1841] Returns: true.
[1842] Else
[1843] Returns false.
[1844] getAlarmHH
[1845] Arguments: none.
[1846] If high-high alarm is active:
[1847] Returns: true.
[1848] Else
[1849] Returns false.
[1850] getAlarmLO
[1851] Arguments: none.
[1852] If low alarm is active:
[1853] Returns: true.
[1854] Else
[1855] Returns false.
[1856] getAlarmLL
[1857] Arguments: none.
[1858] If low-low alarm is active:
[1859] Returns: true.
[1860] Else
[1861] Returns false.
[1862] getAlarmBLK
[1863] Arguments: none.
[1864] If block alarm is active:
[1865] Returns: true.
[1866] Else
[1867] Returns false.
[1868] Discussion of Signals Classes
[1869] Interblock connections are performed with Variable and Parameter objects contained in the upstream block and linked by reference to the downstream block. When the upstream block and downstream block are in different stations, it is necessary to have a periodically updated proxy Variable or Parameter in the station with the downstream block. Fixed constants shared by potentially all blocks and parts are made available in the Constants interface implemented or inherited by all PCOs. All PCOs also inherit or implement the Serializable interface. Composites and blocks also inherit or implement the Runnable interface.
[1870] External Interfaces for Signals Classes
[1871] Output signals are objects of a float, boolean, or int Variable class contained in the upstream block. An input Variable of one block may be linked by reference to an output Variable contained in another block in the same station. When the output variable is contained in a block from a different station it is necessary to store a periodically updated copy of the output Variable in the same station as the downstream block so that the input may be linked by reference to the copy (proxy). A bidirectional Variable involved in a cascade connection requires that certain of its Parameters and attributes (forw and alarmSum) be communicated in the downstream direction, while others (back and range) are communicated in the upstream direction.
[1872] Parameters of one block may be linked by reference to a Parameter component of an output Variable in another block. Similarly an updated proxy Parameter is required in the downstream block's station if the upstream block is in a different station.
[1873] A PCO Temperature Cascade Control Loop with a Simulated Process
[1874] A further appreciation of the operation of a control system 10 (FIG. 1) and particularly, for example, of a controller 36 (or other control device) that utilizes process control objects (PCOs) of the type described above may be attained by reference to the Java code listing that follows. This is an application of a PCO that implements a temperature cascade control loop on the device (e.g., controller 36) on which it resides. A graphical depiction of the operation of that control loop is presented in FIG. 16, above.
[1875] Referring to the listing, in lines 3-7 declare and instantiate the composites and blocks that make up the temperature cascade control loop PCO, to wit, supervisor (Supv) block the cascase composite (Cascade), the temperature process composite (TempProcess), the information collection block (InfoCollect), and the object (ObjList) that enumerates all objects that are to be executed by the control system 10. The latter object is referred to as the “run” list. In lines 9-10, the code declares alias names for parameters internal to the TempCasc PCO object itself.
[1876] Line 13 begins the configuration method, which is provided here merely as an example of how a previously-instantiated PCO (e.g., the TempCasc PCO) can be customized for use in a particular control system. Those skilled in the art will, of course, appreciate that configuration can be performed other than via “hard coding” as shown in lines 13, et seq. Typically, such configuration is performed via a graphical user interface.
[1877] In line 16, the previously instantiated user block object (s21) is added to the run list. No additional configuration is shown here with respect thereto.
[1878] In lines 19-33, the cascade composite object (tc21) is configured and its input variables connected, by reference, to the outputs of other objects utilized in the system 10. Particularly, in lines 19-20, the analog input of the primary control loop in temperature cascade object tc21 is connected to the temperature measurement output of the simulated process object (pr21). In lines 21-22, a bidirectional connection is established between the PID supervisory setpoint of the composite object tc21 and the output of the supervisory block s21. In lines 23-24, a unidirectional connection is established between the flow measurement output of the simulated process object pr21 and the analog input of the secondary control loop in the temperature cascade object tc21.
[1879] In step 25, the configuration method of the temperature cascade control object tc21 is invoked. This effects initialization of the parameters and connections for that object tc21.
[1880] In step 26-27, an optional alarm part of object tc21's primary loop analog input is instantiated. The default alarm limits are set in accord with the output range of the analog input. In steps 28-29, the high and low alarm limits are set to 75 and 30, respectively.
[1881] In step 30, the input mode of the object tc21's primary PID is set to “supervisory,” indicating that it will take its setpoint from supervisory object s21. Those skilled in the art will, of course, appreciate that the supervisory setpoint could be set by other external sources.
[1882] In steps 31-32, the tuning settings previously defined in user block s21 are inserted into the primary and secondary loops of the PID controllers of the composite tc21. In step 33, the block period of the analog input block of the secondary loop is set.
[1883] In step 34, the composite tc21 is added to the run list.
[1884] In steps 37-40, the secondary analog output of the simulated process block tc21 is connected to the flow process input of composite pr21, the latter's configure method is called and it is added to the run list.
[1885] In lines 43-47, inputs for the information collection block are connected to outputs of blocks and composites of interest, and the former is added to the run list.
[1886] In lines 49-50, the composite objects tc21 and pr21 are turned “on” for execution.
[1887] The run method of the temperature cascade control loop begins at line 54. This method is called by the control system 10 scheduler each BPC based on the loop's inclusion in the run list. In steps 64-78, the run method of the cascade control loop invokes the run methods of its respective composites and blocks, specifically, those enumerated the run list. Though not shown here, the composites have their own run lists, the blocks on which are called as each composite is called. In the illustrated embodiment, a loop beginning at step 62 limits the foregoing to n cycles, merely for purposes of testing and illustration.
| public class TempCasc implements Constants |
| { |
Summary
[1888] Described herein are control systems and method meeting the objects set forth above. Those skilled in the art will appreciate that the illustrated embodiment is an example of the invention and that other embodiments incorporating changes therein fall within the scope of the invention. Thus, by way of example, it will be appreciated that the invention can be practiced utilizing, instead of or in addition to Java objects, Java applets, servlets, and/or software constructs of programming languages other than Java. Moreover, it will be appreciated that the invention can be utilized in a range of control application, including, process, industrial, and environmental, among others. In view thereof, what we claim is:
Claims
Certificate of Correction present
The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.
What is claimed is:
1. A control device comprising:
a virtual machine environment,
the virtual machine environment executing an object or other software construct (collectively, “object”) that configures the control device to provide a control function,
the object communicating a datum with an entity that stores the datum, and
the object accessing the datum by reference to storage maintained in the entity.
2. The control device of claim 1, wherein
the virtual machine environment is a Java virtual machine, and
the object is a Java object.
3. The control device of claim 1, wherein the object accesses the datum via any of a pointer, an address, or a symbolic or other reference to storage maintained in the entity.
4. The control device of claim 3, wherein the object accesses the datum for purposes of any of getting or setting a value thereof.
5. The control device of claim 3, wherein the object does not maintain a copy of the datum.
6. The control device of any one of claims 1-5, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.
7. The control device of any one of claims 1-5, wherein the object configures the control device to provide any of sensing, actuation and other control functions.
8. The control device of any one of claims 1-5, wherein the object configures the control device to execute one or more control blocks.
9. The control device of claim 8, wherein one or more of the control blocks execute a control algorithm, provide input, and/or provide output.
10. The control device of any one of claims 1-5, wherein the device is any of a workstation, controller, control station, and a field device.
11. The control device of any one of claims 1-5 adapted for providing any of process, industrial, environmental or other control.
12. The control device of any one of claims 1-5, wherein the object comprises
one or more mandatory portions for which memory is allocated in the control device at the time of object creation,
and one or more optional parts for which memory space is allocated subsequent to object creation as needed.
13. The control device of any one of claims 1-5, comprising
a second object that executes in the virtual machine environment,
the object and the second object having input and output parts defined from subsets of a common set of input and output classes, respectively.
14. The control device of any one of claims 1-5, wherein the object configures the device to provide an analog input function with multiple inputs coupled to accept readings from multiple respective input devices and to generate an output based on one or more of those readings.
15. A control system comprising:
one or more control devices, each providing a virtual machine environment,
a plurality of objects executing in the one or more virtual machine environments,
the plurality of objects including a first object and a second object that communicate a datum with one another,
the first object maintaining a sole instance of the datum as between at least the first and second objects,
the second object accessing the datum by reference.
16. The control system of claim 15, wherein
the virtual machine environment maintained by the control devices is a Java virtual machine, and
the first object and the second object are Java objects.
17. The control system of claim 15, wherein the second object accesses the datum via any of a pointer, an address, or a symbolic or other reference to the instance of the datum maintained by the first object.
18. The control system of claim 17, wherein the second object accesses the datum for purposes of any of getting or setting a value thereof.
19. The control system of any one of claims 15-18, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.
20. The control system of any one of claims 15-18, wherein the first and second objects configure control devices on which they execute to provide any of sensing, actuation and other control functions.
21. The control system of any one of claims 15-18, wherein the first and second objects configure the one or more control devices on which they reside to execute control blocks.
22. The control system of claim 21, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.
23. The control system of any one of claims 15-18, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.
24. The control system of any one of claims 15-18 adapted for providing any of process, environmental or other control.
25. The control system of any one of claims 15-18, wherein at least one of the first and second object comprise
one or more mandatory portions for which memory is allocated in the control device at the time of object creation,
and one or more optional parts for which memory space is allocated subsequent to object creation as needed.
26. The control system of any one of claims 15-18, wherein the first and second objects have input and output parts defined from subsets of a common set of input and output classes, respectively.
27. The control system of any one of claims 15-18, wherein at least one of the first and second objects configures the device to provide an analog input function with multiple inputs coupled to accept readings from multiple respective input devices and to generate an output based on one or more of those readings.
28. A control system comprising:
one or more control devices, each providing a virtual machine environment,
a plurality of objects executing in the one or more virtual machine environments,
the plurality of objects including a first object and a second object between which a connection is established to communicate with one another one or more data contained in a data structure,
the first object maintaining a sole instance of the data structure and data contained therein as between at least the first and second objects,
the second object accessing data in the data structure by reference.
29. The control system of claim 28, wherein the data structure comprises a unidirectional variable able having
a measurement, a setpoint or other value, and
any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.
30. The control system of claim 29, wherein
the virtual machine environment maintained by the control devices is a Java virtual machine, and
the first object and the second objects are Java objects.
31. The control system of claim 29, wherein the second object accesses data in the data structure via any of a pointer, an address, or a symbolic or other reference to the instance of the data structure maintained by the first object.
32. The control system of claim 29, wherein the second object accesses the data structure for purposes of any of getting or setting a datum thereof.
33. The control system of claim 28, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.
34. The control system of claim 28, wherein the first and second objects configure control devices on which they execute to provide any of sensing, actuation and other control functions.
35. The control system of claim 28, wherein the first and second objects configure the one or more control devices on which they reside to execute control blocks.
36. The control system of claim 33, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.
37. The control system of claim 28, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.
38. The control system of claim 28 adapted for providing any of process, environmental or other control.
39. The control system of any one of claims 28-38, wherein the data structure comprises a bi-directional variable having
a forward-going measurement, setpoint or other value (collectively, “forward-going value”),
any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,
a back-going measurement, setpoint or other value (collectively, “back-going value”), and
any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).
40. A control system comprising:
one or more control devices, each providing a virtual machine environment,
a plurality of objects executing in the one or more virtual machine environments,
the plurality of objects including a first object that communicates a datum with a second object and a third object,
the first object maintaining a sole instance of the datum as between at least the first, second and third objects,
the second and third objects accessing the datum by reference.
41. A control system comprising:
one or more control devices, each providing a virtual machine environment,
a plurality of objects executing in the one or more virtual machine environments,
the plurality of objects including a first object with which connections are established by a second object and by a third object, each connection being for the transfer of data contained in a data structure,
the first object maintaining a sole instance of the data structure and data contained therein as between at least the first, second and third objects,
the second and third objects accessing data in the data structure by reference.
42. The control system of any one of claims 40-41, wherein the data structure comprises a bi-directional variable having
a forward-going measurement, setpoint or other value (collectively, “forward-going value”),
any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,
a back-going measurement, setpoint or other value (collectively, “back-going value”), and
any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).
43. A method of operating a control device comprising:
executing an object or other software construct (collectively, “object”) on a virtual machine environment provided in the control device, the object configuring the control device to provide a control function,
communicating a datum between the object and an entity that stores the datum, the object accessing the datum by reference to storage maintained in the entity.
44. The method of claim 43, wherein the virtual machine environment is a Java virtual machine, and wherein the object is a Java object.
45. The method of claim 43, composing accessing the datum from the object via any of a pointer, an address, or a symbolic or other reference to storage maintained in the entity.
46. The method of claim 45, comprising accessing the datum for purposes of any of getting or setting a value thereof.
47. The method of claim 45, wherein the object does not maintain a copy of the datum.
48. The method of any one of claims 43-47, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.
49. The method of any one of claims 43-47, comprising executing the object to configure the control device to provide any of sensing, actuation and other control functions.
50. The method of any one of claims 43-47, wherein the executing step includes executing one or more control blocks associated with the object.
51. The method of claim 50, wherein one or more of the control blocks comprises a control algorithm, an input function, and/or an output function.
52. The method of any one of claims 43-47, wherein the device is any of a workstation, controller, control station, and a field device.
53. The method of any one of claims 43-47 adapted for providing any of process, industrial, environmental or other control.
54. A method of operating a control system comprising:
executing a plurality of objects in virtual machine environments provided on one or more control devices, the objects configuring the one or more devices to provide control functions,
communicating a datum between first and second ones of the plurality of objects,
maintaining in the first object a sole instance of the datum, as between at least the first and second objects, and
accessing by reference the datum with the second object.
55. The method of claim 54, wherein the virtual machine environment is a Java virtual machine, and the plurality of objects are Java objects.
56. The method of claim 54, wherein the accessing step includes accessing the datum via any of a pointer, an address, or a symbolic or other reference to the instance of the datum maintained by the first object.
57. The method of any one of claims 54-56, wherein the datum is any of a measurement, a setpoint or other value, or any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement, setpoint or other value.
58. The method of any one of claims 54-56, wherein the executing step includes executing at least the first and second objects to configure the control devices to provide any of sensing, actuation and other control functions.
59. The method of any one of claims 54-56, wherein the executing step includes executing one or more control blocks associated with the first and second objects.
60. The method of claim 59, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.
61. The method of any one of claims 54-56, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.
62. The method of any one of claims 54-56 adapted for providing any of process, environmental or other control.
63. A method of operating a control system, comprising:
executing a plurality of objects in virtual machine environments provided on one or more control devices, the objects configuring the one or more devices to provide control functions,
communicating one or more data contained in a data structure between first and second ones of the plurality of objects,
maintaining in the first object a sole instance of the data structure and data contained therein as between at least the first and second objects,
accessing by reference data in the data structure with the second object.
64. The method of claim 63, wherein the data structure comprises a unidirectional variable having
a measurement, a setpoint or other value, and
any of a range, a status, a limit status, a time stamp or other information pertaining to such measurement setpoint or other value.
65. The method of claim 63, wherein the executing step includes executing at least the first and second objects to configure the control devices to provide any of sensing, actuation and other control functions.
66. The method of claim 63, wherein the executing step includes executing one or more control blocks associated with the first and second objects.
67. The method of claim 63, wherein at least one of the control blocks executes a control algorithm, provides input and/or provides output.
68. The method of claim 63, wherein one or more of the control devices is any of a workstation, controller, control station, and a field device.
69. The method of claim 63 adapted for providing any of process, environmental or other control.
70. The method of any one of claims 63-69, wherein the data structure comprises a bi-directional variable having
a forward-going measurement, setpoint or other value (collectively, “forward-going value”),
any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,
a back-going measurement, setpoint or other value (collectively, “back-going value”), and
any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).
71. A method of operating a control system, comprising:
executing a plurality of objects in virtual machine environments provided on one or more control devices, the objects configuring the one or more devices to provide control functions,
communicating one or more data contained, in a data structure between first one of the objects and second and third ones of the objects,
maintaining in the first object a sole instance of the data structure and data contained therein as between at least the first, second and third objects,
accessing by reference data in the data structure with the second and third objects.
72. The method of claim 71, wherein the data structure comprises a bi-directional variable having
a forward-going measurement, setpoint or other value (collectively, “forward-going value”),
any of a range, a status, a limit status, a time stamp or other information pertaining to the forward-going value,
a back-going measurement, setpoint or other value (collectively, “back-going value”), and
any of a range, a status, a limit status, a time stamp or other information pertaining to the back-going value).
Patent Citations (295)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US3665172(A) | 1972-05-01 | Spaargaren et al. | Applicant |
| US3810119(A) | 1974-05-01 | Zieve et al. | Applicant |
| US3825905(A) | 1974-07-01 | Allen, Jr. | Applicant |
| US4006464(A) | 1977-02-01 | Landell | Applicant |
| US4096566(A) | 1978-06-01 | Borie et al. | Applicant |
| US4276593(A) | 1981-06-01 | Hansen | Applicant |
| US4302820(A) | 1981-11-01 | Struger et al. | Applicant |
| US4312068(A) | 1982-01-01 | Goss et al. | Applicant |
| US4323966(A) | 1982-04-01 | Whiteside et al. | Applicant |
| US4347563(A) | 1982-08-01 | Paredes et al. | Applicant |
| US4410942(A) | 1983-10-01 | Milligan et al. | Applicant |
| US4413314(A) | 1983-11-01 | Slater et al. | Applicant |
| US4423486(A) | 1983-12-01 | Berner | Applicant |
| US4428044(A) | 1984-01-01 | Liron | Applicant |
| US4435762(A) | 1984-03-01 | Milligan et al. | Applicant |
| US4443861(A) | 1984-04-01 | Slater | Applicant |
| US4456997(A) | 1984-06-01 | Spitza | Applicant |
| US4466098(A) | 1984-08-01 | Southard | Applicant |
| US4471457(A) | 1984-09-01 | Videki, II | Applicant |
| US4488226(A) | 1984-12-01 | Wagner, Jr. et al. | Applicant |
| US4493027(A) | 1985-01-01 | Katz et al. | Applicant |
| US4609995(A) | 1986-09-01 | Hasebe | Applicant |
| US4615001(A) | 1986-09-01 | Hudgins, Jr. | Applicant |
| US4628437(A) | 1986-12-01 | Poschmann et al. | Applicant |
| US4639852(A) | 1987-01-01 | Motomiya | Applicant |
| US4641269(A) | 1987-02-01 | Japenga et al. | Applicant |
| US4641276(A) | 1987-02-01 | Dunki-Jacobs | Applicant |
| US4648064(A) | 1987-03-01 | Morley | Applicant |
| US4649479(A) | 1987-03-01 | Advani et al. | Applicant |
| US4663704(A) | 1987-05-01 | Jones et al. | Applicant |
| US4672530(A) | 1987-06-01 | Schuss | Applicant |
| US4675812(A) | 1987-06-01 | Capowski et al. | Applicant |
| US4682158(A) | 1987-07-01 | Ito et al. | Applicant |
| US4682304(A) | 1987-07-01 | Tierney | Applicant |
| US4683530(A) | 1987-07-01 | Quatse | Applicant |
| US4692859(A) | 1987-09-01 | Ott | Applicant |
| US4692918(A) | 1987-09-01 | Elliott et al. | Applicant |
| US4703421(A) | 1987-10-01 | Abrant et al. | Applicant |
| US4704676(A) | 1987-11-01 | Flanagan et al. | Applicant |
| US4709325(A) | 1987-11-01 | Yajima | Applicant |
| US4719593(A) | 1988-01-01 | Threewitt et al. | Applicant |
| US4727477(A) | 1988-02-01 | Gavril | Applicant |
| US4733366(A) | 1988-03-01 | Devesso et al. | Applicant |
| US4742349(A) | 1988-05-01 | Miesterfeld et al. | Applicant |
| US4750109(A) | 1988-06-01 | Kita | Applicant |
| US4790762(A) | 1988-12-01 | Harms, deceased et al. | Applicant |
| US4805107(A) | 1989-02-01 | Kieckhafer et al. | Applicant |
| US4816996(A) | 1989-03-01 | Hill et al. | Applicant |
| US4817094(A) | 1989-03-01 | Lebizay et al. | Applicant |
| US4872106(A) | 1989-10-01 | Slater | Applicant |
| US4897777(A) | 1990-01-01 | Janke et al. | Applicant |
| USRE33162(E) | 1990-02-01 | Yoshida et al. | Applicant |
| US4910658(A) | 1990-03-01 | Dudash et al. | Applicant |
| US4910691(A) | 1990-03-01 | Skeirik | Applicant |
| US4918690(A) | 1990-04-01 | Markkula, Jr. et al. | Applicant |
| US4958277(A) | 1990-09-01 | Hill et al. | Applicant |
| US4959774(A) | 1990-09-01 | Davis | Applicant |
| US4965717(A) | 1990-10-01 | Cutts, Jr. et al. | Applicant |
| US4965742(A) | 1990-10-01 | Skeirik | Applicant |
| US4965880(A) | 1990-10-01 | Petitjean | Applicant |
| US4991170(A) | 1991-02-01 | Kem | Applicant |
| US5008805(A) | 1991-04-01 | Fiebig et al. | Applicant |
| US5050165(A) | 1991-09-01 | Yoshioka et al. | Applicant |
| US5068778(A) | 1991-11-01 | Kosem et al. | Applicant |
| US5121318(A) | 1992-06-01 | Lipner et al. | Applicant |
| US5122948(A) | 1992-06-01 | Zapolin | Applicant |
| US5124908(A) | 1992-06-01 | Broadbent | Applicant |
| US5129087(A) | 1992-07-01 | Will | Applicant |
| US5131092(A) | 1992-07-01 | Sackmann et al. | Applicant |
| US5134574(A) | 1992-07-01 | Beaverstock et al. | Applicant |
| US5136704(A) | 1992-08-01 | Danielsen et al. | Applicant |
| US5138708(A) | 1992-08-01 | Vosbury | Applicant |
| US5140677(A) | 1992-08-01 | Fleming et al. | Applicant |
| US5146589(A) | 1992-09-01 | Peet, Jr. et al. | Applicant |
| US5150289(A) | 1992-09-01 | Badavas | Examiner |
| US5151978(A) | 1992-09-01 | Bronikowski et al. | Applicant |
| US5151981(A) | 1992-09-01 | Westcott et al. | Applicant |
| US5159673(A) | 1992-10-01 | Sackmann et al. | Applicant |
| US5162986(A) | 1992-11-01 | Graber et al. | Applicant |
| US5163055(A) | 1992-11-01 | Lee et al. | Applicant |
| US5164894(A) | 1992-11-01 | Cunningham-Reid et al. | Applicant |
| US5166685(A) | 1992-11-01 | Campbell, Jr. et al. | Applicant |
| US5168276(A) | 1992-12-01 | Huston et al. | Applicant |
| US5168441(A) | 1992-12-01 | Onarheim et al. | Applicant |
| US5175829(A) | 1992-12-01 | Stumpf et al. | Applicant |
| US5193175(A) | 1993-03-01 | Cutts, Jr. et al. | Applicant |
| US5202961(A) | 1993-04-01 | Mills et al. | Applicant |
| US5212784(A) | 1993-05-01 | Sparks | Applicant |
| US5233615(A) | 1993-08-01 | Goetz | Applicant |
| US5245704(A) | 1993-09-01 | Weber et al. | Applicant |
| US5251125(A) | 1993-10-01 | Karnowski et al. | Applicant |
| US5255367(A) | 1993-10-01 | Bruckert et al. | Applicant |
| US5258999(A) | 1993-11-01 | Wernimont et al. | Applicant |
| US5271013(A) | 1993-12-01 | Gleeson | Applicant |
| US5283729(A) | 1994-02-01 | Lloyd | Applicant |
| US5289365(A) | 1994-02-01 | Caldwell et al. | Applicant |
| US5295258(A) | 1994-03-01 | Jewett et al. | Applicant |
| US5297143(A) | 1994-03-01 | Fridrich et al. | Applicant |
| US5302952(A) | 1994-04-01 | Campbell, Jr. et al. | Applicant |
| US5303227(A) | 1994-04-01 | Herold et al. | Applicant |
| US5303375(A) | 1994-04-01 | Collins et al. | Applicant |
| US5303392(A) | 1994-04-01 | Carney et al. | Applicant |
| US5307346(A) | 1994-04-01 | Fieldhouse | Applicant |
| US5307372(A) | 1994-04-01 | Sawyer et al. | Applicant |
| US5307463(A) | 1994-04-01 | Hyatt et al. | Applicant |
| US5309556(A) | 1994-05-01 | Sismilich | Applicant |
| US5317726(A) | 1994-05-01 | Horst | Applicant |
| US5335221(A) | 1994-08-01 | Snowbarger et al. | Applicant |
| US5347181(A) | 1994-09-01 | Ashby et al. | Applicant |
| US5349343(A) | 1994-09-01 | Oliver | Applicant |
| US5352033(A) | 1994-10-01 | Gresham et al. | Applicant |
| US5359721(A) | 1994-10-01 | Kempf et al. | Applicant |
| US5371895(A) | 1994-12-01 | Bristol | Applicant |
| US5377315(A) | 1994-12-01 | Leggett | Applicant |
| US5381529(A) | 1995-01-01 | Matsushima | Applicant |
| US5384910(A) | 1995-01-01 | Torres | Applicant |
| US5390321(A) | 1995-02-01 | Proesel | Applicant |
| US5392389(A) | 1995-02-01 | Fleming | Applicant |
| US5394522(A) | 1995-02-01 | Sanchez-Frank et al. | Applicant |
| US5398331(A) | 1995-03-01 | Huang et al. | Applicant |
| US5400140(A) | 1995-03-01 | Johnston | Applicant |
| US5408603(A) | 1995-04-01 | Van de Lavoir et al. | Applicant |
| US5410717(A) | 1995-04-01 | Floro | Applicant |
| US5420977(A) | 1995-05-01 | Sztipanovits et al. | Applicant |
| US5426732(A) | 1995-06-01 | Boies et al. | Applicant |
| US5428734(A) | 1995-06-01 | Haynes et al. | Applicant |
| US5428781(A) | 1995-06-01 | Duault et al. | Applicant |
| US5432711(A) | 1995-07-01 | Jackson et al. | Applicant |
| US5434997(A) | 1995-07-01 | Laundry et al. | Applicant |
| US5437007(A) | 1995-07-01 | Bailey et al. | Applicant |
| US5444851(A) | 1995-08-01 | Woest | Applicant |
| US5450403(A) | 1995-09-01 | Ichii et al. | Applicant |
| US5450425(A) | 1995-09-01 | Gunn et al. | Applicant |
| US5450764(A) | 1995-09-01 | Johnston | Applicant |
| US5451939(A) | 1995-09-01 | Price | Applicant |
| US5452201(A) | 1995-09-01 | Pieronek et al. | Applicant |
| US5457797(A) | 1995-10-01 | Butterworth et al. | Applicant |
| US5459825(A) | 1995-10-01 | Anderson et al. | Applicant |
| US5459839(A) | 1995-10-01 | Swarts et al. | Applicant |
| US5461710(A) | 1995-10-01 | Bloomfield et al. | Applicant |
| US5463735(A) | 1995-10-01 | Pascucci et al. | Applicant |
| US5467264(A) | 1995-11-01 | Rauch et al. | Applicant |
| US5475856(A) | 1995-12-01 | Kogge | Applicant |
| US5481741(A) | 1996-01-01 | McKaskle et al. | Applicant |
| US5483660(A) | 1996-01-01 | Yishay et al. | Applicant |
| US5485620(A) | 1996-01-01 | Sadre et al. | Applicant |
| US5490276(A) | 1996-02-01 | Doli, Jr. et al. | Applicant |
| US5491791(A) | 1996-02-01 | Glowny et al. | Applicant |
| US5500934(A) | 1996-03-01 | Austin et al. | Applicant |
| US5504672(A) | 1996-04-01 | Hardiman et al. | Applicant |
| US5504902(A) | 1996-04-01 | McGrath et al. | Applicant |
| US5509811(A) | 1996-04-01 | Homic | Applicant |
| US5513095(A) | 1996-04-01 | Pajonk | Applicant |
| US5513192(A) | 1996-04-01 | Janku et al. | Applicant |
| US5513354(A) | 1996-04-01 | Dwork et al. | Applicant |
| US5517655(A) | 1996-05-01 | Collins et al. | Applicant |
| US5519605(A) | 1996-05-01 | Cawlfield | Applicant |
| US5519701(A) | 1996-05-01 | Colmant et al. | Applicant |
| US5522044(A) | 1996-05-01 | Pascucci et al. | Applicant |
| US5530643(A) | 1996-06-01 | Hodorowski | Applicant |
| US5539909(A) | 1996-07-01 | Tanaka et al. | Applicant |
| US5544008(A) | 1996-08-01 | Dimmick et al. | Applicant |
| US5549137(A) | 1996-08-01 | Lenz et al. | Applicant |
| US5550980(A) | 1996-08-01 | Pascucci et al. | Applicant |
| US5551047(A) | 1996-08-01 | Mori et al. | Applicant |
| US5555213(A) | 1996-09-01 | DeLong | Applicant |
| US5555437(A) | 1996-09-01 | Packer | Applicant |
| US5555510(A) | 1996-09-01 | Verseput et al. | Applicant |
| US5559691(A) | 1996-09-01 | Monta et al. | Applicant |
| US5559963(A) | 1996-09-01 | Gregg et al. | Applicant |
| US5566320(A) | 1996-10-01 | Hubert | Applicant |
| US5568378(A) | 1996-10-01 | Wojsznis | Applicant |
| US5572673(A) | 1996-11-01 | Shurts | Applicant |
| US5576946(A) | 1996-11-01 | Bender et al. | Applicant |
| US5579220(A) | 1996-11-01 | Barthel et al. | Applicant |
| US5579487(A) | 1996-11-01 | Meyerson et al. | Applicant |
| US5581760(A) | 1996-12-01 | Atkinson et al. | Applicant |
| US5586112(A) | 1996-12-01 | Tabata | Applicant |
| US5586329(A) | 1996-12-01 | Knudsen et al. | Applicant |
| US5586330(A) | 1996-12-01 | Knudsen et al. | Applicant |
| US5587899(A) | 1996-12-01 | Ho et al. | Applicant |
| US5594858(A) | 1997-01-01 | Blevins | Applicant |
| US5594899(A) | 1997-01-01 | Knudsen et al. | Applicant |
| US5596331(A) | 1997-01-01 | Bonaffini et al. | Applicant |
| US5596752(A) | 1997-01-01 | Knudsen et al. | Applicant |
| US5598536(A) | 1997-01-01 | Slaughter, III et al. | Applicant |
| US5600845(A) | 1997-02-01 | Gilson | Applicant |
| US5604871(A) | 1997-02-01 | Pecone | Applicant |
| US5611057(A) | 1997-03-01 | Pecone et al. | Applicant |
| US5613148(A) | 1997-03-01 | Bezviner et al. | Applicant |
| US5617540(A) | 1997-04-01 | Civanlar et al. | Applicant |
| US5621871(A) | 1997-04-01 | Jaremko et al. | Applicant |
| US5627979(A) | 1997-05-01 | Chang et al. | Applicant |
| US5629949(A) | 1997-05-01 | Zook | Applicant |
| US5630056(A) | 1997-05-01 | Horvath et al. | Applicant |
| US5630152(A) | 1997-05-01 | DeLuca et al. | Applicant |
| US5642511(A) | 1997-06-01 | Chow et al. | Applicant |
| US5649121(A) | 1997-07-01 | Budman et al. | Applicant |
| US5655092(A) | 1997-08-01 | Ojala | Applicant |
| US5659680(A) | 1997-08-01 | Cunningham et al. | Applicant |
| US5664101(A) | 1997-09-01 | Picache | Applicant |
| US5664168(A) | 1997-09-01 | Yishay et al. | Applicant |
| US5671374(A) | 1997-09-01 | Postman et al. | Applicant |
| US5676141(A) | 1997-10-01 | Hollub | Applicant |
| US5680404(A) | 1997-10-01 | Gray | Applicant |
| US5680409(A) | 1997-10-01 | Qin et al. | Applicant |
| US5682476(A) | 1997-10-01 | Tapperson et al. | Applicant |
| US5687316(A) | 1997-11-01 | Graziano et al. | Applicant |
| US5701414(A) | 1997-12-01 | Cheng et al. | Applicant |
| US5704011(A) | 1997-12-01 | Hansen et al. | Examiner |
| US5708779(A) | 1998-01-01 | Graziano et al. | Applicant |
| US5719761(A) | 1998-02-01 | Gatti et al. | Applicant |
| US5726912(A) | 1998-03-01 | Krall, Jr. et al. | Applicant |
| US5727128(A) | 1998-03-01 | Morrison | Applicant |
| US5732218(A) | 1998-03-01 | Bland et al. | Applicant |
| US5737529(A) | 1998-04-01 | Dolin, Jr. et al. | Applicant |
| US5742762(A) | 1998-04-01 | Scholl et al. | Applicant |
| US5748467(A) | 1998-05-01 | Qin et al. | Applicant |
| US5751574(A) | 1998-05-01 | Loebig | Applicant |
| US5752007(A) | 1998-05-01 | Morrison | Applicant |
| US5752008(A) | 1998-05-01 | Bowling | Applicant |
| US5752246(A) | 1998-05-01 | Rogers et al. | Applicant |
| US5754772(A) | 1998-05-01 | Leaf | Applicant |
| US5758073(A) | 1998-05-01 | Liang et al. | Applicant |
| US5758075(A) | 1998-05-01 | Graziano et al. | Applicant |
| US5761518(A) | 1998-06-01 | Boehling et al. | Applicant |
| US5764906(A) | 1998-06-01 | Edelstein et al. | Applicant |
| US5768119(A) | 1998-06-01 | Havekost et al. | Applicant |
| US5768510(A) | 1998-06-01 | Gish | Applicant |
| US5774670(A) | 1998-06-01 | Montulli | Applicant |
| US5777874(A) | 1998-07-01 | Flood et al. | Applicant |
| US5790791(A) | 1998-08-01 | Chong et al. | Applicant |
| US5793963(A) | 1998-08-01 | Tapperson et al. | Applicant |
| US5796602(A) | 1998-08-01 | Wellan et al. | Applicant |
| US5797038(A) | 1998-08-01 | Crawford et al. | Applicant |
| US5801770(A) | 1998-09-01 | Paff et al. | Applicant |
| US5801942(A) | 1998-09-01 | Nixon et al. | Applicant |
| US5805442(A) | 1998-09-01 | Crater et al. | Applicant |
| US5805922(A) | 1998-09-01 | Sim et al. | Applicant |
| US5822220(A) | 1998-10-01 | Baines | Applicant |
| US5828851(A) | 1998-10-01 | Nixon et al. | Applicant |
| US5831669(A) | 1998-11-01 | Adrain | Applicant |
| US5832418(A) | 1998-11-01 | Meyer | Applicant |
| US5838920(A) | 1998-11-01 | Rosborough | Applicant |
| US5841360(A) | 1998-11-01 | Binder | Applicant |
| US5841963(A) | 1998-11-01 | Nakamikawa et al. | Applicant |
| US5844601(A) | 1998-12-01 | McPheely et al. | Applicant |
| US5844804(A) | 1998-12-01 | Schussler | Examiner |
| US5847957(A) | 1998-12-01 | Cohen et al. | Applicant |
| US5854750(A) | 1998-12-01 | Phillips et al. | Examiner |
| US5854944(A) | 1998-12-01 | Catherwood et al. | Applicant |
| US5862052(A) | 1999-01-01 | Nixon et al. | Applicant |
| US5872992(A) | 1999-02-01 | Tietjen et al. | Applicant |
| US5873089(A) | 1999-02-01 | Regache | Applicant |
| US5874990(A) | 1999-02-01 | Kato | Applicant |
| US5880775(A) | 1999-03-01 | Ross | Applicant |
| US5909586(A) | 1999-06-01 | Anderson | Applicant |
| US5920479(A) | 1999-07-01 | Sojoodi et al. | Applicant |
| US5930768(A) | 1999-07-01 | Hooban | Applicant |
| US5956487(A) | 1999-09-01 | Venkatraman et al. | Applicant |
| US5975737(A) | 1999-11-01 | Crater et al. | Applicant |
| US5980078(A) | 1999-11-01 | Krivoshein et al. | Applicant |
| US5980090(A) | 1999-11-01 | Royal, Jr. et al. | Applicant |
| US5982362(A) | 1999-11-01 | Crater et al. | Applicant |
| US5994998(A) | 1999-11-01 | Fisher et al. | Applicant |
| US6002104(A) | 1999-12-01 | Hsu | Examiner |
| US6014591(A) | 2000-01-01 | Ikeda | Applicant |
| US6014612(A) | 2000-01-01 | Larson et al. | Applicant |
| US6026352(A) | 2000-02-01 | Burns et al. | Applicant |
| US6035264(A) | 2000-03-01 | Donaldson et al. | Applicant |
| US6049775(A) | 2000-04-01 | Gertner et al. | Applicant |
| US6055633(A) | 2000-04-01 | Schrier et al. | Applicant |
| US6061603(A) | 2000-05-01 | Papadopoulos et al. | Applicant |
| US6078320(A) | 2000-06-01 | Dove et al. | Applicant |
| US6085120(A) | 2000-07-01 | Schwerdtfeger et al. | Examiner |
| US6094600(A) | 2000-07-01 | Sharpe, Jr. et al. | Applicant |
| US6115468(A) | 2000-09-01 | De Nicolo | Applicant |
| US6139177(A) | 2000-10-01 | Venkatraman et al. | Applicant |
| US6140911(A) | 2000-10-01 | Fisher et al. | Applicant |
| US6151625(A) | 2000-11-01 | Swales et al. | Applicant |
| US6176421(B1) | 2001-01-01 | Royal, Jr. et al. | Applicant |
| US6195694(B1) | 2001-02-01 | Chen et al. | Examiner |
| US6195774(B1) | 2001-02-01 | Jacobson | Examiner |
| US6201996(B1) | 2001-03-01 | Crater et al. | Applicant |
| US6218930(B1) | 2001-04-01 | Katzenberg et al. | Applicant |
| US6260187(B1) | 2001-07-01 | Cirne | Examiner |
| US6272556(B1) | 2001-08-01 | Gish | Examiner |
| EP411869 | 1990-07-01 | Applicant | |
| WO95/04314 | 1995-02-01 | Applicant | |
| WO96/31047 | 1996-03-01 | Applicant | |
| WO96/23377 | 1996-08-01 | Applicant | |
| WO97/07486 | 1997-02-01 | Applicant | |
| WO98/20649 | 1998-05-01 | Applicant | |
| WO98/36518 | 1998-08-01 | Applicant | |
| WO98/54843 | 1998-12-01 | Applicant |
Non-Patent Literature (106)
- “Apacs Control System,” POWER vol. 139, No. 6 (Jun. 1995) p. 81 (Dialog print-out).Applicant
- Beestermoller, H.J. et al. “An online and offline programmable Multi-Loop Controller for Distributed Systems,” IEEE (1994) pp. 15-20.Applicant
- “Control system,” POWER vol. 139, No. 4 (Apr. 1995) p. 114 (Dialog print-out).Applicant
- Duffey, C.K. et al. “High-Level Control Language Customizes Application Programs,” IEEE (Apr. 1991) pp. 15-18.Applicant
- Gyorki, John R. “PLCs drive standard buses,” Machine Design (May 11, 1995) pp. 83-90.Applicant
- “New Telemacanique Programmable Controllers Feature Multiple Programming Languages,” (Feb. 11, 1985) (Dialog print-out).Applicant
- Peshek, Clifford J. and Mellish, Michael T. “Recent Developments and Future Trends in PLC Programming Languages and Programming Tools for Real-Time Control,” IEEE Cement Industry Technical Conference (May 1993) Toronto, Canada pp. 219-230.Applicant
- Stapleton, N. “802.3 Working Group DTE Power via MDI Call for interest,” 3Com Jul. 1999.Applicant
- Berge, Jonas. “Using Ethernet is a no-brainer,” InTech: The International Journal for Measurement and Control Jul. 2000, pp. 36-39.Applicant
- Stevens, et al. “TCP/IP Illustrated, vol. 1. The Protocols,” TCP/IP Illustrated vol. 1, XP-002106390, pp. 85-96.Applicant
- ICCard Design Sep./Oct. 1995.Applicant
- Strack, Bob. “The HAWK is Soaring,” Chemical Processing (May 1996) p. 11.Applicant
- “Control System Features Plug-and-Play Technology, Scalability,” Chemical Processing (May 1996), p. 33.Applicant
- “Editors' Product Picks,” Chemical Processing (May 1996), p. 34.Applicant
- “Tribe Computer Works' Net Products Can be Managed via World Wide Web,” IAC (SM) Newsletter Database™, DataTrends Publications, Inc., No. 11, vol. 7, May 30, 1995.Applicant
- “Briefs,” Network World, May 29, 1995, p. 19.Applicant
- Wilder, Clinton, “Network Management; Fussing Nets Via The Web—Tribe's WebManage uses popular interface,” InformationWeek, May 29, 1995, p. 62.Applicant
- “Pipeline; Announced,” InfoWorld, May 29, 1995, p. 45.Applicant
- Bernard, Viki, “Remote-access ware emerge; Shiva, Nortel, and Tribe leading list of innovators,” PCWeek, No. 21, vol. 12, May 29, 1995, p. 47.Applicant
- “Tribe Announces Revolutionary Use of the Internet; Launches Innovative Remote Management Solution; New WebManage Technology Provides Network Management via World Wide Web,” Business Wire, May 22, 1995.Applicant
- “Tribe Launches First Networking Device Capable of Being Managed via Internet Web Browser; TribeLine2 Enables Remote Computing and Internet Access,” Business Wire, May 22, 1995.Applicant
- Dryden, Patrick, “Tribes WebManage Enables Remote Fixes,” ComputerWorld, May 22, 1995, p. 14.Applicant
- Ko, Diffu, “Trobe defines net management role for Web browser software,” Network World, May 22, 1995, p. 14.Applicant
- “Tour an actual TribeLink via WebManage,” web page print-out from http://www.tribe.com/products/webmanage/quick_view.htm. (1 page).Applicant
- “Tribe Launches Innovative Remote Management Solution; New WebManage Technology Provides Network Management Via the World Wide Web,” web page print-out (Jul. 12, 1999) from http://www.tribe.com/products/webmanage/wm_pr. (1 page).Applicant
- “TribeRoute,” web page print-out (Jul. 12, 1999) from http://www.tribe.com/products/tr/index. (3 pages).Applicant
- “TribeStar,” web page print-out from http://www.tribe.com/products/tribestar/index.htm (3 pages).Applicant
- Pappalardo, Denise, “Router Can Be Managed via Net,” Internet Week, May 22, 1995, p. 6.Applicant
- Rodriguez, Karen, “Tribe sets software,” Interactive Age, vol. 2, No. 15, May 22, 1995, p. 25.Applicant
- Welch, Nathalie, “Tribe to manage via Web; Tribe Computer Works Inc.'s TribeLink2 Product Announcement,” MacWEEK, vol. 9, No. 21, May 22, 1995, p. 18.Applicant
- Pappalardo, Denise, “Digi Introduces IP/IPX Router,” InternetWeek, Apr. 24, 1995, p. 15.Applicant
- “WWWF'94: Papers Received,” web page print-out (Apr. 7, 2000) from http://www.ncsa.uiuc.edu/SDG/IT94/Agenda/Papers-received html (8 pages).Applicant
- Elmer-Dewitt, Philip, “Snowballs in Cyberspace; With a modem and a soldering iron, you too can build an internet site that is really cool and totally useless,” Time, Jan. 16, 1995, p. 57.Applicant
- Scharf, Ronald, et al, “Using Mosaic for Remote Test System Control Supports Distributed Engineering,” Institute of Computer-Aided Circuit Design—Test and Testsystems Division, University of Erlangen-Nurnberg, Germany, web page printout from http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/CSCW/scharf.html (8 pages).Applicant
- Cox, Mark J. and Baruch, Dr. John E. F. “Robotic Telescopes: An Interactive Exhibit on the World-Wide Web,” web page print-out from http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Museum/cox/marcox.html (11 pages).Applicant
- Gleick, James. “Fast Forward; Really Remote Control,” The New York Times, Section 6, Column 3, p. 42, Dec. 3, 1995.Applicant
- Silverman, Dwight. “‘Attaboy’ for the best software and hardware of 1994,” The Houston Chronicle, Dec. 25, 1994, p. 2.Applicant
- Browne, Malcolme W. “South Pole Ready for Internet Revolution,” The New York Times, Section C, Column 1, p. 1, Jan. 10, 1995.Applicant
- Wolfe, Alexander, “Strong Brew,” Electronic Engineering Times, Apr. 8, 1996, p. 73.Applicant
- “Special Topic: PC-Based Control,” A Supplement to Software Strategies, pp. 3-5, 7-8, 10-15, 20-21.Applicant
- Momal, F. and Pinto-Pereira, C. “Using World-Wide-Web for Control Systems,” from Proceedings 1995 International Conference on Accelerator and Large Experimental Physics Control Systems, Chicago, IL, Oct. 30-Nov. 3, 1995.Applicant
- “The ‘Only’ Coke Machine on the Internet,” web page print-out (Feb. 12, 1999) from http://www.cs.cmu.edu/˜coke/history_long.txt (3 pages).Applicant
- “CMU SCS Coke Machine: Current Status,” web page print-out (Feb. 12, 1999) from http://www.cs.cmu.edu/˜coke/ (1 page).Applicant
- “The Switzerland Coke Machine Credits,” web page print-out (Feb. 12, 1999) from http://www-swiss.ai.mit.edu/htbin/coke/ (1 page).Applicant
- “Peter Beebee's Home Page,” web page print-out (Feb. 12, 1999) from http://www-swiss.ai.mit.edu/htbin/ptbbgate/jwz/?fetch+personal%2Fmain.text.html (2 pages).Applicant
- “bsy's List of Internet Accessible Coke Machines,” web page print-out (Feb. 12, 1999) from http://www-cse.ucsd.edu/users/bsy/coke.html (1 page).Applicant
- “Disk Drive with Embedded Hyper-Text Markup Language Server,” IBM TDB, vol. 38, n. 12, Dec. 1995, pp. 479-480.Applicant
- Leon, Mark, “Tektronix to add Web software on new printers,” InfoWorld, Dec. 4, 1995, p. 6.Applicant
- “I/A Series Model 51 FoxRemote II Installation and Configuration Guide,” Apr. 8, 1998 (Preliminary), pp. i-iv, 1-2.Applicant
- “New State-Logic Microcontroller,” News Release, Control Technology Corp., Jun. 1, 1996, (DialogWeb search result).Applicant
- “NEW at IPC/92! Ethernet link provides Global PLC Registers,” News Release, Control Technology (US), Nov. 20, 1992, (DialogWeb search result).Applicant
- “NEW at IPC/92! High-Capacity Integrated Motion Controller,” News Release, Control Technology (US) Nov. 20, 1992, (DialogWeb search result).Applicant
- “Dual-Axis Servo Module for Small Controller,” News Release, Control Technology (US), Sep. 11, 1990, (DialogWeb search result).Applicant
- “Innovative Small Controller Family offers Full Integration,” News Release, Control Technology, Aug. 17, 1989, (DialogWeb search result).Applicant
- AC I/O Modules Available for Low-Cost Automation Controller, News Release, Control Technology Corporation, Jun. 28, 1989, (DialogWeb search result).Applicant
- “New Small Automation Controller features Precision Analog I/O Modules,” News Release, Control Technology (US), May 30, 1989, (DialogWeb search result).Applicant
- “Inexpensive Automation Controller features Message Display Capability,” News Release, Control Technology (US), May 19, 1989, (DialogWeb search result).Applicant
- “Small Multi-Tasking Controller for Cost-sensitive Applications,” News Release, Control Technology US, Nov. 8, 1988, (DialogWeb search result).Applicant
- “CAD/CAM Software creates Automation ‘Programming Environment’,” News Release, Control Technology (US), Oct. 3, 1988, (DialogWeb search result).Applicant
- “Automation Programming Environment runs On IBM (R)—PC,” News Release, Control Technology (US), Mar. 29, 1988, (DialogWeb search result).Applicant
- “Low-Cost Automation Controller features Motion Control, Communications,” News Release, Control Technology (US), Mar. 7, 1988, (DialogWeb search result).Applicant
- “System Provides Stepping Motor Control in Workcell Environment,” News Release, Control Technology Corp., Dec. 5, 1986, (DialogWeb search result).Applicant
- “Multi-Tasking Controller provides High-level Instructions for Motion Control, Sequencing,” News Release, Control Technology Corporation, Aug. 22, 1986, (DialogWeb search result).Applicant
- “Operator's Console creates ‘Friendly’ Machines,” News Release, Control Technology (US), May 9, 1986, (DialogWeb search result).Applicant
- “Automation Controller features fast 80186 Processor, Integrated Software,” News Release, Control Technology (US), Apr. 22, 1986, (DialogWeb search result).Applicant
- “Plug-Compatible Controls and Actuators Speed System Development,” News Release, Control Technology (US), Jan. 12, 1986, (DialogWeb search result).Applicant
- “Modular Valve Assemblies Connect to Controller with Ribbon Cable,” New Product Release, Control Technology (US), Jan. 8, 1986, (DialogWeb search result).Applicant
- “Linear Actuators offer Plug-Compatibility with Controller,” News Release, Control Technology (US), Nov. 21, 1985, (DialogWeb search result).Applicant
- “Compact System combines Motion Control, Machine Control,” News Release, Control Technology, May 28, 1985, (DialogWeb search result).Applicant
- “Automation Controller accepts Customization,” News Release, Control Technology, Jul. 12, 1985, (DialogWeb search result).Applicant
- “SECS-11 Communication Board Plugs into Automation Controller,” News Release, Control Technology, Aug. 26, 1985, (DialogWeb search result).Applicant
- “Operator's Console for Automated Machines,” News Release, Control Technology, Aug. 15, 1985, (DialogWeb search result).Applicant
- “Programmable Controller offers control of Stepping and Servo Motors,” News Release, Control Technology, May 31, 1985, (DialogWeb search result).Applicant
- Taylor, Ken and Trevelyan, James, “A Telerobot on the World Wide Web,” printed from http://telerobot.mech.uwa.edu.au/ROBOT/telerobo.htm (14 pages).Applicant
- “On-Line Vending Machine and Catalog Product Icons,” IBM TDB, v. 38, n. 4 (Apr. 1995), pp. 113-116.Applicant
- Tinham, Brian, “Getting SCADA by web browsner? Supervisory Control and Data Acquisition,” Control and Instrumentation, No. 12, vol. 28, Dec. 1995, p. 5.Applicant
- “Wizards wheel over SCADA systems; Supervisory Control and Data Acquisition,” Control and Instrumentation, No. 12, vol. 28, Dec. 1996, p. 23.Applicant
- Fulcher, Jim and Dilger, Karen Abramic, “Soft control, Internet spark ISA/96,” Manufacturing Systems, vol. 14, No. 12, Dec. 1996, p. 40-46.Applicant
- “Information technology in manufacturing,” Manufacturing Systems, vol. 14, No. 12, Dec. 1996, pp. 54-78.Applicant
- “A sensation in supervisory control,” Manufacturing Systems, (Windows NT in manufacturing Supplement), Oct. 1996, pp. 12A-24A.Applicant
- Demetratekes, Pam. “Go with the info flow; state-of-the-art automation in the food industry; includes related article on computer software for food processors,” Food Processing, vol. 57, No. 7, Jul. 1996, P. 47.Applicant
- “New Products Provide Interactive Graphics Over Web Using Netscape Plug-Ins and Java,” PR Newswire, May 20, 1996.Applicant
- “Integrated Systems; Industry's top embedded operating software supports Java,” M2 Presswire, Mar. 4, 1996.Applicant
- “ErgoTech upgrades ErgoCim; First ‘plug and play’ component software for manufacturing,” Business Wire, Feb. 15, 1996.Applicant
- “Embedded Systems Conference Addresses the Increasing Complexity of Electronic Systems Design; Technical Program and Exhibits Help Embedded Systems Design Professionals Keep Pace with Rapid Change,” PR Newswire, Dec. 27, 1995.Applicant
- “Industry's top embedded operating software supports Java; pSOSystem enables Embedded Internet applications and Low-cost Internet appliances,” Business Wire, Feb. 1, 1996.Applicant
- “Gensym introduces G2 WebMiner for accessing and reasoning about data from the World Wide Web,” Business Wire, May 15, 1996.Applicant
- “Gensym introduces Internet connectivity for its G2 family of intelligent real-time software,” Business Wire, Mar. 18, 1996.Applicant
- “Gensym Announces Its Initiative for Leveraging Intelligent Systems with Internet/Intranet Technology,” Business Wire, Oct. 7, 1997.Applicant
- “At Interop, Will ToasterNet Be on the Hot List?” Data Communications, vol. 19, No. 13, Oct. 1990, p. 214.Applicant
- Zeff, Joe. “Maui Sunset in Real Time (Modems not Optional),” The New York Times, Nov. 27, 1995, Section D, Column 2, p. 5.Applicant
- Toner, Mike. “Web's view of world far and wide,” The Houston Chronicle, Nov. 5, 1995, p. 6.Applicant
- “Internet windows to the world,” New Media Age, Oct. 26, 1995, p. 4.Applicant
- Foster, Kirsten. “surf's up; lights, camera, but no action; Steve is a Tech-Nomad. He wanders the streets with a camera on his head. And he wants you to join him,” The Independent (London), Aug. 13, 1995, p. 10.Applicant
- Henry, Jim, Ph.D., P.E. “Implementation of Practical Control Systems: Problems and Solutions,” web page print-out from http://chem.engr.utc.edu/Documents/MACSCITECH/MACSCITECHpaper1.html (22 pages).Applicant
- “Jim Henry's 1996 ASEE Paper,” web page print-out from http://chem.engr.utc.edu/Documents/ASEE-96-full.html (5 pages).Applicant
- Henry, Jim, Ph.D., P.E. “LabVIEW Applications in Engineering Labs: Controls, Chemical, Environmental,” ASEE Conference, Anaheim, CA, Jun. 25-28, 1995, web page print-out from http://chem.engr.utc.edu/Documents/ASEE-95-full.html (22 pages).Applicant
- “Breaking News for Invensys Software Systems Employees; iBaan and FactorySuite 2000 Integration Announced,” internal e-mail dated Mar. 23, 2001.Applicant
- Gertz, Matthew, et al. “A Human—Machine Interface for Distributed Virtual Laboratories,” IEEE Robotics & Automation Magazine 1 (1994) Dec., No. 4 (New York) pp. 5-13.Applicant
- Soreide, N. N., et al. “Mosaic access to real-time data from the TOGA-TAO array of moored buoys,” Computer Networks and ISDN Systems 28 (1995), pp. 189-197.Applicant
- Goldstein, Ira and Hardin, Joseph. “Guest editorial,” Computer Networks and ISDN Systems 28 (1995) p. 1.Applicant
- Slater, A. F. “Controlled by the Web,” Computer Networks and ISDN Systems 27 (1994) pp. 289-295.Applicant
- Goldberg, Ken, et al. “Beyond the Web: manipulating the real world,” Computer Networks and ISDN Systems 28 (1995) pp. 209-219.Applicant
- Goldstein, Ira and Hardin, Joseph, “Guest editorial,” Computer Networks and ISDN Systems 28 (1995) p. 1.Applicant
- Goldberg, Ken, et al. “Desktop Teleoperation via the World Wide Web,” IEEE International Conference on Robotics and Automation, pp. 654-659.Applicant
- Redman, Jim, et al. “The Intranet and the Internal Web Server: A Standard User Interface for Integrating Manufacturing Applications,” Proceedings of the Industrial Computing Conference Inst. Society of American, vol. 6, No. 1, 1996, pp. 193-202.Applicant