Computer language structure for process control applications and method of translating same into program code to operate the computer

Description Submit all comments and votes

FIELD OF THE INVENTION

This invention relates to the field of computer languages and translators, as well as to the field of control systems. More particularly, it relates to a method (i.e., an applications-oriented computer language structure and a translator therefor, such as an interpreter or compiler) for developing, describing and implementing process control system for a wide variety of industrial applications. The translator accommodates the writing of programs in terms of self-documenting statements of control objectives or intentions.

BACKGROUND AND OBJECTS OF THE INVENTION

The present invention has broad application in a wide range of computer-driven control applications and analogous enviroments. Its virtues and operation will best be understood if it is described in the context of a specific type of control system, rather than in the abstract. For convenience, the context for explanatory purposes will be the field of industrial process control; it should be appreciated, however, that this is simply an exemplary context and is not limiting of the invention.

Industrial process control, as that term is used herein, refers to the control of manufacturing processes in industries wherein a product is, in at least some significant stage of production, a homogeneous fluid capable of being flowed in pipes or a stream of particles capable of being moved by a conveyor belt. The product can be operated upon by simple actuators such as valves, baffles and deflectors and its state can be determined (or at least estimated) by simple probing and sampling sensors. Typical industries included within this framework are those which manufacture petroleum products, chemicals, power, paper, and films, metals, textiles, plastics, foods, drugs, cement, and, increasingly, semiconductors.

Industrial processing systems, such as systems for preparing chemical compounds and for controlling other complex operation, frequently implement lengthy and highly detailed procedures. These procedures may involve hundreds, or even thousands, of steps in which various process parameters are monitored and selected process variables are controlled in predefined functional relationships which depend on the monitored parameters. Frequently, the control of such steps involves monitoring one or more measurements and initiating an action or setting a parameter (such as a temperature, pressure, composition, rate of change, amount of change, or the like) in response to the value or condition of the monitored measurement. Additionally, such procedures determine and control when individual processing steps are initiated as well as when they are terminated. Many of these steps typically must be performed in an established temporal relationship relative to one or more other steps. That is, step "x" is begun only after step "y" has been completed, or some predefined interval before or after step "y"; or steps "x" and "y" are carried out concurrently.

There are many ways in which industrial process control systems can be categorized or classified. One of the most basic categorizations groups systems into so-called "batch control" systems (or processes) and so-called "continuous control" systems. In continuous processes, production material is flowed through a series of processing units in such a way that each unit performs a logically independent production step. In batch processing, by contrast, the production material is placed in a vessel (the batch processing unit) with various pieces of support equipment. That equipment may perform multiple production steps, such as heating, cooling, and pressurizing the vessel. A batch process may carry out all production by itself or it may be arranged in a production line with other batch processes or with continuous units.

In some situations, an entire processing complex may occupy more than one square mile. With such a large facility, organization has a significant effect on efficiency. A processing complex typically may be organized into a hierarchy of (from bottom to top) units, processes and plants. At the lowest levels, the elements may be integrated in an appropriate manner governed by the requirement of meeting the detailed stoichiometric requirements involved in producing a given product. At higher levels, processing may be more flexibly arranged and rearranged to respond to the needs of the business (e.g., to take advantage of the processing units which happen to be available at the time there is a desire to manufacture a given product). The present invention, which is explained below, addresses the lower levels, where there is a desire for a highly integrated automation of control processing; it is well-suited to developing both batch control and continuous control systems. The scheduling and rearrangement of the higher level processing resources is the role of process management, not process control, and is therefore outside the scope of this invention.

In batch processing, the sequencing of the production procedure is divided hierarchically into various levels of operation. The divisions are made generally along the lines of stages of production, operator intervention and monitoring. This facilitates the use of a plant for producing a variety of products. The physical plant resources may be shared so that these products may be produced at different times while using some or all of the same production equipment, either by rearranging the processing or by using the same procedure but varying parameters to yield a different grade of product.

Control automation in this environment must provide a method for imposing control procedures in a relatively simple form.

It is also highly desireable that the control automation process automate the record-keeping associated with the production of each lot, based on the control parameterization and sources of raw materials used therefor; this is important since there is often a need or desire, at some later time, to be able to identify the source of particular characteristics in a product.

