Embed Size (px)
Citation preview
Event-driven architecture for data collection
in smart factories
Linus Magnusson
Master of Science Thesis TPRMM 2017
KTH Department of Production Engineering
Production Engineering
SE-100 44 STOCKHOLM
1
SAMMANFATTNING
I detta arbete presenteras en mjukvarulösning som stödjer implementation av system
kompatibla med mjukvaruarkitekturen LISA (Line Information System Architecture). Detta
arbete utfördes som en del av den andra omgången av forskningsprojektet LISA. LISA är en
mjukvaruarkitektur som stödjer insamlingen av data i dagens industrier med syftet att
strukturera och bearbeta data för att optimera processer och effektiviteten av system. Detta med
anledning att driva utvecklingen mot en förutsägbar miljö i tillverkande industrier för att hantera
utmaningar relaterade till dagens globala marknad.
I och med detta fokuserar det presenterade arbetet till ett snabbt och smidigt införande av
”endpoints” och mikrotjänster. Därför presenteras i detalj en mjukvaruarkitektur kompatibel
med LISA och ett mjukvarupaket som implementerar mjukvaruarkitekturen.
Mjukvarulösningen testades på produktionslina i en virtuell simuleringsmiljö med syfte att
validera mjukvarans prestanda.
Ett antal tester genomfördes för att validera den presenterade mjukvarulösningen. I dessa tester
användes mjukvaran för att beräkna ett antal nyckeltal relaterade till industrier, och resultaten
användes sedan för att validera prestanda och stabilitet hos den föreslagna lösningen.
I avslutningen av detta arbete dras slutsatsen att den presenterade mjukvarulösningen presterade
som väntat med försumbara avvikelser i testresultaten. Den presenterade mjukvarulösningen
möjliggör ett snabbt och smidigt införande av ”endpoints” och mikrotjänster. Mjukvaran stödjer
enkel utveckling av ny funktionalitet i ett system som integrerat LISA mjukvaruarkitekturen.
Detta då endast är kod relaterad till ny funktionalitet som behöver utvecklas medans
kompabiliteten relaterad till LISA egenskaper behandlas av mjukvarulösningen.
Nyckelord: Eventdriven mjukvaruarkitektur, Tjänstorienterad mjukvaruarkitektur, Cyber-
Fysiskt verkstadsgolv, Industri 4.0
2
3
ABSTRACT
This thesis presents a software stack which supports the deployment of Line Information
System Architecture (LISA) compatible systems. This work was performed under the umbrella
of the second iteration of the LISA research project. LISA is an architecture that addresses the
collection of data in today’s industries with the aim to structure and mine the data towards
optimization of processes and of the system efficiency. This with the purpose of moving
towards a predictive manufacturing environment to cope with challenges related to the current
global market.
In this sense the presented work aims to support the fast and seamless deployment of endpoints
and micro-services. Hence, a software architecture with the characteristics of LISA and the
software stack implementing the architecture is presented in detail. The software stack was
tested through a virtual simulation environment of a production line with the purpose of
validating the performance of the software.
In order to validate the presented solution a number of tests were performed. In those testes a
number of KPIs were calculated and the results were used to validate the performance and
robustness of the proposed software stack.
This work concludes that the presented software stack performed as expected with a negligible
deviation in the testing results. The presented software stack enables a quick and seamless
deployment of endpoint and micro-services. It supports an effortless development of new
functionality since only the code related to the new functionality needs to be developed while
the compatibility with the LISA requirements are taken care of by the software stack for the
user.
Keywords: Event-Driven Architecture, Service-Oriented Architecture, Cyber-Physical Shop-
floor, Industry 4.0
4
5
FOREWORD
This thesis was conducted to finalize my five years of engineering studies at Kungliga Tekniska
Högskolan, Stockholm, Sweden.
I want to thank my supervisor João Dias-Ferreira for the tremendous support during my work
and for all the opportunities you given me to learn and evolve. It has been an honor to get to
know you and work with you.
I would like thank my family for all the support during my studies. My father, Kenneth
Magnusson, my mother, Agneta Magnusson, and my brother Oscar Magnusson. Without you
nothing of this would have been possible.
I would like to direct a special thanks to my grandfather, Rune Magnusson, for all the support
during my childhood and life changing wisdoms in the sauna.
All my friends and my family around me during my work that is not mentioned by name I
would like to thank.
Linus Magnusson
Stockholm, March 2017
6
7
ACRONYMS
CMfg Cloud Manufacturing
COM/DCOM Component Object Model/Distributed COM
CPPS Cyber-Physical Production System
CPS Cyber-Physical System
EDA Event-Driven Architecture
EPS Evolvable Production System
ESB Enterprise Service Bus
HMS Holonic Manufacturing System
HTML HyperText Makeup Language
ISA International Society of Automation
IT Information Technology
JSON JavaScript Object Notation
KPI Key Performance Indicator
LISA Line Information System Architecture
MAS Multi-Agent System
OPC Open Platform Communication
OSGi Open Services Gateway initiative
PLC Programmable Logic Controller
RFID Radio-Frequency Identification
8
RMS Reconfigurable Manufacturing System
SMTP Simple Mail Transfer Protocol
SOA Service-Oriented Architecture
TPS Toyota Production System
URL Uniform Resource Locator
9
TABLE OF FIGURES
Figure 1 Visualization of the methodology used throughout the thesis work .......................... 18
Figure 2 Summary of the industrial revolutions and the drivers for each revolution .............. 22
Figure 3 Illustration of the transition from traditional to CPS-based automation hierarchy [10]
.................................................................................................................................................. 23
Figure 4 Timeline placing manufacturing paradigms in time [15] .......................................... 25
Figure 5 A set of holons that makes a holarchy [20]................................................................ 27
Figure 6 Cloud manufacturing in a simplified visualization [29] ............................................ 31
Figure 7 Basic SOA, the interaction between service provider, service registry and service client
[35] ........................................................................................................................................... 34
Figure 8 Simplified view of an ESB. Note that a service container can host multiple services
[38] ........................................................................................................................................... 35
Figure 9 An overview of architecture developed during this work .......................................... 37
Figure 10 Generic overview of ESB that constitutes the event-driven architecture developed.
The endpoint is an entity on the bus and a placeholder for services where m and n is a positive
integer. ...................................................................................................................................... 38
Figure 11 Conceptual picture of ESB with its hierarchy of channels ...................................... 39
Figure 12 Example of how the subscribing and publishing in different channels work .......... 40
Figure 13 Generic description of a tweet in the architecture ................................................... 41
Figure 14 Conceptual template for a generic endpoint in the architecture .............................. 42
Figure 15 Conceptual template of a generic service in the architecture .................................. 44
Figure 16 Descriptive visualization of fill, map and fold services ........................................... 45
Figure 17 Visualization of the two different monitoring services, event monitoring and service
monitoring ................................................................................................................................ 46
Figure 18 Descriptive visualization of a database service ....................................................... 47
Figure 19 Descriptive detailed visualization of device communication service ...................... 47
10
Figure 20 Class diagram of the main classes in the implementation. The LISAEndpointCore
and the LISAServiceCore. ........................................................................................................ 49
Figure 21 Class diagram explaining the endpoint core, the configuration class and the runnable
functionality of the endpoint .................................................................................................... 50
Figure 22 Execution activities of the run method .................................................................... 53
Figure 23 Class diagram of the service core class and its related classes ................................ 54
Figure 24 Class diagram of the service core class and the related sub-classes. ....................... 58
Figure 25 Class diagram for the LISAMessage class and the related classes .......................... 63
Figure 26 The shop-floor used for the simulation .................................................................... 68
Figure 27 The shop-floor used for the simulation and the modules that is was divided into... 69
Figure 28 The testing setup with all the endpoints and the communication paths between the
endpoints. A simplified view that not shows the services encapsulated within each endpoint.
.................................................................................................................................................. 71
Figure 29 Graph the presents the mean cycle times and the variations from the ten test runs. 74
Figure 30 Graph of the throughput time for each batch. The values are the mean value and the
variation of the testing data. ..................................................................................................... 76
Figure 31 Graph that presents the mean ideal time from the ten test runs for each batch and the
variation. ................................................................................................................................... 77
Figure 32 Graph that presents the mean queue length during the time that the queue has at least
one puck in it. The values are the mean and variation from the ten test runs. ......................... 78
Figure 33 Graph presenting the timestamps of each sensor and each puck. The values are
normalized by the first timestamp which is an indication to when the simulation began. ....... 80
Figure 34 Variance of the sensor data calculated on the ten test runs for each sensor and each
puck .......................................................................................................................................... 81
Figure 35 Histogram of the variation for the sensor data ......................................................... 81
Figure 36 Eclipse runtime configuration .................................................................................... 2
Figure 37 Package explorer application.conf file ....................................................................... 3
11
Figure 38 Application.conf file .................................................................................................. 3
12
TABLE OF TABLES
Table 1 Statically analyze of the cycle times from ten test runs (1 of 4) ................................. 75
Table 2 Statically analyze of the cycle times from ten test runs (2 of 4) ................................ 75
Table 3 Statically analyze of the cycle times from ten test runs (3 of 4) ................................ 75
Table 4 Statically analyze of the cycle times from ten test runs (4 of 4) ................................ 76
Table 5 Statically analyze of the through put time for batches ................................................ 77
Table 6 Statically analyze of the idle time for queues ............................................................. 78
Table 7 Statically analyze of the mean length of queues ......................................................... 79
13
CONTENTS
SAMMANFATTNING .............................................................................................................. 1
ABSTRACT ............................................................................................................................... 3
FOREWORD ............................................................................................................................. 5
ACRONYMS ............................................................................................................................. 7
TABLE OF FIGURES ............................................................................................................... 9
TABLE OF TABLES ............................................................................................................... 12
CONTENTS ............................................................................................................................. 13
1 INTRODUCTION ............................................................................................................ 16
1.1 Background ................................................................................................................ 16
1.2 Thesis presentation .................................................................................................... 17
1.3 Methodology .............................................................................................................. 18
1.4 Limitations ................................................................................................................. 19
1.5 Outline of the work .................................................................................................... 19
2 MODERN MANUFACTURING TRENDS ..................................................................... 21
2.1 Industry 4.0 and smart factories ................................................................................ 21
2.2 Big data ...................................................................................................................... 24
2.3 Modern manufacturing paradigms ............................................................................. 24
2.3.1 Holonic manufacturing systems ...................................................................................................... 26
2.3.2 Reconfigurable manufacturing systems .......................................................................................... 28
2.3.3 Evolvable production systems ......................................................................................................... 29
2.3.4 Cloud manufacturing ....................................................................................................................... 30
3 DISTRIBUTED INTELLIGENT ARCHITECTURES .................................................... 32
3.1 Multi-agent system .................................................................................................... 32
3.2 Service-oriented architecture ..................................................................................... 33
14
3.3 Event-driven architecture .......................................................................................... 36
4 EVENT-DRIVEN ARCHITECTURE FOR DATA COLLECTION IN SMART
FACTORIES ............................................................................................................................ 37
4.1 Architectural overview .............................................................................................. 38
4.2 Communication ......................................................................................................... 39
4.2.1 The tweet ......................................................................................................................................... 40
4.3 Endpoint ..................................................................................................................... 41
4.3.1 Virtual endpoint .............................................................................................................................. 43
4.3.2 Device endpoint............................................................................................................................... 43
4.4 Services ...................................................................................................................... 43
4.4.1 Transformation service .................................................................................................................... 45
4.4.2 Monitoring service .......................................................................................................................... 45
4.4.3 Database service .............................................................................................................................. 46
4.4.4 Device communication service ....................................................................................................... 47
5 IMPLEMENTATION ....................................................................................................... 48
5.1 Architectural implementation .................................................................................... 48
5.1.1 Endpoint core .................................................................................................................................. 50
5.1.2 Service core ..................................................................................................................................... 53
5.1.3 Sub-services .................................................................................................................................... 57
5.1.4 Message ........................................................................................................................................... 62
5.2 Enabling technologies ................................................................................................ 65
5.2.1 ActiveMQ ........................................................................................................................................ 65
5.2.2 JSON ............................................................................................................................................... 66
5.2.3 OSGi ................................................................................................................................................ 66
5.2.4 Cassandra ........................................................................................................................................ 66
5.2.5 ElasticSearch ................................................................................................................................... 67
5.2.6 OPC ................................................................................................................................................. 67
15
5.3 Simulation environment ............................................................................................ 67
5.3.1 The production line ......................................................................................................................... 67
5.3.2 Modules and signals ........................................................................................................................ 69
5.4 Test cases ................................................................................................................... 70
6 RESULT AND DISCUSSION ......................................................................................... 73
6.1 Overall assessment of the software stack .................................................................. 73
6.2 Results from testing ................................................................................................... 73
6.2.1 Cycle times ...................................................................................................................................... 74
6.2.2 Throughput times ............................................................................................................................ 76
6.2.3 Idle time for queues ......................................................................................................................... 77
6.2.4 Length of queues ............................................................................................................................. 78
6.2.5 All the sensor signals ....................................................................................................................... 79
7 CONCLUSION AND FUTURE WORK ......................................................................... 82
7.1 Conclusion ................................................................................................................. 82
7.2 Future work ................................................................................................................ 83
8 REFERENCES ................................................................................................................. 84
APPENDIX I – LISA2CORE SETUP ....................................................................................... 1
16
1 INTRODUCTION
This first chapter introduces the thesis and the purpose of the work. First the background to the
problem and then a presentation of the thesis with a set of objectives for the work. An overview
of the methodology used during the work and the main limitations of the work is briefly
described. The last section of this chapter presents the outline of this work.
1.1 Background
The globalization and the increased demand for customization and even personalization is
pressuring manufacturing industries to be more flexible and adaptive to the current fast
changing market. To handle these changes in market demand and be more agile towards the
manufacturing, a predictive manufacturing approach is preferred. The modern manufacturing
paradigms of today were born because of this new and highly dynamic market. The conditions
of this new market influencing the importance of collect and process data into usable
information [1]. These new paradigms rely on and are supported by recent developments in the
field of digitalization and connectivity between devices, this thanks to the emergence of
Internet-of-Things, Internet-of-Services, new advanced data analytic methods and cyber-
physical systems. These emerging technologies can be used to control and optimize the decision
making for operational and business decisions in a more predictive manner [2]. Analyzing data
and making decision based on huge amounts of data is what encourage the trend of Big Data.
Information is being lost in many industries today, research states that data is a hidden asset in
industry and investigations shows that 85% of data is unstructured and 42% of all transactions
are paper-based [3]. Unstructured and paper-based data prevents the data to generate
competitive advantages and possibilities of optimizing the production by embracing the trend
of Big data. This to facilitate the management of processes by gathering knowledge about them,
since you cannot control what you cannot measure [4].
Despite recent development in technologies, few modular decoupled architectures with
adequate information modules exist. These modules have the purpose of translating the desired
requirements and characteristics of modern paradigms into the shop-floor, particularly in
production management with critical and real-time information.
17
1.2 Thesis presentation
This work aims to develop an event-driven information architecture that enables the seamless
collection and processing of data at the different levels defined by the ISA-95 standard in the
enterprise. For this purpose, this work aims to develop a software stack that supports the
implementation of such architecture and enable the seamless deployment of endpoints and
micro-services. The software stack will enable the collection of data from modular shop-floor
components, and transformation of the data into meaningful and useful information, through
the composition of different micro-services. Due to the lack of access to such shop-floor, a
simulation environment was used to test and validate the proposed solution. The objectives of
this thesis are:
Develop a software stack that support the seamless deployment of endpoints and micro-
services to enable the collection of data from shop-floor modular components, and its
transformation to intelligible information. Objectives of the ultimate software stack:
o Event-driven and service-oriented
o Ability of seamlessly deploy endpoints and micro-services
o Micro services are loosely coupled and self-contained with predefined
transformation behaviors
o Enable data collection from shop-floor control devices independent of vendor
o Flexible and scalable architecture
o Enable calculation of key performance indicators for new and historical data
o Enable stream based aggregation of data
Develop test cases and validation scenarios that enable the assessment of the
implemented architecture
This thesis was conducted under the umbrella of the second iteration of the research project
Line Information System Architecture (LISA2). LISA2 is a research project aimed to contribute
with a standardized software architecture that enables efficient management of data in today’s
automotive industries. The research project is a collaboration between the Swedish academia
and the Swedish automotive industry [2]. This work is contributing to the project with a
standardized software architecture that follows the LISA characteristics, a prototype software
stack implementing the LISA like architecture and a test case validating the software stack.
18
1.3 Methodology
During this work an iterative process has been used to develop the final software stack and the
simulation environment. The task and specifications about the final software stack have been
flexible and therefore, during the development process the specification has changed and been
adjusted to solve the present problems. In this sense, the methodology used during the thesis
work is visualized in Figure 1.
Figure 1 Visualization of the methodology used throughout the thesis work
As shown in Figure 1 this work began with a definition of the assignment which ended up in a
set of objectives . When the objectives were set, the process of gathering the required knowledge
started. This process resulted in a literature review presented in the chapter 2 and 3 of this thesis.
With the knowledge from the literature review, the desired solution was designed to meet the
proposed objectives. Test cases were developed with the purpose of validating the objectives
of the work. The solution was later implemented, tested and finally validated. During this work,
parts of the software were tested separately. Finally, in a later stage, when the entire stack was
completed, the tests and validations were done more thoroughly on the complete software stack.
The validations were done statically by calculation of the confidence interval and the variation
of the test runs.
Present result
Test and validate
Implementation
Design solution
Build knowledge
Thesis objective
19
1.4 Limitations
The main limitations during this work, were the lack of a shop-floor that could be used as a
testing environment, instead a virtual simulation model was used. This meant that all the
software needed, both for the software stack and the simulation, was executed on a single
computer resulting in a high usage of processing power. The high usage of processing power
did slow down the computer which resulted in slight fluctuations on the performance of the
developed architecture. An aspect of the software that not was tested was the networking
capabilities of the software stack, this because a virtual simulation environment was used.
The software stack was developed with the intention to be a prototype for industry to show the
potential of an event-driven architecture for collection of data, which means that part of the
implementation requires further optimization. What is limiting the software to be a prototype is
mainly the fact that it requires further development and testing to validate the performance of
the entire stack with the networking and database capabilities.
1.5 Outline of the work
In this first introductory chapter the background to the work, the objectives of the thesis, the
methodology used during the work and the limitations that the work has been restricted by is
presented. Also, this explanation of the work is present.
The second chapter provides a literature review of the current manufacturing trends and eras
that is relevant for this work. First, the concept of industry 4.0 and smart factories is explained,
then the era of big data is explained and last the different modern manufacturing paradigms
effecting todays manufacturing environment is described.
The third chapter also offers a literature review presenting the distributed intelligent
architectures that support the architecture developed because of this work. First the concept of
multi-agent systems is explained, second the services-oriented approach in software
architectures is presented and last the event-driven architectures are described.
20
The fourth chapter explains the architecture proposed in this work and all the building blocks
of the architecture. It starts with an overview of all the building blocks and then the chapter
presents the communication, the endpoint and the services in a detailed architectural way.
The fifth chapter explains the implementation of the architecture, thus the software stack itself
that is the result of this work. The chapter first presents the technologies used to enable an
implementation, then the implementation itself is described in detailed with the data model of
the software, the virtual simulation environment used for testing and last the test cases used for
assessing the software stack.
The sixth chapter presents and discusses the results from the simulation. The results are
discussed with the use of statistical methods to evaluate the results presented.
The seventh chapter is concluding the work and proposes future work to enable an
implementation of the software stack in a real production environment.
21
2 MODERN MANUFACTURING TRENDS
This chapter presents a literature review investigating the modern manufacturing trends that
support the new era of manufacturing. The trends such as industry 4.0 and smart factories, the
era of big data and modern manufacturing paradigms are described.
Manufacturing trends can be identified throughout the different industrial revolutions. Even
nowadays, one of the most commonly known trend, introduced by Henry Ford, derives from
the T-Ford that was designed for manufacturing. Henry Ford introduced the moving assembly
line and consequently the mass production of products. After Henry and mass production, the
next well-known trend was established by the demand of customized products at similar price
points to those produced in masses. The new demand for customization lead to the development
of the Toyota Production System (TPS) and to what is nowadays more commonly known as
lean manufacturing. Lean manufacturing spread fast in the manufacturing industry and mainly
in the automotive industry where it was first applied. The industrializations have up until the
3rd industrial revolution been driven by technology development, but instead, the 4th industrial
revolution is the result of an effort of several countries to bring the manufacturing industry
forward. The name for the 4th revolution was established by the German project “Industrie 4.0”,
and have since then been named Industry 4.0. Other trends such as big data, smart factories and
modern manufacturing paradigms contribute and play a big role in the realization of the Industry
4.0 vision [5]. These trends and industrial revolutions are investigated in the present chapter.
2.1 Industry 4.0 and smart factories
The 1st industrial revolution started with the introduction of steam and water powered
mechanical industrial systems, the 2nd industrial revolution was a result of introducing
electricity to the mass manufacturing industry and the 3rd industrial revolution was enabled by
the introduction of electronics and IT to facilitate the automated manufacturing industries.
Finally, industry is nowadays experiencing what is called the 4th industrial revolution which as
mentioned before is an initiative that aims to introduce among others, Internet of Things and
Services. The introduction of these technologies will enable connectivity and networking in
manufacturing systems, which will create a smart environment in factories, hence smart
22
factories. These industrial revolutions and consequent changes in the industrial world are
summarized in Figure 2.
Figure 2 Summary of the industrial revolutions and the drivers for each revolution
The initiative of the 4th industrial revolution is focused on ensuring the well-being of local
manufacturing industries and to discourage outsourcing [5]. To ensure the well-being of
industries, Industry 4.0 aims to facilitate the last few years of connectivity trends and emerge
towards predictive manufacturing. This demands devices in manufacturing to be intelligent and
connected. Cyber-physical system (CPS) are systems that connect the physical components
with a computational environment through a communication network. The virtual or cyber
environment can be used for monitoring and controlling of the manufacturing system. Through
the virtual environment, the different entities can seamlessly interact and engage in cooperative
activities towards common goals. Such connectivity also provides an environment where data
can be gathered and mined to optimize, predict and improve production efficiency [6]. CPS was
defined as follows [7]:
“Cyber-physical systems are hybrid networked cyber and engineered
physical elements co-designed to create adaptive and predictive systems for
enhanced performance. Performance metrics include safety and security,
reliability, agility and stability, efficiency and sustainability, privacy.”
The ability to connect and control the physical world through a computational environment was
possible before the introduction of CPS by embedded systems. These systems are limited in the
1st • Mechnical tools powered by water and steam
2nd • Mass production by divided labor and electricity
3rd • IT and electronics for automation
4th • Cyber-physical systems
23
sense that they are like closed boxes, they hide the data and functionality from the outside world.
Unlike embedded systems, the networking nature of CPS aids the collaboration between
devices and the expose of computational abilities to the outside world is beneficial for an
optimal production control [8]. CPS can connect with other systems over a network and has the
ability of collaboration between multiple CPSs [9]. This enables feedback directly from the
physical world and the amount of real-time data accessible will consequently and rapidly
increase. Introducing CPS in manufacturing industries connects all the physical and virtual
components of the production system and creates a cyber-physical production system (CPPS)
[10]. CPPS will transform the hierarchies in traditional automation systems to allow a more
decentralized and interoperable environment as visualized in Figure 3.
Figure 3 Illustration of the transition from traditional to CPS-based automation hierarchy [10]
The interactional and intelligent nature of CPSs together with its knowledge about the
environment enables the system to deal with disturbance and problems on its own [10].
Knowledge about the environment is achieved through the analysis and interpretation of data.
In a smart factory humans, machines and resources communicates like in a social network
which allows a larger amount of data to be considered during decisions. Smart factories have
the advantages of being flexible and adaptive to the production processes trough the
interactional and intelligent nature. This allows a rapid response to a fast-changing market and
the ability to deal with increased complexity in the production environment [11]. Smart
factories are an enabler for the industry 4.0 initiative and comprise all the technologies that
drives Industry 4.0, such as CPS, Internet of things, artificial intelligence and big data, among
others [5].
24
2.2 Big data
Because of the increased use of sensors and resources connected through networks, the amount
of data accessible in industry today is larger than ever before. To set the increase of data in
perspective; in the year of 2003 about 5 exabytes (1018 bytes) where created compared to 2013
when the same amount of data was created in two days [12]. This new era of increased data
production is described by the term “big data”. Big data is referring to a set of data that is large
enough to prevent traditional computational methods to analyze, store and manage it. Tracking
and analysis of this data could be done to manage and optimize the manufacturing processes,
as W. Edwards Deming wrote:
“If you can’t measure it, you can’t manage it”
The challenges in industry today, with all the data generated, is to utilize the data to gain
competitive advantages and optimize the manufacturing systems [4]. Traditional systems and
architectures are not capable of processing and utilizing these volumes of data, hence there is a
need for new architectures with the ability to process and utilize the huge volumes of data
created in the next generation of smart factories.
In such factories, CPS can be used to manage big data and employ the information to increase
intelligence, robustness and flexibility [6]. The data need to be transformed to useful
information and made available for involved resources in the system. The low-level data from
sensors and such is not valuable unless it’s processed and transformed into information with
meaning and a context, which can be achieved by combining CPS with big data [13]. With the
huge amount of data, big data contributes to flexibility and adaptability, which are the main
drivers for modern manufacturing paradigms, and these huge quantities of data enable modern
manufacturing paradigms.
2.3 Modern manufacturing paradigms
Through the industrial revolutions different paradigms have been more popular than others,
some of the more well-known paradigms are mass production and lean manufacturing. With a
market that is more rapidly changing and demands higher flexibility, customization and
sustainability a new set of manufacturing paradigms arose [14]. The manufacturing paradigms
25
considered nowadays, together with some of the main historical paradigms, can be found in the
timeline presented in Figure 4. The manufacturing paradigms, such as holonic manufacturing
systems (HMS), reconfigurable manufacturing systems (RMS), evolvable production systems
(EPS) and cloud manufacturing (CMfg) aim to cope with today’s challenging industrial
demands and are commonly referred to as the modern manufacturing paradigms.
Figure 4 Timeline placing manufacturing paradigms in time [15]
The modern manufacturing paradigms have the goal to meet the challenges related to the global
market of today. These paradigms have a similar approach in many ways. They are all aiming
to have a flexible production environment that can handle a high variety in products and deal
with a high rate of new products entering the market. The paradigms also strive for adaptable
and scalable manufacturing systems with the ability to cope with high fluctuations in demand.
Most of these modern paradigms follows the approach of product intelligence [15]. An
intelligent product is a product that has information and rules about the processes desired to
produce itself. The product should have some or all the following characteristics; a unique
identity, capability of efficiently communicating with its environment, store or retain data about
itself, use a language to display its features, knowledge of production requirements or capable
of making or partaking in decisions relevant to its own destiny. Product intelligence can be
divided into different levels; either the product is information-orienting which means that it can
communicate its status, or the product is decision-oriented which means that is can influence
decisions about itself and communicate with its environment [16]. Either way an intelligent
product is partaking in the manufacturing of itself by providing information to the production
environment. The last sections of chapter 2 is explaining the modern manufacturing paradigms
relevant to this thesis.
26
2.3.1 Holonic manufacturing systems
Holonic manufacturing systems (HMS) was introduced with the aim to bring adaptability,
safety and robustness to manufacturing industries to allow a just-in-time production and
responsiveness to meet the new demands of the fast changing global market. HMS is allowing
this by offering a resistance towards disturbances via a reconfigurable structure that have the
ability of dynamically organizing both physical and virtual modules [17]. The self-organization
that each entity can participate in is beneficial for meeting the requirements and changes of the
current market such as adaptability and autonomous decision making. HMS is aiming to meet
the new demands of the market by adapting behaviors of social interaction to the manufacturing
systems. To reach this social interaction behavior, HMS introduces the “holon” as a main
construct of the manufacturing system. And by this consequently offering a decentralized and
dynamic production environment [18].
A holon is simultaneously part and whole, meaning that a holon can be considered as the whole
system or part of the system itself. The term holon was first defined by A. Koesler and is a way
of describing a living organism. Living organisms can change their structure and are part of a
self-adapting hierarchy while at the same time having an autonomy and interacting behavior.
This autonomy and interacting behavior are making the holons to reorganize by adopting to
changed conditions of the environment when the holon is part of a network [18]. HMS
encompasses the properties of both heterarchical and hierarchical structures. In this sense, it
can explore the advantages of both these approaches. During normal operational conditions, the
system assumes a hierarchical behavior while during disruption the system or part of it can
assume a more heterarchical behavior. This means that during disruption the system adopts the
dynamic flexibility of heterarchical structures and the stability from hierarchical structures
during normal operation [19]. This flexible structure of HMS that is specific for holons is named
a holarchy, a holarchy is visualized in Figure 5.
27
Figure 5 A set of holons that makes a holarchy [20]
By introducing a set of definitions for capabilities that a HMS should fulfill, the translation of
the holonic concept into a manufacturing context is enabled. These definitions were set by the
HMS consortium and are [21]:
“Holon – An autonomous and co-operative building block of a
manufacturing system for transforming, transporting, storing and/or
validating information and physical objects. The holon consists of an
information processing part and often a physical processing part. A holon
can be part of another holon.
Autonomy – The capability of an entity to create and control the execution
of its own plans and/or strategies.
Co-operation – A process whereby a set of entities develops mutually
acceptable plans and executes theses plans.
Holarchy – A system of holons that can co-operate to achieve a goal or
objective. The holarchy defines the basic rules for co-operation of the
holons and thereby limits their autonomy.
Holonic manufacturing system – A holarchy that integrates the entire
range of manufacturing activities from order booking through design,
production, and marketing to realize the agile manufacturing enterprise.
28
Holonic attributes – Attributes of an entity that make it a holon. The
minimum set is autonomy and co-operativeness.”
2.3.2 Reconfigurable manufacturing systems
Reconfigurable manufacturing system (RMS) is, as the other modern manufacturing paradigms,
dealing with challenges connected to the new global market. RMS is especially dealing with
the challenges related to rapid introduction of new products, high fluctuations in demand,
delivering high-quality products at low cost and changes in production technology. RMS was
introduced with the vision to overcome these challenges by having the ability to change capacity
and functionality exactly when needed, RMS also have the capability of scalability and
responsiveness towards the market as a result of dealing with fast changing products and
technology [22]. RMS is defined as follows [22]:
“A Reconfigurable Manufacturing System (RMS) is designed at the outset
for rapid change in structure, as well as in hardware and software
components, in order to quickly adjust production capacity and
functionality within a part family in response to sudden changes in market
or in regulatory requirements.
RMSs are designed to handle rapid changes in its structure, both for hardware and software
components. The paradigms also promote a fast-changing production capacity and functionality
within a product family. RMS is constructed by software and hardware components that can
rearrange quickly and reliably to enable reconfiguration [23]. RMS have a few core
characteristics for a successful implementation, these are defined below [24]:
“Modularity – the compartmentalization of operational functions and
requirements into quantifiable units that can be transacted between
alternate production schemes to achieve the most optimal arrangement to
fit a given set of needs.
Integrability – the ability to integrate modules rapidly and precisely by a
set of mechanical, informational, and control interfaces that enable
integration and communication.
29
Convertibility – the ability to easily transform the functionality of existing
systems, machines, and controls to suit new production requirements.
Diagnosability – the ability to automatically read the current state of a
system and controls so as to detect and diagnose the root-cause of defects,
and subsequently correct operational defects quickly.
Customization – the ability to adapt the customized (non-general) flexibility
of production systems and machines to meet new requirements with a family
of similar products.
Scalability – the ability to easily change existing production capacity by
rearranging an existing production system and/or changing the production
capacity of reconfigurable components (e.g., machines) within that system.”
A RMS that embed these characteristics is configurable and will serve as a cost-effective
alternative to the highly flexible and highly productive production system.
2.3.3 Evolvable production systems
Evolvable production system (EPS) is especially addressing the uncertainty of a global market
by supporting the evolution of the components in the production system. EPS is dealing with
the uncertainty and evolution by offering a modularized, intelligent and open architecture and
a distributed control [25]. There are two fundamental guiding principles for EPS, these are [25]:
Principle 1: The most innovative product design can only be achieved if no
assembly process constraints are posed. The ensuing, fully independent,
process selection procedure may then result in an optimal assembly system
methodology.
Principle 2: Systems under a dynamic condition need to be evolvable, i.e.,
they need to have an inherent capability of evolution to address the new or
changing set of requirements.
In the approach of EPS each component is considered to be a distributed intelligent unit. The
evolvability means that the system can evolve to adapt to new trends and challenges. This
30
evolution of the system is achieved by properties like emergence and self-organization.
Emergence and self-organization is inspired by the biological world; these concepts describe
the phenomena of entities in a system that collaborates and interacts to achieve a common goal.
The emergency of EPS is represented by the systems capability of bringing modules together
to form new systems. By bringing them together the sum of the systems contribution is greater
than the sum of each individual components contribution [26].
EPS and HMS have similarities in the conceptual approach in the sense that they are both
biologically inspired with the difference that only EPS is achieving fine granularity. Granularity
is describing the included components complexity level; i.e. thick granularity is cells on a
production line and fine granularity is smaller components as grippers and sensors [26].
2.3.4 Cloud manufacturing
Cloud manufacturing (CMfg) is mainly aiming to overcome challenges related to having more
cost-effective manufacturing systems and satisfying a more dynamic customer demand. As the
other modern paradigms, CMfg is addressing other challenges related to a global market like
demand fluctuations, flexibility and fast introduction of new products [27]. CMfg is divergent
from the other paradigms in the sense that CMfg is aiming to achieve a resource and information
sharing manufacturing environment. CMfg is an intelligent computing and service-oriented
manufacturing model. Service orientation is addressed and described in chapter 3.2. In CMfg
recent developed technologies like cloud computing, Internet-of-Things, service-orientation
and advanced computing play a central role. These technologies have the benefit of working in
a way that allows information sharing from the beginning, this by being networking
technologies. CMfg aims to achieve a model where knowledge is shared between parties,
enabling a high utilization and on-demand use of manufacturing resources. These goals are
going to be met by providing safe and reliable, high quality, cheap and on-demand
manufacturing service [28].
CMfg paradigms is affecting more than the manufacturing system, cloud manufacturing is a
way of working for the whole enterprise. CMfg also emphasizes on collaborating with other
environments outside the enterprise. The CMfg paradigm is especially important for small and
medium enterprises where the benefit from collaboration to compete against the large
enterprises is outstanding. CMfg is supporting a change from production-oriented industries to
31
service-oriented industries. Service-oriented industries would contribute to the introduction of
a cyber society that facilitates cyber-physical manufacturing in the future [29]. Figure 6 is
visualizing a simplified concept of how cloud manufacturing works.
Figure 6 Cloud manufacturing in a simplified visualization [29]
The vision for cloud manufacturing is that all manufacturing resources and capabilities should
be encapsulated and available as services for the consumers from the manufacturing cloud [27],
as shown in Figure 6. In a CMfg there is primarily three categories of users and these are service
consumer, operators and service providers. The service consumes are using the services in the
manufacturing cloud, they are purchasing the services in the cloud from the operators in the
cloud. The operators are maintaining the cloud and organizing and providing the services
available to the consumers. And the service providers own and provide the resources available
in the cloud as services [28].
Services offered by the could can be divided into two types of services and these are OnCloud
and OffCloud services. OnCloud services take place in the cloud and is computational resources
such as functionality from different software’s. OffCloud services is taking place outside the
cloud and usually with assistance of an operator, these services include machining operations
and logistic services. For the OffCloud services the manufacturing cloud can be used for
scheduling and monitoring [29].
32
3 DISTRIBUTED INTELLIGENT ARCHITECTURES
The present chapter provides an overview of the distributed intelligent architectures that
supports the implementation of the architecture developed during this thesis. First the concept
of multi-agent system is described, then the service-oriented software architecture is explained
and last the event-driven architectural approach in software development is addressed.
Distributed and intelligent architectures is a common approach to support the implementation
of the new modern manufacturing paradigms. A distributed software architecture allows
computational processing to take part in individual parts of the software architecture, the
processing is distributed all over the architecture. The intelligence in software development is
known as the ability for entities to make decisions on its own either by predefined conditions
or by having knowledge of the surrounding environment. The combination of these two
software development approaches gives an architecture that have distributed resources with an
intelligent behavior that is collaborating towards a common goal. The following three sections
provide an overview of the main distributed intelligent architectures influencing the architecture
presented in chapter 4.
3.1 Multi-agent system
Multi-agent system (MAS) derive from the field of distributed artificial intelligence, and is
characterized by decentralization and parallel execution of activities [30]. MAS is a network
of computational agents with the ability of interacting and communicating with each other. An
agent is an entity in a dynamic environment with autonomous and intelligent behavior that
compress computational power. The most important properties of an agent is that it has a
purpose, it is autonomous, it encapsulates intelligence, it has the capability of interacting with
the environment and it is adaptive. An agent has some abilities related to its environment; agents
can observe its environment, has information and theories about its environment, has
knowledge about the state of its environment and takes action to change the environment [31].
In a MAS decisions and actions of agents is affecting the other agents in the system and agents
can exhibit emergent behaviors to fulfill common goals. Agents in a system must coordinate
their actions with other agents to take the effects of other agents into account when making
33
decision. Models that coordinate the interaction of agents need to have some media where the
interaction can be achieved, a communication channel such as an enterprise service bus (ESB),
and rules for managing the interaction and dependencies of agents. The communication
environment also needs a syntax who the agents can use to interact with each other in a
standardized way, meaning that the agents need to use a common communication protocol [31].
A few characteristics can be identified for agents; these characteristics are [31] [32] [33] :
Autonomy – agents are autonomous, considering that they control their internal state
and behaviors on the environment.
Rationality – agents are rational as they can reason about the data they receive in order
to better achieve their goals.
Adaptability – agents are adaptive in the sense that they can learn and modify their
behavior according to the environment to better achieve their goals.
Reactivity – agents can react, chaining their behavior instantly according to their
perception of the environment.
Proactive – agents do not simply act in response to stimulus, they can also take the
initiative when appropriate in order to attain their own objectives.
Social-ability – agents are social as they communicate with other agents to share
information and participate in collective behaviors.
Mobility – agents can move inside their network and maintain their internal state and
knowledge.
Agents have the possibility to exhibit emergent behaviors as stated before, this gives them the
possibility of collaborating with each other. This collaboration manifested by agents’ ability to
agree upon a common goal or a task and then take actions in a sequence towards fulfilling the
goal or executing the task. For example, if the task of a MAS is to perform scheduling and
execution of an order agents in the system can collaborate and perform each task needed to be
completed before delivering the order at a given due date [31].
3.2 Service-oriented architecture
Service-oriented architectures (SOA) originate from the need of a conceptual design that
encapsulates processing functionality. By encapsulating the processing, the user of the
34
functionality does not need to know where the processing is done. This encapsulation is making
SOA offering a modular, interoperable and reusable way of developing and implementing
software. This is done by exposing self-contained applications as a service [34]. A service
consists of an interface and a functional implementation, the interface is the only thing that is
known to the environment and the implementation is often represented by a business function.
The service interface is offering the mechanism that allows other entities in the system to
communicate and use the functionality of the service. A service is like a black box for the other
entities in the system, the only thing that is known by the other entities is how the functionality
can be used. This is achieved with a standardized interface which also provides modularity by
making the service a module. The modularity and interoperability of SOA is making SOA a
scalable software architecture [35]. Service oriented architectures supports the implementing of
the modern manufacturing paradigms from chapter 2.3. A basic SOA is illustrated in Figure 7.
Figure 7 Basic SOA, the interaction between service provider, service registry and service client [35]
In the basic SOA implementation, there are three entities that have different responsibilities and
actions. There is a service provider offering some functionality through its interface, a service
registry that registers the services available in the environment and a service client that is
utilizing the functionality of the services. There are three actions possible to make use of in the
implementation, these are publish, find and bind. The publish action is used by the service
provider which is using the action to publish a description of itself in the service registry to
enable services to find it. The find action is used by the service client to lookup services with
the correct description and functionality. And last the bind action is used by the service client
to create a connection to the service provider providing the right functionality [35].
The environment where the services are available is a network and ideally a public network
offering the possibility to share services between organizations. The communication in the
35
network is often done with the use of an Internet based protocol such as HyperText Makeup
Language (HTML) or Simple Mail Transfer Protocol (SMTP) [34]. In a SOA network the
entities are loosely coupled due to the use of standardized interfaces. An interface of a service
should be defined in a way so the service can be used in a larger business processing context.
The communication in a SOA is asynchronous which differs from regular object-oriented
architectures, which means that if a function is called in a service the result is returned to the
client without suspending either the provider nor the client [36]. The orchestration of the
services is often done centrally in SOA which means that an orchestrator has the control over
the services [37]. An asynchronous communication can be attained by employing the SOA with
an ESB.
An enterprise service bus (ESB) is a technology often used to enable the communication
between services in a SOA. An ESB is a bus where messages can be transferred between
distributed applications in a secure and reliable way, it offers services such as routing,
invocation and mediation. In Figure 8 a simplified ESB is visualized. The ESB has a message
broker that has a central role in this type of infrastructure, the broker is mediating the messages
and is routing them to the right service container. The service container is hosting services that
makes it possible for applications outside the ESB to connect and communicate through the
ESB. In a ESB there can be multiple service containers and a service container can host multiple
services [38].
Figure 8 Simplified view of an ESB. Note that a service container can host multiple services [38]
36
An example of SOA implementations are websites like Google, eBay and Amazon that offers
services to be utilized by developers to enable the combination with other services. When big
enterprises offering services to be utilized by developer’s new application can be developed by
the involvement of the users [34].
3.3 Event-driven architecture
Event driven architecture (EDA) is an architecture that is orchestrated using events transferred
or displayed within the architecture. An event is a change of state or some other occurrence
with a significance for the system. In a EDA, an event triggers other entities in the system that
has an interest in the event occurring [39]. The event could be an emergency signal that trigger
an automated action that stops all the machines on the production line or notifies an operator
that performs a measure. An EDA can register and act on such event in an intelligent way [40].
Meaning that an EDA can make intelligent decisions about the action to take when an event
occurs.
A simple example of an event-driven technology is from the world of control technology. In
the example, events are used to control the heating in houses. The technology is a thermostat;
it’s used for controlling the heating element and turning on the heating when the temperature is
below the set value. A thermostat is measuring the temperature and when an event is occurring,
the thermostat turns on or turns off the heating elements. If the thermostat is turning the heating
on or off is dependent on the type of event occurring, either the event occurs when the
temperature is below or above a set value. This is a simple event-driven system and it’s the
same concept that is implemented in an EDA [40].
EDA is loosely coupled and highly distributed because of the way it’s acting. It’s only the
creator of an event that knows that the event happened and the creator has no knowledge of
other entities in the system that is acting upon the event. The actors only know what event to
act upon and not who the creator is nor where the event is coming from, unless the event itself
is holding information about the creator and the origin [39].
37
4 EVENT-DRIVEN ARCHITECTURE FOR DATA
COLLECTION IN SMART FACTORIES
This chapter explains the architecture developed during this work inspired by the LISA project.
The software architecture is an explanation of the building blocks constructing the software
and the conceptual interaction between them. The first section provides an overview of the
architecture, then the communication between the building blocks is described, later the
endpoints of the system is introduced and last the services are addressed.
The event-driven architecture for data collection in smart factories proposed in this chapter
supports an implementation that fulfills the objectives of this work. This architecture was
constructed with the influence of distributed architectures. The architecture also compresses the
ability to enable implementation of the modern manufacturing paradigms explored during the
literature review of this work. An architectural overview of the entire software stack developed
is presented in Figure 9. The colored birds in the figure represents the messages on the bus and
the communication between each building block of the architecture.
Figure 9 An overview of architecture developed during this work
38
In Figure 9 the channel in the middle is representing the ESB, different endpoints and services
are also visualized with a more detailed view of the communication with hardware. The
different endpoints, services and the communication is described in the upcoming sections of
this chapter. This first part is presenting a detailed overview where the next sections are
breaking down the architecture into its building blocks and providing the knowledge to
understand the architectural concept depicted in Figure 9.
4.1 Architectural overview
The event-driven architecture for data collection in smart factories developed during this thesis
is as the title reveals, an event-driven architecture with the ability of collecting data from a
shop-floor in any smart factory. The architecture developed is implemented as a SOA with the
functionality of a EDA and each entity in the system is inspired by a MAS to give each entity
the required intelligence to fulfill its objectives. The architecture presented in this thesis has a
main bus that enables communication between entities, this bus is an implementation of a ESB
and serve as a communication channel for the entities in the system. The main entities in the
system are the endpoints that encapsulates one or more micro-services. A generic overview of
the ESB with endpoints and services is visualized in Figure 10.
Figure 10 Generic overview of ESB that constitutes the event-driven architecture developed. The endpoint is an
entity on the bus and a placeholder for services where m and n is a positive integer.
In the architecture developed the ESB is central part which supports the communication
between the entities in the system. One or more endpoints are connected to the ESB, an endpoint
encapsulates more than one service and manages the execution of each service, more on
endpoints in chapter 4.3. A service is a basic computational entity with the ability of offering
39
functionality to other services on the ESB, these services are like services in a SOA, more on
services in chapter 4.4. The next sections of this chapter 4 is describing the communication, the
endpoints and the services closer and in a more detailed yet generic way.
4.2 Communication
The communication between endpoints with encapsulated services is done through
standardized messages that is mentioned as tweets in a publish and subscribe fashion. Each
tweet is a result of an event occurring in the architecture, a service is registering the event
occurring and sends a tweet with information about the event, triggering other services on the
bus. The functional core of the service is constructing the tweet, a publisher is publishing the
tweet on the ESB to the related channel and then a subscriber is receiving the tweet from the
ESB. From the subscriber, the information is transferred to the functional core of the service.
The ESB have different channels available for publishing and subscribing of tweets, as seen in
Figure 11.
Figure 11 Conceptual picture of ESB with its hierarchy of channels
The conceptual picture is presenting how the ESB is working, it shows that each channel can
be divided into sub-channels and a hierarchy of channels is possible to achieve. The hierarchy
of channels is useful when the information and data on the bus do not need to reach all the
endpoints. Each endpoint subscribes only to the channel that it has an interest in and if an
endpoint needs all information on the bus it subscribes to the highest level. When an endpoint
receives a tweet from the bus it needs to process the information in the tweet to decide whether
40
it should act on it or not. Using channels limits the number of messages each endpoint receives,
this decrease the processing power needed for each endpoint. The transportation of tweets
through the different channels is exemplified in Figure 12.
Figure 12 Example of how the subscribing and publishing in different channels work
Figure 12 is showing one channel named “C”, the first sub channel to that channel is named
“C.1” and the second sub channel is named “C.2” and so on. There is no restriction in the
naming; the input for the naming is strings and the strings are differentiated with dots to make
the sub-channels. Either a subscriber can subscribe to a sub-channel or to a main channel, if it
subscribes to a main channel it will receive everything from the sub-channels, but if a subscriber
subscribes to a sub-channel it will only receive tweets available in the sub channel. The example
in Figure 12 is visualizing the different type of publishers and subscribers, “Sub C” is receiving
everything in “C” and “Sub C.1” only receives everything from “C.1”.
4.2.1 The tweet
The tweets or as it’s called in an EDA, the events, is a central entity in the architecture. It’s the
tweet that triggers and enables the execution of functional tasks in the system. The tweet that is
used for transferring information through the ESB is an object built up by two separate objects,
a header of the tweet and a body of the tweet as visual in Figure 13.
41
Figure 13 Generic description of a tweet in the architecture
The header of the message contains information about the message entity itself and the message
body contains the data that the message is carrying. The message header has a unique ID that
differentiates a message from other messages in the system, it carries information about the
time of creation for the message, it has the ability of carrying information about earlier actions
taken to the message, it knows about who the sender of the message is and carries information
about whether the receiver of the message needs to confirm a successful delivery. The message
body has information that tells about what type of information the message is carrying and the
body also contains a list of data that the message is carrying. The list of data is in the form of
key pair values, each object in the list contains information about the type of data the object
carries and the data itself. This is enabling a tweet to carry more than one data value and that
the data can be iterated and filtered.
The communication through the ESB is done with texts which means that all the tweets can be
translated to text from objects and back to objects from text. The tweet can be converted
between text and objects in a vendor independent way.
4.3 Endpoint
An endpoint is a placeholder for services in the architecture where the services within one
endpoint belongs to the same logical domain. This means that if one service offers the
42
functionality of transforming data related to logistics the other services also should be, in
principle, related to logistics. Given that one endpoint and its services belongs to the same
logical domain a set of predefined endpoints was defined during the work to ease the seamless
deployment and development of endpoints. An endpoint is an individual entity in the
architecture with a unique set of services with unique functions, each endpoint encapsulates at
least one service or more. Each endpoint is responsible for executing the encapsulated services
and providing the connection for each service to the ESB. A conceptual template for a generic
endpoint is visible in Figure 14.
Figure 14 Conceptual template for a generic endpoint in the architecture
As seen in Figure 14, each endpoint is constructed by information, functional objects and
services. The information available in a generic endpoint is the name and a simple description
of the endpoint including the logical domain and main functionality of the endpoint, and
information about the configuration related to the endpoint such as information about the
authentication information for the ESB. The functional objects accessible in the endpoint is the
connection to the ESB, making it possible for each service to communicate through the ESB.
The services implemented is not limited to a maximum number, but have the requirement of at
least one.
The endpoint and its purpose is mainly decided from the logical domain of the services
encapsulated within the endpoint. In the architecture, the endpoints are divided into two clearly
differentiated categories, the next sections in this chapter is capturing the essential details about
the virtual and the device endpoint.
43
4.3.1 Virtual endpoint
The virtual endpoints basic function is to gather and act upon tweets to generate new tweets
with the resulting mined information. Often a virtual endpoint has the purpose of transforming
a tweet by either adding information or aggregating tweets to new tweets containing aggregated
data. A virtual endpoint can also be used for storing information to a database or monitoring
the entities and events occurring on the ESB. A virtual endpoint is defined as an endpoint that
utilizes the tweets on the bus and is translating or action upon the information in the tweet. The
virtual endpoint is translating low-level data to a higher-level type of data.
4.3.2 Device endpoint
The device endpoint is an endpoint that is reading data from a device on the shop-floor and
making it available for other entities in the architecture. A device endpoint is making the data
available by publishing tweets on the bus for the other entities to access. The device endpoint
has the capability of communicating with the device related to it, and this in a vendor
independent way. This is enabled by the dynamic load of libraries that enable the
communication with the devices. A device is hardware on the shop-floor, typically
Programmable Logic Controllers (PLCs) and other control devices among others. A device
endpoint takes low-level data and makes it accessible for other entities in the architecture.
4.4 Services
A service is an entity with functionality in the architecture and offers its functionality to other
services within the same system. The functionality that each service offers is quite trivial, for
example aggregating data to offer intelligible information to the other services. Services can be
combined and aggregated to offer more complex functionality for the architecture, for example
using data offered by other services to calculate new information for the system. A service also
encapsulating the capability of outputting information on the ESB and taking input from the
ESB. A conceptual template of a generic service is visible in Figure 15.
44
Figure 15 Conceptual template of a generic service in the architecture
As the endpoint, services are also constructed by information and functional objects, the
difference is that a service is offering some type of core functionality to the architecture. The
information accessible in the service is the name of the service and a short description of the
service’s functionality. The functional objects of the service are a subscriber and a publisher for
the ESB. The subscriber is subscribing to a specific channel on the ESB and is receiving all the
tweets published in the specific channel. The publisher on the other hand is publishing tweets
to a specific channel on the ESB with the purpose of communicating information to the other
services in the architecture. The core functionality is performing the computational processing
of the service, for example the computational process could include transformation of data to
intelligible information and managing database access. The main purpose of the core
functionality for a generic service is to gather data from the ESB and outputting new data to the
ESB.
The functional core is separated into different execution states; the states are represented by
different execution condition that the service can enter during runtime. A few examples on
different states are one state during execution, one state during action and one state during
shutdown. The service core has different methods that are executed depending on the present
state of the service.
A service can, as stated before, belong to different logical domains and all services in one
endpoint should belong to the same logical domain and it is the logical domain represented by
the services in each endpoint that is deciding what kind of endpoint it is. In the architecture, a
set of predefined services are available, all the services have the basic functionality of a basic
service but extends the basic services with added functionality and behaviors. The last sections
of the present chapter are describing each predefined service and its template.
45
4.4.1 Transformation service
A transformation service takes a tweet and transforms the tweet by adding information then
publishing it back to the ESB. In the architecture, it is differentiated between three
transformation actions that can be performed. These actions are; adding static information,
adding dynamic information and aggregating data from multiple tweets to generate a new tweet
with aggregated information. These actions are referred to as fill, map and fold in the
architecture, a basic representation of the different services is visual in Figure 16.
Figure 16 Descriptive visualization of fill, map and fold services
The fill service takes static information and adds it to the tweet it publishes on the ESB. The
static information is information that always had the same format, for example information
related to the sender endpoint for instance id of the endpoint or the product type dependent on
information read from a Radio-Frequency Identification (RFID) tag. The map services are
adding dynamic information to the tweet, this dynamic information could be new data
dependent on the state of the system i.e. dynamic. Both the fill and map service is adding or
changing the tweets without changing the unique id or timestamp of the message. The fold
action on the other hand is aggregating tweets to create a new tweet with the aggregated data
from the other tweets. The fold service can be used for tracking when a unique product is
entering and exits the production line and then calculating the cycle time for one product of
throughput time for one batch.
4.4.2 Monitoring service
A monitoring service is tracking and monitoring the actions executed in the architecture, there
are two predefined monitoring services in the architecture. These two predefined monitoring
services are event monitoring service and service monitoring service. In the architecture, it only
makes sense to have one instance of event monitoring service and one instance of service
monitoring service. The monitoring service is tracking either events or services on the ESB and
46
offering a lookup service for the different events or services accessible through the ESB, the
two different monitoring services is visualized in Figure 17.
Figure 17 Visualization of the two different monitoring services, event monitoring and service monitoring
The event monitoring service is receiving all the messages transported on the bus and saving
information of the different types of events. The information about the different events is then
offered as a lookup service for other services in the architecture. The service monitoring service
is receiving a message each time a new service is deployed in the system. The message contains
descriptive information about the service, the information is saved and offered as a lookup
service for the other services in the system. Compared to the basic SOA example in chapter 3.2
the service monitoring service is serving as the service registry.
4.4.3 Database service
The database services are offering the possibility of history access for each service in the system
and is also gathering all events occurring in the system to save it to a database. In the
architecture two different database services are defined, one is indexing database service and
the other is persistent database service. The different between the indexing database service and
the persistent database service is the type of database and the functionality of the service. The
indexing database service provides a fast lookup and searchable database where historic data is
easy and fast accessible. The persistent service is saving all information and is robust towards
disturbances, it has a more stable database structure that do not lose any data. This persistent
database service has the ability of offering historic data for a long time back. These two database
services are basically identical in an architectural context apart from the type of database they
work with. See the visualization in Figure 18.
47
Figure 18 Descriptive visualization of a database service
Both these services offering data availability as a service with the main difference that the
indexing database offers fast searched data but not as robust as the persistent database and the
persistent database offering searchable data but not as fast. For folding services using historical
data for calculation of new aggregated data, the indexing database is to prefer.
4.4.4 Device communication service
The device communication service is offering the functionality of communicating with
hardware components on the shop-floor. It is offering a generic interface for communicating
with hardware which enables a vendor independent communication. It uses dynamic loading of
libraries to enable the change of communication protocol during runtime and in that sense a
dynamic execution of endpoints and services, see Figure 19.
Figure 19 Descriptive detailed visualization of device communication service
The device communication service is the main service in a device endpoint, it enables the
communication with the device in a device endpoint. It reads low-level data in an asynchronous
way and offers the data to the ESB by publishing tweets.
48
5 IMPLEMENTATION
This fifth chapter presents the implementation of the architecture into the ultimate software
stack. The first part is describing the architectural implementation and its data model in detail.
Secondly the technologies used for the implementation is presented and the purpose of the
technology. Then the virtual simulation environment and the shop-floor used for testing is
described and last the test cases used for the assessment of the software stack are presented.
The implementation of the architecture developed during this work, and as presented in chapter
4, require an object-oriented programming language. The implementation also requires a
message bus of some sort to facilitate the ESB, communication with hardware during testing,
and databases to enable transformation and computation of both present and historical data. The
object orientation was realized with use of the programming language Java [41].
5.1 Architectural implementation
The implementation of the architecture used the enabling technologies and Java as the
programming language to connect all the application and to add functionality to the software
stack. The setup of the software stack and a basic example is explained in Appendix I –
LISA2Core setup. The software stack presented in this section of the thesis have the purpose to
be a template when implementing the software in a real production environment. The software
stack should be used as a library when developing solutions with the event-driven architecture
presented in chapter 4. The implementation implemented the endpoints and services, this first
section presents the overall implementation and the upcoming sections goes deeper into detail
explaining the endpoint core, the service core and last the messages, or tweets as mentioned in
the architectural chapter.
The programming language used for the implementation is, as mentioned, Java which is
enabling the development of an object-oriented software stack with the characteristics of SOA,
EDA and MAS. The implementation enables endpoints to connect with the ActiveMQ
communication bus to be used as an ESB. JavaScript Object Notation (JSON) were used as the
text based format for transporting messages and Open Platform Communication (OPC) were
used as a communication protocol with the simulation environment. The entire software stack
49
was developed based on Open Services Gateway initiative (OSGi) to enable the modular
deployment particularly of the device endpoints and the lower level libraries that support the
connection with the hardware.
The main classes of the implementation were the LISAEndpointCore class and the
LISAServiceCore class. These are abstract classes and were used as templates when developing
a software with the architecture. The endpoint class enables the deployment of services and the
services enables the development of functionality. The class diagram for the main classes in the
architecture is visible in Figure 20. The service core is offering a set of execution states for the
services, depending on the state the endpoint executes different methods in the services. The
different states are SETUP, STARTUP, ACTION, END and WATING.
Figure 20 Class diagram of the main classes in the implementation. The LISAEndpointCore and the
LISAServiceCore.
50
The next sections present the functionality of the core classes in a more detailed way, first the
core of the endpoint, then the core of the services and last the messages used for the
communication is presented.
5.1.1 Endpoint core
The endpoint core is a template for development of endpoints and have two main purposes, the
first is to serve as a runtime environment for the services and the second is to nurse the
connection to the ActiveMQ communication bus. The LISAEndPointCore is implementing the
functionality of a runnable in java, this to enable the execution of endpoints in parallel through
different threads. The class diagram explaining the classes building up the core of the endpoint
is visible in Figure 21.
Figure 21 Class diagram explaining the endpoint core, the configuration class and the runnable functionality of
the endpoint
51
The attributes of the endpoint core class supporting the architectural implementation and their
functionality is described as follows:
-url : String – a string with the Uniform Resource Locator (URL) used for connecting to
the ESB. The url is constructed by the ip address and the port number of the connection.
-username : String – the username used for the connection to the ESB.
-password : String – the password used for the connection to the ESB.
-connectionFactory : ActiveMQConnectionFactory – is an object used for creating the
connection to the ActiveMQ, it is a class from the ActiveMQ library. The object has the
functionality of establishing the connection to the ActiveMQ bus and create the connection
attributes.
-connection : Connection – this object is from a sub-library to the ActiveMQ library which
is the JMS library. The connection object encapsulates the open connection to the ActiveMQ
bus and is the objects that authenticating the client during the creation of the object.
-config : Config – the config object have configuration information about the endpoint, such
as username, password, IP address and port number for the ActiveMQ bus. It also has methods
that enables the functionality of setting and getting the values of the attributes. When creating
the config object, it should be done through calling a creation method in the class
configfunctions the reads a file called “application.conf” from the root folder of the runtime
environment. The application file has a JSON formatted text with the attributes of the config
class and a new instance of the config class can be created from that JSON file by the use of a
translation function.
-endpointThread : Thread – the endpoint thread object is the placeholder for the thread
that the endpoint runs in. It’s used for staring the execution of the endpoint and execute the run
method.
+services : HashMap<String, LISAServiceCore> – a hash map with all the services within
the endpoint. All the services inside this map is to be executed during runtime of the endpoint.
52
+dataMapping : ListMultimap<String, String> – this list multimap is a way for the
services within each endpoint to exchange data without using the ESB. The multimap is like a
hash map with the benefit of allowing multiple instances of the same key. When the services
add data to the map, the key string used is the name of the service, and by allowing multiple
instances of the same key it prevents error in the case where one service adds multiple types of
data.
-ipAdress : String – the IP-address attributes is holding the IP-address of the machine the
endpoint is running on.
-endpointName : String – the endpoint name attributes is a placeholder for the name of the
endpoint. The name should reflect the logical domain of the endpoint.
-endpointDescription : String – this description of the endpoint is used to describe the
functionality of the endpoint in a more detailed way than the name.
The endpoint is implementing a runnable which means that the instance of the endpoint can be
executed concurrently in a thread, the method that is executed when running in a thread is the
run method. The endpoint core has different get and set methods that all have the same
functionality. The get methods are returning the value of the attributed related to it and the set
methods assign the value of the attribute connected to it. The methods that differs from the set
and get methods are:
+LISAEndPointCore() – this is the constructor of the endpoint and executes some setup
actions when the endpoint is created. The setup actions are getting an instance of the config
object from the configuration file, setting the value of the URL, username and password,
creating the endpoint thread and assign the endpoint to that thread, and last it sets the IP-address
attribute.
+createConnection() : Connection – the create connection method creates the connection
to the ActiveMQ bus by getting it from the ActiveMQConnectionFactory object. It starts the
connection and returns the connection.
+run() : void – this method is the method that concurrently executes when the thread
withholding the endpoint is active. The run method of the endpoint is executing the services in
53
the hash map by following the activities presented Figure 22. It’s also in the run method the
execution frequency of the service is considered, this is not presented in Figure 22. When the
execution of the action method is due a check towards the execution frequency set by the service
and the last execution timestamp is done to decide whether it should be executed or not.
Service in SETUP state?
Execute the serviceSetup
method and change state to STARTUP
Yes
No
Service in STARTUP state?
Execute the onstart method, set service
to started and change state to
ACTION
Yes
No
Service in ACTION state?
Execute the action method
Yes
No
Service execution
final?
Change service state to END
Yes
No
Service in END state?
Execute the end method and change
state to watingYes
No
Figure 22 Execution activities of the run method
5.1.2 Service core
The service core class is the template for developing services and offers the functionality needed
in the services in each endpoint. The implementation of the service core class and its class
diagram is presented in Figure 23.
54
Figure 23 Class diagram of the service core class and its related classes
The service core inherits the functionality of a subscriber to get access to the method onMessage
which is called each time a message is received to the subscriber. The messageListner interface
that the Subscriber is extending is a class from the JMS library which gives the class the
possibility of overriding the abstract class onMessage. By overriding this abstract class, it can
implement the functionality triggered each time a message is received. The service core
implements the interface of LISAServiceLifeCycle, this is an interface that offers the necessary
abstract methods that is executed by the endpoint during runtime of the services. The onStart
method is executed during the STARTUP state, the action method is executed during the
ACTION state and the end method is executed during the END state of the service. The
attributes of the subscriber class are:
55
-subscriber : MessageConsumer – the subscriber is the objects that have the ability of
receiving messages from the ESB and knows which channel or as in the ActiveMQ software
which topic to receive messages from.
-session : Session – the session is an object used for producing and consuming messages
from the message bus. It is part of the JMS library and is used for creating the subscriber.
-topic : Topic – the topic object withhold knowledge about which topic the subscriber
should subscribe to. It is part of the JMS library and is used for creating the subscriber.
The methods of the Subscriber class are two and these are:
+Subscriber() – this is the constructor for the subscriber and is called each time a new
instance is created.
+createSubscriber(String) : void – this method is used for creating a new subscriber with
the topic name as input for the method. The topic name is used for making the subscriber
subscribe to the correct topic.
The service core on the other hand has multiple attributes that each have a purpose for the
implementation of the software stack. The attributes and their purposes are as follows:
#publisher : Publisher – the publisher attribute is, as the subscriber, the object that have
access to the communication bus through the connection. The publisher has the ability of
sending messages to the bus on the topic that it is connected to. The publisher has a message
producer attribute which is the attribute that gives the ability to send messages. It also has a
method called sendMsg which is taking a LISAMessage object and publishing it on the bus.
When the sendMsg is called first the LISAMessage is translated to JSON text format, then the
JSON text is attached to a JMS message that is then sent to the bus.
#connection : Connection – this is the object that is encapsulating the open connection to
the ESB. This object is passed down from the endpoint when the service is created and is used
in the service to create the session needed to connect to the ESB.
#topicStrSub : String – the placeholder for the name of the topic that the subscriber receives
messages from.
56
#topicStrPub : String – the placeholder for the name of the topic that the publisher sends
messages to.
#ep : LISAEndPointCore – this is a reference to the endpoint that the service belongs to.
#serviceName : String – the placeholder for the name of the service.
#serviceDescription : String – the placeholder for the description of the service’s
functionality.
#dataMapping : ListMultimap<String, String> – this is a reference to the map from the
endpoint that is used for sending messages between services in the endpoint.
#executeFrequency : long – the execution frequency of the action method in the service.
#executionTimestamp : long – a timestamp that is holding information about the last
execution of the action method of the service.
#started : boolean – an attribute that changes to true by the endpoint when the service is
started and running.
#state : ServiceState – this is the attribute that have the information about the current state
of the service. It can present all the predefined constants of the ServiceState enumeration type,
these are SETUP, STARTUP, ACTION, WAITING and END.
The methods in the service core class creates the functionality of the services. A lot of them are
setters and getters that are setting values of attributes and returning values of an attributes, like
in the endpoint core. These methods will not be explained in any closer detail. The methods
that have a different functionality are:
+LISAServiceCore(LISAEndPointCore, Connection, String) – this is a constructor for
the service and is called by an endpoint when the service instance is created. The constructor
takes the parameters as the endpoint that is creating the service, the connection to the message
bus and a string with the topic name that the subscriber and the publisher should connect to.
The constructor is also setting the values for the attributes ep, connection, topicStrSub,
topicStrPub and it also sets the initial execution state to SETUP.
57
+LISAServiceCore(LISAEndPointCore, Connection, String, String) – this is a
constructor for the service core and is doing the same as the other constructor with the different
that this is starting a service with one topic for the publisher and one for the subscriber.
+serviceSetup() : void – this is the method that is called in the initial phase of the service
execution. This method calls the methods createSession, createPublisher, createSubscriber and
registerService. It is basically setting up the service to work as intended.
-registerService() : void – this method is sending a message to the bus with the name and
description of both the service and the endpoint. This to notify the service monitoring service
of the existence of this service and its endpoint.
-createSession() : void – this method uses the connection to create an instance of the session
and assign the instance to the session attribute of the service.
-createPublisher : void – this method creates a new instance of the publisher with the
session and the topic of the service. Then it assigns the publisher instance to the attribute
publisher.
5.1.3 Sub-services
The implementation of the predefined sub-services and the class diagram that explains the
relations between classes is shown in Figure 24.
58
Figure 24 Class diagram of the service core class and the related sub-classes.
The four different predefined services are the fold service, the fill service, the map service and
the device service. Since the predefined services inherits the attributes and functionality of the
service core, the classes related to the predefined services only implements the functionality
that is characteristic for them. Each of the predefined service and its attributes and methods will
be explained separately. The fold service purpose is to collect messages and its data to aggregate
data for calculation then send the newly calculated data as a message. The attributes of the class
LISAFoldService have the purpose and functionality as follows:
-maxSize : int – this attribute sets the size of the aggregated data, the number of messages
collected and considered when calculating the aggregated data.
-dataList : List<LISAMessage> – this is the data list that saves all the messages used for
the calculations.
59
The methods used for performing the fold operation in the LISAFoldService class and their
functionality are:
+LISAFoldService(LISAEndPointCore, Connection, String) – this is the same
constructor as inherited by the service core. It takes the endpoint, the connection and the topic
name as input when creating a new instance of the fold service.
+LISAFoldService(LISAEndPointCore, Connection, String, String) – this is the same
as the other constructor with the difference that this is creating a service with a different topic
for the subscriber and the publisher.
+action() : boolean – this is the method implemented from the service core and it’s
implemented only to avoid it being implemented in any sub-classes. The fold service should
not have any functionality defined by the action method which means that this method is only
returning false to make the service continue to execute.
+onMessage(Message) : void – this method is called each time a message is received, the
method translates the message to a LISAMessage and passes the LISAMessage to the abstract
method addMsgToList.
+fold() : void – this abstract method is to be override in a implementation and perform the
calculation of the aggregated data.
+addMsgToList(LISAMessage) : void – this abstract method is called each time a message
is received in the service. This method is to be override by a service and is used to decide
whether the message received is of the relevant type. If it is of relevant type the message should
be added to the data list and the fold method need to be called.
The other methods in the LISAFoldService is getter and setters, they have the same
functionality as the ones in the service core and the endpoint core classes. The next class is the
LISAFillService class which is used to add data to a message and then send it back to the
communication bus. This class have no attributes but the methods and their functionality is as
follows:
60
+LISAFillService(LISAEndPointCore, Connection, String) – this is the same constructor
as inherited by the service core. It takes the endpoint, the connection and the topic name as
input when creating a new instance of the fill service.
+LISAFillService(LISAEndPointCore, Connection, String, String) – this is the same as
the other constructor with the difference that this is creating a service with a different topic for
the subscriber and the publisher.
+action() : boolean – this is an implementation of the abstract method from the service core.
This method is only returning false to make the service continue executing.
+onMessage(Message) : void – this method is an implementation of the abstract method
onMessage from the service core. This is triggered each time a message is received by the
service, it translates the message from JSON to a LISAMessage object and triggering the
abstract method fill by passing the LISAMessage object to it.
+fill(LISAMessage) : void – the method is triggered each time a message is received by the
service and is to be implemented by a service that inherits the functionality of the
LISAFillService class. This should have the function of adding the relevant data to the message
and then sending the message back to the bus.
The next implementation of the predefined services is the map service, the map service is
behaving in an identical way as the fill service but have different purposes. The map service is
only used to add dynamic data as defined by the architecture. This service neither has any
attributes but the methods and their functionality is as follows:
+LISAMapService(LISAEndPointCore, Connection, String) – this is the same
constructor as inherited by the service core. It takes the endpoint, the connection and the topic
name as input when creating a new instance of the map service.
+LISAMapService(LISAEndPointCore, Connection, String, String) – this is the same
as the other constructor with the difference that this is creating a service with a different topic
for the subscriber and the publisher.
61
+action() : boolean – this is an implementation of the abstract method from the service core.
This method is only returning false to make the service continue to be executed by the endpoint.
+onMessage(Message) : void – this method is an implementation of the abstract method
onMessage from the service core. This is triggered each time a message is received by the
service, it translates the message from JSON to a LISAMessage object and triggering the
abstract method map by passing the LISAMessage object to it.
+map(LISAMessage) : void – the method is triggered each time a message is received by
the service and is to be implemented by a service that inherits the functionality of the
LISAMapService class. This should have the function of adding the relevant data to the
message and then sending it to the bus.
The last sub service to the service core is the LISADeviceService with the purpose of reading
data from hardware devices and send the data to the communication bus in messages. This
service template is enabling the dynamic loading of libraries by the use of a service tracker from
the OSGi library. The attributes of the class have the following purposes:
+ hardwareCommunication : HardwareCommunication – this is the placeholder for the
service from the OSGi environment that have functionality of communicating with the
hardware device connected to the service. The service from the OSGi environment implements
the interface named HardwareCommunication with the methods connect, addIteamToRead,
checkValue, readValue and setInt. The connect method creates the connection to the device,
the addIteamToRead adds a signal to be read, checkValue is a method used to check if the value
has changed on the device, the readValue is returning the value and setInt is setting an integer
to the device connect.
+serviceTracker : ServiceTracker – this is the placeholder for the service tracker object.
The service tracker is an object that have the functionality of searching the OSGi framework
for the service with the right criteria’s. The service that the service tracker receives in this
context is the service with the functionality of connecting to the hardware device relevant for
the device service.
62
The methods implemented in the predefined device service is as in the others some getters and
setters with the same functionality as in the other classes. But the relevant methods in this class
are:
+LISADeviceService(LISAEndPointCore, Connection, String, ServiceTracker) – this
constructor for the class is as inherited by the service core taking the endpoint it is created in,
the connection to the communication bus and the name of the topic that the publisher and the
subscriber connects to. The different from the service core is that this constructor takes a
ServiceTracker and assigns it to the service tracker attribute.
+LISADeviceService(LISAEndPointCore, Connection, String, String, ServiceTracker)
– this constructor is doing the same as the above with the different that this is creating a service
with different topics for the subscriber and the publisher.
+getCommunicationService() : void – this abstract method is to be implemented by a
device service and have the purpose of assigning the right service, with help from the service
tracker, to the hardware communication attribute.
5.1.4 Message
The message is used for transporting data through the bus. The LISAMessage class is the tweet
or message implemented from the architecture and withholds the header and the body of the
message. The LISAMessage class and the related classes is visible in Figure 25.
63
Figure 25 Class diagram for the LISAMessage class and the related classes
Starting with an explanation of the LISAMessage class, the attributes and the methods. The two
attributes of the class are as follows:
-messageheader : LISAMessageHeader – this is the placeholder of the header instance
related to the message.
-messageBody : LISAMessageBody – is the placeholder for the body instance of the
message.
And then the methods of the LISAMessage class, as the other classes also this class have setters
and getters that are setting the value for attributes and returning the value of attributes. The
other methods are and have the functionality as follows:
+LISAMessage() – this is the constructor for the LISAMessage class. The constructor is
assigning values to the message header since they have a set of static values with the same
64
format for all messages. The attributes that are assigned are the senderID which is the IP-address
of the machine the service runs on, the timestamp which is the current time of creation for the
message and also the message ID which is a unique ID for each message and is constructed by
combining the IP-address and the timestamp.
+toString() : String – this method is returning a string with the information inside the
message, both the body and the header. The string is formatted in a way that helps humans to
read the information.
Each message has a message header with information about the message. The class
LISAMessageHeader have the function of message header in this implementation. The
attributes of the LISAMessageHeader class is as follows:
-ID : String – this is a placeholder for the id of the message, this is a unique id for each
message.
-timestamp : long – the placeholder for the timestamp that the message was created.
-history : String – this is a placeholder for the history information of the message, for
instance if the message has been through any transformation services.
-senderID : String – the ID of the sender machine, in this implementation it is the IP-address
of the machine that the message is created on.
-handshakeConfirmation : boolean – this is an attribute that inform the receiver of the
message if the sender require a confirmation.
The methods of the LISAMessageHeader is mainly getters and setter. But the two methods that
differs are and have the functionality as follows:
#LISAMessageHeader() – this is the constructor of the message and it is protected to
prevent instances of the message header to be created from outside the message package and
the LISAMessage class.
+toString() : String – this method returns a string with the content of the header in a format
easy read by humans.
65
The next class to be described is the LISAMessageBody class and is the class that have the
functionality of the message body for the message. The attributes of the message body are as
follows:
-type : String – this attribute is a string describing the type of content the body holds.
-keyPairValues : LinkedList<KeyPairValue> – this attribute withholds a list of the key
pairs containing the data attached to the message. The list contains objects of the class
KeyPairValue, the KeyPairValue class have two attribute and they are:
-type : String – the type of data in the keypair.
-data: String – the data formatted as a string.
The methods, apart from the getters and setters, of the KeyPairValue class and their
functionality are as follow:
+KeyPairValue() – one constructor of the key pair without functionality
+KeyPairValue(String, String) – a constructor for the KeyPairValue that set the value for
the attributes type and data from the input.
+toString : String – returns a string with the type and the data of the key pair in a readable
format for humans.
5.2 Enabling technologies
The technologies used to implement the architecture have the requirement of being compatible
with Java. The technologies used in the implementation is enabling the communication trough
messages, a runtime environment for enabling dynamically deployment of endpoints and
services, databases to assure a historical access of data and last a commutation protocol used
for accessing low-level data from the devices on the ESB.
5.2.1 ActiveMQ
ActiveMQ is a message bus that was used to implement the communication between entities in
the architecture, it has the role of an ESB for the implementation. ActiveMQ is an open source
66
message broker that is written in Java and is compatible with other Java software’s. ActiveMQ
is a message-oriented middleware and is offering the functionality to mediate events and
messages in distributed applications with the guarantee of successful deliveries.
Implementation of ActiveMQ is offering an asynchronous communication and a loosely
coupled deployment, with the possibility of routing and filtering messages. ActiveMQ is a
networking message bus that have a locator address and can be connect to through internet [42].
5.2.2 JSON
JavaScript Object Notation (JSON) is a compact text format that is used for exchange of data
in a structured way between application. JSON uses a syntax of braces, brackets, colons and
commas that is used to translate objects of different programming languages to a format that
can be easily interpreted by both humans and computers. Some of the objects that can be
translated and transported between programming languages and applications are strings,
integers, arrays, lists and class objects [43]. In the implementation of this work JSON was used
for translating the tweets to text and then back to tweets when communicated through the ESB.
5.2.3 OSGi
Open Services Gateway initiative (OSGi) is a modular runtime environment that was
implemented to enable a loosely coupled runtime environment and self-contained services. This
to allow the seamless deployment of both endpoints and services in the architecture. The
modular construction of the software stack was realized using OSGi framework during runtime
of the software. OSGi is a standard that allows a modular runtime environment for applications,
its modularity is realized by interfaces making the collaboration between modules possible. A
module in an OSGi framework is like a service in a SOA. The OSGi framework is also
supporting the dynamic deployment of endpoints and services [44].
5.2.4 Cassandra
Cassandra is a database that is scalable and with a focus on making it safe towards failures. It
is used for critical data by replicating the data among different nodes to assure a minimum risk
for data loss. When Cassandra is deployed on several machines and collaborating in a network,
each machine is a node [45]. During this work the Cassandra database was used as a persistent
database, that is saving all the events on the ESB and making historical data accessible.
67
5.2.5 ElasticSearch
ElasticSearch is an open-source search engine with advanced and high speed search
functionality. It is a full-text search engine that is compatible with JSON format, when having
a JSON text the data can be directly read into the ElasticSearch database [46]. ElasticSearch is
used as an indexing database in the implementation of this work and is providing fast search
and filtering among the data stored in it.
5.2.6 OPC
Open Platform Communication (OPC) is a standardized communication protocol that is using
the Microsoft standard COM/DCOM to enable communication between a client and a server.
Typically, PLCs offers OPC-servers which enables the communication between computers and
PLCs. The OPC protocol can be used to read and write data from and to PLCs [47]. This enables
the device communication in the architecture and was used just for that purpose during the
implementation of this work.
5.3 Simulation environment
During this work a virtual simulation environment for a shop-floor was used, since access to a
real shop-floor with the right characteristics was not possible. The software used for the
simulation is a free software called CODESYS. It is a software used for development and
engineering of controller application in the automation industry, CODESYS is hardware-
independent and have the ability of simulating a virtual PLC with a OPC server attached to it.
5.3.1 The production line
The implementation of the architecture was adopted to access the simulation environment in
CODESYS v. 3.5.3 through a OPC server. The simulation environment was a production line
where batches of pucks where to be processed and finished by going through different processes
and transported by conveyers between the processes. The manufacturing of the pucks starts
with a robot arm picking a puck from the storage and placing it on the conveyer. The conveyers
transport the pucks to the rotating table where the processing of the puck is done and then all
the pucks are transported back to the storage by the two other conveyers. When the pucks arrive
to the storage again the robot picks the pucks once again and sort all the pucks according to a
68
pattern dependent on their colors. The pucks in the simulation can be either red, black or blue.
A visualization of the shop-floor with the processes and resources is available in Figure 26.
Figure 26 The shop-floor used for the simulation
In Figure 26 a visualization of the shop-floor used in the simulation is presented. The production
line for the pucks contains of a robot-arm that transfers pucks from the storage to the conveyers
and back, four conveyers transporting the pucks between stations (B1, B2, B3, B4), four
cylinders that can stop the pucks on the conveyers (C1, C2, C4, C5), three arms that can push
pucks form or to the conveyers (M1, M2, M3), one testing station with a cylinder (C3) going
down to sense (IG) if the puck has a hole in it or not, one drilling station that drills (BR) a hole
in each puck without holes the station also have a clamping device (Fix_WP), ten photo sensors
is used to sense if pucks are passing by (FC1, FC2, …, FC10), one rotating table transferring
pucks between the testing and drilling stations and three capacitive sensors (KG1, KG2, KG3)
sensing the presence of a puck in each position of the rotating table.
The production starts with a puck transferred from the storage by the robot-arm to the first
conveyer (B1) from that passing the sensors FC1 and FC2 to the second conveyer (B2). From
B2 the puck is transferred by M1 to the rotating table, first it is tested and later it is drilled and
last it is transferred from the table to B3 by M2. From B3 the pucks go to B4 and then back into
69
the storage if the robot-arm is done emptying it. The pucks are sorted into a pattern when
arriving to the storage again.
In the simulation, there is two places where queues can be formed if enough pucks are present
at the same time. The two places are before cylinder 1 and before cylinder 4.
The manufacturing of pucks is done in batches and each batch contains 12 pucks each. When
all 12 pucks of one batch has finished one lap and are back on in the storage, everything starts
over with a new batch. In one simulation three batches are processed and stored in the storage.
5.3.2 Modules and signals
To implement the architecture onto the simulation production line, the production line was
divided into different modules and an endpoint was developed to read the low-level signals of
each module. The modules that the production line was divided into is visualized in Figure 27.
Figure 27 The shop-floor used for the simulation and the modules that is was divided into
Each module withholds a set of outputs that connects to a virtual PLC and later read with the
use of OPC. The modules are divided into conveyers, storage with the robot-arm, rotating table,
the test station and drill station. All the signals within each module belong to the same logical
domain which means that each module have a device endpoint connected to it.
70
5.4 Test cases
The test cases developed have the purpose of assessing the software regarding the objectives
set in the beginning of the work. Some of the objectives are directly connected to the
performance of the developed software stack and some is related to the implementation of the
software stack. The objectives related to the implementation of the software stack is mainly
concerning the how of the implementation process, such as event-driven and service-oriented
structure, ability to seamlessly deploy endpoints and micro-services, loosely couples and self-
contained services with predefined behaviors and, flexibility and scalability. But what can be
validated and tested through testing scenarios is the objectives stating that the software stack
needs to enable data collection from shop-floor control devices independent of vendor, enable
calculation of key performance indicators (KPIs) for new and historical data and enable stream
based aggregation of data.
The test cases need to show proof of concept, showing that the software stack has the ability of
collecting data from devices on a shop-floor, calculate KPIs from low-level data accessible in
the devices and doing this in a stream based way. Stream based aggregation means that the
collection and calculation of higher level information is done continuously through the
processing. The tests and setups that will assess the architecture and software stack are:
Calculation of KPIs:
o Throughput time per batch – difference between timestamp of first puck entry
and last puck exit in each batch
o Cycle time for each puck – difference between unloading puck timestamp and
loading puck timestamp
o Mean cycle time for a puck in a batch
o Mean time in queue for the two queues
o Ideal-time for each queue
Collection of all sensor data to enable a real-time tracking of the pucks. The real-time
tracking would enable the simulation of a model with the real-time feedback.
71
The KPIs chosen to be calculated needs at least one or more transformation from the
transformation services and would be relevant in a real production environment. The testing
scenario developed to assess the software stack is briefly shown in Figure 28.
Conveyer3Device
Endpoint
SimulationEnvironment
Conveyer2Device
Endpoint
Conveyer4Device
Endpoint
StorageDevice
Endpoint
Conveyer1Device
Endpoint
Transformation Fill
Endpoint
TableDevice
Endpoint
TestDevice
Endpoint
DrillDevice
Endpoint
TransformationFold
Endpoint
Transformation Cycle Times
Endpoint
PuckTrackingEndpoint
QueueTrackingEndpoint
Idle queue time
Mean queue length
Matrix with timestamps for each puck at each sensor
Cycle times for each puck
Mean cycle time per puck per batchThroughput time per batch
Figure 28 The testing setup with all the endpoints and the communication paths between the endpoints. A
simplified view that not shows the services encapsulated within each endpoint.
The testing setup consist of endpoints with services that worked together to transform low-level
data into the information requested. The device endpoints read the signals from each module
and sent it to the bus. The device endpoint communicates in an asynchronous way with the
device modules from the virtual shop-floor which means that a message was sent every time a
signal changed. The transformation endpoints offer different information. The transformation
fill endpoint added the puck number of the puck that triggered the sensor signal. The
transformation cycle times endpoint calculated the cycle time of each puck which was achieved
by taking the difference for the timestamps of the robot grabbing the puck in the first place and
72
putting it back into the storage. The transformation fold endpoint was using the data from the
transformation fill endpoint to calculate the throughput time for each batch in the simulation
run and the mean cycle time for one puck in a batch. The puck tracking endpoint gathered all
the signals from the modules with the purpose of creating a matrix with all the timestamps of
each puck passing each sensor. The purpose of such matrix is to enable a real-time tracking of
the production in a simulation tools. The queue tracking endpoint kept track of the two queues
that were created during the execution of the simulation. The information that the queue
tracking endpoint calculates were the idle time for each queue meaning the percentage of time
that no puck was present in the queue and the mean queue length of the queues during the time
a puck was present in the queue.
The simulation of the production line in CODESYS was consistent in the execution which
means that the results of each execution can be compared to validate the stability of the software
stack. The test runs were done 10 times to get a cluster of data that could be compared and
evaluated. Some of the important factors in the simulation were the updating frequency of the
virtual PLC and the updating frequency of the asynchronous reading executed through OPC.
The updating frequency of the PLC was set to 100 ms second and the updating frequency of the
OPC communication was set to 50 ms.
73
6 RESULT AND DISCUSSION
This chapter presents and discusses the overall software stack and the results from the defined
test cases. First the assessment of the software stack is discussed and then the results from the
testing is presented. In the section presenting the results from the testing first the calculated
cycle times are presented, then the throughput times for each batch, later the information about
the queues is presented and last all the low-level data and the variation of all the signals is
presented.
The results of this work consist of the proposed software stack itself and the information
calculated from the low-level data collected in the virtual simulation environment implementing
the software stack.
6.1 Overall assessment of the software stack
The software stack presented in the previous chapter were developed as a result of this work
and as a contribution to the LISA2 research project. The software stack is implementing the
architecture presented in chapter 4 and the architecture is compatible with LISA like systems.
The software stack presented is implementing the functionality from the distributed
architectures presented in the literature review, mainly the SOA and EDA architectures.
Collection of data in a stream based manner is possible and the software can be used for
monitoring and calculations of information relevant to optimizing a production line. The
execution of the software was found to be sensitive towards disruption and data loss when
reading signals, this was mainly because of how the calculation of the KPIs during testing was
done. The loss of signals was corrected by lowing the execution frequency with the result of
higher variance in the data collected as can be noticed in the next section of the result.
6.2 Results from testing
The tests were executed 10 times to get a set of data that could be evaluated through statistical
methods and to get a population of data that could give an indication on the assessment of the
developed software. Each test run produced three batches of pucks with 12 pucks in each batch.
Each of the KPIs calculated with the software stack connected to the testing environment is
74
presented with a graph that shows the mean value, upper limit and lower limit of the values
from the 10 tests runs and a table with the statistical classification of the data.
6.2.1 Cycle times
The cycle time for each puck was calculated and is presented in the graph in Figure 29. The
results of the calculated cycle times were evaluated by calculating the variance for each of the
cycle times when running the tests ten times. For the cycle times of each puck the values and
variation is presented in Table 1, Table 2, Table 3 and Table 4.
Figure 29 Graph the presents the mean cycle times and the variations from the ten test runs.
The standard deviation of the cycle times varies a bit but most of them are around 400 ms. The
variation of 400-500 ms were considered as a low-variation due to limitation of this work.
Considering the sample mean that is about size of 100 000 ms to 200 000 ms the deviation is
considered negligible. That all the software was run on the same machine which slowed down
the computation and the updating frequency of the PLC that was set to 100 ms which can
explain the variation up to a half second. As seen in the graph in Figure 29 the cycle times for
the same puck in different batches is also consistence. The cycle time of the first batch should
vary a bit since the first batch is unsorted in storage and the two other are already sorted.
120000
140000
160000
180000
200000
220000
240000
260000
P1
P2
P3
P4
P5
P6
P7
P8
P9
P1
0
P1
1
P1
2
P1
3
P1
4
P1
5
P1
6
P1
7
P1
8
P1
9
P2
0
P2
1
P2
2
P2
3
P2
4
P2
5
P2
6
P2
7
P2
8
P2
9
P3
0
P3
1
P3
2
P3
3
P3
4
P3
5
P3
6
Batch 1 Batch 2 Batch 3
Tim
e (m
s)
Cycle times
Upper limit Sample mean Lower limit
75
Table 1 Statically analyze of the cycle times from ten test runs (1 of 4)
P1 P2 P3 P4 P5 P6 P7 P8 P9
Sample mean [ms] 126234 136628 147034 157134 164334 174836 185238 195738 202938
S. Std. Dev [ms] 419 517 13 312 476 420 424 486 321
No. Tests 10 - - - - - - - -
Confidence 0,95 - - - - - - - -
Significance 0,05 - - - - - - - -
Critical t 2,262 - - - - - - - -
Upper limit [ms] 126534 136998 147043 157357 164675 175136 185541 196085 203168
Lower limit [ms] 125934 136259 147025 156910 163994 174535 184935 195390 202708
Table 2 Statically analyze of the cycle times from ten test runs (2 of 4)
P10 P11 P12 P13 P14 P15 P16 P17 P18
Sample mean [ms] 213339 223640 234142 126029 136133 146733 157034 164596 174830
S. Std. Dev [ms] 481 516 328 14 312 486 12 487 432
No. Tests 10 - - - - - - - -
Confidence 0,95 - - - - - - - -
Significance 0,05 - - - - - - - -
Critical t 2,262 - - - - - - - -
Upper limit [ms] 213683 224009 234377 126039 136356 147081 157042 164945 175139
Lower limit [ms] 212994 223271 233907 126019 135910 146385 157025 164247 174522
Table 3 Statically analyze of the cycle times from ten test runs (3 of 4)
P19 P20 P21 P22 P23 P24 P25 P26 P27
Sample mean [ms] 185105 195704 202803 213206 223408 233907 126050 136453 146557
S. Std. Dev [ms] 346 472 419 367 469 316 129 483 482
No. Tests 10 - - - - - - - -
Confidence 0,95 - - - - - - - -
Significance 0,05 - - - - - - - -
Critical t 2,262 - - - - - - - -
Upper limit [ms] 185353 196041 203102 213468 223744 234133 126143 136799 146902
Lower limit [ms] 184858 195367 202503 212943 223072 233681 125958 136108 146212
76
Table 4 Statically analyze of the cycle times from ten test runs (4 of 4)
P28 P29 P30 P31 P32 P33 P34 P35 P36
Sample mean [ms] 157212 164412 174711 185116 195617 202932 213335 223636 233937
S. Std. Dev [ms] 356 476 420 374 454 516 414 461 224
No. Tests 10 - - - - - - - -
Confidence 0,95 - - - - - - - -
Significance 0,05 - - - - - - - -
Critical t 2,262 - - - - - - - -
Upper limit [ms] 157467 164752 175012 185383 195942 203301 213631 223966 234098
Lower limit [ms] 156957 164071 174411 184849 195292 202563 213038 223306 233777
6.2.2 Throughput times
The throughput time for each batch were calculated and the mean throughput from all the test
runs is presented in the graph in Figure 30. The upper and lower limit of the population is also
presented. The variation of the values is as for the results of the cycle times around 400-500 ms
which is understandable because both the cycle and throughput time is calculated with the same
signals. Variation for each batch and the statistical evaluation of the results are shown in Table
5.
Figure 30 Graph of the throughput time for each batch. The values are the mean value and the variation of the
testing data.
269600
269800
270000
270200
270400
270600
270800
271000
271200
Batch 1 Batch 2 Batch 3
Tim
e (m
s)
Throughput time
Upper limit
Sample mean
Lower limit
77
Table 5 Statically analyze of the through put time for batches
Batch 1 Batch 2 Batch 3
Sample mean [ms] 270663 270522,7 270739
S. Std. Dev [ms] 521 502 416
No. Tests 10 - -
Confidence 0,95 - -
Significance 0,05 - -
Critical t 2,262 - -
Upper limit [ms] 271036 270882 271037
Lower limit [ms] 270290 270164 270441
6.2.3 Idle time for queues
The idle time for each of the two queues that appears when execution the simulations were
calculated. The idle time in this work were considered as the fraction of the time no puck was
presented at the queues divided with the total time between the first puck of the first batch
entering the queues and the first puck of the second batch entering the queues. The mean value
and the variation of the calculated populations is presented in Figure 31. In Table 6 the
calculated standard deviation is presented and was considered low since it is between 0,1-0,2%
and this is not a significant variation.
Figure 31 Graph that presents the mean ideal time from the ten test runs for each batch and the variation.
36,00%
38,00%
40,00%
42,00%
44,00%
46,00%
48,00%
Batch1 Batch2 Batch1 Batch2
Queue 1 Queue 2
Idle time for the queues
Upper limit
Sample mean
Lower limit
78
Table 6 Statically analyze of the idle time for queues
Queue 1 Queue 2
Batch 1 Batch 2 Batch 1 Batch 2
Sample mean 45,9% 45,8% 39,8% 39,8%
S. Std. Dev 0,1% 0,1% 0,2% 0,1%
No. Tests 10 - - -
Confidence 0,95 - - -
Significance 0,05 - - -
Critical t 2,262 - - -
Upper limit 46,0% 45,8% 39,9% 39,9%
Lower limit 45,8% 45,7% 39,7% 39,7%
6.2.4 Length of queues
The average length of the queues during the time that at least one puck is present in the queue
is presented in the graph in Figure 32. From the graph, it can be observed that the pressure on
the queue 1 is higher than for queue 2 which also were the case during the simulation.
Figure 32 Graph that presents the mean queue length during the time that the queue has at least one puck in it.
The values are the mean and variation from the ten test runs.
In Table 7 the deviation for the mean length of the queues are presented. As noticed the mean
length had a small variance which can be expected since the calculations utilize a lot of data to
get value with low resolution.
0,00
1,00
2,00
3,00
4,00
5,00
6,00
Batch 1 Batch 2 Batch 3 Batch 1 Batch 2 Batch 3
Queue 1 Queue 2
Len
gth
(p
cs)
Mean length of queue during utilization
Upper limit
Sample mean
Lower limit
79
Table 7 Statically analyze of the mean length of queues
Queue 1 Queue 2
Batch 1 Batch 2 Batch 3 Batch 1 Batch 2 Batch 3
Sample mean [pcs] 5,44 5,43 5,43 2,19 2,19 2,20
S. Std. Dev [pcs] 0,01 0,02 0,01 0,01 0,01 0,01
No. Tests 10 - - - - -
Confidence 0,95 - - - - -
Significance 0,05 - - - - -
Critical t 2,262 - - - - -
Upper limit [pcs] 5,44 5,45 5,44 2,20 2,20 2,20
Lower limit [pcs] 5,43 5,42 5,43 2,19 2,18 2,19
6.2.5 All the sensor signals
The last results that is presented is the timestamps from all the sensor signals that the testing
software recorded to offer a real-time tracking of the pucks on the conveyer belts and throughout
the product path. The results of the timestamps are presented in Figure 33 and notice that the
data have been translated from timestamps to time by subtracting the first timestamp from all
values. By doing this the first puck do not have a noticeable value for sensor NPunload in the
figure since that was used to normalize the data. The NPunload signal was when the robot-arm
gripped the puck to be placed on the conveyer belt and the NPload signal was when the robot-
arm gripped the puck to placed back into the storage.
80
Figure 33 Graph presenting the timestamps of each sensor and each puck. The values are normalized by the first
timestamp which is an indication to when the simulation began.
Figure 34 presents the variation of each sensor value for each puck calculated from all the ten
test runs and in Figure 35 a histogram presents the standard deviation for all the sensor data.
For most of the values the variation is about 500 ms seconds which is expected considering the
variation of the throughput times and the cycle times also is around 500 ms. The calculations
of these times were done with the same sensor timestamps and should have similar variations.
Most the sensor values are below 520 ms. There is one value with the variation of zero, this is
the initial sensor data used for normalized the value to enable comparison between test runs and
should not be considered since the variation of zero is zero.
81
Figure 34 Variance of the sensor data calculated on the ten test runs for each sensor and each puck
Figure 35 Histogram of the variation for the sensor data
Considering that the variation of the signals is about 500 ms and the updating frequency were
set to 100 ms for the virtual PLC it could be argued that the variation should be about 100 ms.
But since the computation only was done on one computer and the intention is to only have one
endpoint per device, the results are acceptable and the deviations where considered as negligible
in such implementation.
82
7 CONCLUSION AND FUTURE WORK
This last chapter provides the conclusion of this work and work needed in the future for taking
the software stack from a prototype to a software stack that can facilitate the needs of a real
production environment.
7.1 Conclusion
During this work an event-driven software architecture with purpose of collecting data in smart
factories and an implementation of the architecture has been presented. The presented work
fulfills the objectives set in the beginning of this work and the software stack did perform as
intended. The test cases and the result of the tests could be used for validating that the software
stack did execute the tasks it was intended to do. To optimize the performance of the software
stack it needs to be further tested in a real environment and in a networking situation as
intended. This could enhance the performance by distributing the computational power on
multiple devices.
Considering the objectives of this work the architecture developed and the implementation of
the architecture can be used for collection of data from a modular shop-floor and transform data
into useful information, this is proved by the results achieved in the testing scenario. The
architecture has the characteristics of both a SOA and EDA, the ability to seamlessly deploy
both endpoints and services. The services are loosely coupled and self-contained with
predefined sub-services that enables fast development of new applications. The collection of
data is possible from vendor independent devices due to the usage of interfaces for the device
communication and the OSGi services that can offer a different communication protocol
dependent on the vendor of the device. The calculations of KPIs were possible and they are
presented in the result chapter. The KPIs were calculated both for new and for historical data.
The historical data used was the aggregated data for calculations of the mean values. In the
testing scenario, no databases were tested although they have been implemented. And the last
of the objectives for the ultimate software stack were to enable stream based aggregation of
data which has been shown is possible by the presented results in the result chapter.
83
Considering the experimental nature of this work, further development is required to implement
the proposed solution in a real production environment. This work presents the potential and
possibilities with this type of software in manufacturing industries. The utilization of data
collected in the production environment can certainly be used for optimizing the manufacturing
processes and solving problems related to the current market. The connection of such
architectures to higher level systems such as scheduling and logistics systems would enable an
improvement of the entire supply chain performance.
Overall the software stack presented in this work performed as expected and allows a seamless
deployment of a software implementing an architecture inspired by LISA. With use of the
software stack, development of new functionalities can be done in an effortless manner since
only the code related to the functionality need to be developed. The problems and issues related
to the compatibility is taken care of by the purposed solution.
7.2 Future work
Implementing this software stack in a real production environment would require the software
to be further developed. During the testing of the software stack, everything apart from the
database services was implemented. Not all the functionality was tested and validated. Some
parts need further testing and validating such as the monitoring services and the database
services.
If an implementation in a real production environment is to be done, the overall performance
of the software stack need to be evaluated and optimized for running over long time. Execution
over long time would probably highlight problems unable to be discovered when executing
during a limited time frame such as during this work. For this purpose, testing over long time
and in a networking manner need to be performed.
Bringing this software from a prototype stage to a software able to be utilized in a real
production environment would require further testing on a real shop-floor. In a real-life
implementation, the effect of lost signals and unexpected interruption need to be dealt with.
84
8 REFERENCES
[1] A. N. Nambiar, "Modern Manufacturing Paradigms - A Comparison," in International
MultiConference of ENgineers and Computer Scientists 2010 Vol III, IMECS 2010, Hong
Kong, 2010.
[2] A. Theorin, K. Bengtsson, J. Provost, M. Lieder, C. Johansson, T. Lundholm and B.
Lennartson, "An Event-Driven Manufacturing Information System Architecture," in
IFAC/IEEE Symposium on Information Control Problems in Manufacturing, INCOM,
2015.
[3] "Transform to an on demand business thru IBM Business Integration Solution," in IBM
Business Continuity Solutions Seminar, 2007.
[4] A. McAfee and E. Brynjolfsson, "Big Data: The Management Revolution," Harvard
Buiness Review, pp. 59-68, October 2012.
[5] H. Kagermann, J. Helbig, A. Hellinger and W. Wahlster, "Recommendations for
Implementing the Strategic Initiative INDUSTRIE 4.0: Securing the Future of German
Manufacturing Industry; Final Report of the Industrie 4.0 Working Group,"
Forschungsunion, 2013.
[6] J. Lee, B. Bagheri and H.-A. Kao, "A Cyber-Physical Systems architecture for Industry
4.0-based manufacturing systems," Manufacturing Letters 3, pp. 18-23, 2015.
[7] "Strategic Vision and Business Drivers for 21st Century Cyber-Physical Systems:
Strengthening opportunities for U.S. leadership and competitiveness," National Institute
of Standards and Technology, 2013.
85
[8] E. A. Lee, "Cyber-Physical Systems: Design Challanges," EECS Department, University
of California, Berkeley, 2008.
[9] P. J. Mosterman and J. Zander, "Cyber-physical systems challenges: a needs analysis for
collaborating embedded software systems," Software & Systems Modeling, vol. 15, no. 1,
pp. 5-16, 2016.
[10] E. Hozdić, "SMART FACTORY FOR INDUSTRY 4.0: A REVIEW," International
Journal of Modern Manufacturing Technologies, vol. VII, no. 1, pp. 28-35, 2015.
[11] A. Radziwon, A. Bilberg, M. Bogers and E. S. Madsen, "The Smart Factory: Exploring
Adaptive and Flexible Manufacturing Solutions," Procedia Engineering, vol. 69, no. 24,
pp. 1184-1190, 2014.
[12] S. Sagiroglu and D. Sinanc, "Big data: A review," in International Conference on
Collaboration Technologies and Systems (CTS), 2013.
[13] J. Lee, E. Lapira, B. Bagheri and H.-a. Kao, "Recent advances and trends in predictive
manufacturing systems in big data environment," Manufacturing Letters, vol. 1, no. 1, pp.
38-41, 2013.
[14] "Emerging trends in global manufacturing industries," United Nations Industrial
Development Organization (UNIDO), Vienna, 2013.
[15] J. Dias-Ferreira, "Bio-Inspired Self-Organising Architecture for Manufacturing Cyber-
Physical Systems," KTH School of Engineering and Management, Stockholm, 2016.
[16] D. McFarlane, "Product Intelligence: Theory and Practice," in 14th IFAC Symposium on
Information Control Problems in Manufacturing, Bucharest, Romania, 2012.
86
[17] L. Ferariu and D. Panescu, "Pattern Recognition for Holonic Manufacturing Systems," in
Proceedings of the European Control Conference, Budapest, 2009.
[18] M. Höpf and C. F. Schaeffer, "Holonic Manufacturing Systems," in Information
infrastructure systems for manufactuing, Stuttgart, 1997, pp. 431-438.
[19] H. Van Brussel, J. Wyns, P. Valckenaers, L. Bongaerts and P. Peeters, "Reference
architecture for holonic manufacturing systems: PROSA," Computers in Industry, vol.
37, no. 3, pp. 255-274, 1998.
[20] G. Dunning, "Artist residency research and documentation blog," Wordpress, 2
September 2015. [Online]. Available:
https://rhythmanddrone.wordpress.com/2015/09/02/arthur-koestler-on-holons/.
[Accessed 13 03 2017].
[21] P. Valckenaers, F. Bonneville, H. Van Brussel, L. Bongaerts and J. Wyns, "Results of the
holonic control system benchmark at KU Leuven," in Fourth International Conference
on Computer Integrated Manufacturing and Automation Technology, 1994.
[22] Y. Koren and M. Shpitalni, "Design of reconfigurable manufacturing systems," Journal
of Manufacturing Systems, vol. 29, no. 4, pp. 130-141, 2010.
[23] M. Mehrabi, A. Ulsoy and Y. Koren, "Reconfigurable manufacturing systems: Key to
future manufacturing," Journal of Intelligent Manufacturing, no. 11, pp. 403-419, 2000.
[24] Y. Koren and G. Ulsoy, "Vision, Principles and Impact of Reconfigurable Manufacturing
Systems," Powertrain International, vol. 5, no. 3, pp. 14-21, 2002.
[25] L. Riberio, J. Barata, G. Cândido and M. Onori, "Evolvable Production Systems: An
Integrated View on Recent Developments," in Proceedings of the 6th CIRP-Sponsored
87
International Conference on Digital Enterprise Technology, Springer Berlin Heidelberg,
2010.
[26] M. Onori and J. Barata, "EVOLVABLE PRODUCTION SYSTEMS : MECHATRONIC
PRODUCTION EQUIPMENT WITH PROCESS-BASED DISTRIBUTED," IFAC
Proceedings Volumes, vol. 42, no. 16, pp. 80-85, 2009.
[27] G. Adamson, L. Wang, M. Holm and P. Moore, "Cloud manufacturing – a critical review
of recent development and future trends," International Journal of Computer Integrated
Manufacturing, 2015.
[28] F. Tao, L. Zhang and Y. Cheng, "Cloud manufacturing: A computing and service-oriented
manufacturing model," Proceedings of the Institution of Mechanical Engineers Part B
Journal of Engineering Manufacture, pp. 1969-1976, 2011.
[29] L. Ren, L. Zhang, L. Wang, F. Tao and X. Chai, "Cloud manufacturing: key
characteristics and applications," International Journal of Computer Integrated
Manufacturing, pp. 1-15, 2014.
[30] P. Leitão, "Agent-based distributed manufacturing control: A state-of-the-art survey,"
Journal of Engineering Applications of Artificial Intelligence, vol. 22, no. 7, pp. 979-991,
2009.
[31] L. Monostori, J. Váncza and S. Kumara, "Agent-Based Systems for Manufacturing,"
CIRP Annals - Manufacturing Technology, vol. 55, no. 2, pp. 697-720, 2006.
[32] S. Franklin and A. Graesser, "Is It an agent, or just a program?: A taxonomy for
autonomous agents," Intelligent Agents III Agent Theories, Architectures, and Languages,
vol. 1193, pp. 21-35, 1997.
88
[33] L. M. Camarinha-Matos and W. Vieira, "Intelligent mobile agents in elderly care,"
Robotics and Autonomous Systems, vol. 27, no. 1-2, pp. 59-75, 1999.
[34] R. Welke, R. Hirschheim and A. Schwarz, "Service-Oriented Architecture Maturity,"
Computer, vol. 44, no. 2, pp. 61-67, Feb. 2011.
[35] M. P. Papazoglou, "Service -Oriented Computing: Concepts, Characteristics and
Directions," Tilburg University, Tilburg.
[36] F. Jammes and H. Smit, "Service-Oriented Paradigms in Industrial Automation," IEEE
Transactions on industrial informatics, vol. 1, no. 1, pp. 62-70, Feb. 2005.
[37] T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design, Pearson
Education, Inc., 2005.
[38] F. Menge, "Enterprise Service Bus," in FREE AND OPEN SOURCE SOFTWARE
CONFERENCE 2007, 2007.
[39] B. M. Michelson, "Event-Driven Architecture Overview: Event-Driven SOA Is Just Part
of the EDA Story," Patricia Seybold Group, 2006.
[40] H. Taylor, A. Yochem, L. Phillips and F. Martinez, Event-driven architecture: How SOA
enables the real-time enterprise, Boston: Pearson Education, Inc., 2009.
[41] D. J. Eck, Introduction to Programming Using Java, Hobart and William Smith Colleges,
2011.
[42] B. Snyder, D. Bosanac and R. Davies, ActiveMQ in Action, Stamford: Manning
Publications Co., 2011.
89
[43] "The JSON Data Interchange Format," Ecma International, Geneva, 2013.
[44] N. Bartlett, OSGi In Practice, 2009.
[45] Introduction to Apache Cassandra, Datastax, 2014.
[46] C. Gormley and Z. Tong, Elasticsearch: The Definitive Guide, Elasticsearch, 2014, 2015.
[47] CODESYS OPC Server V3: Installation and Usage, 3S-Smart Software Solutions GmbH.
1
APPENDIX I – LISA2CORE SETUP
This appendix explains how to setup the software stack developed during this work. The
software is open-source and all the source code is available on GitHub. The source code is
published with a basic publish and subscribe example. NOTE: the testing setup used for
validating the software stack is not available online.
Requirements:
Eclipse Java Neon with Eclipse PDE (Plug-in Development Extension)
Access to ActiveMQ bus version 5.13
Make sure to start the ActiveMQ bus and start Eclipse Java Neon. Step by step setup for the
LISA implementation example:
1. In Eclipse pull all the projects from the GitHub repository
https://github.com/magnussonl/LISA2CoreEclipse
2. When all the projects have been downloaded the configuration of the execution needs
to be done. Go to Run->Run Configurations...
3. Right click on the OSGi Framework in the tree to the left and choose New. Give it a
name the you prefer and choose the packages visible in Figure 36. NOTE: the
OSGi.LISA2Core package is the package that contains the source code needed to
execute the LISA software stack and the OSGi.LISA2Core.impl is an implementation of
the software stack exemplifying the publishing and subscription of messages.
2
Figure 36 Eclipse runtime configuration
4. Close the configuration window and open the project OSGI.LISA2Core in the package
explorer. Navigate to the “application.conf” file and open it, see Figure 37.
3
Figure 37 Package explorer application.conf file
5. Open the configuration file and put in the url, port, username and password for your
activeMQ bus and save the file, see Figure 38.
Figure 38 Application.conf file
6. Run the application by clicking on Run->”Choose your configuration”. NOTE:
Make sure that the ActiveMQ application is running.
