Baggiolini, V

Barillère, R

Beharell, M

Chmielewski, D

Gras, P

Komoutnikov, V

Kostro, K

Liiou, A V

Milcent, H

CERN Document Server

RESULTS OF THE OPC EVALUATION DONE WITHIN JCOPFOR THE CONTROL OF THE LHC EXPERIMENTSR. Barillère, V. Baggiolini, M. Beharell, D. Chmielewski, P. Gras, H. Milcent, K. Kostro,CERN, Geneva, SwitzerlandA. Liiou, INR, RussiaV. Khomoutnikov, IHEP, RussiaAbstractThe construction of the LHC experiments’ controlsystems will require the integration of a wide range ofCOTS (Component Of The Shelf) and customcomponents: hardware such as instruments, controllers,fieldbuses and sensors as well as applications, forexample, for operator control and visualization or for sub-systems supervision.This integration may require a non-negligible effort ifstandard interfaces or integration mechanisms are notapplied.OLE for Process Control (OPC) is a recently definedset of interfaces designed to allow Windows applicationsto access control data. OPC is based on Microsoft DCOMand is developed by the OPC foundation [1].This paper presents the result of an evaluation done inthe context of the Joint Controls Project (JCOP) [2]. Theaim of this evaluation was to study the usability of OPCfor the detector control of the LHC experiments. Inparticular it presents the benefit and limitations of thespecifications, the availability of OPC compliant COTSand the usability of OPC development kits to developapplications accessing custom devices or non-Windowsplatforms.1  OPC OVERVIEW1.1 IntroductionOPC™ (OLE for Process Control) defines a set ofinterfaces, based on OLE/COM and DCOM technology,for truly open software application interoperabilitybetween automation/control applications, fieldsystems/devices and business/office applications (SeeFigure 1).OPC is managed by an independent body, the OPCFoundation, which counts more than 200 companies andinstitutes as members.The foundation has released two sets of interfaces:- OPC Data Access (V2.0, October 1998);- OPC Alarms and Events (V1.0, December 1998).A third one is in preparation:- OPC Historical Data.As these specifications are rather recent, we focusedour evaluation on the OPC Data Access, which is the onlyone actually supported by industry.Client ApplicationsSCADA Systems DCS SystemsSoftware DriversOPCI/FOPCI/FOPCI/FOPCI/FOPCI/FFigure 1: Example of where OPC may be applied1.1.2 Concepts1.2.1 A Client/Server architectureOPC is a client/server system. OPC servers holdprocess data for OPC clients, OPC clients read, write andsubscribe to the OPC servers’ process data. Relations aren-to-m: an OPC client can simultaneously interact withseveral OPC servers and several OPC clients can accessthe same OPC server.OPC servers optionally offer introspection facilities toallow clients to browse the available process data.1.2.2 OPC groups and OPC itemsOPC servers make process data available by means ofOPC items.  An OPC server creates OPC items on behalfof an OPC client.  The client’s OPC items are organizedin OPC groups.  OPC clients can only access their OPCitems through their respective OPC groups2.  The Figure 2shows two OPC clients accessing process data managedby an OPC server.  The first OPC client accesses its OPCitems through two groups, the second one has only onegroup.                                                          1 DCS stands for Distributed Control System.2 See the OPC specification [3] for details about OPC groups andOPC items.International Conference on Accelerator and Large Experimental Physics Control Systems511International Conference  Accel rator and L rge Experim ntal Physics Control Systems, 1999, Trieste, ItalyProcess dataOPCItemOPCItemOPCItemOPCGroupOPCGroupOPCGroupOPCItemOPCClientOPCClientOPCItemOPCItemFigure 2: The OPC concepts1.2.3 Data access mechanismsFour communication mechanisms have been definedfor OPC™ Data Access: synchronous and asynchronousread/write, refresh and subscription.When a client issues a synchronous read call, the serverdoes not return the control to the calling thread untilsending back the requested values. When a client issues anasynchronous read call, the server immediately returnscontrol to the calling thread and later, using a call-backmechanism, sends the requested values.The synchronous and asynchronous calls require thatclients specify the list of process data that have to be reador written.Refresh and subscription are callback mechanisms.They are used to access predefined sets of process data.Refresh is a "pull" mechanism, subscription is a "push"one.  When an OPC client issues a refresh call, the OPCserver asynchronously returns the current values of thepredefined set of data points using a predefinedcommunication path. Subscription is an event-basedmechanism. OPC servers notify clients when significantchanges (i.e. bigger than the dead-band defined for theOPC group) occur within a predefined set of process data.2 MOTIVATIONSThe main purpose of the JCOP evaluation was to decideif OPC could be recommended as the standard interface tothe various devices to be controlled in the LHCexperiments, as such an interface would obviously easethe integration of both industrial equipment and homemade devices.The use of OPC as middleware for the control of theLHC experiments or to interface high level applicationswas also considered.To assess this, a set of criteria has been identifiedamong which are the adoption of OPC by the market,OPC openness and flexibility, performance and reliabilityof OPC implementations.3 EVALUATION3.1 CapabilitiesAlthough OPC is not fully object-oriented - processdata are accessed through OPC items (i.e. tags) - weappreciated the four communication mechanisms of OPC.One can use both the read/write calls and the subscriptionto adapt the communication to the access speed of adevice.Timestamps and quality flags that can be attached to theretrieved values are useful features for distributed controlsystems. However, we found weaknesses in the OPCcapabilities; they are mainly due to the tight coupling ofOPC with DCOM. DCOM does not offer any namingservice like the one proposed by CORBA. Thedeployment of a distributed control application istherefore more difficult with OPC and DCOM than withCORBA. The location of OPC servers has to be supportedby a custom OPC client configuration or to either becontained in the OPC client source code or in theWindows registry of the OPC client PC.OPC security as well is entirely based on the NTsecurity.  It is not easy to use and the granularity is notfine enough. One can only specify access rights for OPCservers. We would have appreciated to be able to set theserights at the level of the process data.  If this feature is notimproved with the next releases of the specifications, theaccess control of our applications will have to beimplemented at a higher level up in the SCADA system.3.2 MarketAs demonstrated by the OPC catalog3 published by theOPC foundation, OPC has been widely adopted by themarket.  A lot of OPC servers are available to accessfieldbuses and Programmable Logic Controllers (PLC).Most of the SCADA (Supervision Control And DataAcquisition) systems have an OPC Data Access clientdriver and sometimes are OPC Data Access servers. Theothers plan to support OPC in the near future. High levelapplications such as expert systems are also available asOPC clients.When OPC servers are not available for a specificdevice, toolkits can be used to develop the required ones.                                                          3 The catalog is accessible from [1] and [4].512More than 30 toolkits to develop clients and servers arereferenced in the OPC catalog.Although the specifications are rather new, one can findindustrial products supporting the second version of OPCData Access and/or the first version of the OPC Alarmsand Events.3.3 CompatibilityWhile running the evaluation and developing smallprojects4, several OPC servers and clients, mainlycompliant with the OPC Data Access v1.0, were usedconcurrently. We did not experience any major problemsas far the compatibility is concerned. The minor problemswe encountered were due to different interpretations ofthe specifications. The OPC foundation is aware of thisproblem and has set up a compliance working group.3.4 Openness and flexibilityTo integrate very specific devices or devices controlledfrom non-Windows platforms (e.g. VME or PC withUnix) we need to develop our own OPC servers. As aconsequence of OPC relying on DCOM, Windows NT isrequired to run any of the OPC components.We found a large number of toolkits to support thesedevelopments, some of them are provided with evaluationversions. We developed rather easily OPC servers toaccess CAEN and Lecroy power supplies and to accessdevices through CORBA5. The use of these toolkitsusually requires knowledge in C++.  The most advancedtoolkits shield entirely developers from DCOM. This isindeed an advantage.3.5 ReliabilityThe reliability of OPC obviously depends on DCOM(as the underlying technology), on the toolkits used toproduce the OPC components and on the developers’skill.The DCOM communications timeouts being rather long(several minutes), OPC clients (respectively servers) willbe notified lately about the unavailability of the OPCservers (respectively clients) they are in communicationwith.  A workaround consists in implementing watchdogmechanisms to control the quality of the communicationsbetween OPC components. In the current DCOM implementation clients allocatememory in the server address space, they have then to freethis memory. This approach can lead to memory leaks incase of problems with clients. This limitation coulddisappear with the next major DCOM release.                                                          4 A list of JCOP projects where OPC servers have been used isavailable in the JCOP web site [4].5 Details about these OPS servers can be found in the JCOP OPCsub-project web site [4].3.6 PerformanceWhite papers about OPC performances are publiclyavailable on the Web [5]. In order to verify these numberswe ran our own performance tests. Our results6 were closeto the white papers ones.To run these tests, we developed an OPC server thatgenerates test values and OPC clients that consume them.We basically tested the synchronous writing of a set ofOPC items in a single OPC server. We also tested thesubscription to a set of items from a single OPC client.To read n (measured from 1 to 10000) OPC items, aclient needs 515 + (85 * n) µs in synchronous mode.When all n OPC items (we measured with n=500 to20000 items) of a group are modified, the minimumupdate rate is 80 * n µs.These results seem acceptable for the control of theLHC experiments where the majority of process data isnot expected to simultaneously change significantly.4 CONCLUSIONSAlmost all SCADA systems are already or will be soonOPC clients and OPC servers. OPC can then be used at ahigher level to interface SCADA with other COTS or highlevel applications (e.g. Finite State Machine).Although OPC has some limitations, mostly inheritedfrom DCOM, it is a reasonable solution for the integrationof commercial or homemade devices in the controlsystems of the LHC experiments. The use of appropriatetoolkits shields developers from DCOM and reduces theimpact of the evolution of DCOM on the maintenance ofthe developed OPC components.With the emergence of the new OPC interfacespecifications (Alarms and Events, Historical Data), and ifDCOM is extended with naming services, OPC could beused as middleware for component-based control systems.OPC is a de facto industrial standard that is likely tohave its place in our future solutions.5 REFERENCES[1] The OPC foundation:http://www.opcfoundation.org/[2] The Joint COntrols Project:http://itcowww.cern.ch/jcop/[3] The OPC specifications:http://www.opcfoundation.org/specs.asp[4] The JCOP OPC sub-project:http://itcowww.cern.ch/jcop/subprojects/OPC/[5] White papers about OPC performances & securityhttp://itcowww.cern.ch/jcop/subprojects/OPC/NewOPC/Status/[6] JCOP workshop II presentations;http://itcowww.cern.ch/jcop/JCOPworkshop2/                                                          6 Details about our evaluation process will be available on theJCOP OPC subproject web site [4].513

Results of the OPC Evaluation Done within JCOP for the Control of the LHC Experiments

Results of the OPC Evaluation Done within JCOP for the Control of the LHC Experiments

Abstract

Similar works

Full text

Available Versions

CERN Document Server