A configurable, modular, intelligent digital twin architecture for IoT operations that optimizes complex event processing.

Abstract

The described systems and methods may include, upon receiving the created digital twin, processing the created digital twin through a policy core process that determines policies for the digital twin; running an asset core process that determines an asset hierarchy for the physical assets represented by the digital twin based on the physical asset metadata retrieved from a metadata database and the determined policies; running a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from a sensor metadata database and the asset core process; running an analytics solution core that determines analytics solutions for the physical assets; building a pipeline to drive analytics solutions across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin; and running the pipeline.

Description

Technical Field

[0003]

[0001] The present disclosure generally relates to the Internet of Things (IoT) systems, and more specifically, to intelligent solutions for industrial Internet of Things (IIoT) applications for optimizing IoT operations by leveraging the power of data. The development of such solutions may include complex event processing of IoT systems.

Background Art

[0002] Although related art digital twin-based solutions are attractive, they require effort and time for effective deployment. Furthermore, current digital twin-based solutions lack effective and actionable business insights. There is a need for a configurable on-demand digital twin architecture that is modular and extensible to meet customer needs. A solution that standardizes and productizes digital twins along with actionable business insights enables new smart products. Such products can benefit greatly from configurable digital twin solutions based on machine learning. A modular architecture enables configurability by assembling the necessary modules to develop a solution. An extensible architecture enables deployment to a single computer, or a cluster of computers or a cloud environment. Furthermore, heterogeneous architectures with different computing resources are required.

[0003] In this implementation of the related technology, a digital twin of a twinned physical system exists, and one or more sensor values ​​allow the system to monitor the state of a selected part of the twinned physical system and access the remaining service life of the specified part. This implementation of the related technology uses the analysis of sensor values ​​from the twinned physical system to further run optimization software to identify optimal operational control and optimal operational implementation methods for the twinned physical system. This implementation of the related technology enhances mission placement, inspection, and maintenance scheduling tasks and can be extended to other types of digital twins.

[0004] Another implementation of the related technology is a hierarchical asset control system that relies on the identification of a list of devices. This implementation of the related technology works to determine the control paths between assets and identifies asset constraints so that smart agents can control the assets. The control system of the related technology is based on an intelligent asset-based template that is input after the system boundaries have been identified. The control system of the related technology includes a processor that, based on parent / child information, identifies the hierarchical arrangement of asset control relationships for the hierarchical asset control application by connecting each of the instantiated intelligent agents. [Overview of the project] [Means for solving the problem]

[0005] The exemplary implementations described herein relate to adaptive digital twins and their architectures, which can be used to develop configurable digital twins along with business policies that facilitate the rapid development of adaptive machine learning-based business solutions for complex event processing.

[0006] The exemplary implementation described herein includes a configurable modular architecture comprising four modules: an analytics solution core, a sensor core, an asset core, and a policy core. Inference and training pipelines are created on demand for complex event processing. The exemplary implementation can create multiple pipelines in the pipeline knowledge base and execute only event-based pipelines.

[0007] An Analytics Solution Core (ASC) represents a basic building block containing machine learning algorithms that can be used for several vertical applications. The ASC store stores the available algorithms according to the desired implementation. A Sensor Core provides actionable insights using one or more Analytics Solution Cores. A Sensor Core can take in real sensor data or virtual sensor data calculated by simple or complex algorithms / software, according to the desired implementation. An Asset Core represents a target physical asset and connects to the relevant Sensor Core depending on the sensor associated with that particular asset.

[0008] The output of the asset core module is ingested by the policy core, providing actionable insights that can be used with machine learning algorithms such as reinforcement learning or optimization algorithms. Furthermore, the policy core manages the creation of new pipelines with asset cores, sensor cores, and ASCs for training or inference, while allocating computing resources to the new pipelines.

[0009] In exemplary implementations, each layer (policy core, asset core, sensor core, ASC) can be multi-level. For example, an analytics solution core module can be multi-level by arranging several analytics solution cores in series. In another example, a digital twin asset can be multi-level by having a parent unit with multiple subcomponents. Data flow can occur either by being directly input to a module or sent from a parent module, depending on the desired implementation.

[0010] A part of the disclosure includes a method that, upon receiving the created digital twin, includes processing the created digital twin through a policy core process that determines the policy of the digital twin; executing an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin based on the metadata of the physical assets retrieved from a metadata database and the determined policy; executing a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from a sensor metadata database and the asset core process; executing an analytics solution core that determines an analytics solution for the physical assets based on the metadata database and the sensor core process; constructing a pipeline to facilitate the analytics solution across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin; and executing the pipeline with computing resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API).

[0011] Aspects of this disclosure include a computer program that stores instructions, which, upon receiving a composed digital twin, includes processing the created digital twin through a policy core process that determines the policy of the digital twin; executing an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin based on metadata of the physical assets retrieved from a metadata database and the determined policy; executing a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on sensor metadata retrieved from a sensor metadata database and the asset core process; executing an analytics solution core that determines an analytics solution for the physical assets based on the metadata database and the sensor core process; constructing a pipeline to facilitate the analytics solution across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin; and executing the pipeline using computing resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API). The computer program and instructions are stored on a non-temporary computer-readable medium and may be executed by one or more processors.

[0012] Aspects of this disclosure may include a system that, upon receiving a created digital twin, includes means for processing the created digital twin through a policy core process that determines the policy of the digital twin; means for executing an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin based on metadata of the physical assets retrieved from a metadata database and the determined policy; means for executing a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from a sensor metadata database and the asset core process; means for executing an analytics solution core that determines an analytics solution for the physical assets based on the metadata database and the sensor core process; means for constructing a pipeline to facilitate an analytics solution across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin; and means for executing the pipeline using computing resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API).

[0013] Aspects of the disclosure may include a memory configured to store instructions and a processor configured to execute the stored instructions, wherein the instructions may include an apparatus that, upon receiving a composed digital twin, processes the created digital twin through a policy core process that determines the policy of the digital twin; executes an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin based on metadata of the physical assets retrieved from a metadata database and the determined policy; executes a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from a sensor metadata database and the asset core process; executes an analytics solution core that determines an analytics solution for the physical assets based on the metadata database and the sensor core process; constructs a pipeline to facilitate the analytics solution across the policy core layer, asset core layer, sensor core layer and analytics solution core layer of the digital twin; and executes the pipeline using computing resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API).

