|
|
Paper: |
Revisiting the Real-time Requirements for the ALMA Control System |
Volume: |
522, Astronomical Data Analysis Software and Systems XXVII |
Page: |
663 |
Authors: |
Amestica, R.; Brandt, P.; Marson, R.; Rosen, R.; Whiteis, P. |
Abstract: |
The ALMA Online Control software applies the Controller Area Network (CAN bus) to interface with hardware devices. Software applications communicate with antennas (motion, digitizer, etc.) and correlator hardware by means of CAN bus messages and monitors. Specifically designed protocols for the CAN bus are profusely documented across a number of Interface Control Documents. Antenna bus master (ABM) computers and the correlator control computer (CCC) are all equipped with the same TEWS TPMC901 CAN bus controller. Because both the Control and Correlator subsystems use the CAN bus, they share the driver and low level software. To achieve a synchronized array operation (max. 15 Km baseline), a 48 ms electrical timing event (TE) signal is distributed to each computer from the technical building at the ALMA high site. TE interrupts are handled by a custom Linux kernel module, such that the absolute time associated to each event is available. CAN bus commanding can thus happen at specific TEs for any given observation start time, or at periodic moments for specific devices. At the same time, and to achieve reliable command timing, ALMA applies real-time extensions to the Linux Operating System. Low latency is necessary to discriminate individual TEs and to schedule CAN bus messages at specific moments within a TE window. Once real-time guaranties are satisfied at Operating System level, then, a high priority TE interrupt-service routine and specific threads that consume TE interrupts, make possible to command hardware always on time. Currently, a Linux dual-kernel approach (RTAI) is utilized by ALMA. RTAI has registered latencies of just a few tens microseconds under normal observing conditions, which is well below the one millisecond resolution needed by the ALMA online software. Apart from latency performance, a better solution is that one that makes current deployment simple and provides long-term maintainability. For that reason, an effort is in progress to reevaluate other possible solutions, including plain Linux, which requires no kernel patching. In this paper we revisit ALMA's real-time requirements, we overview how they have been fulfilled up to now, and what available alternatives might work better in the near future. |
|
|
|
|