Object-Oriented Programmable Controller

The present invention relates to industrial automation, and in particular to programmable controllers for operating and monitoring industrial processes and equipment.

Sophisticated industrial processes, such as oil refining, automobile assembly or power generation, require the cooperative execution of numerous interdependent tasks by many different pieces of equipment. The enormous complexity of ensuring proper task sequencing and management, which requires not only appropriate logic but constant monitoring of equipment states to organize and distribute operations and detect malfunction, has resulted in the widespread adoption of programmable controllers. These controllers operate elaborate industrial equipment in accordance with a stored control program. When executed, the program causes the controller to examine the state of the controlled machinery by evaluating signals from one or more sensing devices (e.g., temperature or pressure sensors), and to operate the machinery (e.g., by energizing or deenergizing operative components) based on a logical framework, the sensor signals and, if necessary, more complex processing. The "inputs" to a particular controller can extend beyond the sensed state of the equipment the controller directly operates to include, for example, its environment, the state of related machinery or the state of its controllers.

The instructions governing operation of the controller can be organized in different ways. Regardless of the manner in which they are expressed, however, the instructions must ultimately embody the operation of the controlled equipment in order for the controller to perform its function correctly. Modern industrial controllers, therefore, frequently utilize "state-based" control sequences implemented by a user-programmable state language (such as the QUICKSTEP.TM. programming language supplied by Control Technology Corporation, Hopkinton, Mass.). State languages are organized by defining control "steps," each of which consists of executable commands that create action, and one or more executable instructions for leaving the step. For example, a step might initiate machine action, then wait for confirmation (e.g., an electronic signal from the controlled machine) that the action has been completed before progressing to the next step, which initiates another machine action. In moving from step to step, action to action, the control program mimics the ordered, sequential nature of most automated machines. Reducing the conceptual distance between operation of the machine and the structure of the control language frees the programmer to focus on the machine being controlled rather than the needs of the control language.

Nonetheless, procedural state languages still suffer from the disadvantages affecting all procedural languages: functions and routines that are repeated must be programmed repeatedly, raising the prospect of error and, as the program becomes complex, obscuring its overall operation by the welter of detail. Furthermore, the frequently intricate, interdependent nature of industrial equipment can render a simple step-by-step procedural framework inadequate for controlling processes with reliability. The controller must be provided with (and its programming must accommodate) routines for handling "exceptions" ranging from sluggish component operation to complete failure of vulnerable components. These routines may take the form of diagnostic or "exception-handling" procedures. As branches from the primary control sequence, such routines further complicate programming in procedural systems.

The present invention offers a more sophisticated yet conceptually simpler paradigm for representing machine operation at the control level, and for programming control systems capable of directing the operation of complex industrial equipment and/or processes. In particular, the invention utilizes an object-oriented framework to "encapsulate" functions, attributes, and procedures, incorporating these within objects representing the entities most naturally associated with the encapsulated items. In this way, those items are established only once and utilized as necessary. An object may correspond to a part of a machine, to the machine itself, or to a class of machines; hierarchically superior (and conceptually more general objects) may be defined so as to be composed of "instances" of subordinate objects. For example, a "machine" object would contain procedures defining machine operations that the associated controller effectuates, as well as information facilitating orderly and reliable execution of those procedures.

In an object-oriented system, closely related data and procedures are treated as a single entity rather than separately. This is achieved by means of an object manager, which includes a database system to manage and organize the data corresponding to these entities or "objects." Design and implementation of object managers is well-known in the art. Basically, an object is a data structure and a set of operations and functions that can access that data structure. The data structure may, for example, be represented as a "frame" having a plurality of "slots," each of which contains an "attribute" of the frame. Each computational operation (a function, procedure, etc.) that can access the data structure is typically called a "method" or an "action."

The database contains a series of pointers associating each object with the methods and attributes (hereafter "object items") making up the object; those items may be stored anywhere--in volatile memory, on a mass-storage device, or even on a separate machine connected via a network interface. By organizing the object items, the database effectively permits each object to carry its own structure and orchestrate its own behavior. This permits the object frame to be "encapsulated" within the object methods; that is, access to the frame is handled primarily or exclusively by the surrounding methods, thereby ensuring data independence. Furthermore, because only the associated methods access the internal data structure, data integrity is maintained.