[0014] Aspects of this disclosure may include a system comprising: a meta-policy core actor configured to generate policies for a digital twin; an asset core managing asset core templates configured to instantiate asset core actors in an asset hierarchy of physical assets represented by a digital twin based on metadata of physical assets and policies generated by the meta-policy core actor; a sensor core managing sensor core templates that instantiate one or more sensor actors in a sensor hierarchy based on a metadata database and ingest physical or virtual sensor data from the database; an analytics solution core managing analytics solution core templates that instantiate one or more analytics solution core actors and train or infer analytics solutions based on metadata and sensor data received through the sensor hierarchy; and a pipeline constructor configured to build pipelines to facilitate analytics solutions across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of a digital twin, and to build additional pipelines or destroy specific pipelines at runtime execution of the pipelines. [Brief explanation of the drawing]

[0015] [Figure 1] Figure 1 shows an example of a mixed-use industrial facility with multiple assets arranged in a hierarchical structure.

[0016] [Figure 2] Figures 2(A) to 2(C) show examples of schematic diagrams of typical processes in a manufacturing plant.

[0017] [Figure 3] Figure 3 is a schematic diagram of a four-tier architecture consisting of a policy core, asset core, sensor core, and analytics solution core, following an exemplary implementation.

[0018] [Figure 4]Figure 4 shows an example of a four-layer architecture having (a) a policy core, (b) an asset core, (c) a sensor core, and (d) an analytics solution core according to an exemplary implementation form.

[0019] [Figure 5] Figure 5 shows an example of a schematic diagram of the interaction between a policy core, an asset actor, an operation environment, a monitoring dashboard, a business action, and an IoT database and the policy core according to an exemplary implementation form.

[0020] [Figure 6] Figure 6 shows an example of a flow of the architecture of a heuristic-based engine for a meta-policy actor according to an exemplary implementation form.

[0021] [Figure 7] Figure 7 shows an example of a flow of the architecture of an operation process of an LSTM-based engine for a meta-policy actor according to an exemplary implementation form.

[0022] [Figure 8] Figure 8 shows an example of a schematic diagram of components of an asset core template and a sensor core template according to an exemplary implementation form.

[0023] [Figure 9] Figure 9 shows an example of a schematic diagram of components of an ASC core template according to an exemplary implementation form.

[0024] [Figure 10] Figure 10 shows an example of a solution operation process for pipeline execution according to an exemplary implementation form.

[0025] [Figure 11] Figure 11 shows an example of a solution operation process for monitoring with a single ASC according to an exemplary implementation form.

[0026] [Figure 12] Figure 12 shows an example of a solution operation process for handling complex events, following an exemplary implementation.

[0027] [Figure 13] Figure 13 shows an example of an application scenario following an exemplary implementation.

[0028] [Figure 14] Figure 14 shows an example of a manufacturing process problem in a normal operation case, following an exemplary implementation. [Figure 15] Figure 15 illustrates an example of a manufacturing process problem in which a small number of robots are not functioning on the workstation, following an exemplary implementation configuration. [Figure 16] Figure 16 shows an example of a manufacturing process problem in which one of the workstations is not functioning, following an exemplary implementation configuration.

[0029] [Figure 17] Figure 17 shows an example of an execution environment following an exemplary implementation.

[0030] [Figure 18] Figure 18 shows an example of another execution environment following an exemplary implementation.

[0031] [Figure 19] Figure 19 shows a system that includes numerous assets connected to a management device via a network, following an exemplary implementation.

[0032] [Figure 20] Figure 20 shows an exemplary computing environment with exemplary computer equipment suitable for use in several exemplary implementation forms. [Modes for carrying out the invention]

[0033] The following detailed description provides further details of the drawings and implementation examples of this application. Reference numbers and descriptions of redundant elements between drawings have been omitted for clarity. Terms used throughout this description are provided as examples and are not intended to limit the scope. For example, the use of the term “automatic” may include a fully automatic implementation or a semi-automatic implementation with user or administrator control in a particular aspect of the implementation, depending on the desired implementation of a person skilled in the art. Selection may be made by the user through a user interface or other input means, or through a desired algorithm. Exemplary implementations described herein may be used individually or in combination, and the functions of the implementation examples may be implemented by any means according to the desired implementation.

[0034] Industrial systems have several components and a highly complex hierarchical structure. Damage, failure modes, or events in one component can affect other components and, ultimately, the entire system. Intelligent management of IIoT systems requires understanding the combined effects of every event. Therefore, to effectively manage the entire system, a digital twin-based IIoT management software system is necessary to address such complex systems and events. Building such a digital twin-based system is extremely difficult due to the complexity of the software architecture and the types of models required.

[0035] Different components of a system require different types of models. Such models can be purely data-driven, purely physical, or a hybrid of both. These models can be used to gain actionable insights by gaining a deep and intelligent understanding of the data through analyzing event patterns, event filtering, event transformation, or event hierarchy to determine the causal relationships between events.

[0036] Combining such a diverse range of models into a complex digital twin system is extremely challenging. Further complicating matters is the need for streaming data from component sensors, the differing data needs of each component model, and the varying computational resources required depending on the model's nature. Enabling such complex event processing requires a modular, composable digital twin software architecture that enables this processing and reduces development time and time to market for various industrial customers. A repeatable architecture is necessary to model both static physical assets and dynamic processes. Digital twin architectures in related technologies tend to focus on one or the other, but not both. Furthermore, to deliver high business value with a high return on investment, an architecture that encourages standardization and reduces time to market is necessary.

[0037] In the example of the first problem, there is an industrial facility with several assets and a potential digital twin model for IIoT operations and complex event processing.

[0038] Figure 1 illustrates an example of a complex industrial facility with multiple assets in a hierarchical structure. Each asset benefits from processing using different types of analytical algorithms, such as anomaly detection and fault detection. The characteristics of this problem are as follows: The objective may be operational improvement and effectiveness. The challenge may be unraveling both the data network and the system and process network. The value offered is that a modular, manufacturable digital twin architecture can significantly reduce the time to deploy artificial intelligence-based solutions for IIoT applications. The types of models included may include physical models, probabilistic models, and machine learning (ML) models.

