Follow-up of the meeting of 16th December 1992: MEETING OF 21ST DECEMBER 1992. E. Bracke *** --- *** Present: Philippe Baudrengien, Erik Bracke, Trevor Linnecar, John Molendijk, Frode Weierud. 1 Aim of the meeting. 1.1 To present A solution for "static" data transport from the graph database and "runtime" data from an operator to the process layer. 1.2 To agree A strategy for "static" and "operator" data transport towards the Executer. 1.3 To decide The interface formats for linkage path II and, if wanted so, path III. (See the drawing of note: M_161292.FW3) 2 Presentation layer database interfaces, operator entered info transport and static database information transport to Executer applications. 2.1 Introductory discussion. On some occasions data, managed by the presentation layer graph database, is also required by the process layer. We identify: - Node information. This information essentially describes an operator issued command to the RFS equipment (without its parameters and other data). - Target information. At the presentation layer this data is of enumerated type; an operator, wishing to issue a command to the RFS hardware can select here from the permitted value(s) that allow dressing a variable length parameterlist to the current command. - Leaf information. The static values are for the presentation layer: 1) the range bounds within which an operator is permitted to specify the value(s), 2) type of the data associated with the command he is going to issue to the RFS hardware. and: 3) the direction of dataflow. - The 1553b information. The values stored here, are not as such directly used by an operator communicating with the presentation layer while formulating a command for the RFS hardware. The reason for maintaining this data in the graph database is that, in the case of constructing commands for some of the RFS beam control equipment, it has a simple one to one mapping with the obtained target data. As stated in other notes, issued earlier, the entry point to the RFS equipment from over the SL control network, is the process layer. Everybody willing to commit himself to our communication protocol is allowed to construct a command for the RFS equipment. The Kernel process is the "receptionist" of commands to our equipment and therefore it must check the integrity of the command (as far as it has the power: access rights, existence of requested command etc.) and finally be capable of dispatching it to the various Executer processes involved. It uses node and (certain) target information, I believe, to this end. The close connection between the Kernel process and the presentation layer graph database is explained by this: the interface Kernel<->presentation layer is the graph database! Data values associated with a command (leaf data) are not of interest for the functionality of the Kernel process, therefore this data is merely transmitted to the Executer as such (copied into a structured buffer). Each Executer has provided the Kernel with a single reference per permitted command upon startup time. The Kernel, in runtime, having checked the integrity of a command, reduces all the node information as well as some of the target info (I believe) into such a reference. Also, because it needed target information, target data delivered to the Executer by the Kernel in the structured buffer, can be assumed to be coherent. (Isn't it, Frode?) For performing its functionality, the Executer does not need any of the graph database's information passed-on during runtime from the Kernel. The applications, run by the Executer, however, are responsible for doing the runtime check of data value(s) entered by an operator. On this occasion "bound check" values from the presentation layer (static leaf info) will have to be known them. One application running under the Executer will be responsible for the access towards the equipment layer (the ECA's). This application must evidently know of the (static) 1553b parameters. For the rest of the note it is assumed that the drawing of note: M_161292.FW3 is at hand. 2.2 Definition of interfaces path I and II. Path I: A simple list of Executer Object Database runtime names of every "operator permitted command" per Executer sent by the RFS Control Conceiver MMI to the Operator MMI could do the job. The proposed format is ASCII in a mailbox file with an agreed name ("eod_to_ocd.txt") like: /* File: eod_to_ocd.txt E. Bracke december 1992. * Transporting operator permitted commands from the * Executer Object Database to the Operator Command * Database (path I). * Creation MUTAD: 921220. EXE_NAME: N_CMND: RT_NAME: RT_NAME: ... ... ... ... RT_NAME: END_OF_LIST. */ Path II: The Operator MMI will sent back to the RFS Control Conceiver MMI an ultimately changed and extended list. The proposed format is ASCII in a mailbox file with an agreed name ("ocd_to_eod.txt") like: /* File: ocd_to_eod.txt E. Bracke December 1992. * Transporting operator permitted commands from the * Operator Command Database to the Executer Command * Database (path II). * Creation MUTAD: 921220. EXE_NAME: N_CMND: RT_NAME: U_PATH: < 1) > LEAF: < 2) > 1553: < 3) > RT_NAME: U_PATH: < 1) > LEAF: < 2) > 1553: < 3) > ... ... ... ... RT_NAME: U_PATH: < 1) > LEAF: < 2) > 1553: < 3) > END_OF_LIST. */ Notes: 1) Here is specified the attributed "unique path number" that identifies the command with runtime name rt_name for both Operator MMI and the Kernel. 2) Here is either specified the filename containing the static leaf data that needs to be transmitted to the Executer, or, an index in the Operator Command Database to the leaf record belonging to the command with runtime name rt_name. 3) Here is either specified the filename containing the static 1553b data that needs to be transmitted to the Executer, or, an index in the Operator Command Database to the 1553b record belonging to the command with runtime name rt_name. - The brackets "<>" are used here only to indicate a value retrieved from the resp. databases. - The RFS Control Conceiver MMI will default all non mentioned fields to "NIL" meaning NULL in the C programming language. The Operator MMI can make use of this property if desired in the case that no entry for this field of this particular command is available. - Minimum guaranteed coherence must be that the "number of transmitted commands" corresponds with the number of lines starting with a label "RT_NAME: ". Separation character between fieldlabels and values (values and fieldlabels) is "white space". Each line is terminated with "new line". The last phrase of the list must be "END_OF_LIST.". The last line in the file must contain only "*/". 2.3 Transporting static leaf information. Two possibilities can be identified: - The Operator MMI extracts per "operator permitted command" the static leaf information and puts it in an agreed format into a file (let's call it: "lf_upath.ora"). It then attaches the name of this file to the runtime name of the command concerned in the list it got from the RFS Control Conceiver MMI. The file is send to the computer where the application is to run (linkage path III); the RFS Control Conceiver MMI is informed of the file's existence by means of the returned list of operator permitted commands (linkage path II). The RFS Control Conceiver MMI, upon creation of the command description files (called: "rt_name.ora") will pass to the Executer per command the name of the leaf file. The Executer, upon startup, will create in memory the C structure representing the command (a cmnd_nt) and will attach to it the static leaf data extracted from the file: lf_upath.ora. - The Operator MMI provides the RFS Control Conceiver MMI with an index to the leaf record (situated in the operator command database) per "operator permitted command". To this end it attaches the leaf record index to the command concerned in the list it got from the RFS Control Conceiver MMI (via linkage path I). From the returned list of operator permitted commands (linkage path II) the RFS Control Conceiver MMI will extract per command via the index the required static leaf data while constructing the command description files (rt_name.ora). The Executer, upon startup, will create in memory the C structure representing the command (a cmnd_nt) and will attach to it the static leaf data extracted from the same file: rt_name.ora. This approach would eliminate linkage path III as far as concerned static leaf information. 2.4 Transporting static 1553b information. Also here, the same two possibilities can be identified: - The Operator MMI extracts per "elementary command" the 1553b information and puts it in an agreed format into a file (let's call it: "fb_upath.ora"). It then attaches the name of this file to the runtime name of the command concerned in the list it got from the RFS Control Conceiver MMI. The file is send to the computer where the application is to run (linkage path III); the RFS Control Conceiver MMI is informed of the file's existence by means of the returned list of operator permitted commands (linkage path II). The RFS Control Conceiver MMI, upon creation of the command description files (called: "rt_name.ora") will pass to the Executer per command the name of the 1553b file. The Executer, upon startup, will create in memory the C structure representing the command (a cmnd_nt) and will attach to it the static 1553b data extracted from the file: fb_upath.ora. - The Operator MMI provides the RFS Control Conceiver MMI with an index to the 1553b record (situated in the operator command database) per "elementary command". To this end it attaches the 1553b record index to the command concerned in the list it got from the RFS Control Conceiver MMI (via linkage path I). From the returned list of operator permitted commands (linkage path II) the RFS Control Conceiver MMI will extract per command via the index the required static 1553b data while constructing the command description files (rt_name.ora). The Executer, upon startup, will create in memory the C structure representing the command (a cmnd_nt) and will attach to it the static 1553b data extracted from the same file: rt_name.ora. This approach would eliminate linkage path III as far as concerned static 1553b information. Note that in these cases an "elementary command" MUST also be an "operator permitted command" which could be not desirable in some situations. 2.5 Transporting non-static target information and operator provided command data. Non static target information as well as operator data values are transported to the Executer applications, by means of agreed protocols, in the structured buffer. The agreed protocols are described in earlier notes. All this information is transmitted via Remote Procedure Call from workstations to the Kernel client process in the RFS PCA computer hardware. The Kernel transmits then to the Executer(s) concerned via path VI. (Dictionary of target identifiers, together with strings representing the target values for target info and arrays of double floating points, long integers or strings for operator data.) 2.6 Transporting "operator permitted commands" from Executer to Kernel (path VII). The Executer, while booting its runtime database of objects, constructs for its own internal use a "loaded objects" table. In this table it maintains for every COMPLEX class object a field containing the "unique path number" as retrieved from the commands' "rt_name.ora" file. During the initialization phase the executer will create a mailbox file with an agreed name ("exename_to_ker.txt") in the proposed format of ASCII: /* File: exename_to_ker.txt E. Bracke December 1992. * Transporting operator permitted commands from the * Operator Command Database to the Kernel (path VII). * Creation MUTAD: 921220. EXE_NAME: N_CMND: RT_NAME: U_PATH: < 1) > CMND_NTAB: < 2) > RT_NAME: U_PATH: < 1) > CMND_NTAB: < 2) > ... ... ... RT_NAME: U_PATH: < 1) > CMND_NTAB: < 2) > END_OF_LIST. */ Upon forking of the Executer process by the Kernel, the former will boot its runtime database of commands into memory. After table object boot the Executer will initialize its application software (running the INIT_EXE INIT class table) and, if successful, create the exename_to_ker.txt file. Then it will signal the Kernel that the initialization phase is over and that it is ready to receive an order for the execution of a command. The Kernel will use the exename_to_ker.txt file to create in its memory space a lookup table per Executer relating the "unique path" number of a command to the COMPLEX class object address representing this Operator MMI command in the Executer's address space. Notes: 1) Here is specified the Operator MMI attributed "unique path number" that identifies the command with runtime name rt_name for both Operator MMI and the Kernel. 2) Here is specified the address in the Executer's address space (Runtime database) where the command with runtime name rt_name is located. - The brackets "<>" are used here only to indicate a value retrieved from the Executer's loaded objects table. - The Kernel may decide to use or not the runtime name string. In the file it is only meant as provision of "user friendly" interface. In runtime, the only thing transmitted from Kernel to Executer will be the address reference of the command (i.e. the value behind the CMND_NT: field). - Minimum guaranteed consists of "number of transmitted commands" corresponding with the number of lines starting with a label "RT_NAME: ". Separation character between fieldlabels and values (values and fieldlabels) is "white space". Each line is terminated with "new line". The last phrase of the list will be "END_OF_LIST.". The last line in the file only contains "*/". 3 How does it all fit together with the static data transport? The description is from here on especially tailored to the needs of the 200MHz Travelling Wave system. The idea could however be taken-up for other applications as well. I do not pretend to give here for everybody (inclusive myself) the "solution" for-now-and-in-eternity. During initialization time, a special Executer global area initialization programme initializes the global area, an Executer facility to the application programmes. As a function of the Executer name, it translates from a private database file the 1553b family strings for the global area variables TX_FAM[ 0 ], TX_FAM[ 1 ] (symbolic transmitter names), TB_FAM (symbolic tube/klystron name) and DC_FAM (symbolic directional coupler name). In the Executer global area we also find variables that, in runtime, specify symbolically which equipment is involved in the current command and also what action is required. In runtime, the target value interpreter (another special Executer application programme) will initialize the equipment specifiers as a function of the target values it found in the structured buffer that got in from the Kernel. The application programmes in the sequence will take care verifying the data they find in the structured buffer and of the construction of ACTION specifier and USEROPTION specifier. This all according to the algorithm that is theirs and with the help of static leaf data available from the cmnd_nt. The latter was initialized at startup time with static leaf data retrieved via/from the rt_name.ora file by the Executer. The commands, that eventually will do the 1553b access have a fieldbus structure attached to them (partially initialized with 1553b static data retrieved via/from the rt_name.ora file by the Executer at startup time) that will now be further setup from the global area FAMily, ACTION and USEROPTION variables as a function of the (also global area resident) symbolic equipment specifiers. 4 What has been obtained from the discussion? 4.1 Deciding interface file formats. 4.1.1 Path I: It is understood that commands, represented by the runtime name in the Executer Object Database, have to be "manually" connected to "paths through the graph". The proposed file format opens the possibility of writing a database application programme that will help assuring all "paths through the graph" are attributed a to a command of the Executer Object Database (runtime name). At the same time this application could start building the required return file for path II. 4.1.2 Path II: As the Operator MMI already prepares a file, containing the links: "paths through the graph" (identified by their runtime name) to "unique path numbers" for the Kernel, it has become obsolete to pass this information to the RFS Control Conceiver MMI. It has therefore been decided to remove the label and field "U_PATH: " from the path II file. It has been found more useful to leave path III in existence for the transmission of graph static leaf information in a file for use by the Executer during startup time. This is the first presented option on that matter from this note. So: to the "LEAF: " label will be attached the name of a created file with static leaf information for the Executer during startup time. The same leaf file can be attached to many commands (rt_names) in their respective "LEAF: " fields. Also for the transmission of graph 1553b fields the feeling was that path III should remain in place. The label "1553: " will thus indicate per command (rt_name) the name of a file created by the Operator MMI. This represents, however, not exactly the first option presented in this note on the matter, in which there was only spoken of "1553 static data". 4.1.3 Path III: It has been decided that the Operator MMI will generate files containing information from the graph database for use by the Executer during startup time. Neither discussion nor decision about the file format or contents has been undertaken. 4.2 Other related things. A discussion was started on the use of the 1553 fields in the Operator Database. The issue is: "what will the file with extracted 1553 fields from the Operator Database contain?" Two uses are currently distinguished: - No obligatory relation exists on the level of the Operator Database between the value in a 1553 field and a target of the current node of the graph. A target (or range of targets) is simply considered as a parametric value for a command. Those 1553 field values that will remain constant ("static") during a given command are administrated by the Operator Database and could be mentioned in the file for the initialization by the Executer of the 1553b structure at startup time. It is in runtime that the algorithm of the application programme decides that targets could (or not) be used for mapping to 1553 field values. The lookup table for doing such a mapping belongs, in the case of the travelling wave system, to the global area initializer which defines the TX_FAM[n] array; it is part of the initializer's algorithm (also private database), the contents of the array is administrated in the Executer Object Database. The RFS Control Conceiver MMI will extract the values from the database and put them into a file, known and read by the initializer programme at initialization time (i.e. the phase after startup time). - There exists a direct mapping between targets and 1553 fields of a node in the Operator Database. This is the case for the 200MHz standing wave system. In this case the created file contains range of values for one given 1553 field, as a function of a range of target values. These are somewhat different views on the use of these 1553 fields. They are however, both compatible with the design of the Operator Database. The views, in fact, only reflect the way of implementation of a given application; a way of using the facilities offered by the Operator Database. As long as the extraction application in the Operator MMI organizes its work (the extraction of the data in the target fields and storage in a file) according to the defined interface protocol mentioned in this note, I think there is no problem. Indeed, I would even suggest to "parameterize" the extraction algorithm, i.e. a parameter (e.g. one of the possible target fields) determines the organization of the extraction. In this note, the parameter would then be the Executer name field (mind you, NOT its contents!). Furthermore it should be kept in mind, that the use of a set of files is restricted on a "per system" base. Interpreter routines can be easily conceived to cater for different views, if these views are also "per system". In fact, the interpreter routine is just another application programme and it is not the Executer that imposes any interpretation of targets; targets make part of the conception of a particular application. So if need arrives there is always the possibility of making "special" versions of the target interpreter, tailored to a particular use of targets by a system or even by an application. I recognize that in path I, I didn't mention a second field containing the Executer name where the current command is situated. Of course the configuration of commands in an Executer will have to be defined in a "per Executer" defined file. In the Operator Database a field "Executer Name" exists (definable per target value). Coherence must exist between Operator Database and Executer Object Database on this issue, so I propose to add a field "EXEC_N: " for each instance of "RT_NAME: " in the mailbox file of path I. If a command is used in several Executers (a command makes "sense" only in a given Executer; driving existing hardware!), as many lines "RT_NAME: " will exist as the number of Executers that use this command. This will allow checking by the Operator MMI of coherence across the Executer name definitions. Another possibility is that the Operator MMI does the expansion (by means of adding the "EXEC_N: " label + definition) "as many defined command lines as there are uses of this command per Executer" in the return mailbox file via path II. That means that the Control Conceiver MMI will add these instances in its database in an automated way and the control conceiver does NOT have influence where he wants to place (which Executer) an application (does this really make "sense"?!?).