Conceptual Design of an Open Source SCADA System

Conceptual Design of an Open Source SCADA System

Conceptual Design of an Open Source SCADA System C.R. Rocha1* and M.V. Scholl2 1

Industrial Automation Department Federal Institute of Education, Science and Technology of Rio Grande do Sul – Rio Grande Campus Rio Grande, RS, Brazil

2

Software Analysis and Development Course Federal University of Rio Grande Rio Grande, RS, Brazil

ABSTRACT This work concerns the initial stages of the development process of an open source Supervisory Control And Data Acquisition System (SCADA) software. The motivation for this software is the increasing adoption of low cost, low processing power platforms for simple automation applications and scientific experimentation. The initial design process results – software requirements and a conceptual design that meets them – are presented here. Other design choices, such as the implementation platform are discussed. Also, an experimental target hardware platform is depicted, based on the authors experience with open source hardware.

1. INTRODUCTION SCADA (Supervisory Control And Data Acquisition) systems are essential components of modern industrial automation. This category of software is widely used to monitor and operate industrial plants from a central station, regardless its size or the distance of the equipment and sensors. Besides industrial applications, SCADA systems are employed in other areas, such as the power generation/distribution, building automation/surveillance and automatic data acquisition in scientific research [1-3]. Local and remote data acquisition is a key feature of these systems, usually made by communicating with Remote Terminal Units (RTUs) or Programmable Logic Controllers (PLCs) [1, 3]. Data can be automatically stored and monitored, with alarms that can be set to notify abnormal behaviour to operators, allowing them to take actions in such cases. Also, the history of the plant operation and status provides relevant data to the manager and administrative levels to support planning and decision making. Other important feature is the Human-Machine Interface (HMI), which is used by operators to interact with the system, not only by monitoring data, but also to exert high-level control actions to the plant. Due to this large adoption of SCADA software and the increasing complexity/size of the plants where they are used, most of the currently available products become complex and computer resources demanding systems. For instance, client-server architectures with redundant hardware/software are common in industry. This limits the use of recent versions of SCADA in small/simple applications. Eventually, the costs involved and the complexity to configure the system prohibit its use for data acquisition and monitoring in small cases such as in scientific experiments. The idea of developing an open source SCADA system was motivated by these needs, and by the growing adoption of relative low-cost/power computer architectures such as the Raspberry Pi [4] along with open/physical computing hardware as the Arduino [5] for automation applications. The low cost, accessibility and large knowledge base available for this kind of hardware and for low cost sensors/actuators turn them interesting for prototyping and experimentation, not only for amateurs, but for the development of scientific and commercial applications. This work presents the results of the initial design process of this open source SCADA software. Based on the design macrophase of the PRODIP (Integrated Process of Product Development) model [6], an informational design process was executed to identify the system requirements. This was followed by the conceptual design development, where an object-oriented structural model to cope with the previously defined requirements was obtained.

* Corresponding author: Tel.: +55(53)3233.8708; E-mail: [email protected]

Flexible Automation and Intelligent Manufacturing, FAIM2015, Wolverhampton, UK

In the next section, informational design results are analyzed. The following section presents the conceptual design result, which consists of a structural object-oriented model and the definition of the software modules. Afterwards, choices for software development and an experimentation platform are discussed. Finally, conclusions are presented.

