System and method for aircraft digital twin management and query

Abstract

Systems, devices, computer-readable media, and associated methods for managing digital twin networks are disclosed. An example apparatus includes a memory circuit to store a plurality of snapshots, each snapshot including a plurality of digital twin models interconnected by a plurality of connections, the plurality of digital twin models including a first digital twin model of a first asset and a second digital twin model of a second asset, the plurality of connections includes a first connection between the first digital twinning model and the second digital twinning model, the first connection representing a relationship between the first digital twinning model and the second digital twinning model at a specified point in time. The example apparatus includes processing circuitry to process a query to identify a first snapshot and a second snapshot, determine a correlation, and generate a result having an actionable output.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for digital twin modeling and analysis, and more particularly, to systems and methods for digital twin management and querying. Background Art

[0002] Aircraft are complex machines with many parts and many opportunities for error or failure. As such, monitoring and predicting failures is important to drive preventative maintenance for the health of the aircraft, its passengers and crew, and cargo. However, the ability to monitor and predict in such complex systems is currently limited. As a result, errors may occur. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A complete and enabling disclosure of the present technology, including the best mode thereof, to one of ordinary skill in the art is set forth in the specification with reference to the accompanying drawings, in which:

[0004] Figure 1 An example network of an aircraft digital twin is shown.

[0005] Figure 2 Shows Figure 1 An example implementation of an example engine model for an example aircraft model.

[0006] Figure 3 A model and snapshot management system is shown.

[0007] Figure 4 Shows Figure 3 Example implementations of example memory circuits.

[0008] Figure 5 Shows Figure 3 Example implementations of example processing circuits.

[0009] Figure 6 An example hierarchy or set of layers / levels forming a snapshot of a model graph is shown.

[0010] Figure 7 Another example representation of a set of hierarchical digital twins combined to describe an aircraft is shown.

[0011] Fig. 8A Describes the use Figure 3 An example database organization in a data storage layer of an example memory circuit.

[0012] Figure 8B Describes the use Figure 3 An example database organization in a data storage layer of an example memory circuit.

[0013] Figure 8C Describes the use Figure 3 An example database organization in a data storage layer of an example memory circuit.

[0014] Fig. 9 An example collection or network of digital twin models and related event processing is shown.

[0015] Fig.10 An example output in the form of a graphical user interface is shown.

[0016] Fig.11 It is used for implementation Figure 1-10 A flowchart of example hardware logic, machine-readable instructions, hardware-implemented state machines, and / or any combination thereof for an example digital twin model management system.

[0017] Fig.12 It is used for implementation Figure 1-10 A flowchart of example hardware logic, machine-readable instructions, hardware-implemented state machines, and / or any combination thereof for an example digital twin model management system.

[0018] Fig.13 is a block diagram of an example processing platform including a processor circuit configured to perform Figure 11-12 Example machine-readable instructions for implementing an example digital twin model management system.

[0019] Fig.14 yes Fig.13 A block diagram of an example implementation of a processor circuit.

[0020] Fig.15 yes Fig.13 A block diagram of another example implementation of a processor circuit.

[0021] The drawings are not drawn to scale. Instead, the thickness of a layer or region may be exaggerated in the drawings. Typically, the same reference numerals will be used throughout the drawings and the accompanying written description to refer to the same or similar parts. As used in this patent, stating that any part (e.g., layer, film, zone, region, or plate) is in any way on (e.g., positioned on, located at, disposed on, or formed on, etc.) another part means that the referred part is in contact with the other part, or the referred part is above the other part, with one or more intermediate parts located therebetween. Unless otherwise stated, connection references (e.g., attachment, connection, connection, and engagement) will be interpreted broadly and may include intermediate members between a collection of elements and relative movement between elements. In this way, connection references do not necessarily infer that two elements are directly connected and are in a fixed relationship to each other. Stating that any part is "in contact" with another part means that there is no intermediate part between the two parts.

[0022] Descriptors "first", "second", "third", etc. are used when identifying multiple elements or components that can be mentioned separately. Unless otherwise specified or understood based on the context of their use, such descriptors are not intended to confer any meaning of priority, physical order, or arrangement in a list, or temporal ordering, but are merely used as labels that are used alone to refer to multiple elements or components to facilitate understanding of the disclosed examples. In some examples, the descriptor "first" can be used to refer to an element in the detailed description, while the same element can be referred to by a different descriptor (e.g., "second" or "third") in the claims. In this case, it should be understood that such descriptors are only used to easily refer to multiple elements or components. DETAILED DESCRIPTION

[0023] Assets such as aircraft may include multiple parts, each of which is susceptible to errors, failures, updates, etc. Such assets may operate together or separately, and at times a part may be moved from one asset to another in a fleet. Alternatively or additionally, other changes in configuration, state, operation, performance, etc. occur to each individual asset over time. Tracking and responding to changes to a collection of assets over time presents technical challenges in terms of modeling, relationships, and temporal and spatial navigation. Certain examples provide models (e.g., asset object models), such as physics-based digital “twins,” which are virtual models of assets that are interconnected and / or interrelated over time, for improved physical modeling of assets and relationships and modeling over time.

[0024] Certain examples provide a framework or hierarchical structure of models and related systems and methods for interconnecting and organizing multiple models, such as digital twins, other asset object models, etc., to query, analyze, diagnose and / or adjust based on one or more criteria, questions, problems, other issues, etc. For example, the framework can correspond to a fleet or network of aircraft, to a specific aircraft that forms part of the fleet, to a specific engine on the aircraft, etc. For example, assume that a first engine is paired with a second engine on a first plane, and then the second engine moves to a second plane. If the first engine encounters a problem, the framework can be used to locate the second engine, which is now on the second plane, and also evaluate the problem with the second engine. In addition, the framework stores snapshots of a network or a set of digital twins and / or other data at various points in time to enable querying, replaying, modeling and / or extrapolation, etc., to determine what happened in the models at certain points in time, which may be contrary to what is happening in those models today. In this way, certain examples provide an interconnected framework based on devices and time.

[0025] The framework (e.g., digital twin network) provides multiple connected models at multiple snapshot times. Connections between models can be traversed at any time in the past. In some examples, relationships are recorded as change events, and asset-centric snapshots that capture these change events can be used for problem solving, repairs, preventive maintenance, other predictions, etc.

[0026] A digital representation, digital model, digital "twin" or digital "shadow" is a digital information structure about a physical system. That is, digital information can be implemented as a "twin" of a physical device / system / person, as well as information associated with and / or embedded in a physical device / system. A digital twin is linked to a physical system through the life cycle of the physical system. In some examples, a digital twin includes a physical object in real space, a digital twin of the physical object that exists in virtual space, and information linking the physical object to its digital twin. A digital twin exists in a virtual space corresponding to the real space, and includes links for data flow from the real space to the virtual space and links for information flow from the virtual space to the real space and other virtual subspaces.

[0027] In some examples, sensors connected to physical objects (e.g., aircraft, engines, etc.) can collect data and relay the collected data to a digital twin. For example, interactions between multiple digital twins can help improve modeling and prediction to diagnose problems, order maintenance, improve utilization and / or operations, etc. A digital twin is not a general model, but a collection of actual physics-based and / or math-based models that reflect the system / object and related characteristics, conditions, relationships, etc. In some examples, digital twins can be used for monitoring, diagnosis, prediction, adjustment, etc. Historical information, relationships, current and / or future information, etc. can utilize digital twins for predictive maintenance, problem diagnosis / determination, etc.

[0028] In contrast to computers, humans do not process information in a sequential, step-by-step process. Instead, people try to conceptualize a problem and understand its context. While a person can view data in reports, tables, etc., that person is most effective when viewing a problem visually and trying to find its solution. However, often when a person processes information visually, records it in alphanumeric form, and then tries to reconceptualize it visually, information is lost and the problem-solving process becomes much less efficient over time.

[0029] However, using digital twins enables people and / or systems to view and evaluate complex systems and associated trends, issues, improvements, etc. without the need to translate into data and back. Digital twins can be used for simulations and can also drive comparisons (e.g., between aircraft, between aircraft components, between time periods, etc.). Digital twins can be used to model and describe at the macro level (e.g., the entire aircraft, the entire engine, the entire fleet, etc.) and / or at the micro level (e.g., compressors, valves, controllers, etc.).

[0030] Certain examples provide a framework or architecture including a digital twin network. The example framework interconnects multiple digital twins and enables querying, traversing, and interacting with one or more of the interconnected multiple digital twins. Certain examples provide one or more "snapshots" of a digital twin network at different points in time. In this way, digital twins for assets (e.g., engines, controllers, fuselages, aircraft, etc.) can be compared over time to identify changes in the characteristics, properties, states, etc. of the digital twin (e.g., how the performance of the engine evolves over time, etc.). In addition, for a given point in time, for example, the states of multiple digital twins can be identified and retrieved from the network (e.g., what is the state of engine 2 on the failure date of engine 1, based on their respective digital twins). Therefore, for example, the highly dynamic characteristics of assets with relationships that change over time (e.g., an engine is moved from one aircraft to another or otherwise replaced, a controller is installed with an engine, an aircraft is deployed together, etc.) can be modeled, captured, and utilized for comparison, prediction, and / or other processing.

[0031] Using asset digital twins, aircraft and / or aircraft components can be modeled, tracked, analyzed, and improved / maintained over their lifecycles. A digital twin can be expressed individually for a single asset (e.g., a jet engine, and its associated attributes, such as health and status, etc.). For example, by linking twins into one or more directed graphs, multiple digital twins can also capture various relationships between multiple assets (e.g., a jet engine is mounted on a fuselage, paired with another engine, etc.). In this way, the properties of the digital twins and the relationships between the digital twins can be captured, stored, modeled, analyzed, and utilized over time.

