Comparison between commercial and open-source SCADA packages—A case study

Fusion Engineering and Design 85 (2010) 491–495

Contents lists available at ScienceDirect

Fusion Engineering and Design journal homepage: www.elsevier.com/locate/fusengdes

Comparison between commercial and open-source SCADA packages—A case study O. Barana ∗ , P. Barbato, M. Breda, R. Capobianco, A. Luchetta, F. Molon, M. Moressa, P. Simionato, C. Taliercio, E. Zampiva Consorzio RFX, Associazione EURATOM-ENEA sulla Fusione, corso Stati Uniti 4 - 35127 Padova, Italy

a r t i c l e

i n f o

Article history: Available online 26 February 2010 Keywords: SPIDER SCADA Open-source

a b s t r a c t SPIDER (Source for the Production of Ions of Deuterium Extracted from Rf plasma) is a new experimental device under development at Consorzio RFX aimed at providing a full-scale ion source prototype for MITICA (Megavolt ITer Injector and Concept Advance), the experiment devoted at supplying a full-scale prototype of the ITER Heating Neutral Beam Injector (HNB). Both experimental devices will be hosted in a new facility known as PRIMA (Padova Research on Injectors Megavolt Accelerated). The correct operation of SPIDER and MITICA will be guaranteed by process automation and plant monitoring that will be implemented using suitable controllers (cycle time greater than 10 ms) in conjunction with appropriate SCADA (Supervisory Control And Data Acquisition) software. This paper presents the tests performed at Consorzio RFX to evaluate commercial and open-source SCADA packages and prepare a technical base for the selection of the SCADA system for SPIDER. Two commercial solutions and two open-source solutions (EPICS and TANGO) were investigated. The typical test-bed was represented by a SCADA system exchanging data with a PLC (Programmable Logic Controller). The case study consisted of: (a) the development of a minimal panel provided with fields for setting parameters and of a trend window; (b) the set-up of two kinds of communication, a direct connection between the SCADA and the PLC and an indirect one by means of an OPC (Object Linking and Embedding for Process Control) server. The communication performance was evaluated measuring the network traffic with a fixed number of data variables exchanged and different polling cycle times. The conclusions show that the final choice of a SCADA package for SPIDER will be between one commercial SCADA and EPICS. This choice will not depend uniquely on the results of the tests, but will be also dictated by the early schedule of the SPIDER operations. © 2010 Elsevier B.V. All rights reserved.

1. Introduction PRIMA (Padova Research on Injectors Megavolt Accelerated) is a new facility under development at Consorzio RFX in the framework of an ITER collaboration aimed at realizing and providing the ITER Heating Neutral Beam Injectors (HNBs) [1]. PRIMA will encompass two new experimental devices: MITICA (Megavolt ITer Injector and Concept Advance) and SPIDER (Source for the Production of Ions of Deuterium Extracted from Rf plasma). While SPIDER will serve as test-bed for a full-scale MITICA ion source, MITICA will comprehend a full-scale HNB prototype. The correct operation of SPIDER and MITICA will be scheduled, synchronized and supervised by a plant control system, whose main components are the process automation system and the plant monitoring system. These will be implemented using suit-

∗ Corresponding author. Tel.: +39 049 8295003; fax: +39 049 8700718. E-mail address: [email protected] (O. Barana). 0920-3796/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2010.02.004

able controllers, characterized by a cycle time greater than 10 ms, in conjunction with appropriate SCADA (Supervisory Control And Data Acquisition) software. The process automation controllers will rely on Programmable Logic Controller (PLC) technology and the choice criteria of the PLC supplier will follow the prescriptions contained in the ITER Plant Control Design Handbook (PCDH) v4.1 [2] supplied by the ITER CODAC (COntrol, Data Access and Communication) group, which are in line with the Consorzio RFX’s tradition in terms of PLCs (Siemens SIMATIC S7). A major issue will be the choice of the SCADA package. As highlighted in PCDH v4.1, CODAC eventually decided to adopt the open-source EPICS [3] (Experimental Physics and Industrial Control System) package as software infrastructure (thus encompassing the supervision and soft real-time control issues). Many SCADA products are available today on the market and the main differences among them arise from the fact that some of them are commercial and some of them are open-source. Typically, the PLC suppliers have their own (commercial) SCADA, but there are also commer-