2. INFORMATIONAL DESIGN Although the PRODIP model was intended for the development of products for industrial manufacturing, the design macrophase can be adapted to different domains, such as software development. Its initial part is the informational design, where the product features must be identified and understood. It is formed by a series of activities which aim to produce design specifications from the user needs and desires for the product [7]. To start the process, a survey of SCADA products currently used by local/regional industries and in the industrial courses in IFRS (Federal Institute of Rio Grande do Sul) and FURG (Federal University of Rio Grande) was made. It was observed that mostly Brazilian software was used, such as Elipse SCADA/E3 [2], Novus Superview [8] and SCADA BR [9]. These and other products such as Siemens WinCC [10] were analyzed in order to identify usual characteristics and features of SCADA. 2.1. SCADA MODULES It was observed that these products have usually three modules, which can be grouped into single software or divided into three or more software. They are the runtime, the design and the client modules. The runtime module is responsible for data exchange with RTU/PLC, continuously executing scan cycles where communication with the remote data acquisition/command hardware is made. Also, data is stored and analyzed according to alarm conditions, scripts and events defined by users. Also, a parser component is responsible for loading SCADA configuration from files. The design module is used to define the configuration for a particular SCADA application. This consists in the definition of communication parameters, variables, alarms, events and scripts needed to use the SCADA to monitor and control the plant. Also, this module is usually where the HMI is defined by creating screens with widgets that are used to display data and interact with the user. The configuration is stored in files in order to be loaded by the runtime and client modules. So, the design module is not needed for normal execution of the application. Although there are several products where proprietary file formats are used, there is a clear tendency to adopt open/legible file format descriptions, such as the ones based on the standardized Extensible Markup Language (XML) [11]. The client module interacts with the user. It is the one that displays and controls screens used by operators to supervise and control the plant. Screens are usually defined previously in the design module according to the nature of the plant to be commanded. The widgets in screens are linked to internal variables to display its data using text (display) or graphical representations (gauges, animations). Also, there are widgets which can be used to interact with the system to start actions/events (buttons) or modify parameters/setpoints (sliders, dials). Figure 1 illustrates some of the usual widgets found in SCADA systems.

Figure 1: Widgets usually found in SCADA software (based on Qwt) [12]

Conceptual Design of an Open Source SCADA System

In some products, client and runtime modules are integrated, since they are used on a single workstation. When size and complexity of the application grows, however, it is usual that the runtime executes independent from the client. In these cases, it is usual a client-server approach, where the HMI is the frontend, running in workstations and communicating with the runtime on servers as the backend. A hybrid approach is also used when the application is small, but there is need to remote supervision. Also, the expansion of mobile computing motivates the development of web/mobile user interfaces, such as the Elipse Mobile software [2]. 2.2. SCADA COMPONENTS From the survey, SCADA application components were enlisted. Though there are some terminology differences between products, classes of components are easily grouped based on function and characteristics. So, a typical SCADA application has: 

Tags: These components store data in memory. The term is related to the instrumentation area, and it is applied not only from the data provided by the plant hardware, but also for application variables. Usual data types provided by RTU/PLCs are boolean (on/off) or integer. However, most recent hardware also deals with real (fixed precision or floating point), time and textual types. So, tags must be able to handle those different data types, along with different data sources. Some products also offer simulated tags (or demo tags), where the value of them vary according to some function over time, which is interesting during the application development;



Drivers: SCADA applications must use the proper communication protocol to exchange data with external hardware. There are a large number of equipment available, each one using proprietary/exclusive protocols or one of the different standard protocols, as Modbus [13] for instance. So, to cope with different possible protocols without having to load all of them in an application, a solution is to use drivers, which are loadable modules that manage a particular communication protocol/equipment. Usually, tags are linked to the driver that handle the communication with the remote equipment which provides the data they store;



HMI: The human-machine interface of a SCADA application is comprised of screens which contain widgets. These widgets can be linked to tags to display their data or to modify them. Also, screens and widgets can be used to display alerts and to respond to user or plant events. There can be a variety of widgets with different appearance and behavior, sometimes reflecting the appearance of physical instruments. Some of them are shown in Figure 1;



Alarms: These components are related to tags, in order to automatize its monitoring. An alarm usually has some predefined condition, such as the allowed value range for the tag, or a boolean expression which is evaluated every time the monitored tag modify its value. An alarm can fire events or, if it is linked to some widget, can show some alert in the HMI;



Loggers: The plant operation history is handled by this type of component. It can be stored in single files or in DBMS (Database Management Systems), and for each storage type a specialized logger must be used. In some products, they have different names according to their function, with History referring to the record of tags and Log referring to the record of alarms and events;



Scripts: There are situations where an action to be executed involves several components, or the normal behavior of tags, alarms and widgets are too simple. So, SCADA software provides a way to define command scripts to be executed when an event occurs. The script language can be based on an existing programming language or exclusive to the product. Eventually, graphical assistants are available to define the desired logic.

