2015 IEEE International Conference on Smart City/SocialCom/SustainCom together with DataCom 2015 and SC2 2015

Moving SCADA Systems to IaaS Clouds

Philip Churcha,c, Harald Muellerb, Caspar Ryana, Spyridon V. Gogouvitisb,
Andrzej Goscinskia,c, Houssam Haitofb, Zahir Taria
aSchool

of CS and IT, RMIT University, Melbourne, Australia,

Email: philip.church, caspar.ryan, andrzej.goscinski, zahir.tari@rmit.edu.au
b

Corporate Technology, Siemens AG, Munich, Germany

Email: h.mueller, gogouvitis, houssam.haitof@siemens.com
c

School of IT, Deakin University, Waurn Ponds, Australia

Email: ang, chphilip@deakin.edu.au

AbstractSCADA systems allow users to monitor and/or

control physical devices, processes and events remotely. As these
systems are critical to industrial processes, they are often run on
highly reliable and dedicated hardware. Moving these SCADA
systems to an Infrastructure as a Service (IaaS) cloud, allows for:
cheaper deployments, system redundancy support, and increased
uptime, however it is not clear to what degree clouds can support
the real-time requirements. Experiments were carried out to
examine the effects of using cloud resources and public networks
have on SCADA systems. Using the Life-and-Shift approach,
eclipseSCADA was deployed to the NeCTAR research cloud.
Performance metrics were collected from the deployed
eclipseSCADA system under different loads. From these collected
metrics, a series of recommendations are provided for deploying
and modifying a SCADA system on IaaS cloud resources.

particular it is necessary to ask the following questions: What

is the expected Round Trip Time (RTT) of data moving
through a SCADA system deployed on a cloud? What
computational resources are required by a cloud deployed
SCADA system? What is the ideal deployment scenario of a
SCADA system on the cloud? To answer these questions,
experiments were carried out to investigate the effect of using
cloud resources and public networks on SCADA systems.
The open source eclipseSCADA package was chosen as a
representative SCADA system. EclipseSCADA was deployed
on IaaS cloud resources using the "Lift and Shift" deployment
approach. Performance metrics were collected from the
eclipseSCADA system under different loads (varying the
number of sensor) and regions (distributing pieces of the
SCADA system across different geographical boundaries).
From these metrics we present a series of recommendations for
deploying and modifying a SCADA system on IaaS cloud
resources.

KeywordsSCADA, migration, IaaS clouds, performance

I. INTRODUCTION
SCADA systems are instrumental to a wide range of
mission-critical industrial systems, from infrastructure
installations like gas pipelines or water control facilities to
industrial plants. SCADA systems allow a user to monitor
(using sensors) and control (using actuators) an industrial
system remotely. As these systems are critical to industrial
processes, they are often run on highly reliable and dedicated
hardware. This is in contrast to the current state of computing,
which is moving from running applications on internally
hosted servers to flexible, cheaper, internal or external cloud
environments.

Through the presented work, the following contributions

have been made:
x We define a method to port SCADA systems to IaaS
cloud resources.
x We present proof of porting feasibility through the
deployment of eclipseSCADA and collection of
performance metrics.
x We present a number of porting recommendations to
optimize the performance of cloud-deployed SCADA
systems.

For users, the main benefit of moving applications such as

SCADA to the cloud lies in the potential cost savings and
reduced setup time. Cloud resources are purchased and
accessed on-demand, at a price cheaper than buying hardware;
furthermore, as there is no need to install and/or maintain
hardware and manage software, the need for technical staff is
reduced. For industry, running SCADA on the cloud can lead
to new business models, instead of a traditional one-off
hardware cost and software licensing fee. Cloud-based
SCADA solutions can provide users with flexible fees based on
the amount of computing resources, technical support, and
software they use.

The rest of the paper is as follows: section II introduces