[0039] An example of the second problem could be a manufacturing process problem. Figures 2(A) to 2(C) show example schematic diagrams of a typical process in a manufacturing plant. Specifically, Figure 2(A) shows an example of normal operation, Figure 2(B) shows an example where a few robots are not operating, and Figure 2(C) shows an example where one station is not operating. During normal operation, all robots are operating. However, during downtime, a scenario occurs where a specific robot or a specific station is not operating. A digital twin software system needs to dynamically adapt to such scenarios, which are lacking in the current architecture. In the example in Figures 2(A) to 2(C), there is a manufacturing plant where unfinished products enter the assets on the left and move to the right. The plant has three stations 1, 2, and 3, each with three robots 1, 2, and 3 installed. Regarding the operating modes of the manufacturing plant, Figure 2(A) shows an operating mode in which all stations and robots are operational, Figure 2(B) shows an operating mode in which one robot at each station is not operational due to an unexpected failure, and Figure 2(C) shows an operating mode in which one of the stations is completely offline.

[0040] In the examples in Figures 2(A) to 2(C), the digital twin system needs to be able to monitor failure modes such as mechanical failure and performance degradation. If one or more robots or stations fail, the digital twin system needs to be able to create a new solution that reflects the new set of assets. Furthermore, the digital twin needs to be able to handle complex event processing, where a single event or failure mode triggers additional processing to further verify the failure mode and identify defects in the related components.

[0041] Figure 3 is a schematic diagram of a four-tier architecture having a policy core, asset core, sensor core, and analytical solution core, according to an exemplary implementation. The exemplary implementation described herein creates four abstraction or modular layers, which can be developed independently and can interact with or inherit from each other to generate a modular architecture. These four layers include the policy core, asset core, sensor core, and analytical solution core. Together, the cores can be used to create solutions for any vertical application, such as power, oil and gas, rail, healthcare, and mining, according to the desired implementation.

[0042] As described herein, a pipeline is defined as a set of policy cores, asset cores, sensor cores, and analytics solution cores combined to compute business outcomes. The modular architecture in this disclosure has the following characteristics:

[0043] Creativity: The architecture should make it easy to create computation pipelines to meet the requirements for changing physical assets, either statically or dynamically. Static means creating the digital twin pipeline before starting the software, while dynamic means modifying the pipeline as needed while the digital twin software is running.

[0044] Reusability: Cores must be reusable. Core reuse accelerates time to market and significantly reduces development costs.

[0045] Scalability: Each core can expand its capabilities by integrating with additional cores.

[0046] Combinability: Where necessary, cores must be willing to be combined in series or parallel to build pipelines. Such combinationability includes parallelism at the module level, scalability via the cloud, and enables necessary governance in accordance with business needs or government regulations (e.g., GDPR).

[0047] Figure 4 shows a four-level architecture following an exemplary implementation. The control entity 400 enables four-tier orchestration for processing IoT data 401. Depending on the desired implementation, the control entity may also be part of the policy core 410.

[0048] The policy core 410 is an intelligent engine that, once the results are processed, determines the next possible recommendation and shares the insights gained on a dashboard so that users can gain further insights and knowledge about the system. The policy core 410 also instantiates one or more policy actors 412 using the compute resource composer 411 and the constructible pipeline knowledge base 413. Further details of the policy core 410 are provided with reference to Figure 5.

[0049] The asset core 420 instantiates one or more asset actors 421 to represent the asset hierarchy of the physical assets of the underlying system. Further details of the asset core 420 are provided with respect to Figure 10(A). The sensor core 430 instantiates one or more sensor actors 431 to represent the sensor hierarchy derived from the asset hierarchy. Further details of the sensor core 430 are provided with respect to Figure 10(B). The ASC 440 instantiates one or more ASC actors 441 to run the analysis solution. Further details of the ASC 440 are provided with respect to Figure 11.

[0050] Figure 5 shows an example schematic diagram of the interaction between the policy core and asset actors, computing environments, monitoring dashboards, business actions, and IoT databases, following an exemplary implementation.

[0051] The structure of the policy core 410 includes a meta-policy actor 500 that interacts with other policy cores, a pipeline composer 501, and a metadata store containing information about sensor cores, pipelines, ASCs, and assets. The meta-policy actor 500 also interacts with asset actors, computing resources, business action application programming interfaces (APIs) 502, monitoring dashboard APIs 503, or operation control APIs.

[0052] The policy core 410 can instantiate and execute new pipelines based on observed events and results. To start any new pipeline, the policy core 410 performs a series of actions, including identifying possible analytical solution cores and then identifying all possible assets, data, and metadata related to the new analytical pipeline. The policy core 410 is also aware of all available resources (hardware, software, and computing time) and calculates the optimal combination of resources and computing power, giving the time constraints necessary to obtain the desired insights. Depending on the desired implementation, the policy core 410 can be multi-level. For example, the output of an alert optimizer may be sent to a business policy algorithm to provide actionable insights.

[0053] Each policy core 410 can build and run an analytics pipeline that may include asset cores, sensor cores, and ASC cores. The meta-policy core template is a standardized codebase that can be reused to instantiate asset actors at runtime. It may have multiple engines, such as a heuristic engine or a deep learning-based reinforcement learning engine, to make decisions in business insights or additional pipeline generation according to the desired implementation form.

[0054] Depending on the desired implementation, the meta-policy actor 500 and policy actors may be multi-level. The meta-policy actor 500 may be connected to other meta-policy actors or policy actors. A policy actor may be connected to one or more other policy actors or asset actors. Furthermore, the meta-policy actor 500 may be connected to the pipeline composer 501 and the computing resource composer 411.

[0055] Policy Core's intelligence algorithms include, but are not limited to, heuristic-based / deep learning-based reinforcement learning algorithms for defining business actions or triggering the construction / execution of new pipelines, and / or optimization algorithms for optimizing process parameters to maximize the yield of manufacturing processes.

