GBT Control Simulator
The goal of the GBT simulator is to provide a test bed which minimally
replaces the code running on the actual telescope. Of course the ideal test bed would be
one built around a duplicate telescope, however this is a little pricey, so the next
best thing would be a system which replaces only the software directly interacting
with the telelecope.
This solution is attractive because though numerous interfaces to
the electronics and mechanics of the telescope exist, there are surprisingly few
types of interfaces. Providing simulation for only these lowest level
software modules or drivers will allow other software (including observation scripts)
to be developed and tested on the simulator.
In addition, to simulating the protocol of the interface software, the actual
information being passed back to the higher layers of software must be reproduced
if it affects the behavior of other software modules. There are four classes of possible feedback
from the telescope to the software: control, monitoring, alarms,
and data. In the control software, feedback is used only to confirm the that
configuration values were set correctly in the digital interface. Since we
wish to simply reflect back the written value, this can easily be simulated in the drivers.
In most cases,
monitor values are passed on to the user and therefore their values as regards
to the software can be ignored. The exception being when alarms are conditional
on the monitor values. In these cases we will need a way to specify the values
to be returned from the drivers to the monitor software.
Finally, simulation of the data itself will not be attempted in this initial version.
The simulator would need to generate "reasonable" data only for the sake of testing
analysis, reduction or data monitoring programs.
These programs may be tested using data archives
from the telescope.
For the initial
version, the simulator devices will
generate "content free" astronomical data, e.g., all zeros.
Software development needs over the last 15 years has resulted in several simulators being written.
These simulators were developed independently at different times and are operated in a
variety of manners. As a rule of thumb, simulators were written for client programs of
Ygor (GO, config_tool, and turtle) or for complex devices (Spectrometer, DCR, SpectralProcessor, Antenna, and LO1).
In each case the simulator was written for a specific purpose. And some were abandoned once the hardware
was available or the device became operational (SpectralProcessor and DCR).
The better a simulation reflects the system it purports to represent, the fewer new problems the
developer is likely to discover when testing on the actual system. Because the effort
for increasing the fidelity of a simulator quickly becomes costly, most of these specific-purpose
simulators do not attempt to do more than needed for its specific needs since the developer does not expect the simulation
to find all of ones bugs anyway. The telescope simulator described here provides two new attributes to
our toolchest of development tools. Since only the lowest levels of the telescope are replaced
by simulation, nearly to the level of the hardware itself, a greater proportion of bugs can be found
before testing on the actual telescope. Second, some testing requires the entire system, e.g.,
IFManager, and some bugs only manifest themselves if the entire system is running.
In addition to minimizing the differences between the simulator and the
telescope in the actual code being run, the carry over from the actual telescope to the
simulated telescope can be optimized if the build, installation and initialization of the
system are the same.
A Ygor telescope installation contains a directory for housing configuration files ($YGOR_TELESCOPE/etc/config).
These configuration files are used to modify the behavior of the system.
Almost all device software have one or more configurations files which are
read by the software to determine modes of behavior, e.g., setting criteria
for generating messages, what hardware to access, or command-line arguments
for launching daemon programs.
If the only difference between the real and simulation telescopes' installations
are defined by the associated config files, then not only will the builds, installations
and initializations be identical, but even executibles could be directly copied from one
environment to the other for comparisons.
Most of the devices on the GBT use the MCB for interfacing to in-house devices
and IEEE-488 for commercial devices. Simulators for these two drivers will
allow simulation of most devices on the GBT. The port to Linux has gone
a long way to solving this problem. The antenna and most backends
have device-specific drivers which will require custom simulation code.
Fortunately, because of the need for software development three key devices, the Antenna, LO1,
and Spectrometer, already
have simulators of sorts which need be modified to be part of an overall telescope simulation.
The Antenna needs to have its dependencies on the old 140' simulator removed which also
forces it to use code tied to a specific computer (muccu).
The LO1 can be compiled as a simulator; this will need to be modified so the same
executable can run either as part of the telescope or the simulator according to
a flag in its configuration file.
The Spectrometer only needs to pick up the simulation flag from its configuration file
as well as a command-line argument.
The IFRack only requires an MCB device driver, but has not yet been
migrated to Linux. The best use of resources would be to go ahead and port this
device to accomplish the inclusion in the simulation.
The simulation of backends beyond the Spectrometer
are tabled for the initial version.
Most interactions with databases for Ygor are reads so the simulator can use
the same databases as the real telescope.
Other Ygor software such as the ScanCoordinator, Measurements, and IFManager
do not have device drivers and can run "as is."
The following table lists the target set of devices for a simulator which
will provide an initial operating simulator for a reasonable amount of effort.
| Device | Drivers | Architecture | Simulator |
|---|
| | MCB | 488 | Custom | | |
|---|
| AnalogFilterRack |  | | | Linux | |
| Antenna | | | | Linux | |
| ConverterRack | | | | Linux | |
| DCR | | | | Linux | |
| IFRack | | | | Linux | |
| LO1 | | | | Linux/VxWorks |  |
| MMConverter | | | | Linux | |
| Gregorian Receivers | | | | Linux | |
| Spectrometer | | | | Linux | |
| SwitchingSignalSelector | | | | Linux | |
- exists, but requires more work
- Antenna
- The antenna coordinator and manager are currently deployed on Linux/x86. Simulation is performed at the device level, though the use of a servo simulator. The servo simulator needs to be ported. Currently the simulator runs on VxWorks only.
- DCR
- The code does have a Linux version, with simulation of switching and power levels (i.e. noise).
- LO1
- The LO1Coordinator is now deployed on the Linux/x86 platform. The real LO1 synthesizer manager runs on VxWorks, but there are Linux versions of the sythesizer simulators.
- Spectrometer
- A command-line flag -x causes the executible to run as a simulator, the code only needs to be modified so setting SIMULATE to true in the configuration file does the same thing.
For the first release the following items are specifically out of scope:
- simulation of astronomical data
- driver-level simulation in the LO1
- backends except for the Spectrometer (and maybe the DCR)
- prim focus receivers and associated devices
- non-telescope devices, e.g., timing center or weather stations
- PTCS devices
- all-monitor devices, e.g., MotorRack
- ResetBox (no VxWorks in simulator)
- variable monitor values
- Architecture
- Determine the machine and disk to create an installation. (< 1 day)
- Ygor
- Modify hard-coded references in ygor code from /home/gbt to $YGOR_TELESCOPE and from ../ygor to $YGOR_ROOT. (1 day)
- GrailClient
- Make identity of Grail host dependent on installation, e.g., via a configuration file. (< 1 week)
- Antenna
- Port simulator to Linux removing dependencies on specific machines and make running of the simulation version dependent on the host names listed in system.conf and leelooProc.conf. Much of this work has been perform in support of transporter testing, but approximately 3-5 days of debugging is required to finish the port. (The work relates to the emulation of status, and some minor timing issues.)(< 1 week)
- AnalogFilterRack/ConverterRack/MMConverter
- Modify SIBMap.conf to refer to a simulation file having the requisite values for proper simulation. (< 1 week)
- database
- turtle needs an alternate database. The databases gbt_configuration, gbt_status, turtle, receivers, and antenna_pfm should be duplicated with an alternate name and the names should be specified in system.conf. (1 day)
- DCR
- Check out how much effort may be needed to run as a simulator. (< 1 day)
- IFRack
- Migrate to Linux and modify SIBMap.conf to refer to a simulation file having the requisite values for proper simulation. (2 days)
- LO1
- Make running of the simulation version dependent on a variable SIMULATE in LO1Coordinator.conf instead of compile-time options. (1 week)
- Receivers
- Modify SIBMap.conf to refer to a simulation file having the requisite values for proper simulation. (2 days)
- SwitchingSignalSelector
- Modify SIBMap.conf to refer to a simulation file having the requisite values for proper simulation. (< 1 day)
- Spectrometer
- Modify so simulation mode is dependent on a variable SIMULATE in Spectrometer.conf as well as a command-line argument. (1 hour)
The simulator should be able to run (though not produce useful data!)
the following observations:
The simulator should become a part of periodic automatic testing to improve the reliability of our code, and
to guarantee that code changes take into account the simulation version as well as the production version.
- Where ever hard-coded directory paths, host names, or database names were found, they were changed to variables.
from gbt.ygor import getConfigValue
ygor_telescope = getConfigValue(".", "YGOR_TELESCOPE")
grailHost = getConfigValue("localhost", "GrailHost")
turtle_db = getConfigValue("unknown", "TurtleDatabase")
- The selection of a sparrow version for use by Ygor daemons was based on a symbolic link in YGOR_TELESCOPE called sparrow rather than hard-coding a sparrow version in the Ygor code.
- Devices using the MCB hardware driver for interfacing with digital electronics were ported to Linux and their file driven simulation capability were used.
- Current simulators were used and updated where possible, e.g., Antenna and Spectrometer.
- Duplicate databases were created where needed, e.g., turtle, antenna_pfm.
- New configuration files were written to support simulation mode.
APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.
ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.
Symbols:
- Use
%X% if MR is not complete (will display 
)
- Use
%Y% if MR is complete (will display )
Revision r1.24 - 19 May 2006 - 11:59 GMT - JoeBrandt
Parents: PlanOfRecordC62004
|
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.
|
| |