OPC - Device Support

1. OPC - Device Support Bernhard Kuner, Carsten Winkler BESSY, Berlin, Germany

2. Introduction to OPC OPC: OLE (COM) for process control DCOM: Distributed Component Object Model Client/Server scalable and distributed over network �Data Access� specification read/write, time stamps, quality polled or callback �Alarm and Event� specification Existing OPC servers support only a subset of the defined OPC features In former meetings it was the part of Kai Uwe Kasemir or Matthias Clausen to tell something about OPC. Now Bessy developed a device support for OPC and it is our turn. First let me tell you a little about what OPC is. OPC stands for OLE for process control. I don�t want to explain that in detail, but OPC means the specification of data objects and alarm and event objects that are hosted on servers and may be read and written from clients. An OPC based system is as scalable as an EPICS system. It can be made up of one or many servers and clients spread over a network. As with an EPICS system there are means of access security, timestamps and so on. Unfortunately existing OPC servers support only a subset of the defined features. The server from our PLC vendor for example doesn�t make use of all of the alarm and event specifications so it is only possible to poll the data.In former meetings it was the part of Kai Uwe Kasemir or Matthias Clausen to tell something about OPC. Now Bessy developed a device support for OPC and it is our turn. First let me tell you a little about what OPC is. OPC stands for OLE for process control. I don�t want to explain that in detail, but OPC means the specification of data objects and alarm and event objects that are hosted on servers and may be read and written from clients. An OPC based system is as scalable as an EPICS system. It can be made up of one or many servers and clients spread over a network. As with an EPICS system there are means of access security, timestamps and so on. Unfortunately existing OPC servers support only a subset of the defined features. The server from our PLC vendor for example doesn�t make use of all of the alarm and event specifications so it is only possible to poll the data.

3. Data Flow Device - OPC server communication: proprietary, vendor dependant OPC client - OPC server communication: via DCOM (Microsoft) OPC libraries available for: all Windows, Unix, not vxWorks The communication between the OPC server and its hardware is of course not defined by OPC. There are all possibilities like IO-Cards put directly to the server, GPIB, serial connections and so on. Our OPC server communicates with its PLCs via ethernet in a proprietary format. The communication between server and client works under the rules of DCOM. DCOM is one of the Microsoft standards. Of course it is not the up- to-date standard, because Microsoft standards mean a standardised half-life period of the standard, not a functionality. DCOM is a protocol that enables software components to communicate on the same host or over a network. It provides for component instantiation and invocation of methods as they pretend in a reliable, secure, and efficient manner. We have no experience what that means in comparison with the EPICS channel access layer, but we have experience that it is quite tedious to configure DCOM on two PCs to make it run over the network. Non Windows operating systems have the problem to implement DCOM itself So there are vendors that offer OPC libraries for some UNIX dialects but so far vxWorks is not supported. The communication between the OPC server and its hardware is of course not defined by OPC. There are all possibilities like IO-Cards put directly to the server, GPIB, serial connections and so on. Our OPC server communicates with its PLCs via ethernet in a proprietary format. The communication between server and client works under the rules of DCOM. DCOM is one of the Microsoft standards. Of course it is not the up- to-date standard, because Microsoft standards mean a standardised half-life period of the standard, not a functionality. DCOM is a protocol that enables software components to communicate on the same host or over a network. It provides for component instantiation and invocation of methods as they pretend in a reliable, secure, and efficient manner. We have no experience what that means in comparison with the EPICS channel access layer, but we have experience that it is quite tedious to configure DCOM on two PCs to make it run over the network. Non Windows operating systems have the problem to implement DCOM itself So there are vendors that offer OPC libraries for some UNIX dialects but so far vxWorks is not supported.

4. Client Data Access Connect to server Client will start/stop the server Add group Client defines groups with common parameters for all items within the group Add items Client subscribes for several data objects An OPC data server has a static structure of its data objects with their properties. If a client wants access to the data it will first connect to the server. This will start the server on its host. Disconnect of the last client will terminate the server. UNIX users don�t expect this behaviour, but this feature of OLE works a little like script programming. You can start the application, MS-Word for example, add some text, save, and exit. The OLE interface provides for the appropriate methods. An OPC client has to group its data objects. The group defines a poll rate or other common parameters for the group. To this group or groups items may be added. Each item has the properties value, timestamp, and quality, but it can have other properties, too. This depends on the server. There is no broadcast search of a PV like in EPICS, but you can browse a server to look what items it contains. An OPC data server has a static structure of its data objects with their properties. If a client wants access to the data it will first connect to the server. This will start the server on its host. Disconnect of the last client will terminate the server. UNIX users don�t expect this behaviour, but this feature of OLE works a little like script programming. You can start the application, MS-Word for example, add some text, save, and exit. The OLE interface provides for the appropriate methods. An OPC client has to group its data objects. The group defines a poll rate or other common parameters for the group. To this group or groups items may be added. Each item has the properties value, timestamp, and quality, but it can have other properties, too. This depends on the server. There is no broadcast search of a PV like in EPICS, but you can browse a server to look what items it contains.

