Download presentation
Presentation is loading. Please wait.
Published byFay Holland Modified over 8 years ago
1
DIAMON Project Project Definition and Specifications Based on input from the AB/CO Section leaders
2
25 jan 2006AB/CO/TC - P.Charrue Goal of this presentation Present the DIAMON project Purpose, Scope, Objective List the deliverables Propose a calendar Present major requirements No discussion on technical implementation (wait for TC 1st March 2007)
3
25 jan 2006AB/CO/TC - P.Charrue Definitions Two separate concepts Monitoring => Continuous snapshot Diagnostic => Towards recovery of the problem GUIs Central Logger Monitored items MONITORING DIAGNOSTIC
4
25 jan 2006AB/CO/TC - P.Charrue Monitoring => Continuous snapshot Periodic monitoring of the infrastructure Runs locally to the system under monitoring Performs a well defined set of tests Tests are analyzed against rules which define “normal behaviour” Summary results pushed to central processing Monitor: Background processes (servers, tasks, daemons) Front Ends Back Ends Consoles FieldBuses PLCs GUIs Central Logger Monitored items MONITORING DIAGNOSTIC
5
25 jan 2006AB/CO/TC - P.Charrue Diagnostic => Towards recovery of the problem Tool for ‘post-mortem’ Collection of specialists diagnostic utilities Provide access to statistics of the behavior of the infrastructure Get more details on a problem Provide help to solve a problem GUIs Central Logger Monitored items MONITORING DIAGNOSTIC
6
25 jan 2006AB/CO/TC - P.Charrue Purpose of DIAMON Propose tools to monitor the AB Controls infrastructure with easy to use first line diagnostics and tools to solve problems or help to decide about responsibilities for first line of intervention Operators, Equipment Groups and Controls Experts are the target group
7
25 jan 2006AB/CO/TC - P.Charrue Scope Around 3’000 items in the AB Controls Infrastructure are eligible to be monitored : Devices connected to Ethernet (PLCs, VME or PC FrontEnds, File and Application servers, Consoles). High level applications, daemon and servers (e.g. LSA, LASER, SIS, PIC, CMW, …) As the monitoring interface will be publicly available other items owned by equipment groups may also be monitored in the DIAMON project
8
25 jan 2006AB/CO/TC - P.Charrue Deliverables A standard interface for sending monitoring results A central repository of these results A common visualization tool offering many different views of the controls infrastructure (by name, by accelerator, by sub-systems, by building, …) A standard look & feel interface for the diagnostic tools GUIs Central Logger Monitored items MONITORING DIAGNOSTIC
9
25 jan 2006AB/CO/TC - P.Charrue What is available today clic/Clogger/Xcluc suite for the ‘classic’ controls infrastructure (MON and DIAG) LASER (MON and DIAG) PVSS for PLC and industrial infrastructure (MON and DIAG) Several ‘private’ tools (CMWadmin, viewDB, FESA admin, FIPMon, MA section suite of diagnostic tools, TIMDIAG, …) (mainly DIAG) Some initiatives for a new tool Cyan Jaguar, JCluc, JMS prototype of clic/Clogger, FIP integration, …
10
25 jan 2006AB/CO/TC - P.Charrue Requirements - Monitoring A local periodic agent running in the lowest possible place This agent should not hamper the normal operation Executes well defined list of test and builds a résumé to be sent to a central logger Analysis of the results is done in the lowest possible place The GUI must propose different views : Geographical, by sub-systems, by accelerator, …
11
25 jan 2006AB/CO/TC - P.Charrue Requirement - Monitoring The monitoring interface will be made public to be used by other client software Alarm generation and automatic SMS Configuration of the tests could be extracted from the configuration DB FESA specific device for monitoring? TBD Should Monitoring make Logging? TBD Should it use the LASER infrastructure? TBD
12
25 jan 2006AB/CO/TC - P.Charrue Requirement - Diagnostic Diagnostic tools should be launched by the monitoring GUI or available directly Standard look&feel has to be defined to ease their usage The monitoring GUI should ‘select’ the most appropriate diagnostic tool Training the operators to these tools is essential RBAC could be used to ‘protect’ some actions Configuration of the tool could be extracted from the configuration DB.
13
25 jan 2006AB/CO/TC - P.Charrue Domains Backends, FrontEnds and Consoles PLCs and industrial world FieldBus CMW, Logging, Timing, FESA, LASER (?) infrastructure Application Software daemons (WebServers, DB, 3-tier servers)
14
25 jan 2006AB/CO/TC - P.Charrue Resources Each system is responsible for its own monitoring Each system is responsible for its own diagnostic tool The communication, central repository and graphical visualisation tools are under the project responsibility Idem for the standard interfaces for monitoring and diagnostics
15
25 jan 2006AB/CO/TC - P.Charrue Proposed Calendar End January 2007: Subsystems defined and main requirement collected End February 2007: Decision on architecture and technology following an evaluation of present tools (mainly LASER) March 2007: Standard monitoring interface defined May 2007: First vertical slice prototype Mid-2007: Standard diagnostic look&feel proposed LHC startup (October 2007) : Aim for a first operational version
16
25 jan 2006AB/CO/TC - P.Charrue Conclusion Monitoring and Diagnostic are two different concepts Several tools for diagnostic already exists The main requirements are defined The formal URD is now to be written The technical implementation study will be presented here 1st March Implementation via LASER has to be studied Need to assign resources from all systems to implement and maintain the DIAMON
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.