1 / 22

LAFS Update

LAFS Update. Dave McGinnis Fermilab April 18, 2007. Introduction. LAFS = LHC at FNAL Software LAFS is a part of LHC@FNAL LAFS consists of a core group of 14 Fermilab* people 8 computer professionals 6 accelerator physicists LAFS immediate goal is to provide software support for the LHC

terris
Download Presentation

LAFS Update

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. LAFS Update Dave McGinnis Fermilab April 18, 2007

  2. Introduction • LAFS = LHC at FNAL Software • LAFS is a part of LHC@FNAL • LAFS consists of a core group of 14 Fermilab* people • 8 computer professionals • 6 accelerator physicists • LAFS immediate goal is to provide software support for the LHC • With a long term view to be involved in the commissioning and operations of the LHC • LAFS is mutually beneficial to CERN and Fermilab • We provide CERN with a valuable software service • In return, we are trained on LHC control system so that we are poised to make valuable accelerator contributions to the LHC in the future Note: Membership not restricted to Fermilab employees LAFS Update - LARP Collaboration Meeting - McGinnis

  3. LAFS Management • Although we are part of LHC@FNAL, we view ourselves as a software team working for CERN’s Accelerator and Beams Department Controls group (AB/CO) under the direction of Hermann Schmickler • We have an MOU • We follow all the CERN requirements for software engineering • Programming language and environment • Documentation • Look and Feel • Etc. • We view our main customer is Accelerator and Beams Department Operations group (AB/OP) in which our main contact is Mike Lamont • At Fermilab • LAFS reports to the head of LHC@FNAL (Erik Gottschalk) • Is lead by Dave McGinnis with Jean Slaughter as deputy • Has three project leaders • Suzanne Gysin • Elliott McCrory • Jim Patrick • Our goal is to have a constant presence at CERN • Suzanne Gysin (October 1, 2006 – July 1, 2007) • Dennis Nicklaus (Summer 2007) • Elliott McCrory (August 1, 2007 – August 1, 2008) LAFS Update - LARP Collaboration Meeting - McGinnis

  4. LAFS Projects • We are involved in 10 projects • Each project will have a leader and a contact at CERN • With the exception of RBA which is well underway, most projects are currently involved in writing requirements documents • LAFS Projects • Role Based Access Control (S. Gysin) • Sequencer Development (J. Patrick) • Instrumentation Applications • Tune Measurement (J. Patrick) • Wire Scanners (E. McCrory) • Synchrotron Radiation Monitor (D. Nicklaus) • Microwave Schottky Monitor (J. Patrick) • Residual Gas Monitor (E. McCrory) • Beam Profile Fit Library (E. McCrory) • Drag and Drop Display Builder (Synoptic Display) (T. Bolshakov) • Sequenced Data Acquisition (on hold) (E. McCrory) LAFS Update - LARP Collaboration Meeting - McGinnis

  5. LAFS-CERN Visits • S. Gysin -> CERN, October 2006 • P. Charrue & E. Hatziangeli -> Fermilab, November 15-17, 2006 • E. McCrory -> CERN, November 13-17, 2006 • G. Kruk -> Fermilab, December 12-15, 2006 • LHC Java Application Development Training Class • Over 10 Fermilab people enrolled • Huge Success!!! • J. Patrick & D. McGinnis -> CERN, February 14-20, 2007 • J. Annala, D. Still, B. Hendricks -> CERN, March 19-23, 2007 • D. Nicklaus-> CERN, March 26 – April 2, 2007 • E. McCrory ->CERN, March 26 – April 9, 2007 • A. Petrov & C. Schumann -> CERN, April 10-20, 2007 • P. Charrue & E. Hatziangeli -> Fermilab, April 17-20, 2007 LAFS Update - LARP Collaboration Meeting - McGinnis

  6. RBAC is software to prevent An ignorant person from doing anything, anytime. Login using NICE user name and password. No login required in CCC, critical applications being the exception Timeouts A well meaning person from doing the wrong thing at the wrong time. Access is determined by: role, location, mode, and application Logging What is a ROLE? A role is a job function within an organization.Examples: LHC Operator, SPS Operator, RF Expert, BPM Developer … Roles are defined by the instrument designers in a security policy. A user may have several roles What is beingACCESSED? CMW devices which map to physical devices (power converters, collimators, kickers, etc.) What TYPE of access? get: the value of a property once monitor: the property continuously set: the value of a property Role Based Access Control (RBAC) S. Gysin LAFS Update - LARP Collaboration Meeting - McGinnis

  7. RBAC Organization RBAC team leader (S. Gysin - FNAL- LAFS) reports directly to AB-CO-IN section leader (P. Charrue) Development: • Authorization – K. Kostro AB-CO • CMW - W. Gajewski AB-CO • RBAC server - S. Gysin FNAL-LAFS • Authentication – A. Petrov FNAL-LAFS • Database – M. Peryt AB-CO • LSA – G. Kruk AB-CO • JAPC – R. Gorbonosov AB-OP LAFS Update - LARP Collaboration Meeting - McGinnis

  8. Participation in Requirements and Design • Requirements: • Prepared by: • S. Gysin FNAL/ LAFS • K. Kostro AB/CO • G. Kruk AB/CO • M. Lamont AB/OP • S. Lueders IT/CO • W. Sliwinski AB/CO • P. Charrue AB/CO • Checked by: • J. Wenninger AB/OP • S. Page AB/PO • E. Hatziangeli AB/CO • V. Kain AB/OP • K. Hanke AB/OP • R. Schmidt AB/CO • R. Steerenberg AB/OP • Approved by: • P. Collier AB/OP • H. Schmickler AB/CO • R. Bailey AB/OP • S. Myers AB • Design: • Prepared by: • P. Charrue AB/CO • V. Baggiolini AB/CO • W. Gajewski AB/CO • S. Gysin FNAL/ LAFS • V.Kain AB/OP • K. Kostro AB/CO • G. Kruk AB/CO • R. Gorbanosov AB/CO • S. Page AB/PO • A. Petrov FNAL/LAFS • W. Sliwinski AB/CO • N. Stapley AB/CO • Design: • Checked by: • E. Hatziangeli AB/CO • K. Hanke AB/OP • M. Lamont AB/OP • S. Lueders IT/CO • R. Schmidt AB/CO • R. Steerenberg AB/OP • J. Wenninger AB/OP • Approved by: • P. Collier AB/OP • H. Schmickler AB/CO • R. Bailey AB/OP • S. Myers AB LAFS Update - LARP Collaboration Meeting - McGinnis

  9. Application RBAC • RBAC Token: • Application name • User name • IP address/location • Time of authentication • Time of expiry • Roles[ ] • Digital signature (RBA private key) CMW client CMW server Access MAP FESA RBAC High Level Design A1: • User requests to be authenticated. • RBAC authenticates user via NICE user name and password or CERN certificate • RBA returns token to Application A2: • Application sends token to CMW when connecting. • CMW/FE verifies token signature once, and uses the credentials for every subsequent request • CMW checks access map for role, location, application, mode LAFS Update - LARP Collaboration Meeting - McGinnis

  10. RBAC Slice Test Summary • Status: • Working on production release • Vertical Slice Test Complete January 18 • RBA Review Feb. 16 • Successfully executed the vertical slice test for RBAC on January 18 and 19, 2007. The purpose of the test was to verify the design concepts and roughly measure the overhead. We wrote seventeen tests to verify • Authentication with an LHC software application via NICE username and password • Checking the permissions to set/get a device property for the role obtained in the first step. The tests also included the generation, storage, and distribution of the public and private keys for the digital signature and its verification. • We tested on Windows and Linux, and used the BPM properties to test the permissions. • All tests passed. Our timing measurements showed that the time it takes to authenticate on Windows or Linux is about 970 ms. The average time to verify a token is 2.3 ms, and the average time to check an access permission is 2.2 ms. The 2.2 ms to check the access permission are part of a command that took about 600 ms to execute, the RBAC overhead is between 0.5 -1% of the total command time. • The test included code for authentication written by Andrey Petrov (FNAL), authorization software in Controls Middle Ware by Wojciech Gajewski, EquipState modifications by Agnieszka Chabrowska and Greg Kruk, JAPC modifications by Roman Gorbonsov, and new authorization code written by Suzanne Gysin. In total, we added about 30 Java classes to the repository, plus the CMW C++ code. • We concluded the design concepts are valid, the added overhead is acceptable, and we can continue with the current design and develop the production <<RBAC_TestReport_070118.doc>> n version of RBAC. LAFS Update - LARP Collaboration Meeting - McGinnis

  11. RBAC Review – February 16, 2007 LAFS Update - LARP Collaboration Meeting - McGinnis

  12. LHC Sequencer Development (Patrick) • Automates the very complex sequence of operations required to operate the LHC. • Typical commands • Set, get, check devices • Wait for conditions • Execute more complex operations • Start regular programs • Start plots • Send data to shot log • Step through commands • Stops on error • Allow restart at failed command • Sequencer is used for: • Normal operations • Studies or special cases • Working with CERN on requirements LHC State Diagram LAFS Update - LARP Collaboration Meeting - McGinnis

  13. Sequencer Development • Jerry Annala, Brian Hendricks and Dean Still traveled to CERN on behalf of the LAFS sequencer group to collaborate on the LHC sequencer design and development. • During this time we met with Reyes Alemany, Mike Lamont, and Vito Baggiolini and joined various meetings and discussion centered around the current and projected LHC sequencer work. • This also involved a demonstration of the current and proposed Hardware Commissioning (HWC) Sequencer and the LHC Sequencer. • Presented with work currently being developed for a proposed states machine that will be capable of interfacing to the sequencer. • Joined the two meetings that discussed the interactions between the LHC sequencer and the BLM and collimator systems. • Developed a summary of our involvement along with comments and recommendations for continuing progress and development directed at the LHC sequencer work. • Not ready for public release LAFS Update - LARP Collaboration Meeting - McGinnis

  14. Summary of Sequencer Collaboration • Reviewed the different versions of the sequencer.  • Evaluated the design choices using the requirements document generated by CERN. • Evaluated CERN’s proposal on implementing a finite state machine engine.  • Encouraged them to continue with the development. • Encouraged sequencer team to begin detailed meetings with each subsystem group to begin the documenting and specifying the communications needed between the subsystems and: • sequencer, • Finite State Machine engine, • timing system, • etc. LAFS Update - LARP Collaboration Meeting - McGinnis

  15. Tune Measurement Requirement Document LAFS Update - LARP Collaboration Meeting - McGinnis

  16. Tune Measurement Prototype Waterfall/Slice Display LAFS Update - LARP Collaboration Meeting - McGinnis

  17. Wire Scanner Requirements Example LAFS Update - LARP Collaboration Meeting - McGinnis

  18. Synchrotron Light Monitor Requirements Example LAFS Update - LARP Collaboration Meeting - McGinnis

  19. Drag and Drop Controls Display and Builder(Synoptic Display) • For rapid development, the system expert (operator, engineer, or physicist) should be the one to develop the displays or applications • These advanced control systems can seem overwhelming to non controls experts. • This is why Lab View is so popular • However Lab View offers little of the benefits of an advanced control system. • Drag and Drop is an environment that gives non-control system experts the ability to quickly build controls displays which operate inside the control system framework. • Drag and Drop: • is easy to use • sophisticated enough to handle complex displays • operates inside the control system framework. • uses web browsers and/or Java Web Start (requires no extra software installation) • is easily extendible • is a mature application • Developed in 2001 • Fermilab Cryogenics department are heavy users

  20. Demo – Builder, Meson Compressor Room

  21. Demo – Display, Meson Compressor Room LAFS Update - LARP Collaboration Meeting - McGinnis

  22. Summary • Since its inception 7 months ago LAFS has grown rapidly. • Now has a core group of 14 Fermilab people • 8 computer professionals • 6 accelerator physicists • Involved in 10 projects • Ranging from a mature project such as RBAC to new ideas such as Drag and Drop • LAFS immediate goal is to provide software support for the LHC • With a long term view to be involved in the commissioning and operations of the LHC • LAFS is mutually beneficial to CERN and Fermilab • We provide CERN with a valuable software service • In return, we are trained on LHC control system so that we are poised to make valuable accelerator contributions to the LHC in the future LAFS Update - LARP Collaboration Meeting - McGinnis

More Related