Device drivers in the M&C software translate abstract parameter settings which are represented by parameter messages into commands sent to the physical device and vice versa. The basic idea is to modularize the software in a way, that one device in a station setup can be replaced by another model, perhaps even by a model made by another vendor, simply by selecting another device driver.
The sat-nms M&C advances this concept by introducing a 'universal device driver' which is completely user configurable. The configurable device driver let's you write your own device drivers for device models which are not yet supported by the software. Most of the device drivers coming with the software are built on top of this configurable driver, so there are a lot of examples you can use as a template.
The universal device driver
The figure below illustrates the structure of a device driver built with the 'universal device driver'. The principal function, however, applies to 'hard coded' drivers, too.
To other software components (primarily to the user interface) the device driver interfaces by a list of variable definitions. On the other hand, a list or procedures does the 'real work', translating the abstract parameter values to physical command sequences. In between a function here called 'variable -- procedure linkage' defines which procedure is run to set or read a certain parameter.
With the universal device driver, all this is setup (compiled) during the program initialization from a text file which describes the device driver in special, but quite simple programming language.
Variables
Variables are the interface between the device driver and the other components of the software, specially the user interface. Each variable acts as an end point for a parameter message. It may receive messages -- which causes the driver to set this parameter at the physical device -- but also may send it's parameter message in order to tell the user interface about the actual setting of this parameter. Chapter ' Device Driver Variables ' explains this more detailed.
Procedures
There are two types of procedures a driver may define. A 'PUT' procedure sends one or more parameters to the physical device after coding them into the format the physical device expects. A 'GET' procedure sends a request to the device, reads the reply and decodes one or more variable values from the data received. A procure never can be both, 'PUT' and 'GET' at the same time.
The driver's environment in the software provides one program thread for each physical interface (e.g. RS232 port). Within this thread all procedures of all device drivers communicating through this interface are called in a fixed sequence. The threads are running concurrently, utilizing the computer's capacity for one thread while another is waiting for a device's reply. Chapter ' Device Driver Procedures ' gives more information about how procedures work.
Special types of device drivers
Not all device drivers are implemented by means of the universal device driver. On the one hand there are a couple of devices which use such a trick method for their remote control, that the universal device driver is not capable in handling this.
The other and larger group of 'hard coded' drivers comprises the so called logical devices . These devices do not communicate directly with a physical device, they in fact combine parameter messages in some way and send the result to other device drivers. Power control loops or a software based automatic redundancy switching device are two common examples for this driver family.