Digital Twin is a complex of microservices

. Industry 4.0 is an actively developing concept, of which the concept of the Digital Twin is becoming a part. The digital twin is a complex cyber-physical system that consists of many components. One of the main tasks in the construction of a twin is to organize the interaction of the parts of the twin with each other. Previously, an approach called the enterprise service bus was used, but over the years of its use it became clear that it is not suitable for constantly evolving and growing systems. The digital twin is just such a system and therefore it is required to use a different approach, called microservice. If we imagine the parts of the twin as a set of microservices, then it will be possible to create a system suitable for constant evolution and replacement of its parts. This approach was used to solve the problem of building a prototype digital twin of methanol production. The solution of this problem showed the possibility of using a microservice approach.


Introduction
Throughout history, mankind has been developing its technological knowledge and practical skills.During the period of antiquity and the Middle Ages, skills related to manual work and the beginning of the emergence of handicrafts became the basis for development, however, after the beginning of the Renaissance and the active development of guilds (associations of people by occupation), new milestones in technological development became possible.Such jumps began to be called scientific and technological revolutions.These rapid technological breakthroughs were accompanied by significant changes in social, cultural and economic life.At the moment, the historical process of technology development is in the stage of a new scientific and technological revolution called Industry 4.0.This concept is essentially a set of methods, approaches and technologies that involve the digital transformation of industry and the consumer market, the development of smart factories, smart supply chains and smart production chains.[1,2] Technological transformation requires the industry to introduce new technologies and approaches that allow for broad control and predictability of the production cycle.One of the basic technologies that can help in building smart industries in their current understanding is the technology of digital twins.The digital twin has recently been actively turned on and developed as part of the concept of Industry 4.0 [3].According to a scientific paper by Pires and Flávia [4]: "The digital twin is a set of adaptive models that mimic the behaviour of a physical system in a virtual system that receives real-time data to update throughout its life cycle.The digital twin replicates the physical system to predict failures and opportunities for change, prescribe real-time actions to optimize and/or mitigate unforeseen events by observing and evaluating the operating profile of the system."This rather broad definition gives a clear understanding of the tasks it performs.In addition to this publication, which indicates the given definition, other scientific articles devoted to this topic [5] also highlight the listed tasks.As a result, we can say that this concept is designed to ensure continuous processing of data received both on a physical object and on its digital representation.The purpose of this processing is to predict and optimize the processes of a real object.As a result, we can summarize that the digital twin allows you to:  Accelerate and reduce the cost of testing and testing hypotheses when optimizing processes in plants and enterprises. Reduce pollution and injuries by predicting exceptions and problems. Increase the efficiency of both workers and installations through fine-tuning based on predictive results. Reduce the cost of training new employees by documenting production and having a fullfledged digital copy from which to conduct training. Centralize the collection, exchange and processing of data generated by various components of production, by combining all enterprise systems [6].Separately, it is worth highlighting visualization as a significant task that is set for digital twins.About 50% of all publications are devoted to this problem, from which we can conclude that it is significant [7].Visualization can be both classical and three-dimensional, in the case of three-dimensional one, we can talk about VR (virtual reality) and AR (augmented reality) technologies that can increase the return on learning on such a double.