Further, a given industrial process may have to be adjusted or changed from time to time--for example, to accomodate a substitution of raw materials or to make an improvement to the product. It is therefore important that the users of a computer-controlled processing plant be able to identify the portions (and the specific instructions) of the control program which require revision. In the past, these requirements have given rise to a need for extensive documenting of such programs, parameters and materials. This level of documentation is only achieved at considerable expense. And undocumented changes could be difficult to detect and analyze.

Various computer languages have been used in the past for developing and implementing process control procedures. These languages have included general purpose computer languages such as FORTRAN, BASIC, PASCAL, C and other high-level textually-oriented programming languages, as well as specially adapted variants of such languages. Other languages used for process control applications have included graphic features such as block diagrams and ladder diagrams, either by themselves or in conjunction with textual language features; these graphic features, however, typically have no command significance. Moreover, most such prior languages share certain characteristics. For example, they typically require the user to follow a rigid control format using a general purpose instruction set. Further, they provide at best an awkward connection between control functions. These drawbacks are often the result of trying to employ a highly generalized and highly structured language which is implementation oriented instead of being intention oriented. That is, the instruction sets of those prior languages typically emphasize the implementation of an operation as a series of instructions, whereas the control system designer is concerned with what he is seeking to accomplish (i.e., his intentions). Consequently, the control system designer, though generally not interested in the details of how the machine implements each control operation, is forced to become a computer programmer. Many of the errors introduced in system control programs are believed to be the result of the constant need for mental translation which this regime imposes on the designer.

One result of this situation has been an attempt to develop programming strategies to minimize the translation effort. The most obvious of these strategies is the use of subroutines. Subroutines, however, are of only limited benefit. They help when the subroutine requires only a few arguments which act only once each time the subroutine is called. When there are many arguments which must be passed between the main program and the subroutine, though, the subroutine call becomes confusing and the order and meaning of its arguments becomes difficult to remember. Further, it can be an onerous task to link up every argument; and the format is made even more awkward when any of the arguments is optional.

Ambiguity is also a problem in most general purpose programming languages. For example, the expression I=1 could represent a direct calculation, a flag setting, a loop initialization, or some other operation. By contrast, application functions are not likely to be this general.

Another result of the conflict between the application orientation of the control designer and the implementation orientation of general purpose programming languages is that control programs written in such languages require an extensive documentation effort, if they are to be intelligible to future users and are to be capable of being modified from time to time. The documentation activity typically is two-fold. First, the source code for the program must be supported with extensive textual comments. Second, a written manual or the like must be prepared to explain the logical organization and features of the program, nomenclature of variables and labels, and other appropriate information. Consequently, each time the program is modified, the comments in the source code must be revised and the manual must be updated. With a large control program which is being used and modified by a number of people, the support effort needed to maintain up to date documentation is substantial.

It is therefore an object of the present invention to overcome some of these deficiencies by providing a new type of language structure (and translator therefor) specifically suitable for use in designing and documenting control systems.

It is a further object of the present invention to provide a computer language structure and translator which allow a control system designer to program in terms of the control functions he desires to implement, rather than in terms of the computer's internal details.

Another object of the invention is to provide a computer language structure for use in developing programs to control process operations, such that control programs developed therewith are largely self-documenting.

A still further object of the invention is to provide a computer language structure in which the temporal relationships between controlled processes is readily apparent to a reader of a program listing.

Yet another object of the invention is to provide a data structure for a programming environment in which the supporting details for carrying out control operations are segregated from expressions of control intentions, so as to enhance representation of the control intentions.

Still another object is to provide a programming environment for control system programming in which statements of control intentions can be expressed clearly and with little or no ambiguity.

SUMMARY OF THE INVENTION

These objects are achieved in the present invention by the provision of a novel language structure and translator; that is, a new method of operating and programming a computer system and a computer system thus controlled. The statements employed in this language structure are action-oriented and are specifically adapted for use in constructing process control programs. From these control-oriented statements, appropriate program code may be generated for operation of a computer to implement the desired control functions.

In its most complete implementation, this language structure exhibits the following characteristics: (1) it organizes the control system into logically distinct application subsystems according to processing and control activities; (2) it provides distinct representations for logically different control activities; (3) it orders the display of configured data to make it predictable and easy to read and understand; (4) it represents and displays the program structure graphically, in a way which guides the eye to and through critical relationships; (5) it employs command statements which define precise application function roles, to reduce ambiguity in the underlying intent and in the relationships between the functional elements of a control program; and (6) it uses logical and/or standard application functions and practices to account for implied configuration activities.

