ANALYSIS OF A MATCHING PROBLEM BETWEEN THE RFS CONTROL SYSTEM MAN/MACHINE INTERFACE AND EXECUTER + APPLICATIONS. E. Bracke ***---*** 1 Facts. 1.1 *** The Man Machine Interface recognizes as a command unit only a path through the graph (representation of the command database). This yields at the Executer level a reference to a command name/table. 1.2 *** In the MMI environment, an elementary command is defined as a path through the graph, yielding thus a cmnd_nt, in which is embedded a routine type object that makes a single call over the fieldbus. 1.3 *** The fieldbus parameters are administrated by the MMI command database (the graph in a sense). By issuing an elementary command (a cmnd_nt) a reference to the fieldbus parameters of this elementary command must be available. This reference must thus make part of the cmnd_nt. In this way the routine type object embedded in the (elementary) cmnd_nt can be conceived as truly generic; its current use depending on the fieldbus parameters that are belonging to the current elementary command (cmnd_nt). Note: I shall be calling these characteristics for the rest of this note the "MMI view". 1.4 *** The Executer gives every routine type object a reference to the environment where it currently is operating. This reference (name of cmnd_nt, step within the latter) can be used to the routine's own discretion, e.g. as an index in its private RAM database for accessing a set of parameters relevant to the current execution. The initialization of this RAM database was done by reading ASCII files (generated by ORACLE) at the moment of initialization of the Executer and its constituent routine objects (and thus also the current one). 1.5 *** If we adhere to the first and second conclusions presented somewhat further in this note (a thing I have always been doing) we admit: The Executer (+ routine objects, here) uses one more level of detail for its operation as compared to what the MMI database handles; not only table objects but routine objects (i.e. a constituent of a table object) as well. Note: I shall be calling these characteristics for the rest of this note the "Executer view". 2 The problem. Suppose we need writing an Executer application routine object that, for its internal use, requires using some data, e.g. available only in run-time, through the fieldbus. 2.1 This means in terms of "MMI view" of solving: We shall be using an elementary command and 2 solutions look seemingly at our disposition: - We embed the application routine in a cmnd_nt together with the elementary command (cmnd_nt) itself at the step immediately before the application. The generic routine in the elementary command will effectively acquire the requested data via the fieldbus. An elementary command, being just a legal command as any other, will have ackowledging "Start of sequence", "End of sequence" and "Abort sequence" steps. The Executer keeps track of the "last return message" buffer for use by the next step in the cmnd_nt. The acquired data therefore, will be sent, as part of the normal procedure of reporting all steps in a sequence, via the Reply & Report process to the "requester" of the application command only. Our application routine will have only access to the buffer containing "End of sequence". - We embed the application routine in a cmnd_nt together with the elementary command's routine type object at the step immediately before the application. The elementary command's routine however has been conceived generically and it is the database available from the elementary command (i.e. the cmnd_nt) that contains the required fieldbus parameters for correct access. 2.2 In terms of "Executer view" of solving: The generic fieldbus access routine would have build (during its initialization) a private RAM database with fieldbus parameters as a function of all environments where it is going to operate. Here the second solution of the "MMI view" could now do the job; the "last return message" buffer indeed contains the required data. However: Suppose the application programme needs 2 (or more) acquisitions for its internal use... We then need dedicating 2 (or more) steps in the embedding cmnd_nt and again we only have the "last return message" buffer available to our application. 3 Isn't it an "academic" problem? NO! An example: In the sequences for Travelling Wave there are several occasions where acquisition of the global status of equipment (transmitters and cavity) is necessary. In the "MMI's view" the individual acquisitions would all be elementary commands. However the data acquired need in general be disposed in a adequate way into the sequence's data area, depending on the sequence's use of it. Therefore a "global status acquisition" sequence will be a necessary step in the main sequence. This "global status acquisition" sequence will acquire and put the data into the main sequence's data area in the correct format. - In my opinion, either: the acquisition step(s) must know how the main sequence's data area has been laid out (i.e. coupling of programme functionality, and furthermore, the acquisition routine(s) could hardly be called generic anymore), or: - the "acquired data formatting" routine (last step in the aforementioned "global status acquisition" sequence) itself must have to call the acquisition routine(s) under its own responsibility. In this case the acquisition routine(s) must be given the means for accessing the elementary command's database(s) (fieldbus parameters). The latter solution is in my opinion the one to be retained. At least it has been the way how I thought using the facilities available to and from the Executer. 4 Conclusions from the analysis. 4.1 *** It must be made possible for a routine type object to call directly another routine type object. Remark: No other problem than the guarantee of the parameter conformity with the Executer interface needs to be solved by the routine type object that wants to call a non generic routine type object (i.e. one without a database driven operational mode). 4.2 *** It must be made possible for a routine type object to call directly any other routine type object, even if the latter is embedded in a cmnd_nt and has a particular database associated with that cmnd_nt (the case of "elementary commands"). Remark: The callable routine can now even be a generic one; the attached database determines what will be done by it. 4.3 *** The MMI command database is in principle not the adequate place for handling all the data aspects/needs for the Executer (compare first and last facts). 5 Finding a solution. 5.1 Assuming: A routine type object must have the possibility of calling another routine type object directly, i.e. under its own responsibility. 5.2 Using "Executer view": - The elementary commands (fieldbus accessing cmnd_nt's) will comprise a generic routine object doing the actual acquisition and a database that could either be in the routine's private RAM database as a function of sequence name and step, or be a reference, attached to the cmnd_nt representing the elementary command. (The latter option for "compatibility" with the "MMI view".) - The calling routine object will acquire from its own RAM database the name and step of the adequate "elementary command" and will setup the acquisition's routine (embedded in the elementary command) parameter accordingly. - It will make the direct call to the generic fieldbus access routine. The access routine, by its parameter, will "think" being called from the "elementary command" and thus acquire the correct fieldbus parameters from its RAM database or through the (elementary) cmnd_nt reference. - The generic fieldbus access routine will do the required access. 5.3 What remains. The problem now lies at the ORACLE database manager: How to organize the extraction of all routine's RAM database layout files? Is this the work of the RFS control MMI or is it the work of the "operational database" for which a (very, very) tentative definition has been presented approx. one year ago. In fact, is the "operational database" not just another aspect of the MMI? Are programmers (conceivers of the control system) "Men"... and, if considered so, don't they deserve and could not they benefit of using the services of the MMI for their work... Should this part of MMI ("operational database", that is) not especially be dedicated to them? Of course, requirements for both of these database aspects are (as shown in a conclusion), necessarily, quite different. In my opinion they should reflect the two views which I here dubbed "MMI" and "Executer". The first one seeing the control problem "functionally", i.e. abstractly, not with necessarily in mind the required (RFS hardware imposed) control steps for turning the "functionality" into "reality". The second one would be purely "real", i.e. reflecting the RFS hardware imposed control steps, their auxiliary data and other requirements, all necessary for performing the operator requested "function". 6 And finally: where did it go wrong? In my opinion, the MMI presents an ambiguity that is responsible for the above sketched confusion on the level of application programmes and other routine objects of the Executer. At one side it pretends to be "functional", "abstract", which is fine, but on the other side it administrates things like e.g. the fieldbus parameters which is "real" world data. Trying to link, "couple", the two aspects in one database is likely to give us some further surprises in the future. A further indication that something is fundamentally wrong, is, again in my opinion, the fact that the presentation layer of the control system has such an impact on the way the execution layer is allowed to "think". (Note, even with another functional layer in between!). I call this functional coupling of the layers building up the whole control system and I think it is NOT a good feature. I would prefer some more design freedom for the execution layer in order to make the Executer perform as efficiently as possible its own functionality rather than being tied up by satisfying the efficiency requirement of the command presentation or -database layer. At the execution layer I would prefer "being served" by the higher control system levels; in the sense that these levels would "massage" the gathered data into formats that come closer and closer to the required execution format so that finally the Executer can concentrate on its functional task, sure of everything being there and in the right format.