A flexible orchestration method for digital twin services based on workflow technology

Abstract

The present invention discloses a flexible orchestration method for digital twin services based on workflow technology, which includes the following steps: constructing a digital twin resource management and service orchestration framework, constructing a process for accessing and functional servitization of physical entity production equipment in the framework; performing digital twin service registration and discovery; constructing a service health check and elastic healing mechanism; abstractly decomposing the steps in the customer order business flow and the product process processing flow and the collaborative relationship between the steps to form a customized production business workflow; constructing a customized production business process orchestration architecture, constructing a customized production business process model in the digital twin service, and performing customized production in the digital twin service process; uploading the customized production business process model to the Zeebe workflow engine in the cloud, and calling the corresponding business workflow execution. The present invention can flexibly change the task execution module and execution process in the workflow, making it easier to organize resources for production.

Description

Technical Field

[0001] The present invention relates to the field of digital twin service technology, and in particular to a flexible orchestration method for digital twin services based on workflow technology. Background Art

[0002] Digital twins use data channels to communicate the operating status data of physical objects and virtual objects in a timely manner, realizing the monitoring, prediction, and control of the operating status of physical objects and the evolution and development of virtual objects. Digital twin services contain a large amount of heterogeneous software and physical hardware manufacturing resources. Faced with customized production environments with changing business scenarios, the manufacturing resources in digital twin services need to be able to achieve dynamic changes and agile deployment without stopping production.

[0003] However, in the cyberspace, software component resources frequently require upgrades and iterations, and must maintain consistent operation across different server environments. In the physical space, hardware devices are also removed and added based on process flow changes. As new physical devices are added, they must be automatically mapped to the virtual logical devices deployed in the system. Furthermore, because software components may be developed by different teams and physical devices may come from different manufacturers, the communication protocols, interface styles, and operating environments of the hardware and software manufacturing resources connected to the system vary significantly, making interoperability difficult. Furthermore, during customized production, the request traffic received by each node in the production system varies. This requires that worker nodes elastically scale the manufacturing resource instances on their nodes based on actual conditions to ensure system stability. Furthermore, resource deployment may be distributed across different nodes in the cloud or at the edge. In many cases, the functional services provided by these distributed manufacturing resources require cross-domain and cross-node organization or reconfiguration of production.

[0004] To manage and orchestrate distributed, heterogeneous manufacturing resources within digital twin services, resources must first be virtualized. Next, they must be further encapsulated and formed into modular system components. Finally, to organize distributed manufacturing resources for production and processing, the functionality of these resources must be exposed as services and orchestrated according to production business processes. However, most digital twin service resource management and orchestration frameworks lack the flexibility and agility to manage resources across multiple levels and dimensions, as well as the flexible orchestration of manufacturing resource instances across domains and nodes. This makes it difficult for production systems to globally respond to changing workloads and business demands.

[0005] The functions of manufacturing resources in digital twin services need to be dynamically orchestrated and reconstructed according to changes in processing technology and production business processes. In order to facilitate the organization of resources for production and further eliminate the heterogeneity between resources, resource instance functions need to be released to the outside world in the form of services. However, current technologies have major defects in handling heterogeneity and systematic integration in digital twin service resources.

[0006] Therefore, in order to meet the requirements of customized production for high stability, high reconfigurability, and high flexibility of manufacturing resources in digital twin services, there is an urgent need for a framework that can manage and orchestrate digital twin service resources and services, and provide a more elastic and flexible way for the deployment of physical space and cyberspace resources, service orchestration, and production organization. Summary of the Invention

