CA2130801C - Global process control information system and method - Google Patents

Abstract

The process control display program receives input in the form of an alphanumeric process control statement (136, 138).
The alphanumeric statement is parsed into its constituent lexical units and graphical icons (160-170) corresponding to those lexical units are arranged on the display screen (116) in an interconnected network or pattern which corresponds to the syntactic relationship of the lexical units which make up he statement being displayed. The change or flow of five data is depicted by changing the visual quality or color (160, 162) of the icons and their interconnecting network to provide a graphical representation of the alphanumeric statement which is readily understood by users worldwide.

Description

Wa 93!20510 P~T/EP93I00754 t~aLOBAL PROCESS CONTROL INFORMATION SYSTEM AN~ METHO~
The present irtvention generally relates to process control computer systems and particularly to a system and method for graphically displaying the flow of process control information in a way is readily understood by users worldwide.
In recent years, computers have been increasingly employed to automate and control the production of chemicals; plastics and other industrial resources.
In this regard, it should be appreciated that each process will typicaAy present a unique set of operational constraints, input parameters and output devices to be controlled. Thus, the design of procees contrcf systems tends to be driven by the specific considerations of the process at hand. Accordingly, the interaction between the process control equipment and the technicians responsible for running the process will generally be quite different from one process to another.
Additior~alty, it should be appreciatedthat computertechnology has developed and continues to develop at a rapid pace. Thus, it is possible that a variety of different camputer hardware platforms and software packages may be employed for process control systems ~t bne or more sites, even when the peocessos involved were the similar or the same.
Accordingly, tho why in which a technician interacts with the process control equipment wilt depend no>° only uppn the process itself, but the generation and type of equipment being employed to control the process. In this regard; substantial time and effort may be devoted to days!~ping the software for displaying the oomplex information being gathered and manipulated by any .particular computer-based control system; and there may be itttie if any consistency in how this information is communicated from one control system to the next.
This results in a loss of proddctivity due the time invested by system designers and the time 25~ ~ required to train the personne8 who are ultimately charged with the responsibil'tty to run and maintain the equipmerdt used to control tha process.
Accordingly, it is an objective of the present invention to provide a process control information system and method which may be readily applied in a wide variety of processes.
_$_ Vy~ 93/20510 PCT/EP93/!)0754 It is another objective of the present invention to provide a process control information system and method which is capable of quickly communicating the flow of live or real-time information in a way recognizabte by users worldwide.
It is a further objective of the present invention to provide a process control information system and method which is capable of being adapted for use with future generations of computer-based process controt technology.
It is ~an additional objective of the present invention to provide a process control information system and method which is capable of rapidly interpreting complex process control statements and permitting fast switching between different process control statements.
It is yet another objective of the present invention to provide a process control information system and method which will simplify troubleshooting and speed up control decision-making in rerspanse to anomalous process conditions.
To achieve the foregoing objectives, the present invention provides a process 1 S control display program which provides a set of predetermined graphicat symbols through which the lexical and syntactic relationship of a process control statement or expression and the value or status of process ~aarameters may be conveyed. In this regard, each of the graphical cymbals Crave a variable graphic characteristic or variable visual quality which was employ~d to illustrate the value ar slate of a process, parameter and the flow of datalogical queliry in a program statement or expression. Importantly, these graphical symbols and their Yariabie graphic characteristics were desjgned to achieve essentially instantaneous recognition of the information sought to be conveyed with minimal use of alphanumerical text to identcfy any of the parameter values.
Accordingly, the information system according to the present invention 25 provides the necessary software implemented instructions to correlate parameter data from individual process sensors with specific graphical symbols. 'The information system also includes a program for combining selected graphical cymbals into an arrangement which was representative of a control logic sequence for a specific process being controlled. The ihformation system further includes a program far causing the arrangement of graphical 3~ symbols to be displayed, such that the variable graphic characteristic of each of the graphical symbols corresponds to the parameter values received by the sensors in real time.
~~ in one fem~ of the present imrention, the variable graphic characteristic or visual quality of the graphical symbols includes the use of Colors which may be recognized by people who otherv~rise have difficutry perceiving certain colors. Thus, for example, the color 35 blue was a~sed to indicate t~ TRUE condftion, whereas the colox orange was used to indicate a FALSE cond'stion: By employing a consistent set of graphical symbols and applying a _2_ ..J:
p....
tx. .
1.:::. i.: I
F....',~
- .t.-d:.~. 3 q .~ .:~ y ., i.":. , :...;
r. I. "I...
.. . , , ., ..., . ... ~ , .~. . .. r.. . , . .f ., .., . , , , , 5Z'tY.''x7...7~, ... .. ~.... f .m.,n,.........C ..,7... , . r ~.,YV -....
~1:.::.'_. ..,...., . .. .....,... .. ,.. , s ~ n . .. , ...... _. .. r WO 9~12451fl f'Cf'/EP93104754 ~1~0~~~.
consistent set of rules for arranging these graphical symbols, the status of any process may be quickly conveyed to any quafrfied user, regardless of computer hardware platform employed and regardless of the native language of the user.
Although well-adapted for displaying process control information, the invention in its broader aspects may be applied to the display of a wide variety of different computer program statements or expressions. For the most part, the process control display program of the invention was computer language independent. It may be adapted to work with a wide variety of different computer languages. tn general, the process control display program and method of the invention was adapted for displaying a program expression of the type capable of representing a change in d~talogicat quality.
As used herein the term 'datalogicat" was used to denote one form of data modeling which focuses on the computer representation of data. The daPalogiGai realm thus refers to a mapping of infoomation into its corresponding computer representation, which was concerned with computer memory, data types and so foeth. The datalogicat realm can be contrasted with the infalogical realm, which was a user-oriented data modeling which was concerned, ~n a formal sense, with representing the structure of data as they exist in the real world. As used herein "datalogicat quality' was any quality or attribute of or having to do with the datalogicat realm. The change in state of a data valuo from TRUE to FALSE
was one example of a change in datalogica! quality. The change in datatogical quality may have infologicat implications. For exampt~, the change in datalogical quality of a digital variable, say from TRUE to FALSE, may in a given instance map to a physical device, say a switch changing from closed to open: The change in state of the switch might, for example, have arD infological meaning that the shipping container has moved onto position in the loading platform, for example.
The process control display program and method includes a means or step for parsing the expression into lexical units and fof creating a structure for storing the lexical units, and the syntactic relationship among the lexical units. The daea structure was ~rgferabty built recursirroly, based on an exclusive and exhaustive mathematical descripttan of the program language. Some implementations may be created without use of recursion, S~ depending on the nature of the source tanguag~. The program and method further includes a means or step for drawing symboPs which coraespond to the lextca9 units in a spatial . . ' arrangement or irttercannectedl network which reflects the syntactic relationship. The process control display program and rrtethod also employs a means or step in communication with the symbol drawing means or step for displaying the change of datatogicat qual'~ty.
SS Ire the prefe~rsd embodtrrae~ the change of datatogicat quality was displayed by altering the visual quality or. color of at least some of the symbols. in this way, the visual WO 93/20510 ~ ~ PCTlEP93/00754 a .~'~ ~ ~ ~~-appearance of a datalogical flow or logic flow was depicted. The presently preferred embodiment allows the visual qual'tty or color of the symbols and the interconnecting network to change in accordance with live data received from the plant or process being controlled.
More specifically, the process control display program was adapted for producing a graphical display of alphanumeric process control statements. The process control statements comprise a set of Lexical units grouped in a syntactic relationship defined by a predetermined grammar, with at least a subset of the lexical units being capable of representing data. 'The process control display program comprises a means for supplying a process control statement to be displayed. This statement may be an expression or portion of a complete statement; a complete statement or an entire program comprising multiple .statements.
A statement analyzer generates a parse tree corresponding to the process control statement to be displayed, which was stored as a data structure in computer memory.
The process control display program includes a means for producing a graphical display ~ window and for establishing a predefined set of graphical icons to represent at least a portion of the set ~f lexical units A display generation means was in communication with the parse tree data structure and daces selected ones of the predefined set of graphical icons in the display window irt a spatial relationship corresponding to the syntactic relationship of the lexical units whichmake up the process control statement to be displayed. The program also includes a means for supplying data corresponding to at least one of the lexical units of the process control statement to be displayed. In addition, the, program includes an evaluation means which was responsive to the syntactic relationship defined by the process control statement to be displayed, for establishing a visual quatsty of salected graphical icons in the display window, based on tree supplied data. tn this way a first condition may be visually distinguished from a sedond cc~nd'ttion on the basis of visual quality.
Whip a graphical-based embodiment is presently preferred, aspects of the process control display program can be implemented in a character-based system in which a pictorial presentation of the alphanumeric process control statements were generated using selecte~J characters from a provided alphanumeric character set: Such an embodiment would thus provide a process control display program for producing a pictorial presentation of . alphanumeric process cor>xrol statements. The prcacess cor~trml statements would comprise y .. ~ set of hxical units grouped in a syntactic relationship defined by a predetermined grammar, w~h at feaet a subset of the-lexical urirts being capar~te of representing data. The process GoMrol display program of such an embodiment would include a means for supplying a process oontroi statement to be displayed and a statement analyzer for generating a symkaoi table, parse tree or other data structure corresponding to the process control statement to be displayed. The program would further include a means for writing to display device and a means for establishing a predefined set of pictorial symbols for representing at least a portion of the lexical units.
The display generation means of such an embodiment would be in communication with the symbol table, parse tree or other data structure for writing selected ones of the predefined set of pictorial symbols to the display device, in a spatial relationship corresponding to the lexical or syntactic relationship of the lexical units which make up the process control statement to be displayed. The program may further include a means for supplying data, corresponding to at least one of the lexical units of the process control statement to be displayed. An automatic evaluation means, responsive to the lexical or syntactic relationship defined by the process control statement to be displayed was provided for selectively controlling selected pictorial symbols on the display device.
This selective control would be based on the supplied data, whereby at least a first condition may be visually distinguished from a second condition on the selection of pictorial symbols being displayed.
The process control display program may also include a means for establishing a predefined set of pictorial symbols which defines first and second subsets of pictorial symbols.
The automatic evaluation means would selectively substitute selected pictorial symbols of the first subset for selected pictorial symbols of the second subset to visually distinguish a first condition from a second condition. The display generation means of the process control display program may write pictorial symbols in an interconnected network and may further comprise a means responsive to the supplied data for depicting a datalogical flow through the interconnected network. The supplied data may be dynamically changing data and the process control statements may be synchronized (or loosely synchronized) to a clock, in which case the automatic evaluation means may also be synchronized (or loosely synchronized) to the clock.
The invention may be summarized according to one aspect as a computer-implemented process control display system for displaying a program expression of the type capable of representing a change in datalogical quality, comprising: means for parsing the expression into lexical units; recursive means for creating a structure for storing the lexical units and the syntactic relationship among the lexical units; means for drawing symbols corresponding to the lexical units and spatially arranged in a network reflecting the syntactic relationship; means communicating with said drawing means for displaying the change of datalogical quality.
According to another aspect the invention provides a method for displaying a program expression of the type capable of representing a change in datalogical quality, comprising:
parsing the expression into lexical units; recursively creating a structure for storing said lexical units and the syntactic relationship among said lexical units creating a visual display of symbols corresponding to said lexical units in a pattern corresponding to said syntactic relationship; updating said visual display to show the change of datalogical quality by altering the visual quality of said symbols.
The invention will now be described in greater detail with reference to the accompanying drawings, in which:
5a Figure 1 is a schematic block diagram of a system with which the invention may be used;
Figure 2 is a block diagram illustrating an exemplary process control computer configuration;
Figure 3 is a depiction of exemplary program statements of the type useful for process control;
Figure 4 is a diagram illustrating the process of filling a bathtub, useful in understanding the program listing of Table III;
Figure 5 depicts the presently preferred graphical user interface (GUI) of the process control display program;
5b Wta 93l20S90 ;1 ..~ PCT/EP93/00754 :. W
Figure 6 illustrates the presently preferred graphical icons for representing various analog and digital values and expressions;
Figure 7a illustrates an exemplary process control statement in graphical icon representation within the window of the presently preferred graphical user interface of Figure 5; .
Figure 7b illustrates another example of the representation of a process control statement using dynamic graphical icons; , Figure 8 illustrates the manner in which the AND relationship is graphically depicted;
1 p Figure 9 illustrates the manner in which the OR relationship is graphically depicted;
depicted;
Figure 10 illustrates the manner in which the xOR relationship bs graphically Figure 11 illustrates the manner in which the NOT relationship is graphically i 5 depicted;
Figure 1 ~ illustrates the manner in which a nested or bracketed relationship is graphically depicted;
Figure 13a illustrates the presently preferred graphical depiction of a delay timer, showing the OFF irrroe delay (delay in changing from TRUE to FAL~~;
Figure 13b illustrates the presently preferred graphical depiction of a delay timer, showing the ON time delay (delay in changing from FALSE to TRUEj;
Figure i~t illustrates additional 1~0 graphical icons useful in practicing the invention;
Figure 15a shows the graphics! user interface of Figure 5, demonstrating use 2~ of the menu bar buttons;
Figure 15b shows the graphical user interface of Figure 5, demonstrating the plant and computer s~B~ction process;
Figure 15c shoears the graphical user interface of Figure 5, demonstrating the variable selection process;
~p Figure 15d shows the graphical user interface of Figure 5, demonstrating the tine number selection process;
Figure 15e shows the graphical user interface of Figure 5, demonstrating use of the f~lory function;
Figure 15f shows the graphical user interface of Figure 5, demonstrating use 35 of the Extended ~3ios~sary function;

w~ 9~izos'o ~ ~ ~ ~ ~ ~ ~ ~cr«~3roo~s~
Figure 15g shows the graphical user interface of Figure 5, demonstrating use of the Previous Pipe function;
Figures 16a and 15b are a flow chart diagram showing the manner in which the process control display program was constructed and operates;
Figure 17 is a detailed flow chart diagram useful in understanding the, lexical analyzer and parser modules of the program;
Figure 18 illustrates an example of a process control display program statement with its corresponding parse tree;
Figure 19 depicts the presently preferred parse tree data structure;
Figure 20 is a detailed flow chart diagram useful in understanding the display calculation module of the program;
Figures 21 a and 21 b show the parse tree of Figure 1 ~ demonstrating the first pass of the display calculation module;
Figure 22 is the parse tree of Figure 18 demonstrating the second pass of the display calculation module; and Figure 23 shows the screen layout of boundary boxes according to the second pass of Figure 22.
Figure 1 illustrates an exemplary process control computer system with which the process contr~I display program of the invention rnay be used. The system illustrated depicts the process at 102 which was controlled by at least one arad oaten a plurality of process oontrot computers, such as computers 104 and 106. Conventionally, computers i 04 and 106 were connected with process 102 via an assortment of various sensors, actuators, vahres, motors, heaters and other contrpllers by which the computers 1 Q4 and 106 control and rt~onitor the process being controlled at 102. If desired, the process control computers 104 arid 106 can each be dedicated to a different portion of the overall process 102, or they may be used in tandem to provide redundancy for fail-safe operation.
The process control computers were in turn connected through communication int~rfa~e subsystems 106 and i 1 ~ to a supervisory computer 112. The supervisory computer may include a workstation 114 by which the human operator may interact w'tth the supervisory computer. Interaction may be ~imited to viewing information . .. collected by the supervisory computer and displayed on a display device such as monitor 116. Alternatively, th~ human operator rnay interact thraugh an input device such as key~ioard 11 s3 or mouse 119 to supply infomeation to the supervisory computer, which may ~5 in turn be communicated to the process control computers via the appropriate communi~tior~
interface subsystem. Although physically ssparate supervisory computer 112 and .'_ l~l~C~ 93/20510 ~ PCT/EP931a0754 workstation 114 have been shown, the function of the supervisory computer could b$
performed by a suitably programmed workstation.
Providing an intuitive means for the human technician to interact with the supervisory computer and w°tth the process control computers was not easy to achieve. The assortment of various sensors, actuators, valves, motors, heaters and other controllers which control and monitor the process were physical devices. These physical devices were controlled by or produce electrical currents and voltages, which were in rum modeled or abstracted as analog or digital values suitable for processing as data by the process cor~trot computers. Often complex computer programs were run by the process control computers 1 ~ to process these analog and digital data. Because the physical devices were ultimately modeled as abstract computer data, it can often be difficult for a human technician in a plant to look at computer generated displays of data and comprehend what was actually occurring in the decision logic and arithmetic relationships associated with the physical devices which were controlling and monitoring the process. This difficulty was compounded by the fact that process control programs may re-evaluate process control program statements on a periodic basis, far example, once each second. Thus the resulting values from the statements may change on the same periodic basis, making ~ d~cult for the human technician to comprehend the status of the process. Figure 2 further illustrates the nature of abstract modeling.
In Figure 2 process 102 was controlled and mon'ttored by an assortment of various physical devices. Although a wide variety of physical devices are used in industry, for purposes of computer modeling, the physical devices can be generalized as providing a data input or receiving a data output, or both. In general, data inputs and outputs can supply either analog or digital vetoes. By way of example, process ? 02 may employ a digital device 920 which receives digital control instructions in the form of a digital oc~tput DD from process control computer 104. The digital device 120 could be an on/off valve responsive to a digital on/otf signal, for example. The process 102 may also include a digital device 122 which stappltes a dig'ttal TRfJF~FALSI~ value as a digital input Dt to process control computer 104. By way of example, the digital device °922 could be a microswitch which senses whether a door was open or closed.
Because many processes involve analog as weA as digital values, process 102 . may also include analog device 124 which provides an analog value as an analog input At to the process contr~I computer 104. Analog device 124 may be, for example, a temperature sensor which supplies an electrical signet of a voltage which varies according to a measured temperature. The process 102 may also include an analog device 126 which responds to an analog signet supplied as an anaPog output AO from the process control computer 104.

. ..,. ., ;. _;: , . ~:: :: ....
,. ':, .. ::.: ; . r ~.:; , .: . . . ,:.. . ..:: ... _... .. .-, . ,...:.; ~.... ~ .' r . . .. . :. .:. . . : . .
WO 93/20510 ~ PCT/EP93/00754 J~~~~~i Analog device 126 could be, for example, a temperature control device for a heater which regulates the temperature of a bath based on the analog control signet provided.
The foregoing digital and analog devices were merely examples of the types of devices used to control and monitor processes. For purposes of illustrating the invention, devices responding to computer output signals and devices supplying values to the computer as input signals have been separately modeled in Figure 2. Also, digital devices have been modeled separately from analog devices. in practice, some devices may employ both,input and output capabilities and some devices may involve both analog and digital properRies.
Thus the illustration of Figure 2 and the accamparrying description was intended merely to be exemplary of the way in which information about a process may be communicated between the process and the process control computer.
ff the human technician were to be given the ability to supply information to the process control c~mputer, then a data input device may be coupled to the process control computer. The data input device may be as simple as a push button switch, although 75~ frequently a keypad or keyboard 928 wile be provided. In some systems a pointing device such as a trackl~ail; arouse or joystick 13o may also be provided. In most instances input devices of this type supphl di9~al signals to the process control computer although analog signals may also be used.
The prACess control computer will typically include data storage capabitrty, 2a ~ often in the form of random access memory. This memory may be used to store the digitat and analog inprat and output values by suitably encoding the values into a form capable of ' being stored as binary digits in the computer memory. Most computer memory is configured , to store integer values u~ to a predetermined size dictated by the number of binary digits architecturaity reserved for each memory location)., i?igital values are often expressed by 25 associating one irvteger value witi~ the Soolean Ti~U~ state and another integer value with the Boolean FAI.S~ state. In a fixed point system analog values can be stored directly as integer values and are interpreted by aQplying a scads fac8or. The scaled value and the scale factor would both be stored as integer values. Alternatively, in a floating point system analog values can be stored as floating paint numbers, ire which case the number was represented in a 30 fashion similar to scient~c notation employing a mantissa and a power of ten exponent. The -- - examples in this cJescription will use a fixed point representation.
in terms of physical storage, each value was stored at a memory location to whieh an address has been assigned to ~ilow the value to be accessed by reference to its address. Sy way of illustration, Figure 2 diagrammatically depicts a series of sequential 35 memory locations 9~2 in which these dig~ai and analog values might be stored. The memory location designated Addr #1 might; for example, contain a digital output value designated by W~ 93/20510 PCF/EP93/00754 ~0;~~;,~
the name DO(100). The name DO(100) reflects the notion that the DO can be thought of as a virtual one-dimensional array having DO(100) as the 100th element in that DO
array. In this regard, the name DO(100} should not be confused with the actual state of that value, which coutd be either TRUE or FALSE. Similarly, the state of the value TRUE or FALSE
should not be confused with the binary digits' used to represent the state. For example, me ~svv~ean state TRUE might be physically represented by the binary number 00000001 and the Bootean state FALSE might be represented by the binary number 1111 i 110.
Alternatively, the Boolean states could be represented by the state of a single predetermined b'rt, in which case the other bits of the binary number could be used for storing other pieces of information such as attributes.
in a similar fashion Addr #2 might contain the digital input variable DI(iOb), Addr #3 might contain the analog input variable AI~100) and Addr #4 might contain the analog output variable A4(100). tt will be appreciated that by storing the above digital and analog values at known memory locations or memory addresses, the values can be accessed or involved in data processing steps by the process control computer.
In addition to the input and output values which were earmarked for communicatiory with the outside world (process 102 or the human technician) the process control computer may also need to use other values in performing data processing or process control steps. By convention, values which were initially assigned (by a humarv technician) ~0 and were thereafter unchanged (by the computer} vuere called'constants.° Values which may change after inttial assignment were called °variables.° Like input and output values, constants and variables can be either digkat or analog. This description adapts a naming convention in which digital and ~nalag variables were named with a prefix DC and AC, respectively.
Digital and analog constants were named with a pref""u~ DhC and AK, respectively. Variables and constants dnrere stored in the same manner as input and outpdt vetoes. To illustrate, the sequential memory locations 132 include analog constant AK(100} at Addr #3 and a digital ~rariabte ~C(100) at Addr #10. By way of example; analog constant AK(100) might store a scaled, rounded value of ~s whereas the digital constant DC(100) might store the result of a Boolean calculation nebded to determine when a valve should be opened.
SO . ~tthough the physical random access memory storage device of a typical computer res~mblss a sequential arrangement of storage locations, some processes were easier to perforrtl by arranging the data into a matrix ar muttidimensionat array. For example, a chemical process might require a recipe of difPer~~nt propoelions of components depending on the size or some other desired property of a batch. A two-dim~nsionat array or lookup table; such as array 134 may bs welt suited for this purpose. The array comprises a predefined arrangement of rows and columns in which the required value for a given process ~W~ 9/20510 PCTl~~93/00754 was located by identifying its row or column. Like other digital and analog constants and variabtes, the values which comprise an array were stored in memory locations at predefined addresses. This description adopts a naming convention to allow the reader to distinguish array values from nonarray values. Digital array values were assigned a prefix DR and analog array values were assigned the prefix AR.
Sy convention adopted in this written description, variable names may include a parenthetical 1D number to allow variables of the same prefix to be distinguished from one another, for example, DI(100), DI(101), etc. When a constant was nr~ uscsa m uG~~~~~u, .~~~
programmer may went to initialize it or set it equal to a predefined value. In a fixed point system, a predefined value was assigned by giving both the value and the scale factor. Sy convention adopted in this description, the value, and scale factor where applicable, to which a constant was initialized may be parenthetically included along with the ID
number. Thus AK(i,200,1000) assigns the variable name and ID number AK(1) to an analog constant and inittatizes its value to be 200 with a scale factor of 1000. After having been declared and initialized in this fashion, the shorthand notation AtC(1) would be used to refer to this constant thereafter.
!n order to better understand the process control display program of the invention; a fundamental understanding of the structure of a generic computer language may be helpful. There are ~ number of genera! purpose computer languages in popular use today which can be used for process control. Examples include FC3RTRAN, SASIC, F~RTH, C, taASCAL and so forth. There are also special purpose computer languages foe process control. IVlost are modeled after a general purpose language and often comprise a subset or extension of a general purpose language. The process centre! display program of the invention can be adapted to work with most general purpose and specie! purpose languages.
Accordingly, the following descripti~n of the makeup of a generic computer language, adapted fbr process confrol, was intended merely as an exempts and should not be viewed as a limitation of the scope of the invention as set forth in the claims which follow.
Typically; in a general purpose computer language, data is processed and process control procedures were performed in accordance with one or more °program statements° or °expressions° which have been written in conformity with the grammar and .. syntax rules of the cbmputer language. Each program statement or expression typically consists of a string of alphanumeric characters in one or more tines. The alphanumeric characters were usually grouped together into wards or °texical un'tts° (also called "symbols").
in many languages these lexical units were separated from one another by spaces (sometimes called whitaspace), in much the same way as words were separated by spaces in the printed teach of books.

Most computer languages allow one to construct composite lexical units or syntactic groupings from a collection of elemental lexical units. The elemental lexical units, called 'tokens,° were indivisible lexical units such as keywords, ident'rfiers, punctuators, constants, variables and operators, operands and resultants. The syntactic groupings were divisible lexical units such as program statements, expressions, declarations, function defin'ttions and other language constructs.
Commonly, a predefined set of useful tokens were created by the initial language definition. The °PRIt~JT" token in the BASIC languages, for example, was a keyword which causes certain data to be displayed on the computer display or monitor.
The ';' token was used, for example, in the C language as punctuation to denote the end of a program statement or expression. Similarly, the token 't3T' in the FORTRAfJ Language, or the token '>~ was used to denote the comparison operator 'greater than.° Other tokens, such as constants and variables were defined by the programmer.
The predefined set of tokens, such as keywords, operators and punctuation and the user defined tokens were collectively called "terminal symbols.' The computer language gramrviar rules defne the manner in which relationships among these terminal symbols may be sstablished to build syntactic groupings called °nonterminal symbots.° The nonterminat symbols thus defined may then be used to define further nonterminal symbols.
Sometimes symbols were grauped together or said to be °nested.°
Commonly, nested ~0 symbols were set off by being enclosed in parentheses or brackets. The present description uses brackets to set off nested-symbols.
Conventionally a computer language program statement or expression itse~
may be broken down into a left-hand side (sometimes called the L value or LVAL) and a right-hand side (somlPtimes called the R value or RVAL), with an 'equivalence taken' separating the two. The tbft-hated side represents the °resultant' of the program statement. The right-hand side may contain operators (such. as +, -, OR, ANC, XOR, a, ~, etc.) and operands (such as variables or constants) which detemline the state of the resultant. Figure 3 depicts this relationship. In Figure 3 two expressions are illustrated, an arithmetic expression i36 and a logical expression 938. Separating the left-hand and right-hand sides 136L and 1368 of the arithmetic expression was the 'is defined as° or °goes to° squat sign ('=°) equivalence token 140. Sim'olariy: separating the left-hand and right-hand sides 136L and 13138 of the logical expression was the conditional °goes to; !F equivalence token.
Also shown in Figure 3 are two actual expressions written in alphanumeric characters. SpecifcaBly, the arithmetic expression 136 used in this example was:
,~, .PJ a Vs'O 93/2~S14 ~ ~ ~ ~ ~ ~ ~ Pt.'TIEP93/0075d AC(100j = 3 * 6 *[AK(1) + 4].
The logical expression 138 used in this example was:
DC(100) IF DI(100} OR DI('101).
' The tokens used in the construction of program statements, expressions or other syntactic groupings may differ somewhat from language to language. For example, the operator °faT° in FORTRAPd was roughly synonymous to the operator '>° in SASI~G.
Furthermore, while certain classes of symbols, particularly operators, were fairBy common to alt computer Languages, some languages may have special purpose operators or specie!
purpose functions, procedures or subroutines which were not commonly found in most general purpose computer languages. By way of example, operators which were fairly common to most computer languages include the arithmetic operators, which cause the computer to perform the basic arithmetic operations of addition, subtraction, muhiplication and division; the comparison operators, which cause the computer compare two ar'tthmetic variables or constants; and the assignment operators, which set the value of a variable equal 7 5 ' to an arithmetic or logical expression. Table I sets fort! the naming convention which wilt be used in the following description to represent some of these commonly used operators.
Table l also sets forth the naming convention used to describe variables and constar9ts herein.
Recall that the operands characterize one-dimensional data arrays, each array comprising a number of different individual elements. The present process control display program supports special purpose symbols, such as Delay Timer, Deviation, Temnination and Simulation, whicFo were not found in general purpose computer languages. These were special purpose operators and functions which may be useful in process control computer languages and are described later.
'TALE i ~arands variable data clasaDficati~na AC [analog calculated) ~O [digital calculated]
AI [analog input]
DI [digital input]
AO [an~io~ ~utpu~fJ
D~ [digital output]
cors~taM
data clasa~lcatl~ns AK [analog corostant]
DK [digital constant]

ih'O 93/20510 PCT/EP93/00754 Operators artthrrdettc [addition]
* [subtraction]
[multiplication]
I I [division]
logical ' [Boolean NOT]
AND [Boolean AND]
OR [Boolean OR]
Q FOR [Boolean exclusive OR]
comparison GT [greater than]
GE [greater than or squat to]
LT [less than]
[less than or equal to]
~ 5, BO [equal to]
NE [not equal to]
complex (for example f~ancttor~s, $ub~.o~iry~) tog [logarithm function]
cos [cosine function]
sin [sine function) tan [tangent function]
2a integ [integration subroutine]
The process control display program of the invention provides a way of depicting convehtional alphanumeric program statements or expressions using dynamically 25 changing graphical tcohs. That is, the process contra! display program c~f the invention atlouvs the values or states of selected lexical units to tae displayed, as they change in real time, lay changing a ~eisual,quatity of the graphical icons and the tines or "pipes which interconnect the icor9s. The visual quality was dynamicalhy changed in rest time as the value or state of the lexical units change. This attovvuss a human operator to readily comprehend not only the 3tD arithrraetic or logical relationship among the lexical units of a program statement or expression but also the physical value or state being represented at any given moment in limo and why the expression vvas in that state:
Many process central operations in chemical processing and manufacturing applications irnrotve logical expressions (such as the logical expression 1B8 of Figure 3). To 35 illustrate hove the stats~ of lexical units may vary in real time, the logical expression lBt3 can be considered. The digital variable t7~C(100) was dependent upon the digetal input value -i4-1~V0 93/20510 Pd_'TlEP93/00?54 '~1~O~~o~
DI(100), or alternatively upon the digital input DI(101). Specifically, digital variable DC(100) was assigned the value FALSE if both digital inputs DI(i00) and DI(101) were FALSE. Digital variable DC(100) was TRUE if either digital input Dt(100} or Dl(101) was TRUE.
The Table H
below sets forth all four possible states of digital variable DC(100) and digital inputs DI(100}
and DI(101), the state of each lexical unit being given immediately beneath each lexical unit.
'TALE t~
(1} ao('oo} IF Dl~loo) oR DI(1a1) false false false (2) nC(100) IF D!(100) oR DI(1a1) true true false la (~} ~Ct~oa) iF nl(iao) oR Dt(1a1) true false true Dc(1oa) 1F Dl(1ao) oR DI(1a1) true true true !n the above Table II example the logical expression corresponding to logical expression 130 of Fi~ur~ 3 vas shown in the FALS~ state at line (1) and tn the TRUE state at lines (2}-(4). To see hove these expressions might relate to a physical process, the digits!
input ~!(10a} might be respons~rg to a microswiich which changes state from TRUE io FALSE
when a moving dart reaches a predefined position. Similarly, tt~e digital input DI(101) might be responsive to an optical level sensor v~hich signals when a tank is full.
The digital variable DC(10a) might be a storec9 value which was used in a later logical expression for determining whether an a~lam~ should lee activated.
yyhile the'logical expr~sslonof Table I! was relatively simple to understand, anti might be readily comprehended by a busy plant technician, not all expressions were this simple. As an example; Table 111 below sets forth a program listing, comprising a plurality of ~5 program stateraaer~ts ~r expressions, which might be used by a process control computes to . perform the seemingly sirv~ple task of fining a bathtub. fee Figure ~4 in conjunction with Table III.

w~ g3izos~o ~criE~3>oo~s~
:~~.°~~' ~.
~~~LE m List of Operar<ds and Ot~erators Used DO(1) Was the drain valve signal: TRUE to open and FALSE to close DO(2) Was the hot water valve signal:

TRUE to open and FALSE to close DO(3) Was the cold water valve signal: .

TRUE to open and FALSE to close AI(100) Was the temperature measurement AI(101) Was the level measurement AK(1000) Was the setpoint temperature for the bathwater AK(1001) Was the setpoint level for the bathwater 90 AK(1002) Was the setpoint Low Lave! for the Bathtub to Define Neariy Empty pi(1) Was a button which sends a value of Tt~UE into the computer when pushed;

when released, it sends a value of FALSE

DT(1,120,1)Were individual timers which start running when the preceding DT(2,5,1) statement DT(3,10,1) was TRUE and make the resultant DT(~,~,1) variable TRUE when they have run for the time indicated. if the preceding statement goes FALSE

after a timer his started, the timer counts backwards toward zero _16-i~V~ 93/20510 PCTlEP93100754 T~~LE 0n Predefinesf i~Aaantnqs of Stets and Inttiat Value Assignrnents STEP(1) Tub was empty STEP(2) Tub was fiNing STEP(3) Tub was full STEP(4) Tub was emptying AK(1000) 100~ on a scale of 200 AK(1001) 6096 on a scale of 100X
.

AK(1002) 3% on a sGaie of 100~6 comments The system will be in only one sTEP

at a time and will remain in that STEP until another STEP was specifically selected. The system witP begin in STEP(1) after booting. When a STEP was selected, the value of that STEP variable was TRUE

Actuat Pro~rarr~ Code STEP(1} IF STEP(4) AND AI(101,100) LT AK(1002,3,100) FOR
DT(1,120,1) , STEP(2} IF STEP(1) AND DI(1) F~R DT(2,5,1) ~ STEP(3) 1F STEP(2) AND A!(i01) GT AK(1001,60,100) FOR
DT(3,10,1) STEP(a) tF STEP(3) AND Di(1) FoR DT(a,5,1) Comment: A valve wilt only be open when the conditions for being open were TRUE; otherwise, the valve will be closed.
The status of a valve rviii change after the evaluation term which calculates the status has completed (see latch in DO(2)) AC(1,200) AK(1000,100,200} + AK(1003,5,200) .-AC(2,100) AK(1001) + AK(1004,10,100) -DO(1) iF STEP(a) OR STEP(1) UR (Ai(101) GT AC(2)) D~(3) IF STEP(2) AND #DO(2) AND Ai(101) LT AK(1001) ~~(2) . iF [STEP(2) AND AI(~01) GT

AK(1005,20,100) AND Ai(100) LT

AK(1000)J OR [DO(2) AND Ai(100) LT AC(1)] AND
AI(101) LT

AK(1001)]

-17_ ,.-. d .,. :, ,: s '? ,:~,~:.. ,r,: , ~: . . ..":.. ,.... ,.y:; , .'.r'. . . .... ....,., .. .F ;
~.°: ..,;.,~ .,,.:~. . ,. . ,:~~ ..:.~
~ .u w'.~ ,. ~:',u 5'' W~ 93/20510 1'LT/EP93/00754 '~'~.
From the example of Table III it will be more readily appreciated why conventionally expressed alphanumeric program statements were not readily comprehended and why a better way of dynamically expressing a real time process was needed.
The present process control display program fills this need by representing the lexical units of a S program statement or expression by a predefined set of graphical icons. The icons were arranged on the screen to reflect the syntactic relationship among the units.
In addition to the above operands and operators, computer languages used for process control also need a mechanism for monitoring the passage of time.
~ Most computer systems provide one or more periodic ctock signals which can be used to measure '10 time. Commonly, the periodic clock signal was used to change the state of a counting routine; causing the counting routine to count up or down either from a predetermined starting value or to a predeternnined ending value. Thus the counting routine measures time by counting increments of the periodic clock signal. Commonly, the comparison operators (such as those listed above in Tabte I) were used to implement counting loops by which time can 15 . be measured.
because the passage of time is so important to many chemical and manufacturing processes, the process control display program of the invention, in its presently preferred embodiment, was designed to display a special operator called a delay timer. The delay timer may be incorporated into the computer language to give the programmer a 20 shorthand notation for specifying and controlling the timing of events.
Thus the delay timer operator may be viev~ed as a special purpose op3rator which has been custam designed to meet the needs of a speck application. Most computer languages were extensible enough to permit such special purpose operators to be developed and incorporated into the taraguage, as needed, The use of special operators was a matter of choice for the computer 25 system designer, and the nature of such special operators can be quite diverse. Accordingly, the present description will focus on the delay timer, as one example of a special operator, in order to better illustrate how the process cor~trot display program of the invention can be developed and adapi~d to particular process control needs. Accordingly, the process cornrol display program paves not itatended to be limirted to a requirement that the disclosed delay timer 30 be included in the language. Nevertheless, the disclosed delay timer operator was quite powerful and has a wid~ range of uses in process control systems.
The presently preferred delay timer implementation may be uESed in applications where a provision needs to be made for delaying an action or calculation. dome instances where a delay timer may be used include:

W~ 93/20510 PCT/Ei?93/0075~
1 ) Allowing for provisions for normal physical delays encountered in alarm monitoring of equipment operation. The delay timer was used to retard the recognition of alarm conditions in operated equipment during the transitions between ' ON and OFF. For example, if a digital output signal has been sent to open a valve, the programming wilt normally be written to expect the valve to open. The daisy timer allows time for the physical to move before the alarm sounds.
2) Filtering out false triggers. False triggering of equipment can also occur because of electrical noise. Fluctuations in liquid levels because of.turbulence may cause a level detector to alternate between FULL and NOT FULL. signals to the computer. The delay timer can be dsed to filter orrt these false triggers.

3) ~ Measuring processing times. An action needs to take place sometime after an event has compl~ted. An example of this was energizing a vahre, or going to another step only when mixing has been completed for 1 minute, for example.

4) Making a ~igitat output true or false or a calcutation true or false for a set period of time. An example of such use would be opening a cooling water valve when cooling was required for 10 seconds, every 30 seconds, or calculating the integral of a corttroller every 30 seconds:

5) Calculating a change in a variable after a set period of time. An example of this would be to calculate a level drop within a tank every S
minutes.
From the above examples it wilt be understood that a daisy timer may be used to force a preset time delay before a digital event (OIV/OFF) was permitted to occur. The presently preferred delay timer has independent means for providing an Old tame delay and an OFF time delay: In other words; the delay timer operator was capable of delaying the change from OFF to ON by one predetermined time and delaying the change from ON to OFF
by a dif~er~nt predetemnined time. Since the C?NI time delay and the ~F~ time delay were independent of one another; either can be independently set to m, to defeat the delay feature.
The syntax used for the delay timer is shown in the figure below.
~a ~v~ g3~zos~o ~crm~~~oo~s~
~~v i r ~~~ FOR DT ( 1, n, m ) Integer - Off Time Delay Integer - On Time Delay The Element Number By convention adopted in this description, in a program statement or expression the word 'FOR' precedes the delay timer DT operator. For example:
DO(111) IF [DG(2) AND D~(101) FOR DT(15,10,25)] AND #AloM(187) In the above example the delay timer was assigned the unique element number 15. The ON
time delay was 10. The OFF time delay was 25. The AUUi(18~ refers to a speck 'aiarrn' designated by the unique element number 187. The alarm may be treated as a software flag, which rnay be used to cause a hardware alarm to annunciate.
In the above example of filling a bathtub ~'Tabie III) the program was written to correspond to several predefined states or 'steps:' In the example, STEPS 1-4 .
corresponded r~spa;~iv~iy to (1) Tub was Empty; (2) Tuh was Filling; (3) Tub was Fuil; and 2~ (,~) Tub was Emptying. Often manufacturing operations and processes can be defined in terms c~f logical steps such as these. it is sametimes helpful for a process control computer ianguagb to have a special operator which is used to keep track of what predefined slate or step the process is in at any given point in tinne. To illustrate this concept, the present description will employ a special operator STEP, which the programmer can use as a software flag or variable to keep track ~f the slat~: or stage in which the process was. !n a simple embodiment, the STEP operator may function like a digital variable or flag which was set when the process achieves a state and cleared when the process leaves that state.
tn the example of Table !11 each step has associated with ~ a program statement which, if true, causes the corresp~ndong step to be valid (flag set). For example, STEP 8 ('dub was Full) occurs if STEP 2 (Tub was Filling)' and AI(101) was greater than AK(~ioo1) for 10 seconds. In the examples given here, it was assumed that only one step can be valid at a time.
Thus when STEP 3 was TRUE (Tub was Full, ail other steps (Tub was Empty; Tub was Filling; Tub was WO 93/20~t0 s :~ PC'f'/EP93/00754 ~4 Emptying) were FALSE. This assumption was usually invoked where the process being controlled can be described as a sequence of separately occurring steps. Of course, it was also possible to have processes in which multiple sequences occur in parallel, for exempts more than one step being valid at a given time. By treating the step as a software flag the _, present invention places no restriction on whether steps must occur sequentially or whether ' they may also occur in parallel.
It should also be understood that the STEP operator was used to form a relationship between physical processes and the process control program statements being used to control those processes. !n this regard, the STEP operator should not be confused with a program step. The STEP operator was associated with a state or condition of the physical process. Although the eomput~r program controlling the process may perform a number of computational or data processing steps, there was not necessarily a one to one correspondence between'a logical process STEP and a data processing step. By way of example, the STEP of declaring the bathtub to be full (STEP 3) may involve a number of numerical data processing steps in order to determine whether the AI(101) was greater than the AK(1001). Generally speaking, the data processing steps which the computer executes in order to implement thg greater than operator have no direct relationship to the bathtub's state of being full (STEP 3). Hereinafter throughout this description, at times reference will be made to physical process STEPS and at other times reference will be made to the data processing steps needed to t~erform an algorithm. To assist the reader in distinguishing these two concepts; the physical pvocess STEP and the STEP operator were wirtten in a!I capita!
letters. Data processing steps were not written in all capital letters.
Another useful specie! operator was the deviation operator written DEV, for comparing the difference between two values and a third value. Such an operator might be used, for example, to sound an alarm if an analog input value deviates from a seipoint analog constant value by m~r~ than ~ certain amount. Tie deviation operator might be pravided in a process control computer language to calculate the difference between two analog values, convert that diff~renee into an absolute value, arid then campwere the absolute vahre against a tl~lrd analog ~ralue by subtrabtidn. Based on the result of that calculation a digits! resulearrrt SO ('tF~UE/~ALSE) would be generated. Although the procedure for performing the deviation comparison was fairly straightforward, creating a specie! DE~t operatorto perform this function was of great cony~nience try the process contre~l system programmer.
!t is sometimes convenient to ~e able to force the termination of a given step and thereby allow ttoe program to move on to the next step, in numerical order. The termination function TERfUI may be provided for this purpose.

W~ 93/20510 ~~ PCT/EP93/00754 ~~i~
At times 'tt may be useful for the programmer to simulate a digital or analog input variable under certain conditions. A number of different,sirnulation algorithms may be used, depending on the requirements of an application. Sometimes, it is helpful to control or track certain variables, in order to allow problem conditions' to be generated for program testing and evaluation, by manually intervening with the outputs related to certain simulation statements and to permit the simulation to respond to manual intervention as it would in an actual process. , The present invention was configured to handle simulations of this type.
Generally speaking, the process control display program was capable of displaying any 1 o program statement or expression which was valid in the language. fn this description the terminology AISIM and DISIM was used to denote simulated analog and digital input variables, respectively.
The presently preferred implementation of the process control display program uses a graphical user interface (GUI). The presently preferred embodiment runs under the X Vltindows environment, available under VAX/VMS Version V5.3~ or later (available from the Digital Equipment Corporation). Suitable terminals include a VAXstation running DECwindows or an X terminal in the DEC~uindows mode. Suitable X terminals include the VT1S(DO from Digital Equipment Gorporatiop and the Tektronix XP29 with optional TDEnet R~M.
A color monitor with minimum resolution of 1024 pixels horizontal by 6'~8 pixels vertical was preferred.
Figure 5 illustrates the presently preferred graphical window which appears on the user's screen (that is, on display device,916j when the program was operated in the X Vllindbws enviroroment. Those familiar with the X Windows environment will understand that the window or screen depicted in Figure 4 includes a menu bar 150 along the top horizontal edge' bf the screen. The menu bar includes an arrangement of buttons which may be Z~ selected using the pointic~g device (for example, mouse 119) to invoke the desired functions, Selovu the menu bar 950 was the active window display area 152 in which the process control display program paints the dynamically changing graphical icons. This same display area was also used by the program to present alphanumeric textual messages.
Along the horiaorttai bottom edge ~f the screen was a message area 154 in 30 which additional alphanumeric textual messages were presented. Seneath the message area 154 was a scroll bar 156, used to horizontally reposition or scroll the image depicted in . the display area 152. The screall bar was a normally provided feature of X
tNindows. Scrolling was not normally required when the pr~cess control display program was in operation, because the program includes an algorithm to ensure that the displayed image does n~t 35 extend beyond the bounds ~f the window cr screen. This algorithm was called the 'hidden pipe algorithm' and is described in detail bellow.
> .v::
° t,i r . , ttt....
.. 3 ,.. ,.. n . f...
m .w...... , r....._ ,." ..,..~<a. rx,.,:... . . . ::t'.:.. " .... , .... .
.~,-~ 1.,... ...~ . . ... , . !, ....... .. ,<... . , ,... . . .,.

W~ 93/20510 PC.'T/E~93/00?54 >~.~~~Ui The process control display program employs a predefined set of graphical icons for representing the lexical units or symbols which were defined by the computer language. More specifically, the process control display program has predefined graphical icons for representing each of the tokens and any special purpose symbols which were employed to make up the program statements or expressions used in a process control program. The presently preferred embodiment has predefined graphical icons for most of the more commonly used tokens and special purpose symbols (for example, STEP, Delay Timer, etc.). 'These icons have been devised to present an intuitive, symbolic understanding of the corresponding operand, operator or the status of a subroutine or function.
1 a In . general, the icons collectively should define a theme which wilt be understood by the human technicians responsible for overseeing the process. By way of example, in a chemical processing plant, pipes and vahres were commonly employed. Thus when adapting the pracess control display program to a chemical processing application, graphical symbols representing pipes and valves would be preferred. Of course, if the process control display program was to be used to monitor support systems on an aircraft, other graphical symbols might be chosen.
The arse of pipes and valves, as symbols for representing computer logic, should not be confused with physical pipes and valves which might be used in a plant, fn general there was no one-to-one correspondence between the graphical icon 'pipes' and 'vahres' used in the invention and the physical pipes and valves which may exist in a plant.
In keeping ~nr6th the chemical processing plant therr°oe, the preserniy preferred graphical icon for a digital variable or operand (such as Dl, DC, DO, Dtn was that of an onloff vahre, depicted using a 'bbw tie' symbol (160 and 16~} shown in Figure 6.
According to another aspect of the invention, the graphical icon, and its incoming and outgoing connecting lines or'pipes,° were made to change v~suat qualit3l (for exarr3ple, color) to distinguish different conditions or states of the operator or operand. 'thus in Figure 6, the digital operand 160 was shown in a first Mate of visual quality white digital operand 162 was shown in a second state of visual quality.
Thb presently preferred embodiment uses speck rotors to distinguish conditions or states. The color Bi_UE was used to denote the state or condir6on of TI=iUE or ON, white the color ORANGE was used to denote the state or condition of FALSE
or OFF.
The visual quality ~r rotor of the various graphical icons were made to change, preferably in real time, in order to provide the human operator with a symbolic, nonverbal understanding of the togtcat relationships among the lexical units or symbols comprising the program statement or expression, including the neat time or instantaneous conditions or states of those lexical units or symbols. The colors BLUE and ORAPdGE were presently preferred because _23-WO 93/20510 ,; Pf.'T/EP93/QO°154 studies have shown that these colors were readily discriminated by most human technicians, even those suffering from color blindness.
In addition to the BLUE and ORANGE colors, the color GREY was also used in a color system to denote indeterminate states, which were ne'tther TRUE nor FALSE. Such indeterminate states might occur, for example, when the system has detected a faulty communication line from which it can be inferred that data at the port connected to that communication line cannot be reliably treated as either TRUE or FALSE. , Although the presently preferred visual quality was color, othervisual attributes such as texture and shading could also be used. Furthermore, in syseems which do not have color displays, different shades of grey can be used to denote TRUE and FALSE
and white .
(no shadings can be used to denote the indeterminate state. To illustrate this, the Figures of this specification show TRUE as light grey, FALSE as dark grey and the indeterminate state as white:
Arirthmetic expressions were depicted by a 'pocket calculator' icon 164 also shown in Figure 6: Although the pocket calculator icon does not itself convey the a~tuat numerical value, the value can be displayed in the message area 164, or next to the icon itself, when the lean was clicked on or selected by the mouse.
Often, knowing the precise value or condition of an analog operand was not as important as knowing hour that value or condition compares to another value or condition.
2i5 As described above; the deviation function DEi/ was used to compare the difference between analog values. The presently preferred graphical icon for such a comparison was the bar graph icon shown in Figure 6 ae 166, 168 and 170. As illustrated, the bar graph can change fPOm fully BLUE, as at 166, o fully ORANGE, as at 170; as well as assume any intermediate condition, as ~t 168: The relative values displayed autorraatically take the scale factor of both analog values int~ account. The DEV function was 'ttsetf a logical operator which returns a Boolean (°t~UE/FALSE) v~tue.
The graphical icon symbols were connected to one another via horizontal and vertical knee resembldng pipes which also change color between BLUE and ORANGE
depending on the state of the ass~ciated icon. The graphical icons were connected together strictly in accordance vsrith the program statement or expression being depicted. in this way the logical retell~rt~hip of the iexteal units making up the expressdon was graphicai6y depicted.
I~loreover; as the cot~rs Ghange from ORANGE to BLt~E artd from BLUE to ORANGE, in real time, the abstract concept of logic flodv through the program statement or expression was readily eompreiiended.
85 ililith reference to Figure 7a, the logical expression 1 S8 (previously shown and descrii~ed in Figure 3) was now shown in the display area of the screen as an arrangement 1~~ 93/20510 P('T/EP93/00754 ~1~O~~i of graphical icons in a spatial relationship corresponding to the logical relationship of the lexical units. The graphical display was read from left to right. It was thus readily comprehended from the illustration of Figure 7a that the resultant DC(100) was TRUE if either operand Dt(100) or DI(101) was TRUE. This would appear quite intuitively to a chemical plant technician, who would understand that flow would proceed from left to right and that the resultant DC(100) would be'filled' with the TRUE state if either valve DI(100) or valve DI(101) was open (through which the TRUE condition may flow).
A comparison of the illustration of Figure 7a with that of Figure 3 shows that the operators Dt(900) and Dl(101) makeup the tight-hand side 1388 of the program statement while DC(100) makes up the left-hand or resultant side 138L By way of continued illustration, the resultant DC(t00} was depicted as TRUE, which can be seen to logically flow as a result of input DI(101) being TRUE. t~ this example, input Dt(100} was shown as FAt_ aE, but in accordance with Boolean logic that does not affect the outcome that resultant DC(100) was TRUE.
Implicii in the above illustration of Figure 7a was the OR relationship which defines the relationship among the operands and the resultant: In the presently preferred embodiment, operands (variables, constants, etc.} which rwere related by the Baolean OR
;:
operator were aligned and connected vertically. Operands related by the Boolean AND
operator or aligned acrd connected horiaontally. Figures 8-12 depict the pressnt6y preferred manner of depicting he physical tayout relationship of icons utilizing the Boolean AND, OR
and XOR operators, as well as the NOT operator and the nesting feature. Later, in Figure 7b, a more'detailed example will be presented which shows the layout of these operators in use.
Figurb 8 shows the manner in which two graphical icons ar objects were spatially arranged when related by the AND operator. As illustrated, each object has an associated boundary box 1T1 which completely surrounds the icon, including the icon's incoming and outgoipg lines or'pipes.' Accordingly, two such boundary tr~oxes are illustrated at A in Figure 8. Note thaf the incoming and outgoing connection lines for the respective object 1 and object 2 icons do nit line up when the respective boundary boxes were aligned, as showrn at A.
The preferred embodiment aligns objects which were related by the AND
operator so that the incoming and outgoing connecting lines of the objects being joined were norizontalty aligned: This was shown at B of Figure 8. Thus the respective boundary box positions may be adjusted by an offset needed to align the interconnecting lines hoi~zontaity.
This was implemented by assigning a predetermined offset far each graphical icon type. As shown at C in Figure a the bow tie symbol 160 has an offset of 01. The bar graph symbad 166 has an offset of 02. The offset was measured fr~m the horizontal interconnecting ~~ a.- jo ;
r. , r ~.
., :;
.J.. ., ,.
a ~ .. , . v. > . , .n ..~ . ... , . g: r .. .. .r . , . . . . , . . r . , .t , Tt'It.T..,.~:-(,_.i:...... _.,.. , ,.,rr ~~_...,i. .". . ... . ,..w. .e .,..
......, . . . . . . .. .. . ~ ,., ..~ v, vx.. . .,... , ~~ 93!20510 ,~ P(.'T/~P93/00754 ~d~~ t.
c~~
line to the upper horizontal edge of the boundary box. Also shown in Figure 8 at C, the boundary boxes were separated by a distance WD. The position of each boundary box was given by the (X,Y) position of the upper left-hand corner of the box, The position of object i was therefore (X1,Y1) and the pos'ttion~of object 2 (X2,Y2) in Figure 8.
later, in Table V, the formulas for computing the boundary box dimensions and positions of objects grouped by the relational operators (AND, OR, XOR, etc.) will be given. See the later description of 'Pass 1 of Display Calculation Module,' appearing as one of the subsections of the "Detailed Description of the Software.' Figure 9 itiustrates how the OR relationship was graphically depicted. In this case, the objects shown at A were aligned vertically as shown at B. The boundary boxes of the respective objects were separated a distance HD. Note that the left-hand OR li a was drawn to interconnect the incoming lines of both objects. The boundary boxes of both objects have been vertically aligned along the respective left edges, as illustrated at B.
Because object 1 has a smaller width W1 than object 2, a child extension line must be added to the outgoing line from object :1 in order that the resulting outgoing lines of both objects will join with the right-hand OR line, as illustrated.
Figure 10 depicts the XOR object. As illustrated, two objects joined by the XOR operator were aligned verticaBly; as in the case of the OR operator. In addition, the XOR
object was added to the composite drawing. Note that the XOR object was drawn partially inside the boundary box of the object positioned at (X,Y). The XOR object thus results in a horizontal extension of the composite boundary box equal to the dimension WL.
Figure 11 shows how the NOT operator was depicted. As illustrated, the NOT
box eras added around the baundary box of the object which it encloses. The NOT box, itse~, has incoming and outgping lines: Thus the boundary box for the composite object (including the child object and the NOT box) was extended in the horizontal dimension to accommodate ,,~
the length of the incoming and outgoing lines of the NQT box.
Figure 12 illustrates the manner ira which nested or bracketed relationships are illustrated. EsserttiaBly, an object, or group of objects, was positioned within a larger boundary box which was extended in the horizontal dimension by the sum of dimensions WDL
~p and WDR. Although a single object has been shown within the bracketed or nested relationship in Figure 12, in practice the bracketed or nested relationship was used to group a multiplicity of objects together; in order to control the precedence in which operations were pertormed as the program statement or expressoon was axecuted.
The presently preferred delay timer icon is shown in Figures 13a and i3b.
In Figure 13a a sari~s of four delay timer icons is shown to illustrate the sequence by which the OFF time was delayed. Referring to Figure 13a, the presently preferred delay timer icon comprises a °pie chart' circle 172. The sequence in Figure 13a begins at the left, designated by the state A. In state A the circle i72 was BLUE (light grey), representing TRUE or ON. In states B and C the circle 172 progressively changes to the ORANGE (dark grey) color. The circle was seen as a pie chart which progressively changes in a clockwise direction anti! it was fully ORANGE, representing FALSE or OFF. As shown at state D, once the delay timer has timed out, the circle has fully changed to the ORANGE color. The flow of logic through the delay timer was affected by the color of the circle. In Figure 13a, states A, B and C, the circle represents the TRUE or ON state. Only at state D does the circle change to the FALSE or OFF state. In terms of the logic flow analogy, the TRUE or ON
state will flow through the delay timer of Figure 8 while the delay timer was at states A, B
and C. It was only when state D was achieved that the logic flow was cut off, that is switched to the FALSE or oFF state.
Figure 13b depicts the delay timer in the opposite seduence, going from a FALSE or ~FF state to a TRUE or ON state. As illustrated in Figure i3b, the circle pie chart rotates in the opposite direction, (see states B and C}. The circle remains indicative of FALSE
or OFF until it has fully changed to TRUE (see state D}. In other ~nrords, the delay timer of Figure 13b wilt prevent the flow of logic until the timer has timed out at state D.
The rate at which the circle changes state was determined by the integer value > which establish the ~N time delay and the OFF time delay of a given delay timer. With reference to Figures l3a and i3b, the OFF time delay integer controls the clockwise rotation of the circle pie chart (Figure 13a}; the ON time delay integer controls the counterclockwise rotation of the circle pie charC (Figure 13b). Because these integers can be different, the delay timer can effect different OFF time and C9N time delays.
Figure 14 611ustrates a few additional graphical icons which were useful in the presently preferred embodiment: The diamond-shaped step icons 176 and 178 show the respective f=ALSE and' TRUE states. It will be recalled that many physical processes were ~~cribed irf terms of physical process 'STEPS,' for example empty tank, clean tank, mix .
reactants, and so forth. The programmer writes the process control program with this in mind, by defining software states (for example setting attributes within a data structure) to represent these 'STEPS.' To accommodate instances where there Is no predefined graphical icon to represent an operator (for example in the case of a rarely used subroutine}
the CALL icon 181 was provided: The CALL icon simply denotes that program flow was being directed or routed to a called subroutine or function. The name of the called subroutine or function was wrctten in alphanumeric characters at~ov~ the CALL icon. In Figure 14 the alphanumeric name of the integration function, INTEL; has been illustrated.
_27_ .., .~- f ,~ .~r ~-'" a r -r. e., .. ~ , ~c~x r r~....,t~. .a:f.~.~~5,...,.4.......,., .~.Y.:..x..... x. ~.~::.,.,..,..
...,.. ,n.......1" .." . . o.... . .....u",, . . ...., ,.... .,.., ,... . ,..
~.. ..,..,.. .. . " .

WO 93/20510 PCffEP93/00754 ~~~ ~ , Another special purpose icon was the hidden pipe icon 182. As described more fully below, the presently preferred embodiment has been written to display, where possibte, the entire program statement or expression on the screen, without truncating. In the presently preferred embodiment, the icon size remains fixed, regardless of the complexity of the program statement. Therefore; in some instances, the full display of a complex program statement would cause portions of the display to extend beyond the boundaries of the display window. Rather than require the user to scrott back and forth to see the image, a hidden pipe algorithm was used to reduce the complexity of the displayed image. This was done by replacing a logically related or nested group of icons with a single hidden pipe icon 182.
1 Q Thus the hidden pipe icon was used as a symbol to represent or hide a more complex .,;.
relationship beneath. To see the hidden retationship, the user simply clicks on or selects the hidden pipe icon in question and the program then displays the operators for which the hidden icon was substituted.
Using the above-described icons, a wide range of different program statements can be graphically depicted or rendered. As an example, the following program statement was graphically depicted in the display area 152 in Figure 7b.
STEP(417) lF STEP(415) OR STEP(416) AND ' [AI(434) L~ AK(417,400,1000) AND AI(435) LT
AK(417) AND AC(430) LT AK(417) OR DM(417) OR
[#DI(427) AND DO(427) FOR DT(3427,5,2)]]
For purposes of illustration, assume that STEP(415) was TRUE, STEP(416) was FALSE, that digital variable DM(417) was FALSE and digital variable DO(427) was TRUE.
Further assume that digital variable DOT(427) was NOT TRUE and that AI(434) was less than AP(417); AI(435) was NOT less than AP(417); and AC(430) was less than AP(417).
With these assumptions, refer to Figure 7b: From that Figure it was seen that the resultant or LVAL, STEP(417) was FALSE and 'tt can be seen the reason why. Because the analog variable AI(435) was NOT less than the analog variable AP(417), TRUE logic cannot flow through the topmost branch. Because the digital variable DM(417) was FALSE, the flow of TRUE logic cannot proceed through the middle branch. Finally, although TRUE logic was available from digital variable DO(427), the delay timer DT(3427) has not yet timed out. If none of the variables in this example change, eventually the delay timer DT(3427) will time out, permitting the flow of TRUE logic to the resultant STEP(417~.
Now having a basic understanding of the dynamically changing icon, a more detailed explanation of the menu bar buttons will be presented. Referring to Figure 15a, the _._ . ... ~ . ._., . , ..., .,_, .,. ~ : , . ", . . : . ~ .. . .:-.. . . .. .
: . . :; , . . ., ,. , . , : -. ;

1~0 93/20~f0 PCTlEP93/OO~S~t Z~~~~~~~
presently preferred menu bar has a number of buttons which can be clicked on or selocted to allow the human operator to interact with the process control display program in various ways. This was done by placing the mouse cursor 210 over the selected button and then depressing or "clicking on" the mouse button. Some of the button tunccions were curie general. For example, the help button 200 may be selected to display on-screen help while running the program. The exit button 202 was used to terminate the process control display program and remove its window from the display device. .
Several other buttons were used to allow the user to select the precise program statement he or sho wants to display with dynamically changing icons.
in large process control systems the human technician may wish to monitor a speck program statements running on a speck process control computer in a specfic plant. For example, the system described in Figure 1 represented a single plant, running a single process, with two process control computers 104 and 106. A larger system might have several plants, possibly at diverse locations, each having many processes and process control computers.
~ To allow the human technician to select which plant, and which process control computer within the plant, a computer selection button 204 was provided. Clicking on or selecting this tautton prdsents the user with a pull-down menu by which the desired plant and process cbntrol computer was selected. This pull-down menu is illustrated in Figure 15b. in the preserttty preferred embodiment the putt-down menu was actually a pair of pull-down menus; a plant selection menu 206 and a computer selection menu 208. Thus the computer selection button 204 allows the human technician to select any plant, and any process control computer within that plant, simply by selecting the appropriate choices from the pull-clown menus. Sy way of example, in Figure 15b, plant 3 has been selected and the user's cursor 290 has selected a process control computer identified as Mod D
from ~ rraenu 108. Once the riser clicks on or selects the desired plant and computer selection, the user's choices were displayed in the data fields 212 and 214 in the upper right-hand comer of the screen.
~ccasionatty, cr°rtical processes will be controlled by tvwo or more redundant process control cornput~rs: For example, in the previous example the selected computer, named Mod D, might actually comprise two computers operating redundantly (in parallel or tandem). To allow the human technician to select which one of a group of redundant ~ccamputers should be used for display, a redundant computer selection butt~n 216 was provided as shmwn in Figure 15a. Simple names or letters can be used to uniquely identify each of the group ef redundant computers, with the currently selected name appearing on the button 216 itself. if only two redundant computers were provided, button 29 6 can ire a simple toggle switch, for altematety sdlecting ekher one or the other. if more than two _ _ ._ _ , .. - . ,_, i; , _.:-: . - ,;, ;.., . ;: , .,::. ;w . -: . :
=° w °~<
~, ,,:
._. u.,.::. ~r:
f ' J
.. 41 ',k':: ':: ~
'! . T.Y,:.a j..

...d...r. . . , , . , , ,. , ..
_................ r,.. ~, .~3~..:~i1 ) W. ,'F"~s:..... . .. . v . .. . _., .., ,. . . . ,w. , A~VO 93!20510 PC'f"/EP93l00?54 , ~~
redundant computers were provided, a pull-down selection menu can be invoked by the.
button 216.
Having selected the desired plant and computer, and having identified which of a redundant group of computers the user was interested in, the remaining buttons on menu bar 150 were used to give the human .technician different ways of selecting a particular :,r, program statement or expression to be displayed. By selecting the operand selection button 218 a pull-down menu was provided which lists all of the possible digital and analog operands, including the special purpose operands, alarm, termination and simulation. This is shown in Figure 15c. The user would first select the generic name of a desired operand, followed by the appropriate numerical values needed to uniquely identify the selection. For example, if the user wanted o select the calculated digital valeJe DC(100), button 218 would be selected to reweat the illustrated pull-down menus. Next the variable name DC would be selected, followed by a selection of the digits 1,0,0, which were entered e'tther by clicking on the keypad icon or try using ari actual keypad on the keyboard 118.
By default, the program will display the statement in which the selected operand or variable was last calculated; and if not calculated, in which it was first used. The user may change this by using °Unes' button 219 (ident~ed in Figures 15a and 15d). Using the !_ines button, the user may choose ar~y program statement or expression where a variable was de0ned or caicdlated or used: When the'Unes° button was selected from the main menu bar a two item pull-down menu appears; presenting the user with the option of selecting eirther catcutated variables (CALL 220) or used variables (USED 222). When the USED
choice was selected a radio button menu appears in which alt line numbers where the current variable was used were listed: By'setecting one of the line numbers from the radio button menu, the graphical representation ofthe selected line will be automatically displayed.
When the CALL option 220 was selected; a similar radio button menu appears in which all fine numbers where the current variablewas calculated were Dieted. By selecting one of the line numbers in that menu, the graphical representation of the selected line was automatically displayed: in this example the user has selected the statement where the variable was first used via radio button mo~rse 223.
. Once a graphical representation was displayed, the user can click on any objecE comprising that display and that will cause a~ new display to appear represer~tsng the program statemenx at wi~seh the newly selected object was calculated. When a new display w~ created, either by using the menu bar to select a variable or by selecting an object in a currently displayed! s~taterneo~t; the system automatically defau9ts to the 'last calculated' ~5 statement. The radio button menu found under the CALC button 220 indicates this choice by appearing in a color different tr~m the othei radio button choices.

.:r .
. .,. .
.. . , , .
.,.-..,..-.-7..-"m>-,ror...... e.. , ,. . , . i . .v>7~. ~r~... ....__ .. ...
.. ... . . .. n . .... , ...... .... ... , .... . .. .. ... .. . . . ~ n . . .
s ... . ~ h~ ~, , . ,. .....f: ..., . , , ~ . ..... v ., n ., ..

W~ 93/20510 P(.'T/EP93/00754 The menu bar also includes a pair of buttons, the glossary button 230 and the extended glossary button 232, which may be selected to request the display of alphanumeric text information giving further information about the variables displayed. See Figure 96a.
' Often a programmer will include comments or explanatory material about a variable. In the example of Table Ill, the list of operands included a textual description of each variable and identifying which logic state (TRUE/FALS~ corresponds to which physical condition (for example, open/closed). This textual information, or other similar information, could be included in a file for access by the human technician. The file would constitute a'Glossary' of the program statement variables.
In some complex systems, there may be a great deaf of information whieh might potentially be displayed on the user's screen. As a means of organizing this information and of making it more readily accessible to the user, an 'Extended Glossary° in the form of a hierarchial table or outline s~nay be constructed. In this way, information about the system which might be useful to the human technician was arranged in levels and subleveis (for example in outline fomn). By using an outline form, the human technician can select the level of detail which he or she is interested in. This approach also allows certain information to be restricted or hidden' from operators at selected facilities or password levels.
The presently- preferred embodiment was adapted to allow access to both Glossary and Extended Glossary information: By selecting the Glossary button, a pop-up window will appear adjacent the names of each variable for the selected program statemer>t.
In this way, the user was presented with a table which Lists all operands or variables involved beside the corresponding Glossary entry: This is illustrated in Figure 15e. By using the Glossary, the user can readily determine whether a selected variable was of interest or not.
In the presently preferred embodiment the Glossary was displayed in a predefined portion of the window screen ident~ed at 234: The window title line may also display the Glossary text of the variable that was currently being displayed: If desired, the Glossary can be made to automatically appear when the mouse cursor was moved or positioned over an icon for a particular variable ~t the program statement, or over the variable name in a pap-up menu text string.
The Extended Glossary button 232 works in a similar fashion. When the Extended Glossary, button was selected, the user was first presented with a pull-dawn numbered list carresponding to each hierarchial level in the Extended Glossary which was available to that user. The user selects the desired Extended Glossary level by clicking on the appropriate number. This then~causes an Extended Glossary window to appear adjacent the selected variable. In the preferred embodiment, multiple lines of textual informatian can 1~V0 93/20510 P'CT/lEt'93/00754 be displayed in the Extended Glossary pop-out window. See Figure 15f. In Figure 1 Sf, the Extended Glossary pop-out window was designated 236.
Frequently, the user wilt want to follow a thread or sequence of displays, backtracking or moving forward through related program statements to locate which program statement was in control of a portion in :question of the overall process.
This may be conveniently done by selecting the previous pipe button 224 on the main menu bar. See Figure 15g. Depressing the previous pipe button causes a pull-down menu to appear below the button in which a predetermined number of the variable names last displayed were listed.
The previous pipe button was quite handy, since often a user will want to tasalscl for display a program statement which was recently displayed. The previous pipes List was reset or cleared when a different computer was selected via the computer selection button 204.
Having thus described the basic elements of the presently preferred graphical user interface and menu barn an example will now be given of how the system might be used to select and display a program statement in the graphical mode made possible by the program of the invention.
In use, the user was first presented with a screen such as has been illustrated in Figure 15a. The user would first click on the bomputer selection button 204 which causes pull-down menu 206 to aptaear. See Figure 15b. By pulling the mouse cursor down through the selection list 206, the desired plant can be selected. In t=figure 15b Plarrot 3 has been selecter9: Upon positioning he cursor over the desired plant, the computer selection side .
menu 208 appears. The computer selection side menu and the plant selection menu remain on the screen as tong as the nnouse button remains depressed. While keeping the mouse button depressed, the user drags the mouse cursor to the right and then down to select the desered computer. in the example in f=igure 15b the computer entitled 'MOD D' has been selected: By I'~tir~g the mouse button after selecting the desired computer, both menus 2~6 and 20g disappear and the user's choice of plant and computer were made effective. The current selection of plant and computer were displayed in the data fields 2i 2 and 214 in the upper right-hand comer:
Alext the user wilt probably want to select a program statement to be displayed. Commonly the user will be interested in displaying a program statement associated with a particular variable. This selection was made by selecting the operand select . button 218, which causes a pail-doom menu of variables to be listed. See Figure 15c. In additican to the commonly used digital and analog variables, the user can also select other operands such as the alairm operand (ALM), the STEP operand, the termination operand (TERM) as weal as the analog area digic~l simulation operands (AISBM, ~tStM).
To make the selection explicit, the user must not only select the desired variable, operand or operator from -32_ WO 93/20510 P~.'T/~P93/0075d ~~3~~D~.
the pull-down menu 240, but also the digits by which the variable, operand or operator was named. This was done by entering the appropriate numbers on the pop-out calculator keypad 2~d2. The calculator keypad includes a key for each of the digits 0-9, as well as a key to clear or enter the selected number.
The desired variable having been selected, the process control display program was now ready to display the graphical representation of a program statement. It was, of course, possible that the selected variable may be used and calculated in a number of different program statements. The presently preferred embodiment defaults to displayathe pragram statement in which the variable was last calculated, and if not calculated, in which the variable was first used. To be assured of viewing the proper program statement, the user could select the 'Lines' butian 219. See Figure 15d.
If redundant computers were being used, in tandem, for example, the redundant Computer selection button 216 Figure 15a) can bs toggled back and forth to compare the same program statement as it was actually being implemented by the redundant , computers: In alt of these examples the 'F' computer has been selected.
Clicking on the computer selection button 2i6 might change the selection to the'D' computer, for example.
Although ordinarily a great Number of safeguards would be implemented to ensure that the redundant computers were not out of sync, the abifrty to quickly toggle between redundant pales or groups of computers cart be a handy tool for troubleshooting. tf desired, the process control display program could be implemented so the redundant pairs were simultaneously displayed on the screen.
The Glossary of the currently displayed variable automatically appears in the dedicated Glossary window 234, located in the upper right-hand corner of the screen. See Figure 15e. Specifically; he Glossary of the currently displayed variable appears in the title line of the window. Four add~ional lines of Glossary can be displayed within the window.
This happens wtaen th~a deer places the mouse on one of the objects comprising the graphically rendered pr~gram statement. This also happens when the user places the mouse on a pop-up mertu text field which may appear with certain variables, such as analog vadabtes, requiring alphanumeric infbrmation in addition to the graphical rendering. Although a four line Glossary window was presently preferred, the size and position or the Glossary window could be modified if desired. Preferably the Glossary window was a scrollable window to allow more than four lines of the information to be selectively displayed, four lines at a time.
The expanded Glossary appears in the Expanded Glossary window 23s, 3~ located in the bottom sight corn err of the screen, when the user selects the ~cpand~d Glossar~r button 232. See Figure iSf: As previously explained, pressing the F~cpanded Glossary button '1~~ 93/2Q' 0'~~ ~~ PCt'/EP93/00754 gives the user a pull-down menu by which the required level of Expanded Glossary can be selected.
Figures 16a and 16b give an overall view of the manner in which the process control display program was constructed. Specifically, Figures 16a-16b show the manner in S which a program statement or expression was converted into a graphical icon display which was dynamically updated. Beginning at step 300 the program handles the user's input whereby the desired program statement to be displayed was selected. As previously explained, the user selects the desired plant and process control computer, and then selects the operand or variable which he or she wishes to be displayed. tf the operand or variable appears in several program statements, the user may select which program statement was to be displayed.
While the presently preferred embodiment fetches the desired program statement based on user input, it was also possible to employ a separate program to specify a statement to bd displayed. This is shown at step 302. A separate program could provide the required operand specfication by injecting it into the same message stream which handles user input. tn that way, an external program can simulate the user input to provide an operand specification. This cauld be useful in implementing other programs which themselves cats or iniiiat~ the present process control display program by means of conventional spawn or overlay techniques.
Next a text string was built which contains the selected operand as wetl as the necessary identity of the plant, computer and path where that operand was located. This step is shown at 304. The text string thus comprises a descriptor or spec~cation of the desired operand or variable. This text string or descriptor constitutes the input to the display generating portion of the process control display program. By way of example, if the user has indicated the desire to display a program statement involving alarm number 335 on redundant computer E, the text string descriptor might appear like: °B: ALIT
(335)°.
Next, the program finds all statements where the selected operand was used and also al! statements where the selected operand was calculated. This is depicted at step 306. Step 306 ~ctuaily involves a series of actions which are illustrated at steps 308, 310, 312 and 314. First. the program will access the operating system or system definition utilities to locate files associated with the selected computer. See step 303. Next, the program aac~sses all records where the spec'~'eed operand was calculated and used. See step 310.
Next, at step 312, the program determines which statement will be displayed.
By default, the program will display the statement in which the variable was last calculated, and rf not calculated, in which the variable was first used. ~f courso, the user can change this default selection by using the menu bar buttons as ~xplained. Finally, if the desired statement was .,., .,.... , . . 4 ,.... ~ A. .e.~t . .., a , .. r . , , , . a . ':;':t" ..
.,.
'WO 93120510 PCT/EP93l00754 ~~30s~
not located, the program generates an appropriate message indicating that the desired operand was not found. See step 314.
Having thus located the statement to be displayed, the program next performs a statement analyzing and parsing sequence, shown generally at step 316. As indicated at step 318, the parsing sequence involves generating an internal computer representation of the statement in the form of a tree structure. Essentially, the tree structure was a data structure in which each of the individual lexical units making up the program statement was independently stored in computer memory. The tree stnrcture retains information concerning the grammatical relationship of the lexical units, to allow the program statement to be reconstructed, if desired: A syntactical analyzer, which forms part of the process control display program, was used to convert the program statement into the parse tree. A more detailed explanation of the syntactical analyzer and the presently preferred parse tree were set forth below in connection with Figure 17.
Since one of the functions of the process control display program was to change the visual quality or color of the graphical icons and their associated incoming and outgoing lines or °pipes' based on changing live data (or periodically updated data), the program at step 320 constructs a list of operands used in the program statement. This list was stored as a data stnrcture in computer memory. The fist was used to store the I'rve data values needed to dynamically update the icons.
To ~Ilo~ glossary textual information to be presented for any selected icon, the program, at step 322; fetches and stores all pertinent glossary text and extended glossary text for each of the operands in the statement. This text was also stored in a data structure in computer memory, so that it will be available for instant access should the user request it.
As illustrated at step 324; the glossary and extended glossary information was obtained by ~5 accessing the appropriate GL08 and XGLOS files in which the information was stored. These files may be stored on disk:
Having gathered all of the pertinent information, the program next calculates the static display configuration. See step 326. As indicated at 328, the details of the display calcutati~rs routine are shown in later Fig~sre 20. The display calculation routine was 34 essentially responsible for determining which graphical icons need to be displayed, and in what positions. The display calculation routine also includes a hidden pipe algorithm, discussed below, to modify the display iP it was too large to f'rt on the display device screen.
l3ecauss the visual quality of the icons and the associated interconnecting 35 lines or pipes was used to cornrey information about the real time or dynamically changing states of the va~iabtes and operators, the program fetches the live data, at step 330, and uses c ~h~ live data, at step 332, to determine the visual quafrty or color of each icon and pipe. It will be recalled that this fnre data was stored in a data structure wh~h was constructed at step 320. The details of the live data algorithm are also discussed below.
Next, the program will redraw the display to update it to take account far the current values of all live data stored. This is illustrated at step 334. As tong as the user does not make an aitemate selection, the process control display program will continue to dispPay the selected program statement in graphics! icon form and will continue to update the visual quality or colors of the icons as the live data changes. In the presently preferred embodiment, the process control display program was configured to interrogate the process control computers once every second: Thus live data was evaluated and redrawn if necessary once each second. It has been found that this frequency of refreshing the data was sufficient for most processes. Of course, the degree of granularity, that is, the frequency of data refreshing, was a function of the type of process being controlled. Therefore, the presently preferred one second refresh frequency was not a limitation of the scope of the present invention. Other rates of refresh, as well as asynchronous refresh was possible within the scope of the irnrention:
The presently preferred Parser was designed to operate with context-free grammar. An example of a cont8xt free grammar was the Backus-Naur form (BNF~
which was originally developed for the ALGOL language. The speci0c embodiment used in this invention employs a single token look-ahead capability. Strictly speaking, the presently preferred parser works w'tth grammars c9ofiraed as; LAt.R(1).
As previously explained; the lexical units or symbols which make up a language irqcfude both terminal symbols, which cannot be subdivided and nonterminal symbols or groupings; which can be subdivided, ultimately into a collection of terminal 28 symbols. Terminal symbols were sometimes called "tokens." Nonterminal symbols were, sometimes called °groupings.° th terms of grammatical vale~, all tokens of the same type were considered to be the same: For example, the integer 5 and the integer 3085 were equal in forms of grammatical value; they were both °integers.° In temps of semantic value, however, the integers S and 5085 wer~ different. The romantic value of an integer was simply the value of that integer: The semantic value of a more complex symbol such as a grouping might be a tree structure, for example.
For more information about parsers see Compilers Principles, Techni4ues, And Tools, Alfred V. Aho, Ravi Sethi and Jeffrey D. l9tlman, published by Addison-Wesley.
~e p«ertly preferred statement analyzer uses a predefined set of grammar rules by which tokens may be arranged and ctassfied. The statement analyzer may be WO 93/20510 PCT/frP93/00754 viewed as a syntax-driven interpreter which performs first a lexical analysis and then a syntactic analysis. The lexical analysis was performed by a lexical analyzer or scanner which groups individual characters into tokens to build a symbol table. The syntactic analyzer or parser groups the tokens into grammatical phrases in order to build a parse tree. The statement analyzer has a priori knowledge of an exclusive and exhaustive mathematical definition lay which the source language was described. A!I valid program statements and expressions conform to that mathematical description. To illustrate, the presently preferred parser was able to parse progranrt statements having a form or mathematical description exempl~ed by the forms set forth in the Table IV below. The parser takes a program statement and matches it to one of these parseable forms.
TABLE IV
Form ~f Parsea5le Program Statements variabte IF expression = expression variable IF expression dariable = expression CALL subroutine IF expression subroutine iF expression CALL subroutine subroutine 25 ire essence, the parser was a recursive program which processes the input text stream (that is, prograrr~ statement) to determine whether it matches one of the parseable program statement forms in the Tat?Ie 1V above. if it does, a parse tree was constructed for use by the display calculation module: tf the statement does not match one of the abave parseabte prog~em statement forms, an apPr~priate error message can be generated. As will ~~ be more fully explained; the parse tree Hras a data structure to which the pertinent graphical icon data was attachecD. tJltimatefy, this data was used to display the visual icons on the display terminal window. For more infom~ation on constructing a suitable statement analyzer, including lexical ' analyzer and parser, reference may be had to Compiler Design in G, Allen 1. Holub, published by Prent'~ss-Hall. Figure 17 shows the manner in which the presently 35 preferred parser OpBP~teS. First, at step 336 the program statement to be displayed was . .. gored as a static variable: As stored, the program statement, may include noriparseable elements, such as line numbers, programmers comments or column pos~ion dependent information (as in Foriran, for example). These n~nparseabte elements were stripped away.
leaving only a parseabie set ~ tokens andlor groupings of tokens. A lexical analyzer was ~7-. i. . :;: _ ". . '~ ; ~r.;;:' VVO 93/20510 PC,'T/EP93/00754 used in step 338 to identify these tokens and feed them one at a time to the parser in step 340.
The parser then recursively analyzes the tokens to build the paese tree data structure. This is illustrated generally at step 342. The presently preferred parser produces a resultant parse tree designated LVAR at 344. Ultimately, the output of the parser was passed as a global variable pointer for use by the display calculation module.
See step 350.
Figure l8 gives an example of a program statement and its parse tree. The illustrated statement:
STEP(417) IF STEP(415) OR STEP(416) AND
tAl(434) LT AK(41,,4oo,iooo) AND AI(435) LT
AK(41~ AND AC(430) LT AK(41~ OR DM(417) OR
[#DI(~27) AND D8(427) FOR DT(3427,5,2)j) was of the parseable form, °variable IF expression = expression.' As illustrated in Figure 18, the parse tree breaks down the program statement into its individual lexical units as a hierarchial set of nodes. This set of nodes was stored in a data structure to which the pertinent graphical infbrmation can be attached by the display calculation module.
Figur~ 19 illustrates the presently preferred data structure used to store the parse tree data. Actually the data structure used to store the parse tre~
comprises a series of data structures iinlced by pointers. From a top level view; the data structure includes a node tree structure 352 designated node t. This tree stnocture includes: (1) a linked list of all children nodes and (2) a pointer to the speck node's parse data. Thus the node tree 26 data strtacture represents the ~verall configurati~~t of the parse tree, showing the relationship among the lexical units ~rhich make up thp program statement.
At a rraore intermediate level, the data structure also includes a parse data tree ~~~ure 354 which was pointed to by the node tree stnrcture 352. The parse data tree stnrctur~. identified as parse data t, was a tree structure which stores (1 ) the token code latael 3p of the given lexlc~l unit, (2) the semantic value of the labeled 8oken and (3) a hook to application-specific data. This application-speck data identifies the graphical is~n to be used .t~ rapresertt that particular lexical unit or token.
The parse data tree structure 354 in turn points to a lower le~rei tree structure in which the token serrtantic Information was stored. This tpken semantic tree stnrcture 356, 35 also ident~ed as tok~sem_t. contains (1) the token semantic poirrter to yet another data structure and (2) the specific data applicable to that token.

Rt a still lower level the data structure comprises a semantic tree structure 358, which was also referred to as semantic i. This semantic tree structure was used to store the semantic value (S VALUE), the semantic text (S TEX'n, the type, the variable type, the access data and the maximum number of elements data. These data were used to store information needed by the display calculation algorithm. .
The display calculation module receives the parse tree as its input and adds to it a number of data structures used by other modules of the process control display program. Among the primary functions of the display calculation module was the calculation of the dimensions and coordinates (screen posftion) of every graphical icon used to represent the lexical units of the program statement to be displayed. This calculation includes a decision on whether the hidden pipe algorithm needs to be invoked. The hidden pipe algorithm was called when the entire uncompressed graphical representation of a program statement will not fit in the display area of the window.
The display calculation module was also responsible for creating a Display List , used during real time evaluation. In addition to the Display List thg display calculation module also builds a Live Data Variables List and a File System Variables List. The Live Data List was used by the five data module, described below, to create the address list which was ultimately passed to the operating system to allow the operating system to obtain the necessary live data. The Fite System variables List was used to allow the operating system to supply the glossary strings applicable to the selected variables. In this way, the glossary strings can be addressed via the Display List. In computer programming terms, the Display List and the two Variables Lists and the access functions of these lists constitute the interface of the display calculation module.
Referring back to Figure 18; the parse tree sets forth how the individual lexical units make up the program statement. Spec~cally; the program statement comprises terminal symbols, which the display calculation module treats as discrete objects, and nontetminal symbols, which the display calculation module treats as object groups. The discrete objects were each represented by a difgerent nodo of the parse tree. The display calculation module traverses or walks the parse tree node to node, from top down, attaching to each node the object data needed to position and render the graphical icon on the screen.
The specific sequence performed by the display calculation modtale is illustrated in Figures 20-22.
.. ~e displa~r calculation module traverses the parse tree in two passes.
During the Orsc pass, the module determines the s~~ of the graphical representation of the program statement: During the second pass, the display calculation module determines the 35~ COOrdinateS Of each iCOn t0 be placed Irl thB dieSplay window. ThIS
pfoceSS iS illustrated In Figure 20. Beginning at step X60; the parse tree pointer was passed to the display calculation . _.. ...... .. .,.,., ... .. ,.... _. . ....-.:~. . . , ..... ~ ~.r.~ . ._ ,..: . . ..a,:..;~~.... .,rna;, : , r" ? ,:f.,~ ., ~ . r .:W .~. .. ...... , .
, .. , . . .

WO 93/20510 ~ ~ PCT/iEi993/00754 module. It will be recalled that this pointer ultimately supplies access to each of the parse tree nodes as exempl'rfied by the parse tree data structure of Figure 19. For purposes of explaining the display calculation module, the parse tree of Figure 18 is reproduced as Figures 21 and 22 with additional information added to illustrate pass 1 and pass 2 of the display calculation procedure. .
Referring to Figures 20, 21 a and 21 b, at step 362, the display calculation module determines the size of th~ overall graphical represervtation of the program statement to be displayed. As further detailed at step 364, this was done by traversing the parse tree from top down and assigning boundary box sizes to each node. As previously explained, each graphical icon has a pred~tem~ined size. An imaginary 'boundary box' was drawn around each loon, fully enclosing it. The length and width of the imaginary boundary box thus denotes the predetemnined size of the corresponding icon.
By way of example, referring to Figures 21 a and 21 b, the parse tree was entered at the top; namely at the AND statement designated at A. The parse tree was then , traversed from A to B to C ... to R, following the arrows illustrated. Each discrete object encountered was assigned an ordered pair (x,y) of numbers representing the horizontal and vertical dimensions of that object's. boundary box. tn the case of an object which corresponds to a predefined graphical Bcon (such as variables and specie! purpose symbols), the boundary box size was predetermined and may thus simply i;~e assigned to that object:
Operators such as the relational operators, AND, OR, eta; were not themselves rendered as discrete graphical icons. Rather, they serve to group ether objects, hence the boundary box size associated with a relational operator was inherited from the other operators in that group.
By corwentoon adopted in the presently preferred ennbodiment, the AND
Qperator groups ~bjects by joining them hofrzontally: (Refer to Figure 8). The OR operator groups objects by connecting them vertically. (Refer to Figure 9). The XOR
operator groups objects by connecting: them vertically, with an additional X-shaped symbol added to rJistinguish °rt from the OR operator. (See Figure l0). The NOT (#) operator surrounds its operand; ~as illustrated in Figure 11. Finally, the bracket or nesting operator also surrounds the operand; as shown in Figure l2. Thus when two objects were joined by the relational ~1ND operator, the resulting boundary box must be large enough in the horizontal dimension to encompass the sum of the horizontal dimensions of the individual objects and must be . large enc~~agh in the vertical direction to encompass the verkioal dimension of the larger of the individual objects: Spec~catht, the formulas for computing the boundary box dimensions and pos~ions of objects grouped by the relational operators were set forth in Table V below.

V6~0 93/20510 PCI'/EP93/0075~
>~~~~- ~
~~BLE V
The AND relationship (see Figure 8):
W=W1 +W2+WD
H = max(H1-o1, Hz-ozj + max(o1, ozj O = max[01, ~2j X1 = x Y1 = Y + max(zero, oz-o1 j Xz=X+W1 +WD
Y2 = Y + max(zero, o1-OZj The OR reiatior~ship (see Figure 9):
.
W = max(W1, Wzj H-H1+H2+HD
p = 01 z0 X1 = X
Y1 = Y
~-X
yz=Y~:H1+HD
The XJR relationship (see Figure 10):
iM _ max~11V1, Wzj + WL
H .~ H1 + H2 + HD
30 O ..-- 01 Yl a Y
35 ~~X
YZ=Y+H1 +HD
The iVOT reiatior~.ship (see Figure 91).
~0 ~ ~ Wi f 2xWD + 2xW~.
Qr01+HD
~l = H1 + 2xHD
Xi _XC+WD+WL
Y1 = YC + HD
the breck~ted or nested retatior~hiQ (see Figure 12):
W _ ~1 + WDL + WDR
50~ ~=H1 p .~ ~i ~1 ...r r ~z .
Y
.. !
J.:..: !~. P_ .r..l rY
n . i . . _ ..o. . .
i ... .. , , r... ...;,<R. . . .t , P'3'.i..~.,. .;:._ ...... . .". ~.. s.,.:.. _....,r...., tJ'.1" ,.. . .... ...
. . . ,. . ,.. . .~,1 ,. _...:1 ,.... .. .. .. , ., ~ . ,. . , , .r , . . , w~o 93i2osio IPCriE»~ioo~sa X1 = X + WDL
- Y1 =Y
Thus, in the parse tree of Figures 21 a and 21 b, each node, designated by a capital letter, A-R, has associated w'tth it a boundary box size specified as an ordered pair of numbers for the horizontal and vertical dimensions of the boundary box. In the presently preferred embbdiment the STEP operator has a boundary box dimension of 10 horizontal and 8 vertical units. Thus the ordered pair (10,8) was indicated in the circle adjacent the STEP
operators at nodes C and D. The OR operator at node B inherits a boundary box dimension based on the children nodes C and D. Accordingly, the OR node at B has a boundary box size of (10,16) - using the formula of Table V above. In this regard, the boundary box dimensions indicated in Figures 21 and 22 have, in some instances, been approximated by omitting the H~ dimension, to simplify the arithmetic.
tJttimatety, when the entire parse tree has been traversed back to the starting node A, the overall boundary box size wilt have been determined. For the example of Figure 21 b, this size was (62,20): That malue represents the overall size of the right-hand side of the program statement. The presently preferred algorithm enters the parse tree below the equivalents operator IF. The left-hand side, or LVAL side of the program statement, STEP(~817) in Figures 21 a and 29 b, always represents a single object of known boundary box size.
Returning to Figure 20, the display calculation module next determines whether the overall size of the graphical representation will fit within the display window. This was performed at step 366. If the entire display will fit within the display window the display calcuBation module proceeds to the second pass, step 370, where the location of each graphical icon in the display window was detem~ined. tf the entire graphical representation will n~t fit in the display window; the hidden pipe algs~r'tthm was implemented, as indicated at step 368e Using Figure 21 b as an example, the hidden pipe algorithm will now be explained. As previ~bsfy noted, the right-hand slue of the program statement requires a boundary box of dimensions (62,20). Lei us assume that the display window will only permit a boundary box of size 07,20). The hidden pipe algorithm will therefore endeavor to replace a node of a certain size with the hidden pipe icon 182 (Figure 14) of a smaNer size. Irf the presently preferred embodiment, the hidden pipe icon has a boundary box size of (10,8).
Replacing a node of size (20,8) with the hidden pipe icon of size (10,8) will afford a horizontal gain of 1b graphical units. Similarly. replacing a rode of size (10,12) with the hidden pipe -~2-V!r~ 93/2(fSlO PCT/EP93/00754 ~~~~~~'3 icon will afford a vertical gain of 4 graphical units. Attempting to replace a node of size (10,8) with the hidden pipe icon would result in no gain, thus such a substitution was not made.
In this example, a horizontal gain of 5 units was required. Since nodes C and D were both equal in size to the hidden pipe icon, replacing either of them with the hidden pipe icon will not produce the desired increase in gain. Thus the hidden pipe algorithm abandons these two nodes. Similarly, node t3 was inadequate to provide the necessary horizontal gain required in this example. .
Moving on to node E, clearly eliminating that node of size (42,20} would provide more than enough gain - a horizontal gain of 32. However, etiminating node E
would significantly degrade the usefulness of the resulting display, by eliminating all nodes which were children of node E (that is, nodes F-R}. The hidden pipe algorithm therefore continues to node F, to node ~ and to node H, each time findirtg there to be sufficient gain.
Proceeding to the next node t, the resulting horizontal gain would be 4 graphical units. Since this would be insufficient to achieve the desired horizontal gain of 5 units, etimin~tion of node t will not work. Accordingly, the algorithm backtracks to the preceding node H, which was sufficient and then tests node J. Since node J
provides insufficient gain, the algorithm once again backtracks to node H. Since there were no other child nodes descending fir~m n~de H, node H was marked as a hidden pipe. Thus node H
and its children nodes t and J will be replaced with the single hidden pipe icon in the final display.
From the foregoing, it wilt be seen that the hidden pipe algorithm of the presently preferred embodiment will abandon a path if it will not provide sufficient gain. Also, because the parse tree was traversed from left to right, the presently preferred algorithm naturally favors the elimination of nodes more proximate to the LVAL. This was an advantage, because in most instances the nodes farthest from the LVAL were the more important.
Having detemnined the overact size of the graphical representation and having dea6t with the hidden pipe issue; as required, the display calculation module proceeds in step 370 (Figure 2~} to d~termine the location of each graphical icon in the display window.
80 This was done by traversing the parse tree a second time. AS indicated at step 5~2, the parse tree was again traversed to assign position coordinates and icon rendering data (for example, bftrnaps) to each node.
To illustrate this, Figure 22 shows the same parse tree as Figures 19, 21 a and 21 b, this time itiustrating how coordinates were assigned.. By traversing the parse tree in the same path as previously ittustrated, the f°rrst discrete object encountered was at node C. This object .was assigned co~rdinates (0,0}. Proceeding on to the next discrete object the WO 93/20~d0 ~~~ °9.~ PCd'/EP93/007~4 coordinates of node D was determined to be (0,8). This was so because node C
and node D
were grouped as children of the OR operator of node B. As previously discussed, the ~R
operator joins its objects vertically. Thus, knowing the boundary box size of the object at node D, its position was readily calculated to be in vertical alignment with the object at node C
but 8 horizontal units beneath it.
The same procedure was followed for each of the discrete object nodes until the coordinates of each object making up the entire display was known. These coordinates, along with pointers to the appropriate bitmaps for producing the graphical icons were stored in the data structure for use by the operating system windowing facilities in drawing the actual graphical icons on the display screen.
The above procedure causes a graphical icon coordinates and the information about what each icon looks like to be stored by attaching it to the parse tree or a copy of the parse tree. The presently preferred embodiment positions all graphical icons so that their respective incoming and outgoing lines or °pipes' will connect up. To account for the pcissibility that different graphical symbols may have different sizes, and hence their incoming and outg~ing lines may be at different relative positions, the presently preferred display calculation r~nodule associates with each graphical icon certain numerical values or 'offsets' which may be added or subtracted from the boundary box coordinates, as needed, to ensue that all i~tcoming and outgoing lines match up.
In other words, the coordinates detem7ined by pass 2 of the display calculatioe~ madule may be used to specify, for example, the upper left-hand comer of the boundary box: The actual on-screen Coordinates may need to be adjusted up or down from the upper left-hard corner coordinate position by the amount of the stored offset to ensure that the incoming arid outdoing lines of all adjacent and connected icons will properly match up. While the use of stored offset values for this purpose was presently preferred, other comparable techniques may b~ used instead.
Figdre 23 shows the physical layout of each of the discrete objects corresponding to the parse tree of Figure 22. For purposes of illustration, each object has been represer~tdd by a boundary box wkh its upper left-hand corner positioned at the assigned coordinates set forth in Figure 22. Each boundary box has been drawn approximately Ro scale, based on the (x,y) dimensions taken from Figure 21 b.
To simp9y the . .. .. illustration, tha stor~ad offsets applicable to individual icons have not been illustrated in Figure 23: For comparison purposes, the graphical icons display of the statement represented by Figuree 1E~, 21-23 is shown irD Fige~re 7b.
Tha 1'nre data module was responsible for collection, storage and conversion (formatting) of the real time values of all process control computer variables that were preseryt V!~~ 93/20510 PCT/EP93/00754 ~~~~~~~1 in the currently displayed program statement. (See Step 330 in Figure 16b).
The parse tree contains the list of al! variables which were being displayed. This list was used in making a call to the operating system by which the actual live data being collected by the process control computers (for example, 104 and 106) and transmitted through the communication interface subsystems (for example, 108 and 110) to the computer or workstation which. was running the process control display program of the invention.
In practice, the live data may be collected by the process control computers in an asynchronous fashion. Thus the I'~re data module of the preservt program preferably obtains this tive data by creating a subprocess which was responsible for requesting the fNe data synchronously, but in parallel with the process control display program of the invention.
The subprocess signals the completion of the live data request so that the main program can be triggered or ir~terrulated asynchronously. In this wary, the rest of the process control display program can remairro operative, without having tb wait for live data to be collected. Once collected, the live data was passed to the real time evaluation module which was responsible , for determining the appropriate visual quality to be applied to each of the graphical icons and their interconnecting pipes or lines.
As previously indicated, a visual quafdy, preferably color, was used to denote the real time state ~f each g~aphicai icon in the display window. Assigning the proper visual quality or color to ea~tt of the icons therr~nsselves was relatively straightforward, based on the five data obtained by the live data module. However, the process control display program does more than simply dynamically apply the appropriate visual quality or color to each icon on a periodic or real time basis. The proee~s control display program of the invention also detem~ines and applies the' appropriate visual quality or color to the incoming and outgoing dines or pipes associated with each graphical icon.
26 for example, in the simple expression shown in Figurd 7a, the lines or pipes incoming ~rariabtes DIt100) and DI(101) were shaded TRUE. Because the variable Di(100) was currer~tiy shaded FALSE, the outgoing lines bf that variable was also shaded FALSE.
Conversely, because the variable DI(101) was shaded TRUE, its outgoing line or pipe was also shaded TRUE. As illustrated, this same TRUE logic flows through digital variable DC(100).
Thus the plant operator can readily determine that the variable DC(100) was TRUE because the variable DI(101) was TRUE.
.. ~y siding or coloring the pipes as well as the graphical icons, the operator can quickly trace the logic flow corresponding to a program statement. in Figure Via, if the plant operator was expecting the variable DC(100) to be FALSE, but found that it was not, the 36 reason would be irnrnediately clear. ~y tracing the TRUE (BLUE) color back from variable DC(1~0) the'source° of this TRUE logic was immediately apparent -variable DI(101).
~5-1~V~ 93/20~d0 PC't'/EP93/00754 ,~~~ ,4, The real time evaluation module was responsible for producing the proper visual qualities or colors for all of the graphica! icons and their interconnecting pipes. The real time evaluation module was retied as soon as the live data module has indicated that the last live data request has been successfully completed. !n addition to determining the visual quality or color of alb icons and pipes, the real time evaluation module must also take hidden pipes into account.
-The presently preferred real time evaluation module was set forth in the source code listing in Table Vi below which has been written in the C language. The entire source code listing for the real time evaluation module has been provided to allow those skilted in the 1 o art of computer programming to fully understand how the presently preferred module was constructed and how 'tt operates. The source code listing of Table VI oppears at the end of this spec~cation preceding the appended claims.
Although the dynamic control of visual quality or color of the icons themselves was comparatively straightforward, evaluating the visual quality or color of the incoming (left) and outgoing (right) Ilnes merits ome additional discussion. In this discussion the terms °line°
and °pipe° ware synonymous, unless otherwise indicated. The tine coloring algorithm noses two pen colors, a °currerrt' pen color and a °stored° pen color. The stored pen color was retained on a per node basis in the parse tree. in the source code 1'vsting the current pen color was id~nt~od cur colour and the stored pan color was ident~ed static cotour. The ~p stored den rotor (staticPcotour) may be allocated as a static variable and was initialized to SLUE when first eveiuating the incoming lines (left lines). The current pen color (cur colour) may be allocated on the stack.
Ti,e teat time evaluation module (FtTEVAL) includes an incoming line evaluation procedure, E>JAL.~LEFt UN~SQ and an outgoing line evaluation procedure, ~5 EVAL FiiGi°iT LINESQ, Arguments to EVAL_LEFT LINES were to the node pointer NODE~PT
of the parse tree to oe evaluated. Secause the routine was recursive, this wi!! be the subtree associa~ad with a node as the parse tray was descended.
procedure EVAL LEFT LINES first makes a local copy of the SVALUE of the current node. if iha ourrertt node was an OR and if it represents a hidden pipe, the local 30 SVALUE was made so that the hidden pipe object may be property handled.
The left line was stiways colored in the stored pan color (static colour). Th~
right line was colored according to the relation, static bolour AND cur colour. That is, the right line was BLUE if and only if the pen color was SLUE and the object was BLUE. The right line was not colored if the cu~rartt object was an bR or en XOR or an X~R
relationsh'sps ware S5 fitted in by the EVAL,~RIGi-1TT LINES procedure.

wo 93izos~~ Pc-ri~~3>oo~sa The XOR operator was a special case because it includes a displayed object, an X-shaped symbol added to the icon. The color of this additional X-shaped symbol must also be handled.
The delay timer, when TRUE, can require the outgoing tines to be TRUE even though the incoming pen color was FALSE. That was so because the delay timer serves to delay the flow of togic'which vacs otherwise proceeding along its pipe.
When evaluating the children of a current node, the pen color was first saved on the stack. If the current node was a NOT, the pen color was set to BLUE
(TRUE, because a statement inside a NOT was evaluated separately from the enclosing statement.
The EVAL~LEFT UNES procedure was called for alt children.. tf the current node was an OR, the pen color was reset to BLUE after each child. The color was set to its previous value when finished with the NOT operator. When alt of the children have been evaluated, the current node was checked to see if it uvas indeterminate (that is, bad data) for which the pen color was set to grey. If the parent of the current node was one of the , following: the ANf7;operator, a FOR operator or the top node of the parse tree, and if the pen color was BLUE and if the current node was ORANGE, the pen color was set to ORANGE.
Note that this was the o~tly way in which the pen color can become ORANGE, unless the pen color was restored from the stack by an OR operation higher in the parse tree.
The presently preferred routines set an update flag to Indicate if the tine cgtors have been changed. Thus, although the live data module may poll the process control computers on a periodic basis, the display was only redrawn if it was necessary to change visual quality or colors.
The E1/AL_RIGt-tT UNES~ procedure was specifically designed to evaluate the right-hand lines outgoing from OR nodes. This procedure was required because the OR
color can only b~ evaluated after knowing;att of 'tts children, including their children. if a node was an OR or XOR, and its parent was not an OR, the right tine outgoing from the OR node will have the same color as its right-hand child. Visually speaking, this OR
was the lowest OR
in this subexpression, and its right-hand child was the lowest child. The pen color was set t~ this color.
tf he node was an OR and its parent was an OR (that is, this OR was above another OR on the display) and the pen color was either grey (indeterminate}
or BLUE, the .. d~ht tine of this OR w~ drav~rn in BLUE. That way, BLUE will 'f6ow up' the OR as required.
tf the pen color was ORANGE, the right-hand line will be drawn like the bottom level OR (that is. 'tt will inherit the ~I~ of its right-hand cl~itdy, S5 pier eolc~ring the right-hand lines, the program checks to see if the current node was a hiddee~ pipe. if it was, the colors of the hidden pipe object were copied through ..~~_ '30,.~~ ,~..
to the hidden node. If the hidden node was an OR, a special treatment must be performed on the OR on the right-hand line outgoing from the OR symbol.
I°or a more complete understanding of the real time evaluation module, the readec is invited to study .the source code listing of Tabie Vi.
Whiie the process control disptay pragram has been illustrated and described in connection with the presently preferred embodiment, ft wilt be understood that the invention is capable of cerEain mod~cation without departing from the spirit of the invention as set forth in the appended claims.
T~4BLE YI
to Copyright The Dow Chemical Company 1992 #include <stdio.h>
1S #include <stdtib.h>
#include <ctype.h>
#include 'd include:mtree.h' #include 'd includeaistemngr.h"
#include 'd_include:parser.h' 20 #include 'd dispcatc:graphl~alc.h' #include 'd include:disptay str:h'' #inciucle 'd inciude:livedata.h~
/*#inctude 'd_livedataad_private:h'*!
25 #include °tJ_include:dispcaic.h' #include 'd_include:message~rublic.h' #include 'd dispcalc:dispcatc~ate:h' #include 'd include:rtevat:h' 3Q #ifndef MIN
#define MIN(a, b) ( ((a) < (b)) ~ (a) v (b) ) #end'rf ~5 ~x Forvvard declarations */
static G~aphicaNaiue Eval~Subtree(node_pt logictree);
extern double fabs(double x):
4o static rteval detaug _ -1;
. ;: #define DEBUG_VERBPJSE 1 ~d~ne DEBUG ONES 2 #define DEBUG_RUNES 4 45 #define DEBUG_NOGREYOU'~ 8 #defOne DEBUG N~COPYHIDDEN 16 #ifdefi MAllo~_TESI' #include 'd~inctudemailocstest.h' i~V~ 93120510 PCT/EP93/007~4 #else static void *talloc(unsigned int site) void *block;
block = malloc(size);
if (block == NULL} f 11AS0 Log("Error: Out of memory in buitd.c\n');
exit();
i 0 return block;
#endif /*#define _~ISCR R(p} ((discrete pt)DRAW OBJlP((p))->discrete_p)*/
~5 static void SwapHidden(node~pt nodeep) draweobject'pt topobject~;
draw object_pt bottomobject~;
topobject_p = DRAW OBJ P(node_p};
bottomobject_p ~ t~pobject_p->hiddenob~p;
2~ ~ (~ott~rnobjbct~p l= NULL} ~
topobjec2sp->hiddsnobj_p = bottomobject_p;
bottpenolaject;_p->hiddenobjsp = topobject~p;
pR~IAI,O~I~P(node~r} = bottomabject~p;
30 }.
StatlC vOld Eva! (~r~youtObject(drav~r object~pt drawobject) struct DisplayBase *BaseObject;
if (draw~object != IJULL) {
i3asea~ject = clrawobject->discrete~p;
40 f3ase~bject->obj[t].Colobr =Grey; /* left hand line */
Bai~eC3bject->~bj[i].ChangedLi~e~~ta_Ib = 1';
ga~aObject-a~bj[2].Cblour = faray; /* right hand tine */
BasgObject-~obj[2].ChangedLive~ata lb = i;
static node~t ~v~lrGr~youtNode(ne~d~~pt node) 50 ~ , draw obje~t.,pt drawobje~t;
draw~6je~t ~ D~UV_oBJ P(node);
. .. ,: . ,;. T~''' .'.~-, >. : ,~ ;; . .:'~,.,~ __ _ ,. ,. ._ . . , ,., ,, ..
.~.~
i. , e'.
5 a.
~.,f.>..:.,... .. .. .., ... . ~..... .,. . , ... . ... ._ , .... ...,.. ..

W~ 93120510 ~y'~ PC1'BEP93/0075~

6~~~~
if (drawobject != NULL) {
E~al GreyoutObject(drawobject);
if (drawobject->hidden != 0) f SwapHidderi(node);
drawobject - DRAW Os.f_P(node);
SwapHidden(node);
Eval GreyouiObject(drawobject);
}
return node;
}
static void sval Greyout(node pt logictree) int aap = -1;
if (rtevat debug & DESU(3 NOGREYOl.tn return;
MT walk bottom-up(Icgiciree, Eval GreyoutNode, 8aap);
} - _ static GraphicaNaiue Eval compose(node pt node p) f - -Obj Type tYPe;
Graphicatl/alue colour;
draw objectspt chi!d1;
draw~object_pt child2;
#d~~in~ cHIL~_cO~ouR(x) v (((Struct ~isplay~ase *)((x)->discrete~))->obj[0).C~lour) chi!d1 - DRAW OSJ-P((node pt)Lm-DATA 1~P(node p->chi!dren list));
((CHILD C~L.OUR(chi!d1) < Grey) I I (CHIL.,D-cOLOIdR(chi!d1) > sloe)) AIISG~Log('Invalid colour 96d!~n°, CHILD-COLOUR(childi));
rf (CHILDwCOLOUR(chi!d1) _-- Grey) r~t~m Grey:
~5 t* Pfocess unary parse nodes */
switch ( SEiV!-P(node-p)->svafue ) case 'a~' colour = (CHILD COLOUR(childl) ~= Orange) 5p ? slue :. Orange;
return colour, cue '[' cohur = CHILD-COLOIJR(chi!d1);

i,~t~ 9/20510 PC1'/EP~3/00754 ~~~0~0~
return colour;
/* If dare came here, eve must have a binary parse node */
child2 = DRAW_OBJ f~((node_pt)Lm DATA 2 P(node_p->children list));
if (CHILD COLOUR(child2) _= Grey) return Grey; .
suritch ( SEM~,~,(node p)->svalue ) ~ , case for colour = (CHILD_COLOUR(child2) _= Blue) ? Blue : Orange;
break;
case and colour = ((CHILD COLOUR(childl) _= Blue) &&
(CHtLD_COLOUR(child2) _= Blue)) ? Blue : Orange;
break;
2o case °~C~!~ur = ((CHlL.D_COLOUR(childl) .= Blue) i ~
(CHILD COLOUR(child2) _= Blue)) ? Blue: Orange;
break;
~5 case _xor:
colour = ((CHILD COLOUR(chitdl) _= Blue) (CHIL.D_COLOUR(child2) .= Blue)) Blue : orange;
break;
default NISG_Log("R'f'EVAL->Eval compose: Invalid svalue ~dln", ,EM P(n~de_p)->svalue);
return colour;
35 }
static Graphical~/ahae cornpare(ftoat a, float b, char *operator, float *pc1 blue) Grapl~ticalllaiue refuel;
refuel ~ Cre~;
switch(op~ratar[~j) ~~ ~
case 'E':
. .. ,f (~rcmp(operator, "Et~') == f~l ~
retva! _ (a == b) ? Blue : Orange;
*pct !olue = (a =_ b) ? 'l.o : B.a;
~o ~
break;
~a~e.'~'.
if (strcmp(operator, 'G~ _= 0) ~
-5i-,~ , , .. ..,, ; :_ .:
... .,. . . .. . , ,.. . ... T... ~:.. ., .. . . ,.... ,. ., . .. . ... .. ..

Wp 93/20510 PCi'/EP93/00'~54 ~,J~.~,-retval = (a > b) ? Blue : Orange;
*pciibiue = MIN(1.0, (i.0 - ((b - a) / 2.0))); _ else if (strcmp(operator, 'GE') _ = o) ~
retval = (a >= b) ? Blue : Orange;
*pct blue = MIN(i.0, (1.0 - ((b - a) / 2.0)));
break; ' case '~':
io if (strcmp(operator,'!.1') _= 0) {
refuel = (a < b) ? Biue : Orange;
*pct blue = MiN(i.0, (i.0 - ((a - b) / 2.0)));
else if (strcmp(operator, 'LE') _= 0) {
refuel = (a < _ b) ? Blue : Orange;
*pct blue = MIN(i.0, (i.0 - ((a - b) / 2.0)));
break;
case 'N':
20 if (strcmp(operacor, 'NE') _= 0) f refuel = (a i= b) ? Blue : Orange;
*pct blue = (a t= b) ? 1.0 : 0.0;
break;
/* percent blue teas than zero can only happen foe variables w~h * a sceis value smaller than the actual value. if so, the colour * will be grey.
~~ *f if (*pct blue < O.a) retvai = Grey;
ifi (refuel ~ _ grey) 35 *pct blue = -1.0;
return retvat;
static GraphicaiVatue 40 Eval discrete object(node~pt noderp, struct Objecitnfo ds *oi) GraphicalValue colour;
float templf; tsnnpi f, femp2 f, temp3~f;
45 /* Test for bad data Deviations have three values: */
if (DR~dV_~BJ~,P(nade~p)-atype == DICE FUNO~,obj ~&
(nod~~p-achildren~list ~= NULL ~ ~
~M_~~(nod~~p->chitdren list) != 3 t B
L,D_IsBad(oi->MocJvar2->Vaiue~~ ~ ~
~0 ~ LD isBaci(oi->Mod~ra~->Value ~)) ~
oi-~PercaettBiue fi _ -1.0;
tetum Corey;
_~2-Wd~ 93f205A0 i'CT/EP9310075~
/* A comparison has two values: */
_ if (~f~AW OBJ~P(node p)->type == COMPARE obj &~
LD IsBad(oi->Modvar2->Value ~~
return Grey;
/* But all objects have a first value: */
if (LD IsBad(oi->Modvarl->Vaiue f)) return Grsy;
/* If w~ come here, we have valid live data */
switch ( ~raAw ~BJ_P(node~)->type ) case OIG VAS obj:
case ~!G VAR W~4TCHED obj:
case STEP obj:
if (oi->Modvarl->Value f == 0.0) colour = Orange;
else colour _ Blue;
break;
case CT obj:
2~ 'rf (oi->Modvarl->Scale f == 0.0) colour = Orange;
else colour = Blue;
B0 oi->PercentBlue_fl = (oi->Modvart->Value t);
break;
case ~iGa~UNC obj:
( (nodeap->Children_list I= NULL) &&
~5 SBM,-P(node p)->svalue =_ dev &&
Lm~fTEM CNT(nodelp->children list) _= 3 ) ;~ ~~~->Modvar~->s~al~ t == o.o I 1 ~o ~i->Modvar2->Scale f == 0.0 I I
ow>Modvar3->Scale f =_ 0.0) {
tempt f = tempt~f = tempi f = 0.0;
oi-aP~rcerttBiue f! _ -1.0;
colour -= trey; r 45 break;
tempt f = oi->Modvael->Value f / oi->Modvarl->Scale f;
terrap~ f = oi->ModvatZ >Value ~ ! oi->Modvar2->Scat~ f;
ters~p~ f = oi->i~Aodva~>Value f / oi->ModvarS->Scale f;
50 if -(fabs(temp~ f - terirp2 ~ > tempi colour = Biue;
else colour = Orange;
-~3-!A'~ 93/20510 PCT/EP93I0075d if (temp3_f != 0.0) {
temp f = fabs(tempi'f - temp2_f) f fabs(temp3ef);
if (temp f > 1.0) temp f = 1.0;
g if (temp ~ != oi->PercentBlue fl) {
oi->PercentBlue ft = temp f;
oi->ChangedLiveData Ib = 1;
}
} else {
ip oi->PercentBlue fl = -1.0;
colour = Grey;
}
break;
1~
case C4lvtPARB_obj:
if (oi-aModvari->Scale f == 0.0 ~ j oi->Modvar2->Scale f == 0.0) {
tempi_f = tempt f = 0.~;
~0 ~ colour = Grey;
freak;
}
tempi,~f = oi->Modvari->ualue f / oi->Modvari->Scale f;
tempt f = oi->Modvar2->~Palue f / oi->Modvar2->Scale f;
25 col~u~ _ compar$(tempi f, tempt f, oi->tdtodvat'33->Narn~ c, &temp ~;
if (temp f != oi->Percentt3lue f~ {
oi->PercerttBlue 0 = temp f;
oi-a ChangedLiveData Ib = 1;
30 break;
default:
MSG Log('RTE~IAL->Eval~,discrete: Invalid object type (sv: 96d\n', 3g SBM_P(node_p)->svalue);
return colour;
40 static node_pt 6val~,object (node~t nodeip) int i;
struct DispIaySase *newobj;
45 struct GbjectlnfQ ds *cur, *lefttine, *righttine;
~b~Type tyPe~
. . GraphicatlPajue t<otour;
if (node_p ~ = NULL) {
50 MSG_Log(°idUial.. node_p in oval object\n");
return;

l~VC19312~510 i'~T/EI'93/00754 if (DRAW OBJ P(node p) _= NULL) /* No drawobject means */
return node,~p;~ /* no action _ */
newobj = DRAW 06J P(node_p)->discrete_p;
cur = &newobj->obj[~j; /* The object itseff */
leftline = &newobj->obj[1J; /* The Ielt hand linepart */
rightline = &newobj->obj[2j; /* 'The right hand linepart */
' switch ( DRAW_08J P(noderp)->type ) case DIG VAR obj:
case DICa -VAR HATGHED,~obj:
case STEP obj:
case DT obj:
case DIG FUNC_obj:
case COMPARE obj:
colour = Evat_discrete object(node_p; cur);
break;
case ~11DDENdobj:
colour= ~val_Subtree(node_p);
break;
case COMPOSE obj:
colour = EvaP compose (node p);
break;
defiault:
~SG~Log('RTEVAL->Eval object: Invalid object type (sv: 96d)in', SEM P(nod~ p)->svalue);
ff (cur->Colour !_' colour) $
cuf-~Cniour = colour;
cur-aChangedLiveDat~ Ib = ~;
return node p;
static C~raphic~IValeae Eval hrar (node~,pt r~bdep, ~raphicaNaiu~ statement~coiour) ir~t i;
1'toat temp f;
struct ~isplayBase *new~bj;
. ~ .. struct di~~Caic,~lvar *Ivar object;
sy~~ Objecttr~#o_ds *cur, *le~iine;
5p Obj~fi~pe type;
GraphicalValue c~four, left colour if (noderp == tJULL) ~

WO 93/20510 PCg'fE1P93/0075A
MSG Log(°NULL node~p in eval lust\n°);
return;
_ }
if (PARSI=__P(node~p)->tok svalue.tok_sem p->vartype != digital return; /* V~Je on~r colour digital variables */
lust object = (struct dispcalc Pvar *) DRAW 08J P(node'p);
newobj = Ivar object->Ivarbase;
cur = &newobj->obj[Oa; /* The object itself */
leftlins = ~newobj->obj[1]; /* The left hand linepart */
if (LD_IsBad(cur->Modvarl->Yalue ~) ~
colour = ~arey;
1 s } else {
if (cur->Modvari->Value f == 0.0) colour = ~range;
else colour = Biue;
if (colour != cur->Colour) ~( cur-aColou~ = colour;
cur->Changedl.iveCata Ib = 1;
}
i1 (statement colour =_ cur->Cotour) left colour = cur->Colour;
else left coBour = Grey;
(Belt-color ! = leftlina->Colour) ~
leftlirie->Colour _ colour;
leftlirte->ChangedLive~ata Ib = i;
return colour;
static char descrrbernode(1nt svalueo char *name) 4S stat's~ Char buf[100];
ft (~~me[0~ .- '.c' && svalue a 32 ~& svalus < 128) . ., ~ps'ir~(buf; '%d ('%c')°, svalus, svalue);
e0se ~prlni~(buf, '%d (%S)°, S°V'dlue, name), 50 return bui; , }
static ~r~aphic~~latus :,,,-;.
,::.
y. g :, ,~ q , r .Tr.;.fr-.' rl .. ., r..:. a ., 1 .:..,., -:~,r ...: m. > ..~ ;F~
.r .. ~' ..
.. , , r r .. . , ..;,~.~t. : " . . , ..,; .
_ , .. ~ ;. > ,. .. , ~'... .~':.:.~,~... .,...,...,. ...w...r.,",~.... ..... . .._.._..,.,.z~~~d:.
..,. .... ,_..... . t._.... . .. .. . , . ,. .....,, ,......... ...,.... . .
.., , PVC) 93/20510 ~ ~ ~ ~ ~ ~ ~ P~'1EP93/00754 Evai~left-lines(node_pt node p, int parent svatue) int i;
ant SVatt,le;
static ~int depth = 0;
static GraphicalValue static colour;
/*auto*/ GraphicaNalue cur colour;
/*auto _*/ Graphicafi/alue old left colour, old right colour;
struct ~isplayBase *newobj;
struct Objectlnfo ds *cur, *leftline, *righttine;
/* Catl Eval lines(node_p, -500) to init static colour. We need a better */
/* mechanism for this. */
if (parent svalue _ _ -500) f static colour = Blue;
(p~~ OBJ P(node~p) _= NULL) /* We ignore non-drawing objects */
return;
svatue = SEM P(node p)->svalue;
if. (svatue == ~or 8~& DRAW OBJ P(node p)->hidden != 0) svalue = 0; i* treat hidden as discrete object */
new~bj _ DFiAW~OBJ P(node_p)->discrete p;
cur = &newobj->obj[O]; /* °fhe object itseEg */
lefttine = S~newobj->obj[1]; /* The left hand linepart */
righttine = ~newobj->obj[2j; /* The right hand linepart */
~f (rt~valwdebug ~ ~EBUG_uNES) nl9BG Log(~%*s Pre. Obiect 96s c~lour R6s pen 96s left 96s nght 96sln", ~'~deptl~a~" ~, ' ~, descrabe node(svatue, cur_>tNodvari->Nam~ c).
~S fofm~t cotour(cur->Cotour), f~rmat cotour(static_colour);
farmat coloue(leftline->Colour), formal cot~ur(rightline->Colour));
40 /* pre action */
o!d left cotour = lefttine->Coiour; /* remember the colours */
otd~right colour _ rightline->Colour; /* on th~ stack */
leftline-aCoiour = static colour;
~5 if (svatub != or &~ svalue != xor) ~
ri~htlfne-aCotour = tef2tine->Coloure w .. if (cur-~Coiour == Orahge &~ teftline->Cotour == Blue) rightline->Colour = Orange;
of (cur->Cotour == Grey) 50 rightline->Colour = Grey;
if (svatue == xor && static co9our == Orange ~~

wvo 9m2oslo Pcri~~~eoo~s4 ' i~
CUr->CO!OUr == B!Ue) CUf->CO!OUP = Orange;
cur->ChangedhveData Ib = 1;
if (svatue == rdt 8~& static colour != Grey) ~( static colour = cur->Colour;
rightline->Calour = static colour;
cur colour = static_coiour; /* Save the value on the stack */
if (svalue _ '#') #ifdef NotDef if (static_colour != Grey) static colour _ Blue;
~ 5 vise cur-aStatic colour = Grey;
#eise static colour _ Blue;
#endif -}
if ((node p-ychildren,~list !-- idUU_) ~&
(!Lm UST EMPTY(nodeep->chiidren list)) Lm,~Gatott~r~(node_p->childrer~~list, FIRST) ; .
for (i = 1; i <_ Lm ITEM CNT(nodssp->chiidren list); i++) ~
depth++
(void) Eval_left~lines(Lm_DATA P(node_p->chiidren list), svaiue);
depth--;
if (svaiue = _ or) static_colour = cur colour;
Lm_Nextitem (node p->ci~itdren list);
/* post action */
-#rfdef NotDef if ((svalue =_ #,) 8~~ (cut_colour _- Orange)) staticrcolour .= Orange;
#else i~, ((svaiue =_ °#') 8~~ (static~col~ur !._ Grey) && (cur colour !=
Grey)) static~colour = cur_cotour;
#endif if (cur >Colour =-- Gfey) staticecolour ~ Grey, if (rteval~d~bug & DEBUG_UNES) MSG_Lc~g('96*s Post: Object 96s colour %s pen 96s !eft 96s right Xs\n°.
2*depth+1, °';
describe_nod~(svatue, cuf ~Modvah->Name c), forrnat_cotour(cur >Coiour), format cohur(static c~iour) format_colour(ieftline->Colour), r f-:, ~; .
.~ s.
nrfr'I. ~. .fi.. T 1 f...y ~.y' .~21.ri...l.'t :. t. Pd':'-1 .~
a . ~r . . , r . . . . . , s , . . r ... r ..
~(~'~'~ix..., eo...,J.s_.m........ .... ."........J.lC.ise.u,~., , "n m ,..
....... ..e ......s .r...:~.t....._".~u....,., roma , r ....... ~..u~', ...,..
.,5..,.,,.. . ,..w., . , t .,... r , r VVO 93/0510 ~ ~ ~ ~ ~ ~ .l P~.'T/EP93/00754 format cotour(rightline->Colour));
il ((parent~svaiue = and I j parent svalue =_ _t~r I I
parent svalue = _ -500) $,8~ cur->Colour == Orange 8~& static colour == Blue) static colour = Orange;
if (old_lett_colour != leftline-aColaur) leftline->ChangedL.iveData ib = 1;
if (old right_colour != rightline->Colour) , - rightline- _>Changedl-ive~ata Ib = 1;
return static~colour;

static void copY~hidden~;calours(node_pt node) node,_pt rightchi!d;
DispIayBase *subtree obj, *hidden_obj, *child_obj;
struct -struct Objecttnfoeds *chi!drighttine;

~5 if (rgeer~tl debug & DEBUG NOC~PYI-IID~EN) return;

hidden obj = ~i~AW OBJ P(node)->discret~_p:

awapHidden(n~de);

subtr~e_obj = DHAVlt OB,!_P(node)->c9iscrbt~ p;

SwapHidder~(node);

if (DRAW_OBJ~P(node)->type !_ ~IDDE~ obit hidden_colours: no hidden item ai top of tree!\n'):

35 ~BGwLog("\007copy_ obj->obj[1].Coio~r != hidden_obj->obj[1].Colour) ~
if (~ubtree _ obj->obj[1].Changedl-iveDaia Ib = 1;
subtree _ subtree_obj->obj[i].Colour = hidden_obj->obj[1].Colour;

obj->obj[2).Colour it hiddert~obj-aobj[2].Colour) ~
rf (subtree ~ _ subtre~ ~bj->obj[2).ChangedLi~eData_ib = 1;

0 subtree_obj->obj[2].Colour = hidden obj->ob][~].Colour;

/* We then correct the colour ~f a hidden ~I~ node *!
(this gets */

~ ugly!) We have to do this after copying the colours *
to the 4~ /* discrete object because the line has to represent /
the *

. /* '(OR-nods && pen-c~I~ur) in the ~a~e c~f the hidden/
pipe *f . *
in which case it mgt be true when the OR is true, /* ~bject , /
~: ~,h8~e~ ~ must have the special OR line treat~aent *
when /* viewing that same line ~s par't of a hidden OP. !
Sorryl 50 ;f (SEA P(nodl~)-asvalue _- or) ~
2 I'(node->children list):
DA1"A
t)I.m ode ~

~
_ ~p (n rightchild child_obj = DRAld6~ ~BJ_P(rlghtChilii)->discrete~,p;

-s~-W~ 93/2USf0 PCT/EiP93l00754 childrightline = &child obj->obj(2];
if (subtree~obj->obj(2].Colour == Blue &8~
childrightiine->Cotour == Orange) {
subtree_obj->obj(2].Colour = Orange;
subtree obj°>obj[2].ChangedLiveData Ib = 1;
static GraphicaNalue Evai right iines(node~pt node~p, int pared svalue) int i;
int svalue;
static void do DumpBase(struct DisplayBase *bbj');
static (araphi~afValue static colour;
/*auto*J C~aphicalValue bld right cblour;
Z0 struct DisplayBass *newobj, *childobj;
struct ~bjectlrifo~ds *cur, *leftline, ~rightline, *childrightline;
node_pt rightchild;
static int depth = 0;
~5 ;f (DRAyy~OBJ ~(node_p) ~- NUU_) !* ~e ignore non-drawing objects *!
return Grey, svalue -= SEM_P(node_p)°>svalue;
if (svaiue -= or && DRAW OBJ P(node_p)->hidden i= ~) 30 svalue = ~; /* treat hidden as discrete object *J
newobj ~ DRAW OBJ P(node_p)->discreta~p;
cur ~ ~ne~wobj->obj[0]]; /* "fhe abject itself */
hfttine ~ &newobj->obj[i]; /* The 9eft hand iin~part */
35 rightline = &ne~robj->obj[2]; /* 'the right hand iinepart *1 (rteval,~deta~rg & DEBUG RUNES 8~& (!(rteval debug & DEBUG UNES))) MSG Ldg(°96*s Right pre: Object 96d (96s) static colour %s left 96s right 96s1n~, 40 2*depth~l; " ~, - .
~yaiue, cur->fiPlodvarl->Name c, format coiour(stati~ colour), fam7at cotaur(teftiine-yColour), format colour(rightline->Colour));
,* pry action */
o6d~r9ght colour _ rightline->Colour; /* remember the colour *!
if _(svalue =_ br &8~ parent svalue == wor &~
.. (static colour == trey f ~ static~colour == Blue)) {
dgmlina->Colour = static colour;
~0 ~ else if (s~ralue = = ~or ( I svalu~ _= xor) {
rightchiid = (nodespt)lsn DATAe2 P(nodeap->children list);
childobj = DRAWa0B,1 P(rightchitc~j->discret~ p;
.~ifidef NiORE DEBaJtaCaBNCa W~ 93/Z0510 s P~'/EP93/00754 MSG Log('Dump van or node:~n°);
_ do~DumpBase(newob~~;
MSG_Log(°Dump van rightchild:\n°);
d~ DumpBase{chitdobj};
# endif chi!drighttine = 8~chitdobj->obj(Zj; .
/*if (chitdrighttine->Cotour == Blue)*/
rightline->Cotour = childrightline->Cotour;
90 }
static colour = rightline->Cotour;
if ({node_p->children fist != MULL) &&
{!Lm ListEmpty{node_p->chitdren list))) f LrnlGot~ttem(node_p->children list, FIRST') ;
for (i = 9; i <= Un ttemCount(node_p->children list}; i++} f depth++; _ Evai~right_lines(Lrn DATA P(node_p->children Pist), svatue);
depth-;
Nextttem(node_p->chitdren list};
/* post action */
if (old right colour != rightltne->Cotour) ~5 ~ rightttne->ChangedLiveData Ib = 1;
I* Copy the colours through to the discrete hidden object */
if {DRAIIlI,~OBJ_P(nodeep)->hidden !_ ~) copy hiddencotours(node_p);
if (rteval debug & DEBUts RiINES) i~tSC_Log('%*s right post: Object °~s colour 9'°s pen %s left %s right %s\n', 2*depth+i, ~ ~~
deSCflbB_node(SVaiUe, cUr~>Modvar'I->t~iame c}, 3~ format_colour(cur->Golour), f~rmat colour{static colour), format cotour(tefttine->C~lour}, ~o~at colour(rightline->Colour));
40 return static colour, static t~raphi~a!Vatu~
E~ai Subtree(riod~ pt togictree) ~5 ~
int tree depth = -$;
.. Grapttie~l<lalbe left, right;
struct DisplayBase *subtree obj, *hidden obj;
50 hidden~obj = DRA~A1 OBJ,~P(logictree}->discrete~p;
SwapHiddert(togictre~};
if ((s'te~a8ad~bt~g ~ DEEUE~ ioERE3~SE) &&
DRAlN ~l3elf P(logictree)->type != C~MP4SE ~bp~
-6~i-wo ~~szos~o PcriE~~eoo~s4 .;_ MSG Log('Eval 6ubtree: discrete item at top of tree!~n");
MT walk bottom_up (logictree, Eval object, 8~tree depth);
subtree_obj = DRA1~!_OBJ_P(logictree)->discrete_p;
SwapHidden(logictree);
return subtree obj->obj[0]:Colour;
StatIC VOld Eva!_expression(PARSEF~ statement pt parsetree) list_pt evat list; .
Gong *fakelistpoirater;
struct dispcalc Ivar *Ivar object;
int labeftoken;
labettoken = PARSE P(parsetree->lett var_p)->label token;
if (labettoken == T SUBR ~ ' parsetree->ana expr tree_p t= NULL) {
Ivar object _ (struct dispcalc Ivar *) ~RAW ~BJ_P(parsetree->left var,_p);
ifi (brat object->expression !'gist l= NULL) R'fEVAL EvafuateExpression(Nar object->expression list);
VOid RTEVAL EvaluateColours(PARSER_statement_pt parsetree) node pt logictree;
CraphicaN~fue statemerte colour, Nat colour;
rf (rteval debug =-- -1) rtevat rl~bug = gel debug flag(°RTEVAL DESUG°);
Eval expression(parsetree);
logictree .~ p~rsetree->~log exp~ tree_p;
it (logictrbe == NULL) ~
(~eval~~ebug & C?EBUta VER~O~E) elf RASG_Log(°RTEVAL Evalu~teCofors: NULL logic tree!~n')i rett9rn;
(void) Eval Subtr~e(logictree);
~5 statement colour = Eval~fett fines(logictree, -500);
(void] Eva! right~llnes~logictree, -499);
.. Pvar colour = Eval Ivar(parsetree-aleft var_p, statement colour);
if (PARSE P(parsetree->iett var_p)->tok svaluetok sem_,p->vartype .= digital &~
50 hrar,~cotouc t= Grey ~&
staterrient colour 1= Gr~y ~~
fvar colour t= atatetrte~ colour) ~
M ,~_Log(°Statemertt 6s inconsistent with selected varaabtel~rt°), °SZ-~.. r r c x-.> ~,~
t ~ . .'i.
~:i: r : ~.
r r.e .
,,rc...,r-::~ .tua =..... ". ,... ~.. . ..., ., _ .._.._.. ,. ,.,.... ..,.....
..,... . . ,. , .,.... ., . . . .,. ~ > .. ... _ .,.. ,. . , ....5. -'.~~c . , .. ....

i~0 93/20510 P(:T/EIP93l00754 Eval Greyout(logictree);
static void DumpDrawObject(node_pt node_p) if (node p =_ NULL) ~
MSG Log('\t\tDDO: Nuil parse tree node %x\n', node p); ' return;
90 }
if ( DRAW~OBJ P(node~) == NUi1 ) ~ "
MSG Log('\t\tDDO: Nuli tree item %x\n', node~p);
return;
y ,~ , MSG L~g('%x T:%s H:%d X:%o4d Y:%04d C:%d W:%02d H:%02d\n°, node_p, format objeccttyps(DRAlttl OBJ P(node_p)->type), DFiAW_OBJ~P(node P)->hidden, 20 DRAW~nBJ~P(node p)->col, DRAW~OBJ P(node"-p)->line, DRAW OBJ~P(node~p)->conn offset, DRAW OBJ P(node_p)->width, 25 DRAW~OBJ,~P(node~)-> height);
static void d~~DumpRRodv~r(stnrct DispiayModvar ds *mv) 3t? ~
MSG Log('Modvar 96-10.1 os v:%-10.1 os F:96-3.3s S:%-10.1 os\n', nnv->Name c, mv->Vaiuerc, mv->Fiags c, mv->Scale c);
35 syatic void dorDumpC?bjectinfo(struct Objectlnfo ds *o~
i~ (pi->T~ppe =~ Obj_Pipe) MSfarLo9( ~bje~info T:%-9.9s C:96-6.6s X:%o3d-96o3d Y:°~o3d-96o3d~n~, 40 format,~objtYPe(oi->Type);
fomnatdc~lour(oi->Colour), ~i->%_il, oi->Width~,il, oi->Y il, ~i->Height i~; _ ~Ise ~S~~Log( ~~b~ectlnf~ T:%-9.9s C:%-6.6s X:%o3d Y:%o3d W:%o3d H:%o3d B:%5t\n', . format~objtYt~e(oi->Type).
fiomt~t~colour(oi->Colour), oi->X il, oi->Y 61, oi->Width it, o~>Height il, oi->t~~rcentBlue fi};
50 }
static void do DurypDisplayltem(struct Objectlnfo ds ~'oi) °63-~ x ,. a. ..
..
:.,~ r,.
..F
~r T"A.. 'Y .1 ."1:! .
. . f. .
f ,. , k t b r t T
;.:fr., ..:~f w.
t :. , .., ?~.'- ., .. . . a ~.
.Z.' . . . n . . .. . , ..
LfJ,ti.,.:Y..~lJ:.i . ~ 1 ,..~.. ....._..,......."..... . .....~. ... ...v..
... ,......,.. .. . v.. . .:.y,...... .... .,.

W~ 93120510 PC,'T/EP93/00754 do_DumpObjectinfo(o,;
if (oi->Modvarl->ddame coo] !_ '<') do DumpiViodvar(oi->Modvari);
if -(oi->Modva~->hlame c(Oj !_ '<') do_DumpModvar(oi->Modvar2);
if (oi->Modvar3->Pdam2~c[oj !_ '<') do DumpModvar(oi->Modvar3);
static void do DumpSase(struct DispIaySase *ob~
irtt i; °
if (obj == NlJL!.) ~
MSG Log('Basa display item is NULi-\n°);
return;
for(i=0;6<3;i++) do DumpObjectirtfo(&obj->Qbj[ij);
for (i = ~; i < 3; i++) do DumpModvar(~obj->modvar~iJ);

Claims (36)

CLAIMS:

1. A computer-implemented process control display system for producing a graphical display of alphanumeric process control statements corresponding to a process being controlled, the process control statements comprising a set of lexical units grouped in a syntactic relationship defined by a predetermined grammar with at least a subset of the lexical units being capable of representing data, the process control display system comprising:
means for supplying a process control statement to be displayed;
statement analyzer means for generating a parse tree corresponding to the process control statement to be displayed;
means for producing a graphical display window;
means for establishing a predefined set of graphical icons for representing at least a portion of said lexical units;
display generation means in communication with said parse tree for placing selected ones of said predefined set of graphical icons in said display window in a spatial relationship corresponding to the syntactic relationship of said lexica units which make up said process control statement to be displayed;
means for supplying data from the process being controlled, said data corresponding to at least one of said lexical units of said process control statement to be displayed;

evaluation means responsive to the syntactic relationship defined by said process control statement to be displayed, for establishing visual quality of said selected graphical icons in said display window based on said supplied data, whereby at least a first condition may be visually distinguished from a second condition on the basis of its visual quality.

2. The process control display system of claim 1 wherein said display generation means places selected ones of said predefined set of graphical icons in said display window in an interconnected network.

3. The process control display system of claim 1 wherein said supplied data is dynamically changing data.

4. The process control display system of claim 1 wherein said visual quality is color.

5. The process control display system of claim 1 wherein said visual quality is color, in which a first color is used to represent a first condition and a second color is used to represent a second condition.

6. The process control display system of claim 5 wherein said First color is blue and said second color is orange.

7. The process control display system of claim 1 wherein said graphical icons include interconnection means for joining with one another to define said spatial relationship.

8. The process control display system of claim 2 wherein said graphical icons include interconnection means for joining with one another to define said interconnected network.

9. The process control display system of claim 1 wherein said graphical icons include interconnection means for joining with one another to define said spatial relationship and wherein said evaluation means establishes the visual quality of said interconnection means.

10. The process control display system of claim 1 wherein said display window defines a predetermined display area and wherein said process control program further comprises means for determining the boundary defined by said graphical icons placed in said display window and for altering at least a portion of said graphical icons placed in said display window to cause said boundary to fit within said predetermined display area.

11. The process control display system of claim 1 further comprising means for initiating a request to update said data supplied by said means for supplying data.

12. The process control display system of claim 1 wherein said process control statements are synchronized to a clock and wherein said evaluation means is synchronized to said clock.

13. A computer-implemented process control display system for displaying a program expression of the type capable of representing a change in datalogical quality, comprising:
means for parsing the expression into lexical units;
recursive means for creating a structure for storing the lexical units and the syntactic relationship among the lexical units;

means for drawing symbols corresponding to the lexical units and spatially arranged in a network reflecting the syntactic relationship;
means communicating with said drawing means for displaying the change of datalogical quality.

14. The system of claim 13 wherein said means for displaying change in datalogical quality comprises means for selectively altering the visual quality of at least some of said symbols.

15. The system of claim 13 wherein said means for displaying change in datalogical quality comprises means for selectively altering the color of at least some of said symbols.

16. The system of claim 13 wherein said syntactic relationship is based on a mathematical description of a grammar in which said program expression is written.

17. The system of claim 13 further comprising means for receiving data corresponding to at least some of said lexical units and means for updating said visual display based on said data.

18. The system of claim 13 further comprising means for displaying the change of datalogical quality by providing an interconnected network of changing visual quality representing logic flow.

19. A method for displaying a program expression of the type capable of representing a change in datalogical quality, comprising:

parsing the expression into lexical units;
recursively creating a structure for storing said lexical units and the syntactic relationship among said lexical units;
creating a visual display of symbols corresponding to said lexical units in a pattern corresponding to said syntactic relationship;
updating said visual display to show the change of datalogical quality by altering the visual quality of said symbols.

20. The method of claim 19 wherein said visual display is updated by selectively altering the visual quality of at least some of said symbols.

21. The method of claim 19 wherein said visual display is updated by selectively altering the color of at least some of said symbols.

22. The method of claim 19 wherein said syntactic relationship is based on a mathematical description of a grammar in which said program expression is written.

23. The method of claim 19 further comprising receiving data corresponding to at least some of said lexical units and updating said visual display based on said data.

24. The method of claim 19 further comprising displaying the change of datalogical quality by providing an interconnected network of changing visual quality representing logic flow.

25. A computer-implemented process control display system for displaying process control information expressed in the form of a program expression of the type capable of representing a change in datalogical quality, the process control information corresponding to a process being controlled by computer executing said program expression, comprising:
means for parsing the expression into lexical units:
recursive means for creating a structure for storing the lexical units and the syntactic relationship among the lexical units;
means for drawing symbols corresponding to the lexical units and spatially arranged in a network reflecting the syntactic relationship;
means communicating with said drawing means and said process being controlled for displaying the change of datalogical quality corresponding to a state of the process being controlled.

26. The system of claim 25 wherein said means for displaying change in datalogical quality comprises means for selectively altering the visual quality of at least some of said symbols.

27. The system of claim 25 wherein said means for displaying change in datalogical quality comprises means for selectively altering the color of at least some of said symbols.

28. The system of claim 25 wherein said syntactic relationship is based on a mathematical description of a grammar in which said program expression is written.

29. The system of claim 25 further comprising means for receiving data corresponding to at least some of said lexical units and means for updating said visual display based on said data.

30. The system of claim 25 further comprising means for displaying tile change of datalogical quality by providing an interconnected network of changing visual quality representing logic flow.

31. A method for displaying process control information expressed in the form of a program expression of the type capable of representing a change in datalogical quality, the process control information corresponding to a process being control led by computer executing said program expression, comprising:
parsing the expression into lexical units;
recursively creating a structure for storing said lexical units and the syntactic relationship among said lexical units;
creating a visual display of symbols corresponding to said lexical units in a pattern corresponding to said syntactic relationship;
updating said visual display to show the change of datalogical quality, corresponding to a state of the process being controlled, by altering the visual quality of said symbols.

32. The method of claim 31 wherein said visual display is updated by selectively altering the visual quality of at least some of said symbols.

33. The method of claim 31 wherein said visual display is updated by selectively altering the color of at least some of said symbols.

34. The method of claim 31 wherein said syntactic relationship is based on a mathematical description of a grammar in which said program expression is written.

35. The method of claim 31 further comprising receiving data corresponding to at least some of said lexical units and updating said visual display based on said data.

36. The method of claim 31 further comprising displaying the change of datalogical quality by providing an interconnected network of changing visual quality representing logic flow.