existing cloud-based SCADA solutions. Section III introduces
the possible approaches to move a SCADA system to the
cloud. Section IV describes the deployment of eclipseSCADA
to the cloud. Section V presents collected performance metrics.
Section VI discusses the collected metrics and presents a series
of recommendations for deploying SCADA systems on IaaS
clouds. Section VII concludes the paper describing future
work.
II. RELATED WORK
Cloud-based SCADA is a small, highly specialized
research area with only a few research papers. These papers
define cloud-based SCADA architectures, but focus on

When moving a SCADA system to cloud infrastructure,

there is a need to ensure that the real-time monitoring and
control demands of the industrial system can be achieved. In
978-1-5090-1893-2/15 $31.00 2015 IEEE
DOI 10.1109/SmartCity.2015.186

908

When porting or migrating SCADA to the cloud, three

different deployment paths can be considered, re-hosting, refactoring and revising [5]. A quickest and simplest approach is
achieved by simply re-hosting an application in the cloud ("Lift
& Shift" approach). Re-hosting is the process of installing an
existing application in a cloud environment and mainly relying
on IaaS offerings. This can be a first step in a gradual
approach, enabling to perform initial analysis and to improve
the application during multiple iterations.

implementing a solution from the ground up, as opposed to

utilizing pre-existing SCADA solutions.
x
x

Liu, et al. presents a generalized overview of clouds and

SCADA, and propose the possibility of running SCADA
in the cloud [1].
Gligor and Turc recommend exposing each SCADA
component as a service and deploying them through a
Local Directory Service (LDS) [2]. The LDS stores a
description of available SCADA resources, access
methods and description. The use of a broker allows some
components can be replaced by cloud services, for
example the database service can utilize DaaS. This
approach is very flexible; allowing users to extending the
SCADA system by adding new functionalities to existing
services or defines new ones in accordance with needs
and formulated requirements.
Based on these concepts, a web-based SCADA system is
implemented on Rackspace cloud resources. Data was
transferred using a simple protocol, consisting of a few
numerical and process monitoring variable. Data transfer
rates were measured from a local database to a cloud
database, results measured between 125 to 156 ms.
Goose et al. present a secure SCADA cloud framework
called SKYDA [3]. This SCADA system is designed to
take advantage of the scalability and reliability offered by
a cloud-based infrastructure. This paper focuses on
providing a high level understanding of SCADA
replication using clouds, moving all SCADA components
(except the field devices) as a single service. Field
devices are connected to the cloud based SCADA system
directly or (for legacy devices) via a proxy. The
framework utilizes multiple cloud providers, running
multiple copies of the SCADA Master application in
multiple clouds to provide fault tolerance.

To better benefit from the characteristics of cloud

computing, e.g., making an application more reliable, reengineering might be necessary. This can be a simple
refactoring, i.e. a modification of one or a few features. An
example is adding monitoring capabilities which enable elastic
behavior by reporting unused resources. It might also require
revising an application, i.e. making major modifications at its
core; examples would be using a PaaS database offering or
changing an application into a multi-tenancy SaaS offering. To
fully benefit from the cloud, it might also be necessary to
rebuild an application and integrate, for example automatisms
for scaling in and out. Driven by the increasing number of
SaaS offerings, an option might be to replace an existing
application with a cloud-based SaaS solution.
Before carrying this process out, there is a need to
understand the ramifications of running SCADA on a cloud.
The outcomes of a study of advantages of moving SCADA to
the cloud, how clouds can fulfil SCADA requirements, and
how existing cloud-based SCADA solutions utilize cloud
resources are of the most critical importance.
A. Advantages
The major advantages of moving SCADA applications to a
cloud are: saving on costs, support for system redundancy and
scaling, and increased uptime [6] [7].
x By running SCADA on the cloud, the cost of infrastructure
can be reduced. Porting opens the opportunity to change the
business model from a software license model to a pay-peruse model and an extension of the value chain. Migration
allows SCADA to take advantage of an open market of
cloud providers, rather than being locked to a specific
providers cloud solution.
x By running SCADA on the cloud, system redundancy and
scalability can be achieved. SCADA systems often consist
of multiple components, using migration it is possible to
distribute and replicate such a system across many
geographical regions and cloud providers. In the case of a
cloud failure, migration of core SCADA components to
local hardware or private clouds could be carried out.
Porting could be carried out to directly enhance the
reliability of the SCADA application by making use of
cloud-based services, like noSQL databases, which
implement high durability and availability. Furthermore,
scalability can be achieved by using parallel nodes and
concepts like load balancing for performance critical
system components. However, this often requires reengineering of at least part of the system.

The presented cloud-based SCADA solutions have been

developed especially for cloud infrastructure. The fact that
existing SCADA solutions have not been used, eludes to
potential issues with porting SCADA solutions. However, it is
not clear if issues are performance or deployment related. The
solution presented by Gligor and Turc addresses performance
through the use a simple data transfer protocol, while the local
directory service address deployment issues. The SKYDA
cloud framework only address deployment issues through the
use of automated replication. This paper focuses on the process
of porting and understanding the feasibility of SCADA
solutions running on cloud infrastructure.
III. MOVING SCADA TO THE CLOUD
When discussing the process of moving SCADA to the
cloud, two basic terms must be introduced, porting and
migration. Porting is the process of modifying a non-cloud
(legacy) application to be used on cloud resources (IaaS, PaaS,
or SaaS), while migration is the process of moving an
application between clouds and/or on-premise environments.
Where porting is a one-off operation, migration is a reoccurring operation and is often automated through the use of
resource selection and scheduling algorithms [4].

909

x Migrating SCADA to a cloud could improve uptime

through the provision of SCADA applications within
different clouds. With the improvement of scalability, new
servers and applications could be readily provided, without
the time consuming process of setting up and installing
hardware. For this reason, a SCADA application moved to
a cloud is easier to upgrade and install.

The Alberta Electric System Operator suggests communication

RTT between 4 and 30 seconds depending on the application.
Common solutions to reduce RTT include hosting data and
processing on the same cloud, and ensuring the cloud resources
are in the same geographical location as the remote site [11].
Other solutions are targeted at optimizing clouds for
communication [12]. iLAND provides a virtualized
middleware based on the Data Distribution Service (DDS)
standard, implementing a publish/subscribe model for sending
and receiving data [13]. ISONI improves the flow of traffic on
the network by isolating the traffic of individual virtual
machines through a virtual address space and policing network
traffic [14].

While there are numerous advantages of a cloud based

SCADA system, SCADA requirements must be addressed. The
features provided by clouds and cloud providers can be used to
fulfil these requirements, in order to enable an optimal cloudbased SCADA solution.

As key parts of critical infrastructure, SCADA systems

need to be reliable, able to continue operating correctly with an
expected level of performance at all times. Often, SCADA
systems will replicate key components. This approach can be
carried out by clouds; in particular IaaS clouds allowing users
to replicate their virtual machines on demand. Clouds can
further improve reliability by replicating across different
geographical regions. Once a SCADA system is replicated,
synchronization must be performed to ensure that the states of
all SCADA components are consistent. In particular, data must
be mirrored to ensure that when failure occurs analytics remain
accurate. A common method to ensure data consistency is by
keeping track of and carrying out events on each replicated
database, in the order in which they occur.

B. SCADA requirements vs. Cloud solutions

SCADA systems have a number of key requirements which
must be supported when moved to the cloud (see Table 1).
Table 1. SCADA requirements and Cloud features
SCADA Requirements
High Security Requirements
High Availability

Near Real Time

Communication
Reliability

Exemplary Possible Cloud Solutions

Private clouds, Data encryption.
Service Level Agreements (Cloud &
Internet Provider), high availability
architectures, redundancy concepts
SLAs, Region selection, DDS or traffic
policing.
Replication of application components
and databases, geographical isolation.

IV. ECLIPSESCADA DEPLOYMENT

SCADA systems have high security requirements; for this

reason they often operate on isolated networks. On the other
hand, one of the most publicized issues in public clouds is
security. Public clouds are open to users, and hardware is often
shared. As traditional SCADA systems and public clouds sit on
opposite ends of the spectrum, security must be addressed
when moving SCADA to a public cloud. Simple solutions
include utilizing private cloud infrastructure, or only running
aspects of the SCADA system in the cloud that are nonsecurity critical. Databases and data communication can also
be encrypted in order to protect data during transfer and
storage. This will not solve all security issues; data must be
decrypted when carrying out analysis or alarm or event
handling leading to potential vulnerabilities. Cloud based
SCADA system are also vulnerable to denial of service attacks.

The open source EclipseSCADA package was chosen as a

representative SCADA system. EclipseSCADA consists of a
number of components (see Fig. 1):
x Data Acquisition: Reads real-time data from devices, and
handles single scalar values. Data Acquisition Services
incorporate drivers.
x Alarm & Events: Handles process alarms, operation
actions, system responses, and message logging.
x Configuration: Handles creation of server components and
reconfiguration of a running system.
x Core: Defines core code used by many components, such
as the NPG internal communication protocol used by
EclipseSCADA, server code, and data structures.
x Historical Data: Records values from the Data Acquisition
service for later retrieval and analysis.
x Security: Provides authentication through public key
encryption via X509 CA certificates.

SCADA requires high availability; the Alberta Electric

System Operator suggests a 98% uptime for remote terminals
[8]. Clouds provide generated reliability through Service Level
Agreements (SLA) made between the customer and provider.
As the user must also be able to connect to the SCADA system,
there is also a need to have a service level agreement with the
internet provider. The XiO cloud solution [9], for example,
gets around the need to provide an SLA by having backup
SCADA implemented at the remote site. High availability
could also be achieved by having stand-by or redundancy
concepts in the cloud.
SCADA systems require near real-time guarantees. In order
to enable real-time applications to run on cloud environments
certain guarantees need to be provided [10]. As an example,
the speed of network communication needs to be guaranteed.

Fig. 1.

910

EclipseSCADA code map.

real time data. Users connect the eclipseSCADA cloud system

using a java based Admin Client running on their work station.
The admin client retrieves real-time data and alarm and event
information from the master server.

Direct coupling between projects based on number of

methods is shown in Table 2. The table shows that the core
component has the most links, being directly used by the alarm
and events, historical data, and data acquisition components.
The highest coupling values are between the data acquisition
components and the core library, each driver using NGP (NextGen Protocol), server and data structure code. Security is
utilized only by the configuration component, to provide a
layer of authentication on top of generated OSGi services.

V. FEASIBILITY AND PERFORMANCE STUDY

A typical SCADA system supports a large number of
sensors, which are read at 1 second intervals. Larger SCADA
systems can support several 100,000 sensors, sending hundreds
of thousands of messages per second.
To achieve similar rates of data generation and transfer, the
ported eclipseSCADA system (see Fig. 2) was configured to
collect data from polling Modbus Simulators where data was
requested by the remote server every millisecond. Starting at
100 simulators, performance metrics were collected until the
total number of simulators was 983 (the resource limit within
the remote server). As more simulators were added to the
eclipseSCADA system, additional field devices were added,
each field device hosting a maximum of 200 simulators.

Table 2. EclipseSCADA code coupling matrix (rows show

dependencies).
Components
Core
Data
Acquisition
Security
Config

Alarm &
Events
7

Historical
Data
1

Data
Acquisition
29

Core

Config

2
4
3

A. CPU and RAM

Collected performance metrics showed that CPU usage for
the remote and master server increased as more sensors were
added to the SCADA system (see Fig. 3). At 400 sensors, the
CPU usage of the remote server starts to stabilize, remaining at
90% to 95% CPU usage. The cause of this behavior is
explained in Section V. On the other hand, the CPU usage for
the historian remained stable. This is most likely due to the
historian monitoring changes in sensors rather than requesting
data using a loop.

Based on the static code analysis, eclipseSCADA was

broken into three components: a remote sever, a master server,
and a file server. Where the remote server is responsible for
data acquisition, the master server is responsible for Alarm &
Event handling, and the file server is responsible for Historical
Data storage. Using a Lift and Shift method, each component
was deployed on an individual (m1.medium sized) virtual
machine hosted on the NeCTAR research cloud [15], which
runs OpenStack. Each virtual machine had 2 virtual CPUs,
8GB RAM and 60GB secondary disk.

CPU Usage (%)

100%

Fig. 2. Ported EclipseSCADA architecture.

80%
60%
Remote
40%

Master

20%

Historian

0%
100 200 400 600 800 900 983

The outcome was a ported eclipseSCADA system; the

architecture is shown in Fig. 2. In the ported eclipseSCADA
system, simulated Modbus [16] sensors, and the core
eclipseSCADA system were deployed on the NeCTAR cloud.
Modbus simulators are deployed on a virtual machine. A
remote server uses a driver to convert data from the Modbus
simulators to the eclipseSCADA specific protocol, NGP. NGP
runs on top of TCP/IP and provides flexible timeouts,
streaming compression, SSL and callbacks. Converted data is
stored in memory as data blocks. A master server retrieves the
data blocks stored on the remote server (using the NGP
protocol), and implements warning and alarms. In addition an
Alarm & Event Handing add-on is also deployed on the
Master Server to execute events in response to alarms. A File
Server connects to the Master Server, retrieving and storing

Sensors
Fig. 3. CPU Usage per polling sensor

Collected performance metrics showed that RAM usage for

the remote and master server increased as more sensors were
added to the SCADA system (see Fig. 4). The RAM usage for
the historian remained stable.

911

25

150

Size (bytes)

RAM (Mb)

200

Remote

100

Master

50

20
15
10
5

Historian

100

100 200 400 600 800 900 983

200

400

900

983

Fig. 6. NPG data size per sensors

Fig. 4. RAM Usage per polling sensor

B. Field Device communication

In order to retrieve data from a Modbus sensor,
eclipseSCADA sends a request to a field device for its current
value. EclipseSCADA then waits for the field device to send
back the sensor data (a response). This occurs for each sensor
monitored by the remote sever. Based on this operation, the
time to transfer data between field devices and the remote
server was measured. There are two main measurements,
which were carried out on the remote server. Round Trip Time
(RTT), which is defined as time between a sensor request and
response, and Sensor Updates, which is defined as the time
between sensor requests.

Where modbus messages sent from field devices are small

in size but many in number, the NGP messages are large in size
but few in number. On average, thousands of messages are
converted to a few hundred messages. Results (see Fig. 6)
indicate that as the number of sensors increases the size of each
NPG format based message also increases.
D. Internal SCADA communication
The time taken to transfer NPG messages between the Remote
Server and Master Server, and Master Server and Historian
were measured (see Fig. 7). Results show that transferring
NPG messages between eclipseSCADA components takes less
than a second; a 100 probe SCADA system takes an average of
700 milliseconds to transmit a message (SD=0.004), while a
983 sensors system takes an average of 300 milliseconds
(SD=0.0008).

Remote Sensor
Updates
Remote RTT

Time (sec)

Time (sec)

800

Sensors

Sensors

70
60
50
40
30
20
10
0

600

100 200 400 600 800 900 983

Sensors

Fig. 5. Field Device (Modbus) Average Data Transfer

1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0

Master
Historian

100 200 400 600 800 900 983

Results (see Fig. 5) show that, as more sensors are added to

the SCADA system, the average time taken for the remote
server to retrieve sensor information increases. In the case of
the sensor updates, the average wait time for 100 sensors is 3
seconds (SD=0.06); this reaches a maximum of 59 seconds for
983 sensors (SD=0.5). In the case of remote RTT, the
maximum wait time for 100 sensors is 2 seconds (SD=0.5), at
983 sensors the delay is 20 seconds (SD=6.5).

Sensors
Fig. 7. SCADA (NGP) Average Data Transfer

Also shown is the time taken to transfer NPG messages from

the Master Server to Historian. Results show that the time
taken to transfer a single data point to be stored by the historian
takes on average of 729 milliseconds (SD=0.45). This is
consistent even when more sensors are added.

C. Message Comparison
Messages collected from field devices are converted to the
NGP format and compressed before being sent to the Master
Server and Historian.

912

VI. DISCUSSION

hosting SCADA on private cloud resources, or selecting the

closest cloud region on public cloud resources.
2. Deploying the remote server in the same region as the field
devices could improve the rate of data transfer. This will
reduce network traffic, as larger NGP messages will be sent
over the network instead of the smaller Modbus messages.
3. SCADA systems deployed on the cloud should distribute
sensors across multiple remote servers. Instead of having a
single remote sever handling 900 sensors, design the
SCADA system to have multiple remote servers each
handing a percentage of sensors. This will avoid saturation
of the SCADA system which is necessary to fulfill real time
requirements.
4. The SCADA system should be modified to make the sensor
update process more efficient. Rather than sending requests
in blocks, send multiple overlapping requests according to
the configured polling interval. Furthermore, replacing
polling sensors (which rely on a request and response),
which event driven sensors (which respond on state
change) would eliminate the need for requests, and
theoretically reduce the amount of network traffic by a
factor of two.

Analysis of collected results shows that time taken to

transfer sensor data between remote field devices and
eclipseSCADA depends on the size of the SCADA system.
While the eclipseSCADA system meets the standards defined
by the Alberta Electric System Operator [8], some industrial
applications may require a faster response time. A detailed
investigation of the operation of the eclipseSCADA remote
server (when sending messages every ms) reveals the reason
for these latency results.
Fig. 8 shows this operation of two hundred sensors with a 1
ms delay. Requests are sent to each sensor in blocks, where
two hundred requests are sent rapidly to the field devices. As
soon as the last request is sent, sensor data starts being
retrieved. The next block of requests is not sent until all of the
sensor requests are received. Due to the remote latency, the
time taken to retrieve all sensor values exceeds the time taken
to send requests.

Fig. 8. Communication between sensors and eclipseSCADA remote

server

VII. CONCLUSION AND FURTHER WORK

The first stage of our project on migrating SCADA to
clouds is successful. We identified advantages of migrating
SCADA to clouds and matched SCADA requirements and
cloud solutions. That formed a basis of the deployment of
eclipseSCADA across two cloud regions: one located in
Melbourne and another in Hobart. The results of feasibility
and some performance experiments demonstrated that
SCADA migrated to clouds can support industrial processes.
However, the experiments demonstrate the issues of the
presented solutions that should be addressed and a need for
additional enhancement of the SCADA migration project.
We see a need for the resolution of three issues: 1) the
implementation/design of the eclipseSCADA system; 2) speed
of the network on real time communication, 3) sensor data
collection. Currently, as explained in Section V,
eclipseSCADA exploits polling, which furthermore sends a
burst of requests to sensors and waits for their response before
sending another burst of requests. This solution leads to
saturation and decreases scalability. There is a need for a
modification of eclipseSCADA that provides a response to a
poling request independently to handling other poling
requests.
Due to the inefficient implementation of the
eclipseSCADA system, it is currently not clear, how much
influence the speed of the network has on real time
communication. We propose a comparison of the already
achieved results with a bare metal installation and a 100%
local cloud-based installation (all components including
sensors in Melbourne) be carried out.
Lastly, experiments were carried out using polling
simulators, we are convinced that event driven monitoring

