Courthial, J

Epting, U

Martini, R

Ninin, P

Pesard, C

Sollander, P

CERN Document Server

THE TECHNICAL SUPERVISION INTERFACE: A JAVA BASEDSYNOPTIC VIEW ENVIRONMENTP. Sollander, J. Courthial, U. Epting, R. Martini, P. Ninin, C. Pesard, CERN, Geneva, SwitzerlandAbstractThe development of high-level synoptic views forsupervision of the technical infrastructure at CERN isbecoming increasingly important.  Synoptic views aretraditionally used by the control room as a means ofsupervising remote equipment but are also becoming ofincreasing interest to the equipment owners themselvesas the computing power and network connectivityavailable in offices and homes permit the use of theseviews.  The use of common synoptic views facilitatescommunication between control room operators andequipment specialists and helps to limit the amount ofdevelopment required.  In addition, the development ofsynoptic views is better done by the control roomoperators and equipment specialist than by a computerscientist.  The Technical Supervision Interface (TSI) isbuilt to meet the new requirements of users.  It willprovide a Java applet viewer that can download synopticview files from a web server and connect to any datasource through a standardized protocol.  The client-server communication will be done via a standardizedevent driven data acquisition protocol implemented oneach data source type.  This document describes therequirements, the design and the implementation of theTechnical Supervision Interface.1  INTRODUCTIONCERN's Technical Control Room (TCR) is todayusing some 700 mimic diagrams developed with a toolknown as the Uniform Man Machine Interface (UMMI).The UMMI tool was created in 1990 for use on controlroom workstations.Over time, change requests have been made and newusers like equipment groups want to use the tool.  Morerecently, the TCR has introduced the Technical DataServer (TDS) [2] as a common data source for thedifferent types of data clients: alarm screens, datalogging and mimic diagrams.  The TDS may be seen as areal-time database containing the equipment states towhich the client may subscribe and receive changes asthey appear.In order to implement new user requirements,interface to the TDS properly and to prepare for theLHC, we decided start a project to replace the UMMI.A new tool should take advantage of recent visualisationtechnology, implement an appropriate client to thepublish-subscribe mechanism of the TDS and take intoaccount feedback on the previous tool.2  SPECIFICATIONS FOR A NEW TOOLUser interviews were conducted with most of thecurrent users of the UMMI and with potential users of anew system. The resulting user requirements document(URD) [3] was analysed and the following concepts wereseen as important features for a new sy•stem.Object-oriented graphics and symbols.  -- Objectcreated must be completely independent andshould contain everything they need to be run.Data should be device oriented rather than tagoriented.• Standard Symbols.  -- Many symbols; pumps,valves, etc. are the same in many views. There is areal interest in standardising these symbols largelyin terms of colour use and symbol shapes.Standard symbols ease development and provide ahomogeneous operational environment for theoperator.• Flexible navigation.  -- The tool should permittotally flexible navigation in the hypertextfashion.  We can forget the notion of application ifwe can make hyperlinks between views.  Eachuser may set up his own "application" byorganising a list of  "bookmarks" to his views.• Event driven data acquisition.  -- This is aninherent feature of the TDS that the TSI mustmake use of.• Open architecture.  -- Not all data comes from theTDS.  The TSI will define an opencommunications protocol that can be used byfuture data providers.• Platform independent user interface.  -- Userswant to access views from control rooms, offices,their homes and firemen want access from theroad.  However, performance must be optimisedfor control room users.• Simplified view design.  -- The creation of a viewshould not need any programming.  Any usershould be able to design his views simply byselecting the equipment he wants to supervisefrom a list and place them on a screen in the wayof a graphics editor with predefined symbols.International Conference on Accelerator and Large Experimental Physics Control Systems594International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italy3  A NEW SUPERVISIONARCHITECTUREThe analysis of the requirements in the SRD [4]indicated the type of solution we should look into:• Multi-platform requirements imply platformneutral views in a centralised view repository.• The view editor needs an interface to aconfiguration database: to have direct access tothe available equipment descriptions.• Event driven data acquisition is clearly anobjective of the system.  De-coupling the dataacquisition and the data display will open thesystem to any data source, while also keeping theevent driven concept for optimal performance ofthe user interface. The TSI must provide thenecessary self-tests to ensure that thecommunication channels are available and notifythe operator should they become unavailable.In the Software Requirements phase of the project, webuilt a logical model [Figure 1] with the followingentities:• View editor: The graphics editor used to createthe mimic diagrams and their dynamics.• View repository: The common repository for allviews.• Configuration database: An off-line databaseholding descriptions of the equipment parameters(tags) that may be supervised by a TSI view.• Viewer:  The software running on the client side.It is capable of loading a view from the viewrepository and connecting to the necessary dataservers in order to subscribe to data. It may beimplemented in a web browser.• Data Source Adapter (DSA): Entity that givesaccess to a specific data source through apredefined standardised protocol.• Data Server (DS): Entity that dispatchesmessages from Data Source Adapters to theviewers and vice versa.  It manages one or moreDSAs and works like a data switch or a datamultiplex.  Its role is to permit simultaneousaccess to different data sources and to de-coupledata source specific information (tag names,addresses) from the views.4  THE DESIGN OF A PHYSICAL MODELA market survey was performed in Autumn 1998 tofind a suitable commercial product for the TSI project.Six different products that fit the requirements wereidentified.  They were products of very different size andscope ranging from complete SCADA systems includingcommunication drivers to simple drawing editors withassociated run-time software.View EditorViewerTTT Data ServerDSADSAView repositoryTDSDS ?DatabaseFigure 1: The logical modelThe product chosen for the first TSI implementation isthe product SL-GMS from the company Sherrill-Lubinski.  It was chosen considering the followingarguments: it has an appropriate scope (only drawingeditor and run-time engine), it is a well-establishedproduct that has existed for several years and the HP-UXrun-time engine is being complemented with a Java run-time engine that will be used for view access fromoffices and homes.The in-house development needed for a TSIimplementation using SL-GMS comprises a tag selectiontool for the graphics editor, the data server (DS) and onedata source adapter (DSA) for the technical data server.There are several possible ways to distribute the abovemodules (Viewer, DS, and DSA) on the physicalmachine in the control environment.  After studying thetwo main architectures; "Thick client", where the clientapplication contains all modules, and the "Centralizedserver" where the viewer is located on the client machineand the data server on a centralized machine somewherein the controls environment, we decided to implementthe latter. It is a solution that has the followingadvantages (+) and disadvantages (-):+ It makes the client smaller and lighter than theprevious architecture.+ It allows for centralized access control to datasources.+ It permits the development of different modules indifferent languages (as long as they implementCORBA).  This can be especially important forfuture implementations of DSAs.+ It permits data filtering at the DS/DSA level toreduce the data flow to the viewer.+ It makes it possible to have a flexible creationschema for data server and data source adapters.It may be advantageous to give priorities todifferent user groups or to supervise and balancethe load on servers for optimal performance.− However, it implies a centralized CORBA servicethat can create data servers on demand.  Thisservice must be available at all times.For the TSI pilot implementation, we selected the"Centralized server" architecture.  Below is the mainclass diagram for the TSI [Figure 2]595Figure 2: Main class diagram for TSIThe following entities constitute the TSI class model:• Manager:  This is an interface implemented byclasses that create data servers and data sourceadapters.• TsiManager:  A class implementing the Managerinterface for the TSI.• DataClient:  This is an interface to implement forclasses requiring data.• DataServer:  This is an interface to implement forclasses providing data.• SupervisionSession:  The class associated withthe view.  It implements the DataClient interface.• TsiDataServer:  The TSI data server class.  Itimplements the DataServer interface forcommunication with the SupervisionSession and itimplements the DataClient interface forcommunication with the DataSourceAdapter fordata acquisition.• TdsDataSourceAdapter:  The specific datasource adapter for the TDS.  It implements theDataServer interface.• TsiRefDB:  The tag database for the TSI.  Thisdatabase stores a mapping between a data sourcetag name (the way an equipment parameter isdefined in a data source specific context) and aTSI tag name (the way an equipment parameter isdefined in the TSI context). This solution waschosen because it has the same namingconventions in all views, and also allows for easymaintenance of views.A first prototype system has been implemented usingthe Orbacus CORBA implementation of Object OrientedConcepts, Inc. The Manager, DataServer andTdsDataSourceAdapter as well as a Java and a C++prototype client exist at present. An interface betweenthe SL-GMS run-time engine and the TSISupervisionSession is under development and will beused in the TSI pilot application.We have also developed a first tag selection toolwhich connects to the TDS reference database.  This toolwill be integrated with the SL-GMS editor GMSDraw.5  OUTLOOKThe first TSI application will be the user interface forthe CERN Safety Monitoring prototype system.  It isplanned to be ready by the end of 1999 and will includefive views representing fire detection installations. It willuse one data source adapter for the TDS.The development of the TSI software will be iterative.After the first iteration and implementation of the basicsubscription and command sending functionality, wewill implement the access control and the usermanagement features of the Manager.Other DSAs will be implemented for the TSI.  First inline is a DSA allowing access to archived data andfunctionality within the viewer to play back that data.The TdsDataSourceAdapter will also be used by theEvent Logging System [6] that will use it for dataacquisition of TDS data.It is thought that the TdsDataSourceAdapter couldeventually be the standard CORBA interface to TDSdata for any client program.6  CONCLUSIONFinding a supervision tool for the next decade today isa difficult task. From what we have seen it looks as ifWindowsNT and Java tools will dominate the marketand for our use, we have opted for Java. One challengewith using Java is to provide the same performance thatoperators have with platform specific applications today.We have designed the modules in the TSI to besimple, flexible and reusable and we have defined astandard interface for new data sources. It will handleother LHC data sources and could perhaps be thestandard slow control data acquisition interface.The choice of using CORBA seems the bestalternative for distributed inter-object communicationtoday.  We will evaluate the performance andmaintainability of it with the TSI pilot application, butwe are quite confident that we have a systemarchitecture that will last for the required period.REFERENCES[1] U. Epting & al "CERN LHC TechnicalInfrastructure Monitoring ", ICALEPCS'99, Trieste,October 1999.[2] P. Ninin & al. "Technical Data Server: A LargeScale Supervision System", ICALEPCS'97, Beijing[3] M-J Padilla, P. Sollander, "TSI, User RequirementsDocument", - CERN ST/MC/97-01[4] P. Sollander & al, "TSI, Software RequirementsDocument", - CERN ST/MC/98-17[5] P. Sollander & al, "TSI, Market Survey Report andImplementation Proposal", - CERN ST/MC/98-53[6] M. Zurek & al, "Event Logging System,Architectural Design Document", ST/MO/99-08596

The Technical Supervision Interface: A Java Based Synoptic View Environment

Abstract

Similar works

Full text

Available Versions

CERN Document Server