JCMT Observatory Control System

1. JCMTObservatory Control System Frossie Economou, Per Friberg, Tim Jenness, Russell Kackley, Firmin Oliveira, Nick Rees, Matt Rippa, Craig Walther (JAC) Ian Bryson, Bill Dent, Martin Folger, Xiaofeng Gao, Dennis Kelly, John Lightfoot, Ian Pain (ATC) Gary Hovey, Tony Willis (DRAO) Russell Redman (HIA)

2. Overview • Introduction • History • Basic requirements • Top-down design (NPR) • A walk-through the design from the user interface down... • Bottom-up design (CAW) • Detailed description of components • Questions, threats, abuse, etc… JCMT OCS

3. Introduction

4. Some History • Apr 94 Discussion of JCMT Control System Futures • Sep 96 ACSIS proposal • Apr 97 OCS Design & Planning Meetings • Apr 98 ACSIS PDR • Jan 00 OCS put on hold • Apr 00 Parts of OCS restarted at ATC • Jun 00 RTS Requirements Document. RTS starts taking shape • Nov 00 OMP project restarts/JAC Software groups reorganized. • Apr 01 OCS interfaces meeting. Core OCS takes shape. • Oct 01 Second major OCS meeting. • Jan 02 Core software releases. XML file performance evaluated. • May 02 Perl sequencer prototyped. Decision to replace TODD • Aug 02 OCS CDR. JCMT OCS

5. Basic Requirements • VMS systems need to be replaced. • ACSIS and SCUBA2 need additional functionality. • All observations defined using an observing tool. • Observing is controlling a queue of defined observations, not command line driven. • External interfaces are simple and consistent. • Detailed sub-system control in engineering interfaces • Reason is so development groups can have reasonable freedom to do what is right for them. • Need commonality with UKIRT at high level and, where possible, at lower levels (i.e. TCS). JCMT OCS

6. Top-down design

7. Classical design of an OCS • Sequential set of simple commands issued by observer (or script) either at command line or GUI. • Unless instrument is telepathic or predictive, operational sequence is governed by the order commands are issued. • Sub-system has no way of knowing what sort of observing is being done until integration starts. • Complex parallel sequencing is required to ensure every sub-system is ready for integrating in the most optimal fashion. • The complex sequencing has made the existing control task inflexible and impossible to maintain. JCMT OCS

8. New JCMT OCS design • Requirement is for a highly automated system, not a manually controlled one • Control is done at a higher level (observation queue). • Commands are optimized for machine control, not human control. • Observing tool allows all subsystems to be given their complete configuration at the same time. • Small variations from the fixed configuration are broadcast before each data taking sequence. • Don’t care about “micro-managing” the control of sub-systems, just focus on synchronizing them so they are all ready when data taking starts. JCMT OCS

9. User Interfaces The OMP has already delivered most of them! Science programs will be prepared with the Observing Tool MSB’s will be selected by the Query Tool The Observing Queue be controlled by the Queue Monitor The main differences will be: An Observation Monitor for controlling the current observation. Ability to have multiple instruments controlled at once. The Queue monitor and the Observation monitor will probably be joined into one coherent interface. Observing Tool Queue Monitor Observation Monitor Query Tool New JCMT OCS design JCMT OCS

10. Observing Tool Observing Queue Queue Monitor Observation Monitor Query Tool System Configurations Configuration Files Observation List Science Programs MSB’s Observation Observation Database MSB Observation Translation New JCMT OCS design What happens under the hood? JCMT OCS

11. Configuration Files • Serve a similar purpose to SCUBA ODF’s, but much more detailed and flexible. • Uses XML, which gives the following advantages: • Widely accepted standard • No language bias • Document Type Definition (DTD) and XML Schema documents allow XML to be validated. • Hierarchical structure allows data to be ‘packaged’. • Observation configuration can be viewed as one monolithic file, or a number of small ones which are “included” (XML entities). • OCS DTD is at: • http://www.jach.hawaii.edu/JACdocs/JCMT/OCS/ICD/001/ocs.dtd JCMT OCS

12. Configuration Files • The observation configuration is broken into a number of sections: • HEADER_CONFIG • TCS_CONFIG • INSTRUMENT • RTS_CONFIG • FRONTEND_CONFIG (Heterodyne only) • ACSIS_CONFIG (Heterodyne only) • For example: • http://www.jach.hawaii.edu/JACdocs/JCMT/OCS/ICD/001/ocs.xml JCMT OCS

13. Observing Tool Observing Queue Queue Monitor Instrument Manager Observation Monitor Query Tool Configuration Files System Configurations Observation List Science Programs MSB’s Observation Inst. “A” Sequencer Inst. “B” Sequencer Observation Database MSB Observation Translation Instrument “B” Tasks Shared Tasks Instrument “A” Tasks New JCMT OCS design JCMT OCS

14. New JCMT OCS design • Since observations are fully defined, we changed all sub-system interfaces so they had a common set of simple commands: • CONFIGURE • Sends the XML configuration to each sub-system. • SETUP_SEQUENCE • Sends just the few parameters which indicate how the next integration differs from the current configuration. • SEQUENCE • Execute the integration sequence - i.e. take data. • On JCMT we have a real-time sequencer that takes over here. • END_OBSERVATION • Needed to close up an observation. JCMT OCS

15. CONFIGURE • Takes a single parameter which is the XML file. • XML file is generated by the translator, and maps onto the XML generated by the OT reasonably well. • XML file completely determines default instrument state for the observation. • Each sub-system moves to its default state as a result of configuration. • Each sub-system sets task parameters that are needed in SETUP_SEQUENCE by other tasks. • The same file could be sent to all sub-systems but, in practice, only subsets may be sent for efficiency. JCMT OCS