The object-oriented system of the present invention can be a prototyping system, where objects may be selected from pre-programmed libraries of object templates. For example, if objects corresponding to different robot-arm devices contain much the same information (i.e., the information common to all robot arms is substantial), the library of available object templates contains a "robot arm" prototype that the programmer selects, customizing its attributes to suit the particular device the object is intended to represent.

Alternatively, the system of the present invention can support the property of inheritance, whereby properties or attributes of hierarchically superior objects are automatically inherited by hierarchically subordinate objects. This is accomplished by organizing the objects into hierarchical classes within the database, each class representing the template for a set of similar (in the sense of sharing structure and behavior) objects. Thus, objects in a subclass automatically acquire the object items (e.g., the frames and methods) associated with superior objects. To add a new machine of a particular class to an equipment assemblage, for example, the programmer creates an instance of the class, which automatically inherits all of the object items associated the that class, and then adds programming specific to the particular machine. Consequently, if the machine is a new robot arm added to an assembly line, the new object will already contain procedures for extension and retraction; the programmer then adds routines governing the operation of this particular arm and its relationship to other machines in the assembly line.

Hierarchical relationships among objects are not limited to inheritance and class. In addition, objects can be related to one another based on a hierarchical ranking, with higher-tier "parent" objects having pointers to lower-tier "children" objects. As a result, higher-tier objects may behave as if they "contain" hierarchically related, lower-tier objects for purposes of operation or system organization.

Objects can also delegate tasks to one another. For example, an object may not contain programming to perform a particular method, but instead hold a pointer to another object's method appropriate to the requested task.

Actions are performed on an object, or the entities represented by an object caused to perform an action, by invoking one or more of the encapsulated methods of the object that determine its behavior. A high-level routine requests an object to perform one of its methods by "sending a message" to the object, in effect telling the object what to do. Messages therefore perform a task similar to that of function or procedure calls, and can contain arguments that are acted upon by the method. The receiving object responds to the message by choosing the method that implements the message, executing this method and then returning control to the high-level routine, along with the results of the method.

Again, returning to the robot-arm example, a program step requiring actuation of the arm might, in a procedural language, be represented as a series of instructions turning on a solenoid valve and monitoring the progress of arm extension. In accordance with the present invention, the robot-arm object is told to perform its "extend.sub.-- arm" method; the procedural logic required to execute the action is already associated with the object, so the object effectively "knows" how to extend the arm.

Accordingly, the invention comprises a framework for control of complex systems. In one aspect, the invention generally comprises a controller for one or more pieces of industrial equipment, the controller being configured to perform a series of control functions each organized into one or more procedures for performing particular machine actions. The progress of an action, or some parameter of the action-taking machine (which may or may not be associated with an action), is represented by one or more "states." An object manager associates entries corresponding to the items of an object (including the action(s) and the state(s)), and contains storage locations where the associated procedural instructions and/or data are to be found. The action can be independent of state information, or can instead be executed in a manner responsive to a sensed state.

Beyond actions and states, objects can also contain items including (i) a list of the "resources" of the object, i.e., the various I/O points, registers, flags, other objects, etc. by means of which actions are effected and states determined; (ii) diagnostic procedures and/or templates (which may be associated with actions or remain separately callable) that evaluate performance of the action against pre-determined criteria and take specified actions if performance deviates from an acceptable range; and (iii) metrics, dynamically updated as the object executes (that is, as the controlled machine runs), which maintain historical and statistical data concerning machine performance.

For example, a diagnostic template may provide multiple, specified, discrete time spans each reflecting a different machine condition, each condition specifying an action associated therewith. If the controlled machine processes a workpiece, early confirmation of action completion may indicate that the machine is not loading properly, while excessive times to completion may signal a jam. Alternatively or in addition, the template may accommodate a range of possible input values (e.g., a control signal whose magnitude indicates the level of a continuously variable parameter such as tank pressure), specifying a different action associated with different input levels. These condition-indicating variables are herein referred to as "limit parameters."

The actions specified in the template entries might include, for example, issuing an alarm, adding the input value or time to a list for contemporaneous or subsequent review by the system operator, updating a display, branching to a failure-recovery sequence, or continuing the present state or process; the absence of an action (e.g., if the input value or time falls within the normal working range specified in the template) allows the controller simply to proceed with program execution. Each template entry, representing a different machine condition (e.g., normal operation and varying degrees of deviation), may be associated with a different action or with no action at all.

