Design Principles

The Scheduler will be based on a number of principles. These principles will determine the functionality and interface the scheduler will offer to all users of the NCCS. The principles listed below are the result of discussions held between A.Götz, M.Gaylard and J.Quick.

Here is a list of the main design principles and what they signify :

1.

anti-trust - the Scheduler will assume that the users of the NCCS cannot be trusted. That means that checks will be build into the system which prevent users from circumventing the Scheduler. Once the Scheduler has decided which is the next program to run it will inform all active parts of the NCCS. It is assumed that the active parts of the NCCS will be implemented as device servers. The device servers will check every incoming write request to prevent unauthorised programs from executing.

2.

scans - all observations will be based on the concept of a scan. A scan will be the basic unit of observation. There will be a scan type per observation type. The type of observation will determine how the scan is executed e.g. track a single position, scan in declination (for mapping), do an on-off etc. Different scan types will be implemented depending on the different types of observation. Each observation type should be broken down into the smallest meaningful unit i.e. scan.

3.

scan id's - the Scheduler will use the concept of scan identification to determine which program may execute at any time. The scan id will be a unique identifier which is used by the Scheduler to identify every scan. The scan type will determine which resources are required by the observing program and inform the Scheduler. Resources which are not required by the scan type will be released by the Scheduler so they can be used by other programs.

4.

restricted resource super-class - a new super-class, the RestrictedResource class, will implement the necessary methods for handling scan id's. Not all devices require to have restricted access. Those which do will be derived from the RestictedResource super-class. The super-class will keep track of the scan id, implement a command for receiving the new scan id from the Scheduler (using a special identifier to avoid other processes from posing as the Scheduler) and a method for checking the scan id.

5.

active scheduling - the Scheduler will be active. It will periodically check the status of the current observing program, the list of suspended programs and background programs waiting to run. If there has been any change e.g. observing program has crashed, scan has ended/expired, a higher priority request has come in, the Scheduler will invalidate the present scan id and issue a new scan id to the appropriate program. Because the Scheduler is active it can abort a scan when a program has crashed or the scan has expired.

6.

observation cron table - routine monitoring observing programs and background programs will be handled in a similar manner to to the way cron manages background tasks in Unix. Users will submit their background programs to a file. The file will contain all the necessary parameters for running the program at the right time(s). The Scheduler will periodically read this file and intepret its contents. The contents of the file will be very similar to the file SCHDL presently maintains on the HP.

7.

scheduling algorithm - the Scheduler will have an algorithm for deciding which program to schedule next. It envisageable that multiple algorithms are implemented and that it is possible to switch between different algorithms at startup time or even on the fly.

8.

mono resource - the Scheduler will allow only one process to have access to a restricted resource at a time, so-called mono resourcing. Other processes who want access to a resource have to wait for it to be freed. Mono resourcing does not mean mono tasking - multiple processes using different resources can run simultaneously.