| |
|
|
|
4.1 DECOMPOSITION OF AN APPLICATION
A VLT application normally consists of a number of processes communicating with each other via messages. The processes can be located entirely on one computing unit (LCU or workstation) or it can be distributed on different computing units. The communication between the processes are done through the message system.
The processes on a workstation typically coordinates processes on different LCUs and interfaces to the user. The LCU processes controls devices, where devices typically are simple independent electro-mechanical units (motors with tachometer and encoder, detectors, shutters, temperature controllers etc.). A classical example is an astronomical instrument, which consists of filter wheels, gratings, grisms, mirrors moving in and out, slits, all fairly simple mechanical units working independently of each other. Another example is a detector LCU, which controls detector devices and shutters. Such a subsystem also contains processes to copy and to preprocess data. These processes are not directly involved in controlling devices.
4.1.1 Process Naming Conventions
The names of processes accepting commands from outside the module shall conform to the following convention:
where <mod> is the name of the software module.
Additional processes within a module shall be named <mod>Xxxxx.
The reason for having a different convention on LCU and WS is that several modules will have a process on both LCU and WS. Different processes with different functionality (commands) must have different names, because the CDT of a process must have the same name as the process and two processes with different commands cannot share the same CDT.
The name of a process shall correspond to the functionality performed. As an example a LCU process (software device) controlling a hardware device shall have the same name as the device.
If a database branch belongs to the software device, the alias of the root point of the branch shall be the same as the name of the software device, e.g. the alias of the database branch of the altazServer shall be altaz.
A process can control more than one device. This shall only be the case if the devices are functionally connected. In this case the name of the process shall be related to the group of devices it is controlling
4.1.2 LCU Binary Naming Conventions
Each LCU module normally produces at least one binary file to be loaded on the target LCU.
This binary shall have the same name as the software module which is the same name as it is archived with CMM. This is essential because when the binary is loaded, the loading software also searches for error definition files with the same prefix to be loaded on the LCU. These files are used
by the error system to produce the proper error logs according to the error definition files.
Example: the module scan produces a binary scan. Its error definition file is named scan_ERRORS.
Each module shall also include a .boot file which is a VxWorks script file to load the module on the LCU, initialize it and start up the process(es) of the module on the LCU. This .boot file shall have the same prefix as the module, e.g the scan module has a scan.boot file.
By following these rules assures that the tools vcc and lcuboot works as intended. This also assures that the module is loaded into memory before other modules are initialized, thus reducing memory fragmentation.
For multi-module projects it is recommendable to link all LCU-modules to a single binary during make of the top-level module instead of loading many binaries.
4.1.3 Assigning Processes on the LCU
A typical LCU controls a number of relatively independent devices. In such a case it is natural to assign one control process to each device. In case the devices are interacting and the control of one device depends of the state of another device it might be required to control several devices by the same process. Another possibility is to keep one process per device and to have a coordinating process which controls the low level processes.
In any case it is recommended to have a top level process on each LCU performing the main function of the system. This gives a hierarchy of processes, with one top level process controlling low level processes. The interface to the LCU will be simpler only having one process as the destination of commands. It might also be necessary to have several layers of processes. See fig. 3 below.
The global commands, which are used for normal control of the LCU, shall go through the top level process. The top level process then sends the appropriate commands to the lower level devices. If necessary it must also be possible to send these commands directly to the low level devices.
Maintenance and test commands on the other hand will normally be sent directly to the low level devices.
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|
