Документ взят из кэша поисковой машины. Адрес оригинального документа : http://curl.sai.msu.ru/mass/download/doc/infrasoft_eng.pdf
Дата изменения: Tue Mar 15 14:29:24 2016
Дата индексирования: Sun Apr 10 00:20:37 2016
Кодировка:
The package of control software for automatic astro climatic monitor
V. Kornilov, O. Voziakova, M. Kornilov, B. Safonov, N. Shatsky
March 15, 2016


Intro duction
Automatic site-testing monitor (ASM) of Sternberg Astronomical Institute (SAI) is installed on top of mountain Shatdzhatmaz at 40 m to the southwest of the centre of the 2.5 m telescope tower, according to the pro ject of SAI Caucasus observatory. The monitor was installed and started up in 2007 in order to collect the most important astroclimatic characteristics: statistics of seeing and vertical distribution of the optical turbulence, statistics of the fraction of clear skies, data on the atmospheric extinction, and the most essential meteorological characteristics -- the speed and direction of surface wind, diurnal and seasonal variation of ambient temperature and humidity. The obtained information will be used for a comprehensive characterization of the site where the 2.5 m telescope will be installed, estimation the perspectives of adaptive optics systems implementation and strategical planning of observational tasks to realize the full efficiency of the telescope. In the future, the real-time measurements from ASM will be used to optimize the schedule of observations at the telescope.

1

Network and software architecture of ASM

Automatic site-testing monitor includes the following computing and networking items: 1. Machine eagle -- full name eagle.sai.msu.ru, the local IP 192.168.10.8. It is installed in the communication room of the Solar station. This machine is used as a gateway of the ASM for external access. There are several services running on this machine: an HTTPserver displaying the current state of ASM, archiving of the measurement data coming from other machines of the ASM and web-cameras image storage. 2. Access points chines of the Solar station, from the first 192.168.10.2 and 192.168.10.3 provide network connection to the other maASM. The first point is located in the building of optical laboratory of the the second one -- at the ASM tower at mountain summit about 800 m away one.

3. Machine omicron (local IP 192.168.10.5) is installed under the enclosure of the monitor in a metal cabinet. Its purposes are collection of meteorological data, management of the power supply, to control the dome enclosure, acquiring images from the outside (yard) and internal (dome) synoptic cameras (SPC900NC Philips), connected to it via the USB interface. RS485 line for exchange of data and commands with the power controller, dome controller and meteosensors controller is connected to the serial port via custom-made COM/RS485 converter. The machine is running permanently, but in the period from 11:57:00 to 12:03:00 local time it's automatically restarted. 4. Machine druid (IP 192.168.10.4) is installed in the same cabinet where omicron is installed. It is switched on in the beginning of the measurement session and switched off at the end of the session. This machine is connected to the Meade RCX400 telescope, the MASS/DIMM instrument and the telescope finder/guider camera. Its purpose is to control the telescope and data acquisition of the DIMM and MASS channels of the MASS/DIMM instrument. The data exchange with the finder/guide camera (SPC900NC Philips) is performed via the USB port, with the DIMM-channel camera (Prosilica EC650) ­ via the 1


IEEE-1394 interface. The MASS channel is connected through LPT/RS485 converter to the parallel port, and the telescope and its controller are connected to the serial port. The structure of the ASM is represented schematically in Fig. 1, where the left side shows the equipment installed at the Solar station, and the right side -- the equipment installed on the ASM tower and in a trailer located near it which houses the power batteries, the meteo-controller and sensors on the mast of wind turbine.

Figure 1: The structure of the automatic site-testing monitor. Here #1 is druid, #2 is omicron and #3 is eagle.

2

Comp onents of ASM software

The operation of the astroclimatic monitor is currently performed by the following software components: - tlsp -- the program for control of the RCX400 telescope and finder/guider camera. - dimm -- the program for control and data acquisition of the DIMM-channel of the instrument; - mass -- the program for control and data acquisition of the MASS-channel of the instrument; - shutdown -- the daemon for remote shutdown of druid machine; - dome -- the program for control of enclosure and power supply for main equipment; - monitor -- the program for meteo-data acquisition and power status monitoring; - ameba -- the program for scheduling of the observations process. Data on the sky condition are requested from the program everest running on the server of the MASTER pro ject apollo.sai.msu.ru, port 15012. 2


