MINUTES OF A MEETING CALLED BY ERIK ON 16 DECEMBER 1992. E. Bracke *** --- *** Present: Philippe Baudrengien, Erik Bracke, Trevor Linnecar, John Molendijk, Frode Weierud. 1 Aim of the meeting. 1.1 To check If my understanding of what we are conceiving is still up to date (and, if that still agrees with the understanding of the other members of the team). 1.2 To show That what I think "the solution", is fully compatible with the other components of the system. 1.3 To decide What data management will be done where. 1.4 To agree Interface protocols between different functional blocks. 2 Diagram. Please stick here the drawing I gave you yesterday. 3 Linkages on the Diagram. 3.1 Labelled I. - References of "operator permitted commands" (Complex class table objects) are handed over to the Operator Command Database. - By means of the operator MMI the "operator permitted commands" can be combined into "abstract operator functional" commands, creating thus sequences. - In its simplest form, such an "abstract functional command" is the same thing as a single "operator permitted command". 3.2 Labelled II. - The Operator MMI labels all handed over "operator permitted commands" with its "unique" path-through-the-graph number and sends them, together with the number times each "operator permitted command" has been used while constructing "abstract operator functional commands" (a linkcount). In this message is also included the number of "abstract functional commands" that has been created by the Operator MMI. - The Executer Object Database fills in the "unique" path numbers into a reserved field of all of the marked "operator permitted commands". 3.3 Labelled III. - The Operator MMI generates a configuration file for each of the "abstract operator functional commands" (i.e. a Complex class table object) that it has created. This is a ".ora" file. 3.4 Labelled IV. - The RFS Control Conceiver MMI generates a configuration file (".ora" file) for each of the table type objects (Init class, Abort class, Survey class, Complex class) it manages. In the Complex class tables we find both "operator permitted commands" and "operator non permitted commands". - It also generates the other required files: - for initialization of routine objects (per object an ".ora" file). - for inclusion during compile time of the Executer C code (several ".h" files). - a ".ora" configuration file for the "sequence of all sequences" (booting the Executer Runtime Database). - a ".ora" configuration file for the "sequence of all initialization routines". 3.5 Labelled V. - At startup time, the Executer uses the RFS Control Conceiver MMI generated files (".ora") for the construction of the Runtime Database (Executer database, the one that contains the linked sequences of commands known to the Executer). - It then executes the now just created "sequence of all initialization routines" for the initialization of all Executer application- and auxiliary routine objects. During this sequence, all routines that require so, can e.g. create their own private RAM database. 3.6 Labelled VI. - The "agreed protocol" between Kernel process and the Executer process consists of the "Executer interface" structure from the pipe between them together with a structured shared memory buffer containing data for the current command. This data (from the graph: target values, data from the leaf) has been gathered by the Operator MMI from an operator wishing to issue a command. 3.7 Labelled VII. - The Executer, after its initialization phase, hands over to the Kernel a list of all "operator permitted commands" (identified by their "unique path" numbers) together with their addresses in the Executer's (Runtime Database) address space. 4 Questions and answers. 4.1 Why 2 MMI's, each associated with its own database? The essence of controlling (using) the RFS hardware is quite different from the one of conceiving a hardware control system of programmes and permitted sequences. The former must be conceived while keeping in mind the way our clients see and will use our hardware. These users could be relatively unfamiliar with the intricacies of our equipment; therefore "abstract operator functionality". The latter must be conceived with the Executer's needs in mind. Its task is to ease the maintenance of a large software system through automatical generation of required files and the assurance of coherence between the various objects. Therefore the tool of a database manager (the MMI, by virtue of its dB application programmes) is likely to be differently formulated (programmed) in either case. The creation of the database manager (the 2 MMI's) will profit if they were decoupled from each other. The only coupling necessary being the "agreed protocol" I and II. 4.2 What do we gain further by having 2 dB Managers? - The formulation of the "requirement charts" of each database and their associated MMI is easier to do if tailored to each of the 2 aforementioned needs. Programming (the construction of an MMI) will therefore be more straightforward, easier to maintain. - The security for the controlled hardware will be much improved: one either logs-in as an operator (and can then do only "operator permitted commands") or, in a different environment, as a control conceiver (and can then do only "control conception".) This is a positive choice which one has to make. - Furthermore, it is the control system conceiver that can decide which commands will be at the end known to the Operator MMI (and the Kernel). Her lies a possibility of choice at the disposal of the Operator MMI, whether implementation or not is required. No attribution of a "unique path" number automatically means that, although the control system conceiver decided it as "operator permitted", the Kernel will not know the command. The Executer would still be capable of executing it when such a command were included within other sequences (decoupled systems!). - Not known commands at the Kernel level can not be executed. The Kernel is the entry point from the control network to our hardware and therefore vulnerable. If all control of our hardware passes through our Operator MMI, consistency with what is allowed and what is not, would be guaranteed by us. We allow, however, that everybody willing to agree with our communication protocol, is allowed to write its own MMI and hence become out of control to us. Remember that this control system controls, amongst others, 2Mwatt of RF power with equipment worth several million Sfr. 4.3 Is there a price to pay? Seriously, is there one except from the work to be done? 5 Notes. - Suppose the Operator MMI not only sends back to the Executer Object Database the labelled "operator permitted commands" but also (conforming the agreed protocol) its own created "abstract operator functional commands". We could then omit path III for these sequences and have the RFS Control Conceiver MMI create all the files required for the Executer. This can be done under the condition that all object relative data is administrated by the Executer Object Database. Currently this is not the case (family, member, action... and: static data from the leaf: boundcheck ranges...), so path III will be necessary. - The only link between the Operator Command Database and the Executer Object Database, that must be made by hand is the determination which Complex class table object is an "operator permitted commands" and which is not. This is, in fact, link I. 6 What has been obtained from the discussion. 6.1 About my understanding. From the discussion I got the impression that my understanding of the whole system, necessary for designing the Executer, is still adequate. 6.2 About the presented "solution". We have not uncovered, so far, any incompatibilities with the other components. The idea of coupling the Operator Command Database and Executer Object Database through "agreed protocols" (as opposed to "total integration") shown on the diagram is accepted. 6.3 Operator abstract functionality. After discussion it has been decided to give up the possibility of creating "sequences of paths through the graph". This means that only "operator permitted commands" send by the Executer Object Database will be implemented as "single path through the graph" and thus all sequences necessary to control RFS hardware, be constructed under the RFS Control Conceiver MMI. 6.4 Data management. The idea of 2 databases with 2 MMI's is accepted. Of course is this only a matter of thought: all data is in the same ORACLE database; there will exist only 2 sets of database application programmes (the MMI's). The coupling of the databases is done via "agreed protocols" between sets of 2 dB application programmes, each application programme being a part of the respective MMI. 6.5 Other related things. Discussion how to map graph Target info into equipment identification (family, useroption etc.). Erik thinks there is no problem, he promised to look into it (for Monday, in principle).