[0032] In some examples, a digital twin is an asset model that captures how an asset operates over time. Multiple digital twins are interconnected according to an asset model that is a digital twin network (also referred to herein as a graph of digital twins or a digital twin graph). When a change occurs between interconnected assets (and associated digital twins), a change event is captured and / or otherwise created and stored in a snapshot. In some examples, a snapshot is a snapshot of all or part of a network of digital twin models at a specific point in time. The snapshot is stored, and multiple snapshots form a record of the evolution of the state of the network. For example, a cloud database stores changes to a digital twin network over time as multiple snapshots. A change event represents a change to a digital twin network.

[0033] The history of changes in the digital twin can be navigated via a snapshot of the network diagram of the digital twin. For example, change events from the digital twin network can be captured, modeled and stored for further query, analysis and adjustment. The digital twin network implements asset lifecycle management by an overall observation of the health status and state of assets over time and the relationship between assets. For example, conceptual object modeling methods such as ontology (e.g., digital twin definition language (DTDL), other description / definition languages, other modeling methods, etc.) can be used to model the digital twin of the corresponding asset. The actual instances of the asset digital twin, their attributes, and the links between them that conform to the asset object model constitute the time point digital twin diagram. For example, in order to enable applications to utilize change event data from the digital twin diagram, some examples provide a three-step process, including 1) ingestion of change event data, 2) persistent storage of change event data via a cloud-based database service, and 3) querying of change event data via items defined in the asset object model.

[0034] In some examples, one or more data models for digital twin snapshot graphs are defined for temporally consistent representation of change event data from digital twin graphs within a cloud-scale multi-model / document database. Data partitioning and indexing strategies for snapshot data in the data model are determined based on the asset object model. Change events are captured and directed via an event processing service and converted into a snapshot data model for ingestion into a database, for example, via functions as a service and / or serverless functions. An application programming interface (API) is provided to support time-based analysis (e.g., point-in-time queries, range queries, etc.). In some examples, a parser converts high-level queries into a corresponding series of low-level queries for a database service.

[0035] "Include" and "comprising" (and all forms and tenses thereof) are used herein as open-ended terms. Thus, whenever a claim employs any form of "include" or "comprising" (e.g., includes, contains, has, etc.) as a preamble or in any kind of claim narrative, it should be understood that additional elements, terms, etc. may be present without exceeding the scope of the corresponding claim or narrative. As used herein, when the phrase "at least" is used as a transitional term, such as in the preamble of a claim, it is open-ended in the same manner as the terms "include" and "comprising" are open-ended. The term "and / or" when used, for example, in a form such as A, B, and / or C, refers to any combination or subset of A, B, C, such as (1) A alone, (2) B alone, (3) C alone, (4) A and B, (5) A and C, (6) B and C, and (7) A and B and C. As used herein in the context of describing structures, components, items, objects, and / or things, the phrase "at least one of A and B" is intended to refer to embodiments that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing structures, components, items, objects, and / or things, the phrase "at least one of A or B" is intended to refer to embodiments that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. As used herein in the context of describing the performance or execution of processes, instructions, actions, activities, and / or steps, the phrase "at least one of A and B" is intended to refer to embodiments that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B. Similarly, as used herein in the context of describing the performance or execution of processes, instructions, actions, activities, and / or steps, the phrase "at least one of A or B" is intended to refer to embodiments that include any of (1) at least one A, (2) at least one B, and (3) at least one A and at least one B.

[0036] As used herein, singular references (e.g., "a," "an," "first," "second," etc.) do not exclude a plurality. As used herein, the term "a" or "an" entity refers to one or more of that entity. The terms "a" (or "an"), "one or more," and "at least one" are used interchangeably herein. In addition, although listed separately, multiple devices, elements, or method actions may be implemented by, for example, a single unit or processor. In addition, although individual features may be included in different examples or claims, these features may possibly be combined, and inclusion in different examples or claims does not mean that a combination of features is not feasible and / or disadvantageous.

[0037] As used herein, the terms "system," "unit," "module," "engine," "component," and the like may include hardware and / or software systems that operate to perform one or more functions. For example, a module, unit, or system may include a computer processor, controller, and / or other logic-based device that performs operations based on instructions stored on a tangible and non-transitory computer-readable storage medium (e.g., a computer memory). Alternatively, a module, unit, or system may include a hard-wired device that performs operations based on the hard-wired logic of the device. The various modules, units, engines, and / or systems shown in the accompanying drawings may represent hardware that operates based on software or hard-wired instructions, software that directs hardware to perform operations, or a combination thereof.

[0038] Figure 1 An example network 100 of multiple aircraft represented by aircraft models 101, 102, 103 is shown. Each aircraft model 101-103 is associated with one or more asset models, such as engine models 110, 112, 113, 114, 115, landing gear models 120, 121, 122, fuselage models, etc. Each asset model, such as engine models 110-115, may be further associated with one or more component models 130, 131, 132, which may be used to represent and evaluate engine 110-115 subsystems, such as compressors, combustors, turbines, controllers, etc. Asset relationships change over time as assets are repaired, replaced, reconfigured, etc. The queue or network 100 of models 101-132 may help track, correlate, and predict changes when organized as a framework.

[0039] Figure 2 Shows Figure 1 An example implementation of an example engine model 110 for an aircraft model 101. Figure 2 In the example of , a digital twin of the engine model 110 is implemented using a digital twin data model 201 having a data security layer 205 that regulates access to and from the digital twin data model 201. The example digital twin data model 201 may be composed of a plurality of data structures 210, 211, 212, 213, 214 that are related via a federated multimodal data integration layer 220. For example, Figure 2As shown, the digital twin data model 201 corresponding to the engine model 110 is composed of configuration data 210, operation data 211, time series sensor data 212, maintenance records 213, other sources 214, etc. The example digital twin data model 201 for the engine model 110 can be used to enable query 230, drive analysis 231, generate dashboards 232, provide visualization 233, remote storage 234, etc. The multimodal data integration layer 220 enables the various data structures 210-214 to communicate information about the relevant engine at various points in time with new information, query 230, drive analysis 231, etc.

[0040] In this way, the engine model 110 can be implemented as a computable hierarchical asset model that can be queried and explored. The digital twin data model 201 forms a digital record of the physical asset, including real-time instance data that captures knowledge about the components and / or features of the asset. In this way, the digital twin data model 201 facilitates the traceability of the asset and its components over time based on location, etc. The digital twin data model 201 enables the integration and analysis of data across repositories in a single logical view without requiring a priori physical unification of the data.

[0041] Although the engine model 110 is shown Figure 2 , but one or more of the asset models 110-132 may be implemented using a data modeling approach similar to that employed in the example digital twin data model 201. Using such a model, the lifecycle of an asset may be monitored, and a holistic, actionable view of the asset health and status (e.g., past, present, and future) may be provided.

[0042] Figure 3 A model and snapshot management system 300 for ingesting, updating, managing, querying, and processing digital twin models for asset health management is shown. The example snapshot management system 300 includes an interface circuit 310, a processing circuit 320, and a memory circuit 330. All or part of the snapshot management system 300 can be cloud-based, edge-based, implemented on one or more servers and data stores, etc.

[0043] The example interface circuit 310 processes information about an asset (e.g., an aircraft, an engine, a controller, a landing gear, another aircraft component, etc.) to create a new digital twin to be stored in the memory circuit 330, update an existing digital twin stored in the memory circuit 330, create a snapshot to be stored in the memory circuit 330, process queries about one or more snapshots, etc. The example interface circuit 310 also provides outputs from one or more digital twin models, snapshots, etc. in the memory circuit 330 driven by the processing circuit 320.

[0044] The example processing circuit 320 manages asset models or digital twins and inputs data and / or queries in the memory circuit 330 via the interface circuit 310. The processing circuit 320 tracks changes to the digital twin of the asset over time and changes to the digital twin network over time, and enables the ingestion of change events, storage of snapshots representing these change events, and querying of snapshots and / or models via an application programming interface (API), etc. In this way, for example, the processing circuit 320 creates a new digital twin data model 110-132 based on input data from the interface circuit 310. For example, the processing circuit 320 also updates the existing digital twin data model 110-132 stored in the memory circuit 330 based on the input from the interface circuit 310. Such updates may include changes to the asset model, changes to the digital twin data model associated with the asset, etc. The processing circuit 320 also facilitates the query of the memory circuit 330 based on the input from the interface circuit 310 to identify one or more digital twin data models, determine the relationship between the models, locate snapshots of the models in time, compare models, etc.

[0045] In some examples, the processing circuit 320 converts a change event from a network or graph (e.g., a digital twin graph) 100 of modeled assets into a snapshot associated with a subset of the asset models 110-132. For example, the change event can be provided to the processing circuit 320 via the interface circuit 310. For example, the change event can include adding a digital twin to the network graph, such as adding an aircraft to a fleet, adding an engine slot to a fuselage, attaching an engine on a fuselage, maintaining on an engine, flying an aircraft, etc. For example, the processing circuit 320 uses the change event to process the digital twin network (network graph) 100 including the associated asset models 110-132 (e.g., aircraft, fuselage, and engine models, etc.) to update the state of the associated models 110-132 based on the change event. The processing circuit 320 saves a subgraph or network of a subset of the asset models 110-132 as a snapshot that reflects the state and content / configuration of the affected asset models 110-132 at the point in time when the change event occurs. The snapshot is stored by processing circuit 320 in memory circuit 330 .

[0046] Memory circuitry 330 stores a plurality of asset models 110-132 (e.g., for fleets, for aircraft, for aircraft subsystems, etc.) organized in an interconnected network. Models 110-132 are linked in memory circuitry 330 (e.g., via a graph such as a connection graph, a multigraph, a directed graph, etc., and / or other linking / interconnecting memory arrangements). Memory circuitry 330 enables the network of models 110-132 to be stored, updated, retrieved, and / or otherwise utilized securely and stably, such as by processing circuitry 320. Memory circuitry 330 stores captured snapshots of models 110-132 interconnected in network 100 for query, retrieval, and analysis.

