A configurable, modular, intelligent digital twin architecture for IoT operations optimizing 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]

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

[0002] Related art digital twin-based solutions are attractive, but effective deployment is labor-intensive and time-consuming. Furthermore, current digital twin-based solutions lack effective and actionable business insights. There is a demand for a configurable, on-demand digital twin architecture that is modular and scalable with customer needs. A solution that standardizes and productizes digital twins with actionable business insights enables new smart products. Such products can greatly benefit from a machine learning-driven configurable digital twin solution. A modular architecture enables configurability by assembling the required modules to develop the solution. A scalable architecture allows for deployment on a single computer, or a cluster of computers or cloud environment. Furthermore, a heterogeneous architecture with different computing resources is needed.

[0003] In related technology implementations, a digital twin of a twinned physical system exists, where one or more sensor values ​​allow the system to monitor the status of selected portions of the twinned physical system and access the remaining useful life of the designated portions. Such related technology implementations further execute optimization software using analysis of the twinned physical system sensor values ​​to identify optimal operational controls and optimal operational implementations of the twinned physical system. Such related technology implementations enhance mission deployment, inspection and maintenance scheduling efforts, and can be extended to other types of digital twins.

[0004] Another related art implementation is a hierarchical asset control system that relies on identifying an equipment list. Such related art implementations act to determine control paths between assets and identify asset constraints so that smart agents can control the assets. The related art control system is based on intelligent asset-based templates that are input after identifying system boundaries. The related art control system includes a processor that identifies a hierarchical arrangement of asset control relationships for the hierarchical asset control application by connecting each of the instantiated intelligent agents based on parent / child information. Summary of the Invention [Means for solving the problem]

[0005] Example implementations described herein are directed to adaptive digital twins and architectures therefor that can be used to develop configurable digital twins with business policies that facilitate rapid development of adaptive machine learning based business solutions for complex event processing.

[0006] The exemplary implementation described herein includes a configurable modular architecture that includes 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 into a knowledge base of pipelines and perform pipeline-only execution based on events.

[0007] The Analytics Solution Core (ASC) represents a basic building block with machine learning algorithms that can be used for several vertical applications. The ASC store stores the available algorithms according to the desired implementation. The Sensor Core utilizes one or several Analytics Solution Cores to provide actionable insights. The Sensor Core can ingest real sensor data or virtual sensor data calculated by simple or complex algorithms / software according to the desired implementation. The Asset Core represents the physical asset of interest and connects to the relevant Sensor Core depending on the sensors associated with the particular asset.

[0008] The output of the asset core module is consumed by the policy core to provide actionable insights that can use machine learning algorithms such as reinforcement learning or optimization algorithms. Additionally, the policy core manages the creation of new pipelines with asset cores, sensor cores, and ASCs for training or inference while allocating computational resources to the new pipelines.

[0009] In an example implementation, each layer (Policy Core, Asset Core, Sensor Core, ASC) can be multi-level. For example, an analytics solution core module can be multi-level with several analytics solution cores in series. In another example, a digital twin asset can be multi-level with a parent having multiple sub-components. Data flow can be generated by direct input to the module or coming from a parent module depending on the desired implementation.

[0010] Aspects of the disclosure include a method that may include, when receiving the created digital twin, processing the created digital twin through a policy core process that determines a policy for the digital twin; executing an asset core process that determines an asset hierarchy for the physical assets represented by the digital twin based on the determined policy and the metadata of the physical assets retrieved from a metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the metadata of the sensors 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; 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 executing the pipeline with computational resources to determine key performance indicator (KPI) values ​​that are provided to an application programming interface (API).

[0011] Aspects of the disclosure include a computer program storing instructions, the instructions may include: when receiving a composed digital twin, processing the created digital twin through a policy core process that determines a policy for the digital twin; executing an asset core process that determines an asset hierarchy for a physical asset represented by the digital twin based on the determined policy and the metadata of the physical assets retrieved from a metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the metadata of the sensors retrieved from a sensor metadata database and the asset core process; executing an analytics solution core that determines an analytics solution for the physical asset based on the metadata database and the sensor core process; 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 executing the pipeline with computing resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API). The computer program and instructions may be stored in a non-transitory computer readable medium and executed by one or more processors.

[0012] Aspects of the disclosure may include a system that may include means for processing the created digital twin through a policy core process that, when it receives the created digital twin, determines a policy for the digital twin; means for executing an asset core process that determines an asset hierarchy for the physical asset represented by the digital twin based on the determined policy and the metadata of the physical asset retrieved from a metadata database; means for executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the metadata of the sensor 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 asset based on the metadata database and the sensor core process; means for 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 means for executing the pipeline with computational resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API).