This behavior explains why, as more sensors are added to

eclipseSCADA, the time between updates increases as well.
EclipseSCADA has to wait for more data from field devices
before sending a new block of requests. This also explains the
minimal changes to CPU usage after 400 probes. As more
sensors are added, the SCADA system eventually reaches a
point of saturation where the rate of messages being sent is at a
maximum. Exceeding this saturation point means that the
SCADA system is not able to send out the next requests on
time, resulting in the measurement interval degrading, and the
system no longer being able to fulfill real time requirements.
While we can conclude that the communication design of
the eclipseSCADA remote sever is not efficient, this is further
agitated by the speed of the network. Data transfer between
field devices and remote server relies on messages being
passed through the internet taking between 2 and 20 seconds.
On the other hand, internal SCADA communication which
relies on private networks is very fast occurring in less than a
second. From this comparison we can conclude that the speed
of the network, and distance between field devices and
SCADA components also has a great effect on the presented
results.
Based on these results, when deploying a SCADA system to
an IaaS cloud using the "lift and shift" approach, the following
general recommendations are provided:
1. Data transfer between the remote sensors and SCADA
system should be made as fast as possible. This can be
accomplished by: providing a fast network or reducing the
distance between SCADA components. For example:

913

[7] Inductive Automation, "Cloud-Based SCADA systems:

