AO Controls: Status and Issues
Erik Johansson, Jimmy Johnson,
Doug Morrison and Ed Wetherell
NGAO PD Team Meeting #6
Thursday, March 19, 2009
Controls
•
•
Originally called non-RTC Controls --> renamed for simplicity
Controls encompasses “everything but the kitchen sink”: control of all
devices in the AO and Laser systems
– Motion control: control of all movable devices in the system
• All optical stages, shutters, etc.
• Does not include position control of deformable or tip-tilt mirrors
– Device control: control of all non-moving devices in the system requiring
computer control
• Environmental control
– Temperature, humidity, particulates
• Power control
• Camera control (setting parameters, not low-level CCD or focal plane control)
• DM and TT control
– Any control required not including mirror positioning commands, e.g., control of drive amplifiers,
mirror controllers, etc.
• RTC control: set up and operation of the RTC
• Laser system control
• Data server
– Acquisition, guiding, offloading and pointing control
– Instrument control: all coordination and sequencing required to use instrument
with NGAO system
– High level coordination and sequencing control of entire NGAO system
2
Major areas of effort
• Overall control system architecture
• Software architecture
• Sequencer design: Multi-System Command Sequencer (MCS), AO
Sequencer, Laser Sequencer
– Sequencers are main command processors and command sequencers
used to control the system
•
•
•
•
•
•
AO and Laser system SW design (SW not included in sequencers)
Motion control architecture
Motion control design, both HW and SW
Data server design
User interface design
SW standards document
3
Control system architecture
• Control system architecture and SW architecture are deeply
intertwined
• Distributed control system organized hierarchically
• Independent subsystems, but MCS is master
• Instrument does NOT control AO system and telescope
– Instruments in current AO system do this
– Troubleshooting is problematic
– Instrument should be a subsystem of the overall NGAO system
• Each subsystem has levels of control within it
4
Distributed control system
Science
Operations
Tools
Data Communications
Infrastructure
Instruments
AO System
Atmospheric
Tools
Laser Traffic
Control System
Laser System
Telescope
Interface
Data Server
5
Hierarchy of controls
Top level of control
Multi-System
Command
Sequencer
Atmospheric
Tools
Instrument
Sequencer
Telescope
Interface
User
Interfaces and
Tools
AO
Sequencer
Pre- and PostObserving Tools
Laser
Sequencer
LTCS
Cmd
Status
Telem
Data Server
Interface
Cmd
Status
Telem
Middle level of control
Acquisition,
Guiding and
Pointing Control
AO Control
Status
Laser Control
Data Server
Telemetry
Telemetry
Legend:
RT Diags
RT Diags
Non-Real-Time Commands and Data
Bottom level of control
Real-Time Commands and Data
Real-Time Diagnostic Data (high-speed)
AO
Devices
Real-Time
Controller
UTT
Laser
Devices
6
Software architecture
• SW architecture “views”
– Logical view
• Shows object decomposition
– Development view
• SW module organization
• Shows interaction of SW components
– Layered view
• Shows interaction of SW components in layered hierarchy
– Physical view
• Maps SW to HW
• Preliminary mapping during PD phase
• Full definition during DD phase
– Process view
• Shows SW decomposition to tasks, threads, processes
• This view will be defined during the DD phase
7
Logical view
StateMachineObject
-State Mappings
Health
+Transition()
Configurable
-ConfigurationID
Sequence Controller
+GetConfiguration()
+Initialize()
+Standby()
+Halt()
+Fault()
+Shutdown()
MSCS Sequencer
AO Sequencer
AGOP Sequencer
BaseObject
-ObjectID
+Identity()
+Middleware Interface()
-HealthTelemetry
-HealthID
+GetAlarmStatus()
+SetAlarmStatus()
+AcknowledgeAlarm()
+ResetAlarm()
+SetThreashold()
+GetThreshold()
+RegisterObject()
Timing Controller
-Resolution
+Rate()
Controller
Laser Sequencer
Software Timer
Timing Board
Motion Controller
Motor Controller
RTC Controller
-Limits
+Home()
+Position()
+Status()
+Power()
EnvironmentController
Sensor Controller
Camera Controller
-Partciulate Sensor
-Temperature Sensor
-Humidity Sensor
+Temperature()
+Humidity()
+Fan()
-Timing Controller
+GetCount()
+Calibrate()
+Expose()
+ExposureRate()
+On / Off()
+Waveform()
+Binning()
Particulate Sensor
Readback Camera
+GetPixelData()
Humidity Sensor
Temperature Sensor
AO Enclosure
+Cryo()
8
Development view (1)
Configuration GUI
Configuration
Data
MSCS
+Configuration Managment()
+Acquisition()
+Instrument Sequencing()
+Fault Detection()
+Fault Recovery()
+Command Interface()
AGOP System
Telemetry
Atmospheric Tools
Health Monitoring
Laser System
Telescope
AO System
MSCS Operator Interface
+Status()
Telemetry
Telemetry
Telemetry
Telemetry
Telemetry
+Offseting()
+Dithering()
+Nodding()
+Pointing()
+Offloading Tip-Tilt()
+Offloading Focus()
+Offloading Coma()
Instruments
LTCS
Legacy Interfaces
Data Server
Telemetry
+Publish()
+Subscribe()
Real Time Controllers
User Tools
-Observing Tools
Telemetry
9
Development view (2)
MSCS
Configuration
Data Server
AO Sequencer
DM Power Controller
AO System
Telemetry
Vibration Sensor
LSG WFS Camera
NGS WFS Camera
TTFA Camera
NGS Acq. Camera
LOWFS TWFS Camera
Tip-Tilt Sensor
RTC ? Driver
Driver
AO Environment Control
LGS WFS Controller
Humidity Sensor
Particular Sensor
Temperature Sensor
AO Cooling
Driver
Driver
Driver
Driver
Driver
LOWFS Controller
Pickoff Controller (x3)
Driver
ADC Controller
IF FSM Controller
ADC Controller (xN)
Driver
Driver
Driver
Driver
NGS FSM Controller
Focus Manager Controller
FSM Controller (x2)
?????
FSM Controller (x2)
Pickoff Controller (x3)
Driver
Driver
Driver
Driver
Driver
10
Development view (3)
MSCS
Configuration
Laser System
Telemetry
Data Server
Laser Sequencer
Laser Safety System
Point & Center Camera
Beam Quality Camera
Driver
Driver
Driver
Laser Environment Control
Humidity Sensor
Particular Sensor
Temperature Sensor
Driver
Driver
Driver
Constellation Rotator
Constellation Generator
Pointing Controller (x7)
Waveplate Controller (x7)
Switchyard Controller
Driver
Laser Steering Controller (x3)
Driver
Driver
Shutter Controller (xN)
11
Development view (4)
MSCS
Configuration
Data Server
AGOP System
Telemetry
Tip-Tilt Offload Controller
Coma Offload Controller
Guiding Camera
12
Layered view
•
•
•
•
Middleware is the SW that
implements the distributed control
system
Wire protocol is the
communications protocol used by
the middleware
Middleware API implements the
programmer interface to the
middleware
For example, in the Data
Distribution Service (DDS), DDS is
the middleware and Real-Time
Publish-Subscribe (RTPS) is the
wire protocol.
User Interface
Sequencer
Health
Monitoring
Utilities
Middleware API
Middleware Wire Protocol
13
Middleware evaluation
•
•
We are evaluating several
different middleware technologies
for use in NGAO
Evaluation topics:
– Services:
•
•
•
•
•
•
•
•
•
Logging
Data archiving
Alarming
Health monitoring
Configuration
Telemetry
Administration
Event support
User interfaces
– Language support
• Python
• Java
• C/C++
– Communication
•
•
•
•
•
•
Point to point
Multicast
Data support
Synchronous
Asynchronous
Publish-subscribe
– Application development
•
•
•
•
Inheritance
Loosely coupled
Location transparency
Type mapping
– Performance
• Evaluations on 3 PCs
• VMWare to easily switch between
environments
14
Middleware candidates
•
DDS – Data Distribution Service
–
–
–
–
•
ICE – Internet Communication Engine
–
–
–
•
CSF is main controls SW for ATST
ATST are happy to share CSF with us (free)
EPICS
–
–
•
From same group that developed CORBA
Open source (free)
Lots of tools available
Advanced Technology Solar Telescope (ATST) Common Services Framework
–
–
•
Uses a Publish-Subscribe paradigm
Is widely used in DoD, so is robust
Available from several vendors (RTI, PrismTech, Gallium)
DDS is an OMG standard
We are keeping EPICS as a fallback option
We will support (legacy) EPICS interfaces as required through bridges
Several other candidates have already been rejected:
–
–
–
–
TINE
TANGO
OpenDDS
OCERA (open source DDS)
15
Sequencer concept
• Command – response design pattern
– Encapsulates action, parameters, response
• Compound tasks (workflows) are straightforward to build
– Simple syntax will allow SAs to write scripts
• Thread pool to handle multiple asynchronous tasks
• Easy to build UI around
16
Motion control architecture
• KAON 643 Motion Control Architecture Study
– Devices fall into natural groupings based on location and control
complexity
– Want to match control complexity and cost to the device groupings
– No “one size fits all” solution
– Cabling will be a real challenge
– Architecture will likely be a combination of centralized and distributed
components
– We have taken into account the device reductions resulting from the
build-to-cost effort
• Main result is reduced device count  savings in I&T
• No group of devices completely eliminated  only modest savings in NRE
– We need more information:
• Finalization of device specs: speed, accuracy, payload weight, etc.
• Specs on thermal enclosure
• Device lifetime requirements
17
Device groupings
(0) Shutters
–
–
simple in/out devices with very loose positional requirements
actual position when moving is not required
(1) Low precision, non-tracking
–
–
moved during configuration, not during an observation
a dichroic or fold, for example
(2) Medium precision, non tracking
–
–
moved during configuration, not during an observation
aligning a fold (tip/tilt) or other component
(3) High precision, non-tracking
–
–
moved during configuration or acquisition, not during an observation
aligning a lenslet or focusing a unit
(4) Tracking
–
–
synchronized to external inputs, constantly moving
ADCs, rotators
(5) Extremely high precision (non)tracking
–
–
coordinated motion with other DOF(s), possibly tracking
Field steering mirrors, focus adjustment
(6) Pickoff arms - coordinated high precision (non)tracking
–
–
most demanding DOF, coordinated motion with other DOF(s), synched to external inputs
spatial position constraints, based on static and dynamic obstacles, to avoid collision
18
Spectrum of device types
Tracking Capabilities
Coordinated
Tracking
Type
6
Tracking
Type
5
Type
4
NonTracking
Type
Type
Type
Type
0
1
2
3
LOW
HIGH
Precision
19
Location of NGAO motion control devices
20
Distribution of devices in the NGAO system
Input/Relay 1 [12]
[1]
Hatch cover (x)
[1]
Vib Sensor Pickoff (x)
Vib Sensor Lenslet (x,y)
[2]
Vib Sensor Assly focus (z)
[1]
Calibration Source (x,y,z)
[3]
[1]
Input Image Rotator (θ)
[1]
Wyko shutter (x)
[2]
Wyko fold (x, y)
LGS WFS [31]
[3]
LGS WFS Unit Focus (z)
[3]
LGS WFS Unit rotation (θ)
LGS WFS Lenslet array (x,y)
[14]
LGS WFS Detector focus (z)
[4]
[6]
LGS WFS Pickoff (θ,Φ)
[1]
LGS WFS Assy focus (z)
Post Relay 1 [7]
[1]
IF Fold/dichroic (x)
[4]
IF Pointing & centering (x,y)
[1]
NGS Acquisition Fold (x)
[1]
NGS Acquisition Focus (z)
Low Order WFS [20]
[4]
LOWFS TT pickoff (θ,Φ)
[4]
LOWFS TT ADC (θ,x)
[2]
LOWFS TT unit focus (z)
[2]
LOWFS TWFS/TTFA pickoff (θ,Φ)
[2]
LOWFS TWFS/TTFA ADC (θ,x)
LOWFS TWFS/TTFA unit focus (z)
[1]
LOWFS TWFS lenslet (x,y)
[2]
[1]
LOWFS TWFS assy rotator (θ)
[2]
LOWFS TTFA lenslet (x,y)
NGS WFS [8]
[1]
NGS WFS Dichroic (x,z)
[4]
NGS WFS FSMs (x,y)
NGS WFS Lenslet (x,y)
[2]
NGS WFS Assy Focus (z)
[1]
Imagers [3]
[2]
NIR Imager ADC (θ,x)
[1]
NIR Imager ADC assy (x)
Laser System [56]
[7]
Laser Switchyard shutter (x)
[3]
Laser Polarization waveplates (θ)
BTO Centering mirrors (x,y)
[14]
BTO Pointing mirrors (x,y)
[14]
[7]
Shutter (x)
[6]
Laser Constellation steering (x,y)
[1]
Laser Constellation rotator (θ)
Laser Beam dump (x)
[1]
LTO Cover (x)
[1]
Type 0 - Shutter
Type 1 - Low precision, non-tracking
Type 2 - Med precision non-tracking
Type 3 - High precision non-tracking
Type 4 - Tracking
Type 5 - Coordinated tracking
Type 6 - Pickoff arms
[1]
LTO Polarization sensor (x)
Color Codes: Blue - Cooled AO bench, Green: Off-bench AO device,
Brown: Laser enclosure, and Gold: Telescope secondary.
Type 6 [12]
Type 5 [6]
Type 3 [37]
Type 2 [8]
Type 1 [4]
Type 0 [18]
Type 4 [52]
[1]
LTO Focus lens (x)
21
Motion control recommendations
•
Architecture:
– Centralized control for high-precision tracking devices
– Distributed control for other devices
•
•
•
•
•
•
•
•
•
Consider device multiplexing for type 0 devices to reduce control
infrastructure
Use smart motors for distributed control where possible. More analysis of
the thermal constraints is required.
Control components should be specified based on device requirements.
“One size fits all” will be too costly and may not be feasible.
HW selection should be done in collaboration with SW designers
HW should support maintenance and troubleshooting. Devices in cooled AO
bench should require minimum support.
Careful considerations must be taken to minimize EMI.
Use COTS controllers and packaging to reduce overall system cost.
Need better device specifications to proceed: Device Description Sheets.
Now is the time to begin collaborations with the design teams.
22
Issues
• Lack of information has been the biggest obstacle to date.
• Now that B2C effort is drawing to a close, it is time to begin closer
collaborations with the other design teams.
• We need as much information as possible on all the devices to be
used throughout the system.
• We will be calling to set up meetings/teleconferences to kick off the
process and envision many “working” conferences and calls in the
future.
23