2.3. TARGET PLATFORMS The initial motivation for the software development was its use in data acquisition/monitoring in scientific experiments and simple automation using low cost microcontroller prototyping boards as the Arduino. The SCADA software would run on a microcomputer under Windows®, Linux or MacOS®. The development of an embedded HMI interface for an Unmanned Underwater Vehicle (UUV) based on the Raspberry Pi provided additional interest for a SCADA which could run on low power embeddable computer platforms [14]. These computer boards usually run some flavor of Linux or other Unix-like operating system (OS). In order to execute both in usual microcomputers and in these boards, the SCADA software must be OS independent. Also, the IHM must use a multiplatform GUI (Graphical User Interface).

Flexible Automation and Intelligent Manufacturing, FAIM2015, Wolverhampton, UK

2.4. SOFTWARE REQUIREMENTS AND DESIRED FEATURES The information obtained from the survey and the analysis of SCADA software were combined and pondered using design tools such as sort matrices and quality function deployment method [6, 7]. This resulted in the following design specifications: 

Low-demanding: since it should run in low power computational platforms, the software must be as little demanding as possible;



Multiplatform: the software must run in different computational platforms, running different operating systems;



Availability of components: basic components such as tags and drivers are mandatory. However, the software must have alarms and log features; log must be able to be stored in text files and in databases;



HMI: The user interface must have a minimal set of widgets to display data and to interact with the user;



Modularity and extensibility: new components should be easily added to the software, allowing its evolution.

It must be noted that the runtime and the client modules are essential to the present software. The design module is a desired feature, but if the configuration is stored in a standardized textual file format, it can be possible to manually define a SCADA application using a code editor. So, the design module could be a future implementation. Regarding communications with remote hardware, it should be implemented at least a textual and a common open protocol as Modbus. Besides boolean and integer data types, it should be possible to communicate real, string and timestamp data, at least.

3. CONCEPTUAL DESIGN The conceptual design process aims to produce a conceptual model that satisfies the design requirements previously obtained in the informational design phase. The software functional components were identified and different structural models for them were devised by analysis activities. Those were combined by synthesis activities and the feasible ones were compared to choose a solution which was best suited to the design requirements and other software desired features, such as modularity, maintainability and development practices. The adoption of an object-oriented approach to the software modeling was based on the modularity and extensibility requirements, the vast knowledge base available, the diversity of development platforms and the experience of the authors. Unified Modeling Language (UML) was a natural choice to model the software. Figure 2 illustrates the basic software structure in a class diagram.

Figure 2: General class diagram of the SCADA software

Conceptual Design of an Open Source SCADA System

Classes are grouped in packages according to their function in the software. The essential classes for executing an SCADA application are in the app package. The comm package has the communication driver classes. The user interface is based on the hmi package classes. Data and event record are responsibility of log package classes. The aux package comprises auxiliary classes to the SCADA. These packages are detailed in the following. 3.1. APP PACKAGE The app package contains the minimal classes that are needed for executing a SCADA application. The main class is the SCADAApp. There is only one instance of it at any time, which is responsible for the program initialization and the subsequent application loop, where the scan cycles are executed followed by screen updates and log of relevant data. Also, it is a container for objects that compose the application. The tag class has the responsibility of storing data, which can be originated from the remote hardware such as RTU/PLCs, or memory variable data, used for auxiliary purposes or simulations. Different data access is managed by specialized classes such as CommTag and VarTag. Also, for simulation purposes, DataGen instances can be used, which provide data according to some function in a scan cycle. Alarm instances are used to fire events according to evaluation rules for tags, such as change in value or valid range. Script instances store commands which are executed according to events fired by alarms. Figure 3 depicts the app package classes in detail.

Figure 3: app and comm packages

