WO1997040425A2

WO1997040425A2 - Idiomatic control language implementation

Info

Publication number: WO1997040425A2
Application number: PCT/US1997/006978
Authority: WO
Inventors: Edgar H. Bristol
Original assignee: The Foxboro Company
Priority date: 1996-04-25
Filing date: 1997-04-25
Publication date: 1997-10-30
Also published as: WO1997040425A3

Abstract

A computer controller (10) and method of operating the same for controlling industrial process control equipment (16) which uses a language structure and data specifically adapted for use in constructing computer programs for controlling chemical and physical processing. A translator converts to compilable code programs written as statements expressing control intentions or results. Provisions are made for implementing discrete variables using natural language statements, for assigning values to the discrete variables and for performing conditional execution statements using the discrete variables in natural language format.

Description

IPIOMATIC CONTROL LANGUAGE IMPLEMENTATION

PRIORITY CLAIM Benefit is claimed under 35 U.S.C. § 1 19(e) of the filing date of pending U.S. Provisional

Patent Application Serial No. 60/017,480, filed April 26, 1996, which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION l. Field of the Invention

The present invention relates generally to the field of computer-controlled process equipment controllers, as well as the field of control systems. More particularly, the present invention relates to an apparatus and method (i.e., an applications-oriented computer language structure and translator therefor, such as an interpreter or compiler) for developing, describing, and implementing process control of a single device or multiple devices in batch or continuous industrial process control. 2. Discussion of the Related Art

