AN OVERVIEW OF THE RF PCA EXECUTER. together with: REQUIREMENTS AND MANAGEMENT OF THE OPERATIONAL DATABASE FOR THE RF PCA EXECUTER. E. Bracke SL/RF-bc ---***--- 1 Overview of Executer constituent parts. . . . . . . . . . 1 1.1 Table type objects. . . . . . . . . . . . . . . . . 3 1.1.1 The INIT_C class. . . . . . . . . . . . . . . . 3 1.1.2 The COMPLEX_C class. . . . . . . . . . . . . . 3 1.1.3 The SURV_C class. . . . . . . . . . . . . . . . 3 1.1.4 The ABORT_C class. . . . . . . . . . . . . . . 3 1.1.5 The DATA_C class. . . . . . . . . . . . . . . . 3 1.2 Routine type objects. . . . . . . . . . . . . . . . 3 1.2.1 The FIRSTLAST_C class. . . . . . . . . . . . . 3 1.2.2 The SWITCH_C class. . . . . . . . . . . . . . . 4 1.2.3 The EXEC_C class. . . . . . . . . . . . . . . . 4 2 Requirements and management of the operational database for the Executer. . . . . . . . . . 5 2.1 Which files are needed? . . . . . . . . . . . . . . 6 2.1.1 The ROUT_N.ORA file. . . . . . . . . . . . . . 6 2.1.2 The ROUT_E.ORA file. . . . . . . . . . . . . . 6 2.1.3 The CoMmaND Name/Table files. . . . . . . . . . 6 2.1.4 The SWIT_I.ORA file. . . . . . . . . . . . . . 6 2.1.5 The CoMmaND n.ORA files. . . . . . . . . . . . 6 2.3 Appendix. . . . . . . . . . . . . . . . . . . . . . 7 1 Overview of Executer constituent parts. The Executer of the RF PCA is essentially a process capable of executing sequences of sequences of control programmes. The repetition of the word "sequences" tries to illustrate the recursive nature of the way in which the Executer proceeds. A sequence is here defined as a series of steps (minimal control actions) that, when grouped together, represent a global control action. To this end the executer manipulates two types of objects: table type and routine type objects. Table type objects exist in 2 varieties. Either they are descriptions (recipes) to the Executer giving it the order in which a series of minimal control actions are executed such to perform a global control algorithm (a sequence), or they are descriptions of data available to all programme steps within the same sequence. In a sequence type of table object, a step can either be a reference to another sequence table, a reference to a piece of control programme code or a reference to a data description table. When the Executer finds a reference to another sequence on the current sequence step, it will continue execution by starting the first step of the new sequence. Once the new table is completely executed the Executer will continue the old sequence with the step following the one referencing the now completed table. Finding a reference to a piece of programme code in the current sequence step, makes the Executer to hand over the control to this code while passing a (standard) parameter to it. Upon execution of a sequence step containing a reference to a data description, the Executer will skip this step; the sequence step just provides a convenient "home" for the incorporation of data belonging to this sequence (e.g. in the case of the MMI "leaf static data" belonging to this "Path through the graph" sequence). When writing a programme, so to obtain a possible step for a sequence table, we are creating a routine type of object. A routine type object further has one or more "aspects". If we want to survey a piece of RF hardware we are likely to activate a different part of the routine than if we want to control the same hardware. In the first case we look at the "surveillance" aspect of the hardware (by calling the surveillance aspect of the routine) and in the second case at the "control" aspect (by calling the control aspect of the routine). All routine type objects are defined by the same (except for the name, of course) routine prototype which fixes input parameter and output return value; the two interfaces towards the Executer. The input and output data is generally not of concern to the Executer. The components that build table type objects will be administered by an off-line database manager (ORACLE). Extraction of these components (references to tables, routines and static data) and the grouping into meaningful and coherent descriptions will be done by the database manager in the form of man-readable ASCII files, thus documenting the Executer; easing the inevitable debug phase. The Executer, during boot-time, will also read these files and so construct its "database of commands". It is during this (late binding) phase that the Executer links the references to the control programme parts (routine type objects) and data parts (data table type objects) into the sequence steps that form the overall control algorithms for the RF hardware. After boot-time, no further command construction of the run-time command database is needed to be done; everything the Executer can do is already available to it (preservation of run-time resource). All objects (tables and routines) exist only once in the Executer; references to them can exist many times (preservation of memory resource). Sequences and control programmes are defined as belonging to one of either type. The objects of a type are further grouped in classes. Classes determine the "behaviour" of the Executer. Upon calling them, the routine type objects are notified of the Executer's behaviour by means of the aspect parameter. Here follows a description of the organization of these objects. 1.1 Table type objects. 1.1.1 The INIT_C class. This class contains tables of steps to follow in order to initialize RF hardware and/or software. The INIT_A aspect of routine type objects in INIT_C class tables will be activated by the Executer. 1.1.2 The COMPLEX_C class. Steps in the COMPLEX_C class of tables consist generally of either other COMPLEX_C class tables or an EXEC_C class routine type object. Upon calling, the Executer will address the CONTROL_A aspect of a routine type object. The first and the last two steps in a COMPLEX_C class object are reserved for the Executer system and consist of resp. a FIRSTLAST_C class routine type, an ABORT_C class table type and again a FIRSTLAST_C class routine type. 1.1.3 The SURV_C class. The SURV_C class table type object has steps that contain either another SURV_C class entry or an EXEC_C class routine type object. The Executer will call the SURV_A aspect if a routine type object is addressed. 1.1.4 The ABORT_C class. Each routine type object, existing in the current COMPLEX_C table of which this ABORT_C class object forms part of, and having an ABORT_A aspect is entered in this ABORT_C class table. By calling this sequence of routines with the ABORT_A aspect, the Executer will put all relevant hardware and/or software in a safe state, as defined individually by each ABORT_A aspect of the routine type object. The first and the last steps in an ABORT_C class object are reserved for the Executer system and consist of a FIRSTLAST_C class routine type. 1.1.5 The DATA_C class. Static (non run-time dependent) data, belonging to a particular command, can be included on a step in the command's sequence table. Upon execution, the Executer will simply skip such a sequence step that contains a reference to a DATA_C class object. 1.2 Routine type objects. 1.2.1 The FIRSTLAST_C class. The routine in this class (there exists only one for the time being) is a system routine. Its function is the creation of the start and end message of the table type object (i.e. a sequence) where it makes currently part of. When called, it will generate one out of eight messages: - "Master sequence started." - "Sequence started." - "Master sequence stopped." - "Sequence stopped. - "Master sequence aborted." - "Sequence aborted." - "Master sequence ended." - "Sequence ended." 1.2.2 The SWITCH_C class. This class is a system class. The routine in this class accesses the sequence name and sequence step counter and uses them as an index in its local database for finding which EXEC_C class object to launch. Launching of the routine occurs with the SWITCH_A aspect. The switch aspect of the routine might change the sequence step counter such that upon returning the Executer continues the sequence as indicated by the (modified) step counter. Upon exit the switch class routine produces a message showing the result: - "Switching to sequence: step: ." or: - "Invalid switch in sequence: step: ." 1.2.3 The EXEC_C class. In this class reside all RF application programmes that together form all possible RF hardware and/or computer resident RF data accessing single steps. These steps can be used in table type objects to form sequences. An EXEC_C class object can have several aspects that can be activated by the Executer or its system routines in order to perform an application dependent action. The aspects of an application really customize the generic Executer to perform a specific RF hard-/software action. An EXEC_C class object is not obliged to implement all possible aspects. Upon system generation, checks are made to insure that coherence exists between places where the Executer calls an aspect of a routine and the declaration of that routine in the system generation database (Oracle). An EXEC_C class object receives in its parameter a reference to the current sequence name and step counter. It is thus aware in which environment it operates. By using this information as an index in its own local database it is capable of adapting its action accordingly. 2 Requirements and management of the operational database for the Executer. Ideally it should be possible to create objects for use by the Executer and incorporate these in the latter independently from the creation procedure. This requires that the Executer would have a means available of loading both programmes and tables and be aware of their names as well as their addresses in memory in run-time. Such a system uses between the Executer and its routines and tables so called "late binding" or "run-time binding"; it is a characteristic of an object oriented operating system. We do not have such an operating system. The big advantage of independent design and configuration of our Executer is thus per definition not (entirely) available. Our operating system is capable of loading and starting a programme. The programme must be complete, i.e. all its programme constituents (their start addresses) must be known when loaded. This is the requirement of "early binding" or "compile/link time binding". However, by using tables between the Executer and the application programmes, a mixed approach and thus half of the advantages with respect to a truly object oriented system are obtained: - Early binding for routine type objects. A new routine type object added to the capability of the Executer requires compile, link and load phases before being available for operation (sorry). - Late binding for table type objects. Tables can be created off-line and downloaded into the PCA concerned and at a restart command to the Executer it will recreate its operational command database in memory. It is thus the Executer itself that will link the addresses of both its routine type and table type objects in the new system of tables. This system requires certain "tools" available. Tables and routines (i.e. their names, classes and aspects) can be managed by a database manager. Coherence between tables and available routines and aspects can be assured, some include (header) files automatically created, ready for use at the compile/link phase of the Executer and its constituent (application) routines, recipes (in ASCII) for the creation of an operational command database in memory by the Executer. Here we describe how the files, needed for the compilation phase of the Executer as well as those for the creation of all the tables in memory while executing the initialization command could be created from a database. It is assumed that the reader is familiar with the note: "The operational database for the RFS PCA". 2.1 Which files are needed? 2.1.1 The ROUT_N.ORA file. For compile time checking, this file contains the definition of a label that gives the number of routine type objects used by the Executer. Also a formal prototype of each routine type object is here declared. Any discrepancy between what the Executer thinks a routine type object is and the actual definition of the routine type object (the C-code) will thus generate a compilation error. 2.1.2 The ROUT_E.ORA file. During compilation time, an array of structures is declared. Every element of this array has fields for the RunTime NAME, an address and a flag. During the compilation/linkage phase of the Executer code, the linker will put a value in the address field, according to the C-code name and address operator in the ROUT_E.ORA file. When the Executer object code file gets loaded, the operating system will actually initialize the address array fields such that they really contain the addresses of the routines. Every element in this array represents thus data, describing a routine type object of the Executer. At initialization time, the Loader/linker can from this list find the address of every routine type object and thus capable of initializing the routine pointer field in each table object that references a routine object. 2.1.3 The CoMmaND Name/Table files. Every table type of object will have its ASCII descriptor file on the PCA disk, ready for being read during the initialization phase of the Executer. While reading this file, the Loader/linker part of the Executer will create a C-structure in memory, accessible by the Executer when actually commands get executed. 2.1.4 The SWIT_I.ORA file. 2.1.5 The CoMmaND n.ORA files. Although not really of concern for the Executer, the database could also deliver services while constructing the application programmes (the EXEC_C class routine objects). The application is aware of its operational environment through the sequence name and step counter pointers in the input parameter. It is thus possible to create in memory, upon initialization of the application, an application local operational database which gives reference data to the application as a function of the sequence and step where it executes. The format of this database is, of course, completely free to the programmers' distinction. The places, where the application is called by the Executer however, can be extracted from the Executers' database. On the level of the database, checks can be made to verfy if aspects, called by the Executer, are really existing, declared. A file of this category could thus be generated per routine object if runtime environment awareness were a requirement of the object. 2.3 Appendix. The appendix shows some examples of how the database extracted files are used in the compilation phase and initialization phase of the Executer.