492

O. Barana et al. / Fusion Engineering and Design 85 (2010) 491–495

Table 1 Differences between the four test-bed architectures in terms of PCs employed. The subscripts S, C and O stand for Server, Client and OPC, respectively. Architecture

PCS

PCC

PCO

Arch-1 Arch-2 Arch-3 Arch-4

SCADA server and client SCADA server SCADA server and client SCADA server

Not used SCADA client Not used SCADA client

Not used Not used OPC server OPC server

cial SCADAs produced by companies not involved in the PLC market (e.g., Vsystem from Vista Control Systems). Open-source packages typically have their origin in collaborative efforts between physics laboratories, and their development is supported by a world-wide community. The case study1 presented in this paper aims at comparing a set of SCADA packages with a view to deciding on the final choice of the SCADA system for SPIDER, the first device to be realized. Due to the lack of time and human resources, only two commercial and two open-source SCADA packages were retained after a preliminary selection and considered by us the most suitable candidates. The commercial ones were FactoryTalk View Site Edition (FTV-SE) by Rockwell Automation and PVSS II by ETM, while the open-source ones were EPICS (release R3.14.10), originally developed by Los Angeles National Lab and Argonne National Lab, and TANGO [4] (TACO New Generation Objects), which is the evolution of TACO, the initial control system of the European Synchrotron Radiation Facility. The requirements considered during the execution of the tests concerned mainly the SCADA performance and the easiness of setting up a system. Compatibility with the ITER choice was not really required. A similar work can be found here in Ref. [5]; in that case, rather than making a choice among a restricted list of SCADAs, the possibility of employing a generic commercial SCADA for the CERN LHC (Large Hadron Collider) [6] experiment was evaluated and the outcome was positive. The paper is structured in the following way: while the next section outlines the test-bed architectures, the following two sections deal respectively with issues concerning the software installation and configuration and the test performances; conclusions are presented in the last section. 2. Test-bed architecture All the equipment was connected in full duplex mode on an isolated 100BASE-TX IEEE 802.3 Industrial Ethernet local area network, by means of an Ethernet switch (Hewlett Packard ProCurve 2524), in order to avoid external disturbances. Four architectures were used to evaluate the SCADAs. The components common to all the architectures were a PLC and an Apple laptop mounting Mac OS-X Leopard 10.5.6 as operating system and running a network analyzer (the free Wireshark). The laptop was connected to the switch on a properly configured monitor port, just “listening” to the communications. The remaining equipment, constituted mainly by Microsoft (MS) Windows PCs, is detailed in Table 1, which highlights the differences between the four architectures. Two main “options” can be identified: (1) SCADA server and client running in the same PC (PCS ) or on two different PCs (PCS and PCC ); (2) use of a further PC (PCO ), running an OPC (Object Linking and Embedding for Process Control [7]) server, or not. Arch-4, the most

1 It is worth mentioning that while two preliminary one-week courses of basic level were attended for FTV-SE and PVSS, respectively, no courses were attended for EPICS and TANGO, whose investigation was carried out uniquely relying on the documentation available on Internet.

Fig. 1. The fourth test-bed architecture; the main data flows are indicated.

articulated one, is depicted in Fig. 1, together with the main data flows. While the purpose of Arch-1 and Arch-2 was to evaluate a SCADA exchanging data directly with a PLC using either the native SCADA driver (when available) or a custom one, the purpose of Arch-3 and Arch-4 was to check the performance using an OPC server as an intermediate layer with which to exchange data with the PLC. The reason for choosing an intermediate layer of communication was mainly due to the fact that we wanted to consider also a solution that allowed the communication of different products, without the need of developing ad hoc drivers. The choice of the OPC technology as intermediate layer was based on its reliability and on the fact that it is widely used in the automation field. The differences arising by using one package instead of another were kept to a minimum, in order to be able to compare as far as possible the results, but sometimes it was necessary to adopt different solutions. For instance the PLC employed was always a Siemens SIMATIC S7-400, except for the tests with direct connection to a PLC using FTV-SE: in this case, since a driver necessary to communicate directly with the third-party Siemens PLC was not available, it was decided to perform the tests with a PLC from Rockwell Automation (ControlLogix 5561). MS Windows Server 2003 SP2 was the operating system commonly running on PCS , for the sake of homogeneity with FTV-SE (available only under the Windows operating system), except for EPICS, where the Linux Fedora 10 operating system was used, due to problems found in compiling the driver for the S7-400 PLC under MS Windows (where the Linux-like Cygwin environment was required). 3. Application set-up The Human-Machine Interface (HMI) of each test-bed had the same characteristics. In particular, the common features were: the upper-left part, carrying fields and buttons for the parameter conTable 2 Details and evaluations about the HMI development with the different SCADAs (best score is 4, worst is 1).