[0007] In order to overcome the defects and shortcomings of the existing technology, the present invention provides a flexible orchestration method for digital twin services based on workflow technology. On the one hand, it combines the cloud and edge native concepts, and cooperates with information technologies such as virtualization, continuous deployment, service grid, and workflow orchestration to form a one-stop management and orchestration framework for manufacturing resources in digital twin services, thereby solving the problem of dynamic changes in resources in customized production, further eliminating the heterogeneity between resources, and facilitating the organization of resources for production. On the other hand, by automatically registering and discovering services for connected soft and hard manufacturing resources, on the basis of ensuring service health, in accordance with workflow standard specifications, the customized production business process is visually orchestrated, so that the task execution module and execution process in the workflow can be flexibly changed.

[0008] In order to achieve the above object, the present invention adopts the following technical solutions:

[0009] The present invention provides a flexible orchestration method for digital twin services based on workflow technology, comprising the following steps:

[0010] Build a digital twin resource management and service orchestration framework, and establish the process of accessing physical production equipment and servitizing its functions within the framework;

[0011] Perform digital twin service registration and discovery;

[0012] Build a service health check and elastic recovery mechanism for the digital twin service resource management and service orchestration framework. Based on readiness probes and survival probes, periodic checks are performed on manufacturing resource instances that provide services. Service registration and discovery are performed for ready resource instances. Surviving instances are periodically monitored, and failed instances are restarted or repaired.

[0013] Abstract and decompose the steps in the customer order business flow and the product process and the collaborative relationship between the steps to form a customized production business workflow;

[0014] Build a customized production business process orchestration architecture. Based on the available services in the service registry and the BPMN business process model, build a customized production business process model in the digital twin service to perform customized production in the digital twin service process.

[0015] Upload and deploy the customized production business process model to the Zeebe workflow engine in the cloud, and call the corresponding business workflow execution using the gRPC protocol based on the workflow engine's IP address, port number, and workflow instance name or ID.

[0016] As an optimal technical solution, the digital twin resource management and service orchestration framework provides device operation functions and software component functions to the outside world in the form of microservices, and adopts a unified standard interface to provide service acquisition methods.

[0017] As a preferred technical solution, the process of accessing physical production equipment and servitizing its functions in the framework is constructed. The specific steps include:

[0018] When a device is connected, determine whether it is a new device, that is, whether there is a declarative description model for the device;

[0019] If the model is determined to be non-existent, the device metadata is extracted, and an abstract description of the state attributes is made. A YAML file is compiled and uploaded to the Kubernetes API. The controller creates an abstract and instance model of the device based on the description information in the YAML file and assigns it to the corresponding edge node. The SQLite database on the edge node stores the device metadata and attribute values.

[0020] If it is determined that the model already exists, the Mapper at the edge will find the corresponding model and instance from the device model list based on the name and number of the connected device, and through protocol adaptation and conversion, map the actual physical device and the device instance in the information space to each other. Based on the collected device data and the subscribed MQTT topic, the device twin component updates the actual state attribute value of the device instance and uploads the data to the cloud storage through the cloud-edge interaction component; at the same time, the device twin component continuously monitors the changes in the expected state value from the device controller, and synchronously adjusts the actual state value, and then transmits the modified parameters or instructions back to the device control interface through the mapper, so that the device can operate according to the expected state.

[0021] As a preferred technical solution, after constructing the process of accessing physical production equipment and servitizing functions in the framework, it also includes the step of modifying the expected state value, specifically including:

[0022] Modify the expected state value in the cloud or edge and run it in a container manner. The container has the operation rights of the device controller and can change the device instance state. The user accesses the functional services of the corresponding device by accessing the host's IP address and the port number mapped by the container. By modifying the expected state value, the user can remotely control the functional services of the device end.

[0023] As the preferred technical solution, digital twin service registration and discovery are carried out, specifically including:

[0024] After being deployed and started, the digital twin production instance registers its own metadata to the service registration center for other resource instances to discover and call services. When an instance calls a functional service provided by another instance, it uses the service discovery mechanism to find a list of available services and communicate with the corresponding service.

[0025] As a preferred technical solution, during the steps of digital twin service registration and discovery, a digital twin service network architecture is constructed, specifically including:

[0026] When a software program instance or device control program instance is deployed and released in the digital twin service, the digital twin service network architecture injects the proxy description into the corresponding declarative YAML file, automatically generating an Envoy proxy container during the process of forming a Pod instance;

[0027] To service the functions of physical hardware and software programs, Kubernetes automatically registers the Service resources, which are abstracted from the functions of resource Pod instances, in the CoreDNS registry. CoreDNS is used to resolve DNS queries for all running services in the digital twin service network architecture. When one manufacturing resource instance communicates with another, the service name is used to resolve the instance's IP address, providing a basis for service discovery.

[0028] The Pilot component provides service configuration and proxy module management for the data panel, and distributes routing rules for service access to each Envoy proxy. When the sender sends a request, the proxy module intercepts the request and forwards the request to the target service according to the routing rules in the Envoy configuration. When the target service receives the request, it is processed and converted by the proxy module, and then the processed request is handed over to the resource instance for response processing.

[0029] As a preferred technical solution, restart or repair the faulty instance, specifically including:

[0030] When a manufacturing resource instance is diagnosed as faulty, it is restarted according to the restart policy in the declarative description. When the number of restarts reaches the upper limit, the framework removes the manufacturing resource instance.

[0031] After manufacturing resource instances are eliminated, the number of replicas of each resource type is obtained. When the number of replicas drops to the expected value in the declarative YAML file, the corresponding controller pulls the failed resource type from the virtual resource pool and redeploys it until the number of instances of the resource type reaches the expected value.

[0032] As a preferred technical solution, the customer order business flow and the steps in the product process flow and the collaborative relationship between the steps are abstracted and disassembled to form a customized production business workflow, which specifically includes:

[0033] The task execution module of each step is composed of microservices formed by manufacturing resource instances, and the relationship between task modules is described by BPMN;

[0034] The task execution module in the client and the workflow engine Broker in the server interact in a publish-subscribe mode. When the task status in the workflow engine Broker state machine changes, the workflow engine Broker will publish the corresponding event. The task execution module subscribes to the events in its own task queue in a long polling manner. After the execution is completed, the result is returned to the workflow engine Broker, so that the task of the state machine is transferred to the completed state.

[0035] As the preferred technical solution, a customized production business process orchestration architecture is built, specifically including:

[0036] The Brokers component in the Zeebe server is distributedly deployed and elastically managed. The Zeebe processor connects to the cloud client and edge client through the RPC gateway, using the gRPC protocol to interact and maintain a persistent connection, and performs full-duplex information transmission and reception between the cloud and edge.

[0037] For services formed by abstracting resource instance functions, their own API function interfaces are injected into the cloud or edge client;

[0038] The Broker component in the cloud associates the specified task execution module through the service name.

[0039] As a preferred technical solution, based on the available services in the service registry and the BPMN business process model, a customized production business process model in the digital twin service is constructed to carry out customized production in the digital twin service process, specifically including:

[0040] The customized production business process orchestration architecture builds or matches the corresponding BPMN business process model based on the product's feature information and behavior information. Based on the task execution modules of each link, it pulls resources from the virtual resource pool, deploys them in the work nodes and interconnects them with physical devices. The corresponding BPMN business process model execution sequence and logical association are used to complete the customized production of the order.

[0041] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0042] (1) The digital twin service resource management and service orchestration framework proposed in the present invention will provide device operation functions and software component functions to the outside world in the form of microservices, and adopt a unified standard interface to provide service acquisition methods. Another important feature of microservices is service combination. The service combination can be flexibly adjusted and modified according to business needs, so as to flexibly adapt to application scenarios with frequent changes in customized production needs. Therefore, by microservice-izing the functional instance modules deployed in the framework, it can provide a decomposable, scalable and orchestrated foundation for organizing production business workflows.