More generally, in accordance with the object-oriented approach of the present invention, actions are invoked as tasks initially processed by the object manager, which actually locates the object-bound actions. Typically, a message designates a particular action of an object rather than the object itself. The messages originate either with the high-level control program, which governs operation of a particular machine or set of machines by appropriate messages; or with the executing method of another object.

For example, a series of objects might each control a different component of a single machine. The high-level program dictates overall machine operation, invoking object procedures as necessary for proper control of the different machine components. Alternatively, the overall machine may be only one of several such machines on a factory floor, each machine being represented by an object (and the machine components by objects hierarchically subordinate to the machine objects), with the high-level control program orchestrating operation of the entire assemblage of machines. In this case, procedures of the machine-component objects are called by the machine objects, while procedures of the machine objects are called by the high-level control program.

Thus, in another aspect, the invention comprises a programming facility for a controller. The object representation is provided as a means of simplifying the task of programming the behavior of the controller and, ultimately, that of the controlled equipment. Encapsulating the characteristics, capabilities and functionality of a controlled machine as an object (in the form of actions, states, resources, diagnostics and metrics) provides the programmer with access to information not directly available in more traditional programming representations, and also reduces the complexity of the programming task by "packaging" standard components of functionality.

Consistent with these objectives, the actual programming implementation of the invention can take several forms. On one hand, the objects can be used simply as programming aids that exist only at programming time, disappearing at compile time: that is, a compiler (or interpreter) translates the high-level program, all invoked actions, and other object components that directly participate in controller operation into executable machine code. At the other extreme, the objects retain their complete existence as the program executes. For example, the high-level code might be compiled, while actions are processed by the object manager and retrieved from the object database at run time; in other words, the object items do not become incorporated into a static stream executable code, but are remain as table data accessed as the program executes. In the preferred approach, object items are, in fact, compiled at least partly into executable code, but also remain accessible to the programmer for inspection or alteration. By requiring, for example, run-time lookup of state parameters, diagnostics and metrics, the programmer retains the ability to modify controller behavior by making appropriate changes to the object items (and without directly altering executable code).

The foregoing discussion will be understood more readily from the following detailed description of the invention, when taken in conjunction with the accompanying drawings, in which:

FIG. 1 schematically depicts a control system in accordance with the present invention;

FIG. 2 schematically illustrates the object-management features of the present invention in greater detail; and

FIGS. 3A-3E graphically depict of a user interface suitable for data entry into a database in accordance with the invention.

Refer first to FIG. 1, which illustrates generally a hardware architecture for a system embodying the invention. A representative control system, indicated generally at 100, executes program instructions to operate, for example, a piece of industrial equipment. The system 100 includes a central processing unit ("CPU") 112 and one or more computer storage devices indicated generally at 114, 116. Ordinarily, storage device 114 provides nonvolatile mass storage, and may be, for example, an EEPROM, Flash ROM, hard disk or CD-ROM drive; and storage 116 comprises a combination of volatile random-access memory ("RAM") for temporary storage and processing, and non-volatile, programmable read-only memory ("PROM") that contains permanent aspects of the system's operating instructions.

CPU 112 and computer storage 114, 116 communicate over an internal system bus 118. The system 100 further includes a series of input/output (I/O) modules shown representatively at 120.sub.1, 120.sub.2 that sense the condition of, and send control signals to, the controlled machine over a machine interface (indicated by arrows). This machine interface, which may involve direct wiring or include a communication link for interaction over a computer network or telephone lines, facilitates the bidirectional exchange of signals between each I/O module and an associated device (e.g., a sensor or an actuator). I/O modules 120 connect to a secondary I/O bus 122, which is driven by a bus transceiver 124; in effect, buses 118, 122 and bus transceiver 124 form a single logical bus.

For simplicity, system 100 is illustrated at a sufficient level of generality to encompass implementations combining both programming and control capabilities, as well as less elaborate controllers whose programming is generated on an external computer and loaded into the controller 100 (e.g., through insertion of a nonvolatile storage medium, over a computer network or serial line, over the Internet, etc.) Thus, the system 100 also comprises one or more input devices 130, also connected to I/O bus 122, that permit the operator to program the controller and/or enter information. The output of either device can be used to designate information or to select particular areas of a screen display 132. In implementations providing complete programming capability, input devices 130 may include a keyboard and a position-sensing device such as a mouse. In implementations providing only control functions, a less extensive input/display system--such as an operator touch screen serving as both input and display device--may be preferred.

