Possible solutions for interfacing the ATLAS ELMB to SCADA

Mark Beharrell

IT-CO

11/06/2001

Introduction

1. Expedited SDOs with commercial CanOpen/OPC server.

The Principle......

An OPC issue......

Products examined......

Conclusion......

2. CanOpen/SoftPLC/OPC

The Principle......

Product examined......

Conclusion......

3. CanOpen/custom code/(OPC or PVSS driver)

The principle......

The products......

Conclusion......

A comment on CanOpen card recommendation.......

Summary......

Appendix A - PVSS-ELMB adapter requirements......

Configuration Requirements (con)......

Communication Requirements (comm)......

Node Management Requirements (nm)......

Data handling requirements (dh)......

Bus Management requirements (bm)......

Requirements mentioned in previous documents but not included here (and why they were not)......

Appendix B – Product Conformance to requirements......

A – Expedited SDOs with commercial CanOpen/OPC server

B – CanOpen/SoftPLC/OPC

C – CanOpen/custom code/(OPC or DIM)

Appendix C - Beckhoff (with SoftPLC) Configuration for the ELMB......

Configuration of ELMB DI/DO......

Configuration of ELMB AO......

Configuration of ELMB AI......

Thoughts on the configuration process......

Appendix D - List Of Can Cards......

Appendix E - The standard ELMB......

Introduction

In the CanOpen meeting of the 23rd April 2001, three approaches to solving the PVSS-ELMB interfacing problem were proposed. These were PVSS-ELMB adapters based on the following:-

  1. Expedited SDOs with a commercial CanOpen/OPC server.
  2. A CanOpen/SoftPLC/OPC approach
  3. A CanOpen/custom code/(OPC or DIM) approach.

Since this meeting, work has continued on these three approaches, looking in more detail at the viability of each and identifying commercial products based on these approaches. Each of these products was compared against the requirements (Appendix A) for PVSS-ELMB interfacing furnished by the ATLAS experiment in order to determine the suitability of the product for use as a PVSS-ELMB adapter.

The purpose of this paper is to report on the findings of this work and shall proceed by examining each approach in the order listed above.

1. Expedited SDOs with commercial CanOpen/OPC server.

The motivation behind this approach is to avoid using the ELMB style multiplexed PDOs (Process Data Object) that are currently used to transfer the large quantities of ADC data to CanOpen clients. This ELMB style of multiplexed PDO is problematic because it forms a proprietary protocol that is built on top of CanOpen. Naturally commercial products do not support this proprietary protocol. Here it is proposed that in its place expedited SDO’s (Service Data Object) are used in its place to transfer the ADC data.

The Principle

The expedited SDOs are naturally multiplexed, placing 4 bytes of data in a CanOpen object dictionary entry that is identified by the Index and sub-index found in the SDO frame. The cost of this is that SDO’s are acknowledged, so 50% of the bandwidth is lost.

SDO’s are used to communicate in a client server relationship. This enables: -

  1. The OPC server to be a SDO client. This allows the OPC server to poll each ELMB on the bus for each of its ADC values. Because the OPC server is in control of the rate at which ADC values are received, neither the bus nor the OPC server become overloaded. However, it means that the ELMB node cannot implement the sending of ADC values with SYNCH/change/event transmission semantics.
  2. The OPC server to be a SDO server. This approach addresses the problems mentioned in item 1 above, allowing the timely transmission of ADC data that has changed, but means the OPC server cannot control the rate of transmission of data, making it susceptible to overloading.

An OPC issue

Using the OPC server as a SDO server appears to be the preferred solution for sending ADC data as it offers flexible transmission semantics. However, when we take the semantics of OPC into account, this option appears to lose its advantage.

OPC indirectly assigns an update rate to ADC values mapped into its server. The OPC standard specifies that changes in these values must not be sent back to a client at a rate greater than the update rate. Thus an OPC client is only informed of a change in an ADC value at the end of the period defined by the update rate. If a value obtained by an SDO has not changed during this period, the OPC server will request the value from the ELMB via SDO transfer[1] (it has been observed that the Softing implementation requests a new data value even if it has been updated during the refresh rate period).

Thus, as far as the OPC client is concerned the OPC server is acting as a SDO polling client (values are only transmitted to the OPC client periodically).

Products examined

OPC/CanOpen servers from Applicom (version 2), Beckhoff (version 3) and Softing (version 1) have been considered. These were chosen because of experience with them and the availability of HW and documentation.

It was found that Applicom could not access SDO frames at run time from OPC, so it is unsuitable for use with this technique. The Beckhoff OPC server cannot act as a SDO server, but given the problem described above, it is not felt that this is a problem. The Softing OPC server may act as a SDO server, but again, given the problem described above, this is not felt to be an advantage.