[0056] In the example in Figure 5, the pipeline construction process is as follows: In step 1, the metapolicy actor 500 monitors a specific pipeline and determines whether a new pipeline is needed for detection / prediction to generate further business value. In step 10, the metapolicy actor 500 sends monitoring information to a monitoring dashboard, provides feedback on any events to the user, and obtains any user input regarding new pipelines as needed. In step 6, the metapolicy actor 500 sends metadata to build the pipeline based on the monitoring results and business needs. In step 61, the pipeline composer 501 sends the new pipeline metadata to the metapolicy actor 500. In step 2, the metapolicy actor 500, based on the data obtained from the pipeline composer 501, sends the necessary computing resources to the pipeline, such as those calculated using IoT data store and ASC store data, and provides them to the computing resource composer 411.

[0057] In step 9, the computing resource composer 411 sends relevant information to the computing environment 504 for the creation or confirmation of the desired environment. In step 91, the computing environment 504 sends confirmation of the availability of the desired computing environment. In step 21, the computing resource composer 411 sends confirmation of the computing resources to the metapolicy actor 500.

[0058] In step 11, the meta-policy actor 500 spins a new policy actor to build a new pipeline. Further details are provided in Figure 12. As shown in Figure 12, in step 3, the meta-policy actor 500 builds a new pipeline consisting of asset actors, sensor cores, and ASC actors, using the pipeline composer 501, the meta-policy actor 500, and metadata from IoT data as needed. The pipeline uses a directed acyclic graph (DAG) architecture, which can be implemented using parallel distributed computing tools. In step 12, the asset actor collects asset hierarchy information from the IoT asset hierarchy store to create the pipeline.

[0059] Figure 6 shows an example flow of the architecture of a heuristic-based engine for a metapolicy actor, following an exemplary implementation. First, the metapolicy actor 500 continuously monitors the asset pipeline at 700 and filters received signals and results as significant events at 701. The filtered events and metastore are then used collectively to gain further insights into the events (e.g., what the associated key performance indicators (KPIs) are, or which assets contribute most to the signal) by reading the KPI / asset metadata at 702. At 703, once the assets and associated KPIs are understood along with the signal, the associated business rules at 720 are captured. Subsequently, the metapolicy actor 500 evaluates whether a signal was received and determines at 704 whether it is within the normal range or whether the KPI requires optimization. Based on the evaluation, the next action is identified, and the metapolicy actor 500 provides monitoring data at 705.

[0060] Subsequently, in 706, the meta-policy actor 500 continues to monitor the assets to gain further insights. Another possible outcome is the provision of a list of affected assets and KPIs, along with associated actions, in 708, along with the provision of insights in 707. In another possible outcome, a decision is made in 710, and in 711, a new optimized pipeline is created with the help of the list of actions and business heuristics in 709.

[0061] Figure 7 shows an example of the architecture flow of the operation process of an LSTM-based engine for a metapolicy actor, following an exemplary implementation. In the example flow of the Long-Term Short-Term Memory (LSTM)-based engine for the metapolicy actor 500, first, the metapolicy actor 500 continuously monitors the asset pipeline at 800 and filters the received signals and results as significant events at 801. Next, at 802, the filtered events and metastore are used collectively, and at 803, the LSTM-based engine provides further insights about the events (e.g., what the associated KPIs are or which assets contribute most to the signal). Further insights may be derived from the signals with the help of a pre-trained neural network and business actions. Then, at 804, the metapolicy actor 500 may continue monitoring assets to obtain further insights, depending on the desired implementation. For further actions, at 805, the metapolicy actor 500 uses explainable AI to create a list of actions based on the insights obtained through the neural network. Another possible outcome is that, if it is determined in 806 that no additional pipeline is needed according to the desired implementation, business insights are provided to the user in 807 with the help of possible actions for business optimization. Further improvements to the system may be provided by executing another pipeline in 808 if it is determined in 806 that an additional pipeline is needed.

[0062] Figure 8 shows an example schematic diagram of the components of the asset core template and sensor core template according to an exemplary implementation. The asset core template 901 is a standardized codebase that can be reused to instantiate asset actors at runtime. Asset actors can consist of multiple layers. Depending on the desired implementation, an asset actor may be connected to one or more sensor actors, one or more other asset actors, and / or policy actors. Depending on the desired implementation, the template may include, but is not limited to, an asset failure mode analyzer, compatible sensor core metadata, an asset pipeline generator, an API from the asset core to the policy core, an API from the asset core to the sensor core, and a data transfer API to and from IoT data sources.

[0063] Sensor Core Template 902 is a standardized codebase that can be reused to instantiate sensor actors at runtime. Sensor core actors can be in multiple layers. A single sensor actor may be connected to one or more ASC actors, one or more other sensor actors, and / or asset actors, depending on the desired implementation. Depending on the desired implementation, the template may include, but is not limited to, various libraries such as sensor-specific feature engineering, compatible ASC analysis metadata, ASC pipeline generators, APIs from sensor cores to asset cores, APIs from sensor cores to ASC cores, and data transfer APIs to and from IoT data sources.

[0064] Figure 9 shows an example schematic diagram of the components of an ASC core template, following an exemplary implementation. The ASC core 1001 is like a class in object-oriented programming and has the blueprint of algorithms for its analysis solution. The ASC core class may include several subclasses for performing data reading, data processing, feature engineering, model training, and / or inference from the developed model. Furthermore, this class may have appropriate flags for training or inference depending on the metadata sent from the sensor core. While generating the pipeline, the policy actor generates the ASC actor by retrieving the ASC core and passing the metadata necessary to create the ASC actor.

[0065] Figure 10 shows an example of a solution operation process for pipeline execution, following an exemplary implementation. Regarding the pipeline operation process, in 1101, the meta-policy actor 500 sends a message to the appropriate policy actor for execution. In 1103, the policy actor executes the asset actor pipeline. In 1104, the asset actor executes the sensor actor according to the pipeline. In 1115, the sensor data is accessed by the sensor actor according to the ASC of the created pipeline. In 1105, the sensor actor sends data to the ASC and executes the ASC actor. In 1113, the ASC actor receives operational information and other IoT data from the IoT data store. In 1114, the ASC actor sends data related to transfer learning to the IoT store.