The current state of ASM and other information is displayed with help of components that run on machines eagle and omicron through the web interface: 1. meteoAgent -- translation of online data from the monitor program for an HTTP-server; 2. rainAgent -- translation of data from everest program for timely enclosure shutting down.

3

Principles for building the software

Our experience of development and operating the MASS/DIMM software obtained in 2002 ­ 2006 led to changes in the initial approach and requirements to the software for an automatic operation of ASM and other similar automated systems. A detailed discussion is given in the paper "The new software for MASS/DIMM instrument. Control core Turbina-core"1 , where the basic requirements for the software and its elements are represented as well. During the process of designing and programming, we generally adhere to those principles, although some particular ideas have evolved significantly. Thus, in the process of the development of basic software we tried, where possible, to use the following philosophy: 1. The software consists of several individual software components that run and operate independently of each other, and if necessary one can interact with another. Partition of the software into separate components enables 1) to increase significantly the flexibility by performing some functions at the operating system level, 2) to simplify the process of developing and debugging of the software, and 3) ensure the stability of the whole system, 4) to define and simplify the system logic in a separate software component and 5) to provide a smooth parallel execution of various functions. 2. Each software component implements a single logical task or function of ASM. This implies a division of all the work into separate, fairly isolated and self-contained parts. In this case, priority is given exactly to the problem, not to the maintenance of a device. For example, the program tlsp is responsible for pointing the telescope to the desired ob ject, the centering and guiding during the measurement time. For this, the program interacts with the telescope, the special custom-made power controller of the telescope and the finder camera. On the other hand, the enclosure controller is requested from two programs -- dome and monitor. 3. Background operation of the program is a basic feature, so there is no user interface. However, by the default, components start in the foreground. If needed, transition into the background is performed by the program itself but not with help of shell. This approach was selected in order to have the detailed information about the failed startup cases, and then completely release the standard I/O channels. Thus, during normal working all the software components are functioning as "daemons". 4. Reports on progress and error are always recorded in the log file of the program. Some software components do not produce output data (for example, ameba). In such cases the log file should contain all the information about the program. The names of the log files are generated using the format YYMMDD-program.log, where YYMMDD -- the program start
1

http://curl.sai.msu.ru/mass/download/doc/turbina-core.pdf

3


5.

6.

7.

8.

9.

date (calendar date in the evening of the observational night, the date changes at local noon), program -- program name 2 . Controlling of the program is carried out using 1) options on the command line at startup, 2) configuration file data and 3) the commands coming over network connections. The options have the same meaning for all programs because they are handled by a common module and relate to the program context. Configuration files also have similar structure but contain the settings of the functional part of the program and external devices. Commands coming via network connection, initiate a specific action of a separate program. As a rule, these commands do not change tuning parameters. The format of commands of operational control is described in "Supervisor program User Guide SV version 0.24"3 and was used earlier in the MASS software and other pro jects. Using text commands of regular format enables efficient manual control, which is important at the stage of debugging the system as a whole. Synchronization of ASM operation is done at the command level. Program ameba performs the role of sup ervisor which implements a general algorithm for operation of the ASM. The remaining software components are functioning as servers. There is only one exception: the program tlsp uses for automatic guiding the information from DIMM channel -- offset of the star image relative to the centre of the working aperture. To do this, it individually sends requests to dimm program as a client to perform the corresponding measurement. Since this measurement requires 2 s, the synchronization is carried out according to the principle: the first request is satisfied. The command which came after (and thus rejected with BUSY in a response) is repeated by a client within a short period of time if necessary. Logical structure of the software components is built on a common base. The same functions within the program are provided by common modules. In particular, they include the configuration support, error handling, network exchange, analysis of external commands, exchange through the RS485 interface, time and astronomical coordinates. The structure of each program contains a static part and a dynamically generated ob ject which is created in the active (initialized) state -- the so-called Device. The static part supports common functions, a device initialization and its destruction. Software components are mainly implemented in C++ with the active use of standard template library. A common programming style is maintained. In a mandatory manner, a source code is stored and developed in the CVS. All software is designed to run on the operating system GNU/Linux. The preferred distribution -- OpenSuse 9.2, 10.2, 11.2.