The present invention has broad application in a wide range of computer-driven control applications and analogous environments. 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 refers to the control of industrial processing systems, 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, films, metals, textiles, plastics, foods, drugs, cement, and, increasingly, semiconductors. Industrial processing systems 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. The process variables may be changed continuously or at discrete time intervals. Frequently, the control of such steps involves monitoring one or more measurements and initiating an action or setting a parameter (for example, process variables 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 in large industrial processing systems, production material is flowed through a series of processing units in such a way that each unit performs a logically independent production step. Control of a continuous process constitutes a continuous computation of the necessary process variables. 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. Batch processing units and continuous processing units themselves may be termed single vessel processing units. Within this specification, the term single vessel processing unit refers to a single processing station, which may be free standing, for accomplishing a particular predetermined processing task or series of tasks. The single vessel processing unit may receive material input from a previous single vessel processing unit and may send its output onto another single vessel processing unit. Large process control systems may be built up from a number of single vessel processing units. An example of a single vessel processing unit might be a retort or a dyebeck. 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 batch control and continuous control systems which use single vessel processing units.

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 desirable 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, the record keeping system should have the capability of displaying the recorded data in a variety of different formats, such as bar graphs and line graphs so that trends in process variables or product characteristics can be identified and corrected, if necessary.

Further, a given industrial process may have to be adjusted or changed from time to time, for example, to accommodate a substitution of raw materials or to make an improvement to the product. It is therefore important that the users of a computer-controlled single vessel processing unit 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 frequently-unfulfilled 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 for both large complex processing systems and single vessel type processing units. Until recently, these languages have included only 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 special purpose languages used for process control applications have included table-based representations of graphic features such as block diagrams and ladder diagrams, either by themselves or in conjunction with textual language features. Only the information contained in the internal table-based representation of the graphic feature has 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 and the processing objectives which motivate them. 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 application or general purpose languages typically emphasize the implementation of an operation as a series of computational 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 he is 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. To make general purpose computer languages more useful in process control, attempts have been made 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 1=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 system designer and tile implementation orientation of existing application or general purpose programming languages is that control programs written in such languages require m 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 die program is modified, the comments in the source code must be revised and the manual must be updated. With a program which is being used and modified by a number of people, the support effort needed to maintain up to date documentation is substantial. A solution to the above described problems was disclosed in U.S. Patent No.4,736,320, issued to Edgar Bristol, the inventor of the present invention, and incorporated herein by reference. In that patent, there was described a novel language structure and translator; that is, a new method of operating and programming 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 relationship 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 in the language structure disclosed in the '320 patent 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, the language structure described in the '320 patent uses as commands a mixture of textual statements and graphic symbols.

A local equipment controller and method for operating the same, which method includes a subset of the simplified instruction set of the computer language described in the '320 patent is disclosed in U.S. Patent No. 5,371,895, also issued to Edgar Bristol and incorporated herein by reference. The method of operating and programming the computer in the '895 patent includes language structures which reflect a control engineer's objectives in an idiomatic fashion. The database upon which the language structure disclosed therein operates is implemented as a single, contiguous memory segment which is scanned during each sample time to provide for regularity of program execution in combination with reduced processing overhead.

An object of the present invention is to expand the control language structure defined in the '895 and '320 patents to include language structure for discrete variables so that the discrete variables are meaningfully named to reflect a natural process of states of the discrete variables, and the causal roles that they represent.

Another object of the present invention is to provide simplified computational mechanisms for discrete variables.

Yet another object of the present invention is to provide statements of alternatives, conditional actions of discrete variables expressed as simply listed independent cases. SUMMARY OF THE INVENTION

The foregoing and other objects and advantages of the present invention are achieved in a computer-controlled equipment controller for controlling industrial process control equipment which uses a language structure and translator specifically adapted for use in constructing computer programs for controlling chemical and physical processing.

One embodiment of the present invention is directed to a method of operating a computer system to form computer code (i.e. instructions) from user-programmed source statements indicative of process control operations. The method includes steps of providing a language structure for programming the computer system, the language structure including natural language statements that reflect process control intentions, the natural language statements including structures for representing values of discrete variables in terms of natural language states of the discrete variables, and translating the natural language code into program code executable by the computer system, the step of translating including a step of translating the discrete variable data from the natural language statements to an integer form. In alternative embodiments, the language structure includes discrete assignment statements for assigning discrete values to discrete variables, and conditional execution statements for testing states of discrete variables and performing predetermined actions depending on the states of the discrete variables.

In another alternate embodiment, the conditional execution statements include a declaration statement having a plurality of variables and a plurality of test states, and the method further includes steps of comparing a state of a first of the plurality of discrete variables with a first test state of the plurality of test states to obtain a first comparison result, establishing a buffer within the computer system, storing the first comparison result in the buffer, comparing a state of a second of the plurality of discrete variables with the first test state to obtain a second comparison result, and storing the second comparison result in the buffer, etc.

Another embodiment of the present invention is directed to a computer controlled industrial process controller for controlling a processing unit. The process controller includes a computer, means for programming the computer using a language structure having natural language statements that reflect process control intentions, the natural language statements including structures for representing values of discrete variables in terms of natural language states of the discrete variables, and means for translating the natural language code into program code executable by the computer system, the step of translating including a step of translating the discrete variable data from the natural language statements to an integer form.

In alternate embodiments, the language structure of the process controller includes discrete assignment statements for assigning discrete values to discrete variables, and conditional execution statements for testing states of discrete variables and performing predetermined actions depending on the states of the discrete variables.

In another alternate embodiment of the process controller, each of the conditional execution statements includes a declaration statement having a plurality of variables and a plurality of test states, and the process controller further includes means for establishing a buffer having a pattern based on a comparison of the test states with states of the variables in the declaration statement, and means for executing at least one of the action statements when the pattern matches a predetermined pattern.

BRIEF DESCRIPTION OF DRAWINGS For a better understanding of the present invention, reference is made to the drawings which are incorporated herein by reference and in which:

FIG. 1 illustrates one example of a hardware embodiment of the present invention; FIG. 2 illustrates an example of a definitions page for discrete variables in accordance with the language structure of embodiments of the present invention; FIG. 3 illustrates the process by which discrete variable data are packed into a data field in accordance with the language structure of embodiments of the present invention; FIG. 4 illustrates one example of a data field having data packed therein; FIG. 5 illustrates the types of assignments used for discrete variables in the language structure of embodiments of the present invention; FIG. 6 illustrates a second example of a definitions page;

FIG. 7 shows an example of a compiled script form for a simple discrete assignment in accordance with the language structure of embodiments of the present invention;

FIG. 8 shows examples of state prefixes in accordance with the language structure of embodiments of the present invention; FIG. 9 shows an example of a local state environment declaration in accordance with the language structure of embodiments of the present invention; FIG. 10 shows an example of a compiled script form for a local state environment declaration in accordance with the language structure of embodiments of the present invention;

FIG. 11 is a flow chart of a process for interpretive execution of a compiled local state environment declaration in accordance with one embodiment of the present invention; and FIG. 12 shows an example of a truth table in accordance with the language structure of embodiments of the present invention.

DETAILED DESCRIPTION

One embodiment of the present invention is directed to a method of operating a computer, which method is a further refinement of the "idiomatic control language" disclosed in the '320 patent and the "idiomatic control language subset" disclosed in the '895 patent. As described in the '895 patent, the idiomatic control language subset includes a SUPERVARIABLE, which is both a language structure and an implementation device (in the form of a data structure). A SUPERVARIABLE provides the lowest level of control function in the hierarchy of the idiomatic control language subset. A SUPERVARIABLE represents a variable supported with an arbitrary list of associated attributes, and a SUPERVARIABLE includes the ability to represent several distinct variables in a single data structure (e.g., to concatenate variables). As a language structure, the SUPERVARIABLE takes the fomi of a freeform list of attributes, defined by a control engineer. The data structure supporting the SUPERVARIABLE forms the basic implementation vehicle for the local equipment controller computer program. When interpreted or compiled, a single SUPERVARIABLE structure is constructed wherein the entire program is translated into a string of type codes each with associated data stored in data fields.

Embodiments of the present invention are directed to the use of discrete variables within the SUPERVARIABLE structure. The present invention, however, is not so limited, and may also be used in the "idiomatic control language" disclosed in the '320 patent. Embodiments of the present invention allow a user of computer control systems to define discrete variables, assign values to discrete variables, and perform conditional computations involving discrete variables using states defined in terms of natural language statements. Embodiments of the present invention further include a method for translating discrete variables into interpreted or compiled program code corresponding to natural language statements written by a control systems engineer. In one embodiment, the present invention includes a computer-controlled process controller designed to control a single vessel processing unit. The process controller of the present invention, for most applications, will be locally configured for control of the single vessel processing unit to which it is attached (i.e., a local equipment process control). However, the present invention is not so limited, and multiple local equipment controllers may be connected together in order to form a larger process control system. For example, the multiple local equipment controllers may be controlled by a single central process controller which maintains system wide control and management of an overall production system. For ease of description, however, the present invention will be explained with reference to a single local equipment controller controlling a single vessel processing unit.

Reference is now made to Fig. 1, which shows a local equipment controller 10 that includes a computer system unit 12 having at least a central processing unit and associated memory along with any required input/output and mass storage devices. Computer system unit 12 may be a general purpose computer capable of being programmed according to the method of embodiments of the present invention. The computer system unit 12 may also include suitable communications hardware and software to enable multiple process controls to be connected together through the communications port 13 to form a larger process control system. The computer system unit 12 is connected by a suitable process I/O hardware and software represented by block 14 to the single vessel processing unit 16 which may be, for example, a dyebeck or a retort.

Operator commands and programming commands are input to the system unit 12 via a keyboard 18 or by input device 20 which may be a mouse, trackball or other suitable device over communication links 19 and 21, respectively. The local equipment controller of the present invention additionally includes a display device 22 which may be any suitable display device such as a CRT, liquid crystal display, or other devices which receive display data and/or commands over communications link 23. The language structure for operating and programming the local equipment controller in accordance with one embodiment of the present invention will now be explained. One skilled in the art will appreciate that the following explanation is meant as exemplary and not limiting. There are expected to be other implementations of the present invention which will occur to those skilled in the art as embodying broad concepts of the invention. In the language structure, process discrete data is represented in terms of named states using user-selected natural language terms. For example, a motor, identified as M100, may have a first operational mode that can be set to one of two states ON and OFF and a second operational mode that may be set to one of two states AUTO and MANUAL. In the language structure, the operational state of the motor M 100 when in the ON state and in the AUTO state would be described as ON.AUTO. In contrast with this example, in more traditional language representations, such as where Boolean parameters are used, the ON/OFF state of the motor may be represented by one variable having a first value which may be in binary or decimal notation, while the AUTO/MANUAL state may be represented by a second variable having a second value.

In tiie language structure, as suggested above, the state of a discrete variable is represented by a composite expression listing individual named substates separated by commas. This composite expression is referred to as a state expression for the discrete variable.

In the language structure, the present state of a discrete variable as well as the possible states of the discrete variable are defined in the definitions page. The use of definitions pages is described further in the '320 patent. An example of the representation of discrete variables in a definitions page is shown in FIG. 2, which includes a portion of a definitions page 30 showing the representation of 10 discrete variables (C100, M100, ClOl ... M104). The definitions page 30 includes five columns including a name column 32, a state column 34, a states column 38, a PV or packed value column 36 and a mask column 40. The packed value column and the mask column are not typically part of a definitions page, but are shown here for illustrative purposes. The name column 32 lists elements such as valves, motors or sensors which can be modeled as discrete variables with natural state names. The state column 34 contains the state expression for each discrete variable expressing a current state of the discrete variable as the current state of one or more substates of the discrete variable. The packed value column 36 contains a packed value for each of the discrete variables. The packed value is related to the representation of the state expression of the discrete variable after translation and is described further below.

The states column 38 includes a states expression for each discrete variable which contains all possible substates for each parameter or substate of each of the discrete variables. In the states expression, each set of alternative substates of a parameter are listed in order, separated by slashes with substates of different parameters being separated by commas. The mask column 40 includes a mask value for each of the discrete variables. The mask value is used during the translation and computation of discrete variables. The use of mask values is discussed further below.

In FIG. 2, the states expression for discrete variable C 102 includes the number 5, separated by the remainder of the states expression by a colon. A number, such as the number 5 in the states expression for the C102 variable, followed by a colon, is referred to as a field mask. As described further below, field masks are used in the packing of bits during translation.

In the translation of the language structure into a compiled version, or between displayed values and their internal or I/O device representations, the state expression for each discrete variable is translated into a packed field form. When used with the subset of the language described in the '895 patent, the method for translating the states expression in accordance with the present invention causes the state expression to be packed within a data field in the SUPERVARIABLE structure.

The mask value and the field mask are used to pack the data in the packed field format, as will now be described with reference to FIG. 3, which shows the mapping of the states expression 42 of the M100 variable from FIG.2. As shown in FIG. 2, the variable M100 has a first parameter, which may be at one of three substates STOP/START/HOLD, and the variable Ml 00 has a second parameter, which may be at one of two substates UNLOCKED/LOCKED. This example represents a simple case, as there is no field mask value associated with the states expression for variable Ml 00.

FIG. 3 shows the states expression 42 for the variable Ml 00 above a decimal representation 44 of each of the substates contained within the states expression 42. FIG. 3 also shows a data field 46 having bit locations 46A, 46B and 46C into which the states expression 42 is mapped. Reference numeral 48 in FIG. 3 shows the data field 46 as packed to represent the current state (STOP/UNLOCKED) of the discrete variable M 100. For the first parameter of the discrete variable Ml 00, the potential (i.e., available) substates STOP/START/HOLD are respectively assigned values 0, 1 and 2. For the second parameter of the variable Ml 00, the potential substates UNLOCKED/LOCKED are respectively assigned values 0 and 1. The assigned values of the parameters as they occur from left to right in the states expression 42 are mapped in accordance with arrows 45 and 47 from right to left in bit locations 46A, 46B and 46C of the data field 46. The first parameter of the variable M100 has three possible substates and is mapped into the first two bit locations 46A and 46B of the data field 46. The second parameter of the variable Ml 00 has two possible substates and is mapped into the third bit location 46C of the data field 46.

The present state of the variable Ml 00 is STOP,UNLOCKED. From the decimal representation 44 of the substates of variable Ml 00, the state STOP,UNLOCKED corresponds to a decimal value of 0 for the first parameter and 0 for the second parameter. The binary notation of the value of the first parameter is mapped to the first two bit locations of the data field and the binary notation of the value of the second parameter is mapped to the third bit location of the data field. Data field 48 of FIG. 3 shows the representation for the STOP,UNLOOCBD state of the discrete variable Ml 00 after translation. The packed value of a states expression is equal to the hexadecimal equivalent of the values packed in the data field. For example, for the STOP.UNLOCKED state of discrete variable Ml 00 shown in FIG. 3, the packed value is equal to 0. As a further example, ifthe current state of discrete variable M100 were equal to START.LOCKED, then in data field 48, bit location 48A would be set to 1 , bit location 48B would be set to 0 and bit location 48C would be set to 1 , providing a packed value of 5.

The mask value, briefly described above, provides an indication in hexadecimal notation of the number of bit locations required in a data field to represent a state of a discrete variable. The mask value from FIG. 2 for the discrete variable Ml 00 is equal to "7" in hexadecimal notation which converts to the value "111" in binary notation, indicating that the states of the Ml 00 variable will be mapped into the first three bit locations 46A, 46B and 46C of data field 46. As described further below, when a state value is assigned to a discrete variable, or when a current value of the discrete variable is retrieved, the mask value is used to limit the bit locations which are accessed to perform the computation or retrieval.

The field mask, briefly described above, is used to map substates in the states expression of a discrete variable in non-contiguous order in a data field. The field mask may be used to shift bit locations used for a variable or to skip bit locations. The use of field masks provides flexibility for control systems interfacing to hardware devices that provide a non-sequential packing of bits. This allows a user to specify arbitrary bit maps, where necessary to accommodate peculiar hardware (or standards) conventions. For example, the C 102 element of the states expression in FIG.2 has a field map value of

5 for a first parameter having the substates OFF/SUSPEND/ON. Since the first parameter has three possible substates, two bit locations in a data field are used for this parameter. FIG.4 shows a data field 50 into which the bits of the discrete variable C 102 are to be packed. Discrete variable C102 has a mask value of 7, indicating that 3 bits of the data field 50 are used to represent this variable. In the absence of a field mask, the first (right most) two bits 50A and 50B of the data field 50 would be used for the substates of the first parameter. The field mask value of 5 for variable C 102 in hexadecimal notation is equal to 101 in binary notation, indicating that the first and third bit locations of the data field are to be used for the first parameter of the discrete variable C102. Thus, the field mask value of 5 causes bits to be packed into bit locations 50A and SOC rather than in bit locations 50A and 50B when there is no field mask. Once the parameter having the field mask is packed, any remaining parameters are subsequently packed from right to left filling in any unused bit locations. Thus, bit location 50B is used to represent the current state of the second parameter of discrete variable C102. FIG. 4 shows the values of each of the bit locations of data field 50 for the current state OFF,FREEZE. Each of the bit locations has a value of 0 and the packed value of the C102 variable for this state is 0. As a further example, ifthe current state of the discrete variable C102 were ON,FREEZE (with the field mask still equal to 5), then the bit locations SOC, 50B and 50A would respectively have values of 1,0, 0, and the packed value would be equal to 4. Note that separate field masks can be applied to more than one parameter.

In one embodiment of the language structure, the substates within a states expression for a variable are reordered upon compilation, so that the substates are arranged in alphabetical order. This reordering simplifies discrete variable assignments, when one variable is assigned a state value equal to that of another variable. A colon in a states expression without a numerical value preceding it is a field mask indicating that the order of the substates is not to be changed upon compilation. The preceding has focused on the use and translation of states expressions of discrete variables in the language structure in accordance with embodiments of the present invention. Discrete variable computation in accordance with embodiments of the invention will now be described. The language structure includes four basic structures for providing discrete variable computation. These structures include discrete assignments, state prefixes, local state environment declarations, and truth tables. Each of these structures is described further below. niscrete Assignments

In the language structure, a value may be assigned to a discrete variable using a discrete assignment. A discrete assignment consists of a named sink variable (or list of sink variables) followed by a source state name or a source variable. A sink variable is defined as tiie discrete variable which is to receive a state change as a result of the discrete assignment A source state is the state to which the sink variable is to be changed. A source variable is a variable having a state or states to which the sink variable is to be changed.

Table 60 in Fig. 5 shows the types of discrete assignments used in the language structure. There are basically four types of discrete assignments, simple, general, mapped (compact) and mapped (free). Within the simple type of assignments there are three subtypes. The subtypes include basic, listed variables and composite states. Examples of each type of discrete assignment is shown in Fig. 5. Commas are used in the discrete assignment to separate a sink variable from a source state and to separate listed sink variables. Parentheses are used to prevent confusion between an assignment comma and commas used to separate list variables or composite states.

Simple assignments are used to assign one or more sink variables to one or more states or substates. Reference numeral 62 in FIG. 5 indicates a simple basic discrete assignment, C103, OPEN. This assignment places discrete variable C 103 in an OPEN state. Reference numeral 64 in FIG. 5 indicates a simple assignment with listed variables, (C101,C103),OPEN. This assignment places both discrete variables ClOl and C 103 in an OPEN state. Reference numeral 66 in FIG. 5 indicates a simple discrete variable having listed variables and composite states, (C101,C103),(OPEN,LOCKED). This assignment places both sink variables ClOl and C103 in OPENXOCKED state.

A general assignment assigns the state of the second or source variable to the sink variable. In the general assignment example 68 provided in FIG. 5, C 103, (C 101 ), the states of variable ClOl are imposed on variable C103. The general assignment structure is used when the sink variable and the source variable have the same states expression. For example, in the example shown in FIG. 5, ifthe element ClOl had a states expression of ON/OFF/FREEZE/RELEASE, then the states expression for C103 would also be ON/OFF/FREEZE/RELEASE. In the general assignment structure, one or more listed variables may be used in place of the single sink variable shown. A mapped (compact) assignment is similar to a general assignment except that only the current substate corresponding to the alternative substates of one parameter of the source variable is assigned to the sink variable. In the mapped (compact) assignment indicated by reference numeral 70 in FIG. 5, C103,(C 101 (OPEN/HOLD), the current state (either OPEN or HOLD) of the parameter of variable ClOl having substates of OPEN and HOLD is assigned to the sink variable C 103.

A mapped (free) assignment is similar to a mapped (compact) assignment except that the mapped (free) assignment is applicable to discrete variables having data fields defined by one or more field masks. Reference numeral 72 in FIG. 5 shows an example of a mapped (free) discrete assignment. Interpretation of such a mapped (free) assignment is more time consuming, and the language structure supports this with an implementation separate from that of the mapped (compact) discrete assignment.

In a mapped assignment, either compact or free, the states expression of the source variable does not have to be equal to the states expression of the sink variable. When they are not equal, a translation table, as described further below, is used to translate packed values to accomplish the assignment.

As discussed above, and further discussed in the '895 patent, any program in the idiomatic control language may be expressed in a compiled form as a SUPERVARIABLE, consisting of a sequence of attributes. These attributes are expressed as listed pcoded (portable code) data structure elements, which are interpreted once each sample time. Each pcoded data structure includes an initial distinguishing operating code, from which an operating system can identify the type of pcode/attribute and process data fields in the structure accompanying the operating code. The processing (translation) of the language structure into the compiled form is broken into two parts, an initial compilation from the higher level language proper into a text compiled script form, and a final compilation, for example, into the SUPERVARIABLE structure. The compiled script form is a sequential list of line entries each roughly corresponding to a pcoded attribute or expression in the SUPERVARIABLE structure. As described below, each script form entry begins with a basic pcode operation code which carries over into the SUPERVARIABLE structure during final compilation. The translation of discrete assignments during compilation will now be described using the discrete variables ClOl and C103 defined in the partial definitions page 78 shown in FIG. 6, and the simple listed variable assignment (C101,C103),(OPEN,LOCKED) as an example. F1G. 7 shows an example of the compiled script form 80 for the simple assignment with listed variables and composite states 66 of FIG. 5. The compiled script form 80 in FIG, 7 is shown having 5 blocks, 80A-80E for containing data. The total number of blocks in a complied script depends on the type of discrete assignment being translated and on the number of composite states and listed variables contained within the discrete assignment. In one embodiment of the present invention, the compiled script is generated by a high level language compiler and is transportable to the run time operating system. A lower level script compiler, included in the operating system, compiles the final execution database (i.e., SUPERVARIABLE structure). The first block 80A in the script form includes a type code. In the example shown in FIG. 6, the type code is "56", which in one embodiment of the language structure is tile code for a discrete assignment. During final compilation, the type code is passed directly to tiie final execution database. The second block 80B of the script, includes a numerical representation of the state expression for the ClOl state to be assigned. The three numerals contained within block 64 correspond to the offset value of the ClOl variable, the mask value of the ClOl variable, and the packed value of the state being assigned. The mask value and the packed value are described above and correspond to the final pcode form. The offset value is a value that indicates that the corresponding data field is offset from the main data field of the associated attribute, i.e. the discrete variable. The final compilation will convert this to an address difference offset value. The third block 80C in the script form includes a reference number corresponding to the ClOl discrete variable. During final compilation, the reference number is converted to a relative machine address. The fourth block 80D of the script form 80 includes the state expression for the C 103 state in similar form to that of the ClOl variable in the second block 80B. Since the ClOl and C103 discrete variables have different structures (as shown in FIG. 6), the packed value for C103 for the OPEN.LOCKED state is different than the packed value for Clθl for the OPEN/LOCKED state. Were this not true, one state representation would serve both sink variables.

As described above, mapped assignments may require the use of translation tables. Translation tables are implemented as simple numerical lookup tables stored in the compiled code for an assignment At run time, the compiled code representative of a discrete assignment operates by locating the sink variable (for example, in the SUPERVARIABLE structure), extracting those packed sink bits which are not to be affected by the assignment by using the mask value of the source value, obtaining the complement of the remaining packed bits (for example, the complement of 0,1,0 is equal to 1,0,1) combining, using a logical AND, the complement with the packed value (in binary notation) of the sink state, and then performing a logical "OR" of the combination with the new source state packed bits. When a source variable, rather than a source state, is used, the packed value of the source variable must first be extracted from the source variable. For discrete assignments having listed variables and/or composite states, the above described procedure is repeated for each of the listed variables and each of the composite states. For assignments for source variables requiring a translation table, the packed value of the source variable is translated using the translation table prior to the logical AND combination with the complement of the sink variable value.

State Prefixes

The language structure also provides a simple mechanism for conditional execution statements. This mechanism is referred to as a state prefix statement. Examples of three state prefixed statements 80, 82 and 84 are shown in FIG. 8. State prefix statements are used to cause a specified action to occur when a given state (referred to as the test state) exists. For state prefix statements that exist outside of a Local State Environment Declaration (these are described further below), the test state is tested against the state of the system as a whole, rather than against a specific discrete variable. For example, for the system shown in Fig. 1, the single vessel processing unit 16 may have a state coπesponding to AUTO (indicating that the vessel is operating in an automatic mode). Ifthe state prefix statement 80 of FIG. 8 were applied to this system, then a determination would be made as to whether the system was in the AUTO state, and if it were, then discrete variable C103 would be assigned to the OPEN state in accordance with the action statement of state prefix 80. State prefix 80 of Fig. 8 has only one test state, AUTO, and is referred to as a simple state prefix. State prefixes 82 and 84 of FIG. 8 are complex state prefixes, as each has more than one test state. When multiple test states are used in a state prefix, a comma between states, as shown in state prefix statement 82, is analogous to a logical "AND" in a descriptive sense, and a slash between states, as shown in state prefix statement 84, is analogous to a logical "OR" in a descriptive sense. I ncal State Environment Declarations (LSED.

The language structure includes Local State Environment Declarations (LSED) that express a sequence of variables, whose states (snapshotted as of the time of the LSED execution) may be queried through the use of state prefixes. FIG. 9 shows an example of a local state environment declaration 100 having a declaration line 102 followed by three state prefixed statements 104, 106 and 108. The declaration line 102 includes a number of variables contained within brackets and separated by semicolons. As described further below, the variables are generally discrete variables, however, the language provides an alternate form of declaration entry that allows testing of real valued variables. The declaration line 102 of the LSED 100 in FIG. 9 includes three discrete variables M200, P200 and V200.

A local state environment declaration in the language structure is typically located on a procedures page (as discussed in the '895 patent) and the lines constituting the local state environment declaration are bounded using semicolons between lines contained within an LSED, as shown in FIG. 9. The test states of the state prefixes in the local state environment declaration are applied to the collection of all states derived from the variables listed on the declaration line. For example, if at least one of the variables M200, P200 and V200 listed in declaration line 102 is in the ON state and at least one in the READY state, then a message "motor on" will be displayed. Similarly, if any of the three variables are in the HIGH state or in the BLOWN state, then the message "pressure too high" will be displayed. As mentioned above, the variables listed in the declaration line need not be discrete variables, but rather, the language allows for the testing of real valued variables. In this case, real valued variables are represented in the environment declaration along with a value against which the value of the real variable is to be compared. For example, a declaration line having real variables FST and FSP which are to be compared against values 500 and 100 respectively would be expressed as "[FST, 500; FSP, 100]." A real variable is compared to the associated value in the declaration line and the state of the real variable is set to EQUAL, HI or LO depending on the outcome of the comparison. State prefixes may then be used to test the current state of a real variable and set an action based on the outcome of the test.

The local state environment declaration also allows a set of variables to be queried together. To accomplish this, a state prefix statement may include one of a number of key words which defines some combination of states of the variables listed in the declaration line. If the outcome of the query is "true", then the action statement of the state prefix will occur. The available key words include:

ANY, the outcome will be true if any of the variables is at the defined state;

ANY.NOT, the outcome will be true if at least one of the variables is not at the defined state;

SOME, the outcome will be true if one or more, but not all, of the variables is at the defined state;

ALL, the outcome will be true if all of the variables is at the defined state;

NONE, the outcome will be true if none of the variables is at the defined state; ELSE, the outcome will be true if all previous state prefix statements in the local state environment declaration failed and the rest of the state prefix (which may include any of the above-described formats including key words) in which the ELSE keyword is used holds true. It should be noted that the key words described above may also be used with state prefixes not contained within local state environment declarations. In this situation, the key words will apply to a state or states of the system.

The translation of local state environment declarations to a compiled version is similar to the translation of discrete assignments discussed above. Each local state environment declaration is first translated into a simplified compiled script from which compiled data (listed pcode data structure elements) is generated. The LSED pcode consists of an initial standard operations code (the code 24 is used in the example to be discussed below) followed by a sequence of reference structures with their own distinguishing sub-code. Following the reference structures are sub- pcodes having distinguishing sub-operations codes. In one embodiment of the invention, sub-operations codes are distinguished from operations code in that the former has code values greater than 191, while the latter has code values less than 192. The sub-pcodes are grouped to coπespond to the variables of an LSED, with each group starting with a corresponding variable reference structure. For a discrete variable of an LSED, the sub-pcode structure includes a pcode (192 in the following example) for determining a state match condition between a state of the variable and a test state of a state prefix, followed by one of three types of environmental buffer setup pcodes (195, 196, and 197). The specific environmental buffer setup pcode used depends on the type of state prefix, as described further below in greater detail. For a real variable, the sub-pcode structure includes a comparison pcode (193) followed by a state match pcode (194) and one of the three environmental buffer setup pcodes.

An example of the compiled script form 120 is shown in FIG. 10 for the local state environment declaration 100 shown in FIG. 9. The contents of each of the blocks within the compiled script form is described in FIG. 10. The contents of the blocks depend on the declaration line and the state prefixes of the LSED. The blocks in the compiled script form are similar to the blocks in the compiled script form 80 for a discrete assignment shown in FIG. 6 with two major differences. First, blocks 122, 124, 126 and 128, and their corresponding sub- pcode elements, contain a further code (192) calling for a mask and compare state setup (appropriate for discrete variables). Each of the variables in the example, M200, P200 and V200 are discrete variables and the code is the same for each. When a real variable is used, a different code (193) is used in this block indicating that an additional comparison step between the value of the variable and the associated value for that variable in the declaration line must bi performed to generate a state (HI, LO or EQUAL) for the real variable. The comparison setup code for real variables is 194.

The second major difference between the script form 120 and the script form 80 is the use of blocks 130, 132, 134 and 136, (with sub-pcoded counterparts) which contain codes used to setup an environmental buffer used with local state environment declarations. The environmental buffer is described further below. A compiled pcoded LSED includes sub-pcoded elements, which compute for each variable, the successful or failed match of the variable with each of the state prefixes, or state prefix conditions. In the case of real variables the compiled code further includes codes for comparing the value of the variable with the test value to generate a state (HI, LO or EQUAL) of the variable. At run time, the compiled code sets up an environment buffer, using a segment of memory, to store match results of each of the variables with the state prefixes. This is accomplished using the codes stored in blocks 130, 132, 134 and 136 of the script form 120. The results of the state comparisons with each variable, stored in the environment buffer, can subsequently be examined to determine ifthe conditions of each state prefix are met.

In one embodiment of the invention, one byte of the environment buffer (consisting of eight bits) is used for each state prefix in the LSED. Depending on the type of state prefix, one of three methods, respectively corresponding to one of three types of state prefixes, is used to store match results in the environment buffer. For this purpose, the three types of state prefixes include simple prefixes, state prefixes with key words, and state prefixes using logical AND commands for states of different variables.

Simple state prefixes include state prefixes having only one state, having more than one state in a logical "OR" configuration, and having more than one state in a logical "AND" configuration, where the states in the "AND" configuration apply to only one of the variables in the declaration line. For simple state prefixes, when a match between the state and a variable is encountered, the byte coπesponding to the state prefix is set to a full bit pattern. At run time, the outcome of a simple state prefix can easily be determined by examining the byte in the environment buffer corresponding to the state prefix. Ifthe byte has a full bit pattern, the outcome is true. Ifthe byte does not have a full bit pattern, the outcome is false.

Keyword state prefixes include all state prefixes that have one of the key words discussed above. For key word state prefixes, when a match occurs between a test state and a variable, the first bit in the byte of the environment buffer coπesponding to the keyword state prefix is set, and when a mismatch occurs, the second bit in the byte is set. This is repeated for each of the appropriate variables. The outcome of the keyword state prefix at run time can be determined by examining these two bits. Ifthe first bit is set, then the ANY keyword is true. If both bits are set then the SOME key word will be true. Ifthe first bit is set and the second bit is not set, then the ALL key word is true. If the second bit is set then the ANY-NOT keyword is true. Ifthe second bit is set and the first bit is not set, then the NONE keyword will be true. The third type of state prefix, the AND state prefix, includes state prefixes having multiple states in a logical "AND" configuration, wherein the multiple states are not states of one variable. For AND state prefixes, one bit of the corresponding byte of an AND state prefix is assigned to each of the states in the AND state prefix. If a match is found between one of the variables and a state, then the bit corresponding to that state is set. The outcome of an AND state prefix is true if all of the assigned bits in the byte are set, otherwise the outcome is false.

The flow chart shown in FIG. 11 will now be used to demonstrate the procedure for interpretive execution of the compiled structure (in the form of listed pcode structures) of an LSED by an operating system. The LSED 100 of FIG. 9 and its corresponding script form 120 of FIG. 10 will be used to demonstrate the process 200 shown in the flow chart of FIG. 11. The process shown in FIG. 11 begins in step 202 when the local state environment declaration pcode (24) is encountered. In decision block 204, a determination is made as to whether the end of the pcode setups to be interpreted has been reached. Ifthe outcome of decision block 204 is yes, then the process ends. Ifthe outcome is no, then the process continues to line 205 of the flow chart At line 205, the process will continue through one of blanches 206, 208, 210, 212, 214, 216 or 218 depending on the type of the next pcode structure in the list of pcode structures. For the example shown in FIGS. 9 and 10, the next pcode structure tiiat will be encountered is the M200 reference number. Thus, branch 206 of the flow chart will be selected, wherein data for the M200 variable will be fetched and buffered.

The process will then return to decision block 204 and subsequently to line 205. The next pcode structure encountered is a state match setup code (192), so the process will continue through branch 208 where the state of the M200 variable will be compared with the State data (0,3,3) following the state match setup code ( 192).

The process will then again return to line 205, and since the next pcode setup structure is a simple environmental buffer setup (code 195), the process will proceed through branch 214, using the index reference (4) following the buffer setup code in the script form. For the example shown in FIGS. 9 and 10 the process 200 will continue in the above-described manner until all of the setups in the LSED have been interpreted by the operating system.

Truth Tables

The fourth language structure for discrete variables is the truth table. The truth table is an alternate format to the LSED for providing conditional discrete computations. An example of a truth table 130 in accordance with the language structure of embodiments of the present invention is shown in FIG. 12. The truth table 130 includes a top line 132 which defines the variables against which the states of the truth table will be tested. The top line 132 is similar to the declaration line of an LSED. The truth table 130 also includes a number of states 134 (OFF, ON ), organized in three rows 131, 133 and 135, and a number of actions 136. As shown in FIG. 12, the truth table can include a "blank" state 138 for a given variable.

The blank state represents a "don't care" condition, indicating that the outcome of a given row in the truth table is not affected by the variable having the blank state. The truth table operates within the language structure as follows. Starting with the first row 31, if each of the states shown are "true" then the action shown adjacent the row will occur. Ifthe outcome of the first row is not "true", then each of the subsequent rows are examined until the outcome of one of the rows is true. The action coπesponding to the first row that is "true" will occur. The truth table is similar to an LSED and is implemented in the same manner as LSEDs described above using the script form 120 and an environment buffer.

The language structure described above, provides for the implementation and computation of discrete variables within the idiomatic control language described in the '320 and '895 patents. The implementation of discrete variables in accordance with embodiments of the present invention provides significant improvement in the readability and efficiency over prior art techniques. This improvement in readability should result in fewer programming eπors by control system design engineers. The improvement in readability results from using assignment statements that reflect an engineer's intention, using easily readable definition statements and by replacing complex "IF ....then" statements in accordance with prior art techniques with local state environment declarations and truth tables that are presented in a readable format

The writing of a translator based on the foregoing description to implement the above- described language structure is within the skill of system programmers. In particular, the translator may be implemented using methods described in the '320 patent using an appropnate version of the C programming language.

Having thus described at least one illustrative embodiment of the invention, alterations, modifications and improvements will readily occur to those skilled in the art. Such alterations, modifications and improvements are intended to be within the scope and spirit of the invention. Accordingly, the foregoing description is by way of example only. It is not intended as limiting. The invention's limit is defined only in the following claims and the equivalents thereto.

What is claimed is:

Claims

CLA1MS

1. A method of operating a computer system to form computer program code from user programmed source statements indicative of process control operations, the method 5 comprising steps of: accepting natural language statements that reflect process control intentions, the natural language statements including structures for representing multi-parameter discrete variable data of discrete variables in terms of natural language states; and translating the natural language statements into program code executable by tiie computer l o system, the step of translating including a step of translating the multi-parameter discrete variable data from the natural language states to an integer form.

2. The method of claim 1 , wherein the natural language statements include a states expression for each one of the discrete variables, the states expression including a plurality of

15 states of a respective one of the discrete variables and a current state of said discrete variable.

3. The method of claim 2, wherein the natural language representation includes a field mask value, and wherein the step of translating the discrete variable data includes steps of storing the integer form in the computer system in a number of memory locations in binary

20 format and calculating a packed value of said discrete variable based on a current state of said discrete variable and based on the field mask value.

4. The method of claim 3, wherein the step of translating includes a step of selecting memory locations for storing the integer form based on the field mask value.

25

5. The method of claim 1 , wherein the step of accepting natural language statements includes a step of accepting discrete assignment statements in natural language format, and wherein the step of translating includes a step of translating the discrete assignment statements into a form executable by the computer system.

30

6. The method of claim 1 , wherein the step of accepting natural language statements includes a step of accepting conditional execution statements in natural language format the conditional execution statements having a plurality of test states and a plurality of action statements, and wherein the step of translating includes a step of translating the conditional execution statements into a form executable by the computer system.

7. The method of claim 6, wherein each of the conditional execution statements includes a declaration statement having a plurality of variables and a plurality of test states, and wherein the method further includes steps of: comparing a state of a first of the plurality of discrete variables with a first test state of the plurality of test states to obtain a first comparison result; establishing a buffer within the computer system; storing the first comparison result in the buffer; comparing a state of a second of the plurality of discrete variables with the first test state to obtain a second comparison result; and storing the second comparison result in the buffer.

8. The method of claim 7, further comprising steps of storing the first and second comparison results in a pattern in the buffer, the pattern being determined by values of the first and second comparison results, examining the pattern, and executing at least one of the action statements when the pattern matches a predetermined pattern.

9. A computer controlled industrial process controller for controlling a processing unit, the process controller comprising: a computer; means for accepting natural language statements that reflect process control intentions, the natural language statements including structures for representing multi-parameter discrete variable data of discrete variables in terms of natural language states; and means for translating the natural language statements into program code executable by the computer system, the means for translating including means for translating the multi-parameter discrete variable data from the natural language states to an integer form.

10. The process controller of claim 9, wherein the natural language statements include a states expression for each one of the discrete variables, the states expression including a plurality of states of a respective one of the discrete variables and a current state of said discrete variable.

11. The process controller of claim 10, wherein the integer form is stored in the process controller in a number of memory locations in binary format, wherein the natural language representation includes a field mask value, and wherein the means for translating the discrete variable data includes means for calculating a packed value of said discrete variable based on a current state of said discrete variable and based on the field mask value.

12. The process controller of claim 11 , wherein the means for translating includes means for selecting memory locations for storing the integer form based on the field mask value.

13. The process controller of claim 9, wherein the means for accepting natural language statements includes means for accepting discrete assignment statements in natural language format, and wherein the means for translating includes means for translating the discrete assignment statements into a form executable by the process controller.

14. The process controller of claim 9, wherein the means for accepting natural language statements includes means for providing conditional execution statements in natural language format, the conditional execution statements having a plurality of test states and a plurality of action statements, and wherein the means for translating includes means for translating the conditional execution statements into a form executable by the process controller.

15. The process controller of claim 14, wherein each of the conditional execution statements includes a declaration statement having a plurality of variables and a plurality of test states, and wherein the process controller further includes: means for establishing a buffer having a logical pattern based on a comparison of the test states with states of the variables in the declaration statement; and means for executing at least one of the action statements when the logical pattern matches a predetermined pattern.