PVSS presentation, 23/1/04

Martin Koller from ETM

• New release: PVSS II 3.0, release date: end of March

• Enhanced functionality, among others....:

  • protection against port scans

  • improved redundancy (eg. can use redundant network links)

  • Improved UI (alarm + events) - alarms and events can be put on same (split-)window

  • Panel files can be imported/exported (?) using XML

  • enhanced trending (eg. pick up rectangle area with mouse etc)

  • SNMP driver (eg. for remote network interfaces)

• Language and functions:

  • config file reading

  • user authorization

• Scalability:

  • Can handle now up to 254 user interfaces

• Improved Linux port (?)

• Should be backwards compatible

• More info with regard to PLC, field buses, etc. No mention of 'Grid Driver'

Q: Oracle backend on Linux?

• Won't be part of release 3.0

• Release date: around summer, but beta should be available 'soon'

• Oracle backend is only for historical data. "Live" state data (alarms, events etc) is kept under control of the DM (Data Manager), using a propietary database (Rayma?)

Q: How could we use PVSS as an Alarm Display - reading collected data from an "foreign" Oracle database?

• EM (Event Manager) must be under control of the events/alarms. These are read from the GridDriver (or whatever other data collection driver is used) and then stored via the DM (Data Manager). The Data Manager does not access Oracle, but its own database - this access is opaque to the outside world.

• Natural way would be to use GridDriver which collects the data from the MSA's (our current setup)

• Theoretically possible to write a 'OracleDriver' which gets the data from Oracle ("why would you want this?"), but would cost more effort - writing back the alarms to Oracle is not considered.

• Oracle table structure?

Off-meeting discussion (German,  Harry,  Helge):

Should we continue with PVSS? Wait for summer time? Test the beta as soon as it comes out?

• Can we be sure that the Oracle backend will be there next summer? Already waited since last summer..

• What is the support level for the CCS specific modules? It took 3 months to fix a critical bug in their own software (memory leak in GridDriver)

• Can we continue to afford to simultaneously maintain two solutions?

• FIO position: PVSS is the fail-back solution, WP4/Lemon the production one

Proposal after discussion - to be endorsed by ELFms/Lemon team, then to be presented to FIO management:

1. Freeze PVSS activities

2. Concentrate on WP4/Lemon development and stabilization

3. At the time PVSS/Oracle is released, evaluate current status

1. Freezing PVSS: options

• Stop PVSS service, or

• let it running, without any maintenance, or

• automatize 'add/remove hosts' via HMS/SMS

2. WP4/Lemon development and stabilization: criterias (to be refined)

• Stability of OraMon both for data taking and data serving (internal and external clients)- investigate fail over / redundancy techniques

• Status of AlarmBroker: is it considered to be able to do the job?

• Status of AlarmGUI: Will need a technology review

  1. Evaluation of current prototype and feedback (Fabio)

  2. Alternatives to Java/Swing: Java/Eclipse, Qt, GTK, windows, web server based solutions...

3. Evaluation:

• Done around summer (to be precised)

• Not check current 'production' status of tools, rather evaluate if sustainable solution for the future - can remaining problems/issues be solved in a reasonable time frame (2004?)

• If the evaluation is negative, re-consider PVSS as a solution for AlarmDisplays and/or data collection / storage

German.Cancio@cern.ch, 29/01/2004