Embed Size (px)
Citation preview
Systems Integrationwithin Cyber-Physical Systems
José Jorge Abreu e Sousa de Matos Azinheira
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisor(s): Prof. José Alberto Rodrigues Pereira Sardinha
Examination Committee
Chairperson: Prof. Prof. José Carlos Martins DelgadoSupervisor: Prof. José Alberto Rodrigues Pereira Sardinha
Member of the Committee: Prof. Francisco António Chaves Saraiva de Melo
May 2018
ii
Acknowledgments
Em primeiro lugar, queria agradecer o apoio incondicional de toda a minha família, especialmente
de ambos os meus pais, não só durante a realização desta dissertação, mas também durante todo o meu
percurso académico, em especial quando as coisas se complicaram. A educação, valores e apoio que me
deram fizeram uma contribuição muito grande para que mantivesse o foco em acabar o curso.
Em segundo, ao meu orientador, o professor José Alberto Sardinha, por também me ter apoiado
durante este percurso, especialmente quando tive que atrasar a entrega da dissertação devido a alguns
problemas pessoais. A sua compreensão foi essencial.
Por fim, a todos os meus amigos que me perguntaram constantemente como é que tudo estava a correr
e que consequentemente me motivaram a concluir esta final e importante etapa da minha vida académica.
iii
iv
Resumo
Com o aparecimento e consequente divulgação dos sistemas ciber-físicos (CPS), surge também a ne-
cessidade de se desenvolverem soluções no que toca à arquitetura destes sistemas. Esta dissertação aborda
a complexidade dos sistemas ciber-físicos, relacionando as dificuldades de desenho e a consequente imple-
mentação dos mesmos em aplicações reais. Estes sistemas são mais complexos quando comparados com
sistemas tradicionais, devido à combinação de processamento computacional e físico, requerendo assim
a compreensão de diversas disciplinas distintas, tal como cibernética, mecatrónica e método científico.
Visto que o conceito destes sistemas é relativamente novo, a sua definição ainda não é totalmente clara,
bem como quais devem ser as suas características fundamentais no que toca ao desenho de arquiteturas.
Com isto, através da compreensão de alguns conceitos chave e estudo de diversas arquiteturas já
existentes, vamos propor uma possível solução para responder a este problema. Primeiro iremos propor
uma definição para sistemas ciber-físicos, e de seguida uma arquitetura geral para os mesmos utilizando
técnicas de Feature-Oriented Software Development (FOSD). Por fim, iremos apresentar dois cenários
onde a sua aplicação será possível.
Palavras-chave: Sistemas Ciber-Físicos, Service-Oriented Architecture, Sistemas Embebidos,
Feature-Oriented Software Development, Internet of Things, Sistema de Sistemas
v
vi
Abstract
With the appearance and resulting popularization of cyber-physical systems (CPS), the necessity to
develop solutions regarding the architectures of these systems arises. This dissertation addresses the
complexity of cyber-physical systems, relating the difficulties of designing and implementing them in
real-life applications. These systems are more complex when compared to more traditional systems, due
to the combination of both computation and physical processing, thus requiring the comprehension of
several distinct disciplines such as cybernetics, mechatronics and process science. Since the concept of
these systems is relatively new, its definition is still unclear, as are the main foundations for the respective
architecture design.
With this, and by analyzing some key concepts and studying several already existing architectures, we
propose a possible solution to address this problem. First we will propose a definition for CPS, and then
present a general-purpose architecture for these systems using Feature-Oriented Software Development
(FOSD) techniques. Finally, we will present two possible scenarios for its application.
Keywords: Cyber-Physical Systems, Service-Oriented Architecture, Embedded Systems, Feature-
Oriented Software Development, Internet of Things, System of Systems
vii
viii
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Acronyms xv
1 Introduction 1
1.1 Research Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background 5
2.1 Concept Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 System of Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Industry 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Feature-Oriented Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8 Areas of application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8.1 Military - Land Warrior Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.8.2 Medicine - Medical Cyber-Physical Systems . . . . . . . . . . . . . . . . . . . . . . 12
2.9 Concept relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Related Work 15
3.1 Architectural Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Shop Floor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Industry 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3 Prototype architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
ix
3.1.4 PowerCyber architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.5 Service-Based Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.6 Modular architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.7 Context-Aware Vehicular Cyber-Physical Systems with Cloud Support . . . . . . . 25
3.2 Architecture comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.1 Data collection and presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.3 Decision-making . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 Architecture proposal 31
4.1 Definition consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Requirement definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Architecture proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.2 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.3 Computational Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.4 Security Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.5 Publish-subscribe messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Legacy systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Theoretical Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.1 Singular system - Stock control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5.2 System of systems - Parts warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5 Conclusions 45
5.1 Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Recommendations for future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Bibliography 47
x
List of Tables
3.1 Surveyed architecture comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Sensor and actuator comparison regarding the surveyed architectures. . . . . . . . . . . . 27
3.3 Networking comparison regarding the surveyed architectures. . . . . . . . . . . . . . . . . 28
3.4 Decision-making comparison regarding the surveyed architectures. . . . . . . . . . . . . . 28
3.5 Security comparison regarding the surveyed architectures. . . . . . . . . . . . . . . . . . . 29
xi
xii
List of Figures
1.1 The Kerrison Predictor. Notice the angle input displays on the right side of the device [3]. 1
2.1 CPS concept map [24]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 ESB example [26]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 General structure of embedded control systems [31]. . . . . . . . . . . . . . . . . . . . . . 8
2.4 Graphic displaying the exponential growth of devices in the Internet of Things [33]. . . . . 9
2.5 Layout for Industry 4.0 systems [38]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 FOSD phases [39]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 U.S. Army soldier with the Land Warrior system equipment. Here we can clearly see the
LED display, body armor and radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 OICW rifle, used in the Land Warrior program. The sight has the functionalities described
above. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9 Electrocardiograph (ECG) system diagram [43]. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.10 Concept map connecting Background concepts. . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 CPS architecture for intelligent manufacturing [19]. . . . . . . . . . . . . . . . . . . . . . . 16
3.2 5C architecture for implementation of CPS[16]. . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 5C architecture for implementation of CPS[16]. . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Traditional architecture of an embedded system [30]. . . . . . . . . . . . . . . . . . . . . . 20
3.5 Prototype architecture for a CPS[30]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 PowerCyber tested architecture [44]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.7 3-tiers of service-based CPS [48]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8 Standard CPS architecture [9]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Example cloud-assisted context-aware architecture [18]. . . . . . . . . . . . . . . . . . . . 26
4.1 Feature diagram for the first phase of FOSD. . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Model for the service-based architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3 Information flow in the architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 VPN architecture example [70]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.5 Basic publish-subscribe operation [73]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Publish-subscribe operation in the architecture. . . . . . . . . . . . . . . . . . . . . . . . . 41
4.7 Information flow for the weight-based stock control service. . . . . . . . . . . . . . . . . . 43
xiii
4.8 Parts warehouse CPS architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
xiv
Acronyms
ACK
Acknowledgement. 25
CPS
Cyber-Physical System. 1
CPSoS
Cyber-Physical System of Systems. 9
CPU
Central Processing Unit. 2
DMM
Data Management Module. 24
DDoS
Distrubuted Denial-of-Service. 39
ECG
Electrocardiograph. 12
ERP
Enterprise Resource Planning. 18
ESB
Enterprise Service Bus. 7
EVPN
Ethernet Virtual Private Network. 38
FOSD
Feature-Oriented Software Development. 3
FOP
Feature-Oriented Programming. 10
xv
GPS
Global Positioning System. 11
IOT
Internet of Things. 8
IEEE
Institute of Electrical and Electronics Engineers. 25
ISEAGE
Internet-Scale Event and Attack Generation Environment. 23
LAN
Local-Area Network. 23
LED
Light Emitting Diode. 11
MCPS
Medical Cyber-Physical System. 12
MES
Manufacturing Execution System. 31
NGI
Next Generation Internet. 25
RFID
Radio Frequency Identification. 16
RCS
Resilience Control System. 19
RTDS
Real Time Digital Simulator. 23
REST
Representational State Transfer. 38
SAM
Service Aware Modules. 25
SAAM
Scenario-Based Architecture Analysis Method. 15
xvi
SOA
Service-Oriented Architecture. 5
SOAP
Simple Object Access Protocol. 38
SoS
System of Systems. 9
SPL
Software Production Line. 10
SCADA
Supervisory Control and Data Acquisition. 23
VPN
Virtual Private Network. 38
WAN
Wide-Area Network. 23
xvii
xviii
Chapter 1
Introduction
One of primordial principles of cyber-physical systems (CPS) dates back to World War II, where the
term cyber-physical system itself did not exist. Instead, there were cybernetics, the discipline responsible
for studying machine control and communication [1]. Norbert Wiener, an American mathematician and
philosopher, also widely credited as the father of cybernetics [1], worked on the first automated system
for anti-aircraft weaponry (in this case, stationary guns): the Kerrison Predictor, depicted in Fig. 1.1
(Example 1) [2]. The system’s concept was to predict the positioning of enemy aircraft, using their speed
and approach angle: the operator would then insert these values into the device, which would aid an
operator to correctly aim and fire the respective guns, with a better accuracy compared to a system
whose operation was totally dependent on human interaction. This principle consists in converting an
input into an output.
Figure 1.1: The Kerrison Predictor. Notice the angle input displays on the right side of the device [3].
Example 1. The Kerrison Predictor was one the first automated anti-aircraft weapons ever conceived,
being able to shoot down airplanes without the need for complete manual aiming. The system used
mechanical inputs (airplane speed and angle) to produce another mechanical output (aiming the weapon).
This principle of having an input in order to produce an output is one of the main foundations of cyber-
1
physical systems: more specifically, embedded systems.
Later on, we progessed into embedded systems, which still persist to this day.
An embedded system can be broadly defined as a device that contains tightly coupled hardware
and software components to perform a single function, forms part of a larger system, is not intended
to be independently programmable by the user, and is expected to work with minimal or no human
interaction.
[Manuel Jiménez, Rogelio Palomera, Isidoro Couvertier[4]]
These systems are regarded being at the very core of CPS [5], with the following working concept: the
system has a sensor (or group of sensors), which captures input data; a central processing unit (CPU),
which processes and gives context to that data; and finally, an actuator (or group of actuators), which
displays or emits the converted data as output to the user or the environment [6]. We will discuss these
systems more in depth as the document progresses, as they represent the foundations of CPS [7].
Nowadays, embedded systems have evolved into CPS. The term cyber-physical system was first used
around 2008 by Helen Gill, at the National Science Foundation in the United States of America, to define
the combined effort of computation along with physical processes [5]. Essentially, a cyber-physical system
is a system comprised by both software computation (hence the term cyber) and physical processing over
a network, which work together as a mechanism whose performance excels when compared to regular,
traditional systems. This combination relies on the intersection, and not union, of both these components,
which means that it is essential to understand how both these components work and interact between
them; it is not enough to simply understand what they are [5]. This is one of the greatest difficulties in
developing CPS.
These systems can be used for diverse purposes which span across several areas, such as automotive [8],
avionics [9, 10], energy production [11, 12] , medicine [9, 13, 14, 15], industry [9, 16, 17] and transportation
[9, 18].
Due to their connectivity, CPS are essentially present everywhere in our lives and, as such, the demand
for more adequate and faster development, as well as the consequent implementation, is increasing, as
even more areas adopt these systems. There is a wide belief that CPS will play an important part in
technological advance, as its use expands into more areas [18, 19, 9, 20].
CPS research and development is still in its early stages. Since CPS make use of distinct components,
it is necessary to have knowledge in several disciplines, such as cybernetics, mechatronics, design, process
science [21], as well as communications, networking, mathematics and software engineering [21]. This
interdisciplinarity makes studying and developing in this area relatively more complex [22, 23].
2
1.1 Research Problem
The main motivation to study this subject is the fact that cyber-physical systems are a relatively new
topic, which means that there is a lot of room for improvement and new ideas. Henceforth, there are
opportunities for new research that could contribute to the future development of this area. With this,
we identified three main research obstacles:
1. Lack of quality information regarding specific aspects of CPS, such as security.
2. Lack of consensus regarding the definition of a cyber-physical system. Most definitions possess
similarities but also have key differences.
3. Several architectures with distinct characteristics make it difficult to idealize a general-purpose for
building a CPS.
A difficulty noticed while researching the subject of CPS is that there are several definitions for a
cyber-physical system, which can lead to some confusion.
Another obstacle in developing CPS lies in the lack of consensus on what should be and should not
be part of an architecture. Some architectures consider features that others do not, and vice-versa. This
generates some confusion on what should be the correct process of planning an ideal development for a
CPS. The limited number of publicly available architecture models is also a problem for research.
1.2 Contributions
Considering the aforementioned problems, we will then align our objectives to answer them in the
form of a solution.
To better understand and design our objectives, we defined the following research roadmap:
1. Research general CPS information and definitions.
2. Study several CPS architectures. Seven will provide a reasonable study sample, allowing us to
identify key similarities and differences.
3. Identify important and interesting areas of research that connect to CPS, and relate them with
these systems.
4. Determine the key features in a CPS, with focus on features that may not have given proper
research.
Having achieved these research milestones, the key contributions of this dissertation are the following:
• We propose a definition for CPS based on several studies. The several studies enable the combination
of information and definitions into our dissertation.
• We develop a CPS architecture using Feature-Oriented Software Development (FOSD) techniques.
• We apply the developed architecture to two real-life scenarios.
3
By acomplishing these objectives, we believe that this study will be a contribution to the development
of CPS by providing a definition that attemps to summarize not only their functioning but also the
foundations of a system, along with an architecture and corresponding examples that provide another
alternative for system implementation.
1.3 Thesis Outline
In the second chapter entitled Background, we will present some research areas and concepts, and
relate them to CPS. We will also present some real-life application scenarios and a concept map that
relates the studied concepts.
In the third chapter entitled Related Work, we will present an architectural survey conducted on
seven architectures for CPS developed by other authors. We will then present a comparison between
their similarities and differences, as well as some draw some comments.
In the fourth chapter entitled Results, we will first propose a definition for CPS based on our studies.
Then, we will define the requirements for a CPS and compare the studied architectures’ features for a
better understanding of these systems. Finally, we will propose a model for architecture development in
CPS, and also two examples of its possible application.
In the fifth and final chapter entitled Conclusion, we will draw the most important conclusions re-
garding the dissertation, as well as comment on positive and negative aspects. Finally, we will suggest
some future work to be conducted.
4
Chapter 2
Background
In this chapter, we will present some concepts related to CPS that allow us to have a better under-
standing on how these systems work, as well as explore new possibilities when developing our architecture.
We will start by presenting a concept map for CPS that allows us to have a better scope on what are
its foundations and applications. We will also relate some other areas to CPS in order to approach new
possibilities, which will be discussed further on. For example: the Concept Map presented allows us to
have a better scope on what should be in a CPS architecture; Service-Oriented Architecture (SOA) will
be the backbone of our proposed architecture, due to its implementation of services; Embedded Systems
are at the very core of every CPS; the Internet of Things is relevant in connecting CPS’s as well as other
systems; System of Systems are part of grouped CPS, which is a reality of several CPS; Industry 4.0 is
relevant to one of the architectures we will discuss, as well as several mechanisms used in overall CPS
architectures; and FOSD will be used for the development of our solution.
We will also present some relevant areas of application where CPS are examples of functionality and
added performance.
Finally, we present a diagram that connects all the previous concepts and areas for a better under-
standing.
2.1 Concept Map
Asare et al. propose a concept map (Fig. 2.1) that schematizes the key concepts, foundations and
also areas of applications of CPS.
The feedback systems consists of the sensors and actuators that are responsible for information cap-
turing, using sensors, and exposure, using actuators. Here we also have the needs for real-time response
and networking, which are both essential to every system.
Improved design tools and design methodology are relevant to our dissertation, since it is where we
specify requirements and design methodology to plan and design our architecture. It should be given
special attention to several aspects, such as interoperability, due to the heterogeneous nature of several
components present in a CPS, and system synchronization, since CPS are distributed systems.
5
Figure 2.1: CPS concept map [24].
Security is also important, more specifically regarding resilience, in order to assure a systems’ contin-
uous activity in case of failure, and privacy, assuring only authorized users access data.
We can also see that, as already said, there are several disciplines involved in CPS: in this case,
security and design methodology that, while very contrasting, are essential.
Finally, there are some areas of application mentioned. The most important to our dissertation is
manufacturing, as it relates with industry, which are the most common examples of CPS.
This concept map provides a very good overview of what are the foundations and areas of applications
of a CPS, while also presenting its modelling needs.
6
2.2 Service-Oriented Architecture
Service-Oriented Architecture (SOA) is a software design for architecture development that relies on
services being the functionality providers for applications [25]. These services communicate with each
other through an enterprise service bus (ESB) (Fig. 2.2), which establishes a communication channel for
the different components/applications of the system. Its main characteristics are:
• Services are coarse grained, loosely coupled and connection-less.
• Service re-utilization.
Figure 2.2: ESB example [26].
These features are relevant to our problem, since CPS rely on several key features that should be
re-usable in its components, thus providing interoperability of components [21] [27], since CPS usually
have components of very different natures. For example, the security measures should be implemented
considering the nature of the application and how critical they are [18]. For example, a CPS implemented
in a governmental building must consider different threats when compared to a household application,
which naturally results in different features and implementation in both CPS. This is also an advantage
when a certain service has to be changed or removed: neither operation will affect other services due to
their self-containment.
Modularity is also promoted as services are a viable option for adapting legacy systems to current
standards due to the already refered service loose-coupling and composability.
2.3 Embedded Systems
Embedded systems are widely considered to be the primordial type of CPS [5] [7], and CPS to be
their evolution. Because of this, embedded systems are very often mistaken for CPS, and vice-versa. The
difference is that while embedded systems are more computationally focused, CPS give equal relevancy to
the importance of physical context [29]. Essentially, every CPS contains an embedded system. The figure
below (Fig. 2.3) displays the functioning of an embedded system: on the left, sensors capture information
from the environment, which is then passed to the processor and respective peripheral for processing.
Finally, this information is represented in the output interfaces through actuators and indicators.
7
Embedded systems’ architectures are often centralized and tightly-coupled [30], which contrasts heav-
ily with the distributed and loosely-coupled nature of CPS.
Figure 2.3: General structure of embedded control systems [31].
While embedded systems are not the focus of this study, they are at the very core of every CPS,
so we dedicated this small section of the dissertation to address it in order to properly understand the
foundations of a CPS, mainly the principle of converting an input into an output.
2.4 Internet of Things
The Internet of Things (IoT) consists in an abstraction where every single electronic device that can
be connected to the Internet, such as smart-phones, smart-vehicles and smart-buildings, will eventually be
connected to a huge network, dubbed the IoT [32]. These devices, commonly dubbed as smart-devices,
can also be considered CPS, so essentially, the IoT is constituted by an ever-growing number of CPS
(Fig. 2.4). Because of this, it can be said that CPS have a very significant part in the IoT.
The IoT also relates to ubiquitous (pervasive) computing such that ubiquitous computing is the
concept where computation can happen anywhere at anytime [34], even when the user is not aware of it.
This is also a characteristic of some CPS, such as smart-houses, where the devices and computation are
hidden from the user and work autonomously in the background for a specific purpose without the user
being aware of operation.
While the exponential expansion of the IoT is an indication that technology is evolving and reaching
more people, this also translates into a problem regarding CPS: since CPS are connected to the IoT, this
means that more devices have access to these CPS [35]. This means that there can be more possible
points of attack. More on this when we go over the security aspect of our architecture, later on this
document.
2.5 System of Systems
System of Systems (SoS) are singular systems that operate together in a group, pooling their resources
and features to create a new, more powerful and capable system [36]. Essentially SoS can relate to CPS
8
Figure 2.4: Graphic displaying the exponential growth of devices in the Internet of Things [33].
because CPS can group up to form a cyber-physical system of systems (CPSoS), cooperating for a
collective purpose.
The Land Warrior project (Section 2.8.1) is a prime example of a system of systems: several single
systems, such as the body armor, radio and weapon, are given computational capabilities that allow them
to interact with each other and form a collective of systems that work as one.
2.6 Industry 4.0
We must briefly discuss Industry 4.0, which is the current stage of evolution in industry machinery,
that relies on cloud computing, CPS and IoT (the latter two topics being covered in this report). It was
given this name because this software adaptation of industrial process is seen as the fourth industrial
revolution [37]. These concepts are used to further automate manufacturing lines, creating the industry
equivalent of a smart-house: a smart-factory. These factories use CPS for monitoring and decision-
making, and then these same CPS communicate over the IoT to coordinate their efforts [16].
CPS are a very popular application in industry, such as manufacturing [19] and [16]. Fig. 2.5 allows
us to have a perspective of how a Industry 4.0 ecosystem is comprised of several CPS: sensors for data
acquisition; autonomous mechanisms; big-data exchanges; etc. This also relates to how CPS are comprised
of several individual systems who compose a CPSoS.
2.7 Feature-Oriented Software Development
Finally, we must discuss feature-oriented software development (FOSD), also called feature-oriented
programming (FOP). FOSD (Fig. 2.6) is a software development technique that allows for incremental
9
Figure 2.5: Layout for Industry 4.0 systems [38].
development of programs [39], which aligns with the SOA methodology, more specifically with its philoso-
phy of loose-coupling of assets. FOSD relates to software product lines (SPL), as this technique results in
several software that share common assets, because they also shared the same methods of development.
This resulting software is developed usually considering a specific area of appliance: for example, software
designed for use in inventory management will naturally share more features between themselves than
with software developed for video editing.
Figure 2.6: FOSD phases [39].
Following the studies of Apel et al. [39], the FOSD process is divided into four phases:
1. Domain analysis: in this phase, we analyze several domains (in our case, architectures) to determine
what are the common and distinct features among them. The feature diagram that results must
10
be balanced between simplicity and complexity, containing enough information but not becoming
overly large.
2. Domain design and specification: in this phase, we define an architecture, based on knowledge
obtained from domain analysis, using modeling techniques. According to the Apel et al., there has
not been much work developed in this area [39].
3. Domain implementation: in this phase, the previously developed features are converted into code.
4. Product configuration and generation: in this final phase, the software is generated based on the
previous phases, using the appropriate tools. Because the previous phase was not concluded, this
phase will also not be conducted.
The first and second phases, domain analysis and domain design and specification respectively, will
be presented during this document. The domain analysis will be conducted in an architectural survey,
where we will study several architectures proposed by other authors, in order to develop a feature diagram
containing the features of a CPS. The domain design will correspond to the architecture development.
2.8 Areas of application
In this section, we will cover some practical uses of CPS. The following examples were chosen based
on their importance to society but also the relevance and ease of display regarding the use of CPS.
2.8.1 Military - Land Warrior Program
The Land Warrior project (Fig. 2.7) [40] was a United States Army program that aimed to improve the
efficiency of military (both personnel and vehicles) by combining cutting edge technology with standard
issue equipment. Its goals are integrating small-arms with high-technology equipment and providing
real-time information to each soldier as an individual, thus giving the soldier the perspective of a single
entity, rather than being part of a larger group [41]. This program can be seen as one of the first attempts
of implementing cyber-physical systems in military applications.
This system is ideally comprised of several components: the helmet, which contains a LED display,
informing the user of friendly troop locations, an headset communication and even a display that transmits
real-time image relayed from a weapon-mounted camera, allowing the operator to fire around corners
without exposing himself to danger; body armor, designed for protection and to carry equipment; several
technological aids, like a computer to power the system, a navigation system with both GPS and Dead
Reckoning Module in case the GPS is unavailable, and also a radio system; and finally, a weapon (Figure
2.9) equipped with several attachments, like sights with thermal, infrared and nightvision capabilities
and video-cameras.
Land Warrior is a great example of cyber-physical systems for a simple reason: the weapon, which is
a completely mechanical object totally deprived of electronics, is given enhanced capabilities due to the
addition of a cyber counterpart. This is important because it gives soldiers in the field an advantage over
11
Figure 2.7: U.S. Army soldier with the Land Warrior system equipment. Here we can clearly see theLED display, body armor and radio.
Figure 2.8: OICW rifle, used in the Land Warrior program. The sight has the functionalities describedabove.
the enemy forces. This system is also an example of system of systems, since we have several individual
systems (helmet, weapon, etc.) working together to form a singular system as a whole (Land Warrior
system).
2.8.2 Medicine - Medical Cyber-Physical Systems
One important example of CPS lies in health-care, which uses medical cyber-physical systems (MCPS)
[42]. MCPS are used for health-care applications in medical facilities like hospitals and clinics. A concrete
example are electrocardiographs (Figure 2.9), devices that monitor the electrical activity of the heart over
time through electrodes connected to a patient’s body. Examples of these MCPS allow for a simultaneous
control of several aspects of a patient’s physiology [42]. Because of this, whenever a patient requires
medical attention due to anomalous heart activity, the ECG will detect that anomaly and inform the
medical staff through sound (an alarm), prompting them to respond. Here we can exemplify the roles of
an embedded system in a CPS, specifically how sensors and actuators participate: the electrodes in the
ECG serve as a sensor, monitoring heart-rate, and when they read an abnormal value they trigger the
alarm, the actuator. The roles of these mechanisms are very evident: input raw data is captured by the
12
sensor, which is then transformed by the system into an output result, and finally presented to the user
by the actuator.
Figure 2.9: Electrocardiograph (ECG) system diagram [43].
The added complexity of these MCPS warrants for a new way to approach architecture design, requir-
ing new design, verification and validation techniques while preserving safety and efficiency [42]. These
MCPS increase the efficiency of health care services and consequently help save lives and also improve
quality of life.
2.9 Concept relation
Before we present our background studies, we will first explain how the concepts presented in this
chapter will be relevant to the study and how they connect with each other. The following concept map,
depicted in Fig. 2.10, demonstrates how we managed to connect all the presented concepts.
The IoT encompasses embedded systems, CPS and CPSoS because all of these systems exist in this
network. System connectivity allows these system to communicate with each other over this network.
SOA can be used to adapt legacy systems, such as some embedded systems, into current CPS with
the usage of services.
In the Iot we have several specific applications, such as the already refered Industry 4.0 appliances,
the Land Warrior Project, Medical Cyber-Physical Systems and, of course, our own solution.
13
Figure 2.10: Concept map connecting Background concepts.
14
Chapter 3
Related Work
In this chapter we will present the studies relevant to the architectures survey we conducted on
CPS. Despite being a relatively new area, there has been some work developed in this area in terms of
architectures: Liu and Jiang [19] present an architecture for shop floor appliance, along with a definition
for CPS. Lee et al. [16] present an architecture for Industry 4.0 based systems, along with a definition for
CPS. Tan et al. [30] also proposes a definition on what a CPS is, and proposes a prototypical architecture
that considers the essential features that should be part of it, as well as the respective flaws of design.
Hahn et al. [44] present a different architecture from the others, as it is a security testbed for attacks
against CPS, instead of an architecture for CPS itself. La and Kim [27] and Ahmed et al. [9] present a
service-based architecture, which goes in the same direction as this dissertation. Finally, Wan et al. [18]
present an architecture for CPS in vehicles with a heavy focus on Cloud computing.
With this, we will determine the characteristics and design procedure techniques for CPS, also drawing
inspiration from the studies of Dobrica and Niemela [45] on how to properly conduct a survey on software
architecture, specifically on using the Scenario-Based Architecture Analysis Method (SAAM), where
we first identified the problem that each architecture attempts to resolve, their requisites and further
description.
3.1 Architectural Survey
This survey is relevant to the first phase of the FOSD method we discussed in Chapter 2: the Domain
Analysis.
3.1.1 Shop Floor
Liu and Jiang [19] define CPS as ”a system of collaborating computational entities which are in
intensive connection with the surrounding physical world and its on-going processes, providing and using,
at the same time, data-accessing and data-processing services available on the internet [19].
The objective of implementing this CPS architecture into a shop floor is to reduce downtime, provide
autonomous and reliable decision-making, and also reduced overall operational costs, achieving the overall
15
goal of inteligent manufacturing [19].
Like it was previously stated in the course of this dissertation, CPS implementation is still in its early
stages, which is an opinion shared by the authors who quote Dworshack’s and Zaiser’s survey as proof of
it [46]. Additionally, they stress that there is a need for the development of a universal architecture, not
only for general applications but also specifically for shop floor implementation. Some challenges, like
implementing the connection between the cyber and physical counterparts, and also the lack of readiness
of most manufacturing systems to handle big-data, contribute to this delay in implementation [19].
To address these problems, the authors suggest a three-layered architecture, as depicted in Fig. 3.1,
that follows the flow of information from the sensors to the actuators: physical connection, middleware
and computation.
Figure 3.1: CPS architecture for intelligent manufacturing [19].
• Physical connection layer: groups the architectures sensorial capabilities, starting with embedding
relevant components with sensors, RFID devices and measurement devices, which capture data
in real-time [19]. The sensors should be installed and connected with each other via a BUS or
Ethernet, while considerations about connection protocols, distance, location and storage should
be enforced in order to maximize efficiency [19].
• Middleware layer: responsible for transmitting the captured data to the central server for pro-
cessing, serving as a connection between the physical and computation layers, hence the name
middleware [19]. It also goes into detail by dividing itself into three categories: device manage-
ment, interface definition and data management. Device management is responsible for grouping
sensors and their respective communication protocols, allowing different devices to interconnect
with each other; interface definition provides an interface for the architectures’ components, thus
providing an abstraction of complexity and providing plug-and-play; finally, data management is
16
used to store the processed data and to group it according to its proper data type [19].
• Computation layer: responsible for giving context to the processed information, using different
data analysis methods. Since we are dealing with big data, large volumes of information are infered
through stream and batch computing: because of this, a lot of information is non-essential, so this
information must go through noise-reduction and filtering to assure quality data [19].
The architecture also considers networking as a communication channel to transmit data among the
systems’ several resources [19].
In order to better implement this architecture into a shop floor, the authors then suggest three
fundamental technologies:
• Interconnection and interoperability among different devices: CPS are often constituted of hetero-
geneous components, so a unified data format and interface must be defined in order to assure
proper data registry and communication over different protocols [19].
• Abstraction: the authors abstract a CPS into four different components: CPS component, which
is every single element of a CPS; CPS node, which is responsible for sensing, computing, communi-
cating, decision-making and controlling; CPS unit, which is used to finish a task; and CPS system,
which is the totallity of CPS units (the overrall system) [19].
• Definition of data interface: an interface divides itself into three types [19]: sense interface, which is
used to access devices with differing communication protocols ; computing interface, which defines
a unified data format for the computation layer to work with; and application interface, which
provides a unified data format for external applications to work with.
This architecture is relevant to our dissertation because it includes what we consider to be the foun-
dations of a CPS: data collection and networking, decision-making. It also mentions the use of big-data
and the importance of the IoT.
3.1.2 Industry 4.0
Lee, Bagheri and Kao define CPS as ”transformative technologies for managing interconnected systems
between its physical assets and computational capabilities [16].
Lee et al. [16] defend that since CPS are a rather new technology, it is important to define a clear
structure and methodology for their implementation in industry, along with guidelines for a unified
framework [16], an opinion also shared by the authors of the previously presented architecture [19].
According to a report made by a German institute, the country’s respective gross value can be increased
by 267 billion euros by 2025 with the successful integration of Industry 4.0 into the market [47], which
exalts the importance CPS may have on our future.
According to the authors, CPS architectures traditionally consist of two main components: ad-
vanced connectivity, responsible for real-time physical data acquisition and information feedback from
the cyber-space; and intelligent data management, analytics and computational capability, responsible
17
for constructing the cyber-space. This results in a very abstract concept that does not allow for gen-
eral architecture implementation [16]. The 5C architecture (Connection, Conversion, Cyber, Cognition,
Configuration), depicted in Fig. 3.2, provides an answer to this lack of specificity, as displayed in the
following figure:
Figure 3.2: 5C architecture for implementation of CPS[16].
This architecture, as depicted in Fig. 3.2, developed having in mind Industry 4.0 applications Sec-
tion 2.6 consists of five functionality tiers. We will make a bottom-up approach description:
• Smart Connection Level: this level is responsible for the sensorial component of the CPS, capturing
data from the environment. This data can be captured a sensor or from a controller, or enterprise
manufacturing system, such as an ERP [16]. We have to account for the different types of data,
how to manage its acquisition and consequent transferal to the central server through protocol
establishment. Another characteristic is to select the proper sensors, considering their type and
specification [16].
• Data-to-Information Conversion Level: this level is responsible for the inference component of the
CPS, converting raw data into meaningful information. This process can be achieved through
several techniques, such as algorithms and other tools. This level is also responsible for bringing
self-awareness to machines [16].
• Cyber Level: this level is responsible for being the data repository of the whole architecture, having
information being delivered to it from every other machined connected to it in its respective network.
After receiving the information, it then analyses it to extract additional valuable information that
provide better individual insight [16].
• Cognition Level: this level is responsible for decision-making in the system, acting based on knowl-
edge extracted from system monitoring. It also presents performance measurement information to
18
the final-users [16].
• Configuration Level: this final level is responsible for configuration of machines, supervising control
to allow machines to self-configure and self-adapt. This level also acts as a resilience control system
(RCS), applying corrective and preventive decisions to the system itself [16].
Figure 3.3: 5C architecture for implementation of CPS[16].
This architecture is relevant to our dissertation because it includes some of what we consider to be
the foundations of a CPS: data collection and decision-making. It also considers configurability in the
form of resilience control, which is, according to our studies, a feature that is not often given attention.
3.1.3 Prototype architecture
Tan, Goddard and Pérez define CPS as ”a next-generation network-connected collection of loosely
coupled distributed cyber systems and physical systems monitored/controlled by user defined semantic
laws [30].
The objective os this architecture is to provide, according to the authors,a framework that is composed
of all identified requirements and characteristics, as well as unify the human and machine computational
models [30]. The authors then proceed to explain why a traditional embedded system architecture, as
depicted in Fig. 3.4, is not enough for CPS implementation. Sensors and actuators are tightly-coupled
(changes made in a component will be reflected on others, most likely, adversely) with the control unit
so that timing properties can be preserved, individually, on each component [30]. This poses a problem,
as the system is less adaptive and more centralized, which translates into having isolated system-level
time, resulting in more complex, time consuming and error-prone processes whenever we desire to build
a system.
To fill these gaps, the authors suggest four characteristics in our society that when adapted to com-
putation, as an analogy, can act as foundations for CPS. Here, we will just present the CPS counterpart
19
Figure 3.4: Traditional architecture of an embedded system [30].
of the comparison:
• Global reference time: instead of using individual timing for each component, all components use
the same time reference. This way they can operate concurrently and asynchronously with each
other, as well as preserve ordering of behaviors and events [30].
• Event/information driven architecture: events and information should reflect the current status of
the content [30].
• Adaptive output: the system should be dynamic and adaptive, where different components can
produce different outputs for the same input [30].
• Publish/subscriber model: by using the global time reference, content that has been published into
the system can be delivered orderly to the respective subscribers [30].
With these points in mind, the authors proceed to present the prototype architecture [30] depicted
below Fig. 3.5.
Its main features are:
• Global reference time: a global reference time is provided by the network and accepted by all the
components [30].
• Event/information driven system: events are separated from information, where events are raw
data captured from the sensors (sensor events) or actions performed by the actuators (actuator
events), and information is the output processed by the control units [30].
• Quantified confidence: a unified event/information model should be used, with the following prop-
erties: global reference time, life-span; confidence; digital signature; trustworthiness; dependability;
criticalness [30].
20
Figure 3.5: Prototype architecture for a CPS[30].
• Publish/subscriber model: with this model, each CPS control unit only receives the events/information
it has subscribed to, based on the role it plays in the system, and publishes events/information when
necessary [30].
• Semantic control laws: represent the core of the CPS control units, where they limit the system
behaviors according to user defined conditions and scenarios, which allows control over the output
[30].
• New networking techniques: the network, in addition to providing the global reference time, also
provides event routing and data management schemes [30].
This architecture is relevant to our dissertation because it goes into detail regarding more specific
characteristics, like messaging and information confidence. The mentioning of a publish-subscribe model
21
has also inspired us to go more into detail in this matter.
3.1.4 PowerCyber architecture
Hahn, Ashok, Sridhar and Govindarasu present us an architecture, as depicted in Fig. 3.6, that is
different from all others we have studied, as it is not an architecture model for CPS itself, but a security
testbed for CPS, more specifically smart-grids, meaning it is a platform used to test the security of a
CPS in a controlled environment. This architecture is a response to the limited availability of real-life
CPS that allow for security testing, a difficulty that we struggled with during the development of this
dissertation. This is important to discover possible vulnerabilities as well as validate a system [44].
This architecture divides itself into three layers: cyber, physical and communication.
Figure 3.6: PowerCyber tested architecture [44].
The cyber layer consists of the computational part of the system and the human-in-the-loop and
closed loop mechanisms used to measure the grid’s reliability and performance, and is divided into two
types:
• Control center: responsible for operations done with human-in-the-loop considerations. Uses SCADA
(Supervisory Control and Data Acquisition) for a high-level measurement and status check of the
several devices that are part of the system as well as data analysis [44].
• Substations: auxiliary stations to the control center [44].
The physical layer consists of:
• Real-Time Digital Simulator (RTDS): real-time simulation platform that allows for power usage
measurement in a system, in a reliable and cost-effective way [44].
• DIgSILENT PowerFactory: software that allows for non-real-time power usage simulation. The
advantage when compared to RTDS is that it allows for simulation of larger systems [44].
Communication between these two layers is made using LAN and WAN environments. The authors
also suggest using ISEAGE (Internet-Scale Event and Attack Generation Environment) to simulate cyber-
attacks on the system, and to consequently prepare their defense [44]. This is a very interesting approach
to the security problem of CPS.
22
It is also suggested the development of cyber-physical metrics in order to improve system security
and resilience, where in the physical counterpart we can use metrics such as power flow and stability for
measure [44]. This is important because metrics for CPS have not been defined yet, to the best of our
knowledge, as they are very hard to define due to the abstraction of systems.
This architecture is relevant to our dissertation because instead of focusing itself on what we consider
to be the foundations of a CPS, it goes into detail regarding the security of these systems, an aspect often
disregarded by other architectures and general research.
3.1.5 Service-Based Architecture
La and Kim define CPS as an integration of computation and physical processes. In CPS, downsized
and embedded devices execute physical processes by monitoring and controlling entities in the physical
world [48].
Motivated by the challenge of designing and the multidisciplinarity of CPS, the authors present an
architecture based in SOA. Using services, it is possible to make use of their loose-coupling to deal with
dynamic composition, improving a systems’ modularity. The authors then define three key assumptions
on CPS: physical devices being connected to the control system over a network; functionality not being
tightly coupled to hardware elements; and real-time and on-demand processing [48].
The authors then proceed to present their architecture, as depicted in Fig. 3.7. Instead of dividing
the architecture into the typical two layers, where one of them handles the physical devices (physical
layer) and the other handles the computational capabilities (cyber/functional layer), the authors suggest
diving it into three tiers (layers): Environmental Tier, Control Tier and Service Tier.
Figure 3.7: 3-tiers of service-based CPS [48].
• Environmental Layer: consists of the sensors and actuators, where information is gathered from
the environment by the sensors, which is then transfered to applications in the Control Tier, and
finally presented to the user by the actuators [48].
• Control Tier: responsible for decision-making and data-analysis, as well as monitoring physical
devices and services, determining what is the appropriate service for a specific action [48].
23
• Service Tier: where services are stored, possesses control systems that decide which services will be
deployed, and then forwards the final output to the end-user [48].
This architecture is very interesting as it aligns with our studies, considering it implements SOA as
its main foundation. It also divides the architecture into layers, which is what we will do in our proposed
architecture, and as such, can be used for its development.
3.1.6 Modular architecture
Ahmed, Kim and Kim propose a service based architecture, as it allows for a rapid and low cost
deployment in systems, as well as interoperability between systems due to the reusability of services [9].
The authors divide their architecture, as depicted in Fig. 3.8, into five modules (layers): sensing
module, data management module, next generation internet, service aware modules and application
module.
Figure 3.8: Standard CPS architecture [9].
• Sensing Module: this module is responsible for data collection using sensors and providing that
data to the Data Management Module. It is supported by networks which connect the sensors that
enable real-time control[9].
• Data Management Module (DMM): this module is responsible for data processing such as normal-
ization, noise reduction and data storage [9]. This data is then forwarded to the Service Aware
Modules using Next Generation Internet [9].
• Next Generation Internet (NGI): this module is responsible for communication in the system. Its
main feature is that it enables for applications to select the packet transmission path, instead of
being forced to a single path [9]. It proposes using two IEEE standards of wireless communication
[9], 802.16n (IEEE Standard for Air Interface for Broadband Wireless Access Systems - Amendment
2: Higher Reliability Networks) [49] and 802.16p (IEEE Standard for Air Interface for Broadband
Wireless Access Systems - Amendment 1: Enhancements to Support Machine-to-Machine Applica-
tions) [50].
24
• Service Aware Modules (SAM): this module is responsible for decision-making in the system and
task analysis and scheduling, sending data to the respective services [9].
• Application Module: this module is responsible for deploying services while saving data in a secure
database [9]. The system makes use of both cloud storage and local storage for added security [9].
The authors suggest using NoSQL for data saving, as it allows for data management over distrubted
systems.
The authors then proceed to divide the security of CPS into three phases: awareness security, which
considers the security and accuracy of collected data; transport security, which considers data transmis-
sion safety; and physical security, which considers the security of physical devices, such as servers and
workstations [9].
Finally, they present a communication topology for the architecture modules previously presented.
First, the Sensing Module sends an association request to the DMM, which replies with an acknowledg-
ment packet (ACK): after this, nodes start sending captured information to the DMM, which is then
processed and normalized. Information is then passed to the SAM through the NGI. Finally, the services
are matched to their corresponding applications in the Application Module [9].
This architecture is very interesting as it aligns with our studies, considering it implements SOA
as its main foundation. The authors also consider data collection and storage and networking in their
architecture, which aligns with our considerations for the foundations of a CPS.
3.1.7 Context-Aware Vehicular Cyber-Physical Systems with Cloud Support
Wan, Zhang, Zhao, Yang and Lloret [18] suggest an architecture to deploy in vehicular networks in
order to answer to the increasing demand of adapting these networks into cloud-assisted, context-aware
vehicular CPS [18]. The goals of this architecture are to improve road safety and traffic efficiency while
having ambiental preocupations [18].
These context-aware services consist of services like live traffic updates or direct video-feeds for a
certain route chosen by a driver.
The authors divide their architecture, depicted in Fig. 3.9, into three layers: the vehicle computational
layer, the location computational layer, and the cloud computational layer.
• Vehicle Computational Layer: this layer considers equipment and devices in a vehicle that can be
used as sensors to infer information [18].
• Location Computational Layer: this layer considers devices deployed in the environment, such as
roads, that exchange information with the sensors in the vehicles. Vehicles that are out of range of
these devices can connect to the network through nearby vehicles [18].
• Cloud Computational Layer: this layer considers applications and services owned by diverse entities
that exchange information with each other in a single, large cloud [18].
The authors also consider security to be an important aspect, as the user’s information should be
protected by services such as access control, encryption and authentication [18].
25
Figure 3.9: Example cloud-assisted context-aware architecture [18].
This architecture is relevant to our dissertation because it also uses services, and also considers security
as an important part of CPS. On the other hand, the architecture lacks some specificity on how to provide
that security and how the services work.
3.2 Architecture comparison
After conducting the survey on several architectures in the previous chapter, we will now present
a comparison of those architectures based on their characteristics, as depicted in Table 3.1, where we
will determine the similarities and differences, based on what we determined to be common and most
important characteristics existant in the studied architectures. Note that these characteristics include
functionalities or operation methodology that the authors mentioned but may have not specified, which
we will comment on should it be the case. With this, we divided these characteristics into the following
four main categories: data collection, networking, decision-making and security.
3.2.1 Data collection and presentation
All architectures, except the PowerCyber testbed architecture, consider the data collection component,
as it is the most important of a cyber-physical system: to collect raw, unprocessed data through its sensors;
give it context using processing mechanisms; and present it to the final-user using actuators. Table 3.2
provides an overview of this comparison.
26
Table 3.1: Surveyed architecture comparison.Data collection/presentation Networking Decision-making Security
Shop Floor Yes Yes Yes No5C Yes Yes Yes NoPrototype Yes Yes Yes NoPowerCyber No Yes No YesService Based Yes Yes Yes NoModular Yes Yes Yes YesContext Aware Yes Yes Yes No
Table 3.2: Sensor and actuator comparison regarding the surveyed architectures.Shop Floor 5C Prototype Service Based Modular Context Aware
Vehicular
SensorsVibration,pressure,temperature
Sensors and enterprisemanufacturing systems(ERP, MES, SCM, CMM)
Not specified Not specified Not specified Not specified
Actuators Monitors Not specified Not specified Not specified Cars, lamps,watering pumps
Live-feed fromvehicles, real-timeinformation ontraffic
The Shop Floor architecture considers sensors of vibration, pressure and temperature for data collec-
tion, but does not consider how this data is presented by the actuators.
The 5C architecture considers the typical sensor usage for data collection, but also ERP (Enterprise
Resource Management), as well as other tools, for data collection.
The Prototype architecture does not make any specific reference on how data is collected and pre-
sented, as well as what sensors and actuators are used. Interestingly, the authors consider the sensors to
be part of the cyber layer of the architecture, instead of the physical layer, like most of the other authors
and ourselves do.
The Service Based architecture does not specify what the sensors and actuators are and how they
perform, but how the applications that run them should route the information to the respective services.
The authors also reinforce that these devices should not exceed resource usage.
The Modular architecture does not specify the type of sensors that may be used to collect data. On
the other hand, the authors suggest that the actuators may be cars, lamps or watering pumps.
The Context Aware Vehicular architecture considers sensors that are present in a vehicle. The actu-
ators can be live feed from vehicles or real-time information about traffic.
From this analysis, we can draw the following conclusions: devices that act as sensors or actuators
can be almost anything, provided they collect and present data. Other data management tools can also
be used as sensors, as in they collect information that can then be used for further operation. When
considering sensors in a system, it should be given attention to several aspects: positioning, in order to
improve communications with other nodes in the system; resource usage, in order to reduce operational
costs; real-time operation, in order for information to be the current. Actuators are not as specified as
their sensor counterparts.
27
3.2.2 Network
The Shop Floor, PowerCyber and Service Based architectures do not specify how networking is im-
plemented. Table 3.3 provides an overview of this comparison.
Table 3.3: Networking comparison regarding the surveyed architectures.
5C Prototype Modular Context AwareVehicular
Networking MTConnectstandard
Backups, globalreference time
Ethernet,wireless Wireless
The 5C architecture considers the MTConnect standard, which is a data and information exchange
protocol used in manufacturing operations [51].
The Prototype architecture considers the implementation of a set of backup servers, dubbed Secured
Network Knowledge Database Servers, which only accepts expired data. It also considers using a global-
reference time for event-ordering.
The Modular architecture considers both wired and wireless networking. It also defends that network
protocols should be able to adapt in order to individual application necessities in order to assure quality-
of-service.
The Context Aware Vehicular architecture considers wireless networking for information exchange
between its systems and the environment it is connected to.
From this analysis, we can draw the following conclusions: most architectures favor wireless network-
ing instead of Ethernet, mainly due to convenience, such as portability; protocols should be taken in
consideration when designing a systems’ networking infrastructure.
3.2.3 Decision-making
The PowerCyber architecture does not consider decision-making and the 5C architecture does not
specify how it is implemented. Table 3.4 provides an overview of this comparison.
Table 3.4: Decision-making comparison regarding the surveyed architectures.Shop Floor Prototype Service Based Modular
Decision-makingStream and batchcomputing usingSpark, Hadoop
Semantic controllaws Control tier Service Aware
Module
The Shop Floor architecture considers big data for analysis, but identifies the excess, various types
and low quality of data to be processed to be a challenge. To tackle this, data processinmg is divided
into two categories: stream computing and batch computing. Stream computing processes real-time data
while batch computing processes batches of already existing data. Data mining tools such as Spark [52]
and Hadoop [53] are suggested.
The Prototype architecture considers semantic control laws as control systems, defined by the user.
28
The Service Based architecture dedicates a whole tier to decision-making: the control tier. In this tier
there is a local registry with the systems’ services, where a service monitor updates this registry whenever
there a change is made.
The Modular architecture dedicates a whole module to decision-making: the Service Aware Module.
This module redirects received data to the respective services.
The Context Aware Vehicular architecture does not specify how the decision-making is processed,
only the factors that may affect it.
From this analysis, we can draw the following conclusions: there are several alternatives when con-
sidering decision-making, such as dedicating a whole layer of the architecture for that purpose and what
tools to use in them.
3.2.4 Security
The Shop Floor and 5C architectures do not consider security. Table 3.5 provides an overview of this
comparison.
Table 3.5: Security comparison regarding the surveyed architectures.
PowerCyber Service Based Modular Context AwareVehicular
Security Testingenvironment Not specified Integrity
Access control,encryption,authentication
The Prototype architecture considers security as an important aspect of CPS, as well as acknowledging
that security is a challenge, but does not specify how it is implemented.
The PowerCyber architecture provides a testbed to test CPS against cyber attacks. While this does
not fully relate to our architecture, it was important to have a perspective on how attacks may be
conducted on these systems.
The Service Based architecture considers security as an important aspect of CPS but does not specify
how it is implemented.
The Modular architecture considers that the security of each CPS should be done according to its
nature. The authors also divide security into three phases: awareness security, which is essentially an
assurance of integrity; transport security, which is also an assurance of integrity; and physical security,
which considers safety procedures in physical devices such as servers or workstations. This last phase is
very important, as it is equally important to protect the physical devices, such as sensors, actuators and
desktops, when comparing to information in the system.
The Context Aware Vehicular architecture considers information privacy through access control, en-
cryption and authentication, but does not specify how to implement it.
From this analysis, we can draw the following conclusions: while security is acknowledged by some
authors, it is not one of the main concerns in CPS architecture design. Because of this, we will try and
provide some contribution to security measures when proposing our architecture.
29
30
Chapter 4
Architecture proposal
In this chapter, our developments, obtained based on the research presented in Chapter 2 and Chap-
ter 3. We will start by addressing the definition consensus problem, analyzing each definition given
to CPS over the course of the research done and then proposing a definition of our own, having that
research in consideration. We will then determine what requirements are functional and non-functional
in an architecture. Finally, we will propose an architecture for CPS, as well as two scenarios where we
could possibly implement it.
4.1 Definition consensus
An early and very common problem when researching this subject were the multiple definitions for the
concept of cyber-physical systems, which has lead to a lack of consensus regarding on what the definition
is. Despite all of them converging into theoretically the same definition, they also have slight differences
that end up creating some confusion. This confusion can lead to difficulties when trying to understand
what should be part of a CPS. As such, we will propose a definition of our own.
We start by presenting the first-ever definition of a CPS, given by Helen Gill, and then the definitions
given by the authors of the architectures that we have studied.
The term cyber-physical system was used for the first time by Helen Gill at the National Science
Foundation, back in 2008:
Cyber-physical systems are physical, biological, and engineered systems whose operations are
integrated, monitored, and/or controlled by a computational core. Components are networked at
every scale. Computing is “deeply embedded” into every physical component, possibly even into
materials. The computational core is an embedded system, usually demands real-time response, and
is most often distributed. The behavior of a cyber-physical system is a fully-integrated hybridization
of computational (logical) and physical action.
[Helen Gill [7]]
31
This definition is, in our opinion, the most complete when compared to the definitions given by the
other authors because it references both cyber and computation counterparts, the networking between
them, how embedded systems are at the core of CPS, the needs for real-time response and the presence
of distributed systems. The term biological might be used because CPS interacts with the environment,
often with biological (or biometric) scans, such as temperature, humidity or pressure.
Passing on to the definitions by the architecture authors, firstly we have the definition presented by
Liu and Jiang:
CPS is a system of collaborating computational entities which are in intensive connection with
the surrounding physical world and its on-going processes, providing and using, at the same time,
data-accessing and data-processing services available on the internet.
[Liu and Jiang [19]]
In this definition, the authors claim that CPS are a group of computational entities that are heavily
related to their physical environments (hence the term physical) and its processes (hence the term cyber),
while at the same time using data available on the internet, relating to the networking capabilities of
a system. The on-going processes point to a real-time need of these systems. This definition is very
complete, only lacking the reference to decision-making mechanisms.
Secondly, we have the definition presented by Lee et al.’s 5C architecture, which is in fact Baheti and
Gill’s [21] definition:
Cyber-Physical Systems (CPS) is defined as transformative technologies for managing intercon-
nected systems between its physical assets and computational capabilities.
[Baheti and Gill [54]]
In this definition, the authors claim that CPSs are an entity comprised of ever-changing technologies
whose purpose is to manage a group of systems (system of systems) and their correspondent physical
assets and cyber capabilities. We consider this definition to be rather vague, because it does not explicitly
mention the interaction of CPS with the environment. Also, the definition seems to assume that all CPS
have the functionality of managing interconnected systems, which may be mistaken with systems of
systems.
Thirdly, we have the definition presented by Tan et. al.[30]:
Cyber-Physical Systems are a next-generation network-connected collection of loosely coupled
distributed cyber systems and physical systems monitored/controlled by user defined semantic laws.
[Tan et al. [30]]
32
In this third definition, the authors claim that CPSs are a group of cyber and physical systems that
are loosely coupled and whose operation is regulated by user defined semantic laws. In this definition,
artificial intelligence is mentioned by the means of user-defined semantic laws, an aspect not refered in
both previous definitions, as well as loose-coupling, which aligns with our definition. It also mentions
networking. This definition only lacks the mentioning of how CPS affect the environement.
Finally, we have the definition presented by Kim and Jung:
A CPS is defined as integration of computation and physical processes. In CPS, downsized and
embedded devices execute physical processes by monitoring and controlling entities in the physical
world.
[La and Kim [48]]
This last definition encompasses both cyber and physical parts of CPS, refering downsized embedded
systems due to their portability. We consider this definition to be rather vague, as it does not mention
the always present networking and decision-making aspects of CPS.
Taking all of this in consideration, we will now present a defition based on our studies:
Cyber-Physical Systems are distributed systems, comprised of both computational and physical
counterparts which operate in synchronism, loosely coupled between themselves, and whose operation
is regulated by decision-making mechanisms and connected to their surrounding environment.
[José Azinheira]
This definition attempts to encompass all characteristics that we deem necessary in a CPS: com-
putational and physical aspects, decision-making and networking. CPS extract raw data from their
environment using sensors, which is then given context using decision-making tools. This information
is then passed on to actuators, which affect the environment they are present in. We also consider
loose-coupling of components and functionalities, as it allows for easier replacing, modularity and cost
reduction. All components of a CPS must be connected using a network, which is also used to communi-
cate with the outside environment (such as the Internet) if needed. We also classify CPS as distributed
systems, because they consist of a networking of some autonomous machines that share resources [55, 56].
Despite security being very important, it does not fit into the definition because we cannot assume all
CPSs to have security mechanisms, as evidenced in our architecture survey.
As such, we will have this definition in consideration when designing our own architecture.
4.2 Requirement definition
Before presenting the architecture itself, we will present the requirements that are part of it, pertaining
to the first phase of the FOSD: the domain analysis (depicted in Fig. 4.1). These requirements are divided
33
into two categories: functional requirements, those that are related to the functionality of the system
(what the system is supposed to do), and non-functional requirements, which are qualitative attributes
of the system.
On the following figure, we present the feature-diagram that demonstrates the functional requirements
of a CPS architecture.
Figure 4.1: Feature diagram for the first phase of FOSD.
Functional requirements:
• Data collection/presentation: how the system gathers and consequently presents data. Considers
physical devices responsible for data collection and presentation. Sensors are used for data collec-
tion, while actuators are used for data presentation which affects the environment they are present
in.
• Communication: how the system’s components communicate with each other and with the exter-
nal world. Can be wired (Ethernet) or wireless networking. Should have consideration for the
communication protocols.
• Decision-making: how the system processes the information infered by the sensors and consequently
processes it. Considers tools for data optimization, normalization and noise-reduction.
Non-functional requirements:
• Security: responsible for assuring the security of the system and the information in it against attacks
and environmental hazards
• Redundancy: assures that the system’s components have a safeguard component in case of any
unexpected problem that cripples or halts their functioning. This should be emphasised to the
critical components (that are part of the critical requisites). This is a non-critical requisite since it
may not be possible or financially profitable to implement in all scenarios.
34
• Scalability: the system should be ready to receive resource upgrades. This includes hardware,
software and network.
• Availability: the system should be available at all times, specially in critical appliances such as
medicine or security. This can be improved by also improving security and redundacy.
4.3 Architecture proposal
Based on all previous studies, we will now present a model for a cyber-physical system architecture,
which corresponds to the second phase of the FOSD methodology: the domain design implementation.
We will follow the studies of [57], [9], [58] and [59] as guidelines for our design process.
As evidenced in Section 3.2, there is not a lot of emphasis given to security in many architectures, so
what we propose is complete architecture that combines all of functional requirements, as well as non-
functional requirements, while still considering security. One can say that because security is not present
in all models, it may not be essential, but attacks like the one in 2015 which affect several Iranian nuclear
facilities, where a worm (a malicious software named Stuxnet) was used to compromise the centrifuges
operation [60], have specialists giving more attention to this often forgotten aspect.
Our architecture is service-based, using the SOA software design methodology. Due to the hetero-
geneous nature of the several components of a CPS, using services allows for a seamless integration of
their functionalities, as well as assuring loose-coupling of these same services, providing easier replacing
should it be needed, as well as reusability for several systems. This allows for a rapid deployment and
lower costs for interoperable and scalable sytems [9]. As we will see, this feature is particularly useful
when applying this architecture to different scenarios: for example should a certain environment require
additional security measures, it is only necessary to configure the security service module without these
changes having any impact on the remaining services.
First, we must describe what a service is: a service is a software functionality that can be deployed
using Web Services. A service has two main properties: it is self-contained, so its functionality is separated
from other services and encapsulated [61], meaning changes in one service will not impact others (providing
loose-coupling); and produces an output based on an input, where users do not need to understand the
service’s functioning in order to use it. A service also has three main components: an interface, where
the user operates the service (Web Service); a contract, that defines how the service provider and service
requester interact [62]; and its implementation, where the service’s code is defined.
A service is then used to expose the functionality of a component or application via WebService [63],
which allows for different components, which would otherwise be incompatible, to exchange information
via a open standard protocol: SOAP [64].
The following example demonstrates how services can be useful in a CPS architecture:
Example 2. We have a system comprised of: two sensors, A and B, responsible for providing Service
A and Service B, respectively; a central service repository that contains all of the systems’ services and
responsible for deploying applications; an actuator X, that uses Service A and Service B for a specific
35
Operation Y. An end-user requests an operation that uses Service A and Service B. The repository
requests the most recent data infered from Sensor A and Sensor B, and deploys the application that
allows the reading of these Services in Actuator X. Should we need to remove Service B from the system,
because Service B is independent from Service A, doing so would not affect the operation of sensor A.
We can also consider the use of microservices instead of regular services. While SOA divides its services
into four categories, being Business, Enterprise, Application and Infrastructure services, microservice ar-
chitectures only rely on Functional and Infrastructure services. This makes its implementation easier and
more cost efficient when compared to SOA, but there are also several disadvantages: microservice-based
architectures limits the number of protocols used, thus limiting interoperability when using heterogeneous
components and protocols; decoupling is also non-existant in microservices, which limits modularity when
applying an architecture to different environments [62]. Despite these limitations, microservices are ap-
propriate when considering smaller scale systems that perform a limited set of functions.
Inspired by the studies of [30, 65, 48], we will divide our architecture (Figure 4.1) into three layers for
a better approach and understanding. In the case of [48], which divide their architecture into three layers:
Environmental Tier, which considers sensors and actuators, Control Tier, for decision making regarding
the captured data, and Service Tier, which manages the services that are part of the framework. In our
opinion, separating the service capabilities from the Control Tier and dedicating a single layer to the
services is rather unnecessary, adding more complexity to the system. Our solution to this is creating a
single layer that encompasses all cyber capabilities of the system, including decision-making and services,
and another layer for the physical capabilities of the system [66]. Because of these limitations, we will not
consider using microservices in our proposed architecture, but mentioning their existance is important as
it can be useful for less distributed and complex systems.
With this, our architecture, depicted in Fig. 4.2 will be divided into three layers: Physical Layer,
Computational Layer and Security Layer.
4.3.1 Environment
The Environment is where all information is present and collected via sensors, and also where it is
presented once processed via actuators. Information can be collected and presented directly or undirectly:
if a human operator wants to know room temperature at a precise moment (direct, as there will be a human
requesting the sensor operation) or a system responsible for maintaining room temperature (indirect, as
the system is automated and does not require human operation).
The Environment is also where the Internet is.
4.3.2 Physical Layer
The Physical Layer contains all of the physical devices of the system that either capture or present
data. Other components, like data storage, while having a physical presence such as an hard-drive, do
not capture nor present data, so they are not part of this layer.
Sensors: hardware devices that capture unprocessed data from the Environment in a specific context,
36
Figure 4.2: Model for the service-based architecture.
defined by the system’s operation semantic. Will vary according to the system’s nature and appliance,
but we can consider several options like: heat sensors, cameras, objects embbeded with RFIDs, pressure
triggers, illumination sensors, etc.
Actuators: hardware devices that display processed data to the final user, affecting its environment.
Will vary according to the system’s nature and appliance, but we can consider several options like: image,
text data, changes in the environment, etc.
The selection of these hardware devices, for both sensors and actuators, should have several aspects
in consideration: resource usage should not hinder the systems’ performance [67] ; positioning should be
done in order to reduce information propagation times.
37
4.3.3 Computational Layer
The Computational Layer contains components that are involved in computational tasks, more specif-
ically, that manage information and services.
Data storage: devices, or services, dedicated to storage data for further use. This storage can be done
with local storage, using hard-disks for example, adequate for smaller scope applications, such as a small
store or warehouse, or using cloud storage, suited for larger applications. Local storage has the advantage
of access speed to information and easier physical access to the device, while cloud storage has several
advantages: costs, since maintenance is provided by the cloud storage provider; scalability, as it is easier
to request more storage to the service provider rather than upgrading the local storage (this also saves
physical space from being occupied with servers).
Decision-making: contains the decision-making tools to process the data infered by the sensors as
well as the systems’ corrective measures for resilience control. Since CPS are part of the IoT, big-data
is usually involved in these systems, so its adequate to adapt big-data analysis tools. These big-data
batches are usually very volumous, so it is essencial to filter this data for quality information.
Services: repository that contains the definitions of the system’s services. Definition is done using
Web Services and communication through the respective protocols, such as SOAP (Simple Object Access
Protocol) and REST (Representational State Transfer).
Networking: how the system’s components are connected with each other and how the system contacts
the external world. This networking can be done using Ethernet (wired connection) or with a WAN
(wireless connection). The option chosen relates to the type of environment we are implementing the
architecture on, as we will demonstrate in our examples.
The following figure (Fig. 4.3) demonstrates how information flows in our architecture: a service
requests a reading from a sensor, which then sends the reading to the decision-making mechanisms. The
information is then processed and stored in the systems’ storage. Then, it is sent to the service repository,
which will deploy the respective application for the sent value into the actuator, which finally presents
the information.
4.3.4 Security Layer
The Security Layer contains mechanisms that ensure the systems’ safety when exposed to internal and
external attacks. Due to the heterogeinity nature of CPS, it is necessary to consider a considerable larger
number of threats when compared to traditional systems: both cyber and physical parts are prone to
attacks or environmental hazards [68]. As the IoT becomes more and more popular, the number of devices
in it increases. This means that the device number increase is proportionate to the number of threats
posed for CPS. Before CPS and embedded systems, some systems would be isolated from the Internet,
unable to connect with it, so outside threats would not be considered. This lead system designers and
security experts to rely in security by obscurity, which ”hopes” that the possible attackers do not possess
knowledge of the system in order to attack it [35]. Nowadays, with connectivity being mandatory in CPS,
this is simply not acceptable as a security standard [35]. As such, it is imperative to preserve all three
38
Figure 4.3: Information flow in the architecture.
key aspects of information security: integrity, confidentiality and availability.
One of the security measures was already described in the Computational Layer explanation in this
chapter, regarding networking: using a VPN (as depicted in Fig. 4.4) to set-up the systems’ communica-
tion environment. We can use a VPN for both wired and wireless networking, where in the first we use a
EVPN (Ethernet Virtual Private Network) and in the latter a wireless VPN. VPNs allow us to set up a
private network (intranet) whose access is much more restricted, therefore much harder to be susceptible
to attacks as it enforces encryption [69]. For our architecture, we only consider VPN services provided by
companies, not free solutions. This ensures that we can get the best service and also the best customer
support.
Figure 4.4: VPN architecture example [70].
39
We will now go over how VPNs protect integrity, confidentiality and availability:
• Integrity: consists in the information arriving from the origin to its destination exactly the same
(unmodified) [71], can be ensured using the IPsec protocol for data encryption and checking, which
verifies if all of a message’s packets have reached its destination unmodified.
• Confidentiality: consists in the information being transmitted being only seen and received by its
supposed desination and never by anyone else [71], can be ensured a priori, considering that all
information being sent in the VPN is encrypted.
• Availability: consists in the information being available at all times for authorized users only [71],
can be ensured by redundacy, which has already been explained in Section 4.2 in this chapter.
With this, we consider DDoS (Distributed Denial-of-Service) attacks, where the attackers flood
the system with requests, thus rendering with inoperable; with redundacy, we can try to ensure a
duplicate to replace the targetted system and replace functionality.
Like any other system, using a VPN is not a failproof solution. VPNs also have the disadvantage
of reduced connection speed in some occasions (latency) [69] in situations where, for example, the VPN
service provider is located relatively far from the service requester. Even so, we consider using a VPN in
a CPS to be very advantageous, as the advantages far outweigh the disadvantages.
4.3.5 Publish-subscribe messaging
In order to properly align the systems’ messaging service with the loose-coupling nature of SOA, the
publish-subscribe communication paradigm is an adequate option. The publish-subscribe paradigm, often
dubbed pub-sub, consists of a node or group of nodes, the subscribers, which register their interest in a
single event or pattern of events, through a subscription, and whenever a publisher receives any relevant
event they are notified of such [72], as depicted in Fig. 4.5. With this, we can attribute a publisher node
to each sensor and a service responsible for the infered data, which subscribes to the sensor. Whenever a
sensor has to be removed from the system, the node is removed for the messaging list without affecting
other nodes.
The analogy for application in our system would be: a sensor (publisher) sends a reading (topic),
while a control mechanism (subscriber) responsible for monitoring a certain reading will pull its respective
reading, as depicted in Fig. 4.6.
40
Figure 4.5: Basic publish-subscribe operation [73].
Figure 4.6: Publish-subscribe operation in the architecture.
4.4 Legacy systems
Despite the proposed architecture being directed towards new systems that are designed from scratch,
it is also important to consider legacy systems. Legacy systems classify as systems developed using old
and outdated techniques, that still manage to perform adequality and are useful to their environment
but that will eventually deteriorate unless given proper attention [74]. Because of this, these systems do
not need to be discarded, but can be migrated into a SOA, in order to expose their functionalities using
Web Services [75].
41
4.5 Theoretical Examples
Now that we have presented our architecture, we will present some theoretical examples where its
application could be useful. One of the examples represents a single system, while the other example is
a system of system that includes the single system of the first example.
4.5.1 Singular system - Stock control
Our first example consists of a CPS applied to stock control. In this example, we will consider a
parts warehouse as the environment where the CPS will be installed. The main goal is to provide an
automated stock control mechanism to the warehouse, eliminating the need for a human to constantly
check the warehouse’s inventory, henceforth reducing costs and improving efficiency.
• Problem: some items in a parts warehouse are sold individually and not in bulk. Ocasionally, stock
control features in an ERP do not account for these individual sales, which leads to errors in stock
control.
• Solution: implement a weight-based stock control system that sets a minimum threshold for weight
per item. Whenever this minimum is reached or surpassed, the scale embedded with an RFID tag
will prompt, via an interface, for a human operator to restore stock.
For each individual item (or batch of items) in the inventory, a minimum acceptable weight would be
set that determines the minimum amount of said item that should be in stock: for example, if a 3x5mm
screw weighs 5 grams, and each box contains 100 screws, the box weight is 500 grams; if the minimum
set weight is 1000 grams, that would mean that the system will inform the user when only 2 boxes are in
the shelf by detecting that the weight is equal or inferior to a 1000 grams, prompting the user to request
more.
Regarding the Physical Layer:
Sensors: a scale placed in each individual item slot.
Actuators: a user-interface which prompts an alert message whenever stock needs to be replaced.
Regarding the Computational Layer:
Data processing: an ERP such as PRIMAVERA [76] coupled with the stock alert feature.
Data storage: considering this is the only system present in the warehouse, a local storage set-up
would suffice.
Services: the only services involved in this process would be requestReading() and deployService(),
as depicted in (Fig. 4.7).
Networking: the scales would be coupled with an RFID tag for wireless communication with the
decision-making mechanisms.
We will go over the Security Layer in the following example, Section 4.5.2.
42
Figure 4.7: Information flow for the weight-based stock control service.
4.5.2 System of systems - Parts warehouse
The second example consists of a group of CPS, a system of systems, applied to the parts warehouse
mentioned in the previous example, which also includes the stock-control system mentioned in that same
example. The architecture is depicted in Fig. 4.8.
• Problem: the owners want to maximize automation in their warehouse.
• Solution: implement a service-based CPS architecture into the warehouse.
Regarding the Physical Layer:
Sensors: a thermometer for climate control; a lighting sensor for lighting control; a motion-detector
in the warehouse’s entrance for an alarm.
Actuators: air-conditioning system; LED lights; alarm system; desktops or laptops with interfaces.
Regarding the Computational Layer:
Data processing: an ERP such as PRIMAVERA [76] for the overall stock-control, billing and invoicing.
Data storage: an appropriate storage option considering the warehouse size: for a smaller warehouse,
local-storage with external and internal hard-drives: for medium or larger businesses, cloud-storage pro-
vided by a professsional provider would be the best option for scalability concerns.
Services: services for air-conditioning and lighting control, already considering their automated oper-
ation. The ERP could be coupled with Web Services for stock-control, billing and invoicing.
Networking: an appropriate networking option considering the warehouse size: for a smaller business,
43
Figure 4.8: Parts warehouse CPS architecture.
a typical Ethernet or WAN setup would suffice, but a VPN option could also be considered; for medium
or larger businesses,
Regarding the Security Layer:
The company would have a VPN set-up for communications, provided by a professional company.
This would assure information encryption.
44
Chapter 5
Conclusions
One of the major goals of this dissertation was to develop a service-based architecture for CPS based
on several studies of other more specific architectures and related concepts, which was accomplished with
success, resulting in a service-based, general-purpose architecture for CPS, along with two examples: one
singular system and a system of systems. The other major goal was to propose a definition for CPS,
which was also accomplished with success.
With this dissertation we consider that we gave a contribute to the area of CPS by suggesting an
architecture that encompasses what we consider to be all the foundations of a CPS (data collection,
data processing, networking and security), while also giving visibility to an area that is unknown to the
general public. This was most evident when people asked us what was the subject of our dissertation:
when explained that it was CPS, no one knew what it was.
The development of this dissertation had several positive aspects for us: knowledge regarding an
area that was not known previously known to us and that is becoming increasingly more popular and
important; developing the architecture required several studies in the area of architecture design that
were quite challenging, useful for project developing; explaining to people the what a CPS is was also a
positive experience.
With this, the development also had some negative aspects: we did not develop a pratical implemen-
tation of the architecture, which leaves us slightly disappointed. Also, the difficulty in finding quality
information took a toll on overall time for the dissertation’s completion, far exceeding the research time
than what was initially expected.
Most importantly, the positive aspects far outweigh the negative ones, which gives us a lot of satis-
faction in the work done.
5.1 Difficulties
We also encountered several difficulties that impacted its conclusion.The major difficulty came from
the lack of abundancy regarding CPS architectures available for research and overall quality information.
This made it considerably harder to gather information which would then contribute to the development
45
of the solution presented on this dissertation.
Another difficulty was the problem in coming up with a pratical implementation corresponding to
the architecture, which would better underlie our design. Accomplishing this would allow us to complete
the third and second phases of the FOSD metholodogy that was partially used in this dissertation: the
domain implementation and product configuration and generation, respectively.
5.2 Limitations
The fact that we did not develop a practical implementation of the architecture limits its real-life
exequibility and application. Our lack of experience developing architecture also relates to this, as some
aspects of research may be underdeveloped.
The costs often associated with implementing a SOA into enterprise systems may prove too high
and not cost-effective for certain applications. Despite our theoretical example basing itself on a parts
warehouse, an architecture like this may be unnecessary in a smaller business, as sensor installation is
costly, and a standard ERP may be enough.
5.3 Recommendations for future work
Despite the main goals of the thesis being accomplished, we feel like there is still a lot of room for
improvement. Some of these suggestions for improvements are ideas that were initially planned on being
implemented, while others occurred to us in the later stages of the development of this thesis but due
to a lack of time were not implemented. We will group these suggestions based on our personal opinion
regarding their importance.
1. Practical implementation/example: one of the initial goals planned in the dissertation report and
in the dissertation itself was to develop a practical implementation in order to better demonstrate
the functionality of the developed architecture, more specifically, the integration with the robot
being developed by INESC-ID. The studies presented in this dissertation can be used to further
development on this robot.
2. FOSD conclusion: due to the lack of a pratical solution, only the first and second phases of the
FOSD paradigm have been concluded in this dissertation. It would be interesting to have the domain
implementation being done so that phases three and four of this paradigm could be concluded.
3. Performance measuring: an interesting study to complement the one made by us would be to define
performance measuring metrics for CPS. Due to the heterogeinety of the components present in
CPS, this would be a rather complicated and complex achivement, but interesting nonetheless.
46
Bibliography
[1] N. Wiener. Cybernetics: Or Control and Communication in the Animal and the Machine. The MIT
Press, Cambridge, Massachusetts, 1961. ISBN 978-0-262-73009-9.
[2] A. G. Bromley. Computing Before Computers. Iowa State University Press, Ames, IA, USA, 1990.
ISBN 0-8138-0047-1. URL http://dl.acm.org/citation.cfm?id=103047.103052.
[3] Chapter 14: Antiaircraft defense: Ground-to-air weapons. http://tothosewhoserved.org/usa/
ts/usatso01/chapter14.html, 2016. Retrieved in: 2017-09-21.
[4] D. Kleidermacher and M. Kleidermacher. Introduction to Embedded Systems Security. 2012. ISBN
9780123868862. doi: 10.1016/B978-0-12-386886-2.00001-1. URL http://linkinghub.elsevier.
com/retrieve/pii/B9780123868862000011.
[5] E. A. Lee and S. a. Seshia. Introduction to Embedded Systems - A Cyber-Physical Systems Approach.
2011. ISBN 9780557708574.
[6] S. Edwards, L. Lavagno, E. A. Lee, and A. Sangiovanni-Vincentelli. Design of embedded systems:
formal models, validation, and synthesis. Proceedings of the IEEE, 85(3):366–389, 1997. ISSN
00189219. doi: 10.1109/5.558710.
[7] H. Gill. A continuing vision: Cyber-physical systems, 2008. Retrieved in: 2016-11-17.
[8] S. Chakraborty, M. A. Al Faruque, W. Chang, D. Goswami, M. Wolf, and Q. Zhu. Automotive
Cyber–Physical Systems: A Tutorial Introduction. IEEE Design & Test, 33(4):92–108, 2016. ISSN
2168-2356. doi: 10.1109/MDAT.2016.2573598. URL http://ieeexplore.ieee.org/document/
7479578/.
[9] S. H. Ahmed, G. Kim, and D. Kim. Cyber Physical System: Architecture, applications and research
challenges. IFIP Wireless Days, pages 0–4, 2013. ISSN 2156972X. doi: 10.1109/WD.2013.6686528.
[10] P. H. Feiler. Design and Analysis of Cyber- Physical Systems : AADL and Avionics Systems Software
Engineering Institute Pittsburgh , PA 15213. pages 1–23, 2013.
[11] M. D. Ilić, L. Xie, U. A. Khan, and J. M. Moura. Modeling future cyber-physical energy systems.
IEEE Power and Energy Society 2008 General Meeting: Conversion and Delivery of Electrical Energy
in the 21st Century, PES, 2008. ISSN 1932-5517. doi: 10.1109/PES.2008.4596708.
47
[12] S. Karnouskos. Cyber-physical systems in the SmartGrid. IEEE International Conference on Indus-
trial Informatics (INDIN), pages 20–23, 2011. ISSN 19354576. doi: 10.1109/INDIN.2011.6034829.
[13] S. Don and M. Dugki. Medical Cyber Physical Systems and Bigdata Platforms. Proceedings of the
Medical Cyber Physical Systems Workshop, 2013.
[14] L. Piwek, D. A. Ellis, S. Andrews, and A. Joinson. The Rise of Consumer Health Wearables: Promises
and Barriers. PLoS Medicine, 13(2):1–9, 2016. ISSN 15491676. doi: 10.1371/journal.pmed.1001953.
[15] R. W. Picard and J. Healey. Affective wearables. Personal and Ubiquitous Computing, 1(4):231–240,
1997. ISSN 16174909. doi: 10.1007/BF01682026.
[16] J. Lee, B. Bagheri, and H. A. Kao. A Cyber-Physical Systems architecture for Industry 4.0-based
manufacturing systems. Manufacturing Letters, 3:18–23, 2015. ISSN 22138463. doi: 10.1016/j.
mfglet.2014.12.001. URL http://dx.doi.org/10.1016/j.mfglet.2014.12.001.
[17] L. Wang, M. Törngren, and M. Onori. Current status and advancement of cyber-physical systems
in manufacturing. Journal of Manufacturing Systems, 37:517–527, 2015. ISSN 02786125. doi:
10.1016/j.jmsy.2015.04.008. URL http://dx.doi.org/10.1016/j.jmsy.2015.04.008.
[18] J. Wan, D. Zhang, S. Zhao, L. Yang, and J. Lloret. Context-aware vehicular cyber-physical systems
with cloud support: Architecture, challenges, and solutions. IEEE Communications Magazine, 52
(8):106–113, 2014. ISSN 01636804. doi: 10.1109/MCOM.2014.6871677.
[19] C. Liu and P. Jiang. A Cyber-physical System Architecture in Shop Floor for Intelligent Manufac-
turing. Procedia CIRP, 56:372–377, 2016. ISSN 22128271. doi: 10.1016/j.procir.2016.10.059. URL
http://dx.doi.org/10.1016/j.procir.2016.10.059.
[20] R. Poovendran. Cyber-physical systems: Close encounters between two parallel worlds. Proceedings
of the IEEE, 98(8):1363–1366, 2010. ISSN 00189219. doi: 10.1109/JPROC.2010.2050377.
[21] R. Baheti and H. Gill. Cyber-physical Systems. The Impact of Control Technology, (1):161—-166,
2011. ISSN 0018-9162. doi: 10.1145/1795194.1795205.
[22] W. F. V. D. Vegte and R. W. Vroom. Considering cognitive aspects in designing cyber-physical sys-
tems : an emerging need for transdisciplinarity physical systems from a transdisciplinary perspective.
(i):41–52, 2013.
[23] R. Alur. Principles of Cyber-Physical Systems. 2015.
[24] P. Asare, D. Broman, E. A. Lee, G. Prinsloo, M. Torngreen, and S. S. Sunder. Cyber-physical
systems - a concept map. http://cyberphysicalsystems.org/, 2012. Retrieved in: 2016-10-24.
[25] A. Brown, S. Johnston, and K. Kelly. Using Service-Oriented Architecture and Component-Based
Development to Build Web Service Applications. Rational Software Corporation, 1(062):2, 2002.
ISSN 2010376X. URL http://arxiv.org/abs/1304.7345.
48
[26] M.-T. Schmidt, B. Hutchison, P. Lambros, and R. Phippen. The Enterprise Service Bus: Making
service-oriented architecture real. IBM Systems Journal, 44(4):781–797, 2005. ISSN 0018-8670. doi:
10.1147/sj.444.0781. URL http://ieeexplore.ieee.org/document/5386706/.
[27] K.-D. Kim and P. R. Kumar. Cyber-Physical Systems: A Perspective at the Centennial. Pro-
ceedings of the IEEE, 100(Special Centennial Issue):1287–1308, 2012. ISSN 0018-9219. doi: 10.
1109/JPROC.2012.2189792. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?
arnumber=6176187.
[28] J. Klein, J. Shewchuk, and D. Simon. Web Services Security ( WS-Security ). pages 1–22, 2002.
URL http://www.cgisecurity.com/ws/ws-secure.pdf.
[29] Cyber-physical systems. http://www.cpse-labs.eu/cps.php. Retrieved in: 19-04-2018.
[30] Y. Tan, S. Goddard, and L. C. Pérez. A prototype architecture for cyber-physical systems. ACM
SIGBED Review, 5(1):1–2, 2008. ISSN 15513688. doi: 10.1145/1366283.1366309. URL http:
//www.cs.virginia.edu/sigbed/archives/2008-01/Tan.pdf.
[31] L. Ma, F. Xia, and Z. Peng. Integrated design and implementation of embedded control systems
with Scilab. Sensors, 8(9):5501–5515, 2008. ISSN 14248220. doi: 10.3390/s8095501.
[32] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami. Internet of Things (IoT): A vision, architec-
tural elements, and future directions. Future Generation Computer Systems, 29(7):1645–1660, 2013.
ISSN 0167739X. doi: 10.1016/j.future.2013.01.010. URL http://dx.doi.org/10.1016/j.future.
2013.01.010.
[33] A. Crisp. Embedded system. http://www.nsr.com/news-resources/the-bottom-line/
internet-of-things-prime-time-for-satellite/, 2015. Retrieved in: 2016-12-19.
[34] K. Lyytinen and Y. Yoo. Issues and challenges in ubiquitous computing: Introduction.
Commun. ACM, 45(12):62–65, 2002. ISSN 14702738. doi: 10.1145/585597.585616. URL
http://delivery.acm.org/10.1145/590000/585616/p62-lyytinen.pdf?key1=585616&key2=
2022143421&coll=GUIDE&dl=GUIDE&CFID=37631835&CFTOKEN=43284984%5Cnhttp:
//delivery.acm.org/10.1145/590000/585616/p62-lyytinen.html?key1=585616&key2=
5332143421&coll=GUIDE&dl=GUID.
[35] D. Information, A. Centers, D. Technical, C. Security, I. Systems, and T. Information. Journal of
Cyber Security and Information Systems, volume 5. 2017. ISBN 3157323261.
[36] J. Boardman and B. Sauser. System of Systems - the meaning of of. 2006 IEEE/SMC International
Conference on System of Systems Engineering, (April):118–123, 2006. doi: 10.1109/SYSOSE.2006.
1652284. URL http://ieeexplore.ieee.org/document/1652284/.
[37] H. Lasi, P. Fettke, H. G. Kemper, T. Feld, and M. Hoffmann. Industry 4.0. Business and Information
Systems Engineering, 6(4):239–242, 2014. ISSN 18670202. doi: 10.1007/s12599-014-0334-4.
49
[38] F. G. Exploring the enterprise service bus, part 1: Discover how an esb can help you meet the
requirements for your soa solution. http://www.ibm.com/developerworks/library/ar-esbpat1/,
2011. Retrieved in: 2016-12-16.
[39] S. Apel and C. K??stner. An overview of feature-oriented software development. Journal of Object
Technology, 8(5):49–84, 2009. ISSN 16601769. doi: 10.5381/jot.2009.8.5.c5.
[40] Land warrior integrated soldier system. https://www.army-technology.com/projects/land_
warrior/. Retrieved in: 04-04-2018.
[41] J. Murray. Wearable computers in battle: recent advances in the land warrior system. Wearable
Computers, The Fourth International Symposium on, pages 169–170, 2000. doi: 10.1109/ISWC.2000.
888485. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=888485.
[42] L. I. O. Sokolsky. Medical Cyber Physical Systems. Control, pages 743–748, 2010. ISSN 0738-100X.
doi: 10.1145/1837274.1837463.
[43] D. Niewolny. Addressing the technical challenges of developing car-
diac monitoring devices. http://medicaldesign.com/components/
addressing-technical-challenges-developing-cardiac-monitoring-devices, 2011. Re-
trieved in: 2016-11-17.
[44] A. Hahn, A. Ashok, S. Sridhar, and M. Govindarasu. Cyber-physical security testbeds: Architecture,
application, and evaluation for smart grid. IEEE Transactions on Smart Grid, 4(2):847–855, 2013.
ISSN 19493053. doi: 10.1109/TSG.2012.2226919.
[45] L. Dobrica and E. Niemela. A survey on software architecture analysis methods. IEEE Transactions
on Software Engineering, 28(7):638–653, 2002. ISSN 0098-5589. doi: 10.1109/TSE.2002.1019479.
URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1019479.
[46] B. Dworschak and H. Zaiser. Competences for cyber-physical systems in manufacturing-First findings
and scenarios. Procedia CIRP, 25(C):345–350, 2014. ISSN 22128271. doi: 10.1016/j.procir.2014.10.
048. URL http://dx.doi.org/10.1016/j.procir.2014.10.048.
[47] S. Heng. Industry 4.0: Huge potential for value creation waiting to be tapped. Deutsche
Bank Research, 0:8–10, 2014. ISSN 09607919. doi: 10.1049/em:19950108. URL http://www.
dbresearch.com/servlet/reweb2.ReWEB;RWSESSIONID=2136781A2B04838FB197795EFED8CAAF.
srv-tc2-dbr-com?rwsite=DBR_INTERNET_EN-PROD&rwobj=ReDisplay.Start.
class&document=PROD0000000000335628.
[48] H. J. La and S. D. Kim. A Service-Based Approach to Designing Cyber Physical Systems. 2010
IEEE/ACIS 9th International Conference on Computer and Information Science, pages 895–900,
2010. doi: 10.1109/ICIS.2010.73. URL http://ieeexplore.ieee.org/document/5591233/.
50
[49] Ieee std 802.16n-2013 (amendment to ieee std 802.16-2012) - ieee standard for air interface for
broadband wireless access systems–amendment 2: Higher reliability networks. https://standards.
ieee.org/findstds/standard/802.16n-2013.html, .
[50] Ieee std 802.16p-2012 (amendment to ieee std 802.16-2012) - ieee standard for air interface for
broadband wireless access systems–amendment 1: Enhancements to support machine-to-machine
applications. https://standards.ieee.org/findstds/standard/802.16p-2012.html, .
[51] Mtconnect standard. http://www.mtconnect.org/. Retrieved in: 04-04-2018.
[52] M. Zaharia, M. J. Franklin, A. Ghodsi, J. Gonzalez, S. Shenker, I. Stoica, R. S. Xin, P. Wendell,
T. Das, M. Armbrust, A. Dave, X. Meng, J. Rosen, and S. Venkataraman. Apache Spark: a unified
engine for big data processing. Communications of the ACM, 59(11):56–65, 2016. ISSN 00010782.
doi: 10.1145/2934664.
[53] K. Shvachko, H. Kuang, S. Radia, and R. Chansler. HDFS - The Hadoop distributed file system.
2010 IEEE 26th Symposium on Mass Storage Systems and Technologies, MSST2010, pages 1–10,
2010.
[54] R. Baheti and H. Gill. Cyber-physical Systems. The Impact of Control Technology, (1):161–166,
2011. ISSN 0018-9162. doi: 10.1145/1795194.1795205.
[55] H. Yan. Distributed File Systems. Most, pages 1–12, 2008. ISSN 00010782. doi: TechnicalReportNo.
DCSE/TR-2012-02.
[56] A. S. Tanenbaum and M. Van Steen. Distributed Systems: Principles and Paradigms, 2/E.
2007. ISBN 9780132392273. doi: 10.1002/1521-3773(20010316)40:6<9823::AID-ANIE9823>
3.3.CO;2-C. URL http://www.pearsonhighered.com/academic/product/0,,0132392275,00+
en-USS_01DBC.html.
[57] A. J. A. Jansen and J. B. J. Bosch. Software Architecture as a Set of Architectural Design Decisions.
WICSA 2005 - 5th Working IEEE/IFIP Conference on Software Architecture, 2005:109–120, 2005.
doi: 10.1109/WICSA.2005.61. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?
arnumber=1620096.
[58] P. Derler, E. A. Lee, and A. Sangiovanni Vincentelli. Modeling cyber-physical systems. Proceedings
of the IEEE, 100(1), 2012. ISSN 00189219. doi: 10.1109/JPROC.2011.2160929.
[59] V. Gunes, S. Peter, T. Givargis, and F. Vahid. A survey on concepts, applications, and challenges in
cyber-physical systems. KSII Transactions on Internet and Information Systems, 8(12):4242–4268,
2014. ISSN 22881468. doi: 10.3837/tiis.2014.12.001.
[60] R. Langner. Stuxnet: Dissecting a cyberwarfare weapon. IEEE Security and Privacy, 9(3):49–51,
2011. ISSN 15407993. doi: 10.1109/MSP.2011.67.
51
[61] R. Perrey and M. Lycett. Service-oriented architecture. 2003 Symposium on Applications
and the Internet Workshops, 2003. Proceedings., pages 116–119, 2003. ISSN 01996649. doi:
10.1109/SAINTW.2003.1210138. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.
htm?arnumber=1210138.
[62] M. Richards. Microservices vs. Service-Oriented Architecture. 2016. ISBN 9781491952429. doi:
10.1017/CBO9781107415324.004. URL https://www.nginx.com/microservices-soa/.
[63] M. P. Papazoglou. Service -oriented computing: Concepts, characteristics and directions. Proceed-
ings - 4th International Conference on Web Information Systems Engineering, WISE 2003, pages
3–12, 2003. ISSN 0-7695-1999-7. doi: 10.1109/WISE.2003.1254461.
[64] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana. Unraveling the Web
services Web: An introduction to SOAP, WSDL, and UDDI. IEEE Internet Computing, 6(2):86–93,
2002. ISSN 10897801. doi: 10.1109/4236.991449.
[65] L. Hu, N. Xie, Z. Kuang, and K. Zhao. Review of cyber-physical system architecture. Proceedings -
2012 15th IEEE International Symposium on Object/Component/Service-Oriented Real-Time Dis-
tributed Computing Workshops, ISORCW 2012, pages 25–30, 2012. doi: 10.1109/ISORCW.2012.15.
[66] Microservices vs soa: What’s the difference? http://www.bmc.com/blogs/
microservices-vs-soa-whats-difference/. Retrieved in: 2018-04-19.
[67] A. F. Taha, N. Gatsis, T. Summers, and S. Nugroho. Actuator selection for cyber-physical systems.
Proceedings of the American Control Conference, pages 5300–5305, 2017. ISSN 07431619. doi:
10.23919/ACC.2017.7963778.
[68] A. Humayed, J. Lin, F. Li, and B. Luo. Cyber-Physical Systems Security – A Survey. 2017. ISSN
2327-4662. doi: 10.1109/JIOT.2017.2703172. URL http://arxiv.org/abs/1701.04525.
[69] S. Sridhar, A. Hahn, and M. Govindarasu. Cyber-physical system security for the electric power grid.
Proceedings of the IEEE, 100(1):210–224, 2012. ISSN 00189219. doi: 10.1109/JPROC.2011.2165269.
[70] Typical site-to-site vpn general architecture – allow connectivity between enterprises geo-
graphically dispersed sites. go to publication download. https://www.researchgate.net/figure/
Typical-Site-to-Site-VPN-general-architecture-allow-connectivity-between-enterprises_
fig4_228715446. Retrieved in: 04-04-2018.
[71] S. Maconachy and W. Ragsdale. A Model for Information Assurance: An Integrated Approach. Pro-
ceedings of the 2001 IEEE Workshop on Information Assurance and Security, US Military Academy,
West Point, NY, pages 5–6, 2001. doi: 10.1.1.128.2712.
[72] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec. The many faces of pub-
lish/subscribe. ACM Computing Surveys, 35(2):114–131, 2003. ISSN 03600300. doi: 10.1145/
857076.857078. URL http://portal.acm.org/citation.cfm?doid=857076.857078.
52
[73] Publish/subscribe. https://msdn.microsoft.com/en-us/library/ff649664.aspx. Retrieved in:
04-04-2018.
[74] K. Bennett. Legacy Systems: Coping with success. IEEE Software, 12(1):19–23, 1995. ISSN
07407459. doi: 10.1109/52.363157.
[75] Z. Zhang and H. Yang. Incubating services in legacy systems for architectural migration. Proceedings
- Asia-Pacific Software Engineering Conference, APSEC, pages 196–203, 2004. ISSN 15301362. doi:
10.1109/APSEC.2004.61.
[76] Primavera bss, software de gestão, faturação, erp e pos. https://pt.primaverabss.com/pt/. Re-
trieved in: 04-04-2018.
53
54