5. Bessy Installation Connect PLC controlled beamlines to EPICS - 30 PLCs: c. 6,000 PVs - 4 OPC servers Currently 600 PVs with the new iocShell In the future: 30,000 PVs Data volume One PLC: 6 kB/s, polled with 50 ms - > 2 GB/d raw data over the network - > 200 kB Channel Access data At Bessy we have an EPICS based control system for the machine, but control of the beamlines, monochromators, and other related hardware is not standardised. The beamlines with their devices for vacuum, heating, valves and so on are controlled by PLCs that provide for interlock and a local control for the users. Soon there was the demand of data exchange with the machine control system and there was no way to get around EPICS. Now EPICS is about to become a standard also at the beamlines. The main problem is to interface existing hardware. For the beamline there are PLCs with a rather simple OPC server. This server polls the variables in the PLC at a 50 ms rate. This leads to the huge amount of 2 Gbytes of data per day being transmitted over the network and results in approximately 200 kByte relevant data per day.At Bessy we have an EPICS based control system for the machine, but control of the beamlines, monochromators, and other related hardware is not standardised. The beamlines with their devices for vacuum, heating, valves and so on are controlled by PLCs that provide for interlock and a local control for the users. Soon there was the demand of data exchange with the machine control system and there was no way to get around EPICS. Now EPICS is about to become a standard also at the beamlines. The main problem is to interface existing hardware. For the beamline there are PLCs with a rather simple OPC server. This server polls the variables in the PLC at a 50 ms rate. This leads to the huge amount of 2 Gbytes of data per day being transmitted over the network and results in approximately 200 kByte relevant data per day.

6. Former Approaches OPC_CAS Doesn�t work reliably Several crashes a day VisualBasic program with Kepware OPC client and ActiveX_CAS Proper handling of values, alarms and graphic limits Crashes ALH and other clients No access security OPC can�t set STAT and SEVR XCas Another CAS based solution For the beamline PLCs we have our OPC server, but the problem is the interface to EPICS. Kai-Uwe Kasemir was the first who presented a solution. He built an OPC to Channel Access gateway based on the Portable Channel Access Server from EPICS 3.13. One of its problems was that it didn�t run stable. We built a Perl workaround that restarts the gateway after a crash, but it was not a satisfying solution. Roland Fleischhauer from Bessy is still responsible for the beamline hard- and software and after he got no more support from us he built his own gateway with an OPC client library from Kepware and Kai-Uwe�s ActiveX_CAS connected using a visual basic script. This solution worked stable and was able to satisfy EPICS clients like medm with the HOPR and LOPR field. Still it was not possible to set STAT and SEVR in the ActiveX_CAS and there were no means of access security. Nevertheless this system works up to now with its 6000 PVs. The next idea was to build another OPC to CAS solution with the XCAS-library by Benjamin Franksen and me. But I refused to do it as I realised that all of this Portable Channel Access Server solutions will never satisfy the users unless they have exact the same features as an EPICS record. First they want the data value, than they want graphic limits, next are deadbands MDEL, ADEL and of course the alarm acknowledge fields ACKS and ACKT and so on. You are on the way to re-implement EPICS records. This can�t be the way to go. What we never tried was the proper solution of a mailbox IOC which reads all input from the activeX server and satisfies all client demands.For the beamline PLCs we have our OPC server, but the problem is the interface to EPICS. Kai-Uwe Kasemir was the first who presented a solution. He built an OPC to Channel Access gateway based on the Portable Channel Access Server from EPICS 3.13. One of its problems was that it didn�t run stable. We built a Perl workaround that restarts the gateway after a crash, but it was not a satisfying solution. Roland Fleischhauer from Bessy is still responsible for the beamline hard- and software and after he got no more support from us he built his own gateway with an OPC client library from Kepware and Kai-Uwe�s ActiveX_CAS connected using a visual basic script. This solution worked stable and was able to satisfy EPICS clients like medm with the HOPR and LOPR field. Still it was not possible to set STAT and SEVR in the ActiveX_CAS and there were no means of access security. Nevertheless this system works up to now with its 6000 PVs. The next idea was to build another OPC to CAS solution with the XCAS-library by Benjamin Franksen and me. But I refused to do it as I realised that all of this Portable Channel Access Server solutions will never satisfy the users unless they have exact the same features as an EPICS record. First they want the data value, than they want graphic limits, next are deadbands MDEL, ADEL and of course the alarm acknowledge fields ACKS and ACKT and so on. You are on the way to re-implement EPICS records. This can�t be the way to go. What we never tried was the proper solution of a mailbox IOC which reads all input from the activeX server and satisfies all client demands.

