US 4,533,997 AGrant
Computer Monitored or Controlled System Which May Be Modified and De-Bugged on-Line by One Not Skilled in Computer Programming
Issue Date:1985-08-06
•7 Claims
•21 Drawing Sheets
Abstract
A computer monitored or controlled system is equipped with an interactive debugging system which enables a systems engineer to modify the system configuration in a simple manner. At any time, the systems engineer may obtain from the system a complete, understandable description of the system's present operating configuration. He may then modify any part of the system. Operation of portions of the system may be simulated, and detailed records of system and simulation operations may be automatically obtained.
Metadata
Assignee
- Westinghouse Electric Corp.
Inventor
- Donald F. Furgerson
Application Information
Application Number:US 1129724
Filing Date:1980-01-17
Priority Date:1972-08-25
Art Unit:237
Classifications
IPC:
G06F 1100
Field of Search:
364371200 MS File;900 MS File;300;120;12119
Patent Drawings (21 sheets)
Description
CROSS-REFERENCE TO RELATED APPLICATION
Background material for the present invention is contained in application Ser. No. 250,826, filed by John W. Gomola, et al. on May 5, 1972 and assigned to the same assignee as the present application. In particular, the various programs and subroutines disclosed herein are designed to interface with programs and subroutines disclosed in application Ser. No. 250,826.
BACKGROUND OF THE INVENTION
a. Field of the Invention
The present invention relates to monitored and controlled systems, and more particularly to a computer monitored or controlled system the operational configuration of which may be modified on-line.
b. Brief Description of the Prior Art
Many systems are available which permit the operating configuration of a monitored or controlled system to be automatically established. Typically, a systems engineer defines the operating configuration which he desires to achieve by filling in blanks on coding forms and by feeding data from the coding forms into an automatically programmable computer system. Particularly in the field of data monitoring, relatively complex operating configurations may be achieved in this manner.
However, once a system is established and operating, typically it is difficult to modify the operating configuration of a system. After compilation or assembly, conventional computer programs no longer contain the meaningful names for variables and for subroutines which they contain prior to assembly and it is almost impossible for anyone save a skilled programmer to interpret the data which a typical computer system spills forth as its contents. Hence, one who wishes to work with such a system is dependent upon whatever documentation of the system operating configuration is available. If the documentation is lost, destroyed, or erroneous, then typically a prior art system must be reconfigured in its entirety when any changes are made.
In prior art systems, the compilation of software entities is a one-way, irreversible process. Once a program system is established and operating, there is no way that the system may regenerate the language originally written out by a systems engineer or programmer--that language is lost. Only numeric machine language remains which is understandable only to the machine itself.
In prior art systems, modifications are made by altering computer programs written in a language such as FORTRAN IV. Once a modified program has been prepared, it is compiled, fed into the operating system, and the program which it replaces is removed from the operating system. Typically a skilled programmer has to make such modifications. Programs may to some extent be tested and debugged using a time sharing computer which stores programs in their uncompiled form, but no such editing may normally be carried out on a monitoring or control computer due to their limited memory size and the impossibility of storing uncompiled copies of all programs in such a machine.
The need for an easily editable system is particularly acute in process control systems where most of the programming is conventional as opposed to fill-in-the-blank programming. Even in the so-called "interpretive" systems where control operations are defined by interpretable data files, there is typically no way of reconstructing from any given data file the language which was originally used by a systems engineer to define the data file.
SUMMARY OF THE INVENTION
Briefly stated, the present invention enables a systems engineer to decompile any portion or all of the data or software which defines an operating system and return it to a form which is understandable to a systems engineer. The invention contemplates that interactive editing of any portion of an operating system may be carried out by a systems engineer who is not skilled in computer programming. The present invention also enables portions of an operating system to be exercised in a simulation mode without affecting the operating process. Means are also provided for "tracing" or making a record of any desired system operations during either actual or simulated operations. The invention is thus a combined debugging, editing, and documenting system.
In the preferred embodiment of the invention, control operations are implemented through the use of data files called control chains which instruct an interpreter or processing program as to precisely how control actions are to be carried out. The present invention enables a systems engineer to remove a copy of any control action defining data file from the system, decompile the data film back into language which the engineer can understand, modify the data file, and then return the data file to the system for either actual or simulated operation.
Briefly stated, the preferred embodiment of the invention contemplates providing an interactive processor which includes the necessary software to carry on two-way conversations with a systems engineer via typewriter or other equivalent communications device. Chain acquiring or dumping subroutines are provided for retrieving copies of control chain data files from the operating system. These subroutines have access to at least one symbol table which enables the subroutines to replace the numeric language of each control chain block with symbols understandable to a systems engineer. A Boolean or logical expression decompiler is also provided for decompiling logical expressions and for converting such expressions into a FORTRAN IV format which is also understandable to the systems engineer. Another subroutine determines what events trigger the execution of each control chain and prints out a specification of all trigger connections.
Once having retrieved and decompiled a control chain, the systems engineer can have the interactive processor call upon chain modify subroutines which may make modifications and changes in control chains. The chain modify subroutines are also interactive and may accept instructions from the systems engineer in a language which is meaningful to him.
After a chain has been modified, the systems engineer may have the interactive processor call upon a chain activate subroutine to place a modified control chain back into service.
If actual operation of one or more chains is not desired, operation of the chains may be simulated. A chain simulate subroutine is called upon to store in a special table data identifying the chains whose operation is to be simulated and the variables associated with the chains whose states are not to be altered by the identified chains. Once activated, chains whose operations are to be simulated are executed in the conventional manner but are not permitted to communicate directly with the listed variables. Each time a chain whose operations are to be simulated calls for the value of or requests a change in the state of a variable that is identified in the special table, the call is intercepted by bit manipulation routines. These routines retrieve the value of the variable from a bit location within the special table and change the state of this same bit location and do not permit the control chain to alter or check the status of the actual variable in the operating system. Special data modules which are active only during simulation operations may be inserted into any control chain so as to set up initial conditions for simulated chain execution.
The operation of any control chain, whether actually operating or whether simulating actual operation, may be followed through the use of tracing features of the invention. Trace flags are established within the control chains, and data relating to the execution of any such control chain is printed out when the chain is executed. The data is transferred into a circular trace printout buffer and is printed out by a low priority trace printout routine so as not to unduly slow system operations. A counter is provided to limit the number of trace printouts which occur. The counter enables controlled tracing even when an operator is not supervising the computer system.
Further objects and advantages of the invention are apparent in the detailed description which follows. The points of novelty which characterize the invention are pointed out with particularity in the claims annexed to and forming a part of this specification.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates a simple control situation.
FIG. 2 is a block diagram of special software which is used in implementing the present invention.
FIG. 3 is a representation of the symbol table used in implementing the invention.
FIG. 4 illustrates the mechanism whereby control chain execution may be simulated and then traced.
FIGS. 5A to 5F illustrate how a control chain may be modified. Example 1 illustrates modification by replacement, example 2 illustrates modification by insertion, and example 3, illustrates modification by deletion.
FIGS. 6A to 6C illustrate how a new control chain may be created.
FIGS. 7A to 7E illustrate simulated chain execution with tracing in effect.
FIG. 8 is an overview block diagram of a computer controlled operating system or process incorporating the present invention and illustrating the interties which exist between the various software entities which are part of the system.
FIG. 9 is a block diagram of the interties which exist between software entities that support the chain activate subroutine shown in FIG. 8.
FIG. 10 is a block diagram of the interties which exist between the software entities that support the chain modify subroutine shown in FIG. 8.
FIG. 11 is a block diagram of the interties which exist between the software entities that support the chain dump subroutine shown in FIG. 8.
FIG. 12 is a block diagram of the interties which exist between the software entities which maintain the symbol table for use by the system or process.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The description which follows includes an overview description of the invention (Sections I-VI and FIGS. 1-7), a detailed description of the software programs which depict the precise details of the invention (Section VII and FIGS. 8-12), and a series of appendicies.
The overview description is self-contained. The detailed description of the software programs (Section VI) preferably should be studied only after one has studied the background material presented in application Ser. No. 250,826 filed by John W. Gomola, et al. on May 5, 1972 and assigned to the same assignee as the present invention. That application presents detailed descriptions of all the software elements shown in FIG. 8 which are not described in the present application. The Gomola, et al. application also fully describes the host PROGEN (trademark) computer system with which the preferred embodiment of the invention is intended to be used.
To aid one wishing to pursue the details of the programs and subroutines presented in Section VII, each of the programs and subroutines has been assigned a number. FIGS. 8-12 then illustrate the precise nature of the interactions which may occur between the various program elements. Most all of the blocks in FIGS. 8-12 corresponds to a specific numbered program or subroutine, and each such block contains the number of the corresponding program or subroutine. If a block contains no number (for example, the "LOGIC INITIATOR" block in FIG. 8), then that block corresponds to a program or subroutine that is described fully in the Gomola, et al. application.
I. THE LOGIC DIRECTOR PROCESS CONTROL SYSTEM
Application Ser. No. 250,826 filed by John W. Gomola, et al. presents a complete description of a logic director system in which a computer and its associated software are used to replace a larger number of relays and other hardware logic elements in performing simple time-sequential operations, such as conveyor control or the like. As that application explains, an operative system is established by interconnecting various hardware sensors and controllers to the contact-closure inputs and outputs of a small digital computer system. A description of the desired system configuration is then prepared using coding forms, and data from the forms is then fed into the computer system. As each block of data is fed into the system, the control actions defined by that data are immediately rendered operational. The software system described in the above application will hereafter be referred to as the PROGEN-70 (trademark) system, or the PROGEN (trademark) system.
The working environment for this particular process control application requires the solution of a large number of logic equations either in the direct form of logic expressions; or in some more complicated form involving computer time delays, program bids, subroutine calls, etc. The basic motivation for this computer application is the replacement of electro-mechanical devices such as relays and timers used to perform numerous logic sequencing functions in process control. To solve this logic sequencing problem, a sub-set of a PROGEN-70 process control language is utilized. Only 16 unique algorithms are utilized in this application, and a more detailed description of each of these is contained in Appendix B. FIG. 1 shows a typical control example utilizing PROGEN-70 .
In this example, a coil is moving up at a known speed, approaching a photo-cell PC045. When the coil breaks the beam of light that is shining upon the photo-cell, a "control chain" or sequence of algorithms within the computer system is "triggered" by PC045 to carry out the following steps: it reads a digital position feedback from a coil lift device DEV015; it calls upon a FORTRAN routine to calculate the outside diameter of the coil, taking the geometry of the coil cradle into account; and it then generates a new reference for a positioning system so that the coil is ultimately stopped at the proper height for the next operation. The sequence of algorithms are initially selected by the applications programmer from the sixteen standard algorithms, and they are written out in sequence, as is shown in FIG. 1. A detailed explanation of the control chain algorithm language may be found in the Gyres, et al. application cited above.
Applying these basic algorithms, the applications programmer will generate a PROGEN-70 program which is referred to as a control chain. The chain is subsequently compiled into packed strings of data by an off-line PROGEN-70 compiler. These data records are then loaded into the actual target process control machine by a PROGEN-70 loader. Once the chain is loaded into the target machine, it is available for execution in an interpretive mode by the core resident PROGEN-70 interpreter. This interpreter will systematically interpret the data strings that have been pre-stored into the machine. Such a system is normally stored entirely in core, with a high speed data link to a neighboring machine which does in fact have disc capabilities.
The core size required for this type of system varies with the magnitude of the logic sequencing to be performed. Characteristically, however, the operating system required to support such a package, plus the storage of the control chains themselves, occupies somewhere between 32 and 48 thousand 16 bit words. Process inputs to this system are received as interrupts, and subsequently bid the PROGEN-70 control chain designated to solve this particular logic sequence step. When a PROGEN-70 chain is executed, logical inputs are interrogated and a logical output is generated, depending upon the state of the various logical inputs. This logical output is then routed to the process via the computer output hardware.
Once such a system is operational, it must perform reliably with a minimum of down time, even though the customer's control philosophy may change. It is therefore desirable to provide the capability of editing the control software while continuing to perform on-line control. Once the change has been made, it is further necessary to provide some means of testing its performance thoroughly prior to placing it on-line. Both of these features are provided in the debugging package under discussion here.
In summary, therefore, this type of installation requires a relatively small, highly reliable, process control computer. It may be all core and normally is provided with a data link to a more sophisticated machine. It basically performs logical functions with some calculation capability. The logic functions are interpreted by a run-time interpreter, rather than executed in machine code, at a sacrifice in time but at a savings in core storage needed. No sophisticated operating system or control system is provided in this type of computing environment. The present invention was designed for this type of process control system.
II. THE PROBLEM
A. The Process Environment
In the previous section the need for an interactive debugging package for process control was discussed. In this section we shall consider the problems encountered in interfacing such a debugging system into the three operational environments to be found in process control.
The first operational environment under consideration is the process environment itself. This environment varies greatly with the process being controlled. The scope of this discussion shall be limited to the logic sequencing environment. In this application the PROGEN-70 control language will be utilized to initiate and monitor the movements of various mechanical apparatus in such a way as to achieve optimal control. Considering that the computer is a replacement for electro-mechanical devices such as relays and timers which exhibit fairly slow reaction time, the problem of CPU turnaround time, i.e. the time lapse between the contact closure input to the computer, and the subsequent contact closure output generated by the control logic as a result of that input, is not a critical parameter in the evaluation of the effect of this debugging system on the entire process environment. Because these devices operate on millisecond timing as opposed to microsecond timing, even the more complicated CPU actions are completed at a rate which is considerably faster than the electro-mechanical counterpart. Therefore, in the analysis of this particular environment, it is determined that if it becomes necessary to increase the time required to service a given process variable, such a measure would be justified, because the CPU turn-around time is much, much shorter than the equivalent relay turn-around time; and therefore, an extension of this time would have a trivial effect upon the operation of the system.
B. The Software Environment
As a result of the conditions and restrictions indicated in Section A., the software environment has been structured so as to allow a saving in the amount of storage space needed for specific control programs, but at a sacrifice in actual execution time of these control programs. Due to the timing involved, this is entirely consistent with good process control philosophy. The software execution philosophy employed in this environment is one of interpretive execution of packed data strings as opposed to a pre-compilation into machine code, and an actual machine-speed execution of that machine code. Due to this environment, the data structure which forms the storage of actual control algorithms is much simpler than the storage of the equivalent amount of machine code to perform the identical function. The machine code sophistication is therefore included in the run-time interpreter, and the data structures used to depict the 16 basic algorithms used in this type of control is quite elemental indeed, and enhances the ability to generate a fairly sophisticated on-line debugging system without requiring a large, inefficient, run-time support system for such a package. As an example of this premise, because there is no machine code realization of the program, it is unnecessary to add such pseudo-control features as program break points, at which time control would branch out to specialized simulation, debugging, and tracing packages. In this instance, the more pleasing task of actually modifying the structure of the control chain interpreter, the run-time package which interprets each control algorithm, is undertaken. In other words, the method of interpretive execution employed in relation to the control algorithm is the vehicle by which changes are instituted. The data storage which physically represents the control algorithm is not changed in any way and therefore remains the same in both the normal, non-debug environment, and in the artificial debug environment created by this package.
C. The User's Environment
As in the two previously discussed environments, there are unique sets of conditions surrounding the third environment, which is referred to as the user's environment. These conditions, by and large, dictate the degree of inter-activity desired to be designed into this package. The level of sophistication of the user has been one of the key factors in the decision to design into this package a fairly high degree of man-machine inter-activity. In hard wired relay control systems, the maintenance function which is analogous to the debugging function in computer systems is performed by a special breed of control engineer, using well defined, classical relay theory, and lacking significantly in the sophistication normally associated with even the smallest of computer operating systems. If the computer is truly to replace the relay in this type of environment, the user must be capable of rapid and effective cross-training, in that he now must be able to adapt rapidly to a new method of control implementation which still embodies the basic precepts of his previously learned control philosophy. In theory, the computer, its hardware and its software operating system, should be entirely transparent to the user so that he can make the transition to computer logic maintenance as smooth as possible.
In the ensuing sections, design criteria for the debugging package which hopefully will allow it to operate effectively in each of these three environments will be established.
III. OBJECTIVES
A. Use of High Level Syntax
The initial operating version of the debugging system discussed herein was a system involving only hexadecimal input and output. While satisfactory for use as a debugging tool by those skilled in computer programming, this initial version is not easily used by others because a control engineer not familiar with computer terminology and hexadecimal notation has some difficulty in adapting to this type of notation to describe his various control parameters. The typical control diagram indicates contact inputs and contact outputs in symbolic notations where up to eight symbolic characters may be used to reference a given variable. In addition to this, the basic language for process control, the PROGEN-70 language, also allows the control engineer to communicate with the process in essentially an English language type of syntax; where the algorithm names and control statements are clearly and precisely stated in English, and symbol names are entered in a character notation which in some way relates to an English definition (see Appendix B). Hence, an improved operating version of the system has been developed which permits the use of a high level syntax for inter-communication between the control engineer and the debugging package.
Since the original syntax created by the PROGEN-70 compiler is highly legible in itself, the decision was made to attempt in every case which is possible, to duplicate the exact syntax that would have been used if the control engineer was communicating directly with the PROGEN-70 compiler or control chain generator. Hence, the compiler source statements, as they would appear on a coding sheet, are entirely suitable as input to the debugging package in question, providing that the proper entry to the package has been made through certain prescribed procedures. In essence, therefore, the control engineer need only by trained once; if he is competent in the use of the PROGEN-70 compiler, with a small amount of cross-training, he should become quite competent in the use of the debugging package extensions under consideration here.
B. Symbolic Reference to Variables
Symbolic referencing of process variables shall be a design objective for the debugging package extension, with the following qualifications. The symbolic reference to variables will be accomplished through external sources. The computer-to-computer data link which exists in most cases between the small all-core logic computer, and the larger core and disc oriented supervisory computer, shall be utilized in this instance to extract the symbolic representation of process variables from a symbol table stored on the disc of the supervisory machine. For efficiency of process variable extraction from the symbol table, hash code techniques are used to structure the symbol table; hash coded for both access to the name of the variable (in ASCII), or the address of the data, the computer number (bit address) associated with this symbolic reference (hexadecimal).
In the current version of the debugging package, the symbolic referencing of process variables represents the only umbilical tie between the satellite logic computer and the main supervisory computer in the execution of this debugging system. All other debugging functions are contained within the logic computer itself. In extremely small applications supporting only the logic computer in absence of the larger supervisory computer, one could envision the establishment of some more primitive type of symbolic referencing; a method not requiring the extensive symbol table utilized herein, but tying each process variable to some form of alpha-numeric representation. This would admittedly not be as understandable as the version indicated herein; but would suffice in those cases where it would be impractical to attempt to store the symbol table necessary to return all the variable syntax indicated in a typical control situation.
C. Ease of Human Interaction
In addition to direct communication with this package in the algorithmic symbolism utilized by the PROGEN-70 compiler, a control structure which accesses the various elements of this package must be created in such a way that the user is not over-burdened in the use of the syntax necessary to activate the various sections of this package. To this end a simple, but rather powerful, control structure has been implemented. The user is provided with an IBM selectric 735 logger, which serves to provide both an input and an output medium for the debugging package. It is therefore desirable that access to the debugging package be implemented in the easiest and most straight-forward manner. The decision to use a two character mnemonic to represent each of the available control functions existing in the package has been made. Hence the operator quickly overcomes the handicaps of learning a new control procedure, and spends the majority of his time actually worrying about the specific control structures in his program, without worrying about the methods of utilization of the debugging package itself.
D. Compiler/Decompiler for Boolean Functions
The only non-trivial control algorithm available in this particular logic application is the logic expression algorithm. This algorithm allows the control engineer to write actual logic expressions of a form Y=A.AND.B.OR.C. much as would be done in a classical circuit theory example. The PROGEN-70 compiler than analyzes this logic expression and stores away the packed data string necessary to be passed to the PROGEN-70 run-time interpreter; which in turn, unpacks the data string, interprets the data that exists, and takes the necessary action based upon an evaluation of that data.
The design objective is to create two packages:
1. A logic expression compiler, which allows as input from the typewriter keyboard a data string similar to that accepted by the PROGEN-70 control chain generator; and will in turn create the packed data string necessary to be utilized by the PROGEN-70 run-time interpreter, is the first package needed. In essence it will perform the identical function of the PROGEN-70 compiler, but only for the 16 algorithms given in Appendix A.
2. A logic expression decompiler, which will take as input the packed data associated with a previously stored logic expression, and return to the user the original syntax as it was presented to the control chain generator. In case of ambiguous situations, an equivalent logic expression will be returned to the user which will represent the desired control action.
E. Simulated Program Execution
One of the major problems surrounding any control situation is that of testing and debugging the actual control algorithms employed without having any adverse effect upon the real-world hardware, i.e. without causing damage to process equipment. The provide for a simulated mode of control algorithm execution in such a way that the process variables are in turn substituted for dummy variables so as to isolate the control algorithm being tested from the actual process environment itself. The control algorithm may then be tested in this simulated environment until the control engineer has a relatively high degree of assurance that the algorithm is performing in a consistent and correct manner. Then, under control of the engineer, the algorithm may be placed systematically into the on-line environment, thus drastically reducing the risk of causing any problems with its insertion.
F. Debug Trace Printouts
In order to monitor the operational performance of a single control chain, or a group of control chains performing a related function, an extensive debug trace printout section has been added to this overall package. The debug trace printout section performs two tasks.
During the simulated program execution phase the debug trace printout gives a hard copy indication of the performance of each of the control chains being simulated; however, if no chains are being simulated, and the process is performing its normal on-line function, the debug trace printout may be used to selectively place "windows" around certain sections of the process control, to allow an on-line printout of the actual control procedures being invoked at any given point in time.
The actual hard copy trace printout is also broken down into two sections (see Appendix D). One section, the basic printout format, involves the printout of only those parameters necessary to indicate time of execution in milliseconds, the control chain which is currently being traced, and the specific block in the control chain. These parameters print on the left hand side of the output page, one line of print for each block in the chain that is executed under the trace printout control. The second section, an extended printout format, is included so that the control engineer may have more detailed information concerning the operation of the control chain than is provided by the simplified trace just described. The extended trace is identical to the simulated trace on the left hand side of the page; however, for each algorithm being traced, certain important parameters unique to that algorithm are printed out to the right of the normal trace information. Such information would include dynamic subroutine arguments passed to the Progran algorithm; logical bit addresses, and the corresponding logical state of these bit addresses in the logical oriented algorithms; actual core transfer data in the Data Transfer algorithm; and the name of the program being bid in the Bid algorithm. This capability can be modified or extended quite easily. Thus when the control engineer invokes the full power of this trace printout package, he has provided to him a very meaningful source of information as to the actual performance of each of the control chains being traced; whether he is tracing their performance in the simulated environment or in the actual on-line environment. This dual function approach makes this part of the overall package one of the most important sections, certainly an invaluable tool in finding problems associated with the actual or simulated control.
G. Additional Algorithms
When trying to simulate a control chain or a group of control chains, one sometimes encounters difficulties in initializing certain parameters which in a real-time environment would have been initialized by a prior process. However, in a simulated environment, this initialization is not provided by any prior element, and therefore should be conveniently provided by some function of this debugging package. The section which accomplishes this goal is a section which includes the addition of 16 algorithms. Each algorithm is analogous to its corresponding real-time algorithm. However, the additional algorithms only execute in the simulated program environment. During real-time control these algorithms serve as passive data structures in the control chain storage file. They are scanned by the real-time interpreter, but are not executed. In the simulated execution mode, however, the interpreter executes the additional algorithms in a manner identical to their real-time counterparts.
An example of the typical use of the algorithm extension feature would be the initialization of certain control parameters at the entry to a control chain which is going to be simulated. An algorithm which one may choose to use would to the Set-Reset algorithm. If this algorithm were inserted at the beginning of a control chain to be simulated, the control engineer could specify a number of logical or Boolean variables whose initial state would be indicated to be that included in the text of the algorithm. Hence, four process contacts could be simulated to be in the set or true position, and six process contacts could be simulated to be in the reset or false condition, prior to the execution of the simulated chain. When the simulation option had been selected for that chain, and execution had been demanded, the Set-Reset algorithm would be executed by the run-time interpreter in the manner normally used to execute all S-R algorithms. If in fact the simulated execution was continued to completion and the control engineer was satisfied with the simulated results, the control chain in question could be then linked into the active system, executed in a real-time environment, and actually used to control the process. This could be accomplished without any further modification to the control chain itself. The Set-Reset module included at the beginning of the control chain would now be a passive element. It would occupy space in the data structure, but would be scanned by the run-time interpreter and not executed in the real-time mode.
The other algorithms can be used in this same mode of operation, to enhance the ability of the control engineer to set up or create the proper simulation environment, prior to the commencement of any control chain simulation.
H. Self-Documenting Output
Normal debugging procedures would dictate that a control programmer would debug his on-line program using a multitude of patching techniques until he would arrive at such a point where the program was operating correctly. At which time he would update a source deck image of his program to indicate the current state of changes; and then submit each a program to a batch compiler or assembler, which would then recompile or reassemble his program so that the output would resemble the actual operational state of the program. This is somewhat of a complicated and time consuming procedure which, if possible, should be eliminated. In the case of PROGEN-70 and the debugging package in question, the elimination of this need to spend the time to recompile has been included as part of the operational objectives.
In actuality, the output from any compile operation would consist of an object program output on either binary tape or binary cards, and a hard copy listing output readable by the programmer. If these features can be incorporated into the debugging package itself then the need for the control engineer to accomplish this task through other means would be eliminated. Therefore, much effect has been expended upon the generation of self-documenting output from the debugging package.
The hard copy output is an accurate representation of the source syntax, similar if not identical to the syntax developed by the PROGEN-70 compiler itself; hence if a control chain is modified using this package, the hard copy listing output of the modification can be substituted on a one-to-one basis for the currently existing documentation from the control chain compiler. Therefore, one constantly keeps his documentation up to date without the need to go through a recompile procedure. In regard to the object program, a feature of the debugging package allows a binary copy of the debugged program to be punched on paper tape as a permanent copy of the program change; another feature allows the data linking of the debugged program to the mass memory device associated with the supervisory machine located adjacent to the logic control machine.
With these capabilities it is a very rare circumstance indeed that would require the use of the batch control chain compiler. Unless extensive modifications were made, and a mass updating of control chains was required, there would be no need to perform anything above and beyond the actual output performance of the debugging package itself.
IV. DESIGN REALIZATION
A. The Original Package
1. Software Structure
The original PROGEN-70 editing package consisted of three levels of software organization. Level One contained the editing package main processor and a number of support subroutines incidental to the operation of the main processor. Level Two consisted of five special purpose subroutines, each one of which was used to implement the five basic editing functions that formed the original package. These five functions were as follows:
a. Chain Acquire--which allowed the movement of a chain from the active chain working area into the editing package working area for future modification;
b. Chain Modify--which allowed modification of a single PROGEN-70 control block or a number of PROGEN-70 control blocks;
c. Chain Dump--which allowed one to request a hard copy printout of an entire chain or a certain portion thereof;
d. Chain Activate--which allowed a completely modified and tested chain to be placed back into the on-line environment and linked up with the on-line process;
e. Chain Punch--which allowed the user to obtain a paper tape reproduction of his finished control chain in compiled form.
The Level Three software in the original package consisted only of a hexadecimal modify and dump routine which was called by both the modify and dump functions from Level Two, and allowed the user to communicate with the editing package in hexadecimal notation for either modification or for listing output. Refer to FIG. 2 for a graphic representation of this structure.
Because this basic structure has been retained, and additions have merely been made to it, at this time the functions of the major blocks of the original package will be discussed briefly.
The main processor is the routine that interfaces with the user on the control command level, decomposes the control command that has been entered by the user, and stores the decomposed input information in appropriate internal buffers in common. The user of the package enters a control command with the following format:
CC represents any valid two character control mnemonic. Each argument may be a single symbolic alpha-numeric entity; a hexadecimal number; a decimal number; or a double argument separated by a dash.
Example
!CC,ARG1A-ARG1B
By using both the comma and the dash delimiters to their fullest extent, one may enter up to eight arguments following each control command initiation.
The first task of the main processor is to check for any possible syntax errors in the input string, to determine if the control command that has been input is well formed. Once this determination has been made, the specific two letter mnemonic is interrogated in relation to a mnemonic table; and if the mnemonic is legal a subroutine branch is established for use at a later time, and the arguments are then manipulated. Argument manipulation requires the checking of each argument to determine a. is it a symbolic alpha-numeric argument which will require symbol table access, or b. is it a straight hexadecimal number which will require conversion to binary from the base 16, or c. is it a decimal number which will require conversion to binary from the base 10. This operation is performed by the main processor, and the result of the operation is that an argument storage table in common will be updated with the correct binary value for each of the arguments entered by the user. If no argument has been entered for a particular location in the argument table, the table is set to zero, zero being the default case for any argument entry.
After the arguments have been resolved, the main processor then branches, via subroutine call, to one of the five Level Two processors; determined by the two letter control command that had been entered by the user. The first Level Two function, Chain Acquire, performs as follows. The PROGEN-70 sub-level processor (see the above-cited Gyres, et al. application) is interrogated to determine if the sub-level requested by the user is a legal sub-level in the system, and a sub-level that contains a PROGEN-70 control chain as opposed to some other programming entity. If indeed the sub-level is a valid sub-level, and does contain a PROGEN-70 control chain, said control chain will be moved into a working area directly associated with the editing package. Therefore a local copy of the control chain is created for manipulation by the editing package without affecting on-line control. The chain so acquired still continues to function in the on-line environment as if no acquisition had been made. Once the acquisition is complete the two functions directly related to the internal structure of the chain, the modify function, and/or the dump function, may subsequently be activated by the user of the package. Again a two letter control mnemonic is entered by the main processor. The main processor determines whether this is a modify or a dump, and will place a subroutine call for the correct processor at Level Two.
In the original version the modify function determined the extent of the modification, i.e. the starting block number and the ending block number for the modification of the chain. This information was passed on to the Level Three program which, in the case of modification, requested hexadecimal input information from the user in an interactive way; and in the case of the dump function, produced a hard copy printout of the area of the chain in question in a hexadecimal format.
Once the modification and dump cycle is complete to the satisfaction of the user, he may then decide to a. activate the modified control chain by using a two letter mnemonic for the activate processor at Level Two; and this processor will then move the modified control chain to the active chain working file and perform the necessary linking functions with the sub-level processor so as to bring this chain into the active environment, or b. use a chain punch function which allows the user to produce a paper type copy of the modified control chain possibly for loading at a future time.
That is a brief summary of the functions that were available in the original editing package. A later portion of this description shows how this original structure has been modified to include the functions that embody the precepts of this thesis. A complete summary of functions is included in Appendix B.
2. Interface Procedures
The interface procedures used in connecting the various portions of this editing processor and connecting the editing processor to the outside environment shall be discussed in detail in this section.
The main processor itself may be initiated in one of two ways. One, it may be run on a regular task level and bid by the Initiate Task function of the programmer's console package, or two, it may be run on a sub-level under control of the sub-level processor, and is bid then using the General Program function of the programmer's console. Once the user has entered the main processor, a message, "ENTER CONTROL COMMAND", will be typed back to him at the selectric typewriter. This is verification that the package is indeed working and that he is not required to input control command information in the previously mentioned format. Once the main processor has completed its operation, the interface between the main processor and the Level Two software can be accomplished in one of two ways, depending on the configuration of the machine using the processor.
In an all-core machine, the Level Two software is simply concatenated onto the end of the Level One software in the form of attached subroutines. The main processor places a direct subroutine call to the Level Two processors which are run as standard subroutines, and in fact, the Level Two processors also call the Level Three processors via standard subroutine calls. The code for the Level Three processors is concatenated onto the end of the Level Two processors, making an all-core environment with Level One, Level Two, and Level Three.
A more imaginative approach can be used in control machines which have a disc associated with them directly. This allows the Level One processor to be run on a disc-resident sub-level, and interaction between the main processor and the Level Two software is now of such a nature that the main processor places a sub-level read and transfer bid for the Level Two software. A core buffer is assigned by the sub-level processor and the Level Two software is read from the disc into core on a priority basis. The Level Two software is then entered from the sub-level processor and executed to completion, at which time the buffer is released and other control programs may now run in the same area. The Level Two software, if it needs the support of some Level Three software, will use the same sub-level processor control strategy to execute Level Three editing package processors. Therefore, a type of overlaying structure is allowable here which was not allowable in the all-core machine; which enables the editing package to be used in a more efficient manner, with the majority of the programs being on the disc, and only being called into core when needed for actual execution.
The data management system consists of a block of named common into which the main processor and the Level Two software will place the composed input information, in such a form that the Level Three software can easily use the input information; and return its own output information to the Level Two, and/or Level One programs, via the common area. An enhancement of this has been made in the case of the Chain Simulate function, which is discussed in detail in Section IV., D., but in the original package the single area of common was sufficient for the interchange of all the data variables.
It might be prudent at this time to mention that in the Level One software area, in addition to the main processor, a series of support subroutines have been provided to enhance the repetitive operations required by the main processor and the Level Two and Three processors as well. The reading of a character from the typewriter keyboard, the output of error messages to the user of the package, the insertion of a modified control chain into the actual working environment of the on-line sub-level processor, and other specialized routines are included in this support subroutine package. The support subroutine package was not materially changed for the implementation of the added functions of this package.
3. Error Recovery Procedures
Each level of the software structure previously mentioned has associated with it various methods of error detection, error notification to the user, and error recovery by the user. Error numbers have been assigned for each type of error which is reportable to the user, and a summary list of these errors is included in Appendix D.
In the main processor itself, two special control characters are provided to the user to allow him to recover from specific error conditions. If an error is created and detected such that the entire control command must be initiated again, the operator merely types the exclamation character and continues by typing the entire control command a second time. The new control command entry will be analyzed by the processor in lieu of the original entry which presumably had some error in it.
Example
!CM,40-25!CQ,AS00014
The star character is used to cancel argument input if an error is detected in the input of a given argument in the control command string. If the user planned to type symbolic argument XYZ, and noted prior to doing a carriage return that he had typed XYP, he would be allowed to hit the star character and again type XYZ; the XYZ symbol would be accepted, and it would be necessary to reconstruct the entire control command line.
Example
!CQ,AS001*AS00014
The slash character is an escape character, which allows one to exit from the editing package at any time. If the input string analyzer in the main processor should detect a slash character, the task level or sub-level on which the main processor is running will exit, and in order to restart, one would have to bid the main processor by the previously mentioned procedures. The slash character is a character which is used in all three levels of software development. If a slash character is encountered in the input string at Level Three, the user is immediately dropped back to Level Two, and requested to input information according to the demands of the Level Two processor. If the slash is encountered in Level Two, the user is then dropped back to the Level One processor and asked to enter another control command as is consistent with the input to the Level One processor. A further slash will terminate the action of the main processor and exit the function. So, at any given point in time, from the typewriter keyboard a maximum number of three slashes would be required to return the user to the exit state and essentially turn off all editing functions.
Example of Escape Character:
ENTER BLOCK # AND ALGORITHM NAME (Level 2 syntax)=/
ENTER CONTROL COMMAND (Level 1 syntax)=/
This example takes the user from a symbolic modification at Level 3 to the exit of the debugging package by typing 3 slashes. All other printout is generated by the computer.
The error recovery structure is such that errors are broken down into two categories: recoverable errors and non-recoverable errors. For example, assume a recoverable error has occurred at Level Three. Recoverability means that a certain portion of the interactive package at Level Three will be able to resolve the error difficulties, ask the user for more definitive information, and recover from the error without returning back to Level Two and requiring Level Two information to be input. So a recoverable error is defined as one which is recoverable at the level of occurrence. A non-recoverable error is an error which will require the user to drop back to the last software level of operation, and will automatically drop him back to that level of operation. If a non-recoverable error is detected at Level Three, the user will be automatically dropped back to Level Two, and he will be asked to input information to this program in the Level Two format. A great amount of time has been spent in attempting to resolve most error situations at the level of their occurrence, so that by simply inserting some additional symbols or by reconstructing a small portion of the input information, the user may continue at the same software level at which he was operating. But in certain cases the error is of such magnitude that this is not possible, and therefore, the user is dropped back to the next software level and required to input more information at that reduced level. As the software enhancements to this package are discussed, additional error recovery procedures which will further exemplify the error recovery capabilities included in this package shall be pointed out.
B. Conversion to High Level Syntax
1. Symbolic Modify Function
The basic goal of the Symbolic Modify function added to the editing package is to allow the user to communicate with the editing package in a higher level syntax than hexadecimal notation. The result is that the user is now able to communicate with the package in a language which is very similar to that used in the original generation of the control chain.
Symbolic notation is used throughout the package, and modification steps are highly interactive, in that for each given control chain algorithm there are certain well-defined key words that are associated with each of these algorithms. As soon as the Symbolic Modify function realizes that a specific algorithm is requested to be input, a vocabulary key table of 36 words is interrogated to find the first word associated with that particular control chain algorithm.
For an example, the Set-Reset algorithm has two words associated with it for use by the operator. One word is TRUE, and one word is FALSE. Once the Set-Reset algorithm has been invoked by the operator, the typewriter keyboard will return to the operator:
The operator must therefore input in logical high-level notation the representation of the logical element that he desires to have set true as the result of the execution of this algorithm; and then a carriage return. The package will then interrogate this symbolic entry, access the hash-coded disc table to produce the hexadecimal bit address of the variable, and store this hexadecimal bit address into the data structure he wishes to modify, and the vocabulary key table is then searched to find the input word associated with that particular algorithm. If the input word is not repetitive, i.e. if there is only one entry per word, once the input of that one entry has been completed, the processor will immediately ask for the next word without using the slash delimiter. In the case of repetitive requests, the slash delimiter is used to move the next input word.
Certain PROGEN-70 algorithms do not start immediately with input storage, but rather use the first two or three words of their data structures to store internal variables, counters, and pointers etc.; and the third or fourth word would therefore be used for storage of the first word of input by the user. This would be difficult to handle by this processor if it were not for a special field in the vocabulary key table which is a bias field. The bias field indicates how far down into the algorithm the first word of input should start, allowing us to correctly bypass the starting words in some of the algorithms and therefore reserve these starting words for internal use by the control chain interpreter.
The vocabulary key table, the heart of the Symbolic Modify function, and also the heart of the Symbolic Dump function, is a variable field word, a 16 bit word divided into five fields. The first field is a one bit field indicating repeat or no repeat. The second field is a 4 bit field, indicating the algorithm type from 0 to 15; this is used in an initial search by the processor to determine the first word of a given algorithm. The third field is a 3 bit field used for the storage of a bias number as indicated in the previous discussion. The fourth field is a symbol table access code from 1 to 15, which will be discussed in more detail in the portion of this description devoted to symbol table handling. Basically, this number allows the hash coded disc symbol table to differentiate between the hexadecimal number, which is used to represent a logical bit; and an identical hexadecimal number, which may be used to represent a PROGEN-70 sub-level, or any other two numbers which may be in conflict at the hexadecimal level but not in conflict at the character level. This is discussed in more detail in Section IV., C. Field Five is the actual vocabulary word index number which allows one to access up to 20 special vocabulary words in a 20 word vocabulary table, which is also stored in common. These two tables, therefore, allow the return to the user, upon request for input, the original syntax that is used by the PROGEN-70 compiler; and a syntax that by this time he should be most familiar with, as opposed to the more cumbersome hexadecimal format previously used.
2. Symbolic Dump Function
The Symbolic Dump function allows the user to obtain a hard copy listing output of a chain or a given portion of a chain in a format which is entirely consistent with the original output from the control chain compiler. If the extended dump feature is chosen, the user may get in addition to the syntax indicated by the original compiler an expanded syntax which actually shows the internal representation of the chain in the working environment. Examples of both the abbreviated dump format and the extended dump format are included in Section V.
An interesting addition of the Symbolic Dump function is that a dump-with-value feature has been provided. If the user indicates in the control command input for the dump function that a dump-with-value feature is desired, any time a logical element is encountered by the Symbolic Dump function, the current value or state, i.e. either 0 or 1, or the logical variable will be returned to the user for his examination. So, during the execution of a given chain, one could periodically dump the chain in question and obtain an idea of the status of the variables at the time the chain is dumped. When operating in the simulation mode, discussed in Section IV., D., there is certainly not necessary; but in certain debugging instances where it is not practical to invoke the simulation function, the dump-with-value portion of the Symbolic Dump function allows one to gain some insight into the on-line state of the variables in question.
3. Boolean Expression Compiler
In addition to rather fundamental algorithms, which can be handled by the Symbolic Modify and Dump functions previously mentioned, the PROGEN-70 control system allows the generation of Boolean or logical expressions, and the evaluation at run-time of such expressions. The logical operators allowed are the standard logical operators, the unary negation operator, and the binary operators AND, OR, and EOR (Exclusive Or).
The user of this package merely types in at the console a Boolean expression using the operators previously mentioned; and it is a function of this Boolean Expression Compiler to analyze the input string, parse the input string into an internal representation of both the logical variables and the logical operation, and return these logical operations and variables to the system. The Boolean Expression Compiler processes FORTRAN type logical assignment statements, and translates this input string into an internal code representation similar to three-address-code. Characters are input one at a time through the typewriter keyboard. Complete syntactic elements, i.e. variables, operators etc., are converted to a numeric code and stored in an intermediate buffer. The intermediate buffer is then processed as a series of parenthesized nests--innermost nests processed first. Each nest is processed for logical operators, and legal operators are processed in the following order: NOT, AND, OR, and EOR.
When processing is complete, two output buffers exist. One buffer contains the actual core address for each non-temporary, logical variable processed. Another buffer contains modified three-address-code commands, composed of packed words, 16 bits each, as follows: Bits 0-4, relative address of left hand operand; Bits 5-9, relative address of right hand operand; Bits 10-13; relative address of temporary result; and Bits 14-15, code word for the logical operation in question. The program itself is broken down into six distinct sections:
a. Initialization;
b. Input of character;
c. Check input symbol validity;
d. Check syntax and locate parenthesized nests;
e. Scan and process parenthesized nests;
f. Output error diagnostics.
An extensive number of error diagnostics have been generated in association with this package to allow quite flexible recovery from most of the errors encountered in syntactic input. Again, as was the rule for the overall package, this compiler has error diagnostics broken down into two specific types. The first type is the recoverable error, and the second type is the fatal, or non-recoverable error (see Appendix D). The use of the star (*) and slash (/) characters are as described in Section IV., A.
4. Boolean Expression Decompiler
The function of the decompiler is to take the machine representation of a given logical expression, and manipulate it in such a way so as to return to the user the syntax that was originally input at the higher level to create the algorithm, or to return to the user a syntax which is logically equivalent to the original syntax, although not necessarily in the exact syntactic form input originally.
The logical expression decompiler functions in much the same way as the logical expression compiler, except in a reverse manner. It interrogates from bottom to top the packed three-address-code operand words, and creates internal temporaries which hopefully, by the time the last operand word is interrogated, will have disappeared, so that where possible the original syntax is returned to the user. As the individual operation words are interrogated and processed by the decompiler, an internal input string is recreated in the abbreviated form, identical to that used by the compiler. Once the abbreviated input string has been recreated in its entirety, another section of the decompiler scans through this input string, and reconstructs and outputs the syntax required to closely approximate the original entry of the logic expression. When hexadecimal addresses of logical variables are encountered, a request is placed over the computer-to-computer data link to retrieve the actual character representation of the hexadecimal logical address, so that the symbolic notation originally used in the construction of the program will be returned to the user as an output of this symbolic decompile function. The output from this decompiler is a form compatible with that generated by the Symbolic Dump function mentioned previously, so that in chains consisting of mixed algorithms, the printout will be consistent, and acceptable for use as a one-by-one replacement for the original documentation.
Therefore, as in the Symbolic Dump function, the logical expression decompiler generates completely replaceable, completely self-documenting hard copy. In the case where the logical element in question does not have a character representation in the symbol table, the hexadecimal representation will be returned to the user in lieu of the symbolic representation with the syntax X'HHHH', where HHHH is the hexadecimal number, so that the output is readable even if the symbol is not represented on the disc symbol table.
C. Symbolic Variable Representation
1. Use of Computer-Computer Data Link
In the majority of control applications involving both a small logic computer and a larger supervisory computer, one will find a data link existing between the two entities. Typically this would be a parallel data link operating in full duplex mode of operation. In the configuration that we are using for the example in this thesis, the data link configuration is as follows: a. there is a single data link between the logic computer and the supervisory computer, and b. there is a dual data link between the supervisory computer and the logic computer. This is because the traffic between the supervisory computer and the logic computer, i.e. the output of references etc., is much heavier than the feedback information which is transmitted from the logic computer to the supervisory computer. Each data link is capable of a word transfer rate of about 200-220 words per second--these are 16 bit words.
In designing this package consideration was given to using the computer-to-computer data link for the purpose of rolling in and out the various program segments needed for the execution of the debugging package. This was discounted due to the relatively slow speed of the data link and the relatively large amount of on-line control information that must be transmitted across the data link. The transmission of programs across the data link would materially impair the transmission of the necessary data for the on-line control. The decision was made, therefore, to use the computer-to-computer data link in a minimal fashion, making the editing package that exists in the logic computer essentially a stand-alone package, with one exception. This exception in volves the data linking of symbol definitions and symbol table look-up requests between the two machines.
In order to make the use of the data link transparent to the design of the editing package a separate subroutine has been constructed which is linked into the actual editing package itself. A data statement in this subroutine is the determining factor as to whether the subroutine will construct a data link call to the supervisory machine for symbol definition, or in the case that the logic and supervisory functions are combined in one machine, place a call directly to the disc symbol table subroutines which would, of course, be resident in that single machine. So no matter what configuration exists, as far as the host machine is concerned, the symbol table lock-up subroutine call is identical and all of the various levels of software that require symbol definition may place one symbol table subroutine call. By adjusting the parameters within the symbol table look-up subroutine, the decision is made between using the data link and actually calling the symbol table routines in the machine that contains the debugging package.
In the case where the dual computer configuration is utilized, the symbol table look-up subroutine in the logic machine structures a data link called from the logic machine to the supervisory machine, and the symbol table routines in the supervisory machine access the disc to return the hexadecimal address or value associated with that given character representation. The hexadecimal number is then transmitted back across the data link to the logic machine for its subsequent use. The opposite condition exists at certain times where the editing package is in possession of the hexadecimal address for the symbol in question and it also has knowledge as to the symbol table access code which will be discussed later. These two pieces of information, the address and the code, are passed over the data link to the routines in the supervisory machine. At this time a search of the disc symbol table is made to locate the correct character representation of the symbol in question. Once this information is accessed, it is then transmitted across the data link back to the logic machine for its subsequent use.
This minimal use of the computer-to-computer data link is consistent with the original design goals of this package. This package is therefore suitable for operation in a. large control environments where a supervisory computer performs logic functions as well as supervisory functions, therefore the disc symbol table would be in the same machine as the debugging package; or b. medium sized systems where the logic computer data links information to the supervisory machine for processing; or c. very smallest of installations where the logic computer stands alone and does not have access to a disc of any kind. So, since we must operate in that third environment, the minimal use of the disc is desirable in this case.
2. Hash Coded Disc Symbol Table
In order to implement the symbol table look-up procedures mentioned in the previous section, certain symbol table routines have been designed and implemented in the supervisory machine. The following is a discussion of the disc symbol table structure (see FIG. 3).
Assuming for a moment that a certain area of disc has been set aside for the use of the symbol table handlers, the area is partioned in a two-thirds to one-third arrangement. It is important that symbol table access must be rapid in either direction, i.e., from the character to the hexadecimal and from the hexadecimal to the character; so a double-headed symbol table has been designed with the partition as indicated above. The one-third partition is used to store hexadecimal representation in a two word format. Since the disc on the machine in question has a sector size of 256 (16 bit words), one sector in this configuration can store up to 128 hexadecimal numbers.
Word One of the two word entry on this portion of the symbol table contains the hexadecimal address or value of the symbol in question. It is this one word entry in the symbol table that is used by the hash code algorithm to extract the correct sector address for this hexadecimal number. Word Two of the storage pair contains a split field. The first portion of the word, Bits 0-11, contain a sector pointer to a sector in the other portion of the symbol table which will contain the character representation; and Bits 12-15 contain a number which is the code number associated with this symbol table entry. Both of these items require further explanation. In the case of the sector number pointer, a base number is stored away in the machine which represents the starting sector for the entire symbol table, and the character representation of each symbol is stored in the first two-thirds of the symbol table. The sector pointer number therefore points to a relative sector number in the first two-thirds of the symbol table of which sector one will find the character representation of the hexadecimal number contained in Word One of the entry. Since it is possible for two different symbols to map to the same hexadecimal address, a four bit code word is included with each hexadecimal address. Each group of symbols is assigned a specific code number from 1 to 15, and this code number is used to resolve conflicts of the types mentioned above.
As an example, two important entities which are stored on the symbol table are logical bit addresses and sub-level numbers. While by agreement with the users of this package, the character representations will be unique on the symbol table, two different character representations may exist for the same hexadecimal number. The logical bit address 802F, and the sub-level number 802F, are both equally valid; hence the logical bit addresses have been assigned a code number 01, and the sub-level numbers have been assigned a code number 02. Various other entities are assigned separate code numbers as well.
In the first two-thirds of the symbol table, the character representation of the symbol is stored along with the hexadecimal address of that symbol. This is accomplished in a four word format, allowing 64 symbols to be represented on one sector in this area. The first three words of the four word format contain the packed ASCII representation of any eight character symbol. The standard eight bit ASCII with even parity that is used as the character representation by the machine in question is truncated and packed into a modified six bit ASCII format, and the words are shifted so that all eight characters fit within three symbol table words. The fourth word in this section of the symbol table is identical to the first word in the previously mentioned section of the symbol table, i.e. the hexadecimal address or value to be associated with the ASCII stored in the upper three words. Using this configuration and maintaining a 50 percent spare area for symbol table efficiency, it has been calculated that one can effectively store 28.5 symbols per sector. This number can be used in determining the number of sectors needed in the disc storage area as a function of the number of symbols to be stored.
Each of the four subroutines involved in the symbol table storage procedures shall now be discussed. The first subroutine retrieves the hexadecimal number associated with any given ASCII symbol, once the ASCII has been input to the subroutine. As we shall see, this operation can normally take place with one probe of the symbol table. The subroutine first packs the character representation into the three word format compatible with that stored in the table, and then enters a hash code subroutine which takes the three packed ASCII words, adds them together, squares the sum, and then extracts the middle 16 bits from the center of the two word product. This pseudo-random number is then converted modulo the size of this sector area, so that it now represents a relative number from the beginning to the end of the first portion of the symbol table sector area. A disc read is now made and a linear search is made of the 64 entries on the sector in question. If the ASCII equivalent is found on the sector, the hexadecimal number in word position four is returned to the user as the value of that symbol.
In the case where the sector is interrogated and no match-up occurs, the sector number of the sector being examined is entered into the hash code subroutine and a new sector number is created from the old sector number, using the same randomization techniques mentioned earlier. This continues until either the symbol is successfully located in the symbol table area, or all of the sectors have been interrogated and the symbol is not located on the disc. In the latter case it is sufficient only to continue searching through the symbol table until a sector is located which is not completely full. If a sector of this type is discovered, and the symbol has not yet been defined, one can declare that the symbol is not contained on the symbol table.
The next symbol table subroutine uses the hexadecimal number associated with the symbol to search for the actual character representation of the symbol. This operation normally takes two probes of the disc. The hexadecimal value of the symbol is hashed in accordance with the previously mentioned algorithm, and the lower one-third of the symbol table is accessed in an attempt to locate the two word entry mentioned previously. Once the two word entry is located, the sector pointer contained in Word Two will direct the package to the correct sector in the upper two-thirds of the symbol table; hence the two probes. Overflow of the two word symbol table area is handled in a manner analogous to that for the four word symbol table area. These two subroutines represent the major on-line subroutines utilized by the debugging package. However, two other subroutines are provided for symbol table management of the disc.
A symbol table ENTER function is provided which allows one to enter a large number of symbols presumably from some binary input device. Symbol definitions that previously existed on the disc are discarded and the new definitions are put on the disc in place of the old definitions. A symbol table DELETE function is also provided where one wishes to delete a given symbol and no new symbol definition is anticipated.
So a hash coded symbol table with four symbol table handling subroutines is provided: a. fetch ASCII given hex, b. fetch hex given ASCII, c. symbol DELETE, and d. symbol ENTER.
3. Symbol Table Support Routines
Two FORTRAN support routines have been written to aid the user in loading and interrogating the disc symbol table just previously discussed. The first routine is used in conjunction with the symbol table ENTER, and is used to enter symbols from a suitable binary input device. This can be done either by using binary cards or by using binary punched paper tape. The program is interactive in the respect that once it is initiated it asks the user to type into the keyboard the correct information necessary for the activation of the package. One must indicate the binary input device requested; the listing output device requested, if desired; the debug device requested, if desired; and the symbol table access code previously mentioned. Once these numbers are input from the keyboard the package will commence reading from the binary input device.
Two types of hard copy output are provided, as an incidental feature of this package. A symbol table map is output where a listing of each symbol and its definition is provided for the user. In addition to this, a debug symbol table printout is provided indicating the actual sectors onto which the information has been stored for each symbol, and the relative position into each sector where the information can be found. One activates these dump features by selecting a non-zero device for the printing of the listing and the debug information. An indication of zero as a listing or debug device will inhibit either of these printouts.
Another interactive package has been written to provide the user a method of editing the symbol table on a one symbol basis. Again, once the package is initiated, the user merely inputs information that has been requested by the interactive package. The features included are similar to those of the mass input package except that the user may do this on a one symbol basis. He may therefore enter a new symbol, request the ASCII equivalent of the hexadecimal symbol value, or request the hexadecimal value given an ASCII symbol, or he may delete a symbol from the symbol table.
The four basic subroutines discussed in the previous section, plus the two support routines mentioned herein complete the discussion of the disc symbol table and present the user with a very powerful construct in the management of symbols in his system.
D. Simulated Program Execution
1. The Simulate Function
To facilitate the simulated execution of PROGEN-70 chains, a simulate processor has been added to the basic software structure of the debugging package at Level Two. An additional two letter mnemonic, CS, has been added to the system such that any time this mnemonic is encountered by the main processor, control is automatically transferred to Level Two in the chain simulate processor. By examining the input arguments to the Chain Simulate function, one may gain some insight into the operations performed by this simulate processor.
The user is requested to input as Argument One the area of the chain in question over which he wishes to place a Block Trace. The Block Trace is a hard copy printout of the block number being executed, the block algorithm name being executed, and the time of execution in milliseconds. Once this feature is selected and the chain is subsequently placed in execution, the listing output device selected by the user will output a time study of the execution of the chain in question, indicating all blocks falling between the block numbers specified as input parameters that were entered during execution, and the time of entry.
Argument Two is the area of the chain in question over which one desires to have placed the Input-Output Trace. This Input-Output Trace is an enhancement of the Block Trace in that all of the information contained in the Block Trace is presented to the user plus information concerning the state of all of the dynamic variables associated with a given block. In some of the PROGEN-70 algorithms the arguments are all fixed in value, and merely perusing the source listing of the program will determine the value. These items are not included in the I/O Trace. Only those values which may change during the execution of the program are included, such as the state of logical variables in the system, the state of dynamic arguments to the program algorithm etc. are included in this trace. A complete summary of trace formats is included in Appendix E.
Argument Three is a time multiplier which allows one in the simulated mode to expand time to give a more deliberate evaluation of the control chain or group of control chains. An entry of One in the Time Multiplier position will assure the running of the chain in real-time, while a multiplier of Two will expand time by two. A chain normally performing a sequence in one second will now take two seconds. In essence, all software created delays in the execution of the chain will be multiplied by the number indicated in this argument.
Argument Four is a Run Counter. The Run Counter may be set to any arbitrary number and subsequent executions of the control chain will be traced using the Block Trace and I/O Trace to a suitable listing output device and the number will be decremented. When the number reaches zero, the simulation and tracing will be terminated and the control chain will continue to function in a normal manner. This is very beneficial during periods of on-line debugging where the computer operator will not be present during the execution of the chain, i.e. an evening rolling turn in a steel mill. If the operator wishes to observe the next 16 executions of a given chain but he will not physically be present in the computer room, he can select the Run Counter to be 16 and then exit. The next 16 operations or executions of the control chain in question will be logged out on the selected listing device and then the tracing function will be terminated and the control chain will continue to function in the normal manner for the rest of the time.
Thus it can be seen that the Chain Simulate function has the capability of tracing, on a block-by-block basis, events which occur within a chain in two forms: either with an abbreviated trace indicating only the block entry, time, and the block number or block type, or an expanded trace including that information plus the tracing of the change of state of all dynamic input-output variables. Also found is the feature of time multiplication and the ability to set up a predetermined number of simulated runs.
This is not enough information to be input to the Chain Simulate function, but this is all the information that may be entered using the normal syntax associated with the original package. Once the Chain Simulate processor is entered, a request is typed on the selectric typewriter requiring the user to input information pertaining to the dynamic variables that he desires to have simulated during the execution of the chain. Once these variables have been entered, the package asks the user if he desires to have a one time execution of the chain to begin immediately. If the answer is no, the package will be armed and wait until the next actual on-line execution of the chain, at which time the simulation and tracing procedures will occur.
The software required to simulate the various dynamic variables in the system is discussed in general here and then in subsequent sections the interface and the modifications to the interpreter will be discussed in more detail. Assuming, for an example, that a logical variable has been input as a variable designated to be simulated; as a result of this input, the logical address of the variable in question will be placed in one of the locations in the 60 word logical address simulation table for use by the Bit Manipulation routine. Also, the name of the chain will be placed in a five word sub-level number table also for use by the Bit Manipulation routine.
Since all run-time requests to set or reset logical elements pass through the Bit Manipulation routine, assuming the simulate mode has been selected; the Bit Manipulation routines have been modified to check the five word sub-level table and the 60 word bit table before proceeding with normal Bit Manipulation. If a. the chain being currently executed is in the sub-level table, and b. the logical bit address currently in question is found in the 60 word bit table or logical address table, no hardware consequences will occur as a result of any of the Bit Manipulation operations. In lieu of hardware consequences, the request to set and/or reset a given logical element will be simulated by using Bit 13 of the actual bit address which is stored in the logical address table. Therefore, by interrogating Bit 13 of the logical address in the 60 word logical address table, in lieu of interrogating a hardware element, the correct status of the bit in question can be determined readily.
As far as the Trace Printout is concerned, bits will be traced in the normal way with the ASCII symbol being shown and the actual state of the logical variable. However, because the user has selected the simulation mode for this variable, only Bit 13 of the logical address table entry will have changed. Other variables are simulated through changes directly in the control chain interpreter, which shall form a part of a subsequent discussion in this section.
In order to exit the package, by entering a minus number as the first argument of the CS function, a separate branch is taken in the package and the user is interrogated as to his desires in three areas: a. he is asked whether he wishes to terminate the Block Trace, b. he is asked whether he wishes to terminate the Input-Output Trace, and c. he is asked whether he wishes to terminate the simulation of the variables that he has indicated previously. By answering these three questions correctly, one may return the chain to the normal run-time situation, removing all the simulation and tracing features.
This briefly describes the power of the simulate function from the user's point of view. In a subsequent section the interface between the simulate section and the rest of the PROGEN operating system shall be discussed.
2. Interface with Run-Time System
FIG. 4 graphically illustrates the steps involved in simulating the execution of a chain. This figure also shows the various core files which are used to support simulated chain execution. A description of these core files is presented in the paragraphs which follow.
The input information mentioned in the previous section is condensed by the Chain Simulate function and stored in an eight word simulate file. Up to five chains arbitrarily may be simulated at one time, so this results in a forty word simulation file area in common. Word One of the simulation file contains the actual core starting address for the chain in question. Words Two and Three contain the starting block number and the ending block number for the Block Trace. Words Four and Five represent respectively, the starting block and the ending block for the Input-Output Trace. Word Six contains the Time Multiplier integer. Word Seven contains the Run Counter. Word Eight is a flag word which is used by the other various run-time processors to determine the mode of the simulation in question and each bit in the flag word has a particular significance.
It is seen that in a file of eight words one can represent the information needed to be interchanged between the chain simulate processor of the debug package and the actual run-time system, with the one exception of logical variables to be simulated. These logical variables are entered into a 60 word logical variable file which is accessed by the Bit Manipulation routines as necessary. A five word table is also maintained to indicate the sub-level number of the chains currently being simulated. There is another single word utilized to indicate whether any simulation of any type is occurring in the system. So, with a total of 106 words in common, the interface for the simulation package has been completely defined (see FIG. 4.3).
3. Interpreter Modifications
In support of the Chain Simulate function, the PROGEN-70 control chain interpreter or processor has been modified extensively to include the enhancements necessary to perform the simulated execution of chains. The control chain interpreter has been restructured to allow conditional assembly so that one may specify at assembly time whether the enhanced version of the interpreter, or the standard version of the interpreter is desirable. The enhanced version of the interpreter adds about 280 core words to the total length of the run-time interpreter package.
Assuming that the simulation option has been selected and assuming a chain that will be simulated is now ready for execution, the control chain interpreter will interrogate the first word of the eight word simulation file table. If a non-zero entry is found, a comparison is made with the starting location of the chain being executed. If a match is found, this is a chain to be simulated. To facilitate access by the algorithm processors of the interpreter, the eight words of information contained in the simulation file are transferred to the task header of the sub-level task currently executing this particular chain. Once this transfer has been made, control chain interpretation continues in a normal manner until the first algorithm to be interpreted has been encountered, but prior to the time that the interpreter branches to the actual algorithm handler. In the iterative part of the main control chain interpreter which handles the entry of all algorithms, a check is made comparing the block number of the current algorithm being interpreted to the starting and ending block numbers indicated in the simulation file image in the task header. A series of flag words are then used to indicate whether the I/O Trace or the Block Trace or both traces are to be implemented on this particular algorithm. If the Block Trace is to be performed, it is performed in the iterative section of the interpreter, and certain condensed trace storage words are created and placed in a circular queue of size 256. The circular queue is then empted by a low priority FORTRAN task which will call the run-time formater and actually print out the correct trace information in the format desired. This is done so the interpreter will not be slowed up with the task of formating and printing trace messages.
Once this task is completed in the main section of the interpreter, the algorithm branch table is accessed, and a branch is placed to the start of the actual algorithm handler for the particular algorithm in question. It was necessary to imbed in each of the algorithm handlers the code necessary to perform the Input-Output Trace of the variables, and to perform the simulation of the word oriented variables. Therefore, each algorithm handler contains conditional assembly instructions which will be assembled into the interpreter if the simulation mode is chosen. Each algorithm handler checks the Input-Output Trace flag to determine if Input-Output tracing is desired. If such tracing is desired, the correct input-output information is condensed into Input-Output Trace storage control words, and such trace storage control words are stored in the 256 word circular queue for later printout.
Even though the modifications to the interpreter seem extensive in relation to the original interpreting package, the actual run-time consequences of such an extension are minimal. The response of the process in question is not of a nature that is critical, such that high response times are needed. By degrading the speed of the control chain interpreter by a few milliseconds, a very powerful method of tracing and simulation has been incorporated into this package.
4. Modified Handling of Logicals
It was mentioned previously that the Bit Manipulation routines included as part of the PROGEN-70 operating package have been modified slightly to allow the performance of logical bit manipulation in a simulated mode. The three logical operations in question are Logical Set, the assignment of TRUE to the variable in question; Logical Reset, the assignment of FALSE to the logical variable in question; and Logical Check, the interrogation of a logical variable and the return to the user some indication, either true or false, of the state of the logical variable.
In the case of the Logical Check, a normal subroutine call is placed by the user and the results are returned in the accumulator: either zero or minus one depending upon the actual state of the logical, zero being TRUE, and minus one being FALSE. This bit checking subroutine has been modified to place a check in the sub-level table mentioned previously to determine if the sub-level in question is one being simulated, and then to perform a subsequent check of the 60 word logical address table to determine if the logical address currently being input is to be found in the 60 word file. If the logical word is found in the file, the check routine simply interrogates Bit 13 of this word, and if Bit 13 is a zero, the value minus one is returned to the user, representing FALSE. If Bit 13 is a one, the value zero is returned to the user, representing the TRUE condition. As can be seen in this example, no interrogation of the actual hardware bit is accomplished in any way. Only the Bit 13 image is utilized.
In the case of Logical Set and Logical Reset, the same five word sub-level table and 60 word logical address table are interrogated. If in fact the sub-level is the correct sub-level and the logical bit address does appear in the logical address table, Bit 13 of the bit address mentioned in the logical address table will be set to one, or reset to zero depending upon the desire of the user.
So that up to five chains can be simulated simultaneously, there is no distinction made as to which logical element is associated with which given chain, hence one is allowed to simulate logical addresses across chain boundaries, i.e. one is allowed to set a bit in one chain and check its status in a subsequent chain. The above mentioned procedures give a very flexible yet powerful method of handling simulated logic.
5. Modes of Simulation
The basic modes of utilization for the simulation package are discussed in this section. During the course of computer process control project execution, there are three periods of time where the use of this package is extremely helpful.
The first phase, which is the individual checkout phase or individual debug phase, consists of the individual engineer generating, loading, and testing a relatively small number of control chains in a totally artificial environment. This individual checkout might proceed prior to the time that a sophisticated operating system had been installed, so the individual is essentially left to rely upon the power of the simulation and trace features of this particular package. During this individual checkout phase, both internally simulated inputs and internally simulated outputs would be utilized. Internally simulated inputs and outputs are those inputs and outputs which are simulated using the methods described in the paragraphs above. Essentially, therefore, all of the variables in the control chain are selected as simulated variables, be they inputs or outputs. The Block Tracing features and the I/O Tracing features are activated and the control chain or group of control chains in question are initiated. Hence, in this phase, only the integrity of the individual group of chains may be determined without respect to the actual operating system or the actual process involved.
In Phase Two, which is called in-house testing, or system test phase, the power of a larger system simulator is invoked and therefore it is not necessary to simulate inputs and outputs directly. In this Phase Two however, it is quite important to utilize the features of Block Tracing and Input-Output Tracing previously mentioned; also the expansion of time is helpful in this area.
Phase Three is actual on-line testing. This would occur after the computer had been shipped to the control site, and the actual process inputs and outputs had been connected to the computer hardware. In Phase Three, there are two different sub-phases which may be utilized to further test the control software.
In the first sub-phase one may decide to test a group of chains using the actual process input parameters and simulated output parameters. This would work in the following manner. Assume that a certain control chain is functioning moderately well in the actual on-line environment, but the control engineer wishes to make a minor change in the control philosophy, and then test the consequences of this change in a simulated manner prior to activating in the on-line environment. The engineer could simply bring the original chain into the working area of the debugging package, change the sub-level number of the chain to create a second chain, make the minor alternations to this second chain, and then link this second chain back into the operating system, connecting all triggers so that the new, modified chain will run concurrently with the original unmodified control chain. The actual outputs from the modified control chain would be selected to be simulated and both Block and I/O Traces could certainly be selected on both of the chains in question. Now at the time that the process decides that the chain in question is needed, a hard copy printout of the performance of both of the chains will be presented to the control engineer at a suitable listing device. Once the control engineer is satisfied that the new control chain is operating in an optimal way, he may then remove the original chain from the on-line system and activate the modified chain in its place.
The second sub-phase of on-line testing using the features of the simulation package would be to allow the control chain to operate using process inputs and process outputs and just employ the powers of the Block Trace and I/O Trace in checking a suspect chain for proper performance. This can be done at any time, either during computer start-up or any subsequent time when control situations would warrant such a move. In this environment, the utilization of the Run Counter is important since one may wish to monitor various iterations of a given control chain during periods of time when one is not physically present in the computer room of the process. One could, therefore, initiate the Block Trace and I/O Trace with a Run Counter of ten, allowing ten iterations of the operation of this particular control chain to be traced completely to the listing output device before the chain would revert back to the normal mode of operation; for the remainder of the period of time with no further output being logged.
The above phases and sub-phases of control chain checkout certainly do not represent all of the possibilities that could be invoked in the checking of chains in a complex control situation, however, they are most typical of the types of utilization for the package in question.
6. Trace Data Collection and Printout
As mentioned previously, the PROGEN-70 control chain interpreter has been modified extensively to include the Trace and Simulation features indicated in this package. Even though the process timing is quite slow in relation to the interpretive speed of execution of the computer, it would place too much of a burden on the computing system to actually attempt to print trace information using a listing output device on a same task priority level as the actual execution of the control chain. Therefore, an interface has been established between the actual run-time control chain interpreter and a low priority FORTRAN program, which actually does the printing of the trace information.
The heart of the interface is a circular queue containing trace control words. This queue can be of any length, nominally 256 words. The queue is loaded from the control chain interpreter via subroutine call which concentrates the trace control data into packed trace control words and stores these control words circularly in the queue. A periodic program checks the input in the queue, and when the pointer has shifted, a bid is placed for the FORTRAN task; which in turn enters the queue, extracts the trace control words in order, and reformats them into a format suitable for output to the selected logging device.
Actually, there are two levels of message buffering utilized in this system to prevent any trace data overflow. Once the FORTRAN program has reformatted the messages suitable for output to the logging device, the disc message writer is utilized to store the output messages on disc, in the event the logging device is busy typing another message. This message writer disc queue is extremely large, therefore, it is quite unlikely that trace messages will be lost during actual simulation conditions. Examples of the trace printout of each of the algorithms in question are included in Appendix D.
E. Added Algorithms
1. Use of "Simulate Only" Blocks
To facilitate and enhance the use of simulation techniques mentioned previously, a new set of algorithms has been created. These algorithms are identical to the algorithms previously created with the exception that they are labeled Simulate-Only algorithms and their existence in a control chain represents a simulate-only block which is executed only when the control chain interpreter is in a simulate mode of execution on this given control chain.
A specific bit in the block header is utilized to indicate this simulate-only mode, and this bit is subsequently checked upon block entry by the control chain interpreter. The use of the simulate-only block proves to be very helpful during the Phase One of control chain checkout, which is the individual checkout phase. During this phase there is no support software of any magnitude available for the use of the control engineer, so all of the simulation power must be built into the simulation package he is using. Therefore, in the testing of a given control chain using Phase One procedures, the testing is out of context in relation to the other chains. At the entry of the control chain being tested, it may be very desirous to create a simulate-only initialization block which allows certain control parameters to be initialized to have certain specific values. In the normal mode of operation these parameters would have been initialized by previous chains. However, in this single chain checkout mode of operation, this is not possible, so a simulate-only block may be utilized to provide the various initial values for these parameters.
The first of two of the most popular simulate-only blocks would be that of the Set-Reset block which allows the control engineer to establish the state of the logical variables which are inputs to the control chain. The second useful simulate-only block would be Data Initialize, which would allow the control engineer to initialize certain areas of core to have certain starting values.
The simulate-only blocks could actually be left in the chain structure for a fairly long period of time, for instance until the control chain had been checked in the on-line environment and everything was working optimally. At that time, using the Modify function of the debugging package, the simulate-only block could be removed at the convenience of the control engineer.
2. Interpreter Modifications
In order to implement the simulate-only block feature, the PROGEN-70 control chain interpreter was further modified to place a check for the given bit in the block header. If two conditions exist, the simulate-only block will be executed by the interpreter. These conditions are: a. that the flag bit in the header of a given block is set to indicate simulate-only, and b. that the control chain being currently interpreted is a control chain that has been chosen for simulation by the Chain Simulate function of the debugging package. If both of these conditions are met, the block in question will be executed as a normal control algorithm. If either one of the conditions is not met, the block will be skipped over by the control chain interpreter and no execution of the algorithm will take place. Each algorithm handler in the control chain interpreter is modified to add this by-pass feature.
V. QUANTITATIVE RESULTS
A. Modification of Existing Program
This section demonstrates the ease by which an existing PROGEN-70 control chain may be modified, using the modification and dump features of the debugging package. Observe that the chain shown in FIGS. 5A and 5F section is a chain containing seven control algorithms. Two of the control algorithms are trivial in that one is the Chain Header algorithm and the end algorithm is the Exit algorithm. So, there are really five active algorithms in the chain. Notice that the complete listing of the example control chain was created by using the Chain Dump feature of the debugging package. Also notice that by using the extended feature of the Chain Dump function one is able to perform a Chain Acquire and a Chain Dump operation concurrently with only one entry. Following the Chain Dump operation, we shall demonstrate in the following order:
1. Modification by Replacement;
2. Modification by Insertion;
3. Modification by Deletion.
In FIGS. 5A-5F, 6A-6C, and 7A-7E, a typical interactive terminal printout is illustrated. Items entered by the operator are underlined. All other entries represent computer response to operator input.
FIGS. 5A and 5B illustrate modification by replacement. These figures demonstrate the replacement of the original block 20 with a new block 20, still retaining the same number of algorithms as in the original chain, the only difference being that now block 20 is an algorithm different from the original block 20. Modification insertion is illustrated in FIGS. 5C and 5D, where a new control algorithm is created and subsequently inserted in a position between block 20 and block 30. The new block, block 25 extends the length of the control chain so that storage back into the space originally reserved for this chain would be impossible. Therefore, the storage originally reserved for this control chain, once we activate it, is released and new storage is acquired. Modification by deletion is illustrated in FIGS. 5E and 5F. In this example, block 20 is completely deleted from the control chain and in this way the size of the chain is shortened. Again, note the storage allocation procedures utilized by this package.
These three steps represent the normal modes of operation for the modification function. In these figures, one may also see the utilization of the Chain Acquire and the Chain Activate functions and their subsequent allocation of core storage.
B. Creation of New Program
FIGS. 6A, 6B, and 6C illustrate the creation of a new PROGEN-70 control algorithm. The creation of a new control algorithm is initiated by using the Chain Acquire function to acquire a dummy chain, consisting only of a Chain Header Module and a Chain Exit Module. This is the null control chain which performs no meaningful action. Once the dummy chain is acquired and moved into the working area, the Chain Modify function is used interactively to enter the subsequent intervening blocks. Notice block 10 is entered first, then block 2o, then block 30, then block 40, and then block 50. Now there is only one correction necessary to make this a newly operating chain. Using a separate Chain Modify, the Chain Header is modified to insert a new sublevel number, so that the chain will obtain a separate identity from the others. Notice also that as the chain is modified, algorithm by algorithm, the algorithms containing relative addressing are updated to point to the correct target algorithm, even though the referenced algorithm may have moved in relative location with respect to the beginning of the chain. This is an automatic feature of the Chain Insert function, which is part of the Chain Modify processor.
C. Simulated Execution with Trace
In the following simulated execution example (See FIGS. 7A, 7B, 7C, 7D, and 7E), a chain is executed which simply toggles a light on and off at a repetitive rate. Observe that upon activating the Chain Simulate function and immediately requesting a bid for this chain (see example in FIG. 7A), a trace printout is provided (FIG. 7C), which very accurately describes the time of occurrence of each event and the action taken as a result of that event. Also note that this example has been run a number of times. A second example (FIG. 7B at top) is used to demonstrate the operation of the Time Multiplier, which expands time, as seen by the millisecond printout on the trace (FIG. 7D). The last example in this area FIG. 7B, middle demonstrates the use of the Run Counter, at which time the tracing (FIG. 7E) continues for three iterations of the execution of the chain in question, and then terminates, even though the chain continue to function. The last step is, of course, to terminate this operation using the Terminate inputs to the Chain Simulate function (see FIG. 7B at bottom).
VI. EVALUATION AND FUTURE WORK
A. Summary of Accomplishments
The most important features of the invention include: 1. the ability to make modifications in an existing control operation without the use of recompilation procedures which expend time and which effort, and are unnecessary utilizing this package; 2. the fact that the listing output from this package is identical or even somewhat enhanced from the original compile listing output (this aspect of self-documentation is considered among one of the most important benefits); 3. the conventional manner in which the user can communicate with this package, due in part to the interactive nature of the overall design of the package and also due to implementation of the disc symbol table procedures; and 4. the consideration of the ability to simulate a single control chain or a given number of control chains prior to the time that the actual hardware is available for testing. This last feature allows control engineers to meet software shipment schedules even though hardware schedules may slip, and further allows the customer to make rapid changes in his on-line control system with a high degree of assurance that these changes have been tested to a degree that will insure proper operation once brought into the on-line environment.
B. Extension to Other Fields
Just as the final representation of this package is an extension of the works of others in the field of on-line debugging techniques (See "DEBUG--An Extension of Current On-Line Debugging Techniques" by T. G. Evans and D. L. Darby in the May, 1965 issue of Communications of the ACM), this can certainly serve as a base for more adventurous debugging schemes, either in process control or in some other environment which lends itself to real-time applications of computing. One can envision an extension into the field of airline ticketing and route selection in which qualified personnel would be able to create new, more suitable, ticketing and routine algorithms, and then test the consequences of the utilization of these algorithms in a simulated environment prior to actual use. The simplicity of the data structure of PROGEN-70 certainly lends itself to this type of debugging approach, but this is not a necessary factor in order to create such a package. Certainly other high level languages, even though they would employ a more sophisticated data structure, could be successfully messaged to accept a debugging package similar to that which has been created for PROGEN-70.
C. Areas Requiring Future Work
The package as it is now constituted is limited in a number of ways to a use of only 16 control algorithms. Much of the table structure existing in Common would have to be modified fairly extensively to allow the insertion of algorithms beyond 16. This would take a relatively short period of time to accomplish, and would be a meaningful addition to the package.
It can also be noted that it would be desirable to expand the capability of Input-Output variable simulation to the extent that variables could be added and deleted singly without requiring the mass deletion as is now required. In other words, a function allowing deletion of simulation variables by name would be a desirable extension, and again an extension which would not require a great deal of effort.
Possibly the most significant extension to this package would be the creation of an interface with a CRT display and keyboard, so that the speed of interaction could be increased over the current IBM selectric. A great deal of thought has been given to this. Actually, current thinking indicates that a graphic picture or symbolic representation of the control chain in question could be displayed on a CRT in such a way that one could address the variables from the keyboard without having a hard copy present for perusal. Since interactive CRT systems are becoming an integral part of process control in the 70's, an extension of the debugging package to include a CRT interface would be a very logical step indeed.
VII. PROGRAM LISTINGS
A. Explanation of Program Listings
What follows are computer programs which may be used to implement the present invention. Some of these program listings are written in a modified version of the language FORTRAN IV, and some of the listings are written in the assembly language of the Westinghouse P2000 computer system.
The modified FORTRAN IV language used in writing some of the listing is substantially in compliance with the FORTRAN IV language standards approved by the United States of America Standards Institute (X3, 9-1966) on Mar. 7, 1966. The following are some of the more important ways in which the modified language differs from the approved language: A BIT declaration statement allows a 16-bit variable to be declared a bit variable. Each bit of such a variable may be addressed through the use of a subscript notation similar to that used in addressing the elements of conventional one or two dimensional arrays. An ORG statement permits the absolute origin of a program segment to be specified. The use of apostrophes as quotation marks in Hollerith data is permitted. Statement functions may reference array elements. Hexadecimal constants (preceded by X and contained in apostrophes) may be used in DATA statements. The colon is included as a special alphabetic character. The compiler contains a table of 32 predefined executive and library subroutine names. The logical operator EOR is added to the standard FORTRAN IV list of logical operators. DATA statements may include references to a full array by using the array name without subscripts. In-line assembly code is permitted if the assembly language statements are preceded by an S. Other variances which do not appear often enough to be worthy of mention are listed on page B-1 of technical publication TP034 of the Hagan/Computer Systems Division of Westinghouse Electric Corporation, Pittsburgh, Pa.
The assembly language program listings are coded in the standard symbolic assembler language which is used in the P2000 computer system. This language is described in the manuals TP045 and TP033, both of which are available from the Hagan/Computer Systems Division of Westinghouse Electric Corporation, Pittsburgh, Pa. The following paragraphs present a brief explanation of this assembly language.
The first (optional) element of each assembly language program statement is a unique decimal number for each statement in a given listing. In many cases, however, this first element is omitted.
The second (optional) element of each assembly language program statement is a name which is to be associated with the instruction or the data value that comprises the remaining portions of the same statement. Some of these names ultimately are associated with numerical addresses within the process control system, while others are temporary data storage locations used only by the assembler program. The latter names have been left in the listings to facilitate their readability and clarity.
The third (required) entry in each assembly language program statement is a three-letter command. The commands are of two types--machine instructions and assembler directives. A brief description of each command follows:
The fourth (optional) entry in an assembly language program statement is an argument or an address that goes with the command in the same program statement. If this fourth entry is a number, and if it contains no quotation marks or other special symbols, it is a decimal number. A fourth entry that is surrounded by apostrophes and that is preceded by an X is a hexadecimal number. A name in column 4 designates either an address within the computer system or a predefined value within the assembly program. The fourth entry may be a literal. An equal sign precedes a literal fourth entry. During assembly, the value or address which corresponds to a literal entry is computed and is stored within the direct address range of the command which refers to the literal, and a pointer to this value or address is stored with the common. Indirect addressing in the fourth entry is indicated by an asterisk preceding the entry. For example, "#B" means "the contents of the location whose address is stored in index register B." Commas separate the elements of a fourth entry which jointly participate in multiple level address calculations. For example, "1, B" is a reference to the location whose address is the contents of index register B plus 1.
Hexadecimal constants which are used frequently in assembly language programs are stored in a low core storage area where they may be addressed directly. Usually (not always) such constants are referred to by the names listed below. Each of these names is associated with a low core storage area where the corresponding hexadecimal number is stored.
B. Subroutine Name List
For the convenience of those who wish to learn the details of the invention as revealed by the computer programs which follow, the following alphabetical list of subroutine and program names has been compiled. Number references are references to the numbered subroutines and programs which follow. In the case of conventional subroutines and programs for which no listing is provided, a brief explanation of the subroutine or program is presented.
APPENDIX A: PROGEN-70
A complete description of the PROGEN-70 system may be found in the Gomola, et al. application cited at the beginning of this specification. Of particular relevance to the present invention are the following sections of the Gyres, et al. application:
1. Overview of the System
7. The Control Chain Processor (herein referred to as the "Control Chain Interpreter")
8. Control Chain Algorithms and the Use of Control Chains.
9. The Auxiliary Synchronizer
10. Task, Subtask, and File Bidding Processor
11. The Logic Initiator Program
In addition, the Gomola, et al. application includes a number of program listings which are called upon by the programs and subroutines disclosed above.
APPENDIX A: PROGEN-70 LOGIC SEQUENCING CONTROL
The Westinghouse PROGEN-70 Process Oriented Language is a powerful means of writing director control functions in the form of a sequence of algorithms. The sequence, or `chain`, of algorithms is defined by the user for specific director functions to be accomplished in the process. The functions which can be performed by PROGEN-70 are similar to functions which are performed by `hard wire` switching logic found in many process director control systems.
The algorithms are chosen to meet the needs of a specific process control application. The algorithms may be chosen from an already existing list, or new algorithms may be defined to meet special needs. Once an algorithm is defined the computer system is initialized to handle the algorithm. The user may then use the algorithm to his best advantage throughout the process.
A great advantage to utilizing PROGEN-70 is the ease of implementation. It has been found that if a detailed flowchart is available for a control function showing the names of signals to be processed in that function in symbolic form, then the PROGEN-70 source deck may be completely coded. The user does not need to know anything about the computer operating system, input/output software or hardware, storage allocations, or in general anything about the computer. This is not generally true of other process control languages.
Algorithms
Algorithms for Logic Sequence Control are listed below:
1. LOGIC--Used to evaluate a logical expression according to the rules defined under `Logical Operators`;
2. TSTBRL--Used to perform a conditional branch within a chain, depending on the state of a logical variable;
3. LOGTDT--Logical Time Delay--True--Used to set an `output` logical to a true state after a specified period of time, if the `input` logical remains true. If the input logical changes to the false condition before the timer expires, no action is taken;
4. LOGTDF--Logical Time Delay--False--Used to set an `output` logical to a false state after a specified period of time, if the `input` logical remains true. If the input logical changes to the false condition before the timer expires, no action is taken;
5. TIMER--Used as a time delay in a logical sequence;
6. BID--Used to place a bid for another subtask level in the system;
7. PROGRAM--Used to call a subroutine in the system;
8. SET--Used to set a logical variable to the `true` condition;
9. RESET--Use to set a logical variable to the `false` condition;
10. SETRST--Used to set and reset a number of logical variables;
11. GOTO--An unconditional branch within a chain;
12. PERM--Used to check a specific group of logical variables which are permissives for a specific action;
13. DIAG--Used as a diagnostic aid when an automatic sequence fails to perform correctly;
14. DATRNS--Used to transfer and/or initialize word oriented data;
15. EXIT--Used to terminate a logical sequence.
Logical Operators
APPENDIX B: SUMMARY OF CONTROL COMMANDS
1. General Command Syntax
Where: PAR entry may be of the form: LOC1-LOC2; CC is any valid 2 character control mnemonic.
2. Chain Acquire
This function 1. copies chain into working area, 2. fetches all chain triggers.
Where:
CHAINAME=Alphanumeric chain name of up to 8 characters or hexadecimal sublevel number of the form X`HHHH`.
HHHH=Four hexadecimal numbers with leading zeroes if needed.
3. Chain Modify
This function
1. asks for block # and algorithm name of new block;
2. creates block header;
3. interrogates user for algorithm parameters in high level syntax;
4. builds new block in block working area;
5. inserts new block into local copy of chain;
6. fixes up all relative references in chain as a result of insertion;
7. simulate-only blocks created through use of PAR2
Where:
FSTBLK=Block number of first block to be removed.
LSTBLK=Block number of first block to be retained following modified area in chain.
SIMONLY=0 or 1, if 0 (or not used) normal block is created, if 1 (or any non-zero) simulate-only block is created.
IF FSTBLK=LSTBLK, new block is inserted in front of FSTBLK.
4. Chain Dump
This function
1. acquires chain if PAR2 contains valid chain name;
2. allows selection of listing output device and either regular or extended dump formats via PAR3;
3. allows `dump-with-value` option via PAR4;
4. reconstructs original high-level syntax wherever possible;
5. outputs hard copy dump to selected listing output device.
Where:
FSTBLK=First block number to be output.
LSTBLK=Last block number to be output.
CHAINAME=Alphanumeric chain name or hex sublevel #.
LODEV=Listing output device (+16 for EXT dump).
DMPVAL=0 or 1, if 0 (or not used) no dump with value, if 1 (or any non-zero) dump with value option is selected.
5. Chain Activate
This function
1. disables old chain;
2. returns core space for old chain to free list;
3. deletes all triggers for old chain;
4. acquires core space for new chain from free list;
5. moves new chain image into active core area;
6. links new chain into sublevel processor;
7. ables the new chain;
8. selects trace on new chain via PAR1;
9. connects all new chain triggers into digital scan.
Where:
TRACE=0 or 1, if 0 (or not used) do not trace chain, if 1 (or any non-zero) trace chain blocks.
6. Chain Punch
This function 1. acquires chain if PAR1 contains valid chain name, 2. produces binary copy of chain on selected binary output device.
Where:
CHAINAME=Alphanumeric chain name or hex sub-level number (punches from working area if this argument is not present).
7. Chain Simulate
This function
1. inputs simulation and trace information from the user;
2. formats input information and stores into 8 word simulation file;
3. adds desired logical bit addresses to 60 word bit table;
4. places a bid for chain if requested;
5. terminates simulation if requested.
Where:
FBLKT=First block for block entry trace.
LBLKT=Last block for block entry trace.
FIOT=First block for input/output trace.
LIOT=Last block for input/output trace.
TMULT=Time multiplier.
RCOUNT=Run counter.
APPENDIX C: ERROR DIAGNOSTICS
Summary of Error Diagnostics for Logic Expression Compiler
Recoverable Errors
Error 5 Symbolic input greater than 8 characters.
Error 6 Logical operator prior to assignment statement.
Error 7 Incorrect use of unary operator .NOT.
Error 8 Incorrect use of binary operator .AND. .OR. .EOR.
Error 9 Incorrect use of symbolic logical variable.
Error 10 Undefinable implicit logical variable.
Error 11 Logical variable not in symbol table.
Error 12 Too many right parenthesis.
Error 13 More than 16 logical variables input.
Error 14 Improper termination of input string.
Error 15 Incorrect use of left parenthesis.
Fatal Errors
Error 17 Intermediate buffer length exceeded.
Error 18 Internal branching error.
Error 19 More than 8 parenthesized nests.
Error 20 More than 16 internal temporaries needed.
Error 21 Left-hand operand not located.
Error 22 Right-hand operand not located.
Error 23 More than 32 packed commands processed
Summary of Error Diagnostics for Other Processors
Error 100 Incorrect command initiation (no exclamation).
Error 101 Command not recognized as valid.
Error 102 Argument not recognized as valid.
Error 103 Incorrect use of delimiter or termination.
Error 200 Illegal block number input.
Error 201 Illegal character in algorithm name.
Error 202 Illegal algorithm name input.
Error 210 Cannot locate block # in current chain.
Error 211 Modified chain exceeds maximum allowable length.
Error 212 Illegal algorithm type encountered in chain.
Error 300 Exit algorithm missing from chain.
Error 400 Invalid sublevel number input for acquire.
Error 401 Chain size too long to acquire.
Error 500 Invalid sublevel number input for activate.
Error 501 Invalid trigger--cannot connect.
Error 502 Invalid subtask #--cannot link.
Error 503 No core available to store new chain.
Error 504 Cannot delete previous triggers.
Error 600 Invalid entry for chain name.
Error 700 Cannot find hex address for given ASCII symbol (SYMHEX).
Error 701 Block length exceeds maximum allowable for this algorithm.
APPENDIX D: TRACE OUTPUT EXAMPLES
Claims
I claim:
1. A system for controlling the operation of devices in an industrial process, said system including: a process control digital computer system having a memory; means for applying input signals from said devices to said computer system; a plurality of algorithm-defining data sets within the memory of said computer system which specify how the states of some input signals are to be adjusted at least in accordance with the state of other input signals; means for receiving from said memory and for operating display means to display any of said data sets to a human operator on demand, said receiving and operating means including means for translating said data sets into a terminology with which the human operator is familiar prior to display; means controlled by a human operator for operating on a displayed data set including means for deleting portions of data sets and means for making additions to data sets so as to generate an edited data set for display and so as to establish or modify the operating configuration of the process devices when such data set is re-entered into said memory; means for coupling edited and unedited displayed data sets to said memory, said coupling means including means for re-translating said data sets into a machine-executable language prior to storage; and means for generating output signals to operate said devices as a function of the input signals and the data sets as established in said memory and edited from time to time.
2. A system in accordance with claim 1 which further includes: means for operating on specified input signals in accordance with selected data sets to simulate the execution of said data sets in real-time, and means for recording signal state adjustments called for by data sets under simulated execution.
3. A system for controlling the operation of industrial process devices whose states are represented by device-generated input signals and whose states may be altered under output signal control, said system comprising: a process control digital computer system including a memory; signal conveyance means for coupling input signals from said devices to said digital computer system; means within said computer system for receiving said input signals and for maintaining within the memory a machine-readable record of the state of each of said input signals; means for entering within said computer system and for maintaining within the memory a representation of a human comprehensible name for each input signal along with the address of the corresponding signal record; means within said computer system for maintaining within the memory machine-readable control chains which are stored sequences of linked algorithm-defining data files, each defining how and when the state of one or more input signals are to be altered at least in accordance with the state of other input signals, and each including variable linkages to the state-records of the one or more input signals to which each control chain relates; means for executing control chain algorithms at predetermined times to generate computer output signals for the process devices; means for translating representations of the control chains into representations of algorithm statements understandable when displayed to a human and including means for replacing a variable linkage in such a statement with a representation of the name of the corresponding input signal; means for operating display means to display the stored representation of any control chain on demand, said means for displaying utilizing said means for translating to render a displayed control chain intelligible; means for operating on a displayed control chain to generate an edited control chain on demand; means for re-translating representations of a displayed and edited or unedited control chain into a machine executable language and including means for replacing a representation of an input signal name with a linkage to the corresponding state-record; means for returning displayed and edited or unedited control chains to the memory on demand, said means for returning calling upon said means for re-translating to place such control chains into condition for execution so as to establish or modify the operating configuration of the process devices; and means for generating output signals to operate said devices as a function of the input signals as defined by the control chains as edited from time to time.
4. A system for controlling the operation of industrial process devices whose states are represented by device-generated signals and whose states may be altered under signal control, said system comprising: a process control digital computer system including a memory; signal conveyance means for coupling input signals from said devices to said digital computer system; means within said computer system for receiving said input signals and for maintaining within the memory a machine-readable record of the state of each of said input signals; means for entering within said computer system and for maintaining within the memory a representation of a human comprehensible name for each input signal along with the address of the corresponding signal record; means within said computer system for maintaining within the memory machine-readable control chains which are stored sequences of linked algorithm-defining data files, each defining how and when the state of one or more input signals are to be altered at least in accordance with the state of other signals, and each including variable linkages to the state-record of the one or more signals to which each control chain relates; means for establishing trigger linkages between selected input signal state records and selected control chains; means responsive to a change in the state of an input signal for executing the algorithms contained within the control chains linked to the state-record of that input signal; means for translating representations of the control chains into representations of algorithm statements understandable when displayed to a human, including means for replacing a variable linkage in such a statement with a representation of the name of the corresponding input signal, and also including means for locating trigger linkages to a control chain and separate means for adding to a control chain a representation of a list of the names of input signals to which the chain is trigger-linked; means for operating display means to display any control chain on demand, said means for displaying utilizing said means for translating to render a displayed control chain intelligible; means for operating on a displayed control chain to generate an edited control chain on demand; means for re-translating representations of displayed and edited or unedited control chains into a machine executable language and including means for replacing a representation of an input signal name with a linkage to the corresponding state-record and means for establishing trigger linkages to the chain in accordance with any list of triggering input signals that is part of the displayed chain; means for returning displayed and edited or unedited control chains to the memory on demand, said means for returning calling upon said means for re-translating to place such control chains into condition for execution so as to establish or modify the operating configuration of the process devices; and means for generating output signals to operate said devices as a function of the input signals as defined by the control chains as edited from time to time.
5. A system for controlling the operation of industrial process devices whose states are represented by device-generated signals and whose states may be altered under signal control, said system comprising: a process control digital computer system including a memory; signal conveyance means for coupling input signals from said devices to said digital computer system; means within said computer system for receiving said input signals and maintaining within the memory a machine-readable record of the state of each of said input signals; means within said computer system for maintaining within the memory machine-readable control chains which are stored sequences of linked algorithm-defining data files stored within the memory of said computer system, each defining how and when the state of one or more signals are to be altered at least in accordance with the state of other signals, and each including variable linkages to the state-records of the one or more signals to which each control chain relates; means for executing the control chain algorithms at predetermined times to generate computer output signals for the process devices; means for translating representations of the control chains into representations of algorithm statements understandable when displayed to a human and including means for replacing a variable linkage in such a statement with a representation of the name of the corresponding input signal; means for operating display means to display the stored representation of any control chain on demand, said means for displaying utilizing said means for translating to render a displayed control chain intelligible; means for operating on a displayed control chain to generate an edited control chain on demand; means for structuring a control chain with an indication that its execution is to be simulated on demand so that such chain can be checked out in a real-time environment before it is placed in an on line status; means for operating on specified input signals in accordance with selected control chains to simulate the execution of such control chains in real-time, and means for recording signal state adjustments called for by control chains under simulated execution; means for re-translating representations of a displayed and edited or unedited control chain into a machine executable language and including means for replacing a representation of an input signal name with a linkage to the corresponding state-record; means for returning displayed and edited or unedited control chains to the memory on demand, said means for returning calling upon said means for re-translating to place such control chains into condition for simulated or active control execution; means for preventing the execution of any control chain which contains a simulation indication from altering any internal or output signals; means for monitoring the operation of control chains containing a simulation indication including means for displaying the signal-alternation request of such control chains; means for removing a simulation indication from any control chain on demand; means for generating output signals to operate said devices as a function of the input signals as defined by the control chains as edited from time to time.
6. A system in accordance with claim 5 which includes means for operating on a displayed and edited or unedited control chain to enter in it on demand a representation of an algorithm defining data file that is marked for execution only during simulation execution, and wherein the means for executing includes means for bypassing the execution of data files marked for simulation execution except during simulated execution of a control chain, whereby initial conditions different from real-world initial conditions may be established for the simulated execution of control actions.
7. A system for controlling the operation of industrial process devices whose states are represented by device-generated signals and whose states may be altered under signal control, said system comprising: a process control digital computer system including a memory; signal conveyance means for coupling input signals from said devices to said digital computer system; means within said computer system for receiving said input signals and for maintaining within the memory a machine-readable record of the state of each of said input signals; means for entering within said computer system and for maintaining within the memory a representation of a human comprehensible name for each input signal along with the address of the corresponding input signal record; means within said computer system for maintaining within the memory machine-readable control chains which are stored sequences of linked algorithm-defining data files, each defining how and when the state of one or more input signals are to be altered at least in accordance with the state of other signals, and each including variable linkages to the state-record of the one or more signals to which each control chain relates; means for establishing trigger linkages between selected input signal state records and selected control chains; means responsive to a change in the state of an input signal for executing the algorithms contained within the control chains linked to the state-record of that input signal; means for translating representations of the control chains into representations of algorithm statements understandable when displayed to a human, including means for replacing a variable linkage in such a statement with a representation of the name of the corresponding input signal, and also including means for locating trigger linkages to a control chain and separate means for adding to a control chain a representation of a list of the names of input signals to which the chain is trigger-linked; means for operating display means to display any control chain on demand, said means for displaying utilizing said means for translating to render a displayed control chain intelligible; means for operating on a displayed control chain to generate an edited control chain on demand; means for structuring a control chain with an indication that its execution is to be simulated on demand so that such chain can be checked out in a real time environment before it is placed in an on line status; means for operating on specified input signals in accordance with selected control chains to simulate the execution of said control chains in real-time, and means for recording signal state adjustments called for by control chains under simulated execution; means for re-translating representations of a displayed and edited or unedited control chain into a machine executable language and including means for replacing a representation of an input signal name with a linkage to the corresponding state-record; means for establishing trigger-linkages to the chain in accordance with any list of triggering signals that is part of the displayed chain; means for returning displayed and edited or unedited control chains to the memory on demand, said means for returning calling upon said means for re-translating to place such control chains into condition for simulated or active control execution; means for preventing the execution of any control chain which contains a simulated indication from altering any internal or output signals; means for monitoring the operation of control-chains containing a simulation indication including means for displaying the signal-alteration requests of such control chains; means for removing a simulation indication from any control chain on demand; means for inserting into a displayed control chain on request an algorithm-defining data file that is marked for execution only during simulation execution; means within said algorithm executing means for bypassing the execution of data files as marked for execution only during simulation except during the simulated execution of a control chain; and means for generating output signals to operate said devices as a function of the input signals as defined by the control chains as edited from time to time.
Patent Citations (1)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US3588835 | 1971-06-01 | Enabnit |
Non-Patent Literature (1)
- Evans et al, "On-Line Debugging Techniques: A Survey", 1966 Fall Joint Computer Conference, vol. 29, pp. 37-50.