=Paper=
{{Paper
|id=Vol-3855/m4s4
|storemode=property
|title=Towards Modelling the Enterprise Context for Simulating Cyber-Physical Systems and Smart Connected Products
|pdfUrl=https://ceur-ws.org/Vol-3855/m4s4.pdf
|volume=Vol-3855
|authors=Nikola Ivanovic,Benjamin Nast,Kurt Sandkuhl
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/IvanovicNS24
}}
==Towards Modelling the Enterprise Context for Simulating Cyber-Physical Systems and Smart Connected Products==
https://ceur-ws.org/Vol-3855/m4s4.pdf
Towards Modelling the Enterprise Context for Simulating
Cyber-Physical Systems and Smart Connected Products
Nikola Ivanovic1,*, Benjamin Nast1 and Kurt Sandkuhl1,2
1
Rostock University, Albert-Einstein-Str. 22, 18059 Rostock, Germany
2
Jönköping University, Box 1026, 55111 Jönköping, Sweden
Abstract
This paper aims to contribute to more efficient development of simulation models for cyber-physical systems
(CPS) and smart connected products (SCP) by examining the possibility of extracting relevant information from
existing models in organisations, such as models of the enterprise architecture or models of the CPS/SCP. We
propose a procedure for this purpose and demonstrate its use in an application case in managing ventilation and
air conditioning facilities. The core idea is to create a context model that captures and integrates the extracts
from existing models relevant to simulation models. Extracts can be sub-models, views, or model elements. The
study suggests further investigation into industry-specific applications and the development of tool support for
extracting the enterprise context of CPS and SCP.
Keywords
Enterprise Architecture, Cyber-Physical System, Simulation Modelling, Context Model, Smart Connected Product
1. Introduction
Cyber-physical systems (CPS) tightly integrate physical systems, such as vehicles, manufacturing equip-
ment, or medical devices, and IT systems, such as organisational information systems or manufacturing
execution systems, for integrated monitoring and control in real-time (see section 2.1). The simulation
of the behaviour and activities of CPS typically requires modelling of various aspects of CPS, such as
the components and their relations, relevant types of events, data flows or temporal characteristics.
The assumption for the research presented in this paper is that existing organisational models include
information relevant for developing simulation models and extracting this information increases the
efficiency of the development of simulation models. Models have substantial value for enterprises if
they capture organisational knowledge [1]. Extracting information from models makes use of this
previous investment in model development to capture knowledge.
Engineering CPS traditionally requires different kinds of models, such as physical, computational,
and network models. New business models tightly integrating business services and CPS, such as
smart connected products (SCP) [2] or quantified products (QP) [3], have increased the variety of
the required models even more. Many SCP combine CPS (networked physical products controlled
by computational components) with service systems, i.e., business services performed by the human
workforce with support of information systems and computational resources of the CPS (see [3] for
examples). Simulation of such product-service-systems also requires knowledge of business processes,
economic transaction processing and customer relation management.
For the IT-related components of SCP, we can distinguish between product-IT, which encompasses
all sensors, actuators, and computing resources built into the physical product, and enterprise-IT,
which includes all administrative and information systems. For both product-IT and enterprise-IT,
enterprise architecture (EA) modelling can be used for modelling, as shown by Kaidalova et al. [4]. For
modelling CPS, various modelling languages and paradigms have been proposed (see Section 2.2).
Companion Proceedings of the 17th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modeling Forum, M4S, FACETE,
AEM, Tools and Demos co-located with PoEM 2024, Stockholm, Sweden, December 3-5, 2024
*
Corresponding author.
$ nikola.ivanovic@uni-rostock.de (N. Ivanovic); benjamin.nast@uni-rostock.de (B. Nast); kurt.sandkuhl@uni-rostock.de
(K. Sandkuhl)
0009-0006-3874-7216 (N. Ivanovic); 0000-0003-4659-9840 (B. Nast); 0000-0002-7431-8412 (K. Sandkuhl)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
The aim of this paper is a feasibility study in extracting model content with a focus on EA models as
one kind of frequently used organisational model. The intention of the feasibility study is to establish a
conceptual basis for future work. From a procedural perspective, we propose to develop a context model
that includes the elements of EA models that correspond or interact with components in product-IT
or physical CPS components. The context model is intended to represent the relevant information for
simulation models that is extractable from EA models. The required steps to develop the context model
are part of our work, which can be extended in future work into a modelling method.
The paper is structured as follows: section 2 summarises the relevant theoretical background of our
work and defines important terms. Section 3 presents an initial procedure for extracting the relevant
content. Section 4 presents an application example, including the developed models. Section 5 discusses
conclusions and the need for future research.
2. Theoretical background
2.1. Modelling for simulation
Modelling for simulation involves creating representations of real-world systems or processes that can
be analysed and experimented on using simulations. Our work focuses on CPS (see section 2.2). These
models are abstractions that capture the key features, behaviours, and dynamics of a system, allowing
simulations to predict outcomes or optimise performance without directly interacting with the real
system [5].
In general, different kinds of models are used in simulation, for example, deterministic models, where
outcomes are entirely determined by the initial conditions and inputs, with no randomness involved,
or probabilistic models that incorporate randomness or uncertainty and the same input can produce
different outcomes due to the probabilistic nature of the system. For the simulation of CPS, our focus
primarily is on discrete models [6]. These models represent CPS with their components and interaction
in a way where changes are triggered by events that occur at distinct points in time or space. These
models often involve events or transitions between states.
Developing a discrete simulation model involves a structured process that ensures the system being
modelled is accurately represented and that the simulation can generate meaningful insights [5]. Discrete
simulation models focus on systems where changes occur at specific, discrete points in time, often
based on events such as arrivals, departures, or system transitions. This requires creating a high-level
conceptual model identifying the key components, entities, interactions, and rules governing the system.
Furthermore, the entities (e.g., customers, machines), the attributes of these entities (e.g., service time,
queue size), and the events that will trigger state changes (e.g., customer arrival, service completion)
have to be modelled. In our work on reusing existing models in an organisation, our focus should be on
identifying models that contain relevant information about such components and entities.
2.2. Cyber-physical systems and smart connected products
CPS integrate physical world resources, like vehicles or manufacturing equipment, and the information
technology world [7, 8]. The term CPS is closely related to concepts, such as Industry 4.0, Web 4.0
[9, 10], the Internet of Things (IoT) [11, 12, 13] or SCP. In research, there is a substantial amount of
work on CPS, cyber-physical networks and applications of CPS, for example, in manufacturing [14]
and logistics [15]. CPS belong to the class of variable systems with dynamic structures. Such systems
require communication, computation and control infrastructures with often several separated layers for
the physical and IT "world" and with resources such as sensors, actuators, network nodes, computers,
services, etc. [16].
Horvath and Gerritsen stated some years ago that "the next generation of CPSs will not emerge by
aggregating many un-coordinated ideas and technologies in an incremental fashion. Instead, they will
require a more organised and coordinated attack on the synergy problem, driven by an overarching
view of what the future outcome should be" [17]. Barisivic et al. [18] propose in a recent analysis of
the state of research that multi-paradigm modelling could be the basis for this overarching view. They
conclude that the engineering of CPS requires the selection of appropriate modelling formalisms and
tools for physical, computational, and network models.
Barisivic et al. [18] also discovered that organisational aspects, such as business process and involved
stakeholders, are only covered in less than 10% of the modelling approaches. However, the core
elements of SCP (according to [2]) are physical components (e.g., mechanical and electrical parts),
“smart” components (e.g., sensors, microprocessors, controls), connectivity components (e.g., ports
and protocols enabling connections with the product) and value adding services (connected business
applications). Thus, models related to the value-adding services are relevant for SCP or QP.
2.3. Enterprise architecture management
Enterprise architecture management (EAM) is an established discipline in many companies and aims at
a coordinated and long-term development of the business and IT aspects of an enterprise [19]. EA aims
to model, align and understand important interactions between business and IT to set a prerequisite for
a well-adjusted and strategically oriented decision-making framework for both digital business and
digital technologies [20].
EAM, as defined by several standards such as ArchiMate [21] and TOGAF [22] today, uses a relatively
large set of different views and perspectives for managing and documenting the business-IT-alignment
(BITA) [23]. EAM represents a management approach that establishes, maintains and uses a coherent
set of guidelines, architecture principles and governance regimes that offer direction and support in the
design and development of an architecture to realise the enterprise’s transformation objectives.
TOGAF, a widely used industrial approach to EAM, divides EA into four partial architectures [22]:
• Business Architecture defines the business strategy, governance, organisation and the most
important business processes.
• Data Architecture describes the structure of logical and physical data elements and data man-
agement resources in the organisation.
• Application Architecture defines a design for the individually used application system and its
relationship to the organisation’s core business processes.
• Technology Architecture describes the software and hardware functions required to support
the development of business, data and application services. This includes IT infrastructure,
middleware, networks and communication.
3. Procedure for extracting relevant information from EA models for
simulation modelling
The analysis of recent publications on the development of simulation approaches [24] shows that seven
general steps can be identified: formulate the problem (scoping), collect information and document model
assumptions, validate assumptions with stakeholders, program the model, validate the programmed
model, design and conduct experiments, present the results. The procedure for extracting relevant
information from EA models presented in this section primarily contributes to the second step, collecting
information and documenting assumptions.
Our procedure focuses on extracting information and does not include initial model development,
i.e., it starts from an existing EA model for the organisation in question. Furthermore, we assume that
some kind of model exposing the components of the SCP (i.e., the physical, smart and connectivity
components) or the CPS exists. This could, for example, be an architecture description following ISO
42010, a UML or SysML model, or a model in a domain-specific modelling language. This model will be
referred to as the model of the physical part.
Starting from an EA model and a model of the physical part, our basic idea is to derive a context model
from these two models that captures the information relevant to the development of the simulation
approach in a machine-readable way. For the development of the context model, we propose to first
derive a connector model from the model of the physical product. Afterwards, the connector model
can be used to extract the parts of the EA model relevant to the simulation. Finally, the extracted
parts of the EA model and the connector model are merged, resulting in a context model that provides
the information required for simulation in a machine-readable way. Based on this general idea, the
proposed method consists of several steps, which form the procedural part of the method component
according to Goldkuhl’s conceptualisation [25]:
• Select model of the physical part: aims at identifying a model capturing information of the
physical part relevant to the simulation approach. This model should be conceptual and include
structural information (components, architecture), behavioural information (events, activities),
and constraints.
• Derive connector model: aims at identifying and documenting (a) the data sources in the
model of the physical part (e.g., sensors) that have to be processed in enterprise-IT, including
the services or applications needed for this processing; and (b) the data receivers (e.g., actuators
or displays) and their interfaces (service or API) in the physical part that require information
from the enterprise-IT. We envision representing the connector model in the same modelling
language used for the EA model to ease the development of the context model in step 4. A
candidate language is ArchiMate, the de-facto industry standard (see section 2). In ArchiMate,
the data would be represented with model elements of the data architecture and the services in
the application architecture.
• Extract information from EA model: as the connector model is supposed to reflect the input
information required from enterprise-IT, it could be used to identify services and applications in
the EA model that provide this information, including the specification of the exact data structure.
Furthermore, for the output of the physical part, the services in the enterprise-IT that require or
process this information and, in return, provide input to the simulation approach can possibly
be identified. More concretely, we propose a mapping of the data architecture elements in the
connector model on the data elements in the EA model. Identical or similar elements in the
EA model indicate relevant data. The services or applications connected to the identified data
elements are also relevant.
• Create context model: the context model is developed with the connector model as the starting
point and the results of the information extraction step from the EA model as input. The extracted
information, i.e., data elements of relevant ArchiMate types and service or application elements
of relevant ArchiMate types, are integrated into the connector model, which results in the context
model.
• Use context model as input for the simulation approach.
The above process serves as the initial design and method hypothesis for the remainder of this work.
It needs refinement and possibly extension.
4. Feasibility study
4.1. Industrial case
The application case considered in this work stems from a project in collaboration with a small and
medium-sized enterprise specialising in the construction, operation and maintenance of ventilation and
air conditioning facilities. The project aims to improve energy efficiency by installing a system with
the minimum number of sensors needed to monitor the specific performance of the air conditioning
system and ensure it’s optimally used. According to some studies, energy savings up to 30% can be
achieved in most existing facilities by identifying simple malfunctions [26, 27].
Industrial air conditioning facilities are usually customised for each customer and can be very complex,
so monitoring internal processes can be very complicated. Furthermore, the signals from the sensors
often have to be converted into a physical unit of measurement first. The specific measurement methods
depend on the configuration of the respective facility. With the increasing automation of control
technology, the amount of data is also growing rapidly. Intelligent data processing technologies for
direct and indirect processes are essential to operate facilities in an energy-efficient manner.
In the context of our application case, equipping the facilities with sensors results in an IoT-based
system used to monitor the facilities and intended to form a basis for new types of business services. The
planned IoT solution should be a diagnostic aid for potential improvements within the air conditioning
facility and the operating processes of the application case company. It must process a large amount of
data from different sources. In addition, it must integrate seamlessly into the company’s daily operations
and facilitate the provision of innovative service offerings.
4.2. Modelling the physical part of the system
The MIoTA modelling method [28] has been developed to enable the creation of physical models of
facilities by the employees of the application case company. It comprises a tool1 and an integrated
domain-specific modelling language (DSML) for air conditioning facilities, which provide the following
benefits: i.) a familiar interface for the tool users, ii.) the graphical representation of facilities, iii.)
the possibility of collecting relevant data about a facility (metric data), and iv.) the functionality of
exporting this data. The DSML includes the components of a facility, sensors, and further objects
relevant for modelling (e.g., for storing the metric data or objects for grouping components). Moreover,
it incorporates a relation for connecting the components, represented by an arrow symbolising the
airflow direction. Figure 1 shows an example of a physical part model of an existing facility created
by the MIoTA tool and containing the metric data. The visual model of a facility helps the technician
in preparing the sensor installation and is used for internal documentation and energy reports for
customers. The metric data provides information on the characteristics and operating parameters of a
facility (e.g., information about the operator, components, or control system), thereby determining the
facility type (type A: with humidification or dehumidification and type B: without humidification or
dehumidification). Based on the type of the facility, we know which sensors are required to be installed
to get all necessary data. In addition, the metric data determines the application of suitable calculation
methods for subsequent energy optimisation (further described in [29]), depending on the components
included. More about the metric data and its further use is described in section 4.3.
Figure 1: Physical part model of an example facility in MIoTA notation.
1
https://www.omilab.org/MIoTA/
4.3. Enterprise architecture based connector and context modelling
Having outlined the application case in section 4.1 and explained the creation of the model of the
physical part in section 4.2, we now describe the development of the context model intended for CPS
simulations. To achieve this, we analysed available EA models within the company. For this study,
our focus is on the "Heating Supply Service" within the company’s "Service View" model, which
encompasses all services the company provides to its customers. We chose this service because its EA
model is the most recent and provides the best level of detail.
In our work, the definition of the context model starts with the model of the physical part, described
in section 4.2. This model is recreated using ArchiMate notation and is shown in Figure 2. Further details
of the model of the physical part are found below Figure 2. Following the methodology outlined in this
paper, we systematically selected the data source components of the model of the physical part that need
processing within the enterprise-IT. Additionally, we identified the data receiver components and their
interfaces within the model of the physical part that require information from the enterprise-IT. This
analysis led to the development of the connector model, highlighted within the context model presented
in Figure 3. With the connector model established, we developed the complete context model, further
detailed above Figure 3. Additional explanations regarding the context model’s elements, notation, and
structure are provided below Figure 3.
Figure 2: Physical part model in ArchiMate notation.
As mentioned, creating a model of the physical part is the starting point for the context model
required in CPS simulations. As the model of the physical part is created in MIoTA notation, we
first had to model it in ArchiMate notation to ensure that all components for the context model are
visualised in a single notation. In addition, the model of the physical part contains critical information
about the structure of the plant and the specific sensors installed, as well as essential dimensioning
parameters such as room type, occupancy capacity and fan-related specifications necessary for accurate
calculations. We classify this data collection as "metric data", represented in the upper section of Figure 2
as constraint elements within the ArchiMate notation. Metric data is generated uniquely for each facility
by company employees using the MIoTA tool and then automatically stored in the appropriate database.
These metrics are essential input from enterprise-IT, addressing the requirements of the physical part
and forming the basis for further simulations and analysis. In addition, Figure 2, on the left-hand
side, shows the collection of sensor data. The data was sourced from the real-time operations of the
physical part and stored in the respective database, forming a parallel data source to the metric data.
The sensor data reflects the ongoing functional status and environmental conditions recorded by the
physical component, which are essential for the enterprise-IT. These results, in turn, are used to support
customers and other stakeholders who interact with or rely on the physical part’s operational data.
The identification of the sensor and metric data allowed us to determine the data sources and receivers
within the model of the physical part. This was important in order to derive the connector model from
these components. The identification of data sources and receivers provides a comprehensive basis for
the connector model. The connector model ensures that all relevant data sources and receivers in the
next step are identified in the EA model and systematically extracted into the context model.
When the connector model was established, the process moved forward by extracting information
from the EA model to create the context model. Initially, we analysed which components within the EA
model contribute to generating metric data. Through this analysis, we identified the roles and processes
in the business layer of the EA model responsible for creating metric data. In the application layer, we
identified the tools involved in generating metric data and the data objects representing the respective
databases where this data is stored. In the second step, we followed the same approach to examine
which components of the EA model process the sensor data of the physical part. At this stage, we
identified additional roles and processes within the business layer that require data from the physical
part.
Furthermore, we identified the application services, processes, components, and events in the applica-
tion layer. They handle sensor data and deliver outputs to stakeholders. The result of this analysis is the
context model shown in Figure 3, which provides a clear overview of the components responsible for
generating input data and those that process the output data of the physical part. In order to differentiate
these elements, the context model highlights two components: one that generates input data (marked
in green) and one that processes output data (marked in purple).
Figure 3: EA context model.
Before concluding this section and proceeding to the summary, it is essential to outline the layered
structure of the context model and the notation used in each layer. In alignment with the TOGAF Frame-
work and to cover all four partial architectures described in section 2.3, we employed the ArchiMate
layers. The Business Layer models the business architecture, utilising ArchiMate elements such as
business processes, business services, business roles, actors, and business events. The Application
Layer covers both data and application architectures, represented by application components, applica-
tion services, application interfaces, and data objects. Lastly, the Technology Layer represents the
technology architecture, using elements such as technology nodes, system software, communication
networks, technology interfaces, artefacts, and equipment. Additionally, we integrated the Motivation
Layer to document the requirements and constraints that influence the overall architecture.
Furthermore, the structure of the context model is organised as follows: The upper section contains
the motivation elements of the ArchiMate notation, representing the structure of the metric data. At
this stage, the elements encompass facility-structure data relevant to the use case and its connection to
actual sensor data. Since this data influences the facility’s behaviour and settings, we represent it using
Constraint elements. In the middle part of the context model, we depict the components of the EA model
that we have selected through the connector model. The EA model itself is organised hierarchically: the
upper yellow section represents business layer elements, forming the business context, while below this,
we present components from the application and data layers of the ArchiMate notation, establishing
the application and data context. Lastly, the lower part of the context model houses the physical parts’
model, represented through elements of the technology layer, which collectively define the technological
context within the context model.
For the observed company, the starting point for nearly every service provided to its customers is
the calculation of the dimensions for the specific use case and required service. In this process, the
assembly experts plan the facility structure by creating a model of the physical part installed on the
customer site. For this purpose, assembly experts use the MIoTA tool to generate the facility structure
data, known as metric data. Once the metric data is created, it is stored in DynamoDB in the cloud.
Following this, the system and sensors are installed at the customer site. Once the metric and sensor
data are available, they are accessed with Python for further analysis. Finally, from the results of the
physical calculations, the appropriate machine learning (ML) services for the use case are selected, and
their results are subsequently visualised on the GUI for the customers.
We now move to the Application and Data Layers. After the sensor and metric data are stored
in their respective databases, performing physical calculations using Python begins. We evaluate the
available sensors and determine the facility’s structure at this stage. This information is critical, as it
guides the system on which calculations are applicable. For example, if the facility is a heating system
without humidification, only the calculations for the heating use case will be executed. Sensor data
and humidity-related calculations will be excluded from further processing since they are irrelevant
to this specific facility type. Moreover, based on physical calculations supported by metric and sensor
data, we have identified which sensors are available on the facility side. Within the context model, this
information is represented as an event indicating the availability of CO2 sensor data. This information
enables us to select suitable ML services to process and analyse the data. We modelled the event using
the "Application Event" element in the context model in Figure 3. The use case-specific calculated data
is stored in a new InfluxDB bucket, called "Use Case Calculated Data", and is later used as input
for the ML services. Depending on the use case and the physical calculations, the data is prepared for
processing. In this case, the service is called "Person Check", where we estimate the number of people
in a room based on CO2 values, allowing us to optimise the air supply accordingly. The Person Check
service describes how the data is cleaned and transformed and how the ML models are trained, validated
and optimised to make accurate predictions. The final step is to visualise the data and document the
ML model. In addition, all data generated by this service is stored separately in a "Use Case ML Data"
database to increase the transparency of the models.
Lastly, we describe the Technology Layer, which outlines the technology infrastructure and how
the physical sensor data is collected and stored in the cloud. The sensor data is transmitted via the
MQTT protocol to the LoRa Gateway, which then forwards the data to the cloud. In the next step, the
data is stored in InfluxDB, hosted on an EC2 service. On the right-hand side in the lower part of the
context model, the metric data is collected through the API Gateway and stored in DynamoDB, which
is later used for further calculations.
5. Summary and future work
This paper aims to contribute to simulation modelling by proposing a procedure for extracting relevant
information in existing models as input for simulation modelling. The result of this extraction process
is captured in a context model. We propose to focus on EA models as the primary source of reusable
information, such as data elements or services.
The paper only contains initial conceptual work and a study of whether the general conceptual idea
is feasible. The study confirms that the creation of a context model is feasible but does not cover the use
of the extracted information, i.e., the context model, in simulation. This must be part of future work.
Other topics to explore are an automatic extraction of relevant information from an EA model based on
the connector model, the suitability of the connector model for other kinds of models of the physical
CPS part, and a more precise specification of the procedure.
In summary, the ArchiMate notation has proven sufficient for modelling both the context and the
model of the physical parts. It has also proven successful in reducing the complexity of modelling the
context model, as users do not need to deal with different model notations. However, further validation
is necessary to determine its suitability for simulation models of cyber-physical systems. Therefore,
future work will evaluate whether ArchiMate can manage the complexities of these systems and identify
if any adaptations to the notation are needed.
References
[1] M. Benkenstein, M. Fellmann, M. Leyer, K. Sandkuhl, The value of enterprise modelling: towards
a service-centric perspective, in: The Practice of Enterprise Modeling: 9th IFIP WG 8.1. Working
Conference, PoEM 2016, Skövde, Sweden, November 8-10, 2016, Proceedings 9, Springer, 2016, pp.
299–306.
[2] M. E. Porter, J. E. Heppelmann, et al., How smart, connected products are transforming competition,
Harvard business review 92 (2014) 64–88.
[3] K. Sandkuhl, Quantified products: Case studies, features and their design implications, Informatica
34 (2023) 825–845.
[4] J. Kaidalova, K. Sandkuhl, U. Seigerroth, Challenges in integrating product-it into enterprise
architecture–a case study, in: International Conference on ENTERprise Information Systems,
CENTERIS 2017, International Conference on Project MANagement, ProjMAN 2017 and Interna-
tional Conference on Health and Social Care Information Systems and Technologies, HCist 2017;
Barcelona; Spain; 8-10 November 2017, volume 121, Elsevier, 2017, pp. 525–533.
[5] A. M. Law, W. D. Kelton, Simulation modeling and analysis, volume 3, Mcgraw-hill, New York,
2007.
[6] B. P. Zeigler, H. Praehofer, T. G. Kim, Theory of modeling and simulation, Academic press, 2000.
[7] P. Antsaklis, Goals and challenges in cyber-physical systems research editorial of the editor in
chief, IEEE Transactions on Automatic Control 59 (2014) 3117–3119.
[8] K. H. Johansson, G. J. Pappas, P. Tabuada, C. J. Tomlin, Guest editorial special issue on control of
cyber-physical systems, IEEE Transactions on Automatic Control 59 (2014) 3120–3121.
[9] S. Aghaei, M. A. Nematbakhsh, H. K. Farsani, Evolution of the world wide web: From web 1.0 to
web 4.0, International Journal of Web & Semantic Technology 3 (2012) 1–10.
[10] J. J. S. Zapater, From web 1.0 to web 4.0: The evolution of the web, in: Proceedings of the 7th Euro
American Conference on Telematics and Information Systems, 2014, pp. 1–1.
[11] A. Skarmeta, M. V. Moreno, Internet of things: Security, privacy and trust considerations, in: Secure
Data Management: 10th VLDB Workshop, SDM 2013, Trento, Italy, August 30, 2013, Proceedings
10, Springer, 2014, pp. 48–53.
[12] S. Yang, Wireless sensor networks, Springer, London, 2014.
[13] L. Atzori, A. Iera, G. Morabito, The internet of things: A survey, Computer networks 54 (2010)
2787–2805.
[14] A. Fisher, C. A. Jacobson, E. A. Lee, R. M. Murray, A. Sangiovanni-Vincentelli, E. Scholte, Industrial
cyber-physical systems–iCyPhy, in: Complex Systems Design & Management: Proceedings of
the Fourth International Conference on Complex Systems Design & Management CSD&M 2013,
Springer, 2014, pp. 21–37.
[15] J. Wan, D. Zhang, S. Zhao, L. T. Yang, J. Lloret, Context-aware vehicular cyber-physical systems
with cloud support: Architecture, challenges, and solutions, IEEE Communications Magazine 52
(2014) 106–113.
[16] N. Teslya, A. Smirnov, T. Levashova, N. Shilov, Ontology for resource self-organisation in cyber-
physical-social systems, in: Knowledge Engineering and the Semantic Web: 5th International
Conference, KESW 2014, Kazan, Russia, September 29–October 1, 2014. Proceedings 5, Springer,
2014, pp. 184–195.
[17] I. Horvath, B. H. Gerritsen, Cyber-physical systems: Concepts, technologies and implementation
principles, in: Proceedings of TMCE, volume 1, 2012, pp. 7–11.
[18] A. Barišić, I. Ruchkin, D. Savić, M. A. Mohamed, R. Al-Ali, L. W. Li, H. Mkaouar, R. Eslampanah,
M. Challenger, D. Blouin, et al., Multi-paradigm modeling for cyber–physical systems: A systematic
mapping review, Journal of Systems and Software 183 (2022) 111081.
[19] M. Lankhorst, et al., Enterprise architecture at work, volume 352, Springer, Berlin, 2009.
[20] E. Niemi, S. Pekkola, Using enterprise architecture artefacts in an organisation, Enterprise
Information Systems 11 (2017) 313–338.
[21] The Open Group, ArchiMate® 3.0. 1 Specification: The Open Group Standard, Van Haren Publish-
ing, 2017.
[22] The Open Group Standard, „The TOGAF® Standard, Version 9.2“, opengroup.org, https://pubs.
opengroup.org/architecture/togaf9-doc/arch/, 2024.
[23] D. Simon, K. Fischbach, D. Schoder, Enterprise architecture management and its role in corporate
strategic management, Information Systems and e-Business Management 12 (2014) 5–42.
[24] A. M. Law, How to build valid and credible simulation models, in: 2022 Winter Simulation
Conference (WSC), IEEE, 2022, pp. 1283–1295.
[25] G. Goldkuhl, M. Lind, U. Seigerroth, Method integration: The need for a learning perspective, IEE
Proceedings-Software 145 (1998) 113–118.
[26] S. P. Melgaard, K. H. Andersen, A. Marszal-Pomianowska, R. L. Jensen, P. K. Heiselberg, Fault de-
tection and diagnosis encyclopedia for building systems: A systematic review, Energies 15(12):4366
(2022).
[27] W. Kim, S. Katipamula, A review of fault detection and diagnostics methods for building systems,
Science and Technology for the Built Environment 24 (2018) 3–21.
[28] B. Nast, K. Sandkuhl, S. Paulus, H. Schiller, MIoTA: Modeling IoT applications for air conditioning
facilities with ADOxx, in: 22nd International Conference on Perspectives in Business Informatics
Research Workshops and Doctoral Consortium, BIR-WS 2023 Ascoli Piceno 13 September 2023
through 15 September 2023, volume 3514, CEUR, 2023, pp. 158–168.
[29] N. Ivanovic, B. Nast, A. Reiz, K. Sandkuhl, Technologies for a diagnostic technique for hvac systems
using IoT and cloud-based architecture, in: 2023 International Interdisciplinary PhD Workshop
(IIPhDW), 2023, pp. 1–6. doi:10.1109/IIPhDW54739.2023.10124398.