[0047] In some examples, snapshots of subgraphs or networks connecting models 110-132 can be organized in one or more containers and / or other logical data structures in one or more databases in memory circuit 330. For example, one or more containers can be partitioned for efficient database operations and to isolate snapshots and / or associated models 110-132 within containers. In this way, different snapshots and associated models or asset levels (e.g., operators, fuselages, engine slots, engines, etc.) can be associated with different containers. In some examples, a set of containers in memory circuit 330 can include attribute containers and relationship containers for each managed asset (e.g., aircraft, engine, etc.) in the asset model. For example, a snapshot in an attribute container includes attributes (e.g., health status, status, etc.) of an asset instance (e.g., engine 123, etc.) of an asset type (e.g., engine, etc.) at a given point in time. Snapshots in relationship containers connect multiple models of multiple types. For example, a snapshot in an engine relationship container can include links between an engine instance (e.g., engine 123) and all other assets to which it is connected at that point in time (e.g., fuselage 1, controller 2, etc.). For example, the memory circuit 330 may include a lookup container to facilitate organization of snapshots in other containers in the memory circuit 330. For example, the snapshots may be directed by the processing circuit 320 to the relevant container.

[0048] Figure 4 An example implementation of a memory circuit 330 including a plurality of containers is shown. Figure 4 As shown in the example of , the containers of the organizational memory circuit 330 may include a lookup container 410, an asset attribute container 420 for each type of digital twin in the asset model, and an asset relationship container 430 for each type of digital twin in the asset model. Figure 4The example containers 410-430 of FIG. 4 are used to organize snapshots of changes to networks of asset models 110-132, including models for assets such as aircraft, fleets of aircraft, aircraft parts, etc. For example, changes associated with engines, multiple assets on an aircraft, aircraft, fleets of aircraft, etc., can be modeled and stored as interconnected snapshots captured at a point in time in asset attribute containers 420 and asset relationship containers 430.

[0049] The processing circuit 320 may access the lookup container 410 using input data related to change events affecting assets. The lookup container 410 is connected to the asset relationship container 430. The lookup container 410 indexes change events in the digital twin network by the asset that is the subject of the relationship that is changed, and relates the relationship changes to the assets in the asset relationship container 430. Using the mapping information of the lookup container 410, the processing circuit 320 may identify connected and / or otherwise related assets via the asset relationship container 430. In this way, analysis of an engine may utilize a model of the engine including an engine attribute model and an engine relationship model, for example, where organization of the engine relationship model is facilitated via a lookup data structure.

[0050] In operation, for example, the interface circuit 310 receives a query, such as from an aircraft controller (e.g., a full authority digital engine control (FADEC), other electronic engine controllers, other aircraft controllers, a flight management system, an aircraft maintenance controller, etc.). The query may be generated in response to a change detected relative to an asset (e.g., maintenance, adjustments, errors, or failures occurring in an aircraft, fuselage, engine slot, engine, landing gear, controller, sensor, etc.). The interface circuit 310 provides the query to the processing circuit 320, which parses the query and interrogates the memory circuit 330 to access the relevant snapshot (e.g., via the asset attribute container 420 for the engine and / or other relationship container 430 for the engine). For example, access may be facilitated via an application programming interface (API) 405. For example, an API to access an asset attribute container or relationship container utilizes a container name (e.g., engine_relationship, etc.), an asset identifier (e.g., engine123, etc.), and a time point (e.g., 01 / 01 / 2020, etc.) to query the container for associated snapshots related to the asset. In some examples, instead of a time point, the API may accept a time range (e.g., a start time and an end time, etc.) for retrieving multiple snapshots. For example, for a search container, the API for access may include a relationship identifier (e.g., engine1_controller2, etc.). Processing circuitry 320 processes the snapshot, which includes the properties of the engine models 110-115 in the snapshot and the relationships between the models 110-132 stored in memory circuitry 330 (and / or accessible in another memory structure via interface circuitry 310).

[0051] Processing circuit 320 tracks relationships between asset digital twins with similar attributes. For example, a first engine represented by engine model 110 may be paired with a second engine represented by engine model 111 on a first aircraft represented by aircraft model 101. The first engine is then moved to a second aircraft (represented by aircraft model 102) and paired with a third engine (represented by engine model 112). If there is a problem with the first engine (e.g., a failure, suboptimal performance (e.g., running hot, excessive fuel consumption, etc.), etc.), processing circuit 320 may be alerted via interface circuit 310 and may access memory circuit 330 to query and track relationships with the first engine model 110. The second engine may be identified via the first engine model 110 and a snapshot associated with a point in time when the first engine is associated with the first aircraft, and a second snapshot starting from the same point in time when the first aircraft is associated with the second engine. Then, for example, the second engine and its model 111 may be evaluated by analyzing the attributes of the second engine and its model 111 at that point in time to determine whether corrective and / or preventive measures should be taken on the second engine and the first engine to resolve the problem encountered by the first engine.

[0052] For example, high operating temperatures experienced in a first engine (e.g., above an expected temperature threshold) may also be evaluated in a second engine. Similarly, unexpected fuel consumption of a first engine (e.g., greater than expected fuel consumption, reference fuel consumption, or average fuel consumption) may be evaluated in a second engine to identify the same or similar issues. Alternatively (or additionally), analysis of models 110-132 in a snapshot may reveal opposing behaviors in an asset. For example, a first engine may be operating at a higher temperature, and analysis of the second engine model 111 may reveal that the second engine is operating inefficiently, requiring the first engine to withstand more loads during the flight phase of the snapshot. In this way, for example, snapshots of models 110-132 enable analysis and correlation between assets, thereby improving identification of difficult problems and solutions that affect multiple interrelated components.

[0053] As another example, snapshots captured at different points in time may be compared to identify changes (and / or lack of changes) in the state of the associated digital models 110-132 at the various times associated with the snapshots. In this way, a problem (e.g., overheating, imbalance, fuel inefficiency, abnormal airflow, inoperability, etc.) identified in an asset may be evaluated by retrieving and processing the current snapshot and one or more previous snapshots to determine when the problem occurred in the asset, as evidenced by a similar occurrence in one or more previous snapshots. At the time of the first occurrence of the problem and / or in snapshots prior to the first occurrence, the state of the asset and / or other components may be evaluated via the models 110-132 to try and determine causes, symptoms, related asset problems, etc. Such analysis may be used to correct the problem, identify the likelihood of the problem occurring in the future, predict the problem in related assets for the snapshot, etc.

[0054] In some examples, snapshots may be compared at the same point in time. For example, a first snapshot of a first set of digital twin models 110-132 at time t1 may be compared to a second snapshot of a second set of digital twin models 110-132, where the intersection between the first set and the second set is non-empty (e.g., there is overlap in the digital models 110-132 between the sets).

[0055] In this way, the network of models 110-132 in the memory circuit 330 provides an interconnected network of digital twins and / or other models at multiple snapshot times. The processing circuit 320 can traverse the connections between the models 110-132 at multiple storage times (e.g., snapshots) in the past. Relationship change events recorded as asset-centric snapshots can be used for problem solving, repair, preventive maintenance, other predictions, etc. Change events about the associated models 110-132 are stored as snapshots, and queries from the processing circuit 320 can dynamically jump between the models 110-132 and the associated snapshots to determine causes, predict results, prescribe maintenance and / or other adjustments, manage asset lifecycles and associated use / repair / replacement, etc. For example, life-limited parts, long-term use parts, etc. can be modeled, monitored, and managed via the framework of the models 110-132 in the memory circuit 330 and the related analysis (e.g., retrospective, predictive, etc.) of the processing circuit 320.

[0056] Figure 5 An example implementation of processing circuit 320 is shown. Figure 5 In the example of , one or more service APIs 510 enable access to the processing circuit 320 via the interface circuit 310. The example processing circuit 320 also includes one or more data set change handlers 520 to update and / or create one or more digital twin models 110-132 in the memory circuit 330. Figure 5 In the example of , the current state asset model 530 includes one or more digital twins and receives model updates (e.g., via the change handler 520). The service API 510 and the current state asset model 530 interact with the model processor 540 to process and adjust the information.

[0057] For example, Figure 5 As shown, the model processor 540 can be configured to include and facilitate the ingestion of change events 541, the storage of snapshots 542, and querying via a high-level API 543. Figure 5 As shown in the example of , the processing circuit 320 processes the ingestion of change events 541 by extracting one or more change events from one or more digital twins into an event grid and processing the events in the event grid to form one or more snapshots related to a subset of the current state asset model 530.

[0058] The generated snapshot is then stored 542 in a database by the memory circuit 330 via a snapshot storage service API, according to the snapshot data model. As described above, the snapshot data model is arranged for efficient access to attributes and relationships. The model processor 540 then supports queries 543 of the models 110-132 stored in the memory circuit 330 via the API. For example, a query on the health of engine X on a certain date can be used to query the models 110-132, such as using an API-based GraphQL query, etc. Different query types can be parsed according to different schemas, and one or more parsers of the query 543 can return results, metrics, etc. from the storage service 542.

[0059] In this way, the model processor 540 can perform queries based on asset models and time (e.g., time model queries). The parser can convert high-level queries into one or more low-level queries based on the associated data model. The API can facilitate querying and post-processing results of the memory circuit 330 to drive actionable results (e.g., triggering repair and / or other maintenance of assets (e.g., scheduling maintenance, taking an aircraft offline or otherwise shutting down or disabling an asset for maintenance, etc.), detection of assets, reconfiguration of assets (e.g., adjustment of settings or parameters of assets, etc.), dependencies between assets, generating alarms / warnings / alerts, triggering modeling of problems from a first asset in a second asset of the same type or a second asset connected to a first asset, etc.).

