1 / 8

The aLIGO Guardian

The aLIGO Guardian. Jeff Kissel, for the ISC, SEI, SUS, etc. teams. Motivation. iLIGO Experience: Operators/Commissioners had to manage many control systems, but many components were passive

val
Download Presentation

The aLIGO Guardian

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. The aLIGO Guardian Jeff Kissel, for the ISC, SEI, SUS, etc. teams J. Kissel, NSF Review 2013

  2. Motivation • iLIGO Experience: Operators/Commissioners had to manage many control systems, but many components were passive • aLIGO has many more control loops/sensors/actuators – “modules” – of which to keep track; too difficult for one operator to manage • BUT many aLIGO modules are will be controled/managed identically • Design modular control systems to be in well-defined and verifiable states, which can then be managed hierarchically • Inspired by the VIRGO and GEO experience • Natural evolution from operation “by-hand,” to low-level scripts, to an organized well-tought-out infrastructure • Not a necessary deliverable for aLIGO, but essential for long term, robust, repeatable operation – particularly by non-experts J. Kissel, NSF Review 2013

  3. Guardian Principles • NOT responsible for protection, only reporting, verifying, and transistioning between states (“Guardian” is a mis-nomer) • Module Guardian: the lowest level state machine, directly controls a given component that can be treated identically (e.g. a Triple Suspension, or HAM-ISI) • Manager Guardian: the “puppet master” that merely demands modules be in a given state, based on upper level manager or human requests J. Kissel, NSF Review 2013

  4. Module Examples QUAD Suspensions HAM-ISIs J. Kissel, NSF Review 2013

  5. Manager Examples (The Interferometer Sensing and Control System) - Knowledgable about how modules must interact - Does not want/need to know anything about the modules other than they are aligned and in their lowest noise state J. Kissel, NSF Review 2013

  6. The Highest Level Organization Modules J. Kissel, NSF Review 2013

  7. Module (HAM Triple Suspension) Manager J. Kissel, NSF Review 2013

  8. Progress Thus Far… • First article infrastructure created at MIT • Prototype module systems developed at MIT (SUS) and Stanford (SEI) using representative hardware • L1 Input Mode Cleaner Integrated Test Phase included prototype of IMC Manager Guardian • Very new (last week!): face-to-face meeting of subsystem leaders on the Guardian We’ve had enough prototyping that we can now really: • Define Requirements • Define common goals and infrastructure • Software infrstructure can begin to be absorbed by CDS / Software Engineers • Establish “czar” to ensure commonality and smooth interactions at the manager level All of which we accomplished/has begun J. Kissel, NSF Review 2013

More Related