Run-time dynamically adaptive computer process for facilitating communication between computer programs5619685Abstract The present invention provides a dynamic interface between two dissimilar software programs that must communicate with each, whether running on one or a plurality of computers. The invention can provide bi-directional, non-intrusive data manipulation and communications between software programs on a distributed computing platform or across platforms on a distributed network. The invention includes user-defined template files, a user-defined equality file, first and second blocks of shared memory, a master interface, and a slave interface. The template files define the output and input data of their respective programs and map the output and input data to blocks of memory. The equality file equates the input data and output data of one program with the output data and input data, respectively, of the other computer program. The master interface takes data from the master side block of memory, reconfigures the data based on the contents of the equality file to match the input data requirements of the second computer program, and sends the reconfigured data to the slave interface to be loaded into the slave side block of shared memory. The second computer program accesses the reconfigured data from the slave side of shared memory. Claims I claim: Description The present invention relates to digital computers and computer programs, and particularly to interfaces for communicating data between computer programs. More particularly, the invention relates to run-time dynamically adaptive computer processes that automatically configure themselves to facilitate communications between dissimilar software programs, which may be run on the same computer, or on two remotely located computers through a communication link.
______________________________________
begin short host
end for path
record int control is CONFIGURATION
float semkey SECTION
long INTERFACE FILE
memory eof INPUT
char equality OUTPUT
______________________________________
Punctuation: the following is a list of punctuation used in statements : ; = [ ] { } Type: valid type declarations are int short int long int float long float char 1. Declaration Statements: declaration statements take the form: <Identifier>:<type>; A Declaration List is one or more declaration statements. Examples of valid declaration statements are: time:float; name:char[128]; terminate:int; 2. Record Definition Compound Statements: record definition statements take the form record<Identifier> begin Declaration List end An example of a valid record statement is: record record5 begin rectype:int; numflds:int; playid:int; iconid:int; label:char[20]; end In the current syntax, it is illegal to define a record and then use that record as a type in a declaration statement. In order to simulate such nesting, use the "dot" notation to indicate sub-fields of an identifier. A C declaration sequence of
______________________________________
typedef struct foo {
int a;
float b;
}FOO;
struct bar {
FOO q;
}
______________________________________
can be represented in the current syntax as record bar begin q.a: int; q.b: float; end Since memory is linear anyway, this reduces all records to their "linear" representation and more accurately defines the relative location of the fields of the record in memory. 3. Key Declaration Statement: a key declaration statement takes the form semkey=<number>; The number passed as the semkey must be the same as the number the connecting application uses for a key when it creates shared memory and semaphores. An example of a valid semkey statement is: semkey=2314; 4. Memory Declaration Statement: a memory declaration statement takes the form memory<Identifier>[<number>]; The <Identifier> must be a previously defined record or declaration Identifier. <Number> gives the number of slots in memory of this record type that exist. The order of these statements defines the order of the blocks of records in memory to the interface so it is very important that the order of the statements exactly match the actual order of the record blocks. Additionally, the stated size of the record block must match the number actually used in memory by the application for the interface to match the input data to the output requirements correctly. The interface supports a control field so that an application can communicate with the interface and send control signals. In order to signify the location and significance of this special record to the interface, the keyword INTERFACE has been defined. Simply insert the declaration "memory Interface;" in the correct order location in the input file to designate the location of the control record. The control record is defined as a single integer and the only command currently implemented is "-1", signifying terminate. An example of a valid memory statement is: memory record5[200]; 5. Control Declaration Statement: the control declaration statement takes the form control for<Identifier1> is <Identifier2>; where both Identifiers have been previously defined by declaration or record statements. <Identifier1> should be a record that has memory block in which all slots may not need to be passed in every time slice. <Identifier2> will give the number of records that should be passed for the time slice. <Identifier2> will be checked and only the number of records of type <Identifier1> specified by the value of <Identifier2> will pass for the time slice. This allows a convenient mechanism for passing a variable number or records while declaring a large enough memory block to handle all possible data situations. <Identifier2> can only represent an integer with a block size of 1. An example of a control declaration statement is control for record5 is r5info; 6. End of File Marker: an end of file marker must be placed as the last statement in the file. It is the keyword "eof" and must also have at least 1 carriage return/line feed after it. The end of file delimiter is necessary to properly separate the analysis of the input files. 7. Section Definition Statement: a section definition statement takes the form SECTION: <Type> The <Type> is one of input, output or configuration as appropriate. 8. Host Statement: a host statement takes the form Host <name>; The <name> is the name of the host computer for the template file's respective program. 9. Path Statement: a path statement takes the form path <pathname>; The <pathname> is the pathname to where the interface is installed on the host computer. The output data structures for the simulation model 12 should be the same as the normal data structures that are used during its execution. There is no need to change any existing data structure to fit the visualization tool format since the interface 10 will do this automatically during run time. There is a need, however, to ensure that all of the individual data input requirements of the visualization tool 14 are met by some part of the output of the simulation model 12. Data structures in the simulation model 12 must be found which contain the appropriate information for every field of every record defined by the visualization tool template file 18. This is accomplished in an equality file 20 as illustratively shown in FIG. 8. The equality file 20 maps a model output record field of the simulation model 12 to a model input record field of the visualization tool 14. The equality file 20 allows the interface 10 to map spots from the first block of memory 22 to matching spots in the second block of memory 24. This mapping is what provides run-time reconfiguration. That is, the mapping allows the interface to pick apart records on the master side of the interface and output them in the correct format on the slave side. The equality definition file has the following form equality <Identifier1>=<Identifier2>; (more equality statements as necessary) eof The file must have as its first statement the keyword "equality" followed by any number of equality statements and terminated by the "eof" file delimiter keyword. The equality statement has two identifiers. <Identifier1> is a field of a record or declaration in the visualization tool's configuration file and <Identifier2> is a record field or identifier in the simulation model configuration input file. These equality statements show the mapping between output data of the simulation model 12 on the master side and the input data of the visualization tool 14 on the slave side. Note that all of the visualizations tool's input requirements must be met by some field or record of the simulation model's output. As currently implemented, there is no null statement for the simulation model's output, but the model can "fudge" a null by declaring a field in the memory with a zero value and directing a non-essential visualization tool input record to that field. FIG. 8 can be used as an example of a proper equality file. A potential problem to consider occurs when the visualization tool input record references two or more simulation model output records. The block size for each simulation model output record should be equal. Otherwise, the master attempts to access past a simulation model output block's memory limits. In general, it is prudent to use the same block sizes for simulation model output records and their corresponding visualization input records. It is possible to make a visualization tool input record that has a block size greater than "1" reference, a model output record with a block size of "1". The interface will repeatedly write the same model output information to multiple visualization tool input spots if and only if the output block size is found to be "1". This feature can be useful for model output information that is the same for many visualization tool input records, such as the time stamp. FIGS. 2, 3a and 3d illustrate master interface 26 in greater detail. Referring to FIG. 2, the template files 16, 18 are fed into a lexical analyzer 34 which converts the template file information into an internal form usable by a memory mapper 36 (FIG. 3b), which in turn loads the information into main memory mapping tables 46. A control/communicator 38 takes the simulation model data and reconfigures that data, using the information in the main memory mapping tables 46, to match the requirements of the visualization tool 14. The reconfigured data is written into the second slave side block of memory 24. The visualization tool 14 reads the reconfigured data and updates the display. The flow of information in master interface 26 from the template files 16, 18 and the equality file 20 to the main memory mapping tables 46 is shown in more detail in FIGS. 3a-3b. The lexical analyzer 34 determines the correctness of the template file statements, extracts information from the statements, converts the information into a format usable by the interface 10, and stores that information in information tables 40, 42, 44. Once the data is input to the information tables, the memory mapper 36 analyzes the information and creates the main memory mapping tables 46. Referring to FIG. 3a, the information from the template files 16, 18 and the equality file 20 is input to a tokenizer 50 as a stream of characters. The tokenizer 50 breaks up the stream of characters into groups, or tokens, according to rules defined in the analyzer 34. The tokens are organized into statements which comprise the smallest piece of meaningful information and include keywords, punctuation and identifiers. The lexical analyzer 34 uses a four step process to analyze the tokens. In the first step, the analyzer 34 looks at the first token in a statement, which tells the lexical analyzer what type statements follow. Since each statement type requires different operations to be performed on the information retrieved, a separate section was created for each statement type. Accordingly, the second step of the analysis involves calling up an appropriate sub-analysis, based on the contents of the first token. The third step in the analysis involves examining the remainder of the statement using syntax rules for that statement type. Data such as type, identifier and size are extracted from the statement and held until the end of the statement is reached. If a syntax error is found, the whole analysis stops, and error message is printed and the interface terminates. If the end of the statement is reached without an error, the data is transferred to the information tables 40, 42, 44, as shown in FIG. 3a. The lexical analyzer also creates a detailed record information table (DRIT) 56. Once all of the declaration information has been extracted from the template and equality files 16, 18 and 20, respectively, the interface analyzes the DRIT and creates main memory mapping tables 46, as shown in FIG. 3b. As shown in FIG. 4, there are three main memory mapping tables for each of the master and slave configuration files which include a control table (CONTAB), a slave memory allocation table 58, a memory block allocation table (MBAT) 50, and the DRIT 56. The MBAT 50 provides detailed information on the layout of the memory 22, 24 and the CONTAB 52 associates a control record with a memory block. The DRIT 56 contains information on the type, size and some location information for every field of every record. The lexical analyzer creates a DRIT 56 for both the master and slave side of the interface, and each DRIT is placed with the corresponding side's information tables. Once the information is extracted from the template and equality files 16, 18, 20, the DRITs are analyzed. The analysis of the DRITs and the creation of the main memory mapping tables 46 are shown diagrammatically in FIG. 3b and includes matching the equality information to the master and slave information contained in the respective DRITs. Each declared equivalent pair is checked for byte size compatibility and type compatibility. If the size and types match, both the master and slave information is put into a detailed record and equality information table (DREIT) 56. If the types don't match, as for example when the input requires an integer data type and the corresponding output is a floating point data type, the memory mapper 36 converts the data as appropriate and stores the converted data type in the DREIT 56. The master MBAT 50, slave MBAT 58, and the CONTAB 52 cooperate with the DREIT 56 to let the master interface 26 know the read and write memory positions of the equivalent records. The main memory mapping tables 46 provide all of the information necessary for the master interface control and communicator 38 to pass the exact information required by the slave interface 28 (FIG. 4) in the order and type required. Portions of the main mapping tables 46 are sent to the slave interface 28 so that the location for the received information can be determined. Proceeding with the master interface initialization, after completing the lexical analysis and information analysis processes, the master interface control and communicator 38 passes a modified version of the slave MBAT 58 and slave DRIT to the slave interface 28, as shown diagrammatically in FIGS. 4-5. FIG. 5 illustrates slave side memory 24 as part of slave interface 28). Slave interface 28 has an expanded memory block allocation table (XMBAT) 62; which is an expanded version of the slave memory allocation table 58 that exists on the master interface side of the interface. The XMBAT 62 contains the record type and memory address of every individual record located in the slave side memory 24 and provides quick access to the record type and position in the slave side memory 24 by assigning a simple number identifier to each position. The modified slave DRIT contains the data type for each field of a record and is called the field information table (FIT) 64. The FIT 64 is accessed by the same record identifiers used by the XMBAT 62, thus letting the slave interface 28 know the structure of the record referenced by the XMBAT. Once the main mapping tables 46 are created on the master interface 26 and the slave tables have been created and passed, the master interface control and communicator 38 is ready to pass information from the simulation model 12 to the visualization tool 14. The master interface control and communicator 38 on the master interface 26 is responsible for passing only the required information to the slave interface 28 in the correct order and quantity required. The master interface control and communicator 38 uses the main memory mapping tables 46 to obtain the read and write locations for each piece of data, and uses a three step precess to pass each record block of information to the slave interface 28, as shown diagrammatically in FIG. 4. First, the master interface control and communicator 38 accesses the CONTAB 52 to determine if a control record exists for the record block. If so, the number located in that record will determine the number of records to be passed to the slave interface 28. Otherwise, the entire record block will be passed. Second, the master interface control and communicator 38 finds the slave record number and record location from the slave MBAT 58. Finally, for each field of the record type to be passed, the master interface control and communicator 38 (1) finds the equivalent master side record field information from the DRIT 56, (2) finds the location in the master side shared memory 22 of the record field by accessing the master MBAT 50, and (3) sends the record field. Coordination between the master interface 26 and slave interface 28 is achieved by having the master interface control and communicator 38 send control signals to tell the receiver 66 of the slave interface 28 what information to expect next. The information following the control signal tells the slave control 68 the position to access in the XMBAT 62 and FIT 64 tables. Thus, the control signals allow the slave interface 28 to correctly interpret all information passed by the master interface control and communicator 38 and place the information in the correct position in the slave side memory block 24 using a three step process, shown diagrammatically in FIG. 5. First, the slave interface 28 receives a control signal from the slave receiver/sender 66 indicating that a record is to be received. Second, it receives a number which is the position of the record in shared memory. The slave control 68 uses this number to know the type of the record and, therefore, the structure of the record by accessing the XMBAT 62 and FIT 64. Third, the slave control 68 receives the record information as defined by the FIT 64 and writes the information to slave side memory 24. Once all of the record blocks have been passed across the interface 10 and placed into the visualization tool's slave side memory 24, the slave control 68 releases control of slave side memory 24 so the visualization tool 14 can display the information. When control of slave side memory 24 is released back to the slave control 68, it is ready to receive the next set of record blocks from the master control and communicator 38. The process continues until the termination of the simulation scenario. In order to control the flow of communications across the memory blocks 22, 24, the interface uses a scheme of semaphores, which are the means by which the synchronization of reads and writes from and to memory block is 22, 24 are coordinated between the first computer program 12 and the master interface 26 and between the second computer program 14 and the slave interface 28. For example, the semaphore scheme allows the simulation model 12 to write a time slice to master side memory 22 while simultaneously preventing the master interface 26 from reading the information until the simulation model 12 is done writing. Conversely, once the master interface 26 begins to read a time slice, the simulation model 12 will be prevented from writing the next time slice to the master side memory 22 until the master interface 26 is done reading. The correct use of the semaphores ensures that only one portion (i.e., master side or slave side) side of the memory will have access to memory and therefore ensures that all the data for one time slice remains as a complete package. Illustratively, two semaphores, called READSEM and WRITSEM, guard the memory blocks 22, 24 for mutual exclusion between the simulation model 12 and the master interface 26 and between the visualization tool 14 and the slave interface 28. Separate, but identical, READSEM and WRITSEM semaphores are implemented as flags on the master and slave side of the interface 10. Both sets of READSEM and WRITSEM flags have allowed values of 1 or 0. In order to use the flags, two procedures named Give.sub.-- Sem and Get.sub.-- Sem have been implemented. A call to Get.sub.-- Sem decrements the READSEM or WRITSEM flag value from 1 to 0. If a call to Get.sub.-- Sem finds a flag value of 0, the issuer of the call waits for the flag value to change to 1. If the call to Get.sub.-- Sem finds that the flag value is 1, the flag is decremented from 1 to 0 and the call issuer reads or writes, as appropriate. A call to Give.sub.-- Sem increments a flag value of 0 to 1. If properly implemented, the call to Give.sub.-- Sem always sees a 0, which it increments to 1, allowing the other side of the shared memory to read or write, as appropriate. The calls to Give.sub.-- Sem and Get.sub.-- Sem must be placed at the correct location in the applications on both the master and slave sides of the memory for the synchronization of the reads and writes to function properly. The event timings for both initialization and steady state are critical for the proper operation of the computer program/memory/interface combinations. An illustrative initialization and steady state event timing table is shown in FIGS. 9a-9b. The operator starts the simulation model 12, which proceeds through the initialization events of initializing IPCs and calculating the first time slice (events 2-3). The simulation model 12 writes the first time slice to master side memory 22 (event 4), issues a call to Give.sub.-- Sem READSEM (event 5), calculates the next time slice (event 6) and issues a call to Get.sub.-- Sem WRITSEM (event 7). Of course, at this time the WRITSEM flag value is 0, so that the simulation model 12 waits until the Get.sub.-- Sem WRITSEM sees a flag value of 1. After the simulation model 12 has started, the operator starts the master interface 26, which in turn automatically starts the slave interface 28 (event 8). During startup and initialization of the interface 10, both sets of READSEM and WRITSEM flags are set to 0. By this time, however, the Give.sub.-- Sem READSEM is ready to, and does, increment the READSEM flag to 1, based on the call to Give.sub.-- Sem READSEM in event 5. The master interface 26 proceeds to analyze the configuration files, initialize the IPCs and pass the configuration information to the slave interface 28 (events 9-11). The master interface 26 then issues a call to Get.sub.-- Sem READSEM and checks the value of the READSEM flag (event 12). Since the READSEM flag value was just incremented to 1 by the call to Give.sub.-- Sem READSEM, the master interface 26 reads the first time slice from the master side memory 22, decrements the READSEM flag value to 0, and passes the first time slice to the slave interface 28 (event 13). At this point, the master interface 26 pauses to wait for the go ahead signal from the slave interface 28 (event 14), and both READSEM and WRITSEM flags are set to 0. After start up in event 8, the slave interface 28 receives the configuration information, initializes the IPCs, and receives the first time slice and writes it to slave side memory 24 (events 11-13). The slave interface 28 then issues a call to Give.sub.-- Sem READSEM (event 14), which automatically increments the flag value to 1, and waits for the visualization tool 14 to come on line and accept the first time slice. After starting the simulation model 12 and the interface 10, the operator starts the visualization tool 14 (event 9). The visualization tool 14 initializes the IPCs and issues a call to Get.sub.-- Sem READSEM (event 11). Since the slave interface 28 previously incremented the READSEM flag value to 1 in event 14, the call to Get.sub.-- Sem decrements the READSEM flag value to 0. The visualization tool 14 reads the first time slice from slave side memory 24 (event 15), issues a call to Give.sub.-- Sem WRITSEM, which increments the WRITSEM flag value to 1 (event 16), and issues a call to Get.sub.-- Sem READSEM. Since the READSEM flag is 0, the visualization tool 14 waits for a READSEM flag value of 1. At this point, the simulation model/interface/visualization tool system is ready to go into steady state operation. The visualization tool 14 sends a go ahead signal to the slave interface 28, and the slave interface 28 receives the go ahead signal and passes it on to the master interface 26 (event 18) and issues a call to Get.sub.-- Sem WRITSEM (event 19), which decrements the WRITSEM flag value to 0. At this point, the slave is ready to receive the next time slice from the master interface 26 and write it to slave side memory 24. As with the master side of the interface, all READSEM and WRITSEM flag values are set to 0. Upon receipt of the go ahead signal from the slave interface 28, the master interface issues a call to Give.sub.-- Sem WRITSEM (event 19), which increments the WRITSEM flag to 1, enters steady state operation, and issues a call to Get.sub.-- Sem READSEM (event 22). However, the READSEM flag is 0 at this time, so that the master interface 26 waits for the READSEM flag to go to 1. The simulation model 12 has been waiting (since event 7) for the WRITSEM flag value to be 1. Thus, as soon as the master interface 26 issues the call to Give.sub.-- Sem WRITSEM, the simulation model 12 writes the second time slice (previously calculated in event 6) to master side memory 22 (event 21) 21, decrements the WRITSEM flag to 0, issues a call to Give.sub.-- Sem READSEM (event 22), incrementing the READSEM flag value to 1, calculates the next (third) time slice (event 23) and issues a call to Get.sub.-- Sem WRITSEM. The call to Get.sub.-- Sem READSEM from the master interface 26, issued in event 22, decrements the READSEM flag to 0, and the master interface 26 reads the second time slice from master side memory 22 and passes the time slice to the slave interface 28 (events 22-23). The slave interface 28 receives the second time slice, writes it to slave side memory 24 and issues a call to Give.sub.-- Sem READSEM, which increments the READSEM flag to 1. The visualization tool 14 has been waiting for a READSEM flag value of 1 since event 24. Consequently, the Get.sub.-- Sem READSEM decrements the READSEM flag to 0 and the visualization tool 14 reads the second time slice from the master side memory 24 and issues a call to Give.sub.-- Sem WRITSEM, incrementing the WRITSEM flag to 1. At this point, the simulation model/interface/visualization tool system has transitioned into steady state operation. During steady state operation, the master interface 26 and the simulation model 12 continue to write to and read from master side memory 22 under the control of the WRITSEM and READSEM semaphores, as previously described. Likewise, the slave interface 28 and the visualization tool 14 continue to write to and read from slave side memory 24, also under control of the semaphores. Data passes from the master interface 26 to the slave interface 28 when the master interface 26 has completed reading the (current) time slice from shared master side 22 and the slave interface 28 has issued the call to Get.sub.-- Sem WRITSEM and is ready to receive the data from the master interface 26. Although the invention has been described in detail with reference to a simulation model and visualization tool, it will be appreciated that the interface of the present invention is equally applicable to other combinations of programs. It will be further appreciated that the interface of the invention is not limited to use with just two computer programs, but can interconnect a plurality of computer programs that are operating on any number of computers, including multiple programs operating simultaneously on the same computer. Moreover, it will be apparent to one of ordinary skill in the art that the data can also flow both ways across the interface 10. Thus, the invention is not limited to the uni-directional data flow described for the simulation model/visualization tool combination discussed above. Although the invention has been described in detail with reference to a certain preferred embodiment, variations and modifications exist within the scope and spirit of the invention as described and defined in the following claims.
|
Same subclass Same class Consider this |
||||||||||