These approaches to development and support of the ASM software correspond to modern ideas of pattern design and have allowed us to develop and debug the entire set of components with minimum expenditure of resources.

4

Lo cation, starting and stopping of software comp onents

Each software component program is placed in appropriate directory /opt/program/. A structure of these directories is unified. They contain the following subdirectories:
2 3

name of the log file of the program monitor contains the word sens see http://curl.sai.msu.ru/mass/download/doc/sv ug.pdf

4


- - - -

etc/ for configuration files, data/ for all input and output files, data/log/ for log files, data/out/ for output data files.

Executable file is placed in the root directory /opt/program/. Also some additional subdirectories can be found there, for example, /opt/dimm/data/images/ is intended for images obtained on request or as a protocol frames from the CCD-camera of DIMM-channel. The owner of files and directories is a system user mass of mass group which has the necessary privileges. In the case of debug or experiments the program can be run by anyone on behalf of mass, for this the attribute of the executable file contains an s-bit set. In the normal mode, these components are run with help of the system utility cron either during the computer start (tlsp, dimm and mass at machine druid, monitor on the machine omicron) or at a designated time (dome on machine omicron, ameba on machine eagle). Depending on the situation, launch of the software component can be carried out with various options (keys) on the command line. The following keys are common for all software components: -a -b -c -d -p -i -- software component and appropriate equipment initialization on startup; -- transition to background after startup; name -- use configuration file name instead of the default file /opt/program/etc/program.cfg; -- run program in debug mode; N -- use socket port N instead of the default number set in configuration file; host -- use IP name host for machine instead of 0.0.0.0 used as default.

In order to complete the normal operation, the programs are stopped by the command quit sent by the program ameba to each component. In order to minimize the risk of damage of equipment due to failures of network connections, a special watchdog stops the software after the completion of observations on each machine, normally before sunrise. Its main goal is to turn off the power of the instrument (including high voltage in the MASS-channel) and close the dome. Manual control of all software components is possible by using network utilities such as telnet or netcat. When using the telnet it is enough to connect to a needed port at the computer where the component works, and to give a text command in accordance with the used protocol. For example, in order to connect to the program tlsp using the console of any computer located in the local ASM net one should type telnet druid 16400, where 16400 is the program default port number. If the program tlsp is running, the connection will be established and any syntactically correct command will be accepted for execution. The utility netcat is useful in scripts.

5

Common software mo dules and commands

As was already mentioned in previous sections, the common logic functions are maintained with help of the common software modules. For various reasons, these modules are used as source files located in directories infras and server rather than as ob ject libraries. The modules provide 5 basic functions: 5


- - - - -

configuring the software component; exchange with other programs or user via TCP/IP protocol; parsing of external commands and providing their execution; exchange with the equipment via RS485 interface; handling errors and maintaining the log file.

Structure of configuration files was preserved the same as in the program Turbina: a set of separate sections outlined by keywords Section and EndSection and containing a logically cohesive set of subsections SubSection . Each subsection contains specific configurable options related to the particular ob ject of the program. For example, in the configuration file of the program dimm section General contains two subsections: Site and DIMM. The first of these subsections contains parameters that determine the geographical location of the device: SubSection "Site" DeviceNumber SiteName Longitude Latitude EndSubSection MD09 KGO 2 50 40 +43 44 12 ;device serial number ;observatory or site name ;longitude of the site ;latitude of the site