[0013] Aspects of the disclosure may include an apparatus including a memory configured to store instructions and a processor configured to execute the stored instructions, the instructions including, when receiving a composed digital twin, processing the created digital twin through a policy core process that determines a policy for the digital twin; executing an asset core process that determines an asset hierarchy for a physical asset represented by the digital twin based on the determined policy and the metadata of the physical assets retrieved from a metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the metadata of the sensors retrieved from a sensor metadata database and the asset core process; executing an analytics solution core that determines an analytics solution for the physical asset based on the metadata database and the sensor core process; 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 executing the pipeline with computational resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API).

[0014] Aspects of the disclosure may include a system that may include a meta-policy core actor configured to generate policies for the digital twin; an asset core that manages an asset core template configured to instantiate asset core actors in an asset hierarchy of a physical asset represented by the digital twin based on the metadata of the physical asset and the policies generated by the meta-policy core actor; a sensor core that manages a sensor core template that instantiates one or more sensor actors in a sensor hierarchy based on a metadata database and populates the database with physical or virtual sensor data; an analytics solution core that manages an analytics solution core template that instantiates one or more analytics solution core actors and trains or infers an analytics solution based on the metadata and sensor data received through the sensor hierarchy; and a pipeline constructor that builds pipelines to facilitate analytics solutions across the policy core layer, asset core layer, sensor core layer, and analytics solution core layer of the digital twin, and is configured to build additional pipelines or destroy particular pipelines during runtime execution of the pipelines. [Brief description of the drawings]

[0015] [Figure 1] Figure 1 shows an example of a complex industrial facility with multiple assets in a hierarchical structure.

[0016] [Diagram 2] 2(A) through 2(C) show an example schematic of a typical process in a manufacturing plant.

[0017] [Diagram 3] FIG. 3 is a schematic diagram of a four-tier architecture having a policy core, an asset core, a sensor core, and an analytical solution core in accordance with an example implementation.

[0018] [Figure 4]FIG. 4 illustrates an example of a four-tier 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.

[0019] [Diagram 5] FIG. 5 illustrates an example schematic diagram of the policy core and its interactions with asset actors, computing environment, monitoring dashboards, business actions, and IoT databases according to an exemplary implementation.

[0020] [Figure 6] FIG. 6 illustrates an example of an architectural flow of a heuristics-based engine for a meta-policy actor according to an exemplary implementation.

[0021] [Figure 7] FIG. 7 illustrates an example of an architectural flow of an operation process of an LSTM-based engine for a meta-policy actor, according to an exemplary implementation.

[0022] [Figure 8] FIG. 8 illustrates an example schematic diagram of the components of an asset core template and a sensor core template according to an example implementation.

[0023] [Figure 9] FIG. 9 illustrates an example schematic diagram of components of an ASC core template according to an example implementation.

[0024] [Figure 10] FIG. 10 illustrates an example of a solution operation process for pipeline execution in accordance with an exemplary implementation.

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

[0026] [Figure 12] FIG. 12 illustrates an example of a solution operation process for complex event processing in accordance with an exemplary implementation.

[0027] [Figure 13] FIG. 13 illustrates an example of an application scenario in accordance with an exemplary implementation.

[0028] [Figure 14] FIG. 14 illustrates an example of a manufacturing process problem in a normal operation case, according to an exemplary implementation. [Figure 15] FIG. 15 illustrates an example of a manufacturing process problem where a few robots are not functioning on a workstation, according to an exemplary implementation. [Figure 16] FIG. 16 illustrates an example of a manufacturing process problem where one of the workstations is not functioning, according to an example implementation.

[0029] [Figure 17] FIG. 17 illustrates an example of an execution computing environment in accordance with an exemplary implementation.

[0030] [Figure 18] FIG. 18 illustrates another example execution environment in accordance with an exemplary implementation.

[0031] [Figure 19] FIG. 19 illustrates a system including multiple assets networked to a management device according to an exemplary implementation.

[0032] [Figure 20] FIG. 20 illustrates an example computing environment having an example computer device suitable for use with some example implementations. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] The following detailed description provides details of the figures and implementation examples of the present application. Reference numbers and descriptions of redundant elements between the figures are omitted for clarity. The terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatic" may include a fully automatic implementation, or a semi-automatic implementation with user or administrator control over certain aspects of the implementation, depending on the desired implementation of the person skilled in the art implementing the implementation of the present application. The selection may be made by a user through a user interface or other input means, or through a desired algorithm. The exemplary implementations as described herein may be utilized alone or in combination, and the functionality of the implementations may be implemented through any means according to the desired implementation.

[0034] Industrial systems have several components and have a very complex hierarchical structure. Damage or failure modes or events in one component can affect other components and thus the whole system. To manage an IIoT system intelligently, the impact of every event requires a composite event. Therefore, to effectively manage the whole system, a digital twin based IIoT management software system needs to deal with such complex systems and events. Building such a digital twin based system is very challenging due to the complexity of the software architecture and the type of models that are required.