[0043] (2) The present invention monitors the functional services formed by the resource instances in the framework by means of health check probes. The health check probes can periodically send requests to applications or services to ensure that they can respond normally. Through the response results, the basic functions of the services can be tested to know whether the ports are opened normally and whether the response time meets expectations, so as to quickly locate the problems and repair them. The horizontal elastic management of manufacturing resource instances is studied, and the framework is further endowed with the ability of elastic healing.

[0044] (3) The present invention is completed by using Zeebe workflow engine technology as a middleware. Compared with the traditional logical call between services, the workflow engine can separate the implementation of tasks and the collaborative relationship of tasks, store virtualized physical device resources and software resources in the cloud virtual resource pool, and realize shared manufacturing and resource reuse by providing instance description files and acquisition interfaces of abstract resources to the outside world.

[0045] (4) The present invention can realize cross-domain and cross-node autonomous orchestration of distributed available manufacturing resource instance functional services based on personalized order requirements and production business changes, and can dynamically change and reconstruct service modules and execution processes in the workflow, greatly improving the flexibility of customized production business processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 This is a flow chart of the flexible orchestration method for digital twin services based on workflow technology of the present invention;

[0047] Figure 2A schematic diagram of the process of device access and function service provisioning of the present invention;

[0048] Figure 3 This is a schematic diagram of the digital twin service network architecture of the present invention;

[0049] Figure 4 Schematic diagram of the service health check and elastic healing mechanism of the present invention;

[0050] Figure 5 This is a schematic diagram of the execution principle of the Zeebe workflow engine of the present invention;

[0051] Figure 6 This is a schematic diagram of the customized production business process orchestration architecture of the present invention;

[0052] Figure 7 This is a schematic diagram of the customized production business process model of the present invention;

[0053] Figure 8 This is a schematic diagram of the execution process of the customized production task module of the present invention;

[0054] Figure 9 This is a diagram showing the visualized progress of the business process of the present invention. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0056] Example

[0057] like Figure 1 As shown, this embodiment provides a flexible orchestration method for digital twin services based on workflow technology, including the following steps:

[0058] S1: Build a digital twin resource management and service orchestration framework, and establish the process of accessing physical production equipment and servitizing its functions within the framework;

[0059] The digital twin resource management and service orchestration framework of this embodiment provides device operation functions and software component functions to the outside world in the form of microservices, and adopts a unified standard interface to provide service acquisition methods;

[0060] Each microservice function in the production system mainly comes from the capabilities of the actual resources mapped by the virtual manufacturing resources, including the manufacturing capabilities of physical equipment and the logical functions of the application. Manufacturing equipment can provide a variety of functional services for production, including equipment data collection services, equipment monitoring services, remote control services, troubleshooting and maintenance services, etc. However, since hardware equipment resources exist in physical space, and equipment from various manufacturers have differences in communication methods, data formats, etc., this will result in the need for physical hardware equipment to undergo protocol conversion and multiple abstractions in order to ultimately provide users or systems with a unified way to obtain equipment functional services. For example Figure 2 As shown, the process of accessing physical production equipment and servitizing functions in the framework constructed in this embodiment specifically includes:

[0061] The process of hardware device function service actually includes the entire process from device configuration construction to providing services for production. First, when a device is connected, it is necessary to determine whether it is a new device, that is, whether there is a declarative description model for the device. If the model does not exist, it is necessary to extract the device metadata, abstractly describe the status attributes, etc., and write a YAML file and upload it to the Kubernetes API interface; the controller creates an abstract and instance model of the device based on the description information in the YAML file and assigns it to the corresponding edge node; the SQLite database on the edge node will store the device metadata and attribute values; if the model already exists, the edge-side Mapper mapper will find the corresponding model and instance from the device model list based on the name and number of the connected device, and through protocol adaptation and conversion, the actual physical device and the device instance in the information space are mapped to each other. Based on collected device data and subscribed MQTT topics, the device twin component updates the actual state attribute values ​​of the device instance and uploads the data to cloud storage via the cloud-edge interaction component. Simultaneously, the device twin component continuously monitors changes in the desired state value from the device controller and synchronously adjusts the actual state value. The modified parameters or instructions are then transmitted back to the device control interface via the mapper, ensuring that the device operates as expected. To service-oriented control processes and data collection, software programs that manipulate the desired state values ​​need to be written in the cloud or edge and run as containers. This container will have operational rights to the device controller and can modify the state of the device instance. External users can access the corresponding device's functional services by accessing the host's IP address and the port number mapped to the container. By indirectly modifying the desired state value, users can remotely control the functional services on the device. Furthermore, the actual state data uploaded by the edge can be visualized and analyzed on the web.