[0060] like Figure 5As shown in the example implementation of , the processing circuit 320 can generate and / or update a digital twin model for storage in the memory circuit 330, create a snapshot of the model network, query the model to obtain information to drive prediction, determination, adjustment, maintenance, simulation, replay, extrapolation, etc. Changes in asset attributes, asset relationships, etc. can be captured as change events and provided to the processing circuit 320. Change events can drive the creation of digital twin models, the update of digital twin models, the creation of relationships between models, the update of relationships between models, etc. When a relationship change event is introduced into the processing circuit 320, an associated snapshot is created based on the event and associated with the asset model 110-132. Different types of change events can be interpreted in different ways and converted into snapshots and / or models in different ways. When the change event lacks context, converting the change event into one or more snapshots combined with the asset model 110-132 and other information provides context to one or more change events (e.g., due to model attributes, relationships, other information about the asset, etc.).

[0061] The snapshot is directed to the memory circuit 330 via 542 the snapshot storage service API for storage according to its associated model 110-132 (e.g., in the appropriate asset relationship container 430 corresponding to its model, etc.). For example, the processing circuit 320 can then convert a high-level query for the state of the asset into a low-level query of the relevant container in the memory circuit 330, which includes the model and the information to answer the query. The low-level query of the data structure in the memory circuit 330 can be resolved quickly and at a low computational cost.

[0062] For example, when a new engine slot is added to a particular fuselage at a given timestamp, the processing circuit 320 identifies the two digital twin models involved: the fuselage model and the engine slot model. The model processor 540 creates a snapshot of the network including the engine slot digital twin model and the fuselage digital twin model at the given timestamp. For example, the model processor 540 determines that at timestamp 1, fuselage 0 has engine slot 0 and engine 0 is installed on engine slot 0. At timestamp 2, engine 0 is still installed on engine slot 0. At timestamp 3, fuselage 0 adds engine slot 1. Snapshots can analyze events and information from the perspective of different assets (e.g., from the perspective of engine slots, fuselages, aircraft, etc.) and the relationships between these assets. Changes to one snapshot or model are propagated to other related models / snapshots. However, changes that affect one may not affect another. In this way, snapshots created at the same timestamp can be queried to evaluate what happened / what has happened in multiple related digital twin models. For example, the processing circuitry 320 maintains consistency between snapshots of the different models 110 - 132 at a given timestamp so that correlation can occur when a query is made.

[0063] For example, in response to a blade off event occurring in engine 0 mounted on engine slot 0, a collection of snapshots may be queried. Prior snapshots may be retrieved in response to the query and analyzed to determine events, causes, etc., such as an increase in temperature, etc., that led to the blade off event. Instability in engine slot 0 or imbalance due to the addition of engine slot 1 may be identified in a snapshot prior to the blade off event of engine 0. Such events, occurrences, etc. may be provided, analyzed, and used to determine causes of changes in engine 0 that resulted in blade-to-casing friction, etc., leading to a blade off event at a subsequent snapshot time. Collections or groups of snapshots associated with models 110-132 at different points in time may be queried and analyzed accordingly.

[0064] The example model processor 540 converts relationship change events into snapshots, which are generated as local graphs representing the state of a set of digital twin models 110-132 at a certain timestamp. For example, a snapshot graph may involve one or more digital twin models 110-132. The graph and associated asset models may be layered or divided into levels such as operator, fuselage, engine slot, engine, etc. For example, the operator level shows one or more associated fuselages; the fuselage level shows one or more engine slots; and the engine slot level shows one or more associated engines, etc. Figure 6 An example hierarchical structure or set of layers / levels 610 - 640 forming a model map snapshot 600 of an operator 610 , a fuselage 620 , an engine slot 630 , and an engine 640 is shown.

[0065] Figure 7 Another example representation of a hierarchical group 700 that is combined to describe a digital twin 710-740 of an aircraft is shown. Figure 7 As shown in the example of , an operator 710 can be represented by an identifier and is associated with one or more fuselages 720 (e.g., operating). One or more fuselage models 720 contain asset models, such as one or more engine slot models 730 and one or more landing gear slot models 740. One or more engine slot models 730 have attached engine models 735. Each of the one or more engine models 735 provides the relevant status of the engine. Similarly, one or more landing gear slot models 740 have attached landing gear models 745. Each of the one or more landing gear models 745 provides the relevant status of the landing gear (e.g., extended, retracted, faulty, etc.).

[0066] Fig. 8A-C depicts an example database organization in a data storage layer 800 for the memory circuit 330. The example data storage layer 800 implements a highly available, globally scalable, multi-model database platform. In some examples, the data storage layer 800 is rate-limited at certain points and throughput-limited at the database and / or container level. As such, partitioning strategies and methods for storing snapshot data in containers are important for reducing or minimizing the containers searched and partitions scanned in response to a query.

[0067] Fig. 8A An example organization or hierarchy of a data storage layer 800 including database accounts 810 is shown. Within each database account 810, one or more databases 820 may be organized to store models 110-132, snapshot data, and / or other information, data structures, functions, etc. Each database 820 includes one or more containers 830. Containers 830 include projects 840, merge processes 850, conflicts 860, triggers 870, user-defined functions 880, and stored procedures 890 to facilitate storage, updating, querying, and actionable results in conjunction with processing circuitry 320.

[0068] Figure 8B A more detailed view of an example implementation of container 830 is provided. Figure 8B As shown in the example of, for example, container 830 in multi-model database 820 can be configured to store information structured as collection 832, table 834, or graph 836. Container 830 can be partitioned and / or otherwise organized to store asset models and associated information, such as relationships, attributes, etc. Model and snapshot data can be organized via one or more of table 834, graph 836, etc. to facilitate query, retrieval, and modification.

[0069] Figure 8C is a more detailed view of an example implementation of item 840. Figure 8C As shown in the example of , the items 840 of the container 830 can be organized into documents 841, rows 843, nodes 845, edges 847, etc. In this way, the items 840 enable the elements of the container 830 to be easily searched. Document 841 identifies the content of the item 840 in the collection 832. Row 843 specifies the location in the table 834. For example, node 845 and edge 847 identify the location in the graph 836. In some examples, the data storage layer for the snapshot data model can be implemented based on the collection of items (documents), such as Figure 8C However, the data storage layer can be organized to represent the snapshot data model in other ways.

[0070] Fig. 9An example collection or network 900 of digital twin models 101-130 (eg, aircraft model 101, engine model 110, engine model 112, gear model 120, component model 130, etc.) and associated event processing are shown. Fig. 9 As shown in the example of , multiple digital twin models 101-130 and associated functions 920, 922, 924 are interconnected. Functions 920-924 may include processing for telemetry messages, lifecycle notifications, property change notifications, edge change notifications, model change notifications, query processing, etc., and may affect one or more connected models 101-130. Fig. 9 In the example of , the aircraft digital twin 101 is connected to the engine digital twin 110 and the engine digital twin 111. The aircraft digital twin 101 is also connected to the landing gear digital twin 120. The engine digital twin 111 is connected to the compressor digital twin 130. The event scheduler 930 responds to incoming events and applies one or more filters 940, 945 to direct events and / or model data and / or other content to one or more event handlers 950, such as one or more event processing services, service buses, etc. The event-related content is then processed 960 to generate actions, such as actionable outputs, storage, historical comparisons, analysis, time series insights, etc. The example processing function 960 can interpret different event types: create asset events, change asset attributes, create relationships, convert events to attribute and / or relationship snapshots, etc.

[0071] Fig.10 An example output in the form of a graphical user interface 1000 is shown. Via the example interface or dashboard 1000, multiple assets 1010 can be visualized and monitored. The graphical user interface (GUI) 1000 can be driven by the example interface circuit 310 to display information, provide information in response to user selections, generate change events, trigger corrective actions, display instructions, provide instructions, etc. The example GUI 1000 may include aircraft snapshots 1020, reliability metrics 1022, asset data (AD) compliance 1024, etc. Events 1030 generated relative to the aircraft can be displayed via the GUI 1000. Information 1040 pulled from the models 101-132 of the aircraft can also be displayed via the GUI 1000. The analysis workbench can be used to trigger various forms of queries to the digital twin model management system, including those that retrospectively analyze the state of connected digital twin models over time.

[0072] Despite Figure 1-10, an example implementation of a digital twin model management system 300, a processing circuit 320, a model network 900, a graphical user interface 1000, etc. is shown, but one or more elements, processes, and / or devices may be combined, divided, rearranged, omitted, eliminated, and / or implemented in any other manner. In addition, the system may be implemented by hardware, software, firmware, and / or any combination of hardware, software, and / or firmware. Figure 1-10 Thus, for example, it may be implemented by one or more analog or digital circuits, logic circuits, programmable processors, programmable controllers, graphics processing units (GPUs), video processing units (VPUs), accelerator cards, digital signal processors (DSPs), application specific integrated circuits (ASICs), programmable logic devices (PLDs), trusted platform modules (TPMs), field programmable gate arrays (FPGAs), and / or field programmable logic devices (FPLDs). Figure 1-10 When any device or system claim of this patent is read to cover pure software and / or firmware implementations, Figure 1-10 At least one example element of is expressly defined to include a non-transitory computer-readable storage device or storage disk, such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc., including software and / or firmware. In addition, Figure 1-10 The elements may include one or more elements, processes and / or devices in addition to or instead of Figure 1-10 Those elements, processes and / or devices shown in, and / or may include more than one of any or all of the elements, processes and devices shown. As used herein, the phrase "in communication," includes variations thereof, including direct communication and / or indirect communication through one or more intermediate components, and does not require direct physical (e.g., wired) communication and / or constant communication, but additionally includes selective communication at periodic intervals, predetermined intervals, non-periodic intervals and / or one-time events.