Storage 116 contains a series of functional blocks or modules that implement the functions performed by system 100 through operation of CPU 112. A control block 140 contains computer-executable instructions for actually operating controlled equipment via I/O modules 120, and a database organization implementing the object-oriented approach of the present invention. The contents of control block 140 are discussed in greater detail below. For now, it suffices to note that control block 140 contains both the specific high-level instructions for operating the system 100 and the compiler (or interpreter) module for translating these into instructions processed by CPU 112; its operative relationship to I/O modules 120 is indicated by the dashed line. Control block 140 also interacts with a data partition 145, which includes memory cells or blocks serving as registers (for storing particular quantitive values) and flags (to indicate binary status information).

Storage 116 may also include an operating system 150, which directs the execution of low-level, basic system functions such as memory allocation, file management and operation of storage device 114; and instructions defining a user interface 155, which facilitates straightforward interaction over screen display 132. User interface 155 generates words or graphical images on display 132 to represent a simulation, prompt action by the operator, and accept operator commands from input device 130.

Refer now to FIG. 2, which illustrates the organization of control block 140 in greater detail. Again for purposes of simplicity, the more elaborate type of system offering both programming and controller functionality is illustrated. A programming interface 200, which communicates with the programmer via user interface 155, allows the programmer to enter instructions (including invocations of object actions) that collectively form the high-level control routine 205; and to define object items and enter data and/or programming functionality into these. In particular, programming interface 200 provides the programmer with the object views described below; information entered by the programmer is organized into a series of objects representatively indicated 210.sub.1, 210.sub.2 by an object manager and database 215.

Each object 210 comprises one or more actions defining a control procedure--that is, an action associated with a control function--and a series of frames characterizing the object. An "action" is a step or series of steps performed on the controlled machine (connected to controller 100 by means of I/O modules 120), and is represented by a series of executable instructions defining the action. The steps may directly execute a control function, or may instead bear on that function only indirectly; for example, one action might implement the control function, and another implement a recovery routine should the control function fail.

Object manager 215 maintains organizational control over the objects themselves, which are generally stored in a database format, associating the various frames and methods of each object with the object name by means of pointers (thereby encapsulating the frames of an object within the associated methods, as described above). This form of organization allows both frames and methods to be specified (programmed) once but used repeatedly, since different objects can contain pointers to the same method, while nonetheless retaining integrity as independent objects. If the implementation of the invention supports heritability, object database 215 enforces this property as well.

As will become clear, because of the availability of encapsulated procedures, the high-level control instructions of the present invention are not only less lengthy than those of traditional programmable controllers, but more general as well; the programmer is freed from repeating the low-level commands that define specific control operations (since these are stored in the objects), and need only specify the desired operations themselves. In other words, the programmer need only invoke objects, rather than reproducing the methods they include. Moreover, the methods can be self-operative in the sense of reacting to observed conditions without explicitly being invoked by the programmer.

The control routine 205 is translated into machine-executable instructions by a compiler 220, resulting in a run-time control program 225 (which may be stored in memory 116 or, more typically, in nonvolatile storage 114). As stated earlier, the preferred instructional paradigm for control routine 205 is a state-control language that represents controller actions in terms of steps, each of which consists of a command that creates action and one or more instructions for leaving the step. Interpreters and compilers for this and other types of controller languages are well characterized in the art. See, e.g., U.S. Pat. Nos. 5,321,829 and 5,287,548 (the entire disclosures of which are hereby incorporated by reference) and the QUICKSTEP.TM. User Guide published by Control Technology Corporation, Hopkinton, Mass.

In one embodiment, compiler 220 accepts not only the control routine 205, but also the various object items specified in the control routine and necessary to its operation. These items are obtained via object manager 215 and compiled along with control routine 205 into run-time program 225. For example, the final run-time program 225 may explicitly contain the executable instructions comprising the actions and state definitions contained in all objects 210 relevant to the control routine 205.

In the preferred embodiment, however, at least some of the object items are not compiled, i.e., remain as table data accessed by run-time control program 225 in the course of its execution. In this case, the instructions of program 225 and the object actions they invoke, are compiled; but the other object items are read in rapid sequence from the object database as run-time program 225 executes. The run-time instructions cause system 100 to examine the condition of selected sensing devices associated with controlled equipment, and, based thereon, to send appropriate operative control signals to the equipment via I/O modules 120.