Graphical libraries Graphics quality Cross-platform portability HMI development

FTV-SE

PVSS

EPICS

TANGO

Native 4 No 4

Qt 3 Yes 3

Motif 2 Yes 3

Java 4 Yes 4

O. Barana et al. / Fusion Engineering and Design 85 (2010) 491–495

493

Table 3 Drivers, network protocols and data acquisition methods employed for the communications between the SCADA servers and the PLCs in Arch-1 and Arch-2 (best score is 4, worst is 1).

Driver Protocol Data acquisition method Easiness of the communication set-up

FTV-SE

PVSS

EPICS

TANGO

RSLynx Enterprise CIP (TCP/IP-based) Pure polling 4

Native SIMATIC S7 S7 Protocol (TCP/IP-based) Pure polling 4

SLS distribution TCP/IP-based Simulated polling 3

Custom TCP/IP-based Simulated polling 2

figuration; the upper-right part, with a window showing variable trends; the lower part, with the current value of all the test variables available in real-time. It could be noticed that all the packages allow the development of HMI in a user-friendly way, exploiting the drag-and-drop method. Table 2 supplies a few details and evaluations2 of the HMI development with the different SCADAs. Worth of mention is the use of the cross-platform Qt framework to develop graphical objects in PVSS. The EPICS HMI was developed using the MEDM [3] core extension, characterized by a Motif editor and display manager, which required the preliminary installation of the EPICS Win32 Extensions distribution [3] and of an X Server (Xming was used). The HMI development with MEDM was nevertheless simple, thanks to the quick association of graphical objects with the univocal Process Variable Names, one of the EPICS features. TANGO benefited, to build its HMI, from its Application ToolKit JavaBeans APIs (Application Programming Interfaces). Using already-made graphical objects speeded the development process up but offered a limited flexibility in the HMI design. The drivers, network protocols and data acquisition methods employed for the communications between the SCADA servers and the PLCs in Arch-1 and Arch-2 are illustrated in Table 3, together with an evaluation of the easiness of the communication set-up. In order to acquire data at a constant rate, it was chosen to use the polling method. The pure polling could be used only with FTV-SE and PVSS. In order to cope with the lack of drivers supporting the polling capability in EPICS and TANGO, it was decided to simulate the polling with the PLC sending data to the SCADA server at fixed intervals. The simulated polling is of course not equivalent to the real polling, since it presupposes a different client-server communication protocol; we can nevertheless assume that the network load given in the two cases does not depend too much on the kind of polling (simulated or not). The network set-up in FTV-SE required special care, but everything was well documented. The communication set-up with PVSS proved to be very efficient and configurable in very few steps. PVSS comes with a native SIMATIC S7 driver characterized by several useful settings, among which the choice between different protocols (e.g., the native S7 Protocol employed for the tests or the Time Stamp Push Protocol widely used at CERN [8]). The S7 driver employed with EPICS is not part of the EPICS core, but it was originally developed at the Paul Scherrer Institute for the Swiss Light Source [9] experiment. TANGO systems communicate with hardware devices by means of so-called Device Servers. The TANGO Pogo [4] tool was used to generate the “skeleton” structure to build the Device Server in Java. The “skeleton” structure was filled with custom PLC-specific Java code necessary to configure the hardware device; a simple custom protocol based on TCP/IP was defined to communicate with the PLC. The Device Server functionality was tested with Jive [4], another useful TANGO tool.

2

The evaluations presented in all the tables are based on the tests. The classification rate spans from 1 (maximum difficulty or lowest quality) to 4 (minimum difficulty or highest quality).