[0073] exist Figure 11-12 1 is a flowchart representing example hardware logic, machine readable instructions, hardware implemented state machines, and / or any combination thereof for implementing the example snapshot management system 300 and / or its components. The machine readable instructions may be one or more executable programs or portions of executable programs executed by a computer processor and / or processor circuit, such as the following in conjunction with Fig.13The example snapshot management system 300 and / or example processor platform 1300 discussed herein may be embodied in software stored on a non-transitory computer-readable storage medium such as a CD-ROM, floppy disk, hard drive, DVD, Blu-ray disk, or memory associated with processor 1312, but the entire program and / or portions thereof may also be executed by a device other than processor 1312 and / or embodied in firmware or dedicated hardware. In addition, although reference is made to Figure 11-12 The flowchart shown describes an example procedure, but many other methods of implementing the example snapshot management system 300 may also be used. For example, the order of execution of the boxes may be changed, and / or some of the boxes described may be changed, eliminated, or combined. Additionally or alternatively, any or all of the boxes may be implemented by one or more hardware circuits (e.g., discrete and / or integrated analog and / or digital circuits, FPGAs, ASICs, comparators, operational amplifiers (op-amps), logic circuits, etc.) that are configured to perform corresponding operations without executing software or firmware. Processor circuits may be distributed at different network locations and / or local to one or more devices (e.g., a multi-core processor in a single machine, multiple processors distributed on a server rack, etc.).

[0074] The machine-readable instructions described herein may be stored in one or more of a compressed format, an encrypted format, a segmented format, a compiled format, an executable format, a packaged format, etc. The machine-readable instructions as described herein may be stored as data or data structures (e.g., portions of instructions, codes, representations of codes, etc.) that can be used to create, manufacture, and / or generate machine-executable instructions. For example, the machine-readable instructions may be segmented and stored on one or more storage devices and / or computing devices (e.g., servers) located at the same or different locations of a network or a collection of networks (e.g., in the cloud, in an edge device, etc.). The machine-readable instructions may need to be installed, modified, adapted, updated, combined, supplemented, configured, decrypted, decompressed, unpacked, distributed, reassigned, compiled, etc., so that they can be directly read, interpreted, and / or executed by a computing device and / or other machine. For example, the machine-readable instructions may be stored in multiple parts that are individually compressed, encrypted, and stored on separate computing devices, where the parts, when decrypted, decompressed, and combined, form a set of executable instructions that implement one or more functions that together may form a program such as described herein.

[0075] In another example, the machine-readable instructions may be stored in a state where the instructions can be read by a processor circuit, but a library (e.g., a dynamic link library (DLL)), a software development kit (SDK), an application programming interface (API), etc., may need to be added in order to execute the instructions on a particular computing device or other device. In another example, the machine-readable instructions and / or corresponding programs may need to be configured (e.g., stored settings, data inputs, recorded network addresses, etc.) before they can be executed in whole or in part. Thus, as used herein, a machine-readable medium may include machine-readable instructions and / or programs regardless of the particular format or state of the machine-readable instructions and / or programs when stored or otherwise at rest or when in transmission.

[0076] The machine-readable instructions described herein may be represented by any past, present or future instruction language, scripting language, programming language, etc. For example, the machine-readable instructions may be represented using any of the following languages: C, C++, Java, C#, Perl, Python, JavaScript, Hypertext Markup Language (HTML), Structured Query Language (SQL), Swift, etc.

[0077] As mentioned above, Figure 11-12 The example processes of can be implemented using executable instructions (e.g., computer and / or machine readable instructions) stored on a non-transitory computer and / or machine readable medium, such as a hard drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and / or any other storage device or storage disk in which information is stored for any duration (e.g., for an extended period of time, permanently, for brief instances, for temporary buffering, and / or for caching of information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and / or storage disk, and to exclude propagated signals and to exclude transmission media.

[0078] Fig.11 1 is a flow chart of another example method 1100 for managing a digital twin framework. The process 1100 varies depending on whether the processing circuit 320 is to create a new digital twin, update an existing digital twin, or query a network or graph of digital twins.

[0079] At box 1110, the processing circuit 320 is used to create a new digital twin model 101-132 of the asset. For example, a new engine added to the engine slot of the fuselage can be generated as a new model 110-115 of the physical engine structure and its configuration and operation. At box 1112, a new physics-based model construction (e.g., machine learning neural network, graph, other model, etc.) is generated based on a set of inputs (e.g., data, settings, simulation, etc.) describing the asset (e.g., aircraft, fuselage, engine, landing gear, controller, etc.) to form a digital twin model 101-132 of the asset. In addition, when or after creating a new digital twin model, the processing circuit 320 creates a new connection in the network of digital twin models 101-132 by linking the newly created digital twin model to other new or existing digital twin models 101-132 in the network. In this way, a graph or network of digital twin models 101-132 is created, updated, etc.

[0080] At box 1114, the state of a set of digital twin models 101-132 in the network is captured, and any newly created relationships for the digital twin models 101-132 in the network are captured as snapshots. For example, the state of the newly created model 101-132 including operations, configurations, properties, etc. is captured, and the state of the network of models 101-132 interconnected with the newly created model is captured as snapshot 0 at timestamp t0. At box 1116, the snapshot of the digital twin model network is stored in the memory circuit 330. For example, the snapshot including the digital twin models 101-132 and the associated model states, relationships, etc. can be stored in the asset attribute container 420 and / or the asset relationship container 430 to allow further querying, etc.

[0081] At box 1120, the processing circuit 320 is used to update the existing digital twin model 101-132. At box 1122, the specific digital twin model 101-132 is retrieved from the memory circuit 330, and the snapshot associated with the specific digital twin model 101-132 is retrieved via the lookup container 410. At box 1124, the model processor 540 of the processing circuit 320 uses the input (e.g., one or more change events, update data, simulation, etc.) to update the state of the digital twin model 101-132.

[0082] At block 1126, the state of the model network associated with the updated digital twin model 101-132 is captured as a snapshot. For example, the state of the updated model 101-132 including operations, configurations, relationships, properties, etc. is captured as snapshot 1 at time 1. At block 1128, the updated digital twin model and the associated snapshot are stored in the memory circuit 330. For example, the model state and / or snapshot may be stored in the asset property container 420 and / or the asset relationship container 430 to enable further querying, etc. In this way, the containers 420, 430, etc. store collections or groups of snapshots for querying, analysis, etc.

[0083] At box 1130, the processing circuit 320 queries the framework of the digital twin 101-132. At box 1132, the framework or network of digital twin models 101-132 stored in the memory circuit 330 (e.g., stored in one or more containers, etc.) is queried based on identifiers, search terms, types, conditions, asset categories, etc. For example, a specific snapshot (e.g., a snapshot of a model associated with a specific aircraft at a specific time) can be queried for a known set of digital twin models 101-132. The query can request a snapshot of a digital twin model 101-132 including a specific engine, a specific type of engine, an identified problem, a relationship, etc. At box 1134, once the digital twin model 101-132 associated with the query is identified, the snapshot associated with the model 101-132 is retrieved. At box 1136, the retrieved snapshots are correlated. For example, the model processor 540 of the processing circuit 320 correlates the retrieved snapshots about the query (e.g., a snapshot of two digital twin engine models on the same fuselage at the time in question, etc.). Snapshots may be related based on time, relationship, question, configuration, etc. to provide a set of snapshots with defined or otherwise identified relationships to support a query (e.g., snapshots of the same aircraft over time, snapshots of different aircraft with the same type of engine, snapshots of different aircraft with the same engine installed at different points in time, etc.).

[0084] At block 1138, processing circuitry 320 analyzes, generates, and outputs results to the query based on the correlated and processed snapshots. For example, in response to a query regarding an error sensor triggered for a first engine at a first point in time, a snapshot of model 110 of the first engine and model 111 of a second engine identified as being on the same airframe as the first engine is correlated with the model of the airframe and analyzed to determine if the same problem affecting the first engine is affecting or may affect the second engine. This analysis / prediction output is provided via interface circuitry 310 (e.g., via GUI 1000, alert indicators, instructions, logs, etc.).

[0085] At block 1140, the next action is triggered by the actionable output. The actionable output may include triggering of asset maintenance, adjustment of settings or parameters of an asset, warnings or alarms, alerts, shutdown or disabling of an asset, modeling of a problem in a second asset of the same type or a second asset connected to the asset in question, and the like. For example, when a second engine is identified as potentially affected by the same problem as the first engine, preventive maintenance of the second engine may be triggered. As another example, a problem diagnosed in one engine of a certain type under certain flight conditions and lifecycles may be extrapolated to other engines in the fleet, and a maintenance plan may be generated to adjust the corresponding engine before the problem may jeopardize operations.

[0086] Fig.12 A further example illustration of a query process 1200 of the memory circuit 330 by the processing circuit 320 in response to input via the interface circuit 310 is provided. At block 1202, a query received via the interface circuit 310 is parsed by the processing circuit 320. Parsing of the query may identify one or more terms, timings, conditions, constraints, etc., which may form the basis for a search of the memory circuit 330.

[0087] At block 1204, a search is performed based on the parsed query. For example, the processing circuit 320 interrogates the memory circuit 330 to identify one or more containers storing the digital twin models 101-132, associated snapshots, etc. At block 1206, a container is identified in the memory circuit 330. At block 1210, the search is processed to determine whether a relationship and / or attribute is involved in the search. When a relationship of an asset is involved in the search (e.g., a relationship of one engine model to other asset models, etc.), then at block 1212, the asset relationship container 430 is accessed to identify assets related to the asset identified in the search (e.g., another engine, an airframe, a controller, etc. associated with the engine identified in the search). When an attribute of an asset is involved in the search (e.g., temperature, speed, location, etc.), then at block 1214, the asset attribute container 420 is accessed to identify an attribute of the asset in question (e.g., cycle time, temperature reading, speed measurement, etc.). At block 1216, if another relationship and / or attribute is involved in the query, the process can be repeated.

[0088] At block 1218, the search is evaluated to determine if another vessel is identified using the correlated model 101-132, snapshot, etc. If so, control returns to block 1206. Otherwise, control proceeds to block 1220 where the results of the search are processed and correlated to determine an output / result. For example, in response to a query regarding an error sensor triggered for a first engine at a first point in time, a model 110 of the first engine and a snapshot of a model 111 of a second engine identified as being on the same airframe as the first engine are correlated with the model of the airframe and analyzed to determine if the same problem affecting the first engine is affecting or may affect the second engine.

[0089] At block 1222, the results of the query / search are returned via the interface circuit 310. For example, the corresponding engine, the likelihood of failure, the queue status, etc. can be displayed via the GUI 1000, warning indicators, instructions, logs, etc. At block 1224, an action is generated based on the results. For example, when a second engine is identified as potentially affected by the same problem as the first engine, the actionable output triggers preventive maintenance of the second engine. As another example, a problem diagnosed in one engine of a certain type under certain flight conditions and life cycle can be extrapolated to other engines in the queue, and the actionable output can generate a maintenance plan to adjust the corresponding engine before the problem can jeopardize operation.

[0090] Fig.13 is constructed to execute Fig.11 and / or Fig.12 1300 to implement the example snapshot management system 300, etc. The processor platform 1300 can be, for example, a server, a personal computer, a workstation, a self-learning machine (e.g., a neural network), a mobile device (e.g., a cellular phone, a smart phone, an iPad, etc.). TM tablet computer), personal digital assistant (PDA), Internet appliance, or any other type of computing device.