Graphical symbols, or icons, are employed to draw the eye to critical features in the control program and to lead the eye through critical interrelationships among the several commands of a complicated control system. At the same time, the translator treats these icons as statements (i.e., commands) which define the relationships among other associated program statements (which are usually textual commands). While prior languages designed for development of documentation have used somewhat similar graphical symbol systems to make the documentation more readable, those graphical symbols have been only passive in nature and have not also served as command statements. Thus this language structure uses as commands a mixture of textual statements and graphic symbols.

Examples are shown below of specific commands for use in a language comporting with these characteristics and adapted for use in an industrial process environment. The invention, however, does not require the use of any specific set of command statments. Other command sets can and will be readily conceived to comport with this novel language concept. Indeed, in applications other than that shown herein, it will be necessary to provide a suitable set of commands which reflects the control or other functions to be implemented.

Every textual function and statement in the present invention is expressed as a data structure. The data structure expresses the function, as configured, and the state and values most recently calculated for the relevant variables. The program structure (i.e., control connections, program order and components, etc.) is considered to be as much a part of the state of the application as any process data, and as dynamic.

The invention is pointed out with particularity in the appended claims. The above and further objects, features and advantages of the invention may be better understood by referring to the following detailed description, which should be read in conjunction with the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING

In the drawing,

FIG. 1A is a listing of a short routine illustrating three so-called IDIOM-type statements of process control of the type employed by the present invention, wherein the control intentions are immediately apparent in the formulation of each control statement;

FIG. 1B is a schematic diagram of a debutanizer bottom composition control system to which the example of FIG. 1A relates;

FIG. 1C is a diagrammatic illustration of an exemplary IDIOM according to the present invention, further illustrating the relationship between the IDIOM and its Command Feedback and State ASPECTS;

FIG. 2 is a diagrammatic illustration of the relationships between the various specially formatted portions (referred to as "PAGEs") of the control computations of a program written for execution with the present invention, depicting how each type of PAGE contains a different category of function;

FIG. 3 is a pictorial illustration of an exemplary set of icons which may be employed with the present invention to illustrate and control the selection of an order of processing for the statements in a group of control statements labelled by the icons;

FIG. 4 is an example of a sequence of statements whose order is illustrated and controlled by the icons of FIG. 3;

FIG. 5A is a schematic illustration of a tank equipped with sensors for determining the state of the tank by detecting the presence or absence of fluid at three levels therein, annotated to show the four potential conditions of the tank depending on the sensor states;

FIGS. 5B and 5C are truth tables defining the tank states in FIG. 5A as a function of the sensor states;

FIGS. 5D and 5E are ladder diagram counterparts to the truth tables of FIGS. 5B and 5C;

FIG. 6 is an example of a TEST function call according to the present invention, for generating a message conditioned on the tank state;

FIG. 7A is a diagrammatic representation of the keyboard entry for an exemplary portion of a control program written in accordance with the present invention;

FIG. 7B is an illustration of a CRT display which would result from the keyboard input of FIG. 7A;

FIGS. 8A-8H are diagrammatic illustrations of an OPERATION and its related DEFINITIONS PAGE data blocks according to the invention;

FIG. 9A is a diagrammatic representation of the keyboard entry for an exemplary portion of another control program written in accordance with the present invention;

FIG. 9B is a diagrammatic illustration of the data structures resulting from the keyboard input of FIG. 9A;

FIG. 9C is an illustration of the CRT display of the keyboard entry of FIG. 9A;

FIGS. 10A-10D are diagrammatic illustrations of the data fields of the Parameters and ACTIVITIES related blocks of FIG. 9B;

FIGS. 11A-11G are diagrammatic illustrations of exemplary P-code formats for various IDIOM statements according to the invention; and

FIG. 12 is a diagrammatic illustration of the IDIOM SPACE data structure according to the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

In the following description, extensive use will be made of terms having defined meanings. A convention has therefore been adopted to distinguish the use of such terms in their specially defined contexts from their use as terms having ordinary dictionary meanings. According to this convention, all terms defined as objects in this object-oriented language structure will be displayed in upper case block letters; and all terms defined as concepts will be displayed in upper case italics. Some terms will appear both as objects and as concepts.

