This paper aims to contribute to more eficient 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.
Cyber-physical systems (CPS) tightly integrate physical systems, such as vehicles, manufacturing
equipment, 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
eficiency of the development of simulation models. Models have substantial value for enterprises if
they capture organisational knowledge [
Engineering CPS traditionally requires diferent 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) [
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. [
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.
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 [
In general, diferent 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
diferent outcomes due to the probabilistic nature of the system. For the simulation of CPS, our focus
primarily is on discrete models [
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 [
CPS integrate physical world resources, like vehicles or manufacturing equipment, and the information
technology world [
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 [
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 diferent 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 ofer 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 management 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.
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.
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 eficiency 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-eficient 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 diferent sources. In addition, it must integrate seamlessly into the company’s daily operations and facilitate the provision of innovative service oferings.
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.
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.
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 ifrst 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 application 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 diferentiate 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).
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 Framework 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, application 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.
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 suficient 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 diferent 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.