3.2. COMM PACKAGE Figure 3 also depicts the comm package classes, which manage communications with remote hardware data providers. The Link class defines the application interface and derived classes implement specialized communication protocols as ModbusLink and ASCIILink, for instance. The latter class implements a simple textual protocol, which depends of ASCIIParser instances to analyze and extract data from the messages. A Link instance connects with one remote hardware at a time, and can provide data for several CommTag objects. The LinkFactory class is used to abstract the instantiation of Link specialized objects by implementing the factory method design pattern [15]. 3.3. HMI PACKAGE The hmi package contains the classes used to create the user interface. It is composed by different screens, which one containing widgets connected to tags by adapters. The Screen class represents the screens. Widget is the base class of specialized widgets according to their functionality. Adapter instances connect widgets to tags, transforming the values according to different rules, in order to easy scaling or boolean-to-integer conversions. Basic widgets to be implemented are similar to those shown in Figure 1. To ease the implementation, existing GUI library classes can be extended/adapted to the SCADA application needs. Figure 4 shows a possible widget class hierarchy and other classes. 3.4. AUX PACKAGE This package contains accessory classes to the other classes. The Event class defines the behavior of a hierarchy of different event types. To load a particular SCADA application from XML files, the SCADAParser and associated classes (CfgParser and HMIParser) are used to analyze the file contents, create the application components and initialize them. The Timer class can be used to schedule events to be fired at a certain amount of execution time, repeatedly or not. These classes are also shown in Figure 4.

Flexible Automation and Intelligent Manufacturing, FAIM2015, Wolverhampton, UK

Figure 4: hmi and aux packages

3.5. LOG PACKAGE The log package has classes used to record data and messages to storage recipients such as text files and databases. From the logger base class, specialized classes are derived, each one aimed to manage a different kind of storage recipient. The TextLogger class aims to record data in text files, while DBLogger instances manage relational database management system connections. These classes were already shown in Figure 2. 3.6. REMOTE USER INTERFACE FOR SUPERVISION/CONTROL In order to ease the initial implementation of the SCADA software, the hmi package deals with graphical desktop screens only. However, it is important to consider the increasing interest in remote monitoring/control based on web interfaces and mobile devices. A remoteClient package was devised, but was not included into the main class diagram. It contains a DataProvider class, which is used to communicate with the remote user interface using web services and a ScreenProvider class, which provides the screens to the remote devices. Figure 5 shows this package. This will be object of future work, since it will require further research into mobile technologies not considered in this work.

Figure 5: remoteClient package

4. DESIGN CHOICES FOR SOFTWARE DEVELOPMENT The choice of computational platform used to develop the SCADA software were based on the design requirements and desired features identified in the informational design phase and in the conceptual model. The licensing type was also considered, since the software will be licensed as free software. A comparison between possible implementation platforms is presented in Table. 1. These options were considered due to their availability in the target platforms, their use for development of scientific/industrial software and the authors experience. Each line corresponds to a characteristic to be evaluated. After comparison and research for available resources, Python was chosen [16].

Conceptual Design of an Open Source SCADA System

Table 1: Style and font size for printer-ready papers Platform

C/C++

Java

Python

Object-oriented

Yes

Yes

Yes

OS independent

No

Yes

Yes

Extensible

Yes

Yes

Yes

Multiplatform GUI

Yes

Yes

Yes

Communications library

Yes

Yes

Yes

Database interface

Yes

Yes

Yes

Lightweight applications

Yes

No

Yes

Embeddable scripting

No

Library dependent

Yes

Dynamic runtime

No

No

Yes

License

Open/Free Software

Open/Free Software

Open/Free Software

Regarding the user interface, it was observed that many widgets were already available in the Qt library, which is OS-independent [17]. In particular, the Qwt (Qt Widgets for Technical Applications) library [12] provides several widgets commonly used in SCADA supervisory screens, which can be directly used or easily adapted. So, this defined the GUI library to be used. To develop the application, the Spyder IDE (Integrated Development Environment) is being used. Also, Qt Designer is being used to graphically define the user interface. To describe the SCADA applications definitions/configurations, XML was chosen. It is a textual, standardized markup language. Also, it is the same format used by the Qt Designer, which can easy the integration between the runtime and the client applications. Regarding the modules to be implemented, it was decided that the runtime and the desktop client ones were priority. Since it is relatively simple to work with XML files using a text editor and the screens could be graphically designed using the Qt Designer application, the designer module could be developed when the other modules are stable.