More specifically, a performance engine 230 implements the control actions specified by the run-time control program 225 through manipulation of the controlled machine at I/O points accessed through I/O modules 120. A monitoring engine 235 receives or accesses data relevant to the action under execution. The data can originate in the controlled machine itself (and be received via an I/O module 120) or within the controller 100, or some combination thereof. For example, the progress of the action may be monitored through a first control point; the temperature of the controlled machine (which must remain within an operating range in order to continue performance of the action) may be monitored through a second control point; the time to completion of the action may be maintained by the controller itself and stored in an internal register; and an internal flag may indicate the completion of a prior, predicate action. These I/O and internal sources of data, which may be queried by monitoring engine 235, are referred to as "resources." Monitoring engine 235 is configured to establish, via I/O modules 120, the control connections necessary to access the listed resources. It should be stressed that, depending on the application, monitoring engine 235 may be a separate module (as illustrated) or may instead be implementing by appropriate monitoring instructions within object methods; the principle of operation, however, remains unchanged.

The role of monitoring engine 235 is ordinarily to provide action-related information--that is, data representing the measurable characteristics of an action, or other relevant characteristics associated with the controlled machine--to performance engine 230, which utilizes this in the course of execution. Typically this means acquiring data relevant to a state specified in one of the frames defining the object. Monitoring engine 235 may simply enter the data into the "State" frame of the object, which is read (in the preferred embodiment, which involves run-time lookup of object items) by performance engine 230 during the course of execution. Alternatively, monitoring engine 235 may perform an analytical or interpretive function, using the data to further characterize the state. For example, an object may contain one or more diagnostic templates that relate various data ranges to specific conditions; in this case, monitoring engine 235 consults the template for the condition specified therein, and determines the value or state of this condition through analysis of the raw data. In either case, the monitoring engine is said to be "determining the state" specified in the frame. These examples also highlight the advantages of the preferred embodiment of the invention, where the executing program retrieves data from a structure also available (as discussed below) as a visible object to the controller's user or to a programmer. This mode of operation assists in program debugging and redesign, since controller behavior can be directly traced to conditions capable of direct examination; as well as verification of proper controller operation.

More generally, however, monitoring engine 235 maintains state information that may bear only indirectly on the method currently under execution. For example, the temperature of the controlled machine may be directly relevant to a particular action (e.g., a high temperature causing, in accordance with the action, branching to an exception-handling routine), as well as more generally relevant to operation of the machine in a global sense (e.g., a dangerously high temperature calls for termination of machine operation regardless of the current action). Indeed, monitoring engine 235 may acquire and maintain a more or less consistent suite of information regardless of the current action; the particular information relevant to the current action is entered into the state frame of the associated object, while other information is ignored.

Conversely, performance engine 230 may not require progress or state information at all. In simple cases--for example, display of an indication on display 132--performance of the action is all that is required, and monitoring is unneeded.

Operation of the invention, as well as the nature and properties of the object frames, is best understood from the perspective of the objects themselves. FIGS. 3A-3E illustrate both the frames and methods of an exemplary object as well as an interactive window for permitting the operator to enter object-defining information and parameters. In accordance with the invention, once the user has characterized all objects necessary for proper functioning of the controller, s/he is free to program controller operation in high-level code that merely invokes the objects--without replicating the lower-level procedural code residing within the objects themselves.

The window 300, which is generated by programming interface 200, can display any of various object components, each of which is identified by a labeled tab that the user may select by clicking with a mouse in accordance with conventional windows display routines. In FIG. 3A, the "Properties" tab has been selected. Boxes 305, 310--the former visible regardless of the selected tab, the latter shown only under the Properties tab--contain the name of the current object. Interface 200 allows the user to specify the name either by typing it into box 305 using keyboard 130 (in which case interface 200 either locates an existing object via object manager 215, or, if no existing object matches the entered name, instructs object manager 215 to create a new object), or by clicking on the down arrow associated with box 305 and selecting from the resulting pull-down list of available objects; the latter operation is illustrated in FIG. 3A, which results in two objects--Capper and Conveyer--being listed. Selection of Capper identifies this object as the current object in box 310, so that the information under each tab is specific to the Capper object. The Capper object controls the mechanism on a bottle-capping machine that actually applies caps to bottles as they pass under the mechanism.