[0035] Different components of the system require different types of models. Such models can be purely data-driven, purely physics-based, or a hybrid of both. These models can be used to gain actionable insights by deeply and intelligently understanding the data by analyzing event patterns, event filtering, event transformations, or event hierarchies to determine event causality.

[0036] Combining complex digital twin systems with such a wide variety of models is highly complex. Further complicating the process is that each of these component models has different data needs, some of which require streaming data from component sensors, and different computational resources are required depending on the nature of the model. To enable such complex event processing, a modular, composable digital twin software architecture is needed to enable the processing and to reduce development time and time to market for various industrial customers. A repeatable architecture is needed to model both static physical assets and dynamic processes. Related technology digital twin architectures focus on one or the other, but not both. Furthermore, to deliver business value with a high return on investment, an architecture that encourages standardization and reduces time to market is needed.

[0037] In the first example 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 shows an example of a complex industrial facility with multiple assets in a hierarchical structure. Each asset benefits from processing with different types of analytical algorithms such as anomaly detection, fault detection, etc. The characteristics of the problem are: The objective can be operational improvement and effectiveness. The challenge can be to disentangle both the web of data and the web of systems and processes. The value provided is that a modular composable digital twin architecture can significantly reduce the time to deployment of artificial intelligence based solutions for IIoT applications. The types of models included can include physical models, probabilistic models, machine learning (ML) models, etc.

[0039] In the second problem example, there may be a manufacturing process problem. Figures 2(A)-2(C) show an example of a schematic diagram of a typical process in a manufacturing plant. Specifically, Figure 2(A) shows an example of normal operation, Figure 2(B) shows an example of a few robots not working, and Figure 2(C) shows an example of one station not working. During normal operation, all robots are working. However, during downtime, scenarios arise where a particular robot is not working or a particular station is not working. Digital twin software systems need to dynamically adapt to such scenarios, which is lacking in current architectures. In the example of Figures 2(A)-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, 3, each with three robots 1, 2, 3 installed. Regarding the operating modes of the manufacturing plant, FIG. 2(A) shows an operating mode in which all stations and robots are in operation, FIG. 2(B) shows an operating mode in which one robot at each station is not in operation due to an unexpected failure, and FIG. 2(C) shows an operating mode in which one of the stations is completely offline.

[0040] In the example of Figures 2(A)-2(C), the digital twin system should be able to monitor for failure modes such as machine failure, performance degradation, etc. If one or more robots or stations fail, the digital twin system should be able to create a new solution reflecting the new set of assets. Additionally, the digital twin should be able to handle complex event processing, where the triggering of one event or failure mode should initiate additional processing to further confirm the failure mode and identify defects in related components.

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

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

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

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

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

[0046] Composability: Cores should be open to being combined to build pipelines in serial or parallel combinations, if necessary. Such composability includes parallelism at the module level, scalability via cloud, and allows for the necessary governance according to business needs or government regulations (e.g. GDPR).

[0047] 4 illustrates a four-level architecture according to an exemplary implementation. A control entity 400 enables a four-tier orchestration for the processing of IoT data 401. Depending on the desired implementation, the control entity can also be part of a policy core 410.

[0048] The policy core 410 is an intelligent engine that determines possible next recommendations once results are processed and shares the resulting insights on a dashboard for users to gain further insight and knowledge about the system. The policy core 410 also instantiates one or more policy actors 412 using a computational resource composer 411 and a composable pipeline knowledge base 413. Further details of the policy core 410 are provided with respect to FIG.

[0049] Asset core 420 instantiates one or more asset actors 421 to represent an asset hierarchy of the infrastructure system's physical assets. Further details of asset core 420 are provided with respect to FIG. 10(A). Sensor core 430 instantiates one or more sensor actors 431 to represent a sensor hierarchy derived from the asset hierarchy. Further details of sensor core 430 are provided with respect to FIG. 10(B). ASC 440 instantiates one or more ASC actors 441 to perform analytical solutions. Further details of ASC 440 are provided with respect to FIG. 11.

[0050] FIG. 5 illustrates an example schematic diagram of the policy core and its interactions with asset actors, computing environment, monitoring dashboard, business actions, and IoT database according to 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 that contains information about sensor cores, pipelines, ASCs, and assets. The meta-policy actor 500 also interacts with asset actors, computational resources, business action application programming interfaces (APIs) 502, monitoring dashboard APIs 503, or operational control APIs.

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

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

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

[0055] Intelligence algorithms in the policy core include, but are not limited to, heuristic / deep learning based reinforcement learning algorithms to prescribe business actions or trigger the construction / execution of new pipelines, and / or optimization algorithms to optimize process parameters such as to maximize yield of a manufacturing process.

