1. Middle-tier servers for CMW Bartek Paszkowski AB-CO-FC

2. Outline  Overview  Requirements  Implementation  Current status

3. Outline  Overview  Requirements  Implementation  Current status

4. Overview  Project goal  Provide a solution based on CMW for Controls standard services (Alarms, Logging) that will decrease the load on Front End computers  Make a re-usable framework for CMW middle-tier servers to reduce their implementation cost  Target applications  Integration of PS equipment surveillance into GTPM  Integration of PS alarms monitoring into Laser  Data concentrator for Windows passerelle  Logging?

5. Architecture LHC Alarm Service Logging Service GTPM RDA HTTPJMS RDA Data collection Data treatment Data distribution MTS (middle tier server) LynxOS Front End

6. Outline  Overview  Requirements  Implementation  Current status

7. Requirements  “on change” subscription (GTPM, passerelle) or “on change” push (LHC Alarms Service) for virtual device/virtual property that minimize Front End load  Requirements of both LHC Alarms Service and Logging service need to be analyzed to provide additional functionality of Data Distribution layer (like polling mechanism)  Users should easily define virtual devices  Functionality adjustable through configuration files  Frequent use of creational patterns

8. Outline  Overview  Requirements  Implementation  Current status

9. Implementation  Data collection  Acquires data for given client (IOListener) from given I/O point (device/property/cycle selector)  Data acquired “on change”  Device represented by a device handle  Clients for one I/O point stored in one I/O subscription object  Device handles are retrieved from a device handle pool

10. Implementation  Data treatment  Calculates and stores value of a virtual property  Introduces virtual devices and virtual properties  Virtual device  is a set of virtual properties that can be monitored,  is created by virtual device builder that uses virtual device meta data  Standard way of creating virtual device meta data is by reading XML configuration file (standard virtual device builder). However other builders may be provided:  for GTPM virtual devices creation is based on database description (working set)  Virtual devices are retrieved from virtual device pool

11. Implementation  Data treatment  Virtual property  subscribes/unsubscribes for I/O points  stores data of base device/base property pairs for a subscribed cycle selector (I/O points) and provides business logic to calculate its value  Virtual property propagates calculated value for a subscribed cycle selector if at least one I/O point changed its value (however Data Distribution layer can poll this value)

12. Implementation  Virtual devices XML configuration file example

13. Implementation  Data distribution  Distributes data to end clients (GTPM, LHC Alarms Service,Logging Service)  Introduces MTS service along with subclasses (adapters) in order to interface with end clients  subscription for virtual device/virtual property for a given cycle selector is done either dynamically (GTPM, passerelle) or statically (based on XML configuration file) for LHC Alarms Service and Logging Service

14. GTPM example  Virtual device based on meta data retrieved from database (working set)  Virtual devices created statically (at start up time)  Each virtual device has only one virtual property – alarm counter, that counts non zeros alarms’ values

15. GTPM example MTS LIN:GTPM-BEAMST LI.STP01 RDA LynxOS Front End GTPM RDA Monitor LIN:GTPM-BEAMST.ALARMCOUNT GTPMService Value of virtual property that counts number of alarms is calculated data

16. Outline  Overview  Requirements  Implementation  Current status

17. Current status  Tests for GTPM this week  Additional design work to be done for LHC Alarms Service and Logging Service  Exceptions definition and handling…