1 / 29

Online Software

Online Software. November 10, 2009 Infrastructure Overview Luciano Orsini, Roland Moser Invited Talk at SuperB ETD-Online Status Review. Scope Motivation and Requirements Architecture Software Product Line Outlook Integrated web technologies Monitoring Errors and Alarms

hungate
Télécharger la présentation

Online Software

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. Online Software November 10, 2009 Infrastructure Overview Luciano Orsini, Roland Moser Invited Talk at SuperB ETD-Online Status Review

  2. Scope Motivation and Requirements Architecture Software Product Line Outlook Integrated web technologies Monitoring Errors and Alarms Generic Event Builder Configuration Management Conclusion Topics

  3. CMS DAQ System 40 MHz Collision rate Detectors 1 Terabit/sec50000 channels 100 kHz output from trigger 500+500 ports switching fabric ~800 Gb/sec full connectivity 10 TeraOpsprocessing cluster 100 Mbytes/sec output toPetabyte archive

  4. Context Diagram Run control software Online software Detector Control System software High-level trigger software

  5. Motivation • CMS consists of a set of sub-projects • Similar to a coordinated set of small experiments • Many scenarios: central DAQ, subdetector DAQ, testbeams, • Geographically dispersed participants • Autonomous developments • High personnel turnover • High performance requirements • Long lifetime and need to survive technology generations • Similar tasks to be performed in each sub-detector

  6. Functional Requirements (TDR) • Communication and Interoperability • Transparent use of communication protocols • Possibility to add new protocols • Concurrent use of multiple protocols • Device Access • Access to custom devices • Hardware abstraction layer • Configuration, control and monitoring of applications • Inspect and modify simple/complex parameters • Allow coordination of application components • Record structured information • Uniform logging, error reporting, monitoring • Interface to persistent data stores

  7. Non-Functional Requirements (TDR) • Maintainability and Portability • Portability across operating system and hardware platforms • Add new electronics without functional changes in user software • Application code shall be invariant with respect to the physical location and the network • Encourage working with re-usable building blocks

  8. Scalability • Scalability • Operate within requirements if size or volumes change • Take advantage of additional resource availability • Overhead introduced by the software environment must be constant for each transmission operation and small with respect to the underlying communication hardware in order not to introduce unpredictable behaviour linear good within requirements Performance bad System size

  9. Architecture Foundation Uniform building block One or more executives per computer contain application and service components XML Configuration Executive Application Components HTTP SOAP I2O/ B2IN Fast control and data Control and GUI Service Plug-ins Custom device access Devices

  10. Architecture Foundation (II) Replicated building blocks Scalable cluster system architecture Executive Executive Executive Executive

  11. Software Distribution coretools powerpack worksuite Core framework Reusable applications CMS specific applications

  12. Layered View Online Software Worksuite Event Builders Front-end Controllers External System Interfaces Detector Specific Applications Powerpack Data Monitoring Error and Alarming Job Control User Interfaces Configuration Management Support Coretools OS Abstraction Executive Framework Hardware Access Communication Subsystems Platforms Operating Systems Networking Infrastructures Hardware Device Interfaces

  13. Timeline Well consolidated after eight years of development and use 2008 2006 2004 2002 2000 Commissioning and first beam event successfully achieved XMAS – monitoring, orthogonal to applications XDAQ 3 –experiment wide adoption XDAQ 2 – Web enters DAQ (SOAP) First version of XDAQ - I2O communication kernel Need for common platform arises (3 operating systems, many different develoments)

  14. Outlook • Integrated web technologies • Monitoring • Errors and Alarms • Generic Event Builder

  15. HyperDAQ • Access through embedded HTTP • Navigate and inspect the whole cluster

  16. HyperDAQ (II)

  17. HyperDAQ (III)

  18. Data Monitoring Concept

  19. Scalable Architecture

  20. Flashlist Viewer

  21. Errors and Alarms Coloured if subtree has errors Acknwoledge errors and alarms In selected subtree of model Alarms/acknowledged

  22. Errors and Alarms (II)

  23. Generic Event Builder • Configurable in size and network technology • Customization at boundaries through pluggable components Trigger Readout specific software component Readout unitcomponents Event Run Builder Networks Manager Control Builder unitcomponents High-Level Trigger/Event filter services

  24. Configuration Management • Identification • definition of packages • versioning • Traceability • Status accounting • Documented change history • Tickets • Planning • Milestones • Priorities, People • Release • Source and binary releases • Parallel releases • Upgrades

  25. Configuration Management Tools WEB Services E-Groups

  26. Parallel Releases

  27. Change Process Workflow

  28. Roadmap

  29. Conclusion • Building a DAQ system as a process of assembly re-usable componentsin a predetermined way rather than a programming task. • Achieved a uniform DAQ product-line for all CMS data acquisition application scenarios ranging from single CPU setups to the final systems comprising thousands of nodes. http://cern.ch/xdaq

More Related