16. SETUP_SEQUENCE • Manages the state transition between sequences. • A small number of well-defined parameters: • TASKS: The names of the sub-systems that will participate • MASTER: The task which will signal the start of the sequence. • STEP_TIME: The time taken (in seconds) for each RTS cycle. • SOURCE: Next TCS position - SCIENCE or REFERENCE. • INDEX: A number - the next grid point or raster row. • BEAM: A, B or MIDDLE • LOAD: Front-end load - SKY, AMBIENT or LOAD • FE_STATE: Name of the state table for the front end • GROUP: General parameter for grouping sequences. • DRCONTROL: General parameter Data Reduction control. • SMU_X, SMU_Y, SMU_Z: SMU position (for focus recipes). • Tasks can, in return, place constraints on the length of the next sequence, if required. JCMT OCS

17. SEQUENCE • Actually performs the data-taking • Three parameters • START: Start sequence number - between 1 and 232 • END: End Sequence number - between START and 232 • DWELL: The number of RTS transitions (and sequence numbers) between each state transition of the sub-system. • Hands control over to real-time sequencer • CONFIGURE XML file and SETUP_SEQUENCE parameters define the state table to execute. • Rendezvous on first RTS handshake starts observing. • Only one task (the master) can delay the handshake significantly. JCMT OCS

18. END_OBSERVATION • Signals everyone that the current observation is finished. • Data files are closed and systems will wait in an idle state for the next command. • Another observation will require a new CONFIGURE command, so END_OBSERVATION is normally followed by getting the next observation off the queue and another CONFIGURE command. JCMT OCS

19. New JCMT OCS design • All commands are broadcastto participating systems • In general, all tasks on the list receive all the commands. • An important observing recipe parameter is the “tasklist” - the list of the participating sub-systems. • To first order we don’t care how the sub-systems sequence themselves, we just want them to be ready when data taking starts. • The observing recipes contain no detailed sequencing. • In reality, there are some dependencies, and this is handled by a rendezvous protocol in which a task can wait until another task is ready. • We found didn’t need multiple levels of rendezvous. JCMT OCS

20. JCMT OCS observing recipes • ACSIS will be delivered with 6 basic “Observing Recipes” • Pointing • Focus • Jiggle-Chop • Raster • Grid • Jiggle Frequency Switch JCMT OCS

21. JCMT OCS observing recipes • Recipes make use of simple “primitives”, e.g.: • integrate • does a SETUP_SEQUENCE, followed by a SEQUENCE • calibrate • does a two or three load calibration • The exact syntax is not finalized • Recipes are currently pure Perl, but this may be too daunting - users may get confused by the syntax, and not focus on the actual content. JCMT OCS

22. Typical Observing Recipe sub jiggle_chop { read_parameters; configure( configuration_file_name ); for ( cycle = 1 .. num_cycles ) { calibrate(); for ( nod_set = 1 .. nod_sets_per_cal ) { for ( beam = “A”, “B”, “B”, “A” ) { integrate( SOURCE => "SCIENCE", BEAM => beam, LOAD => “SKY” … ); } } } calibrate(); end_observation(); } JCMT OCS

23. Actual Observing Recipe sub jiggle_chop( $$$$$$$ ) { my ( $tasks, $configuration, $num_cycles, $num_nod_sets, $jos_mult, $step_time, $n_load2samples, $n_skysamples, $n_ambsamples ) = @_; # Read recipe parameters my ( $status, $group, $i, $j, $k ) = ( 1, 0, 0, 0, 0 ); # Initialise variables configure( $tasks, $configuration, $status ); for($i=0; $i<$num_cycles && $status; $i++) { calibrate( $tasks, 1, $n_load2samples, $n_skysamples, $n_ambsamples, $status ); for($j=0; $j<$num_nod_sets && $status; $j++) { $k=0; foreach my $beam ( "A", "B", "B", "A") { $group = $group + 1 if (($k % 2) == 0); $k = $k + 1; # Integrate on beam A or B integrate( $tasks, { "SOURCE" => "SCIENCE", "INDEX" => 1, “BEAM" => $beam, "STEP_TIME" => $step_time, "LOAD" => "SKY", "GROUP" => $group, "DRCONTROL" => 0, "MASTER" => "" }, 1, $jos_mult, $status); } } } calibrate( $tasks, 1, $n_load2samples, $n_skysamples, $n_ambsamples, $status ); end_observation( $tasks ); } JCMT OCS

24. Engineering interfaces • Problems are detected by OCS when observation fails • Once a problem is isolated to a sub-system, they are diagnosed and worked around through engineering interfaces. • Existing front-ends and SCUBA will still have ICL command interface and terminal interfaces. • All future instruments and sub-systems will have purely Unix engineering interfaces. • New TCS interface will be based on UKIRT one - no VAX interface. JCMT OCS

25. Adding a new sub-system • Sub-system builders must provide: • JCMT OT component and iterator to define observations. • XML DTD and Schema to define configuration files. • Additional system configuration files to enable OT output to be translated into XML. • DRAMA and EPICS task(s) to control the sub-system • Must abide by OCS interfaces, including reading and parsing XML, control instrument and manipulate RTS. • Observing recipes and data reduction recipes and algorithms. • JAC will provide: • RTS interface hardware and software infrastructure. • Training and assistance in software development. • Assistance in providing new functionality to TCS, SMU etc. • Translator code. JCMT OCS

26. Bottom-up design