Next: Defining device commands
Up: How to write
Previous: Understanding the device
Once the Device Server Programmer has understood the hardware
the next important step is to define what is a logical device i.e.
what part of the hardware will be abstracted out and treated as a
logical device.
In doing so the following points of the DSM should be kept in mind -
-
Each device is known and accessed by its ascii name.
-
The device is exported onto the network to be imported by applications.
-
Each device belongs to a class.
-
A list of commands exists per device.
-
Applications use the device server api to execute commands on a device.
The above points have to be taken into account when designing the
level of device abstraction.
The definition of what is a device for a certain hardware is primarily
the job of the Device Server Programmer and the Applications Programmer
but can also involve the Equipment Responsible.
The Device Server Programmer should make sure that the Applications
Programmer agrees with her definition of what is a device.
Here are some guidelines to follow while defining the level of
device abstraction -
-
efficiency, make sure that not too fine a level of device
abstraction has been chosen. If possible group as many signals
together to form a device. Discuss this with the Applications
Programmer to find out what is efficient for her application.
-
hardware independency, one of the main reasons for writing
device servers is to provide the Applications Programmer with
a software interface as opposed to a hardware interface.
Hide the hardware structure of the device. For example if the
user is only interested in a single channel of a multichannel
device then define each channel to be a logical device.
The user should not be aware of hardware addresses or cabling
details. The user is very often a scientist who has a physics-oriented
worldview and not a hardware-oriented worldview.
Hardware independency also has the advantage that applications
are immune to hardware changes to the device
-
object oriented worldview, another raison d'etre behind the
device server model is to build up an object oriented view
of the world.
The device should resemble the user's view of the object as closely
as possible.
In the case of the ESRF's Machine Control System for example the
devices should resemble an operator's view of the machine.
-
atomism, each device can be considered like an atom -
is a independent object.
It should appear independent to the client even if behind
the scenes it shares some hardware or software with other objects.
This is often the case with multichannel devices where
the user would like to see each channel as a device but
it is obvious that the channels cannot be programmed
completely independently.
The logical device is there to hide or make transparent
this fact.
If it is impossible to send commands to one device
without modifying another device then a single
device should be made out the two devices.
-
tailored vs general, one of the philosophies
of the DSM is to provide tailored solutions.
For example instead of writing one serial line class which
treats the general case of a serial line device and leaving the
device protocol to be implemented in the client the DSM advocates
implementing a device class which handles the protocol of the device.
This way the client only has to know the commands of the class and
not the details of the protocol.
Nothing prevents the device class from using a general purpose serial
line class if it exists of course.
Next: Defining device commands
Up: How to write
Previous: Understanding the device
Andy Goetz
Tue Jan 28 13:58:13 MET 1997