[0062] S2: Digital twin service registration and discovery;

[0063] Digital twin service registration means that after a digital twin production instance is deployed and started, it registers its metadata (service name, IP address, port number, etc.) with the service registry so that other resource instances can discover and call services. Service discovery for manufacturing resource instances means that when an instance needs to call functional services provided by other instances, it can use the service discovery mechanism to find a list of available services and communicate with the corresponding services.

[0064] like Figure 3 As shown in the figure, the digital twin service network architecture is constructed. First, when software program instances or device control program instances are deployed and published in the digital twin service, the framework injects proxy descriptions into their declarative YAML files, automatically generating an Envoy proxy container during the pod instance formation process. Next, to service the physical hardware and software program functions, Kubernetes automatically registers the Service resource, which abstracts the pod instance functionality, in the CoreDNS registry. CoreDNS resolves DNS queries for all running services in the framework. When a manufacturing resource instance communicates with another, it uses the service name to resolve the instance's IP address, providing the foundation for service discovery. The control plane component that implements service discovery in Istio is primarily the Pilot. It manages service configuration and proxy modules for the data plane and distributes routing rules for service access to each Envoy proxy. Based on this, when a sender sends a request, the proxy module intercepts the request and forwards it to the target service based on the routing rules in the Envoy configuration. When the target service receives the request, it processes and transforms it through the proxy module, which then forwards the processed request to the resource instance for processing. Istio also provides Mixer's policy control capabilities and Citadel's security management capabilities. Working together, these components provide the framework's service mesh with rich service discovery, traffic management, and security management capabilities, making communication between digital twin services in production systems more reliable.

[0065] S3: Digital Twin Service Health Check;

[0066] like Figure 4As shown in the figure, the service health check and resilience recovery mechanism of the digital twin service resource management and service orchestration framework is constructed. Readiness probes and liveness probes periodically check the manufacturing resource instances providing services: service registration and discovery of ready resource instances; periodic monitoring of live instances; and restarting or repairing failed instances. When a manufacturing resource instance is diagnosed as faulty, it is restarted according to the restart policy specified in the declarative description. When the restart limit is reached, the framework automatically removes the instance. After the instance is removed, to ensure that the number of resource instance replicas in the framework remains unchanged and to provide stable digital twin functional services, the monitor continuously monitors the number of replicas of each resource type. When the number of replicas drops to the expected value specified in the declarative YAML file, the corresponding controller pulls the failed resource type from the virtual resource pool and redeploys it until the number of instances of that resource type reaches the expected value. This allows for rapid redistribution of the missing resource instances to horizontal worker nodes when an instance or even an entire worker node fails due to network issues or excessive workload. This ensures that in customized production, digital twin services have the ability to elastically recover from physical production system failures, allowing the system to quickly return to normal and provide high-quality, highly available digital twin services at all times.

[0067] S4: Build customized production business workflows;