The benefits & Risks," 2011.
[8] Alberta Electric System Operator, "AESO SCADA
Standard," ed, 2005, p. 46.
[9] XiO. (2015). XiO Cloud SCADA Control System.
Available: http://www.xioio.com/wp/
[10] S. Gogouvitis, K. Konstanteli, S. Waldschmidt, G.
Kousiouris, G. Katsaros, A. Menychtas, et al.,
"Workflow management for soft real-time interactive
applications in virtualized environments," Future
Generation Computer Systems, vol. 28, pp. 193-209, 1//
2012.
[11] A. Goscinski, M. Brock, and P. Church, High
Performance Computing Clouds.: CRC, Taylor &
Francis group, June 2011.
[12] M. Garca-Valls, T. Cucinotta, and C. Lu, "Challenges in
real-time
virtualization
and
predictable
cloud
computing," Journal of Systems Architecture, vol. 60, pp.
726-740, 10// 2014.
[13] M. Garcia Valls, I. R. Lopez, and L. F. Villar, "iLAND:
An
Enhanced
Middleware
for
Real-Time
Reconfiguration of Service Oriented Distributed RealTime Systems,"
Industrial Informatics, IEEE
Transactions on, vol. 9, pp. 228-236, 2013.
[14] M. K. T. Voith, K. Oberle, D. Lamp, A. Cuevas, P.
Mandic, A. Reifert, "ISONI Whitepaper v2.0.," 2009.
[15] J. Kirby. (2012). NeCTAR - Australian Research Cloud.
Available: http://www.nectar.org.au/
[16] Modicon, "Modicon Modbus Protocol Reference Guide,"
ed, 1996, p. 121.