The communication set-up when using OPC (Arch-3 and Arch-4) required a special care. With FTV-SE and PVSS the DCOM (Distributed Component Object Model) settings had to be changed in order to cope with the MS Windows Access Permission system. No particular DCOM setting was required with EPICS, but it was necessary to install the OPC libraries (OPC Core Components 3.0 Redistributable [7]) and the EPICS OPC Device Support distribution, developed at the BESSY Synchrotron [10]. With TANGO the Device Server available in the official TANGO repository [11] was used to communicate with the OPC server. The evaluation of the technical difficulties encountered to install the SCADA packages and the overall estimation of the efforts necessary to develop an application are supplied in Table 4, together with the Average Time for Development (ATD), an estimation of the time necessary to one person to develop autonomously and efficiently a simple supervision system. The easiness of the PVSS installation is due to the fact that what is needed is included in just one DVD. All the PVSS tools and libraries are normally installed in the PC and the choice between the different project types (Standard Project, Redundant Project, Distributed Project, etc.) is possible during a project’s creation, starting from the PVSS Project Administrator application. The EPICS installation was relatively trouble-free, thanks to the detailed documentation, and no particular settings were required. TANGO is supported by a complete documentation and its installation is simple too. Several graphical programming tools are available to help a user build up a system. The internal communication layer, based on CORBA (Common Object Request Broker Architecture), is totally transparent to the user.

4. Performance To evaluate the SCADA performance, it was chosen to analyze the network traffic during data dispatching from the PLC to the SCADA client. While the PLC was continuously changing its data with a cycle time of 50 ms, the data acquisition was regulated using the polling technique; the polling time was a pre-set SCADA parameter. The polling times used with Arch-1 and Arch-2 were: 1 s, 500 ms, 250 ms and 100 ms. Just one polling time was employed with Arch-3 and Arch 4: 100 ms. 200 variables of double-integer type (4 bytes) were read from the PLC. The results supplied hereafter concern only Arch-2 and Arch-4, since they are the most interesting from a network-load point of view. Tests with Arch-1 and Arch-3 were nevertheless performed since they were useful to get acquainted with the SCADAs and since they allowed comparing the network traffic with respect to Arch-2 and Arch-4.

Table 4 Evaluation of the technical difficulties encountered to install the SCADA packages and to develop an application (best score is 4, worst is 1). ATD is the Average Time for Development (see text) and the measurement unit is “weeks”.

Installation Application development ATD [weeks]

FTV-SE

PVSS

EPICS

TANGO

3 3 2

4 3 2

3 3 3

4 2 3

494

O. Barana et al. / Fusion Engineering and Design 85 (2010) 491–495

order of magnitude); this result was obtained with a better data organization internal to the Device Server, which was developed by us and therefore very well know. The data-exchange mechanism through OPC of the other SCADAs had not been deeply investigated, but the measurements obtained, which are more or less comparable in terms of order of magnitude, make us think that the other SCADAs were using a data-access method to the OPC server different from, and therefore not comparable to, the TANGO one. Concerning the communication from PCO to PCS or PCC (Arch-3 and Arch-4), it was noticed that each SCADA accumulated on average a delay of 100 ms per second. This is not really an issue, since the situation of 200 variables changing every 100 ms in not very realistic (it was decided to implement it just to test the system in “stress” conditions). Anyway, a means of avoiding such a situation would be that of adopting a distributed architecture, splitting the SCADA system in several subsystems, each devoted to a well-identified part of a plant.

5. Conclusions Fig. 2. SCADA network load with Arch-2. The full lines represent the overall network throughput while the dashed lines characterize the throughput from PCS to PCC . A fixed amount of 200 double-integers (4 bytes) data is read from the PLC.