[0056] In the example of FIG. 5, the pipeline construction process is as follows: At 1, the meta-policy actor 500 monitors a particular pipeline and determines if a new pipeline is needed for detection / prediction to generate more business value. At 10, the meta-policy actor 500 sends the monitoring information to the monitoring dashboard to provide feedback of any events to the user and get any user input for new pipelines if necessary. At 6, the meta-policy actor 500 sends metadata to construct the pipeline based on the monitoring results and business needs. At 61, the pipeline composer 501 sends the new pipeline metadata to the meta-policy actor 500. At 2, based on the data obtained from the pipeline composer 501, the meta-policy actor 500 sends the required computational resources as computed using IoT data store and ASC store data for the pipeline and provides it to the computational resources composer 411.

[0057] At 9, the computational resource composer 411 sends relevant information to the computational environment 504 for creation or confirmation of the desired environment. At 91, the computational environment 504 sends confirmation of the availability of the desired computational environment. At 21, the computational resource composer 411 sends confirmation of the computational resources to the meta-policy actor 500.

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

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

[0060] Thereafter, at 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 and their associated actions at 708 along with providing insights at 707. In another possible outcome, a decision 710 is made to create a new optimized pipeline at 711 with the help of the list of actions and business heuristics at 709.

[0061] FIG. 7 illustrates an example of an architecture flow of an operation process of a LSTM-based engine for a meta-policy actor according to an exemplary implementation. In the example flow of a long short-term memory (LSTM)-based engine for a meta-policy actor 500, first, the meta-policy actor 500 constantly monitors the asset pipeline at 800 and filters the received signals and results as significant events at 801. Then, the filtered events and metastore are collectively used at 802 to obtain further insights about the events (e.g., what are the associated KPIs or which assets contribute most to the signal) by the LSTM-based engine at 803. Further insights can be obtained from the signals with the help of pre-trained neural networks and business actions. The meta-policy actor 500 can then continue monitoring the assets to obtain further insights at 804 depending on the desired implementation. For further actions, the meta-policy actor 500 utilizes explainable AI to create a list of actions based on the insights obtained through the neural network at 805. Another possible outcome is to provide business insights to the user with the aid of possible actions for business optimization at 807 if it is determined at 806 that additional pipelines are not required according to the desired implementation. Further improvement of the system may be provided by running another pipeline at 808 if it is determined at 806 that additional pipelines are required.

[0062] FIG. 8 illustrates an example schematic diagram of the components of an asset core template and a sensor core template according to an exemplary implementation. The asset core template 901 is a standardized code base that can be reused to instantiate asset actors at runtime. The asset actors can be multi-tiered. The asset actors can be connected to one or more sensor actors, one or more other asset actors, and / or policy actors depending on the desired implementation. The templates can include various libraries such as, but not limited to, an asset failure mode analyzer, compatible sensor core metadata, an asset pipeline generator, an asset core to policy core API, an asset core to sensor core API, and data transfer APIs to / from IoT data sources depending on the desired implementation.

[0063] The sensor core template 902 is a standardized code base that can be reused to instantiate sensor actors at runtime. The sensor core actors can be multiple tiers. A sensor actor can be connected to one or more ASC actors, one or more other sensor actors, and / or asset actors, depending on the desired implementation. The template can include various libraries such as, but not limited to, sensor-specific feature engineering, compatible ASC analysis metadata, ASC pipeline generator, sensor core to asset core API, sensor core to ASC core API, and data transfer API to / from IoT data sources, depending on the desired implementation.

[0064] FIG. 9 shows an example schematic diagram of components of the ASC Core template according to an exemplary implementation. The ASC Core 1001 is like a class in object-oriented programming and has the algorithmic blueprint for the analytical solution. The ASC Core class may include several subclasses to read data, process data, feature engineering, train models, and / or perform inference from the developed models. Furthermore, this class may have appropriate flags to perform training or inference depending on the metadata coming from the sensor core. During pipeline generation, the policy actor creates the ASC actor by calling the ASC Core and passing the required metadata to create the ASC actor.

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

[0066] At 1105, the ASC actor computes the results and sends them to the sensor core. At 1104, the sensor actor computes the results and sends them back to the asset actor. At 1103, the asset actor aggregates and computes the results and sends an event to the policy actor. At 1101, the policy actor sends the event information to the meta-policy actor 500. At 1108, the meta-policy actor 500 sends all action triggers based on the algorithm being executed to the business action API 502. At 1110, the meta-policy actor 500 sends the 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 according to an exemplary implementation. In the case of a monitoring process with a single ASC, the meta-policy actor 500 will execute one or several pipelines for monitoring assets. The example of Figure 11 shows an example of monitoring with one pipeline.

[0068] The monitoring process and data flow is as follows: At 1215, the sensor core receives asset sensor data, whether sensor data or virtual sensor data, to be processed by the ASC actor. At 1213, the ASC actor receives operational data from the IoT store. At 1205, the ASC actor sends detections or predictions to the sensor core.

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