could be more efficient and plan to perform these experiments

in the near future.
ACKNOWLEDGMENT
This work was supported by a NeCTAR research grant,
providing access to the IaaS cloud resources necessary to
deploy eclipseSCADA in the cloud.
The authors are also grateful for the support of Deakin
University, providing a working environment.
REFERENCES
[1] M. Liu, C. Guo, and M. Yuan, "The Framework of
SCADA System Based on Cloud Computing," in Cloud
Computing. vol. 133, V. C. M. Leung and M. Chen, Eds.,
ed: Springer International Publishing, 2014, pp. 155-163.
[2] A. Gligor and T. Turc, "Development of a Service
Oriented SCADA System," Procedia Economics and
Finance, vol. 3, pp. 256-261, // 2012.
[3] S. Goose, J. Kirsch, and D. Wei, "SKYDA: cloud-based,
secure SCADA-as-a-service," International Transactions
on Electrical Energy Systems, pp. n/a-n/a, 2014.
[4] Z. Zhang, L. Xiao, X. Chen, and J. Peng, "A Scheduling
Method for Multiple Virtual Machines Migration in
Cloud," in Network and Parallel Computing. vol. 8147,
C.-H. Hsu, X. Li, X. Shi, and R. Zheng, Eds., ed:
Springer Berlin Heidelberg, 2013, pp. 130-142.
[5] Gartner. (2011). Gartner Identifies Five Ways to Migrate
Applications
to
the
Cloud.
Available:
http://www.gartner.com/newsroom/id/1684114
[6] K. Wilhoi, "SCADA in the Cloud - A Security
Conundrum?," 2013.

914