The "Parts" field 315 lists all of the resources (inputs, outputs, registers, flags, subobjects, etc.) that are associated with the object Capper. These resources include two outputs (I/O points to which commands are issued by performance engine 230, via I/O modules 120) and two inputs (I/O points where confirmation signals are received by monitoring engine 235, once again via I/O modules 120). Generally, the resources associated with one object cannot be directly accessed by other objects, although they can be indirectly accessed by sending a command to the object Capper. (This latter capability is standard in the art; see, e.g., U.S. Pat. No. 5,202,981.) Resources and their types are entered by the user via keyboard 130. Performance engine 230 and monitoring engine 235 may consult (via object manager 215) the Parts field of an invoked object in order to establish the necessary control connections.

The actions (i.e., methods) associated with an object--that is, the functions (typically mechanical in nature) the object is programmed to perform--are listed under the "Actions" tab, as shown in FIG. 3B. Actions are defined or selected for editing using the name box 320. The actions are each defined by conventional procedural task steps (such as QUICKSTEP.TM. commands); the tasks defining the selected action--"Retract" in FIG. 3B--are displayed in the window 325. The actions are invoked by the high-level program using a command specifying Capper:Retract, which, when sent to object manager 215, causes the object Capper to execute its action called Retract. The illustrated action contains the command CAPPER.sub.-- UP, which causes a signal to be sent to the output resource CAPPER.sub.-- UP (see FIG. 3A); and an instruction, Capper:Retract.sub.-- Check, referring back to the same object. This instruction tests the state of the object, as discussed below.

The advantages of hierarchical object organization are readily apparent in the context of actions. For example, a hypothetical object named Gripper, designed to control a robotic gripper, might have only two actions named Open and Close. These actions are invoked by the high-level control program or by a hierarchically superior object by calling Gripper. Thus, a higher level object named Loader might control the parts-handling robot of which the robotic gripper is a component part. This object may have more elaborate actions, e.g., Load.sub.-- Part and Unload.sub.-- Part, that make use of the functionality embodied in Gripper--that is, the Load.sub.-- Part and Unload.sub.-- Part actions would likely contain a number of Gripper:Open and Gripper:Close commands.

The possible states defined for an object are listed under the "States" tab, as shown in FIG. 3C, and may be tested, as just noted, by appropriate instructions issued by the actions within the object itself or by a higher-level control program. States represent test or other conditions associated with an action or with the controlled machine generally. The currently available states are listed in the pull-down menu of box 330, and the characterstics defining the selected state are shown in the window 335. The user may define a new state by typing its name into the box 330 and defining its characteristics in window 335; object manager 215 enters these into the database containing objects 210.

The illustrated example shows a state called Retracted, associated with the object Capper. The definition of this state is a simple one: it characterizes the state of the input resource called CAPPER.sub.-- RAISED (see FIG. 3A). In more complex cases, the state may reflect a combination of multiple inputs, flags, and tests. By issuing the instruction if Capper:Retracted goto next, an action repeatedly tests whether the state is true--that is, whether the capping mechanism has been raised--and when it is, proceeds to the next step. The goto command indicates that the next step resides within the current action; the statement if Capper:Retracted then done dictates conditional termination of the current action, at which point control routine 205 may invoke a new action.

This example demonstrates how organization of actions and states into objects simplifies machine reconfiguration. Suppose, for example, that an improved bottle-capping mechanism were to add a second limit switch to be tested in combination with the input resource CAPPER.sub.-- RAISED in order to determine whether the mechanism were fully raised. By changing the definition of the state Retracted to include both tests, the tests would be automatically be performed at all points of the control program referring to this state.

An object can also hold diagnostic information. In particular, an object may contain, for each state, a template specifying conditions and associated processes, actions or states; in this way, various modes of abnormal operation--which may be defined, for example, as deviation by a predetermined extent from a mean limit-parameter value--can be addressed in a manner appropriate to that condition. This is illustrated in FIG. 3D, which shows a diagnostic titled Retract.sub.-- Check (as indicated in the name box 340); this diagnostic analyzes the time between the completion of the action named Retract to achievement of the state named Retracted. More generally, diagnostics relating to the expected timing behavior of an object measure the time between an action and some resulting state, or the time between two related states. This is specified in the Type field 342, which indicates that time is the relevant limit parameter.