[0070] FIG. 12 illustrates an example of a solution operation process for complex event processing in accordance with an exemplary implementation.

[0071] In an example of event-driven complex event processing, the system monitors assets using a specific monitoring pipeline, and based on a specific event, the meta-policy actor 500 may spin additional pipelines at runtime to calculate and compute additional parameters such as remaining useful life of the same component, health scores of related components, and so on, to calculate and derive actionable insights.

[0072] The Event 1 pipeline (dashed line) is responsive to Event 1 that the Meta-Policy actor initiated creation of to calculate additional parameters. In this case, the Event 1 pipeline is for the same asset as the monitoring asset. The Event 2 pipeline (bold line) is triggered on a different asset based on an event on the monitoring asset. Additionally, multiple pipelines may be triggered in parallel in response to the result of a monitoring alert or a combination of a monitoring alert and a previous event pipeline, depending on the desired implementation.

[0073] FIG. 13 illustrates an example of an application scenario according to an exemplary implementation. In the example application scenario, at 1301, a monitoring asset core sends a request to a sensor core to start an ASC pipeline to monitor a motor of an underlying system. The request can be change-based or time-based. At 1302, the sensor core collects metadata of the required data and identifies and creates the correct data structures for the ASC related to the motor. At 1303, the ASC collects data from an IoT data store to ensure that the latest data is used to run the ASC. Additionally, if applicable, previously deployed models can 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 separately 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 a policy agent, which is responsible for understanding the results and identifying the next steps to take based on the results. At 1307, the policy agent shares insights about the system on a monitoring dashboard. At 1308, the policy agent initiates the creation of a new pipeline to calculate the remaining useful life of the gearbox, if recommended by the monitoring pipeline. To facilitate the creation, the policy agent looks at both the available hardware resources and the pipeline composer, which keeps watch over the system resources. At 1309, the new remaining useful life pipeline is triggered. At 1310, the predictive asset actor initiates the pipeline by collecting information about the gearbox and identifies whether the results from the monitoring pipeline can be used as features for the predictive pipeline.

[0074] 14-16 show an example of a manufacturing process problem with three cases: normal operation, few robots not functioning on the workstations, and one of the workstations is not operational, according to an exemplary implementation. The digital twin architecture needs to adjust for such scenarios and change the digital twin according to the latest functioning physical assets. The present disclosure addresses this issue by having a meta-policy core dynamically change the pipeline depending on the scenario, as shown in FIG. 14-16. Three types of digital twins corresponding to each case are shown in FIG. 14-16.

[0075] 17 illustrates an example of an execution computing environment according to an exemplary implementation. In the example execution environment of FIG. 17, there is a computing environment 1700, which may be any computing environment (e.g., a Kubernetes cluster) according to 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 the meta-policy actor and the center piece of orchestration by the policy actor. The digital twin composer 1703 includes the composer, metadata store, and templates of asset / sensor / ASC core. 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 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, repair, etc. The model server 1710 can execute models based on IoT data received from the IoT devices 1711.

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

[0078] Throughout the exemplary implementations described herein, it is possible to facilitate complex event processing for IIoT systems, standardization of the computational framework of the asset core to provide business value, and flexibility in reusing the ASC, sensor core, and asset core for new assets and customers. Additionally, the exemplary implementations described herein facilitate the creation of new solutions from existing modules, scale computation from a single computer to multiple computers and cloud infrastructures with minimal or no modifications, provide standardization of analytics for rapid deployment, significantly reduce the time to deploy solutions, and enable non-experts to perform deployment tasks.

[0079] 19 illustrates a system including multiple assets networked to a management device according to an exemplary implementation. One or more assets 1901 are communicatively connected to a network 1900 (e.g., a local area network (LAN), a wide area network (WAN)) via corresponding on-board computers or Internet of Things (IoT) devices of the assets 1901, which is connected to a management device 1902 that facilitates a model or digital twin of the assets. The management device 1902 manages a database 1903 that includes historical data collected from the assets 1901 and also facilitates remote control over each asset 1901. In an alternative exemplary implementation, data from the assets may be stored in a central repository or database, such as a proprietary database that captures the data, or a system such as an enterprise resource planning system, and the management device 1902 can access or retrieve data from the central repository or database. Assets 1901 may include any physical system for use in a physical process, such as an assembly line or production line, depending on the desired implementation, including, but not limited to, air compressors, lathes, robotic arms, etc. Data provided from sensors of such assets 1901 may serve as data flows upon which analysis as described herein may be performed.