5. EXPERIMENTAL TARGET PLATFORMS The initial hardware platform to be used during the development of the SCADA software is based on a conventional microcomputer running Microsoft Windows® and Linux. An Arduino board will be connected in an USB port to work as a RTU. To communicate with the RTU, a textual protocol and a minimal Modbus protocol driver will be available. Also, further communication tests will be conducted using a PLC and the Modbus driver. The hardware originally designed for the embedded HMI interface for the UUV experimental platform [14] will also be used to test the software functionality in low processing power platforms and its multiplatform characteristics. In consists of a Raspberry Pi board running Raspbian, a linux distribution [4], connected to an Arduino board with different sensors attached to it. Little modifications to the platform will allow it to command actuators such as LEDs and motors. A 10” LCD screen with 1200x800 pixels resolution and a wireless mini keyboard will be also available to test the SCADA user experience. Figure 5.a displays a schematic view of the hardware, and Figure 5.b is a picture of the partial assembly of the hardware. It must be observed that these are not the only hardware/OS for which the SCADA software is being developed, but it is an initial set for testing during development. Multiplatform is an important software requirement and an objective to be pursued.

6. SUMMARY This work presented the initial design process of a SCADA software aimed for small/simple automation applications and scientific experimentation which run in microcomputers and in low power computer platforms. The result of this initial process was a conceptual structural model for the software and the choice of software development tools and experimental hardware platforms to test it.

Flexible Automation and Intelligent Manufacturing, FAIM2015, Wolverhampton, UK

Figure 5: Mission Monitoring/Control hardware for the UUV: (a)Schematic view; (b) Partial assembly

The software is currently being implemented as a final work project for the Software Analysis and Development undergraduate course by one of the authors (Scholl), which is advised by the other one (Rocha). The initial operational version will be readily available as open source software in a proper repository in order to contribute with the physical computing and open source community. The authors believe that it will be a contribution to the academic community, to aid the automatic/remote experiments supervision using a low cost platform which had few software to that end. Future work concerns enhancements to the software and the analysis of its evolution due to further developments from the open source community.

REFERENCES [1]

D. Bailey and E. Wright, Practical SCADA for Industry, Elsevier, 2003.

[2]

http://www.elipse.com.br/eng/index.aspx/ (accessed January 4, 2015).

[3]

S. A. Boyer, SCADA: Supervisory Control And Data Acquisition, 4ed. ISA, 2009.

[4]

http://www.raspberrypi.org (accessed January 4, 2015).

[5]

http://arduino.cc (accessed January 10, 2015).

[6]

N. Back et al., Integrated Design of Products: Planning, Conception and Modeling – Projeto Integrado de Produtos: Planejamento, Concepção e Modelagem, Manole, 2008.

[7]

A. J. H. Fonseca, Systematization of The Design Specification Process of Industrial Products and Its Computational Implementation - Sistematização do Processo de Obtenção das Especificações de Projeto de Produtos Industriais e Sua Implementação Computacional, PhD Thesis, Federal University of Santa Catarina, Florianópolis, 2000.

[8]

http://www.novus.com.br/catalogos/?ID=518254 (accessed January 4, 2015).

[9]

http://www.scadabr.org.br/ (accessed January 4, 2015).

[10] http://w3.siemens.com/mcms/human-machine-interface/en/visualization-software/scada/simatic-wincc/Pages/default.aspx (accessed November 25, 2014). [11] http://www/w3c.org/XML/ (accessed November 20, 2014). [12] http://qwt.sourceforge.net/ (accessed December 18, 2014). [13] http://modbus.org/ (accessed November 03, 2014). [14] C. R. Rocha et al., “Design Aspects of an Open Platform For Underwater Robotics Experimental Research”, Proceedings of the 14th Mechatronics Forum International Conference, Karlstad, Sweden, 2014. [15] E. Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994. [16] https://www.python.org/ (accessed January 22, 2015). [17] http://qt-project.org/ (accessed January 22, 2015).