[0068] To achieve customized production business goals, it is necessary to abstract and decompose the steps and collaborative relationships between steps in processes such as customer order business flow and product processing, thereby forming a customized production business workflow. The task execution module of each step is composed of microservices formed by manufacturing resource instances, and the relationship between task modules is described by BPMN. In order to combine the two to form a workflow-based service orchestration architecture, the task execution module in the client and the workflow engine Broker in the server mainly interact using a publish-subscribe model. When the task state in the Broker state machine changes, for example, when the task is in the active state, the Broker will publish the corresponding event. The task execution module will subscribe to the event in its own task queue in a long polling manner. After execution is completed, the result will be returned to the Broker, causing the task in the state machine to be transferred to the completed state.

[0069] like Figure 5The figure below illustrates the execution principle of the Zeebe workflow engine. The Zeebe client's active polling and subscription model further decouples task state maintenance from business logic execution. Because the same abstract functional service can consist of multiple resource instances, the server-side broker can adopt various resource instance execution schemes based on business logic. When there are many tasks, the broker can accumulate them in the task queue, while the client's resource instance can poll the queue for pending tasks at a relatively stable rate based on its own processing capabilities. Simultaneously, the workflow engine monitors the entire process and tracks any issues that arise.

[0070] S5: Build a customized production business process orchestration architecture;

[0071] Based on the execution mechanism of the Zeebe workflow engine, in a production environment, production business personnel can focus on product business workflow design, while developers can focus on the independent development of each task module, allowing teams to collaborate with each other on the basis of decoupling responsibilities, such as Figure 6 As shown in the figure, to enable flexible orchestration and customized production organization of manufacturing resource instances within the digital twin service, a customized production business process orchestration architecture is constructed. The Brokers component in the Zeebe server is deployed in the same manner as other resource instances, enabling distributed deployment and elastic management, resulting in extremely high availability. The Zeebe processor connects to cloud and edge clients via an RPC gateway. This process utilizes the gRPC protocol for interaction, maintaining persistent connections and enabling full-duplex communication between the cloud and edge, across domains and nodes. Subsequently, the service, abstracted from the functionalities of the resource instances, injects its API function interface into the cloud or edge client. The cloud broker simply associates a specific task execution module using the service name. It is important to note that to ensure efficient processing of production operations within the digital twin service, many task execution modules are presented as service blocks. This means that if multiple microservices have strong logical connections and the processes within the service blocks remain unchanged, the dependencies between them are preserved.

[0072] Combine Figure 6As shown, in this embodiment's personalized customization service and order payment service, after a customer places a customized order, the related payment is required, so the two can form a dependent service block. Once the customer's customization requirements are placed, the architecture can build or match the corresponding BPMN business process model based on the product's feature and behavior information. Then, based on the task execution modules of each link, resources are pulled from the virtual resource pool, deployed in the work node, and interconnected with the physical device. Finally, each module executes and provides feedback according to the process model execution order and logical association, thus completing the customized production of the order.

[0073] like Figure 7 As shown, based on the available services in the service registry and the BPMN business process model, a customized production business process model is constructed within the digital twin service. The overall logic of customized production within the digital twin service process is as follows: Customers customize products through the web order page. The order information is processed by the order service block, which returns the results. Next, the warehousing service queries and processes information such as product raw materials. Once the raw materials are available, specific sub-processes and steps are selected for processing based on the product's characteristics and behavior. For example, if the product information includes a requirement for laser engraving, during the printing phase, the workflow engine transmits the order information and invokes the laser printing service. The device twin component then operates the printer to print the printed text. Finally, after the order is processed, the product is shipped out of the warehouse. Furthermore, if an error message, such as a "downtime failure" signal, is detected during workflow execution, the workflow engine immediately interrupts the current sub-process and executes the sub-process that handles the error message.

[0074] like Figure 8 The figure below shows the execution process for the customized production task module for the commemorative disk. Each service module executes its own atomic logic, with no dependencies on each other. This decouples the design and construction of the business process from the development of the task service module. Therefore, once the required manufacturing resource instances have been deployed, production orchestrators can flexibly orchestrate and restructure processes in a low-code manner, using only the service names provided by the registry and the logical relationships between the modules in the production process. This allows for rapid reshaping of the system's production capabilities to accommodate the flexible changes required for customized production.