[0066] In step 1105, the ASC actor calculates the result and sends it to the sensor core. In step 1104, the sensor actor calculates the result and sends it back to the asset actor. In step 1103, the asset actor aggregates and calculates the result and sends an event to the policy actor. In step 1101, the policy actor sends event information to the meta-policy actor 500. In step 1108, the meta-policy actor 500 sends all action triggers to the business action API 502 based on the algorithm being executed. In step 1110, the meta-policy actor 500 sends event information to the monitoring dashboard 503 for user consumption.

[0067] Figure 11 shows an example of a solution operation process for monitoring with a single ASC, following an exemplary implementation. In a monitoring process with a single ASC, the metapolicy actor 500 will run one or more pipelines for monitoring assets. The example in Figure 11 shows an example of monitoring with a single pipeline.

[0068] The monitoring process and data flow are as follows: At 1215, the sensor core receives asset sensor data indicating whether sensor data or virtual sensor data should be processed by the ASC actor. At 1213, the ASC actor receives motion data from the IoT store. At 1205, the ASC actor sends a detection or prediction to the sensor core.

[0069] In step 1204, the sensor core sends event information to the asset actor. In step 1203, the asset actor sends event information to the policy actor. In step 1210, the meta-policy actor 500 sends monitoring information to the monitoring dashboard 503. In step 1208, the meta-policy actor 500 sends a business action 502 based on a pre-built algorithm.

[0070] Figure 12 shows an example of a solution operation process for handling complex events, following an exemplary implementation.

[0071] In an example of event-driven composite event processing, the system monitors assets using a specific monitoring pipeline. Based on a specific event, the metapolicy actor 500 may spin additional pipelines at runtime to calculate additional parameters such as the remaining service life of the same component, the health score of the related component, and derive actionable insights.

[0072] The Event 1 pipeline (dashed line) responds to Event 1, which the metapolicy actor begins creating to calculate additional parameters. In this case, the Event 1 pipeline is for the same asset being monitored. The Event 2 pipeline (bold line) is triggered on a different asset based on an event on the monitored asset. In addition, depending on the desired implementation, multiple pipelines may be triggered in parallel in response to the results of monitoring alerts or a combination of monitoring alerts and previous event pipelines.

[0073] Figure 13 shows an example of an application scenario following an exemplary implementation. In the example application scenario, at 1301, the monitoring asset core sends a request to the sensor core to start the ASC pipeline to monitor the motors of the underlying system. The request may be change-based or time-based. At 1302, the sensor core collects metadata for the necessary data and identifies and creates the correct data structure for the ASC related to the motors. At 1303, the ASC collects data from the IoT data store and ensures that the most up-to-date data is used to run the ASC. Furthermore, if applicable, previously deployed models may be used for transfer learning. After execution, the ASC returns insights to the IoT data store and the sensor core. At 1304, the sensor core stores the metadata in the IoT data store for future use. At 1305, the sensor core shares the results calculated by the ASC with the asset actor. At 1306, the asset actor shares the results with the policy agent, which has the role of understanding the results and identifying the next steps to take based on the results. In 1307, the policy agent shares insights about the system on the monitoring dashboard. In 1308, the policy agent initiates the creation of a new pipeline to calculate the gearbox's remaining service life, if recommended by the monitoring pipeline. To facilitate creation, the policy agent looks at both the available hardware resources and the pipeline composer that monitors system resources. In 1309, the new remaining service life pipeline is triggered. In 1310, the predictive asset actor initiates the pipeline by gathering information about the gearbox and identifies whether the results from the monitoring pipeline can be used as features for the predictive pipeline.

[0074] Figures 14–16 illustrate an example of a manufacturing process problem with three scenarios, each following an exemplary implementation: normal operation, a small number of robots not functioning on the workstation, and one of the workstations not working. The digital twin architecture needs to adapt to such scenarios and modify the digital twin according to the most up-to-date physical assets that are functioning. This disclosure addresses this problem by having the metapolicy core dynamically modify the pipeline according to the scenario, as shown in Figures 14–16. The three types of digital twins corresponding to each scenario are shown in Figures 14–16.

[0075] Figure 17 shows an example of an execution environment following an exemplary implementation. In the example execution environment in Figure 17, there is an execution environment 1700 which can be any execution environment (e.g., a Kubernetes cluster) following a desired implementation.

[0076] The distributed parallel environment builder 1701 builds and manages clusters according to instructions from the policy core runtime 1702. The policy core runtime 1702 includes meta-policy actors and the centerpiece of orchestration by policy actors. The digital twin composer 1703 includes composers, metadata stores, and asset / sensor / ASC core templates. The ML flow model store 1704 is a model store with pre-developed models. The user input API 1705 provides user input to the meta-policy store. The user API provides APIs for the visual dashboard 1706 and storage 1707. The operation control system API 1708 provides instructions to control the system for further actions according to the operation system algorithm. The business action AP 1709 is an application performance management (APM) alert system for maintenance, repairs, etc. The model server 1710 can execute models based on IoT data received from IoT devices 1711.

[0077] Figure 18 shows an example of another execution environment following an exemplary implementation. The example execution environment in Figure 18 includes a parallel distributed solution with multiple nodes 1801, 1802, and 1803 instead of the model server. By using a modular architecture that enables parallel distributed computing, the exemplary implementation can utilize all available resources in the computing environment, execute multiple pipelines and resources in parallel, and the results can be aggregated by a parallel results aggregator 1804 for computation. The core template-based architecture ensures that each pipeline is built and then processed independently, while optimally utilizing available computing resources.

[0078] Throughout the exemplary implementations described herein, it is possible to facilitate complex event processing for IIoT systems, standardization of the asset core computing framework to deliver business value, and the flexibility to reuse ASC, sensor cores, and asset cores for new assets and customers. Furthermore, the exemplary implementations described herein facilitate the creation of new solutions from existing modules, extend computing from a single computer to multiple computers and cloud infrastructure with minimal or no changes, provide standardization of analytics for rapid deployment, significantly reduce the time to solution deployment, and enable non-experts to perform deployment tasks.

