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 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).
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 [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.
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.
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 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. 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 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.
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 tool 1 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 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 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 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). 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 CO 2 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 CO 2 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 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.