Materials
Based on everything that is written above, and based on a number of scientific papers, we can conclude that the digital twin is not a single monolithic system and involves the presence of many parts [6][7][8].Each of these parts is obliged to communicate with each other and ensure the transfer of data, performing its task assigned to it.Such a system should grow and develop along with the physical object and incorporate all new subsystems used for a more comprehensive and complete description of the original object.Building such systems is a complex task that has various solutions: an approach called the enterprise service bus is often used [9].
However, this approach has a number of disadvantages associated with the device architecture itself, as follows:  Performance -the named architecture is based on a specific center of concentration of data flows, the very bus through which all communication takes place.This center is under severe stress when many different systems are connected to it. Delayed effects -the essence of this architecture assumes that the service bus performs not only a transport function, but also contains a number of business logic.Although initially many systems built in this way do not imply such a load on the bus, but over time it becomes a point of concentration of logic that unites various subsystems.Gradually, it turns into a tangle of intricate connections that are extremely difficult to parse. Documentability -is a disadvantage closely related to the previous one, since the algorithms for computing business logic are transferred to the bus.Documenting such a bus turns into a task comparable in complexity to building a bus. Blurring of responsibility -similar to the previous problem, it grows due to the placement of logic in the bus itself, at some point during the development of the next subsystems, part of their logic, for the sake of simplicity and speed of development, begins to be implemented on the bus, their own responsibility and control over data are lost, with which this subsystem operates. Fault tolerance -in fact, the presence of one point of concentration creates problems with fault tolerance, since it turns out a single node of disruption in operation, failures of which entail guaranteed problems in the functioning of all the others. Entanglement -this problem is generally connected with the fact that a single bus turns a system distributed in its idea into a common monolithic tangle of relationships and dependencies.
All the problems described above relate not so much to the very concept of the service bus as an architectural idea, but to the incarnations that it takes during implementation and long-term operation.In this fact lies the most basic problem -such an architecture is not in the full sense of evolutionary, and it will be impossible for it to grow together with an object that involves a gradual increase and change.Building such a system would require a more evolutionable architecture.The microservice architecture copes with this task [10].Microservice architecture is used by many Internet companies, such as Google, Apple, Amazon, Netflix and others, who collect and process huge amounts of data.This architecture presupposes the exclusion of the possibility of building single points of concentration of all functions and the distribution of tasks and logic into separate parts.At the same time, it is important to note that the microservice architecture also has malicious and incorrect implementations that involve the division of a single business logic into parts according to the entities involved in this logic, which turns the entire operation of the system into a block of separate independent parts, each of which must constantly interact with others to solve their problem.But this problem, in contrast to the problem of the growth of the service bus into a monolith, is solved at the initial stage, and in most cases it harms the system immediately, which forces developers to abandon and never use this option again.If the microservice system is combined with the concept of domain logic [11], this will create a complex system that maintains a balance between the independence of individual parts and the connectivity of the entire system.As a result, the microservice architecture provides the following properties:  Scalability -is associated with the ability of the system to quickly increase its performance in certain segments, which have become its bottleneck. Flexibility -is determined by allowing parts of the system to be implemented on any technological basis, be it different programming languages, different execution environments, different data transmission channels, the main thing is that the common format of interaction should be preserved. Integrability -is determined by the almost complete independence of the entire architecture from technology, the only rule is a single interaction protocol that will allow any part to adapt to it. Fault tolerance -is provided by the capabilities of systems built on such an architecture to operate on distributed computing power, store their data in distributed storages and use distributed databases. Decentralization -is ensured by the fact that the architecture does not assume the presence of a single center for the concentration of functions or data by default.The properties described above are not exhaustive and are not strictly exclusive to the chosen approach, but the combination of these properties is definitely an important achievement of the microservice approach.It is important to note that in order to achieve these properties, not only the architecture itself must have these characteristics at its core, but also its individual parts must provide them.That is, any microservice should be designed and developed in such a way that:  Be capable of flat scaling of the resources allocated to it;  Implement the base interoperability standards defined in the original architecture design. Make it easy to deploy yourself to new capacities. Guarantee versioning and the ability to use previous versions to quickly fix inoperability. Be able to perform its own functions with a minimum amount of information taken from other integrated systems.Ensuring all the above properties of parts of the system ensures that the described properties of the entire system are guaranteed, which is the key advantage of the architecture over alternative options for working with really large amounts of data that the digital twin of production must operate with.