Parameter string consists of its name and value. After reading the configuration file, the value is stored in the program as part of a three-dimensional associative array. Not all of the settings contained in the configuration file are need for the program, these parameters are simply being transferred in the output file and then are used by processing software. This approach reflects the principle that the output data must contain all the information necessary for processing and further interpretation of the information. In a certain degree, the configuration file resembles the logical structure of the program, because the parameters naturally unite together in sections and subsections corresponding to some program ob jects. The location of some of the parameters is rather arbitrary, for example, the above DeviceNumber may be in another place in the file, since it is not used by the program itself nor by the processing software and is given for reference only. Exchange of commands and data over a network connection in the form of text messages is provided by module server. A mark of the end of the command is a terminal symbol . Functioning of the module is weakly associated with the accepted command protocol and focused on the correct service of network connection and disconnection of the clients and handling error situations. In addition to the server side, the module also contains a class for the client side. Recall that the exchange is based strictly on an individual form -- the answer to a command or request will be sent only to that client which has sent a request. The module for command parsing comms supports the command protocol. Through the appropriate interface layer it produces the initialization (command init) and parking of the program (command park), completion of the program (command quit), an extraction of relevant data (command get), a modification of software parameters or processes (command set) and a basic functions of the program by a command run. One of the main functions of the module is synchronization of these commands processing. The command get doesn't modify the component status and may always be executed. Other commands will be executed if the program is initiated. Difference between handling of the 6


command set and the command run lies in the fact that the first is performed over time much less than the typical time-out of network communications but commands run require more time. So, it (as well as the command init and park) is executed in a separate thread. Initialization of the program involves the following steps: reading the configuration file, the creation of program ob jects, opening the output data file, the connection with the equipment and its initialization. After a successful initialization the program goes into the status READY. Parking is done in reverse order: disable hardware, closing exchange and output files. After parking the program is in status PARKED. Also, parking is performed before program will quit after receiving the command quit. Commands set or run cannot be executed if the software component (and related equipment) is in the parked state. In this state, one can only get information about the general state of the program, for which the parsing module provides 3 get-commands by itself: get status -- returns the component current status: OK STATUS=READY or OK STATUS=BUSY or OK STATUS=PARKED. get ident -- returns name of the component and its current version, e.g. IDENT= ''Turbina-core(D) Vers. 2.26''. get error -- returns last error description in the same form as in the log file. In further description of commands of specific programs, these commands will be omitted, as well as init, park, quit. Programs interact with custom equipment with help of batch exchange via the physical interface RS485. In order to provide this interaction we use a set of software modules (along with appropriate system driver developed at SAI). Front-end modules provide all the necessary functions of exchange, including error handling and emulation or exchange for debugging purposes. They also provide synchronization (deadlock) of requests from the different program streams. Adopted way of handling error states which may occur in operations of software components is based on the mechanism of generation of exceptions in point of error detection and broadcast it to the upper software layers where errors are processed or simply recorded in the log file. Apart from error states, messages on the main phases of the program execution are recorded in the log file. Extended recording in the log file is enabled when you start the program with the option -d on the command line. Typically the programs that interact with the equipment via the RS485 interface record all communications and commands. In the log-file of the ameba all network commands and received replies are recorded. The structure of a typical message in the log file is illustrated by the following lines from the log file of the dimm program 2009-04-29 2009-04-29 2009-04-29 2009-04-29 2009-04-29 20:38:06.88 20:48:31.82 20:48:38.29 21:34:54.18 21:35:00.09 (000) (000) (000) (620) (000) Digital Client Images No two Client Camera (DCAM 127.0.0.1:2688 have different star images 127.0.0.1:2944 1.31) camera is connected attaches max brightness > 0.43 Centering frame is empty detaches

After the UT timestamp, the error code in parentheses is recorded. It was designed for automatic error handling for the client and for filtering of protocol messages (search for identical or similar errors). Code 000 indicates an informational message rather than an error. A textual description of the error consists of two parts, the filling of which is possible on different logical levels of the program for more simple localization of source errors. 7


6

Software comp onent mass

