# Semantic Microservice Framework for Digital Twins
## 2 Related Work
### Requirements for a Digital Twin Service Framework  
Requirements found in the literature primarily target the overall concept of a DT, rather than only focusing on the service infrastructure. Nevertheless, some general requirements are also relevant for the proposed service framework. Here, the main literature is presented, which is used to derive the requirements presented in Section 3.1.  
A requirements-driven DT framework for smart manufacturing or Industry 4.0 is presented in [25]. Some requirements mentioned there are also specifically relevant for a service framework, e.g., a DT's capability should be modular with clear boundaries (RN2). Services should also provide some form of narrow intelligence to solve some special tasks in the application domain (RI3). Furthermore, expertise should be incorporated into services to realize intelligence in solutions (RI4). Another aspect is the interoperability with DT clients, which must be realized by providing an appropriate service interface (RI5). DT should also be extensible, which means incorporating data or services from outside (RN4). An important aspect is that a DT framework must support an evolution rather than a revolution of capabilities, helping us to introduce and further develop the DT over its whole life-cycle (RN3). New services are supporting the evolution of existing capabilities.  
As DT should provide an added value over lifetime, the DT services have to be integrated into the business process at the enterprise level in some way (RB1).  
In [26], a method for DT-driven product design, manufacturing, and service is introduced. In this context, nine service categories are presented. Some of these service categories demand some requirements regarding the service communication infrastructure. For instance, a service for real-time state monitoring requires a certain data acquisition infrastructure (RF1) and certain communication patterns (RF2). The same holds for a service within the category of energy consumption analysis and forecast, such as processing heterogeneous data from various sources (RI1, RF3), dealing with historical data (RI2) and supporting request-response communication with other services (RF4). These two examples show that a service framework has to be able to support different communication patterns.  
A DT architecture reference model for the cloud-based CPS (C2 PS) is presented in [27], in which the key properties of computation, control, and communication are described. The cloud-based approach seems reasonable, based on requirements such as computational power and scalability. On the other hand, this can cause a problem, as the communication over the Internet is critical, regarding availability [28] and the communication delay [29] for real-time control applications. Thus, a combination of an edge, fog, and cloud-based approach is feasible for a DT to provide services with their needed resources, as presented in [30]. However, in some use-cases with a high demand for reliability, security, and privacy, the hosting of the DT has to be done on-premise (RN1). To enable this flexibility, a containerized solution for DT services, as proposed in [31], seems to be suitable.  
Human-machine interaction is also essential in the context of DTs, which includes social and technical aspects [32]. Maintenance scenarios are one example of such a human-machine interaction. These scenarios can be quite complex, and their states have to be stored during this process, as shown in [33] for gas turbine maintenance. Thus, the state must also be stored at the involved services in such a human-machine interaction (RB2).  
Services of a DT often have to process a large amount of data. Such data-intensive applications have some basic non-functional requirements which should be met, such as reliability (RN5), scalability (RN3), and maintainability (RN2, RN4) [34]. Unfortunately, there are no easy solutions to meet these requirements, but specific architectural patterns and techniques can be applied during implementation to fulfil them.