[0080] , The system of Figure 19 may include an underlying physical system on which a physical process may be performed. Depending on the desired implementation, the physical system and physical process may be represented by a sensor core layer, asset core layer, ASC core layer, and policy core layer representation, as described herein. In an example implementation of a truck production line that may be used as the subject of the system of Figure 19 and the represented digital twin, the physical process may include two parts: assets 1901 and their hierarchy, and the physical process for assembling the truck.

[0081] 20 illustrates an exemplary computing environment having an exemplary computing device suitable for use in some exemplary implementations, such as a management device 1902 as shown in FIG. 19, or an on-board computer of an asset 1901. The computing device 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 the like), internal storage 2020 (e.g., magnetic, optical, solid-state storage, and / or organic), and / or I / O interface 2025, any of which may be connected over a communication mechanism or bus 2030 for communicating information or may be embedded in the computing device 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.

[0082] The computing device 2005 may be communicatively connected to an input / user interface 2035 and an output device / interface 2040. One or both of the input / user interface 2035 and the output device / interface 2040 may be wired or wireless interfaces and may be removable. The input / user interface 2035 may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch screen interface, keyboard, pointing / cursor control, microphone, camera, Braille, motion sensor, optical reader, and / or the like). The output device / interface 2040 may include a display, television, monitor, printer, speaker, Braille, or the like. In some example implementations, the input / user interface 2035 and the output device / interface 2040 may be embedded in the computing device 2005 or physically connected to the computing device 2005. In other example implementations, other computing devices may function as or provide the functionality of the input / user interface 2035 and the output device / interface 2040 of the computing device 2005 .

[0083] Examples of computing device 2005 may include, but are not limited to, highly mobile devices (e.g., smart phones, devices mounted on 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 to be portable (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] Computing device 2005 may be communicatively connected (e.g., via I / O interface 2025) to external storage 2045 and a network 2050 for communicating with any number of networked components, devices, and systems, including one or more computing devices of the same or different configurations. Computing device 2005, or any connected computing device, may function, provide services, or be referred to as a server, client, thin server, general purpose machine, special purpose machine, or another label.

[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 protocols, and the like) for communicating information between at least all connected components, devices, and networks in computing environment 2000. Network 2050 may be any network or combination of networks (e.g., the Internet, a local area network, a wide area network, a telephone network, a cellular network, a satellite network, and the like).

[0086] The computing device 2005 can use and / or communicate using computer usable or computer readable media, including transitory and non-transitory media. Transitory media include transmission media (e.g., metallic cables, optical fibers), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid-state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory.

[0087] The computing device 2005 may be used to implement techniques, methods, applications, processes, or computer-executable instructions in some exemplary computing environments. The computer-executable instructions may be retrieved from a transitory medium, stored in a non-transitory medium, and retrieved from a non-transitory medium. The executable instructions may be generated from one or more of a programming language, a scripting language, and a machine language (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others).

[0088] The processor 2010 can run under any operating system (OS) (not shown) in a native or virtual environment. One or more applications can be deployed, including a logic 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, with the OS, and with other applications (not shown). The described units and elements may vary in design, function, configuration, or implementation and are not limited to the description provided. The processor 2010 may be in the form of a hardware processor, such as a central processing unit (CPU), or a combination of hardware and software units.

[0089] In some example implementations, when information or instructions to execute are received by the API unit 2065, the information or instructions to execute may be communicated to one or more other units (e.g., logic unit 2060, input unit 2070, output unit 2075). In some examples, logic unit 2060 may be configured to control the flow of information between the units and direct the services provided by API unit 2065, input unit 2070, output unit 2075 in some example implementations described above. For example, the flow of one or more processes or implementations may be controlled solely by logic unit 2060 or in cooperation with API unit 2065. Input unit 2070 may be configured to obtain inputs for calculations as described in the example implementations, and output unit 2075 may be configured to provide outputs based on the calculations as described in the example implementations.

[0090] The processor 2010 may be configured to execute instructions or methods that may include, as shown in FIGS. 4-7 , processing the created digital twin through a policy core process that determines a policy for the digital twin when the created digital twin is received; executing an asset core process that determines an asset hierarchy for the physical assets represented by the digital twin based on the determined policy and the metadata of the physical assets retrieved from the metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the 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; 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 executing the pipeline with computing resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API).

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

[0092] The processor 2010 may be configured to execute instructions or methods where executing an asset core process includes executing an asset core template based on metadata of the physical asset and a determined policy 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 the determined policy, 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] The processor 2010 may be configured to execute instructions or methods where executing a sensor core process 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, providing physical or virtual sensor data to one or more sensor core actors from a database or from one or more other sensor core actors, providing 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] The processor 2010 may be configured to execute instructions or methods including an analytical solution core process executing an analytical solution core template 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, where the one or more analytical solution core actors write metadata to the database and KPI values ​​are provided to the one or more sensor core actors.