[0091] The processor platform 1300 of the illustrated example includes a processor 1312. The processor 1312 of the illustrated example is hardware. For example, the processor 1312 may be implemented by one or more integrated circuits, logic circuits, microprocessors, GPUs, DSPs, or controllers from any desired family or manufacturer. The hardware processor may be a semiconductor-based (e.g., silicon-based) device.

[0092] The processor 1312 of the illustrated example includes a local memory 1313 (e.g., cache and / or other memory circuits). The processor 1312 of the illustrated example communicates with a main memory / memory circuit including a volatile memory 1314 and a non-volatile memory 1316 via a bus 1318. The volatile memory 1314 may be comprised of synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), Dynamic Random Access Memory The non-volatile memory 1316 may be implemented by flash memory and / or any other desired type of memory device / memory circuit. Access to the main memory 1314, 1316 is controlled by a memory controller.

[0093] The processor platform 1300 of the illustrated example also includes an interface circuit 1320. The interface circuit 1320 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), interface, near field communication (NFC) interface, and / or PCI express interface.

[0094] In the example shown, one or more input devices 1322 are connected to the interface circuit 1320. The input devices 1322 allow a user to enter data and / or commands to the processor 1312. The input devices may be implemented by, for example, an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a track pad, a track ball, and / or a voice recognition system.

[0095] One or more output devices 1324 are also connected to the interface circuit 1320 of the illustrated example. The output device 1324 can be implemented, for example, by a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display (LCD), a cathode ray tube display (CRT), an in-place switching (IPS) display, a touch screen, etc.), a tactile output device, and / or a speaker. Therefore, the interface circuit 1320 of the illustrated example typically includes a graphics driver card, a graphics driver chip, and / or a graphics driver processor.

[0096] The interface circuitry 1320 of the illustrated example also includes a communication device, such as a transmitter, a receiver, a transceiver, a modem, a residential gateway, a wireless access point, and / or a network interface to facilitate the exchange of data with an external machine (e.g., any type of computing device) via a network 1326. Communications may be via, for example, an Ethernet connection, a digital subscriber line (DSL) connection, a telephone line connection, a coaxial cable system, a satellite system, a field line wireless system, a cellular system, etc.

[0097] The processor platform 1300 of the illustrated example also includes one or more mass storage devices 1328 for storing software and / or data. Examples of such mass storage devices 1328 include floppy disk drives, hard disk drives, optical disk drives, Blu-ray disk drives, redundant array of independent disks (RAID) systems, and digital versatile disk (DVD) drives.

[0098] Figure 11-12 The machine executable instructions 1332 may be stored in the mass storage device 1328, in the volatile memory 1314, in the non-volatile memory 1316, and / or on a removable, non-transitory computer-readable storage medium such as a CD or DVD.

[0099] Fig.14 yes Fig.13 1312 of the processor circuit 1312. In this example, Fig.13 The processor circuit 1312 is implemented by the microprocessor 1400. For example, the microprocessor 1400 may implement a multi-core hardware circuit, such as a CPU, a DSP, a GPU, an XPU, etc. Although it may include any number of example cores 1402 (e.g., 1 core), the microprocessor 1400 of this example is a multi-core semiconductor device including N cores. The cores 1402 of the microprocessor 1400 may operate independently or may cooperate to execute machine-readable instructions. For example, machine code corresponding to a firmware program, an embedded software program, or a software program may be executed by one of the cores 1402, or may be executed by multiple of the cores 1402 at the same or different times. In some examples, the machine code corresponding to the firmware program, the embedded software program, or the software program is split into threads and executed in parallel by two or more of the cores 1402. The software program may correspond to a thread executed by Figure 11-12 A flowchart may represent a portion or all of machine-readable instructions and / or operations.