The diagnostics frame contains a series of fields (i.e., attributes) relating various values or value ranges of the limit parameter to associated machine conditions, each of which may require a different form of handling--e.g., branching to a different control routine, issuing an alarm, etc. In the illustrated case, the frame contains five fields 345 corresponding to five different machine conditions: Low Shutdown, Low Warn, Normal, High Warn, and High Shutdown. A limit-parameter value (in this case, a time) is entered for each condition in the associated box, either by typing or clicking on the arrows. The significance and interpretation of these entered times depends on the existence of entries in the "On Event Do" fields corresponding to each of the condition fields 350. If an entry is added for a particular condition field, the action stated in the entry is associated with the specified condition.

The diagnostic Retract.sub.-- Check is configured to register a Low Shutdown condition upon an action-to-state time of 5 msec or less; a Low Warn condition for times in excess of 5 but equal to or less than 15 msec; a normal condition for times between 15 and 70 msec; a High Warn condition for times in excess of 70 but less than 80 msec; and a High Shutdown condition for times in excess of 80 msec. (Naturally, different applications may have different numbers of condition fields.) "On Event Do" actions--i.e., branch routine names or actions to be taken--have been entered for the extreme conditions Low Shutdown and High Shutdown. Upon detection of one of these condition outside the normal range, the object causes the action specified in the On Event Do field to occur--namely, the task called ERROR, which may shut down the machine and issue a notification to the operator. On the other hand, the conditions Low Warn and High Warn may correspond to inefficient machine behaviors or projected failure states, requiring no immediate action or a warning to the operator. These conditions may serve statistical or historical functions (e.g., as performance records associated with the controlled machine), and may be received, for example, by a central station monitoring the performance of all controllers on a network.

Once again, by utilizing run-time object lookup (rather than complete compilation of object contents), the user is permitted to alter the limit parameters and/or their values without the need to recompile the entire program sequence, and may also consult object frames in real time to determine current values (which are dynamically updated as the controlled machine operates).

Also relevant to ongoing monitoring of machine performance is the "Metrics" frame shown in FIG. 3E. This frame facilitates accumulation and processing of data relating to control transitions--generally, the time between an action and a succeeding state. The name of the transition is entered in the name box 360, and the action and state defining the transition are entered in boxes 362 and 364, respectively. Thus, the metric named Cap.sub.-- Time records each transition interval between the action Cap and the state Retracted. The "Type" field specifies an operation performed on the measured intervals, the result of which is stored in a data partition associated with the metric. In the illustrated example, the metric Cap.sub.-- Time keeps running track of the mean interval time; this value remains associated with the name Cap.sub.-- Time, and may be examined or utilized like any named variable. Multiple metrics can be applied to the same interval; for example, a different metric might utilize the same interval but perform thereon a different statistical operation. In addition to time-based measurements, metrics can track other quantitative performance indicators such as production or reject counts.

The Properties, States, Diagnostics, and Metrics frames all contain data representative of the objects with which they are associated. Some of these data (such as the object name) are static, while other data (such as Metrics) are dynamically updated. Still other frames (such as Diagnostics) specify operations involving monitoring of resources and the triggering of actions in response to detected conditions.

Preferably, the objects are organized such that they are invoked not by name, but by particular components. A high-level program (or hierarchically superior object) refers not to an object as a whole, but to a method or frame of the object. For example, a command to execute the Retract action of Capper would not call Capper, but would instead specify the method Capper:Retract, typically by means of a "do" instruction (e.g., do (Capper:Retract) goto next). States may be invoked within an action (as shown above) or in the high-level control program to test conditions predicate to branching or proceeding; for example, states may be tested as part of an "if" statement--if the state is true, the next action is taken (e.g., if Capper:Retracted goto Conveyor).

Diagnostics may be explicitly invoked as tests predicate to proceeding, as shown in FIG. 3B (if Capper:Retract.sub.-- Check then goto next), or may instead be self operative merely as a consequence of object presence or invocation of any object action. In the latter case, the instructions defining the diagnostic are executed on an ongoing basis by monitoring engine 235. Similarly, metrics may be executed upon command, or automatically--either by direct implementation by monitoring engine 235 (again, as a consequence of object presence or action invocation) or by code automatically inserted into a program that invokes a particular action.

It will therefore be seen that the foregoing represents a convenient and highly versatile approach to control organization that expands capabilities while minimizing programming effort and reducing the likelihood of error. The terms and expressions employed herein are used as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described or portions thereof, but it is recognized that various modifications are possible within the scope of the invention claimed.