New MOOC: Dispatcher A mechanism to translate device-property based data requests to object-method based data requests. Carl Schumann  

1. Requirements/Goals
• Mechanism that enables arbitrary mapping of traditional device-property data requests to object-method based data requests for requests which do not involve an alarm block property.  The motivation for this is that an object-method based way of requesting data is where the control system is headed with either Java RMI or CORBA.  The current device-property scheme resembles an object-method scheme where a device corresponds to an object and a property to a method, but fails because the small number of properties and the fact that all devices share the same property space means that many real world objects, e.g., 453 cards, have too many methods to be handled as a single device.  A device is smaller than an object, i.e., it is more on the scale of an object attribute than a whole object.
• Mapping should allow devices to map to potentially different objects for each non-alarm-block property.
• For alarm block properties, the mechanism  in combination with other parts of the new MOOC does the normal alarm handling, so that the front-end developer does not have to write alarm handling code for the normal situation..  But for complicated alarm handling situations, e.g., frig (becaues it has multiple alarms per device) or MADCs (beacuse the alarm block is downloaded to the CAMAC module), new MOOC should allow the front-end developers to supply their own alarm handling.
• In combination with other parts of the new MOOC put the di in the EMCs.  Modify DABBEL so that for new MOOC devices DABBEL will supply the EMC.
• The mechanism must be fast for the vast majority of  requests.
• The mechanism must handle devices which did not exist in the database at the time the front-end code was developed and the front-end booted.  However, will require that  the possibility that such a device could exist does need to be know when the front-end code is developed.
• Mechanism should not require database access from the front-end.
• Mechanism should not require modifying existing device information, e.g., SSDNs, in the device database.
2. Details of mapping for requests which do not involve an alarm block property
• Currently, when a device is accessed the following information is provided:
• Protocol
• Device index (di)
• Property index (pi)
• SSDN
• Length
• Offset
• Actual data
• In the future, want to view front-end data access in terms of the following information:
• Object
• Method
• Method arguments
• Need a mapping from the cartesian product of the first set to the cartesian product of second set.   Since object and method are not independent some points in the cartesian product of the second set do not make sense, these points are ones that correspond to an object and method, where the object is not of a class that supports that method.  The mapping should not map any points in the cartesian product of the first set to such points.
• In order to simplify the mapping the following observations are used.
• The only issue that the mapping cares about in regards to protocol is whether the protocol is for getting or setting data.  Thus the mapping does not need to distinguish between RETDAT and FTP, for example.  However it must distinguish between RETDAT and SETDAT.  Therefore, protocol can taken on one of two values "get" or "set".
• Protocol is not allowed to participate in the selection of the object only the method.
• Based on how existing devices have been implemented here, it should not be necessary for length, offset, and the actual data to participate in the selection of object and method.  The length, offset, and actual data would be provided to the object has method arguments.
• Since a di-pi pair completely determines the SSDN, the mapping can be done by either by the di-pi pair or the pi-SSDN pair.   To compute the  mapping for a previously unknown di-pi pair one would want to use the pi-SSDN pair.   For looking up the mapping of a known di-pi pair one would want to use a dictionary, perhaps implemented with a hash table, that uses the di-pi in the key.
• So we end up with two equivalent mappings one fast one dynamic
• Fast mapping:
• (Protocol,di,pi) to (object,method)
• Used for di-pi pairs the front-end already knows about, either because they were in the startup script or because a request for the pair has been made previously to the front-end.
• Mapping implemented by a dictionary.
• Dynamic mapping
• (Protocol,pi,SSDN) to (object,method)
• Used when a front-end sees a di-pi pair that it does not know about.
• The front-end computes the mapping using the SSDN.  More details on how this is done later.
• Since the front-end also receives the di-pi pair for that SSDN it adds the di-pi pair to the dictionary so that future requests will use the fast mapping.
• There would be potentially 10 different method signatures - 2 protocols by 5 non-alarm-block properties.  The method signature would include SSDN, length, offset, and data.
3. Computation of mapping using SSDN used for non-alarm-block properties
• ObjectLocater class
• One instance per front-end.
• Method to return object pointer given a pi-SSDN pair.
• An abstract class with specific implementations for different SSDN formats, e.g., a CAMAC ObjectLocater would look at the crate and slot fields of the SSDN to determine the object.  Some mechanism, a registry of some sort, would need to be provided to go from an object specified in terms of crate and slot to an object pointer.  The CAMAC ObjectLocater could check that the driver code was appropriate for the card that is actually in the given crate and slot.
• MethodLocater method provided by each object itself
• An abstract class method of the generic object class.  Concrete subclasses of generic object, e.g., 453 object, implement this method. It is a class method since all instances will return the same method pointer given a pi-SSDN pair.
• This method returns two method pointers, one for each protocol, given a pi-SSDN pair.
• As an example the 453 method would look at the the subtype codes in the SSDN to determine the methods.  If the subtype was 2 and property was setting it would return setFtTable() and getFtTable(), if the subtype was 3 and property was setting  it would return setGiTable() and getGiTable(), etc.  If the subtype was 2 or 3 and the property was not setting then the method would return an error.
4. Details of mapping for requests which involve an alarm-block property
• The mechanism needs to be able to map an alarm-block request to an arbitrary object, but it does not need to be able map it to an arbitrary method, since alarm handling will be provided by the generic object class from which all objects inherit and therefore the method names can be known in advance.  These four instance methods implemented by the generic object - setting an analog alarm block, getting an analog alarm block, setting a digital alarm block, and getting a digital alarm block - will be dynamically bound, i.e., virtual functions, so that objects can provide their own alarm handling if needed.   The computation of the object pointer will use the ObjectLocater class in the same way as non-alarm-block properties do.
• The di, pi, SSDN, and alarm-block will be provided as arguments to the above four methods.  New MOOC will store the di so that when an alarm occurs it can be placed in the EMC.  For each alarm block the object, method, and method arguments for retrieving the value to be compared to the contents of alarm block needs to be computed from the pi and  SSDN.  This computation is done when an alarm block is set and the result is stored so that the computation is not done each time the alarm is scanned.
• The computation of object and method from the pi-SSDN pair is described above, but first the pi must be changed to the pi for the property that the alarm block monitors, i.e., digital to status and analog to reading.  This means that SSDNs in the database for a device's alarm block and its associated property should point to the same "data item".  However the SSDNs may not be identical because the SSDNs might encode information on how the data item is to be formatted.  If the data needs to be formatted one way for input to a PDB conversion routine and another way to be compared against the alarm block, then the SSDNs would be different.
• The arguments to the status or reading method would include as stated before an SSDN, a length, and an offset.  The SSDN is the one sent when the alarm block was set, so new MOOC will need remember the SSDN.   The length is specified in the alarm block.  The offset is zero.
5. How a  request is handled (This does not address the modification of the SSDN for a di-pi  for which the mapping has already been computed with the old SSDN.   This situation could be handled in at least two ways which are presented in the next section.)
1. if the property is not an alarm-block
1. Look-up the protocol-di-pi 3-tuple in the dictionary.
1. if the dictionary returns an object-method pair continue
2. if the dictionary indicates that the di-pi is known but the protocol is in appropriate, e.g., setting a reading, return an error
3. else ( the dictionary does not have a mapping for this di-pi )
1. Invoke ObjectLocater's method to translate the pi-SSDN pair to object pointer, this could fail in which case the front-end should return an error
2. On the object returned by the ObjectLocater invoke the MethodLocater method to translate the pi-SSDN pair to method pointers for both protocol types, this could fail in which case the front-end should return an error
3. Add mapping of this di-pi pair for both protocols to dictionary.
2. Invoke the method on the object.
2. else ( the property is an alarm block)
1. if getting alarm block
1. Look-up alarm block by di-pi in alarm block storage and return it
2. else ( setting alarm block )
1. Store alarm block by di-pi in alarm block storage
2. if this alarm block's object, method, and method arguments have not been initialized
1. Compute and initialize object, method, and method arguments from SSDN
6. How consistency with database is maintained. In the following discussion when I refer to DABBEL doing a particular task, this task could instead be done by some auxilliary program, which is informed of database changes by DABBEL, e,g., DOWNLD.
• DABBEL generates the startup script for a front-end when a device on that front-end is added, modified, or obsoleted.  The script specifies di-pi-SSDN 3-tuples as arguments to a routine which is executed in the startup script.  The routine is executed for each di-pi pair with that di-pi pair's 3-tuple as the arguments.  Alarm-block property SSDNs would also be specified in this matter.  Of course, the front-end will need to have the associated alarm blocks downloaded before it can begin scanning alarms.  This introduces a concurrency issue since DABBEL and the front-end will potentialy access the stratup script at the same time.  However, this should not cause any problems, beyond having to reboot the front-end again if DABBEL was writting the script when the front-end is booting.
• There are at least two mechanisms to insure consistency with the database when an SSDN is modified.  The first is easier to implement; the second has better performance.
• Since the SSDN is stored with each di-pi pair in the mapping (so that it can be provided as an argument to the method), just compare the incoming SSDN to the stored SSDN and recompute the mapping if they differ.  This comparison be should relatively quick - comparing two 4 byte integers for equality.
• Create a new protocol for updating mappings on the front-end. This protocol would contain an array of di-pi-SSDN 3-tuples. DABBEL would use this protocol to transmit SSDN changes to front-ends.
• For di-pi pairs added to the database after the front-end boots, the front-end will use the SSDN which is sent along with the di-pi in the request.  The next time the front-end boots it will get this information from the startup script since DABBEL will have rewritten the startup script.  The front-end does need to know about the possibility that such a device could be created at boot time, though.  Example, at boot time the front-end has a 453 card in a given crate and slot with no devices in the database.  Even though no devices currently access this 453 the front-end will still construct a 453 object for this card, so that if  a device is added later that accesses this 453 card the associated 453 object will be there to handle the request.

 

Security, Privacy, Legal