It is worth considering Fig. 2, which shows the network throughput for all the test-beds with Arch-2. In particular the full lines represent the overall network throughput while the dashed lines characterize the throughput from PCS to PCC . It is clear that the greatest contribution to the overall traffic is given by the data flow from PCS to PCC . TANGO and FTV-SE result the most efficient SCADAs in terms of network throughput. The network throughput in the communication from PCC to PCS is not represented because negligible with respect to the other quantities. The points at 1 s for TANGO have not been represented because the two measurements are missing. Fig. 3 shows the comparison of the network throughput for all test-beds (except TANGO) with Arch-4, where only data at 100 ms are available. The traffic from PCO to PCS , from PCS to PCC and from PCC to PCS is shown. The TANGO performance is not represented because its measurement is not comparable with the other SCADAs, being much better (the represented quantities differ of about one

The SCADA choice for SPIDER will be made not only taking into account the test results and the following considerations, but it will be also dictated by the short time available for the development of the SPIDER control and data acquisition system, whose operation at full capacity is scheduled in 2013. FTV-SE is a very good product in terms of easiness of development, features and graphical quality. Nevertheless it will have to be discarded, mainly because of the CODAC choice in terms of PLC brand, which was made public after the end of our tests. Indeed FTV-SE performs very well when exchanging data with PLCs from Rockwell Automation, but it needs an intermediate layer (Kepware technology) to communicate with third-party devices. It is also currently limited to the MS Windows operating system. About TANGO, its richness of tools and the possibility of customizing a system writing code with effective and multi-platform object oriented programming languages like Java, C++ and Python make it a very appealing product. Nevertheless the comprehension of its structure requires more efforts than the other SCADAs and a strong programming skill is needed. A special effort is necessary to implement the data exchange in an efficient way. These latter issues mainly contribute to discarding this package. The choice will therefore eventually be between the PVSS and EPICS SCADA packages. The case study showed that, in terms of test performance, the two SCADAs are basically equivalent. PVSS proved better in terms of communication set-up, also thanks to the availability of a user interface from where to choose, for instance, the driver and polling group to be associated with each variable, whereas the communication in EPICS had to be configured through script files. The EPICS network performance was better than the PVSS one, but this might not be a crucial issue, considering the loose SPIDER requirements in terms of PLC data throughput. On one side EPICS could be favoured, because it is the CODAC group choice, it is open-source and open-licensed and it does not depend on market policies. On the other side ETM supplies comprehensive training courses, PVSS is provided with a better documentation and is strongly supported by CERN [12].

Acknowledgment Fig. 3. Comparison of the network throughput for all test-beds (except TANGO) with Arch-4, where only data at 100 ms are available. The traffic from PCO to PCS , from PCS to PCC and from PCC to PCS is shown. A fixed amount of 200 double-integers (4 bytes) data is exchanged through the OPC server.

This work was set up in collaboration and financial support of Fusion for Energy, under F4E Grant No. F4E-2008-GRT-011-01 (PMS-H.CD).

O. Barana et al. / Fusion Engineering and Design 85 (2010) 491–495

References [1] R.S. Hemsworth, Long pulse neutral beam injection, Nucl. Fusion 43 (2003) 851–861. [2] ITER CODAC home page [Online]: http://www.iter.org/org/team/chd/cid/codac/ Pages/default.aspx. [3] EPICS home page [Online]: http://www.aps.anl.gov/epics. [4] TANGO home page [Online]: http://www.tango-controls.org. [5] A. Daneels, W. Salter, Selection and evaluation of commercial SCADA systems for the controls of the CERN LHC experiments, in: Proceedings of 1999 ICALEPCS Conference, October 4–8, 1999, Trieste (Italy), 1999. [6] LHC home page [Online]: http://lhc.web.cern.ch/lhc/.

495

[7] OPC Foundation home page [Online]: http://www.opcfoundation.org. [8] J. Brahy, TSPP UNICOS Manager, LHC Project Document, 2005. Available online at http://ab-project-unicos.web.cern.ch/ab-project-unicos/. [9] EPICS at SLS [Online]: http://epics.web.psi.ch/software/s7plc/. [10] EPICS OPC Device Support at BESSY GmbH [Online]: http://www-csr. bessy.de/control/SoftDist/OPCsupport/. [11] TANGO repository at Sourceforge.Net [Online]: http://tango-ds.cvs. sourceforge.net/. [12] E. Blanco, Ph. Gayet, LHC cryogenics control system: integration of the industrial control (Unicos) and front-end software architecture (FESA) applications, in: Proceedings of 2007 ICALEPCS Conference, October 15–19, 2007, Knoxville, TN (USA), 2007.