New MOOC: Dispatcher
A mechanism to translate device-property based data
requests to object-method based data requests.
Details of mapping for requests which do not involve an alarm block property
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.
Computation of mapping using SSDN used for non-alarm-block properties
Currently, when a device is accessed the following information is provided:
Device index (di)
Property index (pi)
In the future, want to view front-end data access in terms of the following
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
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
(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.
(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
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.
Details of mapping for requests which involve an alarm-block property
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
This method returns two method pointers, one for each protocol, given a
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.
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.)
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
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
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.
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.
if the property is not an alarm-block
Look-up the protocol-di-pi 3-tuple in the dictionary.
if the dictionary returns an object-method pair continue
if the dictionary indicates that the di-pi is known but the protocol is
in appropriate, e.g., setting a reading, return an error
else ( the dictionary does not have a mapping for this di-pi )
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
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
Add mapping of this di-pi pair for both protocols to dictionary.
Invoke the method on the object.
else ( the property is an alarm block)
if getting alarm block
Look-up alarm block by di-pi in alarm block storage and return it
else ( setting alarm block )
Store alarm block by di-pi in alarm block storage
if this alarm block's object, method, and method arguments have not been
Compute and initialize object, method, and method arguments from SSDN
Security, Privacy, Legal
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
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.