7. Device Support for EPICS 3.14 For these record types: - ai, ao - bi, bo - mbbi, mbbo - mbbiDirect, mbboDirect - longin, longout - stringin, stringout - (waveform) OPC client with - Softing OPC Toolbox 3.01 - Other client libraries possible With EPICS 3.14 it was possible to run the host based IOC on a Windows-PC and write device support for EPICS records. This is the best solution and we have it in use for 600 PVs now and it will completely replace the former solution with the vba script soon There are still problems like it is hard work to configure DCOM to run OPC server and client on different hosts. More features to be added include connecting an iocShell to several servers and support array data for waveform records. The device support is developed to run with the OPC client library from Softing. That is for historical reasons because it was used for Kai Uwe�s OPC_CAS. The concept is that all record dependant code is in the devOpc.c file and all opc dependants on the drvOpc.cpp so it should be easy to port it to an other opc library. With EPICS 3.14 it was possible to run the host based IOC on a Windows-PC and write device support for EPICS records. This is the best solution and we have it in use for 600 PVs now and it will completely replace the former solution with the vba script soon There are still problems like it is hard work to configure DCOM to run OPC server and client on different hosts. More features to be added include connecting an iocShell to several servers and support array data for waveform records. The device support is developed to run with the OPC client library from Softing. That is for historical reasons because it was used for Kai Uwe�s OPC_CAS. The concept is that all record dependant code is in the devOpc.c file and all opc dependants on the drvOpc.cpp so it should be easy to port it to an other opc library.

8. opcDevSup Features Data conversion for all integer and float data types Timestamp generated by OPC server or EPICS determined by the record�s TSE field Map OPC quality to records STAT/SEVR fields Out records may be written by the PLC and by EPICS in - records: read only records out - records: read/write records Record processing: SCAN field: �I/O Intr� or �.1 second� to �10 second� OUT records are not �Passive�, but �I/O Intr� This device support works somewhat like a gateway. It gets its data in a variant data type and converts it to the native data type of the record. So it was easy to support all record types. Support for data arrays is not implemented yet, but this is the next on the to-do list. The user can set the TSE field of the record to configure the timestamp source: native OPC timestamp or the EPICS timestamp. We also try to map the quality information to the options of the STAT field and set SEVR to INVALID if the quality is notified as bad One major problem was that OPC data objects can be written from the iocShell and also by the PLC. So we need In/Out-records, which are not provided by EPICS. If we get an update of the data from the OPC library it is no problem to set the VAL field, but we also want the record to send monitors and set severity. So it is neccessary to process the record. This will cause writing the value back to the PLC because it is an out-record and we get an infinite loop. We solved this problem with a flag set by the incoming object and read by the write routine to prevent unintentional output. A problem may occur if the OPC object is written from both sides, EPICS and the PLC, at the same time. In this case it is not defined which write is discarded, but on the other hand as long as there is no priority defined we don�t care for that. So here there are out-records that are not SCAN=�Passive� but �I/O Intr�.This device support works somewhat like a gateway. It gets its data in a variant data type and converts it to the native data type of the record. So it was easy to support all record types. Support for data arrays is not implemented yet, but this is the next on the to-do list. The user can set the TSE field of the record to configure the timestamp source: native OPC timestamp or the EPICS timestamp. We also try to map the quality information to the options of the STAT field and set SEVR to INVALID if the quality is notified as bad One major problem was that OPC data objects can be written from the iocShell and also by the PLC. So we need In/Out-records, which are not provided by EPICS. If we get an update of the data from the OPC library it is no problem to set the VAL field, but we also want the record to send monitors and set severity. So it is neccessary to process the record. This will cause writing the value back to the PLC because it is an out-record and we get an infinite loop. We solved this problem with a flag set by the incoming object and read by the write routine to prevent unintentional output. A problem may occur if the OPC object is written from both sides, EPICS and the PLC, at the same time. In this case it is not defined which write is discarded, but on the other hand as long as there is no priority defined we don�t care for that. So here there are out-records that are not SCAN=�Passive� but �I/O Intr�.

9. Conclusions Portable CAS solutions never satisfy EPICS clients. For full range of EPICS functionality EPICS records are required. An important conclusion is that portable CAS solutions can not satisfy all EPICS clients. At first users are content if they see the values but the next day they come back and want support for the medm, for the archiver and so on. In the end you have programmed a full EPICS record. If no device support is possible, the best solution seems to be a record that gets its input from a channel access server and provides the full EPICS functionality. An important conclusion is that portable CAS solutions can not satisfy all EPICS clients. At first users are content if they see the values but the next day they come back and want support for the medm, for the archiver and so on. In the end you have programmed a full EPICS record. If no device support is possible, the best solution seems to be a record that gets its input from a channel access server and provides the full EPICS functionality.