1 / 48

JCMT Observatory Control System

JCMT Observatory 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)

gracep
Download Presentation

JCMT Observatory Control System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  27. JCMT OCS

  28. ACSIS Hardware (Right Nasmyth) • BITE module • Nasmyth switch (replaces the IFS) JCMT OCS

  29. ACSIS Hardware (Carousel Floor) • 32 DCMs (Down Converter Modules) • 4 Local Oscillators • Eight correlator processors each controlling 4 correlators • IF Control processor • Can read 32 total power sensors • 1 Gbit Ethernet switch JCMT OCS

  30. Additional JAC Hardware • Real Time Sequencer (RTS) computer under right nasmyth stairs. JCMT OCS

  31. ACSIS Hardware (Computer Room) • 1 Gbit Ethernet switch • Linux machine cluster (8 or 16 machines) to process the data from the correlators. • Linux machine for data display JCMT OCS

  32. Hardware Being Replaced • DAS • CBE • IFS • SMU tables and chopper microcomputers • IFD JCMT OCS

  33. JCMT OCS

  34. Software Being Retained • PTCS (has been modified to work with the OCS) • RxA, RxB and RxW “D” tasks • SCUBA JCMT OCS

  35. Software Being Replaced • ICL • All SMU software • All back end software • Weather task (working prior to ACSIS) • Much of the work previously done in the frontend “D” tasks will be done in the frontend wrapper tasks • Data Handling System software • Data reduction software • Real time display software JCMT OCS

  36. JCMT OCS

  37. JCMT OCS

  38. JCMT OCS

  39. JCMT OCS

  40. JAC Responsibilities • JCMT sequence console (Russell Kackley) • JCMT Observation Sequencer. These are the observation recipes themselves. (JOS) (Russell Kackley / Craig Walther) • Secondary mirror unit control tasks (SMU) (Craig Walther) • Front end wrappers (FE_A, FE_B, FE_W) (Firmin Oliveira) JCMT OCS

  41. JAC Responsibilities • Portable Telescope Control System OCS modifications (PTCS) (Russell Kackley) • Real Time Sequencer (RTS) (Craig Walther, Xiaofeng Gao) • Environment monitoring task (ENVIRO) (Matt Rippa) JCMT OCS

  42. DRAO Responsibilities • Correlator tasks (CORRx) (Gary Hovey) • IF Controller (Gary Hovey) • Monitor Tasks (CORRx_MON, BEAM_POS_MON, IF_MON, FE_MON, ENVIRO_MON) (Tony Willis) • Synchronization tasks (SYNCx) (Tony Willis) JCMT OCS

  43. ATC Responsibilities • Data reduction tasks (DR recipes) (John Lightfoot) JCMT OCS

  44. More DRAO Responsibilities • Data gridder task (Tony Willis) • Data displays (Tony Willis) • Strip chart display • Spectrum display • Image display JCMT OCS

  45. Benefits • Simple, easy to understand (and change) observing recipes. • Much more functionality in TCS and SMU (easy to define complex SCUBA2 observing patterns - and avoids the SCUBA “big lump”). • Impossible to control ACSIS any other way - ACSIS is basically a kit of parts, we need to control it. • Ability to simultaneously process the 16 HARP-B receptors • Increased bandwidth (ACSIS samplers run at 2 GHz) • Is being designed to control SCUBA2 as well as heterodyne instruments JCMT OCS

  46. Benefits • Efficiency • largely automated observing • Sub-second coordination through the RTS will lead to greater accuracy and higher efficiency • Reliability and quality control • observing is performed in a well defined way. • Maintainability. • Much higher understanding of how system is coordinated • Compliance with the “JAC basic software requirements” • Most of software running on Vaxes will be obsolete • Ease of use during engineering. • Less dependence on entire system being up to while working with a portion of it • Better connection management JCMT OCS

  47. Questions (threats, abuse etc)

More Related