There are scalability issues with both cards. Beckhoff because of configuration, it does not accept EDS (Electronic Data Sheet - Beckhoff claim to address this in the future) or DCF (Device Configuration File) files and its configuration file format is closed, this then requires the configuration of each OPC item to be done by hand (120 items per ‘standard’ ELMB – see Appendix E). Softing has scaling problems because the OPC server will only support one CanOpen network. OPC requires that there is only one server of the same type active at any one time on the same machine – hence one PC per network would be required.

A comparison of the Applicom, Beckhoff and Softing OPC servers with the ELMB requirements is found in Appendix B, section A.

Conclusion

The use of an commercial OPC server in this approach means that data will be transmitted periodically to its clients (where the period is defined by the OPC client), irrespective of the transmission semantics and model (OPC server as a SDO client or server) of the data being transferred by SDOs.

If this approach were to be used, the Beckhoff OPC server seems to offer the most viable solution, and thus would be a candidate for further testing. However, with the configuration issues associated with this product, it is advisable to continue looking for alternative servers.

2. CanOpen/SoftPLC/OPC

In this approach it is assumed that ELMB style multiplexed PDOs are used to send ADC data from the ELMB. This means that the multiplexed data has to be demultiplexed before is can be used by a user. Demultiplexing can be done by the client, or in the OPC server. As it is inefficient for this to be done in the client (particularly since every client must know the demultiplexing algorithm, implement and run it), the demultiplexing is to be carried out in the OPC server. For this to be done there must be some component of the OPC server that is user programmable – in this instance the SoftPLC.

The Principle

ELMB style multiplexed PDOs are read by the SoftPLC application, which extracts the ADC data and channel number (that the ADC data relates to) from the PDO. The SoftPLC uses the retrieved channel number to identify the OPC item that represents the ADC channel. Once this is achieved the ADC data is written to the OPC item previously identified.

Product examined

The Beckoff TwinCat system (version 2.7) is the only product examined that is based on this approach. The Twincat system, at least on a small scale, appears to do job of interfacing the ELMB to PVSS in an effective manner – it meets the most requirements of any commercial product examined (see Appendix B section B). However, when examining the ELMB as a whole and not just concentrating on the ADC aspects, we find the configuration is complex (see Appendix C). Some data items (56 per standard ELMB) having to be mapped directly into the OPC server whilst other items (64 per Standard ELMB) have to be mapped into the SoftPLC. This is a process which must be done by hand (configuration file formats are closed). Clearly as the number of ELMB nodes increases, this becomes very problematic.

Additionally, the SoftPLC application increases in complexity with code having to be added for every node that is added to the bus. This application requires that an OPC client can handle OPC items that are of an array type. PVSS can not currently do this (OPC array support will apparently be implemented sometime next year). Although it is possible to implement the SoftPLC application without arrays, this would be very inefficient and prone to error.

A further issue arises because of the semantics of OPC. According to the OPC standard it is possible to force read an OPC item (under normal circumstances a subscriber interface would be used in favour of this in order to avoid polling) – this normally resulting in a read from the device the OPC item is representing. However, when the OPC item represents an ADC value, the current value of the output variable in SoftPLC is read – not the device itself. However, ELMB data items mapped directly into the OPC server (such as DI values) will be read directly from the hardware. Hence, there is inconstancy in the forced read behaviour depending on whether or not the ELMB data values map directly into the OPC server or go via the SoftPLC.

Conclusion

Although it is felt that the Beckhoff TwinCat system is the most promising of all the commercial products that have been examined, it has extreme configuration problems due to the closed nature of its configuration tools. Because of the large amount of configuration required for networks of ELMBs and the current inability of PVSS to handle OPC arrays, it is felt that this product is unsuitable, at least for the time being.

3. CanOpen/custom code/(OPC or PVSS driver)

The principle

Using this approach it is feasible to write custom code that will fulfil any behaviour-oriented requirements that are required of the adapter. Of course, it is necessary that a CanOpen stack and OPC/PVSS driver interfaces are available with which this custom code interacts. Because this is a component-based solution, it is possible to select a CanOpen stack from a range available on the market, that best meets the adapter requirements. Because these stacks are not specialized to meet the needs of one particular application, it is more likely that they will provide the APIs to CanOpen services not usually accessible in other commercial adapter solutions.

The products

CanOpen protocol stacks from Port and Softing were examined. Appendix B section C shows the conformity to requirements table for the two products. The configuration requirements are not applicable for either of these products as it is the responsibility of the implementers of the adapter to read in configuration files (presumably DCF files) and use the contents to configure both the adapter and the nodes on the CanOpen network.

The Softing protocol stack provides an intuitive programming interface for accessing Softing CanOpen cards. The stack maybe accessed via Visual C++/BASIC, Borland C++ builder or Delphi. However, it restricts the implementation of an adapter to Microsoft-based Operating Systems. Additionally, it supports only one network and just 80 transmit/80 receive PDOs .