[0095] The processor 2010 may be configured to execute a method or instructions further comprising: upon detecting one or more events associated with one or more assets from the asset hierarchy from monitoring the KPI values, generating additional pipelines at runtime execution of the pipeline for the one or more assets to calculate and derive actionable insights for the one or more events. Depending on the desired implementation, the method or instructions may further facilitate dynamic event generation, interpretation, and / or resolution functionality for complex event processing. Each event interaction in the pipeline may contribute and be aggregated to a final KPI. Depending on the size of the event, sub-pipelines may be generated to investigate sub-events. Additionally, the predictability of the aggregation of event information from the executed pipelines may predict and remediate certain events before they occur, depending on the desired implementation. Furthermore, optimization of the event pipeline results by the policy core layer may potentially aid in prescriptive actions on assets at the time the event occurs.

[0096] The processor 2010 may be configured to execute methods or instructions to build a pipeline to facilitate an analytics solution by generating a pipeline configuration through interaction with an infrastructure compiler based on available computing resources of the digital twin, and executing a pipeline set from the pipeline configuration based on constraints on the available computing resources.

[0097] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the substance of their innovations to others skilled in the art. An algorithm is a sequence of defined steps leading to a desired end state or result. In one implementation, the steps performed require physical manipulations of tangible quantities to achieve a tangible result.

[0098] Unless otherwise specified, as is apparent from the description, the description utilizing terms such as "processing," "computing," "calculating," "determining," "displaying," and the like throughout the description will be understood to include the actions and processes of a computer system or other information processing device that manipulates and converts data represented as physical (electronic) quantities in the registers and memory of the computer system to other data similarly represented as physical quantities in the memory or registers of the computer system, or other information storage, transmission, or display device.

[0099] The implementations may also relate to an apparatus for performing the operations of the present specification. The apparatus may be specially constructed for the required purposes, or may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer-readable medium, such as a computer-readable storage medium or a computer-readable signal medium. The computer-readable storage medium may include tangible media, such as, but not limited to, optical disks, magnetic disks, read-only memories, random access memories, solid-state devices and drives, or any other type of tangible or non-transitory medium suitable for storing electronic information. The computer-readable signal medium may include media such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. The computer programs may include pure software implementations that include instructions to perform the operations of the desired implementation.

[0100] Various general-purpose systems may be used with the programs and modules according to the examples herein, or it may prove convenient to construct more specialized apparatus to perform the desired method steps. In addition, the implementations are not described with reference to a particular programming language. It will be appreciated that a variety of programming languages ​​may be used to implement the techniques of the implementations 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 may be performed by hardware, software, or some combination of software and hardware. Various aspects of the implementations may be implemented using circuits and logic (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software) that, when executed by a processor, cause the processor to perform a method for performing the implementation of the present application. Furthermore, some implementations of the present application may be performed exclusively in hardware, while other implementations may be performed exclusively in software. Furthermore, the various functions described may be performed in a single unit or distributed among 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 format.

[0102] Additionally, other implementations of the present application will be apparent to those skilled in the art upon consideration of the specification and practice of the techniques of the present application. Various aspects and / or components of the described implementations may be used alone or in any combination. It is intended that the specification and implementations be considered as examples only, with a true scope and spirit of the present application being indicated by the following claims.

Claims

1. When you receive the created digital twin, processing the created digital twin through a policy core process that determines policies for the digital twin; executing an asset core process that determines an asset hierarchy for the physical assets represented by the digital twin based on the determined policies and the metadata of the physical assets retrieved from a metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the metadata database of sensors and the asset core process; executing an analytic solution core that determines an analytic solution for the physical asset based on the metadata database and the sensor core processes; Building a pipeline to facilitate the analytic solution across a policy core layer, an asset core layer, a sensor core layer, and an analytic solution core layer of the digital twin; executing the pipeline using computational resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API); A method comprising:

2. The method of claim 1 , further comprising triggering automatic construction of additional pipelines based on execution of the pipeline upon detecting an event.

3. said executing said asset core process further comprising: executing an asset core template based on the metadata of the physical assets and the determined policies to instantiate one or more asset core actors to form the asset hierarchy; connecting the one or more asset core actors to one or more policy core actors based on the determined policy; connecting the one or more asset core actors to one or more other asset core actors to construct the asset hierarchy; providing said KPI values ​​to said one or more policy core actors; The method of claim 1 , comprising:

4. said executing said sensor core process executing a sensor core template based on the metadata database to instantiate one or more sensor core actors as the sensor hierarchy; connecting the one or more sensor core actors to one or more asset core actors based on the asset hierarchy; connecting said one or more sensor core actors to one or more other sensor core actors to establish sensor dependencies; providing physical or virtual sensor data to said one or more sensor core actors from a database or from said one or more other sensor core actors; Providing metadata from a metadata database or from the one or more asset core actors to the one or more sensor core actors; providing said KPI values ​​to said one or more asset core actors; The method of claim 1 , comprising:

5. said executing said analysis solution core process further comprising: executing an analytic solution core template on the metadata database to instantiate one or more analytic solution core actors; Providing physical or virtual sensor data from one or more sensor core actors; training or inferring the analytical solution based on metadata received through the sensor hierarchy; Including, The one or more analytic solution core actors write metadata to a database; The method of claim 1 , wherein the KPI values ​​are provided to the one or more sensor core actors.

6. 2. The method of claim 1, further comprising: upon detecting one or more events associated with one or more assets from the asset hierarchy from monitoring the KPI values, generating additional pipelines during runtime execution of the pipeline for the one or more assets to calculate and derive actionable insights for the one or more events.

7. Building the pipeline to facilitate the analytical solution includes generating a pipeline configuration through interaction with an infrastructure compiler based on available computing resources of the digital twin; executing a set of pipelines from the pipeline configuration based on constraints on the available computing resources; The method of claim 1 , comprising:

8. A non-transitory computer-readable medium storing instructions for carrying out a process, the instructions comprising: When you receive the created digital twin, processing the created digital twin through a policy core process that determines policies for the digital twin; executing an asset core process that determines an asset hierarchy for the physical assets represented by the digital twin based on the determined policies and the metadata of the physical assets retrieved from a metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the metadata database of sensors and the asset core process; executing an analytic solution core that determines an analytic solution for the physical asset based on the metadata database and the sensor core processes; Building a pipeline to facilitate the analytic solution across a policy core layer, an asset core layer, a sensor core layer, and an analytic solution core layer of the digital twin; executing the pipeline using computational resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API); A non-transitory computer readable medium comprising:

9. 10. The non-transitory computer-readable medium of claim 8, the instructions further comprising: triggering automatic construction of additional pipelines based on execution of the pipeline if an event is detected.

10. said executing said asset core process further comprising: executing an asset core template based on the metadata of the physical assets and the determined policies to instantiate one or more asset core actors to form the asset hierarchy; connecting the one or more asset core actors to one or more policy core actors based on the determined policy; connecting the one or more asset core actors to one or more other asset core actors to construct the asset hierarchy; providing said KPI values ​​to said one or more policy core actors; 9. The non-transitory computer readable medium of claim 8, comprising:

11. said executing said sensor core process executing a sensor core template based on the metadata database to instantiate one or more sensor core actors as the sensor hierarchy; connecting the one or more sensor core actors to one or more asset core actors based on the asset hierarchy; connecting said one or more sensor core actors to one or more other sensor core actors to establish sensor dependencies; providing physical or virtual sensor data to said one or more sensor core actors from a database or from said one or more other sensor core actors; Providing metadata from a metadata database or from the one or more asset core actors to the one or more sensor core actors; providing said KPI values ​​to said one or more asset core actors; 9. The non-transitory computer readable medium of claim 8, comprising:

12. said executing said analysis solution core process further comprising: executing an analytic solution core template on the metadata database to instantiate one or more analytic solution core actors; Providing physical or virtual sensor data from one or more sensor core actors; training or inferring the analytical solution based on metadata received through the sensor hierarchy; Including, The one or more analytic solution core actors write metadata to a database; The non-transitory computer readable medium of claim 8 , wherein the KPI values ​​are provided to the one or more sensor core actors.

13. 10. The non-transitory computer-readable medium of claim 8, further comprising, upon detecting one or more events associated with one or more assets from the asset hierarchy from monitoring the KPI values, generating additional pipelines during runtime execution of the pipeline for the one or more assets to calculate and derive actionable insights for the one or more events.

14. Building the pipeline to facilitate the analytical solution includes generating a pipeline configuration through interaction with an infrastructure compiler based on available computing resources of the digital twin; executing a pipeline set from the pipeline configuration based on constraints on the available computing resources; 9. The non-transitory computer readable medium of claim 8, comprising:

15. A memory configured to store instructions; a processor configured to execute the instructions to perform a process; the instructions comprising: When you receive the created digital twin, processing the created digital twin through a policy core process that determines policies for the digital twin; executing an asset core process that determines an asset hierarchy for the physical assets represented by the digital twin based on the determined policies and the metadata of the physical assets retrieved from a metadata database; executing a sensor core process that determines a sensor hierarchy associated with the asset hierarchy based on the sensor metadata retrieved from the metadata database of sensors and the asset core process; executing an analytic solution core that determines an analytic solution for the physical asset based on the metadata database and the sensor core processes; Building a pipeline to facilitate the analytic solution across a policy core layer, an asset core layer, a sensor core layer, and an analytic solution core layer of the digital twin; executing the pipeline using computational resources to determine key performance indicator (KPI) values ​​provided to an application programming interface (API); 13. An apparatus comprising:

Images