Available via license: CC BY 4.0
Content may be subject to copyright.
Sensors 2021, 21, 6829. https://doi.org/10.3390/s21206829 www.mdpi.com/journal/sensors
Article
Digital Twins Supporting Efficient Digital Industrial
Transformation
Dinithi Bamunuarachchi, Dimitrios Georgakopoulos, Abhik Banerjee and Prem Prakash Jayaraman *
Department of Computer Science and Software Engineering, Swinburne University of Technology,
Hawthorn 3122, Australia; mbamunuarachchi@swin.edu.au (D.B.); dgeorgakopoulos@swin.edu.au (D.G.);
abanerjee@swin.edu.au (A.B.)
* Correspondence: pjayaraman@swin.edu.au
Abstract: Industry 4.0 applications help digital industrial transformation to be achieved through
smart, data-driven solutions that improve production efficiency, product consistency, preventive
maintenance, and the logistics of industrial applications and related supply chains. To enable and
accelerate digital industrial transformation, it is vital to support cost-efficient Industry 4.0 applica-
tion development. However, the development of such Industry 4.0 applications is currently expen-
sive due to the limitations of existing IoT platforms in representing complex industrial machines,
the support of only production line-based application testing, and the lack of cost models for appli-
cation cost/benefit analysis. In this paper, we propose the use of Cyber Twins (CTs), an extension of
Digital Twins, to support cost-efficient Industry 4.0 application development. CTs provide semantic
descriptions of the machines they represent and incorporate machine simulators that enable appli-
cation testing without any production line risk and cost. This paper focuses on CT-based Industry
4.0 application development and the related cost models. Via a case study of a CT-based Industry
4.0 application from the dairy industry, the paper shows that CT-based Industry 4.0 applications
can be developed with approximately 60% of the cost of IoT platform-based application develop-
ment.
Keywords: cyber twins; digital twins; industry 4.0 cost model
1. Introduction
Industry 4.0 is the latest trend in advanced manufacturing, and it is powered by ad-
vancements in the Internet of Things (IoT) and Artificial Intelligence (AI) [1]. Industry 4.0
applications are helping the digital industrial transformation and use IoT-based solutions
to integrate and interact with machines to harvest their data, AI-based solutions to ana-
lyze machine data, and the combination of these foundation technologies for the produc-
tion of high-value information in the form of recommendations or decisions that improve
manufacturing production efficiency, reduce unplanned maintenance, and enhance prod-
uct consistency [2,3].
Industry 4.0 applications utilize complex machines and their development using con-
ventional IoT platforms is costly and time-consuming. This is because, unlike IoT devices
that are relatively simple machines that often incorporate a single sensor or actuator, a
complex industrial machine includes considerable built-in automation and incorporates
many sensors and actuators. Therefore, integrating and interacting with complex ma-
chines involves considerable cost and time to (1) analyze such machines to identify the
machine data parameters that need to be integrated with each Industry 4.0 application,
and (2) integrate the machines with an existing IoT platform (e.g., Azure IoT) that will be
used to develop the Industry 4.0 applications. Furthermore, machine data integration may
also require the translation of machine data into meaningful information related to the
context of the application which demands additional work. Finally, testing the Industry
Citation: Bamunuarachchi, D.;
Georgakopoulos, D.; Banerjee, A.;
J
ayaraman. P. Digital Twins
Supporting Efficient Digital
Industrial Transformation. Sensors
2021, 21, 6829. https://doi.org/
10.3390/s21206829
Academic Editor: Sisi Zlatanova
Received: 29 August 2021
Accepted: 11 October 2021
Published: 14 October 2021
Publisher’s Note: MDPI stays neu-
tral with regard to jurisdictional
claims in published maps and institu-
tional affiliations.
Copyright: by the authors. Licensee
MDPI, Basel, Switzerland. This arti-
cle is an open access article distrib-
uted under the terms and conditions
of the Creative Commons Attribution
(CC BY) license (https://creativecom-
mons.org/licenses/by/4.0/).
Sensors 2021, 21, 6829 2 of 34
4.0 applications that utilize complex machines is both challenging and extremely time-
consuming and costly, as it requires the use of the actual machines and entails a risk of
potential unplanned stoppages and machine damage. The integration and use of machine
simulators for testing purposes are extremely important for Industry 4.0 application test-
ing. In addition, updating and porting an existing application to a machine change or
across a manufacturing plant requires a considerable amount of rework.
To explain these, let us consider an example from the food manufacturing industry.
The production process of food spreads (such as jam, vegemite, tomato paste, peanut but-
ter) involves the utilization of evaporator machines to process the raw materials to achieve
the targeted quality and the consistency of the final product [4]. To achieve the target
product quality, machine operators often need to adjust the machine settings that control
the product consistency (e.g., the steam pressure, inflow, outflow, and other parameters)
of the evaporator machines. Industry 4.0 applications can automate and increase product
consistency by determining and recommending the optimum machine settings that will
achieve or exceed the product quality targets set by the manufacturer by 1) analyzing the
machine sensor data (e.g., pressure, temperature) as well as the current machine settings
(e.g., the setting/position of its control valves), and 2) computing the optimal machine set-
tings that will achieve the target product quality and applying these to the evaporator
machine. Furthermore, Industry 4.0 application testing often involves using evaporator
machine simulators to test the relevant aspects of the machine’s automation before the
application is deployed in the plant to avoid machine damage and to reduce plant down-
time. Any upgrade of the evaporator machine utilized by an existing Industry 4.0 appli-
cation or porting an existing application to a different plant further requires the above
integration and testing activities to be performed for the new machines.
Currently, developing such an Industry 4.0 application using existing industrial IoT
platforms is expensive and time-consuming. The lack of standardized and semantically
rich machine descriptions impedes efficient application development using complex ma-
chines [5,6] and identifying the machine data needed by an application generally requires
going through the machine manuals. Moreover, this needs to be repeated each time when
a new Industry 4.0 application needs to be introduced into the plant. Machine data inte-
gration with the application requires first integrating the machines with an IoT platform
that would be used to develop the application. However, if the integration is application-
specific, it may have a limited ability to support a new application that needs to use the
same machine [7]. Moreover, existing support for the reuse of the machine data translation
functionalities is limited and results in considerable rework to support similar applica-
tions [8]. Furthermore, Industry 4.0 application testing using the existing IoT platforms
requires knowledge about the behaviors of the complex machines including machine au-
tomation for enabling device simulation [9]. Thus, application testing consumes a consid-
erable amount of time. In addition, updating an application to a change of a machine or
porting an application to a different plant is extremely costly due to the required rework,
even when the new plant has similar types of machines.
Digital Twins (DTs) are digital representations of physical objects (processes or sys-
tems). DTs and their corresponding physical objects have a bi-directional data flow be-
tween them, and DTs closely reflect the state and the behavior of the corresponding phys-
ical object [10–12]. In the context of Industry 4.0, DTs are increasingly being used to rep-
resent industrial machines and to provide smart data-driven solutions in manufacturing
plants [13], including for predictive maintenance, product quality monitoring [14,15], and
production process optimizations [16–20]. However, there are limitations in existing DTs
and their ability to support cost-efficient Industry 4.0 application development, testing,
update, and porting. A detailed analysis of the related work, including that of the DTs, is
presented in Section 2. The proposed Cyber Twins (CTs) [6], are an extension of existing
DTs and they address some of the limitations in existing DTs to support cost-efficient In-
dustry 4.0 application development, testing, update, and porting. CTs can be cost effi-
Sensors 2021, 21, 6829 3 of 34
ciently auto-generated by using the machine semantic descriptions and they contain se-
mantic descriptions of the machines and the CTs themselves. In addition, a CT can be cost
efficiently updated to accommodate machine upgrades or replacements, as well as pro-
vide services to support application testing by incorporating a simulator of the corre-
sponding machine. In [21], we proposed a CT Management Framework for generating
and managing CTs.
In this paper, we focus on CTs and their use in CT-based Industry 4.0 application
development and propose a cost model that captures Industry 4.0 application develop-
ment costs. Next, we use these to compare the CT-based Industry 4.0 application devel-
opment with the current state-of-the-art IoT platform-based approach for the develop-
ment of Industry 4.0 applications. Finally, we show that CT-based Industry 4.0 application
development is more cost-efficient via a case study from the dairy industry. The main
novel contributions of this paper are the following:
• The CTs, and in particular, the ability of each CT to digitally represent a specific com-
plex industrial machine via a semantic description of the machine, to communicate
with the corresponding machines to obtain its data and send machine settings and
other actuation to the machine, and to simulate the machine operation to facilitate
Industry 4.0 application testing;
• CT-based Industry 4.0 application development that utilizes CTs instead of individ-
ual sensors and actuators to make Industry 4.0 application development more cost-
efficient. Unlike IoT platform-based Industry 4.0 application development that can
integrate the individual sensors and actuators of the machine, CT-based application
development can integrate entire-complex machines reducing the cost of application
development, especially when CTs are used by multiple Industry 4.0 applications;
• A novel cost model for estimating the cost of developing an Industry 4.0 application.
To the best of our knowledge, no other model currently exists for that.
• An evaluation of CT-based applications using a sample application from the dairy
industry that shows the benefits of CT-based Industry 4.0 application development.
The rest of the paper is organized as follows. Section 2 presents the related work and
Section 3 presents an overview of the CTs. Section 4 describes CT-based Industry 4.0 ap-
plication development and presents the cost model proposed for modelling Industry 4.0
application development costs. Section 5 presents the case study from the dairy industry
to exemplify and evaluate the CT-based Industry 4.0 application development and pre-
sents the evaluation results. Finally, Section 6 presents the conclusion and future research
directions.
2. Related Work
Traditionally, Industry 4.0 applications are developed by directly integrating the ma-
chines with the application via an existing IoT platform. However, with the emergence of
Digital Twins (DTs), the DTs have also been utilized to develop Industry 4.0 applications.
Existing research and commercially available IoT platforms have introduced a variety of
DTs to represent industrial machines and to develop Industry 4.0 applications for manag-
ing and improving plant efficiency, product quality, and preventive maintenance. Section
2.1 briefly describes how these DTs are different and then reviews their applications and
the provided support for Industry 4.0 application development. Section 2.2 reviews the
traditional Industry 4.0 application development approach and the support provided by
the existing IoT platforms for Industry 4.0 application development. Next, Section 2.3 re-
views the existing cost models proposed and used to calculate the Industry 4.0 application
development costs, and finally, Section 2.4 summarizes the review findings.
2.1. DTs and DT-Based Industry 4.0 Application Development
DT variants that have been proposed in the existing research include Digital Models
(DMs), Digital Shadows (DSs), and Digital Twins (DTs). These variants differ in the level
Sensors 2021, 21, 6829 4 of 34
of data integration between the physical object and its corresponding virtual object (i.e.,
the digital representation) [22]. A DM is a virtual portrayal of a physical object with no
automated data exchange between the physical object and the virtual object. In a DS there
exists an automatic uni-directional dataflow from the physical object to the virtual object;
thus, the virtual object reflects any changes to the state of the physical object. In DTs, there
is a bi-directional data flow between the virtual and physical objects and the changes
made to the DTs are reflected in the corresponding physical object and vice versa [10,22].
These digital representations have been proposed and are used for providing smart data-
driven solutions to make improvements in manufacturing plants.
The DSs can collect and integrate data from the physical object and other relevant
sources in real-time as they have an automated data flow from the physical to the virtual
object. They can enable numerous applications to use these data to perform a comprehen-
sive analysis on the corresponding machines or the manufacturing systems. To allow in-
cident detection and the deciphering of the related operation context of the machining
incident, a DS is proposed in [23]. The framework proposed for knowledge-based DSs
allows the integration of data from diverse sources to create the DS, including from the
machine tool itself and the smart sensing devices. Moreover, an ontology model is used
to create the knowledge model of the proposed DS framework and the ontology support
describing the detection elements, operational context, and incident types. The authors of
[14] propose integrating the DS simulation model with the Manufacturing Execution Sys-
tem (MES) to create a DT. The MES integrated DT is used for decision making with the
support of an underlying intelligence layer that hosts rules and the knowledge to choose
among alternatives. Next, the DT is used to support the management of error states and
to trigger disassembly processes that result from low assembly quality. In [24], a DS frame-
work is proposed to enable real-time data collection and the integration of the mainte-
nance, repair, and overhaul services of machine manufacturers. This includes the support
of different kinds of maintenance activities including preventive and corrective mainte-
nance. Moreover, the authors of [25] propose DSs to enable the efficient use of knowledge
management systems to support single small batch production companies towards Indus-
try 4.0. Riesener et al. has proposed a DS as an enabler for data analytics in product lifecy-
cle management. The proposed model merges data from heterogeneous sources and uses
mechanisms to choose the suitable data sources to obtain the required information [26].
While DSs allow information fusion from heterogeneous sources and can support the
comprehensive analysis of machines and manufacturing systems, they do not support ac-
tuating and sending data to the machines.
The DTs have a bi-directional data flow between the physical and virtual objects and
have the potential to support many facets of Industry 4.0 application development. To
support the predictive maintenance of a flexible production system, Barthelmey et al. have
proposed a dynamic DT [27]. The DT receives data in the AutomationML format, and the
available analytical models are applied to the data to identify the predictive maintenance
requirements. To support localized anomalous faults and also to infer the product quality
of fused deposition modelling-based additive manufacturing printers, DTs are proposed
in [15]. The work proposes an IoT-based methodology to build DTs using data from an
indirect medium (i.e., retrofitted low-end sensors available in IoT devices) as the legacy
manufacturing systems do not have built-in multi physics sensors by default. To support
the condition monitoring of a CNC machining tool, Liu et. al, have proposed a DT mod-
elling framework [28]. In the proposed approach, the functions of the machining tool are
provided as services to support manufacturers, enterprises, and operators by the DT. This
enables a variety of applications to utilize the DT data. Moreover, Schroeder et al. [29]
have proposed a data modelling mechanism for DTs of the industrial plant components
using AutomationML. To support utilizing DT data by applications, the DT data are ex-
posed to third-party applications via a middleware platform, using JSON/REST interfaces.
However, the lack of the use of semantics can hinder the portability of the applications
that utilize these data. To reduce the cost of programming and reconfiguring the robots
Sensors 2021, 21, 6829 5 of 34
that are used to improve the flexibility of production systems, Hoebert et al. have pro-
posed DTs [30]. In this work, ontologies are used as a knowledge base to describe the
robot and the related environment to support the automatic configuration of the DT and
the robot. To advance the traditional CNC machine tools to Cyber-Physical Machine Tools
(CPMT), Liu et al. have proposed a systematic development method. The CPMT encom-
passes a Machine Tool Cyber Twin (MTCT) that contains an information model of the
machine tool, supports data fusion, and embeds intelligent algorithms in it. An MTCon-
nect-based information modelling approach is used in this work to support the represen-
tation of the logical structure of the machine tool and its static and dynamic properties
[17]. To support a variety of applications, Lu and Xu have proposed a resource virtualiza-
tion framework for smart factories [31]. The proposed framework encompasses a meth-
odology for DT creation that is based on the hierarchy of the DT, the information to be
modelled, and the related modelling method. However, this requires a considerable
amount of manual work. In [32], DTs are proposed for a production line to support the
optimization of the production processes using OPC data. In the proposed DT, the sensor
data from the sensors of the production line machines are collected to provide a visual
representation. This simulation-based model is then used to identify and alerts about the
deviations from the optimal scenarios. Moreover, DTs have gained a lot of attention from
industries. General Electric (GE) has invented the DT of a wind farm, where the DTs are
constantly updated based on the data collected from the control systems of wind turbines
in a farm [13]. The system allows the running state of wind turbines to be monitored
through the respective digital models. Moreover, GE developed a DT interface to manage
multiple DTs at the same time, which displays the latest operating conditions of the wind
turbines and control features that can be (re)configured to optimize the wind farm perfor-
mances. The DTs have the potential to support different aspects of Industry 4.0 application
development. However, despite their potential in many cases, DTs are proposed to sup-
port specific applications [15,27,28]. Moreover, the lack of semantically rich machine de-
scriptions hinders the ability to use the DTs in application development [29]. In addition,
existing DTs have a limited ability to support the simulating/emulating complex machines
including their machine automation [17,27,29–31] or to allow switching between the phys-
ical machines and the simulators to support Industry 4.0 application testing [32,33].
Furthermore, open source and commercial IoT platforms exist that support DT de-
velopment and their use. GE’s Predix platform allows the creation of DTs and the running
of data analytics and monitoring [34]. Moreover, the Siemens MindSphere platform al-
lows machines and physical infrastructure to be connected to a DT and allows data to be
streamed from these machines to support the development of DT solutions [35]. Moreo-
ver, Azure DT is a PaaS solution by Microsoft for supporting DT development. Azure DT
provides a Digital Twin Definition Language (DTDL) to create DT model definitions and
provides APIs to interact with DTs [8]. Azure also supports sensor data simulations and
provides services for querying and finding the deployed DTs. Moreover, Eclipse Ditto is
an open-source framework built to support the development of the DTs of “things”. The
domain model used by Ditto for modelling has the concepts “thing”, “access controllers”,
and “features”. Ditto maintains the model of the device and updates the model with the
last reported state of the IoT device and further provides services for using the sensing
and actuation capabilities of the device via its DT. It also provides search functionality for
the applications to search and find a DT that maps a given criterion [36]. We have further
discussed and evaluated the use of such IoT platforms and frameworks for building DTs
in [21]. Currently, limited research has been completed to support cost-efficient DT gen-
eration to support Industry 4.0 applications and most of these solutions that support DT
development require a considerable amount of manual work [31].
Sensors 2021, 21, 6829 6 of 34
2.2. Traditional Industry 4.0 Application Development
Traditionally, Industry 4.0 application development is completed by (directly) utiliz-
ing IoT platforms. The machines are integrated with the IoT platforms to develop the In-
dustry 4.0 applications. Here we review the support provided by the IoT platforms to
develop Industry 4.0 applications related to the identification of machine data, the inte-
gration with the Industry 4.0 applications, and Industry 4.0 application development and
testing when using this approach. Currently, identifying the machine data that are re-
quired by an Industry 4.0 application is time-consuming due to the unavailability of
standard and semantically rich machine descriptions. Most of the IoT platforms enable
the use of simple key-value pair-based machine descriptions [37,38] or support the use of
IoT platform-specific vocabularies [39] to describe the machines. These descriptions are
often developed by application developers who do not have expert knowledge about
complex machines; thus, they lack accuracy. Moreover, complex machines can have many
sensors, actuators, and multiple machine automation that utilize the sensors and actua-
tors. Simple key-value pair-based descriptions have a limited capability to describe the
complex inter-relationships among these elements. Further, due to the lack of the use of
rich semantics, such descriptions can be difficult to understand [5,6]. To support the mod-
elling of machines and their data, ontology-based approaches have been proposed in the
existing research work [40–42]. IoT platforms such as OpenIoT [43] allow the SSN [44]
ontology-based integration of sensors and their data with the IoT platform. Moreover, the
DataTweet [45] framework allows semantic descriptions of the machines to be utilized to
integrate them with the framework. However, the utilized ontologies do not support the
modelling of complex machines. The platforms such as FIWARE support the adoption of
common data models to support the interoperability of the applications [46]. They also
contain reusable data models for domains such as smart cities, smart health, and smart
aeronautics [47]. However, these need to be expanded to support the context of manufac-
turing and the modelling of complex machines including their machine automation.
Moreover, MindSphere [35] supports Semantic Data Interconnect (SDI) to support the use
of ontologies to understand and maintain relationships among data from different sources
such as manufacturing resource planning, IoT data lakes, etc. This aims to support the
building of interoperable solutions. However, it is necessary to have ontology models that
support the description of the machines and their data. This is not provided by the plat-
form. IoT platforms such as SiteWhere [37] and DataTweet allow application development
using the machines integrated with the platform and provide REST-based APIs to send/re-
ceive data to/from the machines [45,48]. Moreover, Azure IoT provides the Azure IoT Hub
service to integrate the machine with the IoT platform and provides AMPQ-based end-
points to retrieve machine data for application development [38]. However, due to the
lack of the use of semantics in data integration, such solutions can lead to vendor lock-
down. Moreover, certain machine outputs may need to be translated related to the context
of the new application before integration with the application. To support this kind of
translation, Azure IoT provides Azure functions [8]. However, due to the lack of the use
of semantics, the reusability of such data translators and the related programming effort
can be limited. Existing IoT platforms facilitate services that support the development of
applications such as data analysis support, stream processing services, etc. [35,38]. How-
ever, there is a lack of support for facilitating the testing of Industry 4.0 applications that
utilize complex machines. IoT platforms such as OpenIoT have a limited ability to support
the application testing of complex machines. Industrial solutions such as Azure IoT pro-
vide device simulation services and allow sensor data simulation [49]. However, if it is
necessary to simulate the aspects of machine automation, they require a considerable
amount of work to implement the simulators and code their behavior [9]. Further, this
may require knowledge about the behavior of machine automation. Moreover, the appli-
cation update and porting require similar issues relating to each application development
activity that was described earlier to be solved. Furthermore, the unavailability of reusable
Sensors 2021, 21, 6829 7 of 34
data translators and their descriptions can further hinder the cost-efficient update and
portability of an application.
2.3. Industry 4.0 Application Development Cost Modelling
Developing an Industry 4.0 application requires the identification of machine data
needed by an application, integrating these with the application, developing the applica-
tion functionality, and testing the application using machine simulators or emulators.
Cost models exist that have been proposed to calculate general software development
costs such as COCOMO [50]. Moreover, to measure the reusability and portability of the
software, evaluation formulas based on metrics such as man-hours, lines of code, are
available [51,52]. However, these cost models do not capture the Industry 4.0 application
development costs at a fine-grained level considering the application interactions with the
machines and the application development activities, including an understanding of the
machines and integrating their data.
2.4. Summary
The traditional approach towards Industry 4.0 application development is impeded
by the lack of accurate and comprehensive machine descriptions, inefficient machine data
integration approaches with the Industry 4.0 application development, and limited sup-
port for application testing. The existing research and commercially available IoT plat-
forms have introduced a variety of DTs to represent industrial machines and to support
the development of Industry 4.0 applications. However, there are limitations in existing
DTs with respect to their ability to support Industry 4.0 application development, testing,
update, and porting. Existing DTs have a limited ability to simulate and/or emulate the
aspects of complex machines, including their machine automation controllers, and they
do not support switching between physical machines and their respective simulators to
support application testing. Moreover, some of them are application-oriented and are un-
able to support a variety of Industry 4.0 applications. Furthermore, cost-efficient DT de-
velopment needs to be supported to enable Industry 4.0 application development using
DTs; however, this has not been sufficiently explored in the research. In addition, it is
important to support the updating of the Industry 4.0 applications to facilitate the change
of machines and porting them across manufacturing plants; this has not been explored in
existing DT solutions. To overcome the above limitations and to enable cost-efficient In-
dustry 4.0 application development, this paper proposes CTs that are an extension to DTs.
A CT can support a variety of applications, has a semantic description of the machine that
it represents, and includes capabilities to support cost-efficient application testing, updat-
ing, and porting. The CTs are introduced in Section 3 and CT-based Industry 4.0 applica-
tion development is discussed in Section 4.
Moreover, there is a lack of cost models for Industry 4.0 application cost/benefit anal-
ysis and the available cost models only allow the modelling of general application devel-
opment costs. To address this, this paper also proposes a cost model for calculating the
Industry 4.0 application development costs and this is introduced in Section 4.2.
3. Cyber Twins (CTs)
CTs are digital representations of physical machines. We note here that the paper
covers only the area of Industry 4.0 applications (e.g., preventive maintenance, product
quality improvement) and in Industry 4.0, the main physical entities are industrial ma-
chines. Thus, CTs provide digital representations to them to support Industry 4.0 appli-
cation development. The CTs support bi-directional communication between the physical
machine and the CT. A CT reflects the state of the physical machine, and any changes
made to the state of the CT are reflected on the physical machine, similar to existing DTs.
Moreover, CTs closely reflect the behavior of the physical machine by incorporating an
emulator/simulator of the machine. This can be a near real-time reflection of the behavior
Sensors 2021, 21, 6829 8 of 34
of the physical machine if the provided simulators can be configured to accept real-time
inputs from the machine, or it can be a close reflection of the expected behavior of the
machine if the simulators are provided with historical data from the machine, or if a ma-
chine emulator is used. Furthermore, the proposed CTs extend the existing DTs by ad-
dressing some of the limitations in existing DTs to support Industry 4.0 application devel-
opment, testing, update, and porting. CTs can be cost-efficiently auto-generated by using
the machine semantic descriptions and contain semantic descriptions of the machines and
the CTs themselves. In addition, CTs can be easily updated to accommodate machine up-
grades or replacements. Further, a CT can support a variety of Industry 4.0 applications
and provides the following services to support their development:
• Query the semantic description of the machine that is represented by the CT;
• Communicate with the machine including obtaining the data produced by the ma-
chine, applying the machine settings, and sending other inputs to the machine;
• Interact with the machine emulator or simulator that is incorporated in the CT to
support application testing.
In the following sections, we present a brief overview of the CT ontology that is used
as a basis for capturing the semantic description of any specific machine and explain CT
generation via a CT management framework, which was introduced in [21]. Moreover,
we briefly explain how the simulators in CTs can support Industry 4.0 application testing.
3.1. CT Ontology for Describing Complex Industrial Machines
The concepts and relationships provided in the CT ontology to capture machines and
their data are depicted in Figure 1. The ontology can be used to model simple machines,
which contain a single sensor and an actuator, or complex machines with many sensors,
actuators, and machine automation. It contains Communication Protocol and Endpoint
concepts to be able to capture the connectivity details of a machine. It reuses the concepts
such as Sensor, Actuator, System, and Platform from existing SSN[44]/SOSA[53]ontolo-
gies and these are prefixed using “sosa” and “ssn” in Figure 1. An example of CT ontol-
ogy-based machine modelling is presented in Section 5.1.
Sensors 2021, 21, 6829 9 of 34
Figure 1. The CT ontology for modelling machines. The CT ontology reuses the sensor, actuator, system, and platform
concepts from SOSA/SSN ontology and introduces the machine, operating system, machine automation, machine control,
communication protocol, and endpoint concepts to model the machines and elements of a machine. It also supports the
modelling of machine data using machine inputs, machine outputs, and machine settings.
3.2. CT Management Framework
The framework provides services for the CT developers to generate the CTs for the
machines and updates them based on the machine semantic descriptions. Figure 2 illus-
trates the framework services.
Figure 2. The CT management framework. The framework enables the CT developers to generate
and update the CTs of the machines. The Industry 4.0 applications utilize the machines via their
corresponding CTs, and end-users interact with these Industry 4.0 applications.
To generate a CT for a machine, a CT developer first needs to model the machine
using the CT ontology. A modelling tool such as Protégé [54] can be used for modelling
purposes. Then the semantic description of the machine and the information that needs
to be associated with the CT needs to be provided to the CT generation service. This ser-
vice accepts the machine’s semantic description, CT ID, and context information relating
to the CT as its inputs. The context information is optional and can include a description
of the environment (e.g., the plant where the machine is located), as well as the latitude
and the longitude of the environment’s location. In response to the service request, the
service generates the CT for the machine and deploys it into the CT deployment environ-
ment integrated with the framework.
To support CT-based Industry 4.0 application development, the CT generation ser-
vice also generates and associates a semantic description of the CT with the generated
CTs. This description contains the CT ID, machine ID, the context, and the endpoints re-
quired to connect with the CT. The ontology concepts that are used for generating this
description are shown in Figure 3.
Sensors 2021, 21, 6829 10 of 34
Figure 3. The ontology concepts that are used for generating the semantic descriptions of the CTs.
The ontology concepts include Cyber Twin, machine, context, endpoint, and the communication
protocol.
The context is used to model the information provided by the CT developer to the
CT generation service. It has Datatype properties to model the longitude (geo:long), lati-
tude (geo:lat) and description (Description) of the CT. Moreover, a CT can have multiple
endpoints that support different Communication Protocols for the sending/receiving of
machine data and the querying of semantic descriptions. Section 5.2 includes an example
of a specific CT semantic description. The CTs generated for the machines become avail-
able to the application developers via a web interface. This interface allows the application
developers to apply filter criteria to find the CTs and query the machine semantic descrip-
tions via their corresponding CTs to support the integration of the machines with the ap-
plications.
The CT framework allows the CTs to be updated to support machine replacement.
More specifically, updating a CT to connect to another machine involves providing the
CT ID and the machine description of the new machine as an input to the CT update ser-
vice provided by the CT management framework. When the respective service receives
this request, it will update the selected CT and connect it to the new machine. Here, a brief
overview of the generation and updating of the CT was provided for the comprehensive-
ness of the paper, and the reader is referred to [21] for a detailed discussion on the topic.
Please note that this paper only focuses on the use of the generated CTs to develop the
applications.
3.3. Simulators in CTs and their Support for Testing
Industry 4.0 application testing is an important aspect of Industry 4.0 application de-
velopment. Generally, machine simulators are available for many industrial machines and
testing typically involves using these simulators [55,56]. The proposed CTs incorporate
the physical machine as well as simulators of the corresponding machines to support ap-
plication testing. CTs allow a choice between the simulator or emulator of the machine
they represent as is needed to carry out application testing. This approach allows CTs to
support Industry 4.0 application testing and improvement. Later in the paper, in Section
5.2.2, we describe the specific simulators used for testing the application described in Sec-
tion 5.
Next, we describe the Industry 4.0 application development using the CTs and the
proposed cost model for modelling Industry 4.0 application development cost.
4. CT-based Industry 4.0 Application Development and Costing
CT-based Industry 4.0 application development involves selecting the CTs that are
needed by the application, integrating the CT and the machine data they provide with the
Sensors 2021, 21, 6829 11 of 34
application, testing the application using CT-provided machine simulators, and deploy-
ing the application with the CTs set to use the actual machines. Section 4.1 presents CT-
based application development and the roles of users that develop and use CTs. Section
4.2 introduces a cost model for Industry 4.0 applications that will be used later in this
paper to show the benefits of CT-based application development.
4.1. CT-Based Industry 4.0 Application Development: Activities and Roles
CT-based Industry 4.0 application development also includes application updates
and application porting and involves two user roles: CT developer and application devel-
oper. The CT developer generates the CTs for the machines and updates the CTs. CT gen-
eration is only required if a machine that needs to be used by an application does not
already have a CT. Thus, CT generation only needs to be performed once and once gen-
erated, a CT can be used/reused by any Industry 4.0 application that needs to use the
corresponding machine. Moreover, a CT can be updated by the CT developer as required
to support its usage in application development. The application developer uses CTs to
develop the Industry 4.0 applications.
In the following sections, we discuss the activities involved in a) developing a new
CT-based Industry 4.0 application, b) updating an existing CT-based Industry 4.0 appli-
cation to a change or an upgrade of a machine and c) porting an existing CT-based Indus-
try 4.0 application to a different environment (e.g., a plant or a farm).
4.1.1. Developing a New CT-Based Industry 4.0 Application
For new application development, the application developer needs to query the ma-
chine description via the CT and identify the machine data needed by the application. If
the machine produces the data that map the application requirements, then the data need
to be integrated with the application via the CT. Finally, it requires the development of
the application functionality and the testing of the application using the CTs. These activ-
ities are further illustrated in Figure 4.
Figure 4. New CT-based Industry 4.0 application development, related activities, and user roles.
4.1.2. Updating an Existing CT-Based Industry 4.0 Application
If a machine used by an application is upgraded, changed, or replaced, it may require
an update to the Industry 4.0 application that uses the machine via the CT. If the new
machine has its own CT, this requires querying the CT of the new machine, integrating its
data with the application, and finally (if required) updating the application functionality
and testing it. If the new machine produces different data, the CT of the new machine
needs to be updated by applying a data translator and its data need to be integrated with
the application. This is further illustrated in Figure 5.
Note that if the CT of the old machine is updated to be connected to the new machine,
the application code does not need to be modified unless it requires data translation.
Sensors 2021, 21, 6829 12 of 34
Figure 5. CT-based Industry 4.0 application update, related activities, and user roles.
4.1.3. Porting an Existing CT-based Industry 4.0 Application
If an application needs to be ported to a different environment (e.g., to a different
plant) it may require changes to the application. If machines in the new environment have
CTs, the application developer needs to query the machine descriptions, integrate the new
CTs with the application and (if required) update the application functionality and test
the application. Moreover, the CTs of the new machines can be updated as necessary by
applying the data translators. These activities are the same as those depicted in Figure 5.
In the case that the new machines do not have CTs, the CTs need to be generated.
4.2. A Cost Model for Industry 4.0 Application Development
In this section, we introduce a cost model for the Industry 4.0 application that allows
us to compare the cost of CT-based application development with other application de-
velopment alternatives. The proposed cost model considers all application development
activities that go into Industry 4.0 application development, so that CT-based application
development can be compared to IoT-platform-based application development. More spe-
cifically, the proposed cost model considers the costs of the following for each Industry
4.0 application: a) identifying the machine data needed by the application, b) integrating
machines and their data with the application and c) developing the application functionality
and testing the application. Before introducing the formulas for calculating the application
development cost, we first present how the machines are used by Industry 4.0 applications
based on the data flow interactions between them. This is depicted in Figure 6.
Figure 7 depicts the internal data flow of a machine 𝑚, including the machine out-
puts, machine inputs, and machine settings and Figure 6 depicts how they are mapped to
set of outputs (𝑂) and set of inputs (𝐼). The set of machine outputs produced by 𝑚 is
𝑀𝑂, the set of machine inputs consumed by 𝑚 is 𝑀𝐼, and the set of machine settings
consumed by 𝑚 is 𝑀𝑆𝑇. For each machine 𝑚 (𝑚∈𝑀), 𝑀𝐼⊂ 𝑂, and 𝑀𝑂 ⊂
𝐼 and 𝑀𝑆𝑇⊂ 𝐼. In a case where a machine output cannot be directly mapped to an input
that needs to be retrieved by an application, the utilization of a data translator (a program
that implements the functionality for converting the machine outputs to the required ap-
plication input) is required. The set of data translators that allow the translation machine
outputs are denoted by 𝑇. 𝑀𝑆 and 𝑀𝐴 denote the set of sensors and the set of actua-
tors in the machine 𝑚. 𝑀𝐶 denotes the set of machine automation/machine controls in
𝑚. If 𝑚 is a simple machine, |𝑀𝐶|=0. If 𝑚 is a complex machine |𝑀𝐶|>0. Next,
we present the formula for calculating the total cost of developing an Industry 4.0 appli-
cation.
Sensors 2021, 21, 6829 13 of 34
Figure 6. Industry 4.0 applications utilizing machines. The applications retrieve outputs and provide inputs, and the ma-
chines consume the inputs and provide outputs.
Figure 7. Internal elements of machine 𝑚, the machine data produced and consumed by 𝑚, data translators applied to
𝑚, inputs, and outputs. Machine 𝑚 consumes machine settings and machine inputs and produces machine outputs.
If 𝐶𝑜𝑠𝑡(𝑀,𝑎) denotes the costs of identifying the data produced by 𝑀
that needs to be used by the application 𝑎, 𝐶𝑜𝑠𝑡(𝑀,𝑎) denotes the cost of integrating
𝑀 and their data with 𝑎, and 𝐶𝑜𝑠𝑡(𝑀,𝑎) denotes the cost of developing the applica-
tion functionality and testing 𝑎 using 𝑀, the total cost of developing 𝑎, 𝐶𝑜𝑠𝑡(𝑎),
is,
𝐶𝑜𝑠𝑡(𝑎)= 𝐶𝑜𝑠𝑡(𝑀,𝑎) +𝐶𝑜𝑠𝑡(𝑀,𝑎) +𝐶𝑜𝑠𝑡(𝑀,𝑎) (1)
Sensors 2021, 21, 6829 14 of 34
A summary of the notations introduced earlier is listed in Table 1. Next, we describe
how the 𝐶𝑜𝑠𝑡(𝑀,𝑎) , 𝐶𝑜𝑠𝑡(𝑀,𝑎), and 𝐶𝑜𝑠𝑡(𝑀,𝑎) are calculated and the
metrics that can be used in the cost calculations.
Table 1. Notations and their description.
Notation Description
𝐴
Set of applications (𝑎∊
𝐴
)
𝑀 Set of machines in a plant (𝑚∊𝑀)
𝐼 Set of inputs
𝑂 Set of outputs
𝑀 Set of machines that are utilized by 𝑎 (𝑀⊂𝑀)
𝐼, Set of inputs provided by 𝑎, to 𝑚
𝑂, Set of outputs retrieved by 𝑎, from 𝑚
𝑀𝑆 Set of sensors in 𝑚
𝑀
𝐴
𝑀𝐶
Set of actuators in 𝑚
Set of machine automation/machine controls in 𝑚
𝑀𝐼 Set of machine inputs consumed by 𝑚 ( 𝑚𝑖
∊𝑀𝐼)
𝑀𝑂 Set of machine outputs produced by 𝑚 ( 𝑚𝑜
∊𝑀𝑂)
𝑀𝑆𝑇 Set of machine settings consumed by 𝑚 ( 𝑚𝑠𝑡
∊𝑀𝑆𝑇
)
𝑇 Set of data translators
𝑇, Set of data translators used by 𝑎 for translating
machine outputs produced by 𝑚
𝐶𝑜𝑠𝑡(𝑎) The total cost of developing 𝑎 by using 𝑀
𝐶𝑜𝑠𝑡(𝑀,𝑎) Cost of identifying the data needed by 𝑎 from 𝑀
𝐶𝑜𝑠𝑡(𝑀,𝑎) Cost of integrating 𝑀 and their data with 𝑎
𝐶𝑜𝑠𝑡(𝑀,𝑎) Cost of developing and testing 𝑎 using 𝑀
4.2.1. Cost of identifying the machine data required by the application
The total cost of identifying all the machine data that need to be utilized by an appli-
cation is the summation of the costs of identifying the data needed by an application from
each machine utilized by the application. If 𝐶𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑦(𝑚𝑗,𝑎𝑙) denotes the cost of identify-
ing data required by 𝑎𝑙 from 𝑚𝑗, 𝐶𝑜𝑠𝑡𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑦(𝑀𝑙,𝑎𝑙) is,
𝐶𝑜𝑠𝑡(𝑀,𝑎) = ∑𝐶(𝑚,𝑎)
∀∊ (2)
Here, 𝐶(𝑚,𝑎) includes the costs of identifying the machine outputs directly
consumed by the application (𝑀𝑂∩𝑂,), the machine inputs (𝑀𝐼∩ 𝐼,), and the ma-
chine settings (𝑀𝑆𝑇∩ 𝐼,) needed by the application. If C(𝑦) denotes the cost of
identifying an individual element 𝑦, where 𝑦∊ (𝑀𝑂
∩𝑂,) 𝑂𝑅 𝑦 ∊ (𝑀𝐼∩ 𝐼,) 𝑂𝑅 𝑦 ∊
(𝑀𝑆𝑇∩ 𝐼,),
𝐶𝑚,𝑎
=𝐶
(𝑝)
∀∊∩,+𝐶
(𝑟)
∀∊∩ ,
+ 𝐶(𝑡)
∀ ∊ ( ∩ ,)
(3)
Here, C(𝑦) includes the costs of querying and applying the filter criteria (or
executing commands) to identify 𝑦. If 𝐶(𝑦) denotes the cost of querying the identifi-
cation of element 𝑦 and 𝐶(𝑦) denotes the cost of applying configurations (e.g., ap-
plying filter criteria or commands) to identify 𝑦,
Sensors 2021, 21, 6829 15 of 34
𝐶(𝑦) = 𝐶(𝑦) + 𝐶(𝑦) (4)
It is possible to use the Number of Configurations (NoCs) and the Number of Queries
(NoQs) as the metrics for calculating these costs. We define 𝑘 to be the querying cost
factor (e.g., cost of writing a query) and 𝑘 to be the configuring cost factor (e.g., cost of
applying filter criteria or a command). If 𝑤 is the number of queries executed for identi-
fying 𝑦 and 𝑤 is the number of configuration parameters (or commands) applied for
identifying 𝑦, by applying these to Equation (4) we obtain,
𝐶(𝑦) = 𝑘𝑤 + 𝑘𝑤 (5)
𝐶𝑜𝑠𝑡𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑦(𝑀𝑙,𝑎𝑙) can be calculated by calculating 𝐶𝑚,𝑎 for each ma-
chine 𝑚 using Equation (4) and (5).
4.2.2. Cost of Integrating Machines and Machine Data with the Application
The total cost of integrating all machines utilized by an application and the related
data is a summation of the costs of integrating each machine and its related data with the
application. If 𝐶𝑖𝑛𝑡(𝑚𝑗,𝑎𝑙) denotes the cost of integrating machine 𝑚𝑗 and its data to use
in 𝑎𝑙,
𝐶𝑜𝑠𝑡𝑖𝑛𝑡(𝑀𝑙,𝑎𝑙) = 𝐶𝑖𝑛𝑡(𝑚𝑗,𝑎𝑙)
∀𝑚𝑗∊ 𝑀𝑙 (6)
Here, 𝐶(𝑚,𝑎) includes the costs of integrating 𝑚𝑗 and its data and integrating
the related data translators with the application. If C(𝑦) denotes the cost of integrating
an individual element 𝑦, where 𝑦∊{𝑚
} 𝑂𝑅 𝑦 ∊ 𝑇,, C(𝑚,𝑎) is,
𝐶𝑚,𝑎= 𝐶
𝑚+ 𝐶
(𝑞)
∀ ∊ (,) (7)
Integrating a machine and its data or the related data translators with the application
requires the configurations and/or writing code needed for integration to be set. If
𝐶(𝑦) denotes the cost of setting configurations to integrate 𝑦 and 𝐶(𝑦) denotes
the cost of coding for integrating 𝑦,
𝐶(𝑦) = 𝐶(𝑦) + 𝐶(𝑦) (8)
We use Source Lines of Code (SLoC) and NoCs as the metrics to calculate the costs.
If 𝑥 is the NoCs applied (or executed) for integrating 𝑦 and 𝑥 is the SLoC added or
modified for integrating 𝑦, 𝑘 is the configuring cost factor, and 𝑘 is the coding cost
factor, by applying these to (8) we obtain,
𝐶(𝑦) = 𝑘𝑥 + 𝑘𝑥 (9)
Subsequently, 𝐶𝑜𝑠𝑡𝑖𝑛𝑡(𝑀𝑙,𝑎𝑙) can be calculated by calculating 𝐶𝑚,𝑎 for each
machine 𝑚 using Equations (8) and (9).
4.2.3. Cost of developing the application functionality and testing the application
The cost of developing the application functionality and testing it using the machine
simulators/emulators is the summation of the costs of the coding required for developing
the application functionality and the cost of testing it using the machine simulators/emu-
lators. If 𝐶(𝑎) denotes the coding cost of developing 𝑎 and 𝐶(𝑀,𝑎) denotes
the cost involved in testing 𝑎, by using the simulators/emulators of 𝑀,
Sensors 2021, 21, 6829 16 of 34
𝐶𝑜𝑠𝑡(𝑀,𝑎) = 𝐶(𝑎)+ 𝐶
(𝑀,𝑎) (10)
It is possible to use SLoC as the metric for calculating 𝐶(𝑎). If 𝑦 is the SLoC
added or modified for implementing the application functionality,
𝐶(𝑎) = 𝑘𝑦 (11)
𝐶(𝑀,𝑎) is the summation of the costs of simulating/emulating each machine
used by the application 𝑎 and the cost of writing code for testing the application 𝑎. If
𝐶𝑚 denotes the cost of simulating/emulating an individual machine, 𝑚 and
𝐶_(𝑎) denotes the cost of writing code to test 𝑎,
𝐶(𝑀,𝑎) = 𝐶_(𝑎)+ 𝐶
𝑚,𝑎
∀∈
(12)
We use SLoC as the metric for calculating 𝐶_(𝑎). If 𝑦 is the SLoC added or
modified for testing 𝑎,
𝐶
_
(𝑎) = 𝑘𝑦 (13)
𝐶𝑚,𝑎 includes the cost of developing machine simulators/emulators and the
cost of integrating them with the application. If 𝐶_𝑚,𝑎 denotes the cost of devel-
oping a simulator/emulator of 𝑚 to test 𝑎 and 𝐶_𝑚,𝑎 denotes the cost of inte-
grating the simulator/emulator of 𝑚 to test 𝑎,
𝐶𝑚,𝑎 = 𝐶
_
𝑚,𝑎 + 𝐶
_
𝑚,𝑎 (14)
As before, we use SLoC as the metric for calculating both 𝐶_𝑚,𝑎 and
𝐶_𝑚,𝑎. If 𝑦 is the SLoC added or modified for developing the simulator of 𝑚
for 𝑎, and 𝑦 is the SLoC added or modified for integrating the simulator of 𝑚 with
𝑎,
𝐶𝑚,𝑎 = 𝑘𝑦 + 𝑘𝑦 (15)
It is possible to use Equation (13), (14) and (15) for calculating 𝐶(𝑀,𝑎) in (10) and
use (11) to calculate 𝐶(𝑎) in (10).
Finally the calculated values for 𝐶𝑜𝑠𝑡𝑖𝑑𝑒𝑛𝑡𝑖𝑓𝑦(𝑀𝑙,𝑎𝑙), 𝐶𝑜𝑠𝑡𝑖𝑛𝑡(𝑀𝑙,𝑎𝑙) and
𝐶𝑜𝑠𝑡(𝑀,𝑎) can then be applied in Equation (1) to find 𝐶𝑜𝑠𝑡(𝑎).
Next, we introduce two formulas for assessing the adaptability of an existing Indus-
try 4.0 application to a change of a machine (the degree of adaptability) and the portability
of an existing Industry 4.0 application to a different environment (the degree of portabil-
ity).
4.2.4. Degree of Adaptability of an Industry 4.0 Application
The degree of adaptability of an application is formulated based on the cost of up-
dating an existing application to the change of machines and the cost of redeveloping the
same application to use with the changed machines. 𝐶(𝑎,𝑀) denotes the cost of de-
veloping an Industry 4.0 application 𝑎 by using the set of machines M.𝐶(𝑎,𝑀) de-
notes the cost of redeveloping 𝑎 using the set of machines 𝑀. If 𝑋 is the set of changed
or replaced machines in 𝑀 and 𝑌 is the set of replacements, the updated set of machines
𝑀 = {𝑀\ 𝑋} ∪ 𝑌 and |𝑋 | = |𝑌|. 𝐶(𝑎,𝑀) denotes the cost of updating 𝑎 to be
used with 𝑀. Based on these, the degree of adaptability of 𝑎, 𝐷𝐴(𝑎) is,
𝐷𝐴(𝑎)=1−(𝐶
(𝑎,𝑀)/𝐶(𝑎,𝑀)) (16)
If 𝐷𝐴(𝑎) is a high positive value, the application is easy to update and the cost of
updating the application is low compared to the cost of redeveloping the application and
Sensors 2021, 21, 6829 17 of 34
vice versa. 𝐶(𝑎,𝑀) can be calculated using (1) as the basis, considering the related
cost of identifying the machine data needed by the application from the changed ma-
chines, the cost of integrating them with the application, and the cost of doing any modi-
fication to the application code and testing the application. 𝐶(𝑎,𝑀) can also be cal-
culated using Equation (1) as the basis, considering the related cost of identifying the ma-
chine data needed by the application from 𝑀, the costs of data integration, and the cost
of application functionality development and testing.
4.2.5. Degree of portability of an Industry 4.0 application
We have adopted the formula proposed by Mooney [51] to measure the degree of
portability for evaluating the degree of portability of Industry 4.0 applications across en-
vironments. We denote an environment 𝑝, an example of which is a manufacturing plant
or even a combination of multiple plants an application uses. If 𝐶(𝑎,𝑝) denotes the
cost of developing an Industry 4.0 application 𝑎𝑙 for environment 𝑝, 𝐶(𝑎,𝑝) de-
notes the cost of redeveloping the same Industry 4.0 application for a new environment
𝑝 and 𝐶(𝑎,𝑝) denotes the cost of porting the existing application 𝑎𝑙 to 𝑝,
𝐷𝑃(𝑎) the degree of portability of 𝑎𝑙 is,
𝐷𝑃(𝑎)=1− (𝐶
(𝑎,𝑝)/ 𝐶(𝑎,𝑝)) (17)
If 𝐷𝑃(𝑎) is a high positive value, the application is highly portable and the cost of
porting the application is low compared to the cost of redeveloping the application and
vice versa. 𝐶
𝑝𝑜𝑟𝑡𝑎𝑙,𝑝2 can be calculated using Equation (1) as the basis, considering the
related cost of identifying the machine data needed by the application from the machines
in 𝑝, the cost of integrating them with the application, and the cost of doing any modifi-
cation to the application code and testing the application. 𝐶(𝑎,𝑀) can also be calcu-
lated using Equation (1) as the basis, considering the related cost of identifying the ma-
chine data needed by the application from 𝑀, the related data integration costs, and the
application functionality development and testing costs for 𝑝2.
Next, we present a case study from the dairy industry to exemplify CT-based Indus-
try 4.0 application development and to evaluate the CT-based Industry 4.0 application
development using the proposed cost model.
5. Experimental Evaluation of a CT-Based Industry 4.0 Application
Here we first explain the milk pickup process from the dairy industry that involves
milk tank and pickup truck machines and the milk pickup monitoring application. Next,
in Section 5.1 we present the related CT ontology-based models of the machines used in
the application. Section 5.2 presents the CTs generated for these machines and Section 5.3
discusses the CT-based milk pickup monitoring application development. Section 5.4 pre-
sents an evaluation that compares the costs of the development of this Industry 4.0 appli-
cation using CTs with the alternative of using an IoT platform. Section 5.5 discusses the
evaluation results.
In dairy farms, milk is collected by the farmers and stored in milk tanks until a pickup
truck arrives. When the pickup truck arrives at the milk farm, milk pickup begins, and the
pickup truck driver loads the milk from the tank to the pickup truck. After the milk load-
ing is completed, the pickup truck driver initiates the milk tank wash. Following the milk
tank wash, the milk tank reports the milk pickup as complete. An overview of this milk
pickup process, the roles that are responsible for each of the processing activity, and the
resources utilized by each activity are illustrated in Figure 8. The milk pickup monitoring
application enables milk processors (who produce products from milk) to monitor the
milk stored in tanks in an environment (e.g., a farm), including temperature and quantity,
and to receive milk pickup events from the milk tank to be able to make process planning
and forecasting decisions.
Sensors 2021, 21, 6829 18 of 34
Figure 8. The milk pickup process, activities, responsible roles, and utilized resources. The milk pickup process utilizes
milk tank and pickup truck machines as resources and the farmer and pickup truck driver are the responsible user roles.
Next, we present the CT ontology-based model of these machines.
5.1. CT Ontology-Based Models of the Pickup Truck and the Milk Tank Machines
As explained earlier in Section 3, CTs aim to support the development of Industry 4.0
applications that utilize industrial machines. A CT of an industrial machine includes the
corresponding sensors and actuators of the industrial machine, which are needed by the
application that the CT is designed to support. For example, here the CT of the pickup
truck machine in the use case is represented by the capture of the truck location data from
its GPS sensors and a few other aspects that are needed for the milk monitoring applica-
tion. However, note that the semantic representation of the Cyber Twin of the pickup
truck can be modelled to include additional onboard sensors (e.g., acceleration sensors,
airflow sensors, fuel sensors), actuators (e.g., fuel pump, control relays), and built-in au-
tomation (e.g., engine control unit) if these are required to support additional applications
(e.g., diagnostics and preventive maintenance).
The pickup truck machine has a GPS sensor connected to a Raspberry Pi Zero W and
communicates over the MQTT communication protocol. It produces the truck arrival
events based on GPS location data as the machine output. By using the CT ontology, the
pickup truck can be modelled as an instance of a Machine. The GPS sensor can be mod-
elled as a sosa:Sensor and the Raspberry Pi Zero W and the Raspbian operating system
can be modelled as a sosa:Platform and OperatingSystem, respectively. Moreover, the ma-
chine’s communication interface can be modelled as an Endpoint and the related commu-
nication protocol can be modelled as a CommunicationProtocol. The truck arrival event
can be modelled as a MachineOutput. Moreover, the machine has hardware identification
that can be described using the Datatype Property MachineId. Figure 9 depicts the ontol-
ogy model of a pickup truck with hardware identification “b8:22:eb:77:xx:xx”.
Sensors 2021, 21, 6829 19 of 34
Figure 9. CT ontology-based model of the pickup truck. The model includes a GPS sensor, a Raspberry PI hardware plat-
form, and a Raspbian operating system. The machine produces truck arrival events as machine outputs and has an end-
point that supports MQTT/TCP communication protocol.
A milk tank is a complex machine. It has multiple sensors observing milk tempera-
ture, milk quantity, and tank wash motor actions connected to Raspberry Pi zero W hard-
ware platform. Moreover, it has an automation program that observes the milk sensor
data, milk tank wash motor actions, and truck arrival events, and generates milk pickup
events. The machine also includes a built-in tank control that actuates the tank wash mo-
tor. The pickup event generator produces milk temperature, milk quantity, and pickup
events as machine outputs and consumes truck arrival events as machine inputs. Using
the CT ontology, a milk tank can be modelled as an instance of a Machine. Its sensors,
actuators, platform, and operating system can be modelled as sosa:Sensor, sosa:Actuator,
sosa:Platform, and OperatingSystem, respectively. The pickup event generator program
can be modelled as MachineAutomation and the milk tank’s built-in control system can
be modelled as an ssn:System. The tank control can be modelled as a MachineControl as
it actuates the tank wash motor based on its control logic implementation. Then it can be
connected to the milk tank machine as a subsystem via ssn:hasSubSystem object property.
Moreover, similar to the truck, the machine hardware identification for the milk tank can
be described using the DatatypeProperty MachineId. The milk tank model is depicted in
Figure 10 for a milk tank with hardware identification “b8:22:eb:33:xx:xx”.
Next, we present the CTs generated for the pickup truck and the milk tank using the
semantic description of the machines.
Sensors 2021, 21, 6829 20 of 34
Figure 10. CT ontology-based model of the milk tank. The model has milk temperature and milk quantity sensors, a tank
wash motor actuator, a pickup event generator machine automation, and built-in machine control that actuates the tank
wash motor actuator. The machine produces milk temperature, milk quantity, and pickup events as machine outputs and
consumes truck arrival events as machine inputs.
5.2. CTs of the Pickup Truck and the Milk Tank
The CTs of the machines incorporate CT descriptions as well as machine simulators.
Here we present the CT descriptions and the used machine simulators for the pickup truck
and the milk tank.
5.2.1. CT Descriptions of the Milk Tank and Pickup Truck Machines
The semantic descriptions of the CTs generated to support the integration of the
pickup truck machine and its data are depicted in Figure 11. The same descriptions for the
milk tank are depicted in Figure 12. Note that these are generated by the CT management
framework when it generates the CTs for these machines. The framework uses the ontol-
ogy concepts presented in Section 3.2. to generate these descriptions.
Sensors 2021, 21, 6829 21 of 34
Figure 11. Pickup truck CT description. The CT description includes the machine ID, emulator ID, the identification of the
Cyber Twin, the communication protocol, and the endpoint information provided by the CT to the application.
As depicted in Figure 10, the pickup truck CT has CT ID ct-1. It connects to the ma-
chine with machine ID “b8:22:eb:77:xx:xx” and an emulator with Id emu-7001. The milk
tank CT has CT ID ct-2 and connects to the milk tank machine with machine ID
“b8:22:eb:33:xx:xx”. The milk tank has a context associated with it. The context includes a
description of the farm and its longitude and latitude information. Moreover, both the
CTs support MQTT/TCP communication for machine data retrieval and sending. In the
provided MQTT interfaces, the topics published by the CTs and subscribed to by the CTs
are prefixed by the CT ID. They are in the format {CT-Id}/{MachineOutput}, {CT-ID}/{Ma-
chineInput} or {CT-ID}/{MachineSetting}. Moreover, the topics published by the emulator
and subscribed by the emulator are both prefixed by the CT ID as well as the term “emu”.
They are in the format {CT-ID}/emu/{MachineOutput}, {CT-ID}/emu/{MachineInput} or
{CT-ID}/emu/{MachineSetting}. This is a convention used by the CT management frame-
work for generating MQTT-based interfaces for CTs.
5.2.2. Machine Simulators of the Milk Tank and Pickup Truck
To support this use case, we have developed custom simulators for the milk tank and
the pickup truck. The CTs of the milk tank and the pickup truck each incorporate the
instances of their respective simulators to support application testing. The hardware spec-
ifications of the developed simulators are as follows. The milk pickup truck simulator:
QEMU-based Raspberry Pi hardware emulator proposed in [57] was used with configu-
rations CPU: ARM1176, RAM:256MB and the operating system Raspbian Jezzie-lite [58].
Moreover, it was customized by adding a GPS sensor simulator that communicated with
the Raspberry Pi hardware reflecting the 1-Wire communication protocol. The milk tank
simulator: QEMU-based Raspberry Pi hardware emulator proposed in [57] was used with
configurations CPU: ARM1176, RAM:256MB and the operating system Raspbian Jezzie-
lite [58]. Moreover, it was customized by adding three simulators including a temperature
sensor simulator, a quantity sensor simulator, and a tank control simulator that commu-
nicated with the Raspberry Pi hardware reflecting the 1-Wire communication protocol.
The milk tank simulator also had the pickup event generator program that accepts pickup
truck arrival events and generates the milk pickup events based on the data collected from
the milk quantity and tank control simulators. Docker images were then built for each of
the machine simulators by using Ubuntu 16.04.3 LTS as the base image. These simulator
Docker images were utilized to conduct the experiments in Section 5.4. During the CT
Sensors 2021, 21, 6829 22 of 34
generation, the instances of the corresponding simulators were deployed along with the
CTs.
Next, we describe the development of the milk pickup monitoring application using
CTs.
Figure 12. Milk tank CT description. The CT description includes the machine ID, the emulator ID, the identification of
the Cyber Twin, the context related to the Cyber Twin and the machine, the communication protocol, and the endpoint
information provided by the CT to the application.
5.3. CT-Based Milk Pickup Monitoring Application Development
Here we discuss the development activities involved in a) a new CT-based milk
pickup monitoring application, b) the updating of the CT-based milk pickup application
to a change of a pickup truck and c) the porting of the CT-based milk pickup application
to a different milk farm.
5.3.1. Developing a New CT-Based Milk Pickup Monitoring Application
The application developer needs to use the web-based interface (described in Section
3.2.) to find CTs and to query the machine descriptions of the milk tank and the pickup
truck. It allows the application of filter criteria to find the CTs as well as allowing the
querying of the CTs using SPARQL. As an example, to find the CT connecting to the
pickup truck machine described in Figure 11, the application developer can provide the
machine identification “b8:22:eb:77:xx:xx” as the filter criteria and then query the machine
description as required to identify the required machine data.
After identifying the machine data needed by the application, the application devel-
oper can integrate the CTs and the related data with the application by connecting to an
endpoint specified in the machine CT descriptions. As depicted in Figure 11 and Figure
12, the pickup truck CT, and the milk tank CT both provide MQTT-based endpoints to
connect to the machines and their corresponding emulators via the CTs. The pickup mon-
itoring application needs to receive truck arrival events from the pickup truck, and the
milk temperature, milk quantity, and milk pickup events from the milk tank. Therefore,
the application needs to subscribe to ct-1/ns:TruckArrivalEvent from ct-1 and ct-
2/ns:MilkTemperature, ct-2/ns:MilkQuantity and ct-2/ns:PickupEvent topics from ct-2.
Sensors 2021, 21, 6829 23 of 34
The credentials for connecting to the CT endpoints are given in the CT descriptions. Figure
13 depicts the source code extracted from a milk pickup monitoring application developed
using Android (Java). In the application, an existing MQTT library is used to integrate the
truck CT with the application. As shown in line 240 of the code snippet, after successfully
connecting to the truck CT, the application subscribes to the truck arrival event ct-
1/ns:TruckArrivalEvent published by the truck CT. Similarly, the application can integrate
the data from the milk tank CT.
Figure 13. Integrating the pickup truck data with the milk pickup monitoring application via pickup truck CT.
Then the application functionality needs to be developed and the application needs
to be tested. To test the application, the application developer can connect the application
to the machine emulators/simulators via their CTs. As an example, to connect to the
pickup truck’s emulator instead of the pickup truck the application only requires chang-
ing the subscribed topic from ct-1/ns:TruckArrivalEvent to ct-1/emu/ns:TruckArrivalEv-
ent. Line 112 of Figure 13 needs to be changed as depicted in line 240 of Figure 14. Simi-
larly, the application developer can switch between the milk tank and milk tank emulator
via the CT.
Figure 14. Using the pickup truck CT emulator for application testing.
5.3.2. Updating an Existing CT-Based Milk Pickup Monitoring Application
Updating the application to a change of the pickup truck can be completed by updat-
ing the CT of the old pickup truck (i.e., ct-1) to connect with the new pickup truck. If the
Sensors 2021, 21, 6829 24 of 34
new pickup truck produces similar data as the old pickup truck, the application code does
not need to be changed.
5.3.3. Porting the CT-Based Milk Pickup Monitoring Application to a Different Milk
Farm
If the pickup monitoring application is moved to a new farm, the application needs
to be integrated with the pickup truck and the milk tank CTs in the new farm. The new
farm has two CTs, ct-3 and ct-4, for the pickup truck and the milk tank, and they produce
similar data as the previous machines. Now the application code needs to be changed to
connect with the ct-3 and ct-4 instead of ct-1 and ct-2 via the respective interfaces provided
by ct-3 and ct-4.
5.4. Experimentally Evaluating CT-Based Industry 4.0 Application Development
We used the milk pickup monitoring application for our evaluation. We first mapped
the application to the cost model proposed in Section 4.2. Next, we provided an overview
of the experimental methodology. Then we presented the costs of a) developing a new
Industry 4.0 application, b) updating an existing Industry 4.0 application and c) porting
an existing Industry 4.0 application when using the CTs and (directly) using an existing
IoT platform. Microsoft Azure is a leading IoT platform [59] and allows the development
of Industrial solutions for Industry 4.0 [60]. Thus, we chose Azure IoT for our comparison.
The environment (𝑝) had a pickup truck (𝑚) and a milk tank (𝑚). The pickup truck
produces truck arrival events as machine output (𝑚𝑜
). It has a GPS sensor (𝑚𝑠
,) that
produces machine output (𝑚𝑜
). Milk tank (𝑚) produces milk temperature (𝑚𝑜
), milk
quantity (𝑚𝑜
), and pickup events (𝑚𝑜
) as machine outputs and accepts truck arrival
events (𝑚𝑖
) as machine inputs. It has a milk temperature sensor (𝑚𝑠
,) that produces
machine output (𝑚𝑜
), milk quantity sensor (𝑚𝑠
,) that produces machine output
(𝑚𝑜
), current sensor (𝑚𝑠
) for detecting tank wash motor actuation, machine automa-
tion pickup event generator (𝑚𝑐
) that produces machine output (𝑚𝑜
) and consumes
truck arrival event machine input (𝑚𝑖
), and tank built-in control system (𝑚𝑐
) that ac-
tuates tank wash motor actuator (𝑚𝑎
). These notations are summarized in Table 2.
Table 2. Summary of notations.
Notation Description
𝑝 Environment being monitored
𝑎 Pickup monitoring application
𝑚 Pickup truck
𝑚𝑜
Machine outputs of 𝑚
𝑚 Milk tank
𝑚𝑜
,𝑚𝑜
,𝑚𝑜
Machine outputs of 𝑚
𝑚𝑖
Machine input of 𝑚
𝑚𝑐
Pickup event generator machine automa-
tion of 𝑚
5.4.1. Experimental Setup and Methodology for Experiments
The CT-based application required the use of existing CTs of the machines that it
required or the generation of the required CTs if they did not exist. We first used the CT
management framework to generate any missing CT that was required by the application.
The CT management framework components resided in a Kubernetes cluster master node
with the configurations Ubuntu 20.04 LTS, RAM: 8GB, 4VCPUs and Disk size 30GB. The
Kubernetes cluster master node had two worker nodes registered with it each having con-
figurations Ubuntu 20.04, RAM: 8GB, 4VCPUs and Disk size 30GB which were used by
the CT management framework for deploying the CTs. Further details on CT generation
Sensors 2021, 21, 6829 25 of 34
and update processes are provided in [21]. The simulators described in Section 5.2.2 were
also integrated by the CT management framework as a part of the CT generation for each
of the CTs.
To compare the IoT platform-based and the CT-based Industry 4.0 implementations,
we created an Azure IoT Hub instance and used that to integrate the machine simulators
with the IoT platform. More specifically, in Industry 4.0 application, the pickup truck is
represented as a simple machine that only generates GPS location data. To simulate this,
we considered the Azure IoT -provided telemetry simulator [49] to generate device-sim-
ulated GPS data. On the other hand, in our application, the milk tank was a complex ma-
chine with machine automation. To simulate the milk tank machines we developed and
integrated a milk tank simulator with the IoT platform. Milk tank simulators were de-
ployed on a machine running Ubuntu 18.04 and with RAM size 8GB.
Next, we developed IoT platform-based and CT-based versions of the milk pickup
monitoring application 𝑎 using the Python flask web application development frame-
work. The user interfaces of these were developed using HTML. To minimize the impact
on the final cost calculations from factors that did not specifically depend on these alter-
native implementations of 𝑎, we used the same user interfaces and the same data read-
ing and writing mechanisms in the development of the IoT platform and the CT-based
versions of 𝑎.
5.4.2. Estimating the Costs of New Industry 4.0 Application Development
Developing 𝑎 requires the identification of the data required by 𝑎 from 𝑚 and
𝑚, including 𝑚𝑜
of 𝑚 and 𝑚𝑜
,𝑚𝑜
,𝑚𝑜
and 𝑚𝑖
of 𝑚. It then requires the inte-
gration of these with 𝑎. Using 𝑚 and 𝑚 to develop 𝑎 requires coding the applica-
tion functionality and testing it. To test 𝑎 it is necessary to simulate 𝑚 and 𝑚. 𝑚 is
a simple machine with a single sensor 𝑚𝑠
,. Therefore, it only requires the simulation of
the sensor data and integrating it with 𝑎. The 𝑚 is a complex machine with machine
automation 𝑚𝑐
. The 𝑎 interacts with 𝑚𝑐
and it is required to simulate/emulate 𝑚
including 𝑚𝑐
to support application testing. We calculated the application development
cost by using Equation (1) as the basis. The assumptions made in the evaluation were:
• When developing the CT-based application we assumed that 𝑚 and 𝑚 were al-
ready integrated with their CTs. Therefore, the CT generation cost was not consid-
ered in the calculation of application development cost;
• In Azure IoT we assumed 𝑚 and 𝑚 were already integrated with the Azure IoT
platform via the Azure IoT Hub [61]. Therefore, the cost of integration with the IoT
platform was not considered in the calculation of the application development cost.
Moreover, we assumed that 𝑚 and 𝑚 had sufficient and accurate machine de-
scriptions associated with them that could be directly used by the application devel-
oper.
Next, we developed 𝑎1 using the CTs of 𝑚 and 𝑚. Then we also developed 𝑎1
using Azure IoT and integrated 𝑚 and 𝑚 and their data with the application via the
IoT Hub endpoint. Table 3 summarizes the cost of application development using Azure
IoT (first row) and CTs (second row). It shows the NoQs executed and the NoCs applied
for identifying the data required from 𝑚 and 𝑚, SloC added or modified and NoCs
applied for integrating 𝑚 and 𝑚 and the related data with the application and NoCs
applied and SloC added or modified for developing and testing 𝑎1. Equations (2), (6), and
(10) proposed in Section 4.2 were used as the bases for calculating these values. In our
calculations, we considered the values k1, k2, and k3 introduced in Equations (5) and (9) to
be the same with an average value of USD 18.00 [62].
Table 3. Cost of developing the pickup monitoring applications using the IoT platform and CTs.
Sensors 2021, 21, 6829 26 of 34
Industry
4.0 Ap-
plication
Identify
(NoQ)
Identify
(NoC) Integrate
(NoC)
Integrate
(SloC)
Dev and
Test
(NoC)
Dev and
Test
(SloC)
Total
Cost
($)
IoT plat-
form 0 2 4 42 2 159 3762.00
CTs 0 2 3 32 0 112 2682.00
Moreover, we next considered the following scenario to estimate the application de-
velopment cost when the number of machines that needed to be utilized by 𝑎 changed.
Consider a scenario where 𝑎 needs to monitor milk pickups in a set of milk farms in a
region where each milk farm has a single milk tank with a ten thousand litres capacity
and each pickup truck has a capacity of twenty thousand litres and makes five pickup
trips per day. We estimated the application development cost when 𝑎 is developed for
an environment having 𝑛 milk tanks and 𝑛/10 pickup trucks for collecting milk, for
𝑛 = 20, 𝑛 = 40, 𝑛 = 60, 𝑛 = 80, 𝑛 = 100. Table 4 and Table 5 summarizes the cost esti-
mates for Azure IoT and CTs, respectively. For each application that uses Azure IoT and
CTs, the total cost was estimated as the summations of the cost of identifying the machine
data, integrating the machines and the related data, and developing the application func-
tionality and testing the application. The cost estimations for each of the application de-
velopment activities were completed based on the results summarized in Table 3 and
based on the Equations (2), (6) and (10) presented in Section 4.2. The line graph in Figure
15 further illustrates the related cost values.
Table 4. Cost of developing the pickup monitoring application (directly) using IoT platform and
the number of machines used by the application.
Number of
Milk Tanks
Number of
Milk Trucks
Cost of
Identifying
Cost of
Integration
Cost of
Dev and Test
Total Cost
($)
20 2 396.00 2286.00 4050.00 6732.00
40 4 792.00 3402.00 5202.00 9396.00
60 6 1188.00 4518.00 6354.00 12060.00
80 8 1584.00 5634.00 7506.00 14724.00
100 10 1980.00 6750.00 8658.00 17388.00
Table 5. Cost of developing the CT-based pickup monitoring application and the number of ma-
chines used by the application.
Number of
Milk Tanks
Number of
Milk Trucks
Cost of
Identifying
Cost of
Integration
Cost of
Dev and Test
Total Cost
($)
20 2 396.00 1332.00 2016.00 3744.00
40 4 792.00 2088.00 2016.00 4896.00
60 6 1188.00 2844.00 2016.00 6048.00
80 8 1584.00 3600.00 2016.00 7206.00
100 10 1980.00 4356.00 2016.00 8352.00
Sensors 2021, 21, 6829 27 of 34
Figure 15. The new milk pickup monitoring application development cost and the number of ma-
chines used by the application.
5.4.3. Estimating the Costs of Industry 4.0 Application Update
To evaluate the cost of updating an application, we considered a scenario where 𝑚
changed and 𝑎1 needed to be integrated for a new pickup truck (𝑚). We considered
that the models of both 𝑚 𝑎𝑛𝑑 𝑚 were similar and provided similar machine outputs.
The application update required the identification of data from 𝑚 (𝑚𝑜
) and the inte-
gration of 𝑚 and 𝑚𝑜
with the 𝑎1. Equation (16) proposed in Section 4.2.4 was used to
calculate the degree of adaptability of 𝑎1. The assumptions made in the evaluation were:
• When updating 𝑎1 to use 𝑚, we assumed that the CT of 𝑚 was updated to con-
nect with 𝑚 without generating a new CT for 𝑚;
• When updating the application using Azure, we assumed that 𝑚 was already inte-
grated with the same IoT Hub instance as 𝑚 and had a different device id.
Table 6 summarizes the cost of updating 𝑎1that used Azure IoT (first row) and CTs
(second row), respectively. It shows the NoQs executed and the NoCs applied for identi-
fying data from 𝑚, SloC added or modified, the NoCs applied for integrating 𝑚 and
its data with 𝑎, and the NoCs applied and SloC added or modified for developing 𝑎
functionality and testing 𝑎. The final column summarizes the total cost of updating the
application. Moreover, Figure 16a further illustrates the degree of adaptability of the two
applications that were calculated using Equation (16).
Table 6. Cost of updating the pickup monitoring application using the IoT platform and CTs.
Industry 4.0
Application
Identify
(NoQ)
Identify
(NoC)
Integra-
tion (NoC)
Integration
(SloC)
Dev and
Test
(NoC)
Dev and
Test
(SloC)
Total
Cost
($)
IoT platform 0 1 0 2 3 0 90.00
CTs 0 1 1 0 0 0 36.00
Moreover, we next considered the following scenario to estimate the degree of adapt-
ability of the pickup monitoring application with the number of changed/replaced ma-
chines when the application monitors an environment with hundred milk tanks and uses
ten pickup trucks for collecting milk. We measured the degree of adaptability of the ap-
plication when 𝑞 machines out of the total 110 machines are changed/replaced, for 𝑞 =
22, 𝑞 = 44, 𝑞 = 66, 𝑞 = 88, 𝑞 = 110. At each instance, we kept the number of changed milk
tanks to the number of changed milk trucks ratio at 10:1. Table 7 (relating to Azure IoT)
and Table 8 (relating to CTs) shows the costs involved in updating the pickup monitoring
2000
4000
6000
8000
10000
12000
14000
16000
18000
22 44 66 88 110
Total cost of new application
development ($)
Number of machines used by the application
Using IoT platform Using CTs
Sensors 2021, 21, 6829 28 of 34
application when it utilizes 110 machines and some of them are changed or replaced. The
cost estimations were completed based on the results summarized in Table 6 and the final
column of Table 7 and Table 8 shows the degree of adaptability of the resulting application
that was calculated using Equation (16). Figure 16b further illustrate the cost of updating
the application and Figure 16c illustrates the degree of adaptability of the application with
the number of changed machines.
Table 7. Degree of adaptability of the pickup monitoring application developed using the IoT plat-
form with the changed number of machines.
Changed Machines/Total
No. of Machines
Cost of
Updating
Cost of
Redev.
Degree of Adaptabil-
ity
22/110 2736.00 17,388.00 0.8426
44/110 5472.00 17
,
388.00 0.6853
66/110 8208.00 17,388.00 0.5279
88/110 10,944.00 17,388.00 0.3706
110/110 13,680.00 17,388.00 0.2133
Table 8. Degree of adaptability of the CT-based pickup monitoring application with the changed
number of machines.
Changed Machines/Total
No. of Machines
Cost of
Updating
Cost of
Redev.
Degree of
Adaptability
22/110 792.00 8352.00 0.9052
44 /110 1584.00 8352.00 0.8103
66/110 2376.00 8352.00 0.7156
88/110 3168.00 8352.00 0.6207
110/110 3960.00 8352.00 0.5259
Figure 16. The milk pickup monitoring application: (a) Degree of adaptability of the application when using a single
pickup truck and a milk tank; (b) Application update cost with the changed number of machines (c) Degree of the adapt-
ability of the application with the changed number of machines.
5.4.4. Estimating the Costs of Industry 4.0 Application Porting
To evaluate the portability of 𝑎1 we considered a scenario where the 𝑎1 was ported
to a new environment (𝑝) with a different milk tank (𝑚) and a pickup truck (𝑚). We
Sensors 2021, 21, 6829 29 of 34
considered the case where the models of 𝑚 and 𝑚 were similar to 𝑚 and 𝑚 in 𝑝,
and produced similar machine outputs and accepted similar machine inputs. The degree
of portability was calculated based on Equation (17) presented in Section 4.2.5. The as-
sumptions made in the evaluation were:
• When porting 𝑎1that uses CTs to 𝑝 we assumed that CTs were available for 𝑚
and 𝑚;
• When porting 𝑎1 using Azure IoT, we assumed 𝑚 and 𝑚 connected to a differ-
ent IoT Hub and had different device ids, and they were already connected with the
IoT Hub.
Table 9 summarizes the cost of porting 𝑎1 that use Azure IoT and CTs. It shows the
NoQs executed and the NoCs applied for identifying data from 𝑚4 and 𝑚5, SloC added
or modified and NoCs applied for integrating 𝑚4 and 𝑚5 and their data with 𝑎1 and
NoCs applied and SloC added or modified for developing the functionality and testing of
𝑎1. The final column summarizes the total cost of porting 𝑎1. Moreover, Figure 17a further
illustrates the degree of portability of the two applications.
Table 9. Cost of porting the pickup monitoring applications using the IoT platform and CTs.
Industry
4.0 Appli-
cation
Identify
(NoQ)
Identify
(NoC)
Integration
(NoC)
Integration
(SLoC)
Dev and
Test
(NoC)
Dev and
Test
(SLoC)
Total
Cost
($)
Azure IoT 0 2 4 3 2 4 270.00
CTs 0 2 3 0 0 0 90.00
Moreover, we next considered the following scenario to estimate the degree of port-
ability of the pickup monitoring application 𝑎1with the number of machines (i.e., milk
tanks and milk trucks) utilized by the application. The degree of portability of the appli-
cation was measured when the application needs to be ported from 𝑝 to 𝑝 where 𝑝
and 𝑝 each is having 𝑛 milk tanks and 𝑛/10 pickup trucks, for 𝑛 = 20, 𝑛 = 40, 𝑛 =
60, 𝑛 = 80, 𝑛 = 100. The cost estimates were completed based on the results summarized
in Table 9 and Table 10 (relating to Azure IoT) and Table 11 (relating to CTs) summarizes
the estimated costs involved in porting 𝑎1when the number of machines in the environ-
ment that is used by the application changes from 22 to 110. The final column of both
tables shows the resulting degree of portability of the applications that were calculated
based on Equation (17). Figure 17b further illustrates the cost of porting the CT-based ap-
plication and the application developed using Azure IoT. Figure 17c further illustrates the
change in the degree of portability.
Table 10. The degree of portability of the pickup monitoring application developed by (directly)
using the IoT platform and the number of machines in the environment.
No. of Machines Cost of Porting Cost of Redev. Degree of Portability
22 2358.00 6732.00 0.6497
44 4662.00 9396.00 0.5039
66 6966.00 12,060.00 0.4224
88 9270.00 14,724.00 0.3704
110 11
,
574.00 17
,
388.00 0.3344
Table 11. The degree of portability of the CT-based pickup monitoring application and the num-
ber of machines in the environment.
No. of Machines Cost of Porting Cost of Redev. Degree of Portability
22 1152.00 3744.00 0.6923
44 2304.00 4896.00 0.5294
Sensors 2021, 21, 6829 30 of 34
66 3456.00 6048.00 0.4256
88 4608.00 7200.00 0.3600
110 5760.00 8352.00 0.3103
Figure 17. The milk pickup monitoring application, (a) Degree of portability of application for an environment with a
single milk tank and a pickup truck; (b) Application porting cost with the number of machines used by the application,
(c) Degree of portability of the application with the number of machines used by the application.
5.5. Discussion
Figure 15 illustrates the application development costs using Azure IoT and CTs with
the number of machines used by the application. The application development cost shows
a gradual incremental increase in the CT-based approach with the increase in the number
of machines used. However, the cost of (directly) using Azure IoT is high when compared
to using CTs. This is because Azure requires additional effort to integrate the milk tank
emulator with the IoT platform to support application testing. This can be also seen in
Table 3, as the effort of developing and testing the application that uses Azure IoT is rela-
tively high (SLoC 159) when compared to the application that uses CTs (SLoC 112). More-
over, it can be observed that there is a sharp increase in the cost of development using
Azure IoT compared to using CTs. Moreover, in these instances, the CT-based application
development cost is approximately 60% or less than the IoT platform-based Industry 4.0
application development cost. Hence, we can conclude that using CTs to develop the
pickup monitoring application is more cost-efficient.
The results presented in Figure 16a show the degree of adaptability of the pickup
monitoring application developed using the Azure IoT and CTs for an environment with
a single pickup truck and a milk tank. The application that utilizes CTs has a higher degree
of adaptability when compared to the application that uses the Azure IoT. This is because
CT offers increased adaptability when the corresponding physical machine is changed.
This reduces the integration cost of the new machine, and it is primarily achieved by up-
dating the CT. However, the application that uses the IoT platform requires the integra-
tion of the new machine and its data with the application. Figure 16b shows the applica-
tion update cost using Azure IoT and CTs with a changed number of machines. As shown
in the figure, updating an application is less costly than developing a new application in
both Azure IoT and when using CTs. However, the application update cost is high when
using the Azure IoT platform compared to using CTs. The results presented in Figure 16c
compares the degree of adaptability of the pickup monitoring application that utilizes 100
milk tanks and 10 milk trucks when some of the machines used by the application are
Sensors 2021, 21, 6829 31 of 34
changed. In the figure, it can be seen that the applications that use CTs are more adaptable
to change of machines when compared to the application that uses the IoT platform. In
summary, the application that uses CTs offers a higher degree of adaptability, and the
update cost of CT-based applications is less.
The results presented in Figure 17a show the degree of portability of the pickup mon-
itoring application developed using the Azure IoT and CTs for an environment with a
single milk tank and a pickup truck. The application that utilizes the CTs has a higher
degree of portability when compared to the application that uses the IoT platform. The
results presented in Figure 17b compares the cost of porting the application that uses Az-
ure IoT and CTs with the number of machines used by the application. As shown in the
figure, the cost is less with CTs. The results presented in Figure 17c compare the degree
of portability of the pickup monitoring application when the number of machines used
by the application is increased starting from 20 milk tanks and 2 pickup trucks up to 100
milk tanks and 10 pickup trucks. The application that uses CTs and Azure seems to have
a similar degree of portability. However, the porting cost and redevelopment cost of an
application that uses CTs is less when compared to the cost of porting an application that
uses Azure IoT. Thus, the porting cost of CT-based Industry 4.0 application is less com-
pared to the IoT platform-based application. In summary, it can be concluded that the CT-
based Industry 4.0 application development, update and porting is more cost-efficient
when compared to using an IoT platform.
6. Conclusion and Future Research
In this paper, we proposed CTs for CT-based Industry 4.0 application development
and introduced a novel cost model for estimating the cost of developing Industry 4.0 ap-
plications. We also presented an experimental evaluation of CT-based Industry 4.0 appli-
cation using a case study from the dairy industry that illustrated the benefits of CT-based
Industry 4.0 application development in comparison with traditional IoT platform-based
application development. In this evaluation, we considered all aspects of the application
development lifecycle including the development of a new Industry 4.0 application, the
updating of an existing Industry 4.0 application to a change of a machine and porting an
existing Industry 4.0 application to a different set of machines (e.g., deployment to a new
plant). We used the proposed cost model to compare the application development costs
for each application development scenario when using the CTs and (directly) using an IoT
platform. This evaluation showed that CT-based application development is less costly
than the IoT platform-based alternative when the same CTs are used to develop multiple
Industry 4.0 applications, which is normally the case in all industry settings that require
efficiency, preventive maintenance, and product consistency management and improve-
ment.
In our future work, we aim to extend our experimental analysis to include a statistics-
based approach to validate the significant improvement in cost of developing the Industry
4.0 application and the degree of adaptability of the Industry 4.0 application using the
proposed CTs-based approach compared to IoT platform-based approaches. We also aim
to extend the CTs, the CT management framework and the cost model to support complex
machines which incorporate automation that determines the machine actuation and the
data that the machine will generate based on the automation. In particular, we aim to
explore CT model extensions that are symbiotic to the automation in complex machines.
Author Contributions: Conceptualization, D.B.;D.G.;A.B.; and P.P.J.; writing—original draft prep-
aration, D.B.;D.G.;A.B.; and P.P.J.; writing—review and editing, D.B.;D.G.;A.B.; and P.P.J.; supervi-
sion, D.G.;A.B.; and P.P.J. All authors have read and agreed to the published version of the manu-
script.
Funding: This work has been partially funded by “Live Inbound Milk Supply Chain Monitoring
and Logistics for Productivity and Competitiveness”, a Cooperative Research Centres Project (CRC-
P) with Bega Cheese, Optus and Software AG., grant number CRCPSEVEN000137.
Sensors 2021, 21, 6829 32 of 34
Institutional Review Board Statement: Not applicable.
Informed Consent Statement: Not applicable.
Data Availability Statement: Not applicable.
Conflicts of Interest: The authors declare no conflict of interest.
References
1. Georgakopoulos, D.; Fazia, M.; Villari, M.; Rajiv, R. Internet of Things and Edge Cloud Computing Roadmap for Manufacturing.
IEEE Cloud Comput. 2016, 3, 66–73, doi:10.1109/MCC.2016.91.
2. Ranjan, R.; Hsu, C.H.; Chen, L.Y.; Georgakopoulos, D. Holistic Technologies for Managing Internet of Things Services. IEEE
Trans. Serv. Comput. 2020, 13, 597–601, doi:10.1109/TSC.2020.3000844.
3. Milojevic, M. Digital Industrial Transformation with the Internet of Things; CXP Group: Glasgow, UK, April 2017.
4. Zhang, L.; Schultz, M.A.; Cash, R.; Barrett, D.M.; McCarthy, M.J. Determination of quality parameters of tomato paste using
guided microwave spectroscopy. Food control 2014, 40, 214–223.
5. Montori, F.; Liao, K.; Jayaraman, P.P.; Bononi, L.; Sellis, T.; Georgakopoulos, D. Classification and Annotation of Open Internet
of Things Datastreams. In proceedings of the International Conference on Web Information Systems Engineering, Dubai, United
Arab Emirates 12–15 November 2018; pp.209–224.
6. Madithiyagasthenna, D.; Jayaraman, P.P.; Morshed, A.; Forkan, A.R.M.; Georgakopoulos, D.; Kang, Y.B.; Piechowski, M. A
solution for annotating sensor data streams-An industrial use case in building management system. In Proceedings of the 2020
21st IEEE International Conference on Mobile Data Management (MDM), Versailles, France, 30 June–3 July 2020; pp.194–201.
7. Bamunuarachchi, D.; Banerjee, A.; Jayaraman, P.P.; Georgakopoulos, D. Cyber Twins Supporting Industry 4.0 Application De-
velopment. In Proceedings of the The 18th International Conference on Advances in Mobile Computing and Multimedia
(MoMM ’20), Chiang Mai, Thailand, 30 November–2 December 2020; pp.64–73.
8. Microsoft. Tutorial: Build out an end-to-end solution. Available online: https://docs.microsoft.com/en-us/azure/digital-
twins/tutorial-end-to-end (accessed on 19 April 2021).
9. Microsoft. Azure IoT device simulation. Available online: https://azure.microsoft.com/en-au/resources/videos/azure-iot-device-
simulation/ (accessed on 8 July 2021).
10. Fuller, A.; Fan, Z.; Day, C.; Barlow, C. Digital Twin: Enabling Technologies, Challenges and Open Research. IEEE Access 2020,
8, 108952–108971, doi:10.1109/ACCESS.2020.2998358.
11. Sepasgozar, S.M.E. Differentiating Digital Twin from Digital Shadow: Elucidating a Paradigm Shift to Expedite a Smart, Sus-
tainable Built Environment. Buildings 2021, 11, 151.
12. Schleich, B.; Anwer, N.; Mathieu, L.; Wartzack, S. Shaping the digital twin for design and production engineering. CIRP Annals
2017, 66, 141–144, doi:https://doi.org/10.1016/j.cirp.2017.04.040.
13. Tao, F.; Zhang, H.; Liu, A.; Nee, A.Y.C. Digital Twin in Industry: State-of-the-Art. IEEE Trans. Industr. Inform. 2019, 15, 2405–
2415, doi:10.1109/TII.2018.2873186.
14. Negri, E.; Berardi, S.; Fumagalli, L.; Macchi, M. MES-integrated digital twin frameworks. J. Manuf. Syst. 2020, 56, 58–71,
doi:https://doi.org/10.1016/j.jmsy.2020.05.007.
15. Chhetri, S.R.; Faezi, S.; Canedo, A.; Faruque, M.A.A. QUILT: Quality Inference from Living Digital Twins in IoT–Enabled Man-
ufacturing Systems. IoTDI '19 2019, 237–248, doi:10.1145/3302505.3310085.
16. Qiao, Q.; Wang, J.; Ye, L.; Gao, R.X. Digital Twin for Machining Tool Condition Prediction. Procedia CIRP 2019, 81, 1388–1393,
doi:https://doi.org/10.1016/j.procir.2019.04.049.
17. Liu, C.; Vengayil, H.; Zhong, R.Y.; Xu, X. A systematic development method for cyber-physical machine tools. J. Manuf. Syst.
2018, 48, 13–24, doi:https://doi.org/10.1016/j.jmsy.2018.02.001.
18. Mourtzis, D.; Vlachou, E. A cloud-based cyber-physical system for adaptive shop-floor scheduling and condition-based mainte-
nance. J. Manuf. Syst. 2018, 47, 179–198, doi:https://doi.org/10.1016/j.jmsy.2018.05.008.
19. Wang, J.; Ye, L.; Gao, R.X.; Li, C.; Zhang, L. Digital Twin for rotating machinery fault diagnosis in smart manufacturing. Int. J.
Prod. Res. 2019, 57, 3920-3934, doi:10.1080/00207543.2018.1552032.
20. Vachalek, J.; Bartalsky, L.; Rovny, O.; Sismisova, D.; Morhac, M.; Loksik, M. The digital twin of an industrial production line
within the industry 4.0 concept. In Proceedings of the 2017 21st International Conference on Process Control, Strbske Pleso,
Slovakia, 6–9 June 2017; pp.258–262.
21. Bamunuarachchi, D.; Georgakopoulos, D.; Jayaraman, P.P.; Banerjee, A. A Framework for Enabling Cyber-Twins based Indus-
try 4.0 Application Development (In press). In Proceedings of the 2021 IEEE International Conference on Services Computing
(SCC) (Online), 5–11 September 2021; pp.64–73.
22. Juarez, M.G.; Botti, V.J.; Giret, A.S. Digital Twins: Review and Challenges. J. Comput. Inf. Sci. Eng. 2021, 21, 030802,
doi:10.1115/1.4050244.
23. Ladj, A.; Wang, Z.; Meski, O.; Belkadi, F.; Ritou, M.; Da Cunha, C. A knowledge-based Digital Shadow for machining industry
in a Digital Twin perspective. J. Manuf. Syst. 2021, 58, 168–179, doi:https://doi.org/10.1016/j.jmsy.2020.07.018.
24. Schuh, G.; Jussen, P.; Harland, T. The Digital Shadow of Services: A Reference Model for Comprehensive Data Collection in
MRO Services of Machine Manufacturers. Procedia CIRP 2018, 73, 271–277, doi:https://doi.org/10.1016/j.procir.2018.03.318.
Sensors 2021, 21, 6829 33 of 34
25. Schuh, G.; Kelzenberg, C.; Wiese, J.; Ochel, T. Data Structure of the Digital Shadow for Systematic Knowledge Management
Systems in Single and Small Batch Production. Procedia CIRP 2019, 84, 1094–1100,
doi:https://doi.org/10.1016/j.procir.2019.04.210.
26. Riesener, M.; Schuh, G.; Dölle, C.; Tönnes, C. The Digital Shadow as Enabler for Data Analytics in Product Life Cycle Manage-
ment. Procedia CIRP 2019, 80, 729–734, doi:https://doi.org/10.1016/j.procir.2019.01.083.
27. Barthelmey, A.; Lee, E.; Hana, R.; Deuse, J. Dynamic digital twin for predictive maintenance in flexible production systems. In
Proceedings of the IECON 2019-45th Annual Conference of the IEEE Industrial Electronics Society, Lisbon, Portugal, 14–17
October 2019; pp.4209–4214.
28. J, L.; D, Y.; X, B.; Y, H.; H, Y.; B, L. The Research of Ontology-based Digital Twin Machine Tool Modeling. In Proceedings of the
2020 IEEE 6th International Conference on Computer and Communications (ICCC), Chengdu, China, 11–14 December 2020,
2020; pp.2130–2134.
29. Schroeder, G.N.; Steinmetz, C.; Pereira, C.E.; Espindola, D.B. Digital Twin Data Modeling with AutomationML and a Commu-
nication Methodology for Data Exchange. IFAC-PapersOnLine 2016, 49, 12–17, doi:https://doi.org/10.1016/j.ifacol.2016.11.115.
30. Hoebert, T.; Lepuschitz, W.; List, E.; Merdan, M. Cloud-Based Digital Twin for Industrial Robotics. In Proceedings of the Inter-
national Conference on Industrial Applications of Holonic and Multi-Agent Systems, Linz, Austria, 26–29 August 2019; pp.
105–116.
31. Lu, Y.; Xu, X. Resource virtualization: A core technology for developing cyber-physical production systems. J. Manuf. Syst. 2018,
47, 128–140, doi:https://doi.org/10.1016/j.jmsy.2018.05.003.
32. Vachálek, J.; Bartalský, L.; Rovný, O.; Šišmišová, D.; Morháč, M.; Lokšík, M. The digital twin of an industrial production line
within the industry 4.0 concept. In Proceedings of the 2017 21st International Conference on Process Control (PC), Štrbské Pleso,
Slovakia, 6-9 June; pp.258-262.
33. Cai, Y.; Starly, B.; Cohen, P.; Lee, Y.-S. Sensor Data and Information Fusion to Construct Digital-twins Virtual Machine Tools
for Cyber-physical Manufacturing. Procedia Manuf. 2017, 10, 1031–1042, doi:https://doi.org/10.1016/j.promfg.2017.07.094.
34. GE. Predix Platform. Available online: https://www.ge.com/digital/iiot-platform (accessed on April. 04 2021).
35. Siemens, M. MindSphere. Available online: https://siemens.mindsphere.io/en (accessed on 15 June 2021).
36. Ditto™, E. Eclipse Ditto. Available online: https://www.eclipse.org/ditto/ (accessed on 4 April 2021).
37. LLC, S. The Open Platform for the Internet of Things™. Available online: https://sitewhere.io/en/ (accessed on 15 June 2021).
38. Microsoft. Azure IoT. Available online: https://azure.microsoft.com/en-us/overview/iot/ (accessed on August. 22 2020).
39. GmbH, C. Sensor library–Cumulocity IoT Guides. Available online: https://cumulocity.com/guides/reference/sensor-library/
(accessed on 10 August 2020).
40. Hussain, I.; Park, S.J. HealthSOS: Real-Time Health Monitoring System for Stroke Prognostics. IEEE Access 2020, 8, 213574–
213586, doi:10.1109/ACCESS.2020.3040437.
41. Hussain, I.; Park, S.J. Big-ECG: Cardiographic Predictive Cyber-Physical System for Stroke Management. IEEE Access 2021, 9,
123146–123164, doi:10.1109/ACCESS.2021.3109806.
42. Dawod, A.; Georgakopoulos, D.; Jayaraman, P.P.; Nirmalathas, A. An IoT-owned Service for Global IoT Device Discovery,
Integration and (Re)use. In Proceedings of the 2020 IEEE International Conference on Services Computing (SCC), Beijing, China,
7–11 November 2020; pp.312–320.
43. Soldatos, J.; Kefalakis, N.; Hauswirth, M.; Serrano, M.; Calbimonte, J.-P.; Riahi, M.; Aberer, K.; Jayaraman, P.P.; Zaslavsky, A.;
Žarko, I.P.; et al. OpenIoT: Open Source Internet–of–Things in the Cloud. In Proceedings of the Interoperability and Open-
Source Solutions for the Internet of Things, Split, Croatia, September 18 2014; pp. 13–25.
44. Compton, M.; Barnaghi, P.; Bermudez, L.; García-Castro, R.; Corcho, O.; Cox, S.; Graybeal, J.; Hauswirth, M.; Henson, C.; Her-
zog, A.; et al. The SSN ontology of the W3C semantic sensor network incubator group. J. Web Semant
.
2012, 17, 25–32,
doi:https://doi.org/10.1016/j.websem.2012.05.003.
45. Datta, S.K.; Bonnet, C. Easing IoT application development through DataTweet framework. In Proceedings of the 2016 IEEE
3rd World Forum on Internet of Things (WF-IoT), Reston, VA, USA, 12–14 December 2016; pp.430–435.
46. Cirillo, F.; Solmaz, G.; Berz, E.L.; Bauer, M.; Cheng, B.; Kovacs, E. A Standard-based Open Source IoT Platform: FIWARE. IEEE
Internet Things Mag.2020, 3, 12–18, doi:10.1109/IOTM.0001.1800022.
47. Foundation, F. SMART DATA MODELS. Available online: https://www.fiware.org/developers/smart-data-models/ (accessed
on 15 June 2021).
48. Kim, M.; Lee, J.; Jeong, J. Open Source Based Industrial IoT Platforms for Smart Factory: Concept, Comparison and Challenges.
In Proceedings of the Computational Science and Its Applications-ICCSA 2019, Saint Petersburg, Russia, 1–4 July 2019; pp.105–
120.
49. Microsoft. Azure IoT Device Telemetry Simulator. Available online: https://docs.microsoft.com/en-us/samples/azure-sam-
ples/iot-telemetry-simulator/azure-iot-device-telemetry-simulator/ (accessed on 14 June 2021).
50. Boehm, B.; Clark, B.; Horowitz, E.; Westland, C.; Madachy, R.; Selby, R. Cost models for future software life cycle processes:
COCOMO 2.0. J. Softw. Eng.1995, 1, 57–94.
51. Mooney, J.D. Issues in the specification and measurement of software portability. In Proceedings of the 15th International Con-
ference on Software Engineering, Baltimore, MD, USA, 17–21 May 1993.
52. Devanbu, P.; Karstu, S.; Melo, W.; Thomas, W. Analytical and empirical evaluation of software reuse metrics. In Proceedings of
the Proceedings of the 18th international conference on Software engineering, Berlin, Germany, 25–29 March 1996; pp.189–199.
Sensors 2021, 21, 6829 34 of 34
53. Janowicz, K.; Haller, A.; Cox, S.J.D.; Phuoc, D.L.; Lefrançois, M.J.J.W.S. SOSA: A lightweight ontology for sensors, observations,
samples, and actuators. J. Web Semant. 2019, 56, 1–10.
54. Musen, M.A. The protégé project: a look back and a look forward. AI matters 2015, 1, 4–12.
55. All3DP. All3DP. Available online: https://all3dp.com/2/cnc-simulator-online-software/ (accessed on 18 September 2021).
56. Corporation, F.A. FANUC. Available online: https://www.fanucamerica.com/products/cnc/fanuc-simulators/cnc-machine-sim-
ulation-software (accessed on 18 September 2021).
57. Platt, E.R. Virtual peripheral interfaces in emulated embedded computer systems. Thesis, The university of Texas at Austin,
Austin, TX, USA, December 2016.
58. Index of /pub/raspberrypi/raspbian_lite/images/raspbian_lite-2017-07-05. Available online: http://ftp.jaist.ac.jp/pub/raspber-
rypi/raspbian_lite/images/raspbian_lite-2017-07-05/ (accessed on 12 September 2021).
59. Gartner, I. Magic Quadrant for Industrial IoT Platforms. Available online: https://www.gartner.com/doc/reprints?id=1-
2434LPHV&ct=200903&st=sb (accessed on 18 August 2021).
60. Microsoft. Azure Industrial IoT. Available online: https://azure.microsoft.com/en-us/solutions/industry/manufacturing/iot/ (ac-
cessed on 18 August 2021).
61. Microsoft. Read device-to-cloud messages from the built-in endpoint. Available online: https://docs.microsoft.com/en-us/az-
ure/iot-hub/iot-hub-devguide-messages-read-builtin (accessed on 15 June 2021).
62. Pedersen, P. The Open Source Community as a Top 100 Country. Available online: http://www.inside-open-
source.com/2007/11/open-source-community-as-top-100.html (accessed on 20 April 2021).
