Performances Analysis of a SCADA Architecture for Industrial Processes

SCADA (Supervisory Control And Data Acquisition) systems are used to monitor and control various industrial processes, and have been continuously developed in order to incorporate the new technologies from software development and field busses areas. The middleware communication has the most relevant role in the development of such complex distributed systems as SCADA systems. These systems are very complex and must be reliable and predictable. Furthermore, their performance capabilities are very important. This paper presents a performance analysis of a SCADA system developed for Windows platform, including Windows Compact Embedded. The analysis is focused on the performance difference between computing systems based on Windows desktop and Windows CE operating systems. The utilization of the Windows CE is useful on the application with real-time requirements that cannot be achieved by the Windows desktop. Testing the application and analyzing the results led to the validation of the proposed SCADA system. Keywords—SCADA systems; middleware; data acquisition; data stream; distributed systems


I. INTRODUCTION
In the last decade, the SCADA systems that are found anywhere have been developing exponentially by including the new efficient and reliable technologies from the IT&C field.The SCADA applications are complex systems that acquired data from one or more local and remote processes.Furthermore, a SCADA system can control these processes by sending commands to the actuators depending on the type of process [1].This system has the advantages of increases efficiency and profits and lowers costs.
A human operator can use this distributed system to remote monitor and control of the industrial processes, by using the HMI (Human Machine Interface) [2] provided by the SCADA system.This interface allows the handling of data related to that application (data acquired from the processes and the commands sent to the processes).
The most common areas of applicability for SCADA systems are the following: telecommunication systems [3], [4], power distribution systems [5], energy transmission systems [6], oil industry [7], gas and natural gas extraction, ore extraction systems, storage systems [8], irrigation systems [9], water distribution systems [10], sewerage systems, parameters measuring equipment for fluids, hydroelectric systems [11], monitoring systems for a production line or an entire company [12], monitoring systems for a building or a building complex, etc.
In this paper, it is analyzed a proposed new architecture of a SCADA system.The analysis focuses on the performance achieved with different data volumes and different operating systems.
Furthermore, this paper is organized as follows: Section II presents the most important specifications launched for the industrial field and the main manufacturers for the SCADA applications; Section III describes the architecture of the SCADA system; Section IV focuses on several considerations regarding the implementation; Section V highlights the experimental results obtained, whereas Section VI finalized with conclusions.

II. RELATED WORK
Over the years, a wide variety of applications have been developed to achieve the data exchange between two devices or between a device and a software application using the clientserver or peer-to-peer paradigm (M2M -Machine to Machine and D2D -Device to Device).In turn, the applications using the specifications launched by the OPC Foundation have a unified view [13].These specifications are the following: OPC (Object Linking and Embedding for Process Control) Data Access, OPC Alarm and Events, OPC Historical Data Access, OPC Unified Architecture, OPC .NET (previously called OPC eXpress Interface -XI) [14].Depending on the type of architecture they use, these specifications have been divided into: OPC classicbased on DCOM (it includes: OPC Data Access, OPC Alarm and Events, OPC Historical Data Access), OPC Unified Architecture and OPC .NET [15].
Due to this unified vision, the OPC specifications have become widely known and used by most of the production systems as the following: MES (Manufacturing Execution System) systems, HMI/SCADA systems and ERP (Enterprise Resource Planning) systems.www.ijacsa.thesai.orgCurrently, SCADA applications used in industry are being produced by many manufacturers, such as the following: Siemens, ABB, Emerson, Rockwell Software, Schneider Electric, Matrikon, B-Scada, Iconics, Intellution, Indusoft, Mitsubishi Electric, Yokogawa Electric, Honeywell, WonderWare, Omron, Citect, GE/Fanuc, USDATA, National Instruments, and Think & Do.However, each of the application developed by the manufacturers mentioned above, is targeted for certain issues and for some devices.

III. ARCHITECTURE OF THE PROPOSED SCADA SYSTEM
In order to implement a monitoring and control system of some industrial processes, the main functions that a SCADA application must consider are the following: 1) Data acquisition -It refers generally to acquiring data from a process, either as inputs or outputs, or even data that change during the process.
2) Communication/Data transfer over the network -It is related to the "transport" of data towards the Master station and vice versa (from the Master station towards the process).An important role is played by the communication network that must be well developed, flexible and easy to remodel.
3) Data presentation -It can be seen by the human user through a graphic interface located on the Master server.It presents an overview of the monitored process, it alerts the human operator if certain limits are exceeded, it processes the data collected from the process, it details the information at the command of the user, and keeps record of all the logs.
4) System Control -Represents the manual or automated configuration of the system, depending on the parameters and events that have been generated.This function can only be performed with the help of the human operator (the user), and the communication environment between the operator and the system is represented precisely by the interface of the SCADA system.This interface displays real-time process data, and the system is controlled by entering commands or messages for the process.
All these four important functions of a control and monitoring system intertwine at the most important level that is middleware level.In fact, this is where the data exchange is performed.
Starting from the proposed architecture presented by the Gaitan et al. in [16] the system is an industrial process to monitoring and control, designed and developed to meet the requirements of a complex system called the Metropolitan Heterogeneous System for Monitoring Utility-Specific Data (SMEDU).
The architecture of this system is presented in Fig. 1 and contains two software modules, namely: the client module and the server module; the middleware bus connects the two modules [17], [18].
The client module is an executable software module, called MCIP (Monitoring and Control of Industrial Processes) [19], after the role it has to fulfill within the proposed SCADA system.This is in fact a standard communication interface through which the user (the manager of an enterprise or a production line) can create and organize all the objects needed in the managed industrial process.The MCIP application presents two working modes:  The first is the working mode, enabling the implementation and modification of the project.This working mode is performed when the application is unplugged from the servers.Basically, in the editing mode, the user can add as many graphic objects as he needs in the process, connecting them to the real devices to be monitored.Also, he can set certain features, and has the possibility to change or delete objects.The types of objects used are: graphic objects for displaying texts or images, template objects, control objects and middleware interfacing objects, through which the human operator can access the values in the process.
 The second working mode is the execution mode.In this case, the application executes what has been designed in the editing mode.The middleware bus is a software bus connecting the client mode to the server mode.Here, we can find some middleware technologies from the ones mentioned above, namely: COM/DCOM, CORBA, .NET technology, Web Services, but also others.These technologies must ensure the client-server communication in all possible cases.The server module is also an executable software module that brings together, through standard communication interface, a variety of servers with the data acquisition software component, the object dictionary, the network manager, the database and the device drivers.

