1 / 17

Middle-tier servers for CMW

Middle-tier servers for CMW. Bartek Paszkowski AB-CO-FC. Outline. Overview Requirements Implementation Current status. Outline. Overview Requirements Implementation Current status. Overview. Project goal

bian
Download Presentation

Middle-tier servers for CMW

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. 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 GTPM Logging Service LHC Alarm Service RDA HTTP JMS MTS (middle tier server) Data distribution Data treatment Data collection RDA LynxOS Front End LynxOS Front End 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 <vdevices> <vdevice name='TST.ALARMDEV'> <vproperties> <vproperty name='ALARMCNT' class="core.properties.CounterVirtualProperty"> <base> <baseDevices> <device name='TST.DEV1' /> <device name='TST.DEV2' /> <device name='TST.DEV3' /> </baseDevices> <baseProperties> <property name='ALARM1' /> </baseProperties> </base> </vproperty> </vproperties> </vdevice> </vdevices>

  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 RDA Monitor LIN:GTPM-BEAMST.ALARMCOUNT data Value of virtual property that counts number of alarms is calculated RDA LynxOS Front End GTPM example MTS GTPMService LIN:GTPM-BEAMST LI.STP01 LI.STP01

  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…

More Related