After discussing the language structure, a translator for certain aspects thereof will be explained.

The guiding concept of the invention is expressed in a novel control structure, termed the IDIOM, for expressing individual control statements directly in terms of clear application intentions. As a concept, an IDIOM is a well-developed and standardized control strategy defined by its normal intention, its normal implementation, and the normal practices for connecting its implementing elements together to each other and to the surrounding system to accommodate the relevant control intentions and context. As a language element, the IDIOM is represented as a simple statement of control intention which is compilable or interpretable automatically into a user-adjustable, context-dependent control implementation. Beyond that, it is a statement which is structured to conform to or reflect necessary control function interconnections.

The IDIOM is a replacement for block diagrams and control loops. Using IDIOMs, the signal relationships between control functions are established (or replaced) by top down analyzed statements of control intention. Isolated single and multi-loop blocks are replaced by an automatic degree-of-freedom analysis of flexibly interconnected IDIOM calls.

Referring now to FIG. 1A, an example is given of several IDIOM-type intention-oriented control statements such as might be used to operate the bottom composition portion of the debutanizer of FIG. 1B. Statement 1 signifies to regulate the bottom's composition (BC1) of the debutanizer tower by manipulating a target value for the heat flow (Q1), which is itself regulated by manipulating the oil flow (OF1) with a valve (OV1). Statement 2 is an instruction to "low limit" the heat flow (Q1) to avoid tray weeping. And statement 3 is a direction to constrain within a high limit the differential pressure (DP1) across the tower to avoid flooding. Similarly, a statement such as R(TL2,OV2) could be used to represent the goal of regulating the Top Level TL2 with the Oil Valve OV2. That is, the single degree of freedom of OV2 is used to control TL2. Each of these IDIOMs would be implemented by one or more conventional controllers (which are implemented as software processes). The distinct IDIOM statement form of each of these expressions provides an unambiguous announcement of the intended role of each controller. At the same time, the listing and writing of the control program are not overburdened with the details of how the controllers are to be operated to bring about the respective control objectives. Thus in each case, the goal (i.e., the control objective) is defined by the function designation (e.g., R, LL, CH), the variable associated with the single controlled degree of freedom (BC1, Q1, DP1, or TL2, which are termed "control variables") and the manipulated variable (e.g., OV2, which is termed a "controlling variable"). The "low limit" statement is a unique case; it represents a limiting action on the controller set point corresponding to the heat flow variable Q1, which serves as both control variable and controlling variable.

Such IDIOM statements may be cascaded, as well. In that case, the controlled variable of the secondary controller through, its set point, is used as the controlling variable of the primary controller.

The notation of IDIOM statements, while similar to that of conventional subroutines or macros, invokes different actions at different times. A macro acts at system configuration or compilation time and a subroutine acts when it is encountered at run time in a program. By contrast, there are four different times of interest for a continuous control IDIOM. At system configuration time, the IDIOM is analyzed to set aside any control blocks needed to store tunings (i.e., adjustments to control parameters) and to establish basic control connections based on the permanent aspects of system context--i.e., to connect the control elements together in a way which reflects the physical connections between the various components in the processing system. At run time, when an IDIOM is encountered, the control calculations are configured automatically, based on context, to determine relative computation order and final connections. At sample time, while the IDION is active, the configured calculations are run in appropriate order. Finally, when the segment of program involving the IDIOM calculations completes execution, the IDIOM's calculations are disconnected.

Various types of IDIOMs are provided for in the language structure, along with the freedom for the user to define its own IDIOMs.

Briefly, there are two key IDIOM concepts: the KEY VARIABLE and the IDIOM SPACE. KEY VARIABLES are variables whose values are controlled, or manipulated to carry out control; they model the process variables in their feedback control participation. The IDIOM SPACE is a directed graph which is modeled by data structures described below, to represent the current disposition of degrees of freedom called for by the IDIOMatic control subsystem.

KEY VARIABLES must have a measurement ASPECT and a control ASPECT; these will normally be drawn from the attributes defined on the DEFINITIONS PAGE. These ASPECTs permit the monitoring of success and failure to control. Every IDIOM call is implemented in a way that allows access to the Co