Results
Using the concept of architecture described earlier, it is possible to build a digital twin system that will provide and guarantee the availability of a resource for constant expansion and evolution.The essence of the idea is to present each part of the twin as a separate domain microservice that deals exclusively with its own tasks.So the separate parts will be: The real object, and in the future and, if necessary, its individual parts:  A program for modeling a real object or its parts. Object monitoring system. Predictive analytics system. Object management system. Model management system. Operator assistance and support system. Visual representation of an object.
Each of these parts will act as a provider or consumer of data that will be used by other parts.In a situation where all systems generate and receive data, it would be reasonable to introduce a center for their collection and provision as a separate unit.At this point, we run into a contradiction with the approach described above, and it is logical to point out that such a system is very similar to a service bus, but there are important differences.So the server for aggregating and providing data is not the only link, and other systems, if necessary, can interact independently.Separately, we note that the server does not imply any additional logic other than storing data sent by one consumer and providing it to others.The server does not ensure the operation of signals and reactions to data changes, it simply concentrates them and transmits them further along the chain.Thus, such a data concentration server is not a point of failure, since it can be run as a separate unit in any quantities, it does not modify the data and does not process them in any way, its whole task is to quickly save and quickly provide.If one such server fails, the consumer and supplier can always switch to another, the data in which will be up to date.The only duty that can be assigned to such a server, in addition to data transmission, is their replication among all their fellows.
As a result, in the system, the conceptual representation of which is shown in Figure 1, there will be only three entities that are significantly different from each other:  Data providers are those parts that generate the data coming into the system. Data consumers are those parts that receive and use data from the system. Data sender -those parts that act as aggregators, layers whose only task is to receive data from the supplier and pass it on to the consumer if he requests it.Separately, it should be noted that in order to build a system based on such an architecture, it will be necessary to choose a single data exchange protocol and a format for presenting this data, and since it is the microservice architecture that is used, it is logical to use the JSON data format and protocol that have proven themselves and are the de facto standard in such systems.HTTPS exchange.The main advantage of this choice will be the ability to use existing libraries for writing code and organizing the interaction of all parts of the system.Also, it is worth noting the convenience of the data format for human reading, which will simplify the task of debugging an embedded system.A similar conceptual twin device was implemented in the prototype digital twin of the co-production of methanol and ammonia, shown in Figure 2.This implementation is a prototype of the digital twin because there is no real object constantly communicating with the model.This is due to the initial formulation of the problem, according to which only a digital model was provided, implemented using the UniSim Design software package, used in the simulator existing at the enterprise.The constructed system serves as an illustration of the viability of the idea of organizing a digital twin as a set of microservices.

Discussion
When implementing this task, the complexity associated with the proprietary software on which the production model was implemented was identified.This program was created at a time when the basis of technological programs was the dependence on programs from the same manufacturer, and therefore there was no convenient way of integration interaction in UniSim Design.Also, the method of data extraction that was discovered did not in itself provide integrability into a system built on the basis of web technologies, i.e. it was impossible to use the HTTPS protocol directly.To solve this problem, a separate entity called the data driver was added to the overall architectural design.This program connects to a data source or consumer that cannot be integrated into the system on its own, and using the interaction mechanisms provided by it, provides data transmission or reception from the aggregation server.In fact, this program runs in parallel with the simulation program, and either directly controls it, interrupting it to receive data, or removes data during the calculation in any of the available ways.
Also, in the process of solving the problem of constructing another digital representation, it became necessary to change the modelling program to the Aspen HYSYS program.This program has the same roots as UniSim Design, but has its own distinctive features.When switching to another modelling program, for its integration into the system, it was also necessary to create a data driver, but no other changes were made to the developed digital representation, which perfectly shows the flexibility of the system to changes achieved with such an implementation.
In the process of implementing the prototype of the digital twin, it was not possible to load test the proposed architecture, for this reason, it is possible to judge its resistance to loads only by the presence of such stability in the architecture itself, as well as scalability.To solve the second problem, it is supposed to use automatic build systems and project deployment on servers in order to be able to horizontally scale the used capacities by launching additional servers if necessary.Traffic redirection and balancing must be provided by Nginx using a random server selection mechanism to process the request.The deployment of processing servers itself must use CI/CD mechanisms and containerization technology to rapidly scale up capacity.

Conclusion
The presented work can be considered as proof of the viability and applicability of the idea of building systems similar to a digital twin as a set of microservices.Such a device will allow the system to evolve together with the physical object and adapt to improvements in the modeling process.Such an architecture will allow any third-party software from any manufacturer to be integrated into the digital twin, i.e. connect it with existing management and analytics systems at enterprises.The microservice approach will enable the ease of management of the entire enterprise ecosystem and the gradual introduction of the concept of smart enterprise, smart supply chains and smart products.The approach will allow E3S Web of Conferences 458, 09012 (2023) EMMFT-2023 https://doi.org/10.1051/e3sconf/202345809012gradually increasing computing power and increasing the amount of data collected, which will ensure a smooth increase in the cost of introducing new approaches and technologies for analysis and modeling.The use of a modern evolutionary architecture in a technological enterprise to build data collection systems will simplify the process of implementing a thirdparty software vendor, which, in turn, can save on the final cost of the entire system.Separately, it is worth highlighting the fact that this technology is associated with the use of commonly used web interaction standards, which means that it can be implemented by a wider range of specialists, which will ensure the influx of fresh qualified personnel into production.The microservice architecture is not without its drawbacks and may be replaced by a more advanced one in the future, but now it can give the industry a new impetus in the development of production systems.

E3SFig. 1
Fig. 1 Conceptual representation of the described digital twin system.

Fig. 2
Fig. 2 Actual structure of the conceptual implementation of the digital twin.