Burkimsher, Paul C

Milcent, H

CERN Document Server

APPLYING INDUSTRIAL SOLUTIONS TO THE CONTROL OF HEP EXPERIMENTSP. Burkimsher, H. Milcent CERN, Geneva, SwitzerlandAbstractAn increasing number of industrial systems are nowusing PLCs (Programmable Logical Controllers) andSCADA systems (Supervisory Control And DataAcquisition systems) for process control. Thesetechnologies have been used at CERN in the L3 Muoncontrols project[1] and the NA48 experiment[2]. Under theauspices of JCOP[3], the control systems of B1GCS, theATLAS-TRT[4] and the ALICE-HMPID[5] have all usedthe above off the shelf technologies plus OPC (OLE forProcess Control) and the PROFIBUS fieldbus. Theselatter control systems include only a small number ofdevices, but nevertheless they demonstrate all of the layersof a complete system. In this paper a synthesis will bemade of the experience gained and conclusions drawn as tothe possible use of these technologies for the CERN LHCdetector controls.1 INTRODUCTIONThere is a wide range of industrial products on themarket potentially applicable to the different componentsof a High Energy Physics Detector Control System(DCS). PLCs, Fieldbus components and SCADA toolshave all been used successfully in existing systems atCERN. This paper describes our experience, discusses thefields of application of these industrial products and makesobservations relevant to their possible use in the DCSsystems at LHC.A PLC is a diskless compact computer including allthe necessary hardware interfaces for the process control:CPU, fieldbus interface, input/output module. A fieldbusis a data transport medium designed for use in controlsystems. A SCADA package comprises a developmenttoolkit and a run-time system. The SCADA run-timesystem supports the supervisory level functions of theuser developed DCS. The technology of PLCs, fieldbusand SCADA is widely used in industry. OPC (OLE forprocess control) is an emerging non-proprietary softwarestandard to interface these different components.2 INDUSTRIAL SOLUTIONS USEDIN EXISTING SYSTEMS AT CERN2.1 NA48 control systemThe NA48 control system is a large system designedand written for the NA48 startup in 1996. Since thattime, there has been a programme of continuousenhancement during the life of the experiment such that itnow controls• 795 High Voltage channels• 167 crates• 750 other miscellaneous itemsIn total this represents 22,000 individual I/O elementsand 72,000 internal SCADA tags. The architecture isdivided into two parts, known as the back-end and thefront-end, depicted in Figure 1.Figure 1: The Architecture of NA48The back-end comprises a single HP-Unix workstation.This is connected to a series of front-end processors whichare in turn connected to the hardware being controlled.The back-end workstation runs the main control systemapplication. This was implemented using Factorylink, aSCADA tool from USDATA. The controls application isconnected to the “front-end” (FE) part using remoteprocedure call (RPC) over Ethernet.Four front-end computers are connected to theequipment being controlled. Some equipment is directlyconnected, typically through VME with custom hardware.Other equipment, in particular the high voltage powersupplies, are daisy chained on a CAENet fieldbus. Thefront-end machines take care of all equipment polling.The front-end machines support CERN written driversfor the hardware being controlled. The detector hardware isenumerated in a database and this information is used toconfigure the object-oriented (OO) generic front-end codeat run-time.The back-end controls application provides the usualMan-Machine Interface (MMI) functionality of buttonsand status displays, as well as sophisticated trendingRPCdatabaseConfigurationFieldbus4 Front-End  CPUsHardwareBack-End Unix Workstation forMMI, logging and alarm functions.DirectFE2 FE3 FE4FE1International Conference on Accelerator and Large Experimental Physics Control Systems362International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, Italytools. All displays are available anywhere in the Ethernetlocal area network (LAN) as Factorylink uses X-windows.Access control facilities were implemented using a 3rdparty add-on package to Factorylink.The back-end application also implements extensivealarm condition checking plus data and event loggingfunctions. The application is event driven, stimulated bychange notification from the front-ends. Parameter loading(from a recipe) is also supported.2.2 L3 Muon control systemThe L3 Muon chambers are part of the L3 experiment.This is a medium size overall system controlling severalindependent sub-systems:• 136 values from discriminators accessed overRS232• 512 proximity sensors over standard ±5v interface• 4 independent CAEN high voltage systemsaccessed via VME with a total of 544 HV channels• 2100 float values in the alignment system usingVME RASNIK hardwareThe control software was re-engineered with acommercial product DAMATIC-XD/XIS from VALMETAutomation. DAMATIC XD is a distributed and scalablecontrol system toolkit based on VME. It is equivalent toa PLC with supervisory facilities such as an X-windowMMI and basic alarm management being provided.VALMET’s own modules can be connected into thesystem over a proprietary fieldbus. Non-VALMET VMEI/O modules are also permitted with provision forincorporating custom drivers and other software written inC.The control program was developed on a PC withAUTOCAD and was then downloaded onto the targetCPU. DAMATIC XIS, the supervisory system, runs onHP-Unix. It provides archiving, alarm logging, MMIthrough X-windows and an Application Programmer’sInterface (API). The communication between XD and XISis based on a proprietary TCP-IP-like protocol overEthernet.The L3 Muon control system was distributed over 5VALMET CPUs and a Motorola MVME-167 CPU withboth VALMET hardware (ADCs, RS232) and nonVALMET hardware (RASNIK, CAEN). C functions werewritten to interface the latter.Custom hardware was required to connect the ±5 Voltproximity sensor signals to the 0-10 Volt ADC.The data from the system was first archived in theproprietary DAMATIC-XIS database and then sent to theL3 database for offline analysis. In total the L3 Muondetector involves around 6700 SCADA I/Os and around13,400 SCADA tags.2.3 ATLAS-TRT control systemThe Gas Working Group[6] has implemented a short-term gas system hardware prototype for the ATLAS-TRT(Transition Radiation Tracker) sub-detector. The gassystem comprises a gas supply module plus mixer,purification, distribution and circulation modules. This isa small system, there are in total only 21 analog and 18digital I/Os. Most of the equipment is standard for gassystems, e.g. valves, pressure transmitters, flow meterswith standard analog interfaces (4-20 mA, 0-10 Volt,etc.). The TRT gas system has two identifiable portions:• A process control task that handles all the process’periodic and asynchronous events.• A supervision task that provides MMI, alarmhandling, logging, archiving and access control.The ATLAS-TRT gas system is a single layer system,meaning that both of the process control and thesupervision tasks are implemented within the sameBridgeVIEW SCADA tool available from NationalInstruments. The hardware sensors were connected toWAGO PROFIBUS-DP modules. PROFIBUS is one ofthe three fieldbuses recommended by CERN and wasselected because a wide range of equipment is alreadyavailable offering integrated PROFIBUS connections.BridgeVIEW was connected to PROFIBUS using thePC1500PFB APPLICOM card.2.4 B1GCS gas  control  and HMPID liquidcontrol  systemsB1GGCS is a gas system under development by theGas Working Group on behalf of the CMS Micro StripGas Chamber. HMPID (High Momentum ParticleIDentification) is an ALICE subdetector for which aprototype of the liquid distribution system has alreadybeen built. A control system for this prototype hardwarehas been implemented. The prototype hardware is a scaled-down version of the final system, and has only 8 analogand 11 digital I/O points. The HMPID and B1GCScontrol systems are considered small systems. Theequipment used in both systems is similar, includingmass flow controllers and temperature probes usingstandard analogue interfaces (4-20 mA, 0-10 Volts). Thefunctionality for both includes two distinct layers:• The process control layer in which the closed loopcontrol is performed• The supervisory layer providing MMI, alarmhandling, logging, archiving and access controlIn contrast with the TRT system, both layers can beoperated independently from each other. The processcontrol layer was implemented in a SIEMENS PLC S7-300 using SIEMENS I/O modules directly connected tothe hardware (i.e. without a fieldbus). The supervisionlayer is implemented with BridgeVIEW for the ALICE-HMPID and with PANORAMA for the B1GCS system.OPC was used as a communication interface between thetwo layers in both systems. SIEMENS provides an OPCServer running under Windows NT and a library to accessthe PLC via Ethernet. An OPC Client is included withinBridgeVIEW and PANORAMA.3633 DISCUSSION OF THE DIFFERENTAPPROACHESThe experience described above shows the use ofindustrial solutions in a variety of different CERNcontexts. The TRT example connects a fieldbus to aSCADA run-time system; HMPID connects PLCsdirectly to a SCADA system. In the laboratory we havesuccessfully connected PLCs directly to a fieldbus. Theseexamples show that the industrial components can bearranged in a very flexible manner.PLCs are effective at performing autonomous andsecure local process control with closed loops. A fieldbusis an ideal solution in a geographically dispersedenvironment. The advantage of using a standard busrelates to its ease of use. There are no drivers to write normaintain. If the fieldbus is connected to a SCADAproduct or to a PLC component then neither is there anycommunications software to write.The OPC software standard offers several advantages.First, it acts as glue between independent layers of thesystem, allowing change of an individual layer withoutbreaking the entire system. Second, it permits separatelydeveloped components to be readily incorporated into theoverall DCS.The re-engineering of the L3 Muon control systemfurther shows how an industrial product can be interfacedinto an existing experiment, in this case into one wherein years gone by, it was necessary to write custom code.Using standard hardware components is convenient, butentails a cost and at CERN there is a considerableinvestment already in other equipment, for example VME.Nevertheless, it has been shown to be possible andworthwhile to provide supervisory functionality using aSCADA tool even when interfacing to VME.The NA48 experience underlines how the Object-Oriented paradigm maps well onto external hardware. Eachdevice being controlled is represented as a software objectin the front end. Instances of devices can be created at run-time as required, according to configuration informationcoming from a database. OO software lends itself well tore-use and indeed many of the equipment drivers weretaken over from the preceding WANF[7] beamline project.Unfortunately, the Factorylink SCADA does not supportan OO style of working directly. This meant that theinterface with the front-end objects was somewhatcontrived. We observed a 1:3 ratio between the number ofI/O points and the number of tags in the SCADA system.Managing such a large number of tags is not easy andneeds careful engineering. Some higher levelconfiguration tool is clearly required to build a system anylarger than NA48. We are aware of at least one enterprisethat has successfully written an in-house configurationtool on top of Factorylink, expressly for this purpose.Industrial SCADA development tools offer manyadvantages when preparing individual DCS controlsystems. The NA48 experiment was able to capitalise onthe power of Factorylink for implementing not only theuser interface but also for its alarm handling, trending andlogging capabilities. At this level, constructing a DCSwith a SCADA tool typically requires configuration-stylework rather than detailed coding. This work can beperformed by less highly trained personnel and is quickerto implement and easier to maintain than custom code. Itis important to note that DCS systems built this wayremain open for custom code inserts if required.Whilst industrial development tools permit enormousleverage to be gained when implementing one’s own DCSsystems, they are not a cure for all problems. Today’stools are frequently not integrated with each other unlessone is prepared to lock oneself into a proprietary system.This can mean that one has to use more than one tool toachieve an overall development goal.Whatever tools are used, commercial or home-made,there always remains the need to perform properengineering, performing systems analysis developing“Use Cases” with the experiments.4 CONCLUSIONSExisting Detector Control Systems at CERN aresuccessfully using industrial component technology in avariety of configurations. These examples demonstratethat the technology exists now and we believe it isappropriate for use at LHC.REFERENCES[1] L3 Muon control software:http://itcowww.cern.ch/L3-CTRL/muon.html[2] NA48 experiment:http://itcowww.cern.ch/NA48/welcome.html[3] JCOP home page URL:http://itcowww.cern.ch/jcop/[4] ATLAS-TRT:http://itcowww.cern.ch/jcop/subprojects/ATLAS_TRT/[5] ALICE-HMPID:http://itcowww.cern.ch/jcop/subprojects/hmpid/ALICE/99-13 Internal note-DCSALICE/99-14 Internal note-DCS[6] Gas Working Group home page URL:http://www.cern.ch/LHCExp/GasWG/gwg_main.htm[7] http://www.cern.ch/Wanf/Impl_Desc/wmwork/www/WanfSystem_3.htmlACKNOWLEDGEMENTSThe authors would like to thank their many staffcolleagues and visitors to CERN who have contributed inno small way to the implementation of these projects.                                                                        364

Applying Industrial Solutions to the Control of HEP Experiments

Abstract

Similar works

Full text

Available Versions

CERN Document Server