[0100] The core 1402 can communicate via an example bus 1404. In some examples, the bus 1404 can implement a communication bus to enable communications associated with one or more of the cores 1402. For example, the bus 1404 can implement at least one of an inter-integrated circuit (I2C) bus, a serial peripheral interface (SPI) bus, a PCI bus, or a PCIe bus. Additionally or alternatively, the bus 1404 can implement any other type of computing or electrical bus. The core 1402 can obtain data, instructions, and / or signals from one or more external devices via an example interface circuit 1406. The core 1402 can output data, instructions, and / or signals to one or more external devices via the interface circuit 1406. Although the core 1402 of this example includes an example local memory 1420 (e.g., a level 1 (L1) cache that can be divided into an L1 data cache and an L1 instruction cache), the microprocessor 1400 also includes an example shared memory 1410 (e.g., a level 2 (L2_cache)) that can be shared by the cores for high-speed access to data and / or instructions. Data and / or instructions may be transferred (eg, shared) by writing to and / or reading from the shared memory 1410. The local memory 1420 of each of the cores 1402 and the shared memory 1410 may be a memory including multiple levels of cache memory and main memory (eg, Fig.13 The cache memory is part of a hierarchy of storage devices (main memory 1314, 1316). Generally, memory at higher levels in the hierarchy exhibits lower access times and has a smaller storage capacity than memory at lower levels. Changes in various levels of the cache hierarchy are managed (e.g., coordinated) by a cache coherence policy.

[0101] Each core 1402 may be referred to as a CPU, DSP, GPU, etc., or any other type of hardware circuit. Each core 1402 includes a control unit circuit 1414, an arithmetic and logic (AL) circuit (sometimes referred to as an ALU) 1416, a plurality of registers 1418, an L1 cache 1420, and an example bus 1422. Other structures may exist. For example, each core 1402 may include a vector unit circuit, a single instruction multiple data (SIMD) unit circuit, a load / store unit (LSU) circuit, a branch / jump unit circuit, a floating point unit (FPU) circuit, etc. The control unit circuit 1414 includes a semiconductor-based circuit configured to control (e.g., coordinate) data movement within the corresponding core 1402. The AL circuit 1416 includes a semiconductor-based circuit configured to perform one or more mathematical and / or logical operations on data within the corresponding core 1402. The AL circuit 1416 of some examples performs integer-based operations. In other examples, the AL circuit 1416 also performs floating-point operations. In other examples, AL circuit 1416 may include a first AL circuit that performs integer-based operations and a second AL circuit that performs floating-point operations. In some examples, AL circuit 1416 may be referred to as an arithmetic logic unit (ALU). Register 1418 is a semiconductor-based structure for storing data and / or instructions, such as the results of one or more operations performed by AL circuit 1416 of corresponding core 1402. For example, register 1418 may include vector registers, SIMD registers, general registers, flag registers, segment registers, machine-specific registers, instruction pointer registers, control registers, debug registers, memory management registers, machine check registers, etc. Fig.14 As shown, registers 1418 may be arranged in a memory bank. Alternatively, registers 1418 may be organized to include any other arrangement, format, or structure distributed throughout core 1402 to reduce access time. Bus 1422 may implement at least one of an I2C bus, an SPI bus, a PCI bus, or a PCIe bus.

[0102] Each core 1402 and / or more generally, the microprocessor 1400 may include additional and / or alternative structures to those structures shown and described above. For example, there may be one or more clock circuits, one or more power supplies, one or more power gates, one or more cache home agents (CHA), one or more fusion / common grid stops (CMS), one or more shifters (e.g., barrel shifters), and / or other circuits. The microprocessor 1400 is a semiconductor device manufactured to include many interconnected transistors so that the above structure is implemented in one or more integrated circuits (ICs) contained in one or more packages. The processor circuit may include one or more accelerators and / or collaborate with one or more accelerators. In some examples, the accelerator is implemented by a logic circuit to perform certain tasks faster and / or more efficiently than a general-purpose processor. Examples of accelerators include ASICs and FPGAs, such as those discussed herein. A GPU or other programmable device may also be an accelerator. The accelerator may be on a processor circuit, in the same chip package as the processor circuit, and / or in one or more packages separated from the processor circuit.

[0103] Fig.15 yes Fig.13 1312 is a block diagram of another example implementation of a processor circuit 1312. In this example, the processor circuit 1312 is implemented by an FPGA circuit 1500. For example, the FPGA circuit 1500 may be used to execute a program that may be executed by a corresponding machine-readable instruction. Fig.14 However, once configured, FPGA circuit 1500 instantiates machine-readable instructions in hardware and can therefore typically perform operations faster than they could be performed by a general-purpose microprocessor executing corresponding software.

[0104] More specifically, Fig.14 The microprocessor 1400 (which can be programmed to execute Figure 11-12 In contrast, a general purpose device may be a flowchart representation of some or all of the machine-readable instructions, but its interconnections and logic circuits are fixed once manufactured. Fig.15 The example FPGA circuit 1500 includes interconnects and logic circuits that can be configured and / or interconnected in different ways after fabrication to instantiate, for example, Figure 11-12In particular, FPGA circuit 1500 can be thought of as an array of logic gates, interconnects, and switches. The switches can be programmed to change how the logic gates are interconnected by the interconnects, effectively forming one or more dedicated logic circuits (unless and until FPGA circuit 1500 is reprogrammed). The configured logic circuits enable the logic gates to cooperate in different ways to perform different operations on the data received by the input circuits. These operations can correspond to the operations performed by Figure 11-12 Thus, FPGA circuit 1500 can be constructed to effectively Figure 11-12 Some or all of the machine-readable instructions of the flowchart of FIG. 1500 are instantiated as dedicated logic circuits to perform operations corresponding to those software instructions in a dedicated manner similar to an ASIC. Therefore, the FPGA circuit 1500 can perform operations corresponding to the software instructions more efficiently than a general-purpose microprocessor can. Figure 11-12 faster execution of some or all of the operations of the machine-readable instructions corresponding to Figure 11-12 Some or all of the operations in the machine-readable instructions.

[0105] exist Fig.15 In the example of FPGA 1500, FPGA circuit 1500 is configured to be programmed (and / or reprogrammed one or more times) by an end user via a hardware description language (HDL) such as Verilog. Fig.15 FPGA circuit 1500 includes example input / output (I / O) circuit 1502 to obtain data from example configuration circuit 1504 and / or external hardware (e.g., external hardware circuit) 1506 and / or output data from example configuration circuit 1504 and / or external hardware (e.g., external hardware circuit) 1506. For example, configuration circuit 1504 may implement interface circuits that can obtain machine-readable instructions to configure FPGA circuit 1500 or a portion thereof. In some such examples, configuration circuit 1504 may obtain machine-readable instructions from a user, a machine (e.g., a hardware circuit (e.g., a programmed or dedicated circuit) that can implement an artificial intelligence / machine learning (AI / ML) model to generate instructions), etc. In some examples, external hardware 1506 may implement Fig.14 FPGA circuit 1500 also includes an array of example logic gate circuits 1508, a plurality of example configurable interconnects 1510, and example storage circuits 1512. Logic gate circuits 1508 and interconnects 1510 may be configured to instantiate one or more operations that may correspond to Figure 11-12 At least some of the machine-readable instructions and / or other desired operations. Fig.15The logic gate circuits 1508 shown are manufactured in groups or blocks. Each block includes a semiconductor-based electrical structure that can be configured into a logic circuit. In some examples, the electrical structure includes a logic gate (e.g., an AND gate, an OR gate, a NOT gate, etc.) that provides a basic building block for the logic circuit. An electrically controllable switch (e.g., a transistor) is present in each of the logic gate circuits 1508 to enable the configuration of the electrical structure and / or the logic gate to form a circuit to perform the desired operation. The logic gate circuits 1508 may include other electrical structures, such as a lookup table (LUT), a register (e.g., a flip-flop or a latch), a multiplexer, etc.

[0106] The interconnect 1510 of the illustrated example is a conductive path, trace, via, etc., which may include an electrically controllable switch (e.g., a transistor) whose state can be changed by programming (e.g., using an HDL instruction language) to activate or deactivate one or more connections between one or more of the logic gate circuits 1508, thereby programming the desired logic circuit.

[0107] The storage circuit 1512 of the illustrated example is configured to store the results of one or more operations performed by the corresponding logic gates. The storage circuit 1512 may be implemented by registers, etc. In the illustrated example, the storage circuit 1512 is distributed in the logic gate circuit 1508 to facilitate access and increase execution speed.

[0108] Fig.15 The example FPGA circuit 1500 also includes an example dedicated operation circuit 1514. In this example, the dedicated operation circuit 1514 includes a dedicated circuit 1516, which can be called to implement commonly used functions, thereby avoiding the need to program those functions in the field. Examples of such dedicated circuits 1516 include memory (e.g., DRAM) controller circuits, PCIe controller circuits, clock circuits, transceiver circuits, memories, and multiplier-accumulator circuits. Other types of dedicated circuits may exist. In some examples, the FPGA circuit 1500 may also include an example general-purpose programmable circuit 1518, such as an example CPU 1520 and / or an example DSP 1522. Other general-purpose programmable circuits 1518 may exist additionally or alternatively, such as GPUs, XPUs, etc., which may be programmed to perform other operations.

[0109] although Fig.14 and Fig.15 Shows Fig.13 These are two example implementations of the processor circuit 1312, but many other approaches are contemplated. For example, as described above, modern FPGA circuits may include an on-board CPU, such as Fig.15 One or more of the example CPUs 1520. Thus, by combining Fig.14 An example microprocessor 1400 and Fig.15 The example FPGA circuit 1500 may additionally implement Fig.13 In some such hybrid examples, the processor circuit 1312 is Figure 11-12 The first portion of the machine-readable instructions represented by the flowchart may be represented by Fig.14 1402 and is executed by one or more of the cores 1402 and by Figure 11-12 The second portion of the machine-readable instructions represented by the flowchart may be represented by Fig.15 FPGA circuit 1500 executes.

[0110] In some examples, FPGA circuit 1500 is used for edge computing. In some examples, FPGA circuit 1500 is implemented in conjunction with snapshot management system 300 for improved timeliness and / or data fusion. TPM can also be incorporated to provide and enable hardware and / or software trust security roots for stronger computing / memory / CPU / GPU / etc. under second / sub-second time constraints.

[0111] In some examples, processing circuitry 320 implements means for processing, means for identifying, and means for determining. For example, memory circuitry 330 implements means for storing. For example, interface circuitry 310 and API 405 implement means for interfacing.

[0112] It should now be understood that the apparatus, systems, and methods described herein establish and maintain a network of digital twins that can be queried to correlate assets, issues, maintenance / preventive maintenance opportunities, replacements, reconfigurations, and the like. The apparatus, systems, and methods enable fleet management as well as asset management for individual aircraft and / or aircraft subsystems. Certain examples generate and correlate a series of snapshots of a digital twin model network and related states over time to drive the identification and resolution of problems based on relationships, attributes, and time. In this way, the presently described technology improves digital twin correlation and management. The presently described technology provides new digital twin / snapshot processing circuits, and the presently described technology improves the structure, organization, and management of memory circuits.

[0113] This document discloses example devices, systems, and methods for generating, managing, updating, and querying digital twins. Further examples and combinations thereof include the following:

[0114] Example 1 is a device comprising: an interface circuit, the interface circuit being used to receive an input for a query and provide a result of the query as an output; a memory circuit, the memory circuit being used to store multiple snapshots, each snapshot comprising multiple digital twin models interconnected by multiple connections, the multiple digital twin models comprising a first digital twin model of a first asset and a second digital twin model of a second asset, the multiple connections comprising a first connection between the first digital twin model and the second digital twin model, the first connection representing a relationship between the first digital twin model and the second digital twin model at a specified point in time, each snapshot representing a state of the digital twin model at the point in time, the memory circuit being arranged to enable identification and processing of one or more snapshots in response to the query; and a processing circuit, the processing circuit being used to process the query to search the memory circuit, the processing circuit being used to identify at least a first snapshot and a second snapshot in response to the query, the processing circuit being used to determine a correlation between the first snapshot and the second snapshot, and generating a result with an actionable output based on the correlation.

[0115] Example 2 includes an apparatus according to any preceding clause, wherein the first snapshot represents a plurality of interconnected digital twin models at a first point in time, and wherein the second snapshot represents the plurality of digital twin models at a second point in time.

[0116] Example 3 includes an apparatus as recited in any preceding clause, wherein the correlation comprises at least one of: i) changes from the first snapshot to the second snapshot over time, or ii) commonalities between the first snapshot and the second snapshot.

[0117] Example 4 includes the apparatus of any preceding clause, wherein the commonality comprises at least one of: related assets on the same airframe or similar assets on different airframes.

[0118] Example 5 includes an apparatus as described in any of the preceding clauses, wherein the change comprises at least one of: i) at least one of the first asset or the second asset moving from a first fuselage to a second fuselage, ii) a difference between a first configuration of the first asset and the second asset on the first fuselage and a second configuration of the first asset and the second asset on the first fuselage, or iii) a difference between the first configuration of the first asset and the second asset on the first fuselage and a third configuration of the first asset and the second asset on the second fuselage.

[0119] Example 6 includes an apparatus according to any of the preceding clauses, wherein the multiple digital twin models include at least one of an engine digital twin model, a landing gear digital twin model, a controller digital twin model, a fuselage digital twin model, or an aircraft digital twin model.

[0120] Example 7 includes an apparatus according to any of the preceding clauses, wherein the aircraft digital twin model includes the engine digital twin model, the landing gear digital twin model, the controller digital twin model, and the fuselage digital twin model.

[0121] Example 8 includes the apparatus of any preceding clause, wherein the aircraft digital twin is part of a fleet of aircraft digital twins.

[0122] Example 9 includes an apparatus as described in any preceding clause, wherein the memory circuit includes a plurality of containers that organize the plurality of digital twin models.

[0123] Example 10 includes an apparatus according to any of the preceding clauses, wherein the actionable output includes at least one of: i) triggering maintenance of at least one of the first asset or the second asset, ii) monitoring at least one of the first asset or the second asset, or iii) reconfiguring at least one of the first asset or the second asset.

[0124] Example 11 includes an apparatus according to any preceding clause, wherein the processing circuit processes the change event to: ingest the change event, store a third snapshot of multiple interconnected digital twin models based on the change event, and facilitate queries based on the change event.