[0079] Figure 19 shows a system including numerous assets networked to a management device, according to an exemplary implementation. One or more assets 1901 are communicably connected to a network 1900 (e.g., a local area network (LAN), a wide area network (WAN)) via the corresponding onboard computer or Internet of Things (IoT) device of the asset 1901, and this network 1900 is connected to a management device 1902 that facilitates a digital twin of the model or assets. The management device 1902 manages a database 1903 containing historical data collected from the assets 1901 and also facilitates remote control of each asset 1901. In an alternative exemplary implementation, data from assets may be stored in a central repository or central database, such as a proprietary database that ingests the data, or in a system such as an enterprise resource planning system, and the management device 1902 can access or retrieve data from the central repository or central database. Asset 1901 may include any physical systems for use in physical processes such as assembly lines or production lines, in a desired implementation form, and may include, but are not limited to, air compressors, lathes, robotic arms, etc., in a desired implementation form. Data provided from sensors of such Asset 1901 may serve as a data flow on which analyses such as those described herein can be performed.

[0080] , The system in Figure 19 may include an underlying physical system on which physical processes can be carried out. Depending on the desired implementation, the physical system and physical processes may be represented by representations of the sensor core layer, asset core layer, ASC core layer, and policy core layer, as described herein. In the exemplary implementation of the system in Figure 19 and a truck production line that may be used as the subject of the represented digital twin, the physical processes may include two parts: namely, asset 1901 and its hierarchies, and the physical processes for assembling the trucks.

[0081] Figure 20 shows an exemplary computing environment having exemplary computer equipment suitable for use in several exemplary implementation forms, such as the management device 1902 shown in Figure 19, or the onboard computer of asset 1901. The computer equipment 2005 of the computing environment 2000 may include one or more processing units, cores, or processors 2010, memory 2015 (e.g., RAM, ROM, and / or similar), internal storage 2020 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interfaces 2025, any of which may be connected on a communication mechanism or bus 2030 for information and communication, or embedded in the computer equipment 2005. The I / O interface 2025 may also be configured to receive images from a camera or provide images to a projector or display, depending on the desired implementation form.

[0082] Computer device 2005 may be communicatively connected to input / user interface 2035 and output device / interface 2040. One or both of input / user interface 2035 and output device / interface 2040 may be wired or wireless interfaces and may be detachable. Input / user interface 2035 may include any physical or virtual devices, components, sensors, or interfaces that can be used to provide input (e.g., buttons, touchscreen interfaces, keyboards, pointing / cursor controls, microphones, cameras, Braille, motion sensors, optical readers, and / or similar). Output device / interface 2040 may include displays, televisions, monitors, printers, speakers, Braille, or similar. In some exemplary implementations, input / user interface 2035 and output device / interface 2040 may be embedded in or physically connected to computer device 2005. In other exemplary implementations, other computer devices may function as or provide the input / user interface 2035 and output device / interface 2040 of computer device 2005.