The program performs the collection and initial processing of data from the MASS-channel of the device and controls this channel. Principles of measurement is similar to those which we used previously in the program Turbina4 . Data collection and processing is done in the following temporal intervals: - exposition ­ duration of the elementary flux measurement (microexposure), is given in milliseconds - basetime ­ interval (in seconds) for which the statistic moments of relative fluctuations of the flux is calculated - accumtime ­ duration of the whole mode (in seconds) of measurement All the fluxes written in the output file, are converted to microexposure interval. The program provides the following modes -- the specialized functions of measurement: - Normal mode ­ measuring the scintillation of stars over Normal mode/Accumtime time. Minimal star flux Normal mode/MinimalStarFlux is checked. The mode outputs "m" and "s" lines after basetime integration, and "A" lines on the end of accumulation. - Background measurement ­ measuring the sky background without any checking during the Background measurement/Accumtime. The mode outputs the "m" line and "A" line. - Flux estimation ­ any flux measurement over Tests/FluxEstimationTime is typically used when checking an ob ject. The mode outputs the "m" line and "A" line. - Statistic measurement ­ measuring of the control light source during Normal mode/Accumtime for specified control light level. The mode outputs "c" format line after basetime integration, and "C" line on the end of accumulation. - Counting measurement ­ measuring of the control light source during Normal mode/Accumtime for specified high voltage level. The mode outputs "c" format line after basetime integration, and "C"line on the end of accumulation. - Detector test ­ the measurement of control light source with Tests/DetectorLight intensity for the detector checking during Tests/DetectorTestTime. The mode outputs the "m" line and "A" line on the end of accumulation. Error is detected if the resulting fluxes don't coincide with specified Tests/TestCounts. - Statistic test ­ the measurement of artificial scintillation over Normal mode/Accumtime. The mode outputs the "m" line and "A" line on the end of accumulation. - Exchange test ­ the checking for a failure of data transmission from the device into computer over Tests/ExchangeTestTime. The test outputs only final verdict, e.g. Exchange Test: It's OK The sequence of modes can be specified as a scenario -- a combination of mode codes and arithmetic operations. Example: F+20*(N+B), where F -- mode of the flux estimation, N -- normal mode, B -- background measurement. In this example, first the flux is estimated, then pair of normal and background measurement modes is repeated twenty times. The list of implemented commands:
4

http://curl.sai.msu.ru/mass/download/doc/main document.pdf

8


- - - - - - - - - - - - - - - - - - - -

- - - - -

run or run normal ­ start the normal mode, run background ­ start the background measurement, run flux ­ start the flux estimation, run dtest ­ start the detector test, run stest ­ start the statistic test, run etest ­ start the exchange test, run stat=ligh ­ start the statistic measurement set before control ligh level (0.0­1.0), run counting=hv ­ start the counting measurement set before hogh voltage value in Volts, run normal background dtest ­ start the few modes in one sequence, run scenario=2*N+F ­ start the scenario 2*N+F, run scenario ­ start the scenario which was set before, get flux ­ request for the flux values, the values for 4 apertures FluxA=... FluxB=... FluxC=... FluxD=... are returned, averaged over last completed mode, get data ­ request for the measurement results for the completed mode (output as in the file format), get temp erature ­ request for the inner temperature of the device, get hv ­ request for the high voltage status. ON or OFF are returned, get illum ­ request for the field aperture illumination status. The response is ON or OFF, get light ­ request for the control light status. The response is ON or OFF, get mirror ­ request for the viewer mirror position. Response ON -- the mirror is at optical axis, OFF -- the mirror is out, set scenario=2*N+F ­ set of scenario 2*N+F (for example), set ob ject=". . ." ­ write the information on ob ject in the output file. This is used for data processing and is provided as (e.g.) 20 set object=``7949 Eps Cyg 20 46 13 +33 58 13 2.46 1.03 K03'', giving the HR-catalogue number, star name, ICRS coordinates, V- and B-V magnitudes and spectral code for weight function selection, set illum=on/off ­ turn on/off the field aperture illumination, set hv=on/off ­ turn on/off high voltage for PMTs, set cnt=on/off ­ turn on/off record of raw counts over exposition into *.cnt-file stop ­ stop of scenario after currently executed mode, stop now ­ abort the mode after current basetime.

The results of basetime-measurements are written to the output file YYMMDD-mass.stm in lines with the prefix "m". Average over accumtime results are written as lines with prefix "A". Those lines format is identical to Turbina "m" lines format and contains the following space-separated fields: 1. Line prefix "m" or "A" 2. UT date of the measurement finish in YYYY-MM-DD format 3. UT time of the measurement finish in hh:mm:ss format

9


4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.

Average Average Average Average Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali Normali