Middleware BUS
Within the server module, there may be several types of servers that use different specifications, but also serve a wide range of activities.For example, the most common types of servers are: data access servers, alarms and events servers and history servers.
The data dictionary, which can be found at the level of the data acquisition software, is nothing more than a hierarchical organization of the process data.Its most important feature is the uniformity of the data presentation, namely, it remains the same for any type of server used.
The server application also includes a standard interface for connecting to the database, as well as to the network manager.

IV. THE IMPLEMENTATION OF THE PROPOSED SYSTEM
As mentioned in the previous sections, the proposed system has been designed according to the client-server model and contains two software modules, namely: the MCIP client and the gpDAServer [19] data server.
Each of these has been designed so that in the end it could be easily installed and used by any device in the industry.Therefore, in the end, the two software modules will be executable.
The server module was developed in C++, and the MCIP client was developed as an application in C # (using the .NET platform).
When implementing both modules, the following aspects have been considered:  The data provided by a server can be retrieved by as many middleware objects need that data.
 A server can connect to as many local industrial networks as possible.
 At the level of the data dictionary, the most important thing is the uniformity of the data presentation.In other words, all servers must have the same data and in the same mode.

V. EXPERIMENTAL RESULTS
In order to validate the proposed system, a total of four tests have been performed on two similar star architectures.The differences between the two test architectures are the type of system used (real time or not) and the implementation mode for each individual case.
The first architecture consists of 7 test stations and a Master station (8 PCs with Windows XP/7/8/10 operating systems) connected in a TRENDnet TEG224WS+ switch, with a 100Mbps Ethernet interface.This test architecture is presented in Fig. 2.
The second test architecture consists of 6 embedded eBox 2300 SX systems, 1 embedded PDX 089T system with Windows CE real-time operating system, a Master desktop PC (the same as in the first test architecture) and a Super Stack II Baseline 10/100 Switch.This test architecture is presented in Fig. 3.A MCIP client application and a server application have been installed on each of the other 7 systems (either the 7 PCs in the case of Test Architecture 1, or the 7 embedded eBOX or PDX embedded systems in the case of Test Architecture 2).These were launched in execution, and a process and the objects required for test have been added to each MCIP application.In this way, the client application has connected to the server through a OPC middleware object, thus managing to read or even write data.Through this object, it was possible to set an update rate required for reading and writing data.
In terms of transmission rates, the test range was of 100ms (0.1seconds) to 1000ms (1 second).Also, for each OPC object, the data transfer speed for 1 item, 5 items, 10 items and 15 items has been tested.Fig. 4 shows the chart of experimental results obtained by testing the Test Architecture 1 at different refresh rates and for a different number of items in a group.Similarly, tests have been performed for Test Architecture 2 and the experimental results are shown in Fig. 5.
In order to facilitate the analysis and interpretation of data obtained from the experimental tests, a comparison has been performed between the data resulted from the tests performed on the two operating systems (Windows XP and Windows Embedded CE), using identical parameters.
The analysis of the experimental results chart in Fig. 3 shows a tendency to decrease the data transfer speed once with the increase of the update rate.
The analysis of the experimental results chart in Fig. 4 also shows a tendency to decrease the data transfer speed once with the increase of the update rate.Also, there is a minor difference between the data transfer speed of the two tested operating systems.This difference may be due to the fact that the server, at a certain point, might not perform exactly the update rate, because the CPU is overloaded.The update rate is performed on the server, because it calls a callback function in the MCIP client application.
Another explanation might be the implementation mode of the TCP/IP stack for the Windows Compact Embedded (CE) operating system.It can also be noticed that, at high update rates, the data transfer speeds in the case of Windows CE tests are close to the values obtained for Windows XP.
In conclusion, following the tests carried out on the two architectures and the analysis of the experimental results, the proposed model and solutions have been validated.

VI. CONCLUSIONS
The need to have more and more efficient and reliable systems led to the rapid development of SCADA systems.However, there is not yet an architecture pattern that can be used by all types of SCADA systems and that can meet all requirements.
The system proposed in this article attempts to satisfy these needs.This is why it has been designed to be easy to use and improvable by adding new components or features that might completely change the context.This paper presented the performance analysis of a SCADA application that is executed on a computing device based on Windows desktop and Windows CE operating systems.We can conclude that the Windows CE can be used at the application with real-time requirements, which cannot be achieved by the computing systems based on Windows desktop.
As future work, we intend to develop the proposed system to approach other technologies.We also want to port the server application on a real-time system (Linux RTAI or Windows Compact Embedded).


A middleware object can connect to a single server placed on the same computer as the client application or any other computer in the network that supports the same middleware technology.If we are dealing with different computers, we have two possible cases: the two devices are in a LAN (local connection) or the two devices are connected to the Internet (this time, the connection is remote).