The Port protocol stack is CPU, Operating System and CanOpen card independent. The API may be accessed by programs written in standard C/C++. The API itself appears to be less intuitive than Softing’s and the documentation is oriented to writing code for CanOpen slaves rather than a master. However, it supports up to 255 networks and 512 transmit and 512 receive PDOs per network, additionally the stack appears to support multiplexed PDOs in a CanOpen compliant manner.

Conclusion

The Softing protocol stack does not scale well when trying to use it to communicate with large numbers of CanOpen nodes - one application using this stack will only access one bus of 20 ELMBs (one ELMB requires 4 TPDOs). Thus controlling 3000 ELMBs will require 150 networks, each with it’s own application to control it. Configuration file management then becomes an issue (the right file must be matched to the right application instance).

Port offers a solution with machine and Can interface independence, and scalability. However, the API is cluttered and not so intuitive. Whilst, this appears to meet the requirements list most fully, if this approach were to be chosen, it would be worth examining other CanOpen Protocol stacks that have come to light such as those from Vector and IXXAT, before opting for this protocol stack.

A comment on CanOpen card recommendation.

Following the meeting of the 23rd April 2001, it was suggested that a CanOpen card should be recommended that is suitable for solving the PVSS-ELMB adapter problem. However, it is found that in most approaches to PVSS-ELMB adapters examined, the commercial solutions are tightly integrated with the corresponding company’s Can interface. For approach:-

  • ‘Expedited SDOs with commercial CanOpen/OPC server’. The Applicom and Softing OPC servers will only work with the respective company’s card. The Beckhoff TwinCat OPC server works with Beckhoff or Hilscher cards.
  • ‘CanOpen/SoftPLC/OPC’. The Beckhoff TwinCat system works with a Beckhoff or Hilscher cards only.
  • ‘CanOpen/custom code/(OPC or DIM)’. The Softing stack will only work with Softing Can cards. While the Port protocol stack is CanOpen card independent, it still has requirements of the card to be used, namely the card provides a Can (not CanOpen) interface. Therefore cards with a CanOpen only interface are unsuitable for this purpose.

Therefore the solution chosen to the PVSS-ELMB adapter problem determines to a large degree the card that is to be used. Therefore without knowing the solution that is to be used for the adapter, it is felt that it is not possible to recommend a card for use with that solution.

Summary

Large quantities of ADC data, scalable configuration and access to the CanOpen network management protocol all seem to be major barriers when trying to solve the PVSS-ELMB adapter problem, to an extent that no particular approach or product stands out clearly as the one to use.

It has been interesting to note the effects of the use of OPC in the chain between the SCADA system and the ELMB. The manner in which ELMB data is sent between the OPC client and server depends on the adapter approach used and the implementation of the OPC server. If an OPC based approach is chosen, it is advisable to look more closely at the data transfer behaviour that the OPC server imposes on the ELMB data to ensure that any requirements that may arise in this area are met.

If it is necessary to preserve at PVSS, the transmission semantics of ELMB process data, then a custom code approach implemented as a PVSS driver (approach 3) is felt to be the most viable approach to take.

Appendix A - PVSS-ELMB adapter requirements

(M) Mandatory – The fundamental objectives cannot be met if these requirements are not realised.

(U) Useful – The fundamental objectives may be realised if these requirements are not met, but at some cost in functionality or ease of use.

(O) Optional – The fundamental objective may be realised without any lose of functionality or ease of use, if these requirement are not met.

Below is a list of requirements for the PVSS-ELMB adapter that were obtained from Fernando’s requirements document and subsequent conversation. Each requirement has an identifier (for reference purposes) with the format <Priority-Category-number>. Within this format, ‘number’ serves only to discriminate between requirements in the same Priority-Category group and should not be interpreted as denoting some importance or priority within that group.

Configuration Requirements (con)

It should be noted that there are two types of configuration –

  1. The configuration of the bus and its nodes.
  2. The configuration of the adapter itself.

Most of the requirements listed in this category are related to configuration of the bus. This is not necessarily the responsibility of the adapter, instead a configuration application may be used. However, because many of the solutions examined in this paper have a configuration application tightly integrated with the adapter, these requirements are included.

Configuration information expected to be handled is: -

  1. For bus and nodes.
  • Bus speed.
  • Synch rate.
  • Indication of nodes on the bus.
  • SDO data for each node (Node guard interval, PDO mappings, etc).
  • Program download information for each node.
  1. For the adapter
  • How object dictionary entries relate data elements accessible to PVSS (such as OPC items).
  • Which object entries require special processing.

M-con-1 PVSS must be able to produce configuration data for the adapter, this would be used for generating configuration information for large ELMB installations in an automated manner.