[0075] After building a customized production business process through the BPMN model, you can upload the model and deploy it to the Zeebe workflow engine in the cloud. After the deployment and registration service is completed in the manufacturing resource instance, the corresponding business workflow can be called and executed using the gRPC protocol based on the workflow engine's IP address, port number, and workflow instance name or ID. Figure 9As shown, the Zeebe workflow engine also provides a customized production business process visualization progress chart and records the execution history and flow parameters of each link.

[0076] The present invention further abstracts the manufacturing resource instance functions deployed in the working nodes to form microservices, and realizes service registration and discovery through service grid technology; describes the customized production business process by introducing the BPMN business process model; on this basis, combined with the workflow engine technology, proposes a customized production business process orchestration architecture to flexibly organize cross-domain and cross-node manufacturing resource instance services to complete customized production business, solve the elastic scaling management stability problem of manufacturing resource instances caused by the non-fixed request traffic received by each node in the production system, and solve the cross-domain and cross-node organization or reconstruction of production caused by the deployment of resources in digital twin services distributed on different nodes in the cloud or edge, meeting the requirements of high stability, high reconfiguration and high flexibility of manufacturing resources in digital twin services in customized flexible production.

[0077] The above embodiments are preferred implementation modes of the present invention, but the implementation modes of the present invention are not limited to the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications that do not deviate from the spirit and principles of the present invention should be considered as equivalent replacement methods and are included in the scope of protection of the present invention.

Claims

1. A flexible orchestration method for digital twin services based on workflow technology, characterized in that: The steps include: Build a digital twin resource management and service orchestration framework, and establish the process of accessing physical production equipment and servitizing its functions within the framework; Perform digital twin service registration and discovery; During the digital twin service registration and discovery steps, the digital twin service network architecture is constructed, which specifically includes: When a software program instance or device control program instance is deployed and released in the Digital Twin service, the Digital Twin service network architecture injects the proxy description into the corresponding declarative YAML file, automatically generating an Envoy proxy container during the process of forming a Pod instance. To service the functions of physical hardware and software programs, Kubernetes automatically registers the Service resources, which abstract the functions of resource Pod instances, in the CoreDNS registry. CoreDNS is used to resolve DNS queries for all running services in the digital twin service network architecture. When one manufacturing resource instance communicates with another, the service name is used to resolve the instance's IP address, providing a basis for service discovery. The Pilot component provides service configuration and proxy module management for the data plane, and distributes routing rules for service access to each Envoy proxy. When the sender sends a request, the proxy module intercepts the request and forwards the request to the target service according to the routing rules in the Envoy configuration. When the target service receives the request, it is processed and converted by the proxy module, and then the processed request is handed over to the resource instance for response processing; Build a service health check and elastic recovery mechanism for the digital twin service resource management and service orchestration framework. Based on readiness probes and survival probes, periodic checks are performed on manufacturing resource instances that provide services. Service registration and discovery are performed for ready resource instances. Surviving instances are periodically monitored, and failed instances are restarted or repaired. Abstract and decompose the steps in the customer order business flow and the product process and the collaborative relationship between the steps to form a customized production business workflow; Build a customized production business process orchestration architecture. Based on the available services in the service registry and the BPMN business process model, build a customized production business process model in the digital twin service to perform customized production in the digital twin service process. Upload and deploy the customized production business process model to the Zeebe workflow engine in the cloud, and call the corresponding business workflow execution using the gRPC protocol based on the workflow engine's IP address, port number, and workflow instance name or ID.

2. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: The digital twin resource management and service orchestration framework provides device operation functions and software component functions to the outside world in the form of microservices, and adopts a unified standard interface to provide service acquisition methods.

3. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: The process of accessing physical production equipment and servitizing its functions in the construction framework includes the following steps: When a device is connected, determine whether it is a new device, that is, whether there is a declarative description model for the device; If the model is determined to be non-existent, the device metadata is extracted, the state attributes are abstractly described, and a YAML file is compiled and uploaded to the Kubernetes API. The controller creates an abstract and instance model of the device based on the description in the YAML file and assigns it to the corresponding edge node. The SQLite database on the edge node stores the device metadata and attribute values. If it is determined that the model already exists, the Mapper at the edge will find the corresponding model and instance from the device model list based on the name and number of the connected device, and through protocol adaptation and conversion, map the actual physical device and the device instance in the information space to each other. Based on the collected device data and the subscribed MQTT topic, the device twin component updates the actual state attribute value of the device instance and uploads the data to the cloud storage through the cloud-edge interaction component; at the same time, the device twin component continuously monitors the changes in the expected state value from the device controller, and synchronously adjusts the actual state value, and then transmits the modified parameters or instructions back to the device control interface through the mapper, so that the device can operate according to the expected state.

4. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: After constructing the process of accessing physical production equipment and servitizing its functions in the framework, the expected state value modification step is also included, specifically including: Modify the expected state value in the cloud or edge and run it as a container. The container has the operation rights of the device controller and can change the device instance state. The user accesses the functional services of the corresponding device by accessing the host's IP address and the port number mapped by the container. By modifying the expected state value, the user can remotely control the functional services of the device.

5. The digital twin service flexible orchestration method based on workflow technology according to claim 1 is characterized in that: Register and discover digital twin services, including: After being deployed and started, the digital twin production instance registers its own metadata to the service registration center for other resource instances to discover and call services. When an instance calls a functional service provided by another instance, it uses the service discovery mechanism to find a list of available services and communicate with the corresponding service.

6. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: Restart or repair the faulty instance, including: When a manufacturing resource instance is diagnosed as faulty, it is restarted according to the restart policy in the declarative description. When the number of restarts reaches the upper limit, the framework removes the manufacturing resource instance. After manufacturing resource instances are eliminated, the number of replicas of each resource type is obtained. When the number of replicas drops to the expected value in the declarative YAML file, the corresponding controller pulls the failed resource type from the virtual resource pool and redeploys it until the number of instances of the resource type reaches the expected value.

7. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: Abstract and decompose the steps in the customer order business flow and the product process flow, as well as the collaborative relationships between the steps, to form a customized production business workflow, specifically including: The task execution module of each step is composed of microservices formed by manufacturing resource instances, and the relationship between task modules is described by BPMN; The task execution module in the client and the workflow engine Broker in the server interact in a publish-subscribe mode. When the task status in the workflow engine Broker state machine changes, the workflow engine Broker will publish the corresponding event. The task execution module subscribes to the events in its own task queue in a long polling manner. After the execution is completed, the result is returned to the workflow engine Broker, so that the task of the state machine is transferred to the completed state.

8. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: Build a customized production business process orchestration architecture, including: The Brokers component in the Zeebe server is distributedly deployed and elastically managed. The Zeebe processor connects to the cloud client and edge client through the RPC gateway, using the gRPC protocol to interact and maintain a persistent connection, and performs full-duplex information transmission and reception between the cloud and edge. For services formed by abstracting resource instance functions, their own API function interfaces are injected into the cloud or edge client; The Broker component in the cloud associates the specified task execution module through the service name.

9. The flexible orchestration method for digital twin services based on workflow technology according to claim 1 is characterized in that: Based on the available services in the service registry and the BPMN business process model, a customized production business process model is built in the digital twin service to carry out customized production in the digital twin service process, specifically including: The customized production business process orchestration architecture builds or matches the corresponding BPMN business process model based on the product's feature information and behavior information. Based on the task execution modules of each link, it pulls resources from the virtual resource pool, deploys them in the work nodes and interconnects them with physical devices. The customized production of the order is completed based on the execution sequence and logical association of the corresponding BPMN business process model.

Images