[0083] Examples of computer devices 2005 may include, but are not limited to, highly mobile devices (e.g., smartphones, devices mounted in vehicles or other machines, devices carried by humans or animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for portability (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded and / or coupled to one or more processors, wireless equipment, and the like).

[0084] Computer device 2005 may be communicably connected to external storage 2045 and network 2050 (for example, via I / O interface 2025) to communicate with any number of network-connected components, devices, and systems, including one or more computer devices of the same or different configurations. Computer device 2005 or any connected computer devices may function as a server, client, thin server, general-purpose machine, special-purpose machine, or whatever label they may be, or may be referred to as such.

[0085] I / O Interface 2025 may include, but is not limited to, wired and / or wireless interfaces using any communication or I / O protocol or standard (e.g., Ethernet, 802.11x, Universal System Bus, WiMAX, modem, cellular network protocol, and similar) for information communication between at least all connected components, devices, and networks within the computing environment 2000. Network 2050 may be any network or combination of networks (e.g., the Internet, local area network, wide area network, telephone network, cellular network, satellite network, and similar).

[0086] Computer equipment 2005 may use and / or communicate using computer-available or computer-readable media, including temporary and non-temporary media. Temporary media include transmission media (e.g., metal cables, optical fibers), signals, carrier waves, and the like. Non-temporary media include magnetic media (e.g., disks and tapes), optical media (e.g., CD-ROMs, digital video discs, Blu-ray discs), solid-state media (e.g., RAM, ROMs, flash memory, solid-state storage), and other non-volatile storage or memory.

[0087] Computer device 2005 may be used in several exemplary computing environments to implement techniques, methods, applications, processes, or computer executable instructions. Computer executable instructions may be retrieved from temporary media, stored on non-temporary media, and retrieved from non-temporary media. Executable instructions may be generated from one or more programming languages, scripting languages, and machine languages ​​(e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

[0088] Processor 2010 can run under any operating system (OS) (not shown) in a native or virtual environment. One or more applications may be deployed, including a logical unit 2060, an application programming interface (API) unit 2065, an input unit 2070, an output unit 2075, and an inter-unit communication mechanism 2095 for different units to communicate with each other, the OS, and other applications (not shown). The units and elements described may vary in design, function, configuration, or implementation, and are not limited to the description provided. Processor 2010 may take the form of a hardware processor, such as a central processing unit (CPU), or a combination of hardware and software units.

[0089] In some exemplary implementations, when information or execution instructions are received by the API unit 2065, that information or execution instructions may be transmitted to one or more other units (e.g., a logical unit 2060, an input unit 2070, and an output unit 2075). In some examples, the logical unit 2060 may be configured to control the flow of information between units and direct the services provided by the API unit 2065, the input unit 2070, and the output unit 2075 in some exemplary implementations described above. For example, the flow of one or more processes or implementations may be controlled by the logical unit 2060 alone or in conjunction with the API unit 2065. The input unit 2070 may be configured to obtain input for computations as described in the exemplary implementations, and the output unit 2075 may be configured to provide output based on computations as described in the exemplary implementations.

[0090] Processor 2010 may be configured to execute instructions or methods that, upon receiving a created digital twin, include processing the created digital twin through a policy core process that determines the policy of the digital twin; executing an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin based on the metadata of the physical assets retrieved from a metadata database and the determined policy; executing a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from a sensor metadata database and the asset core process; executing an analytics solution core that determines an analytics solution for the physical assets based on the metadata database and the sensor core process; constructing a pipeline to facilitate the analytics solution across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin; and executing the pipeline using computing resources to determine key performance indicator (KPI) values ​​provided to the application programming interface (API).

[0091] The processor 2010 may be configured to execute instructions or methods that, when an event is detected, may include triggering the automatic construction of additional pipelines based on the execution of the pipeline.

[0092] Processor 2010 may be configured to execute instructions or methods that include executing an asset core process, which includes executing an asset core template based on metadata of physical assets and determined policies to instantiate one or more asset core actors to form an asset hierarchy, connecting one or more asset core actors to one or more policy core actors based on determined policies, connecting one or more asset core actors to one or more other asset core actors to build an asset hierarchy, and providing KPI values ​​to one or more policy core actors.

[0093] Processor 2010 may be configured to execute instructions or methods that include executing a sensor core process, which includes executing a sensor core template based on a metadata database to instantiate one or more sensor core actors as a sensor hierarchy; connecting one or more sensor core actors to one or more asset core actors based on an asset hierarchy; connecting one or more sensor core actors to one or more other sensor core actors to build sensor dependencies; supplying physical or virtual sensor data to one or more sensor core actors from a database or from one or more other sensor core actors; supplying metadata to one or more sensor core actors from a metadata database or from one or more asset core actors; and providing KPI values ​​to one or more asset core actors.

[0094] Processor 2010 may be configured to execute instructions or methods that include the execution of an analytical solution core process on a metadata database to instantiate one or more analytical solution core actors, supplying physical or virtual sensor data from one or more sensor core actors, and training or inferring an analytical solution based on metadata received through the sensor hierarchy, the one or more analytical solution core actors writing metadata to the database, and KPI values ​​being provided to one or more sensor core actors.

[0095] Processor 2010 may be configured to execute a method or instruction that, when it detects one or more events associated with one or more assets from the asset hierarchy from monitoring KPI values, further includes generating additional pipelines during runtime execution of the pipeline for one or more assets to compute and derive actionable insights for one or more events. Depending on the desired implementation, the method or instruction may further facilitate functionality for dynamic event generation, interpretation, and / or resolution for complex event processing. Each event interaction in the pipeline can contribute to and be aggregated in the final KPI. Depending on the size of the event, sub-pipelines may be generated to investigate sub-events. In addition, the predictability of the aggregation of event information from executed pipelines can, according to the desired implementation, predict and correct a particular event before it occurs. Furthermore, optimization of the event pipeline results by the policy core layer may potentially be useful for prescribed actions on assets at the time the event occurs.

[0096] Processor 2010 may be configured to execute methods or instructions for building pipelines to facilitate analytics solutions by generating pipeline configurations through interaction with an infrastructure compiler based on the available computing resources of a digital twin, and by executing pipeline sets from those configurations based on constraints on the available computing resources.

[0097] Some parts of the detailed explanation have been presented concerning algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are means used by those skilled in data processing technology to convey the essence of the innovation to others skilled in the art. An algorithm is a set of predefined steps that produce a desired end state or result. In one implementation example, the steps performed require the physical manipulation of tangible quantities to achieve a specific result.

[0098] Unless otherwise specified, explanations that use terms such as “processing,” “computing,” “calculating,” “determining,” and “displaying” throughout the explanation, as is evident from the explanation, should be understood to include actions and processes of a computer system or other information processing device that manipulate data represented as physical (electronic) quantities in the registers and memory of a computer system and convert it into other data similarly represented as physical quantities in the memory or registers of a computer system, or in other information storage, transmission, or display devices.

[0099] Implementation examples may also relate to apparatus for performing the operations described herein. Such apparatus may be specifically constructed for a required purpose and may include one or more general-purpose computers that are selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in computer-readable media such as computer-readable storage media or computer-readable signal media. Computer-readable storage media may include, but are not limited to, tangible media such as optical disks, magnetic disks, read-only memory, random-access memory, solid-state devices and drives, or any other type of tangible or non-temporary media suitable for storing electronic information. Computer-readable signal media may include media such as carrier waves. The algorithms and representations presented herein are not specific to any particular computer or other apparatus. Computer programs may include pure software implementations containing instructions for performing the operations in a desired implementation form.

[0100] Various general-purpose systems may be used with the programs and modules illustrated herein, or it may be convenient to construct more specialized devices for performing desired method steps. Furthermore, the implementation examples do not describe any particular programming language. It will be understood that various programming languages ​​may be used to implement the techniques of the implementation examples described herein. Instructions in a programming language may be executed by one or more processing units, such as a central processing unit (CPU), processor, or controller.

[0101] As is known in the art, the operations described above can be performed by hardware, software, or any combination of software and hardware. Various aspects of the implementation examples may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions (software) stored on a machine-readable medium, which, when executed by a processor, cause the processor to execute a method for performing the implementation of the present application. Furthermore, some implementation examples of the present application may be performed by hardware alone, while others may be performed by software alone. Moreover, the various functions described may be performed within a single unit or distributed across several components in any number of ways. When performed by software, the method may be executed by a processor such as a general-purpose computer based on instructions stored on a computer-readable medium. If desired, the instructions may be stored on the medium in compressed and / or encrypted form.

[0102] Furthermore, other implementations of the Application will become apparent to those skilled in the art by examining this Specification and practicing the Techniques of the Application. Various aspects and / or components of the implementations described herein may be used individually or in any combination. This Specification and the implementations are intended to be considered merely as examples, and the true scope and spirit of the Application are indicated by the appended claims.

Claims

1. When you receive the created digital twin, The processor processes the created digital twin through a policy core process that determines the policy of the digital twin, The processor executes an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin, based on the metadata of the physical assets retrieved from the metadata database and the determined policy. The processor executes a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the sensor metadata database and the asset core process, The processor executes an analysis solution core process that determines an analysis solution for the physical asset based on the metadata database and the sensor core process, The processor builds a pipeline to facilitate the analytical solution across the policy core layer, asset core layer, sensor core layer, and analytical solution core layer of the digital twin, The processor executes the pipeline using computing resources to determine key performance indicator (KPI) values ​​provided to the application programming interface (API). Methods that include...

2. The method according to claim 1, further comprising triggering the automatic construction of an additional pipeline based on the execution of the pipeline when the processor detects an event.

3. The processor executes the asset core process, To instantiate one or more asset core actors and form the asset hierarchy, an asset core template is executed based on the metadata of the physical asset and the determined policy, Based on the determined policy, connect the one or more asset core actors to one or more policy core actors, In order to construct the aforementioned asset hierarchy, the one or more asset core actors are connected to one or more other asset core actors, The KPI values ​​are provided to the one or more policy core actors. The method according to claim 1, including the method described in claim 1.

4. The processor executes the sensor core process, In order to instantiate one or more sensor core actors as the sensor hierarchy, the sensor core template is executed based on the metadata database, Based on the aforementioned asset hierarchy, connect the one or more sensor core actors to one or more asset core actors, To establish sensor dependency, the one or more sensor core actors are connected to one or more other sensor core actors, Supplying physical or virtual sensor data from a database or from one or more other sensor core actors to the one or more sensor core actors, To supply metadata from the metadata database or from the one or more asset core actors to the one or more sensor core actors, To provide the KPI values ​​to the one or more asset core actors mentioned above. The method according to claim 1, including the method described in claim 1.

5. The processor executes the analysis solution core process, To instantiate one or more analytical solution core actors, execute the analytical solution core template on the metadata database, To supply physical or virtual sensor data from one or more sensor core actors, Based on the metadata received through the sensor hierarchy, the analysis solution is trained or inferred. Includes, The one or more analytical solution core actors described above write metadata to the database, The method according to claim 1, wherein the KPI value is provided to the one or more sensor core actors.

6. The method according to claim 1, further comprising generating an additional pipeline at runtime during the pipeline's execution for the one or more assets in order to compute and derive actionable insights for the one or more events if the processor detects one or more events associated with one or more assets from the asset hierarchy from the monitoring of the KPI values.

7. The processor constructing the pipeline for facilitating the analysis solution involves generating a pipeline configuration through interaction with an infrastructure compiler based on the available computing resources of the digital twin, Based on the constraints on the available computing resources, the pipeline configuration is used to execute the set of pipelines. The method according to claim 1, including the method described in claim 1.

8. A non-temporary computer-readable medium that stores instructions for executing a process, wherein the instructions are: When you receive the created digital twin, The process of creating the digital twin involves processing the digital twin through a policy core process that determines the policy of the digital twin, The process involves executing an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin, based on the metadata of the physical assets retrieved from the metadata database and the determined policy, Execute a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the sensor metadata database and the asset core process, Based on the metadata database and the sensor core process, an analysis solution core process is executed to determine an analysis solution for the physical asset. To build a pipeline to facilitate the analytics solution across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin, The pipeline is executed using computing resources to determine key performance indicator (KPI) values ​​provided to the Application Programming Interface (API). Non-temporary computer-readable media, including [specific examples of such media].

9. The non-temporary computer-readable medium according to claim 8, further comprising the instruction triggering the automatic construction of additional pipelines based on the execution of the pipeline if an event is detected.

10. Executing the aforementioned asset core process means To instantiate one or more asset core actors and form the asset hierarchy, an asset core template is executed based on the metadata of the physical asset and the determined policy, Based on the determined policy, connect the one or more asset core actors to one or more policy core actors, In order to construct the aforementioned asset hierarchy, the one or more asset core actors are connected to one or more other asset core actors, The KPI values ​​are provided to the one or more policy core actors. A non-temporary computer-readable medium according to claim 8, including the following:

11. Executing the aforementioned sensor core process means In order to instantiate one or more sensor core actors as the sensor hierarchy, the sensor core template is executed based on the metadata database, Based on the aforementioned asset hierarchy, connect the one or more sensor core actors to one or more asset core actors, To establish sensor dependency, the one or more sensor core actors are connected to one or more other sensor core actors, Supplying physical or virtual sensor data from a database or from one or more other sensor core actors to the one or more sensor core actors, To supply metadata from the metadata database or from the one or more asset core actors to the one or more sensor core actors, To provide the KPI values ​​to the one or more asset core actors mentioned above. A non-temporary computer-readable medium according to claim 8, including the following:

12. Executing the aforementioned analysis solution core process means To instantiate one or more analytical solution core actors, execute the analytical solution core template on the metadata database, To supply physical or virtual sensor data from one or more sensor core actors, Based on the metadata received through the sensor hierarchy, the analysis solution is trained or inferred. Includes, The one or more analysis solution core actors described above write metadata to the database, The non-temporary computer-readable medium according to claim 8, wherein the KPI value is provided to the one or more sensor core actors.

13. The non-temporary computer-readable medium according to claim 8, further comprising generating an additional pipeline at runtime during the pipeline execution for the one or more assets in order to calculate and derive actionable insights for the one or more events if one or more events associated with one or more assets from the asset hierarchy are detected from the monitoring of the KPI values.

14. Building the pipeline to facilitate the analysis solution involves generating a pipeline configuration through interaction with the infrastructure compiler based on the available computing resources of the digital twin, Based on the constraints on the available computing resources, the pipeline set is executed from the pipeline configuration. A non-temporary computer-readable medium according to claim 8, including the following:

15. Memory configured to store instructions, A processor configured to execute the instructions for executing a process and A device including, wherein the instruction is, When you receive the created digital twin, The process of creating the digital twin involves processing the digital twin through a policy core process that determines the policy of the digital twin, The process involves executing an asset core process that determines the asset hierarchy of the physical assets represented by the digital twin, based on the metadata of the physical assets retrieved from the metadata database and the determined policy, Execute a sensor core process that determines the sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the sensor metadata database and the asset core process, The process involves executing an analysis solution core that determines an analysis solution for the physical asset based on the metadata database and the sensor core process, To build a pipeline to facilitate the analytics solution across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin, The pipeline is executed using computing resources to determine key performance indicator (KPI) values ​​provided to the Application Programming Interface (API). A device including a device.

Images