flux in A aperture flux in B aperture flux in C aperture flux in D aperture zed variance of flux in A aperture zed variance of flux in B aperture zed variance of flux in C aperture zed variance of flux in D aperture zed covariance of fluxes in A and B apertures zed covariance of fluxes in A and C apertures zed covariance of fluxes in A and D apertures zed covariance of fluxes in B and C apertures zed covariance of fluxes in B and D apertures zed covariance of fluxes in C and D apertures zed temporal (lag 1) covariance of flux in A aperture zed temporal (lag 1) covariance of flux in B aperture zed temporal (lag 1) covariance of flux in C aperture zed temporal (lag 1) covariance of flux in D aperture zed mixed (lag 1) covariance of fluxes in A and B apertures zed mixed (lag 1) covariance of fluxes in A and C apertures zed mixed (lag 1) covariance of fluxes in A and D apertures zed mixed (lag 1) covariance of fluxes in B and C apertures zed mixed (lag 1) covariance of fluxes in B and D apertures zed mixed (lag 1) covariance of fluxes in C and D apertures zed temporal (lag 2) covariance of flux in A aperture zed temporal (lag 2) covariance of flux in B aperture zed temporal (lag 2) covariance of flux in C aperture zed temporal (lag 2) covariance of flux in D aperture

The example of an "m" line: m 2009-06-29 18:07:27 0.13019 0.08321 0.25292 0.15963 0.10496 0.07140 0.30545 0.22407 0.13013 195.1 332.6 1476 1636 0.30575 0.22430 >>> 0.16987 0.08573 0.15699 0.08648 0.08862 0.20257 >>> 0.17305 0.13209 0.08179 0.12354 0.07904 0.07805 >>> 0.08320

For Statistic measurement and Counting measurement, the results of basetime-measurements are written to the output file YYMMDD-mass.stm as lines with the prefix "c". Averaged over the accumtime results are written as lines with prefix "C". Those lines format is identical and contains the following space-separated fields: 1. Line prefix "c" or "C" 10


2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

UT date of the measurement finish in YYYY-MM-DD format UT time of the measurement finish in hh:mm:ss format Average flux in A aperture Average flux in B aperture Average flux in C aperture Average flux in D aperture Normalized variance of flux in A aperture Normalized variance of flux in B aperture Normalized variance of flux in C aperture Normalized variance of flux in D aperture Poisson parameter of flux in A aperture Poisson parameter of flux in B aperture Poisson parameter of flux in C aperture Poisson parameter of flux in D aperture

The example of an "c" line: c 2014-11-27 20:36:56 0.130 1.425 1.033 1.27365 3.08925 1.1371 1.1676 1.3157 0.377 1.1647 8.77569 0.81917 >>>

7

Software comp onent dimm

Modes, formats of the output files and commands of the program dimm are described in detail in a special document "Turbina-core(D): Dimm User Guide"5 . Just as in the program mass, the following temporal intervals are used: - exposition ­ frame exposure of the CCD-camera (in milliseconds), - basetime ­ interval (in seconds) over which the calculated parameters and characteristics of differential motion of images of star are computed, - accumtime ­ duration of measurement mode (in seconds). The list of commands is shown below with a brief explanation of the function related. - run or run normal ­ start the main mode to measure differential motion inside the working window at the CCD frame, - run center ­ start the measurement of the images positions in whole field aperture - run test ­ start the measurement of the illuminated field aperture for device parameters evaluation, - run scenario=2*N+C ­ start the scenario 2*N+C (for example), - run raw ­ start the main mode with raw data output, - run estimation ­ start the main mode with duration of one basetime, - run pictures ­ start the record of the working window images into output file,
5

http://curl/mass/download/doc/dimm soft description.pdf

11


- get offset ­ request for the position of common pair centre regarding centre of the field aperture (in pixels), - get separation ­ request for the separation between images for x and y (in pixels). - get flux ­ request for the total and maximal intensities for left and right images (counts per exposure), - get data ­ request for the data. The data of last completed mode is returned in the form of output file string, - get mo de ­ request for the name of current or completed mode, - set scenario=2*N+C ­ set of scenario 2*N+C for further action, - set ob ject=". . ." ­ write the information on ob ject in output file like: 20 set object=``6396 Zet Dra 17 08 47 +65 42 53 3.17 -0.12 B55'' (see mass component section), - stop ­ stop of scenario afte