[0125] Example 12 includes an apparatus according to any preceding clause, wherein the processing circuit includes an application program interface for facilitating the ingestion of change events, the storage of snapshots, and the querying of the memory circuit.

[0126] Example 13 is a non-transitory computer-readable storage medium comprising instructions that, when executed, cause a processor to at least: process a query to search for multiple snapshots, each snapshot comprising multiple digital twin models interconnected by multiple connections, the multiple digital twin models comprising a first digital twin model of a first asset and a second digital twin model of a second asset, the multiple connections comprising a first connection between the first digital twin model and the second digital twin model, the first connection representing a relationship between the first digital twin model and the second digital twin model at a specified point in time, each snapshot representing a state of the digital twin model at the point in time; identifying at least a first snapshot and a second snapshot in response to the query; determining a correlation between the first snapshot and the second snapshot; and generating a result with an actionable output based on the correlation.

[0127] Example 14 includes a non-transitory computer-readable storage medium according to any of the preceding clauses, wherein the first snapshot represents a plurality of interconnected digital twin models at a first point in time, and wherein the second snapshot represents the plurality of digital twin models at a second point in time, and wherein the instructions, when executed, cause the processor to correlate the first snapshot with the second snapshot by comparing the first snapshot and the second snapshot to determine at least one of: i) changes from the first snapshot to the second snapshot over time, or ii) commonalities between the first snapshot and the second snapshot.

[0128] Example 15 includes the non-transitory computer-readable storage medium of any preceding clause, wherein the instructions, when executed, cause the processor to search a plurality of containers including an asset property container, an asset relationship container, and a lookup container to identify the first snapshot and the second snapshot.

[0129] Example 16 includes a non-transitory computer-readable storage medium as described in any of the preceding clauses, wherein the actionable output includes at least one of: i) triggering maintenance of at least one of the first asset or the second asset, ii) monitoring at least one of the first asset or the second asset, or iii) reconfiguring at least one of the first asset or the second asset.

[0130] Example 17 includes a non-transitory computer-readable storage medium according to any of the preceding clauses, wherein the instructions, when executed, cause the processor to process a change event to perform at least one of: ingesting the change event, storing a snapshot of a first digital twin model among the multiple digital twin models based on the change event, or facilitating a query based on the change event.

[0131] Example 18 is a method comprising: processing a query by using a processor to execute instructions to search for multiple snapshots, each snapshot comprising multiple digital twin models interconnected by multiple connections, the multiple digital twin models comprising a first digital twin model of a first asset and a second digital twin model of a second asset, the multiple connections comprising a first connection between the first digital twin model and the second digital twin model, the first connection representing a relationship between the first digital twin model and the second digital twin model at a specified point in time, each snapshot representing a state of the digital twin model at the point in time; identifying at least a first snapshot and a second snapshot in response to the query by using the processor to execute instructions; determining a correlation between the first snapshot and the second snapshot by using the processor to execute instructions; and generating a result with an actionable output based on the correlation by using the processor to execute instructions.

[0132] Example 19 includes a method according to any of the preceding clauses, wherein the first snapshot represents a plurality of interconnected digital twin models at a first point in time, and wherein the second snapshot represents the plurality of digital twin models at a second point in time, and wherein the method includes correlating the first snapshot with the second snapshot by comparing the first snapshot with the second snapshot to determine at least one of: i) changes from the first snapshot to the second snapshot over time, or ii) commonalities between the first snapshot and the second snapshot.

[0133] Example 20 includes a method according to any of the preceding clauses, wherein processing the query includes processing the change event to perform at least one of: ingesting the change event, storing a snapshot of a first digital twin model among the multiple digital twin models based on the change event, or facilitating the query based on the change event.

[0134] Example 21 is a system comprising: a device for processing a query to search multiple interconnected digital twin models, the digital twin models being associated with snapshots representing the states of the corresponding digital twin models at a point in time; a device for identifying at least a first snapshot and a second snapshot in response to the query; a device for determining a correlation between the first snapshot and the second snapshot; and a device for generating a result having an actionable output.

[0135] Example 22 includes a system according to any of the preceding clauses, wherein the first snapshot represents a plurality of interconnected digital twin models at a first point in time, and wherein the second snapshot represents the plurality of digital twin models at a second point in time, and wherein the method includes correlating the first snapshot with the second snapshot by comparing the first snapshot and the second snapshot to determine at least one of: i) changes from the first snapshot to the second snapshot over time, or ii) commonalities between the first snapshot and the second snapshot.

[0136] Example 23 includes a system according to any of the preceding clauses, wherein the means for processing queries includes means for processing change events to perform at least one of: ingesting change events, storing a snapshot of a first digital twin model among the plurality of digital twin models based on the change event, or facilitating queries based on the change event.

[0137] Example 24 includes the system of any preceding clause, wherein the commonality comprises at least one of: related assets on the same airframe or similar assets on different airframes.

[0138] Example 25 includes a system according to any of the preceding clauses, wherein the change comprises at least one of: i) at least one of the first asset or the second asset moving from a first fuselage to a second fuselage, ii) a difference between a first configuration of the first asset and the second asset on the first fuselage and a second configuration of the first asset and the second asset on the first fuselage, or iii) a difference between the first configuration of the first asset and the second asset on the first fuselage and a third configuration of the first asset and the second asset on the second fuselage.

[0139] Example 26 includes a system according to any of the preceding clauses, wherein the plurality of digital twin models includes at least one of an engine digital twin model, a landing gear digital twin model, a controller digital twin model, a fuselage digital twin model, or an aircraft digital twin model.

[0140] Example 27 includes a system according to any of the preceding clauses, wherein the aircraft digital twin model includes the engine digital twin model, the landing gear digital twin model, the controller digital twin model, and the fuselage digital twin model.

[0141] Example 28 includes the system of any preceding clause, wherein the aircraft digital twin is part of a fleet of aircraft digital twins.

[0142] Example 29 includes a system as described in any preceding clause, wherein the means for storing includes a plurality of containers organizing the plurality of digital twin models.

[0143] Example 30 includes a system according to any of the preceding clauses, wherein the actionable output includes at least one of: i) triggering maintenance of at least one of the first asset or the second asset, ii) monitoring at least one of the first asset or the second asset, or iii) reconfiguring at least one of the first asset or the second asset.

[0144] Example 31 includes a system according to any preceding clause, wherein the processing circuit includes means for interfacing to facilitate ingesting change events, storing snapshots, and querying the means for storing.

[0145] Example 32 includes an apparatus, method, or system according to any of the preceding clauses, wherein the interconnected multiple digital twin models are a first interconnected multiple digital twin models, wherein the first snapshot represents the first interconnected multiple digital twin models at a first point in time, and wherein the second snapshot represents a second multiple digital twin models at the first point in time.

[0146] Although specific examples have been shown and described herein, it should be understood that various other changes and modifications may be made without departing from the spirit and scope of the claimed subject matter. In addition, although various aspects of the claimed subject matter have been described herein, these aspects do not need to be used in combination. Therefore, the appended claims are intended to cover all such changes and modifications that fall within the scope of the claimed subject matter.

[0147] The following claims are incorporated by reference into this detailed description. Although certain example systems, methods, devices, and articles have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all systems, methods, devices, and articles that fully fall within the scope of the claims of this patent.

Claims

1. A device, characterized in that: include: an interface circuit for receiving an input for a query and providing a result of the query as an output; a memory circuit for storing a plurality of snapshots, each snapshot comprising a plurality of digital twin models interconnected by a plurality of connections, the plurality of digital twin models comprising a first digital twin model of a first asset and a second digital twin model of a second asset, the plurality of connections comprising a first connection between the first digital twin model and the second digital twin model, the first connection representing a relationship between the first digital twin model and the second digital twin model at a specified point in time, each snapshot representing a state of the digital twin model at the specified point in time, the memory circuit being arranged to enable identification and processing of one or more snapshots in response to the query; and processing circuitry for processing the query to search the memory circuitry, the processing circuitry for identifying at least a first snapshot and a second snapshot in response to the query, the processing circuitry for determining a correlation between the first snapshot and the second snapshot, and generating the result with an actionable output based on the correlation.

2. The device according to claim 1, characterized in that Wherein the first snapshot represents the multiple digital twin models at a first point in time, and wherein the second snapshot represents the multiple digital twin models at a second point in time.

3. The device according to claim 1, characterized in that The correlation comprises at least one of: i) changes from the first snapshot to the second snapshot over time, or ii) commonalities between the first snapshot and the second snapshot.

4. The device according to claim 3, characterized in that The commonality includes at least one of the following: related assets on the same airframe or similar assets on different airframes.

5. The device according to claim 3, characterized in that wherein the change comprises at least one of: i) at least one of the first asset or the second asset moving from a first fuselage to a second fuselage, ii) a difference between a first configuration of the first asset and the second asset on the first fuselage and a second configuration of the first asset and the second asset on the first fuselage, or iii) a difference between the first configuration of the first asset and the second asset on the first fuselage and a third configuration of the first asset and the second asset on the second fuselage.

6. The device according to claim 1, characterized in that The multiple digital twin models include at least one of an engine digital twin model, a landing gear digital twin model, a controller digital twin model, a fuselage digital twin model or an aircraft digital twin model.

7. The device according to claim 6, characterized in that The aircraft digital twin model includes the engine digital twin model, the landing gear digital twin model, the controller digital twin model and the fuselage digital twin model.

8. The device according to claim 7, characterized in that The aircraft digital twin model is part of a fleet of aircraft digital twin models.

9. The device according to claim 1, characterized in that The memory circuit includes multiple containers for organizing the multiple digital twin models.

10. The device according to claim 9, characterized in that Wherein the actionable output comprises at least one of: i) triggering maintenance of at least one of the first asset or the second asset, ii) monitoring at least one of the first asset or the second asset, or iii) reconfiguring at least one of the first asset or the second asset.

Images