WO2019103775A1 - Method and apparatus for automated suggestion of additional sensors or inputs from equipment or systems - Google Patents

Abstract

A computer-implemented method for recommending sensors for uses in a system design includes receiving a knowledge graph describing a design of a system of a particular type, and identifying a set of required data items typically needed to model systems of the particular type. The knowledge graph is analyzed to identify one or more missing data items included in the set of required data items but not in the design of the system. For each missing data item, a physical device generating the missing data item identified and a recommendation is generated for placement of a sensor at a corresponding output of the physical device. Each recommendation is then presented to a user.

Description

METHOD AND APPARATUS FOR AUTOMATED SUGGESTION OF ADDITIONAL SENSORS

OR INPUTS FROM EQUIPMENT OR SYSTEMS

CROSS-REFERENCE TO RELATED APPLICATIONS

[1] This application claims the benefit of ELS. Provisional Application Serial No. 62/590,678 filed November 27, 2017, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

[2] The present disclosure generally relates to systems, methods, and apparatuses for the automated suggestion of additional sensor(s) on or inputs from equipment or systems. The techniques described herein may be applied, for example, to integrate sensor recommendations into generative design tools.

BACKGROUND

[3] Determining the need for and placement of additional sensors and their feedback for integrated design and analysis is an important problem for modern knowledge graph systems, integrated design and analysis tools, and rapid experimental design. As can be seen from such recent publications as“Embedded sensors and feedback loops for iterative improvement in design synthesis for additive manufacturing”, IDETC/CIE 2016 Conference proceedings: ASME International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, the state of the art in sensor placement suggestion is ad hoc, as determined manually on a case-by-case basis by human experts. Such techniques fail and are generally time-intensive and, thus, there is a desire to leverage knowledge existing system designs in a manner that allows for the automated suggestion of sensors.

SUMMARY

[4] Embodiments of the present invention address and overcome one or more of the above shortcomings and drawbacks, by providing methods, systems, and apparatuses related to a the automated suggestion of additional sensor(s) on or inputs from equipment or systems.

[5] According to some embodiments, a computer-implemented method for recommending sensors for uses in a system design includes receiving a knowledge graph describing a design of a system of a particular type, and identifying a set of required data items typically needed to model systems of the particular type. The knowledge graph is analyzed to identify one or more missing data items included in the set of required data items but not in the design of the system. For each missing data item, a physical device generating the missing data item identified and a recommendation is generated for placement of a sensor at a corresponding output of the physical device. Each recommendation is then presented to a user. In some embodiments, each recommendation is presented to the user on a graphical depiction of the knowledge graph at a location associated with the corresponding output of the physical device.

[6] In some embodiments of the aforementioned method, in response to presenting the recommendation for placement of the sensor, the computing system performing the method receives a user request to add the sensor to the system. In response to the user request, a new node is added in the knowledge graph corresponding to the sensor. Additionally, the new node is linked to the corresponding physical device generating the missing data item.

[7] In some embodiments of the aforementioned method, the knowledge graph is a digital twin graph comprising a plurality of subgraphs, and each sub-graph comprises a plurality of nodes associated with a distinct physical device. In one embodiment, the digital twin graph is analyzed to identify one or more missing data items by identifying a possible device generating each required data item, and a particular sub-graph corresponding to the possible device. This particular sub-graph is traversed to determine whether the required data item is represented in the sub-graph. If the required data item is not represented in the sub-graph, the required data item is designated as one of the missing data items.

[8] In some embodiments of the aforementioned method, the knowledge graph is defined with respect to a knowledge graph template and the set of data items are identified based on the knowledge graph template. In these embodiments, the missing data items may be identified by traversing each node in the knowledge graph. As each node is processed during the traversal, if the node corresponds to a data item included in the set of required data items, a record is create indicating that the required data item is present in the knowledge graph. At the end of the traversal, any of the required data items not recorded as being present are designated as the missing data items. In one embodiment, the required data items are defined with respect to a plurality of input parameters associated required to execute the model of the system of the particular type.

[9] In some embodiments of the aforementioned method, existing knowledge graphs are analyzed to determine the set of data items typically needed to model systems of the particular type. In these embodiments, the missing data items may be identified by traversing each node in the knowledge graph. As each node is processed during the traversal, if the node corresponds to a required data item, a record is created that the required data item is present in the knowledge graph. At the end of the traversal, any of the required data items not recorded as being present are designated as the missing data items. In one embodiment, the required data items are defined with respect to a plurality of input parameters associated required to execute the model of the system of the particular type.

[10] According to another aspect of the present invention, a computer system comprises one or more processors and a non-volatile memory. The non-volatile memory stores instructions that, when executed by the processors, cause the processors to perform the aforementioned method, with or without the various additional features described above.

[11] Similarly, according to another aspect of the present invention, an article of manufacture for recommending sensors for use in a system design includes a non-transitory, tangible computer-readable medium holding computer-executable instructions for performing the aforementioned method, with or without the various additional features described above.

[12] Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[13] The foregoing and other aspects of the present invention are best understood from the following detailed description when read in connection with the accompanying drawings. For the purpose of illustrating the invention, there is shown in the drawings embodiments that are presently preferred, it being understood, however, that the invention is not limited to the specific instrumentalities disclosed. Included in the drawings are the following Figures: [14] FIG. 1 shows a system for autonomous generative design using a knowledge graph (KG), according to some embodiments;

[15] FIG. 2 shows a method for recommending sensors for uses in a system design, according to some embodiments;

[16] FIG. 3 shows a method where a DTG is analyzed; and

[17] FIG. 4 provides an example of a parallel processing memory architecture that may be utilized to perform computations related to execution of the various workflows discussed herein, according to some embodiments of the present invention.

DETAILED DESCRIPTION

[18] The following disclosure describes the present invention according to several embodiments directed at methods, systems, and apparatuses related to automated suggestion of additional sensor(s) on or inputs from equipment or systems. As described in further detail below, a knowledge graph is leveraged to understand what information is available about a system and what information is typically needed for systems which are of the same type (e.g., based on automatic labeling of the system or on a priori information). This allows automatic suggestion of additional sensors to provide any “missing” information. The automatic suggestion of additional sensors to provide the missing information ensures that the complete information needed for analysis of the system is available, even in the case that the original designer doesn’t know what information is necessary for that analysis.

[19] FIG. 1 shows a system 100 for autonomous generative design using a knowledge graph, according to some embodiments. The term knowledge graph, as used herein, refers to a graph structure that stores knowledge about a system design in a graph-based structure. Although several types of knowledge graphs may be used with the techniques described herein; the example of FIG. 1 assumes that a digital twin graph (DTG) is employed.

[20] As is generally understood in the art, a digital twin (DT) is a digital version of a machine. Once created, the DT can be used to represent the machine in a digital representation of a real world system. The DT is created such that it is identical in form and behavior of the corresponding machine. Additionally, the DT may mirror the status of the machine within a greater system. For example, sensors may be placed on the machine to capture real-time (or near real-time) data from the physical object to relay it back to a remote DT. The DT can then make any changes necessary to maintain its correspondence to the physical twin. The DTG is a graph structure where nodes correspond to DTs and edges correspond to data flowing between DTs. Even though the DTG may comprise a large graph with billions of nodes and edges, existing databases (e.g., GraphX, Linked Data) and algorithms (e.g., Pregel, MapReduce) running in parallel processing platforms (see FIG. 4) may be used to efficiently search and update the DTG. Alternatively, a specialized database that uses graph structures for semantic queries (i.e., a “graph database”) may be used in some embodiments.

[21] Continuing with reference to FIG. 1, a user 120 interacts with a design computer system 130 to design a system based on the DTG 105. A digital twin graph editor 115 provides a graphical user interface (GUI) to the user 120 that allows the user 120 to select a DTG template from a DTG template database 113. The DTG template provides a starting point for creating a new design of a system. The template may include, for example, a list of DTs typically used to define a system of a given type and default parameters for those DTS. The templates may be generated, for example, using design documents 110. A requirements distiller 135 receives the design documents 110 and digitizes the design documents 110 and extracts the useful information from the design documents 110, allowing the useful information to be integrated into the DTG 105. Details on implementation of the requirements distiller 135 are described in PCT/US2018/024490 entitled“System for Automated Generative Design Synthesis using Data from Design Tools and Knowledge from a Digital Twin” filed on March 27, 2018, the entirety of which is incorporated herein by reference.

[22] Once the DTG 105 has been generated, the user 120 can use a sensor recommendations generator 125 to generate recommendations on how the DTG 105 can be augmented with sensors to make the DTG 105 more compatible with modeling tools. The process of making recommendations is described in further detail below. Briefly, by analyzing the input parameters of a modeling tool, the sensor recommendations generator 125 can determine a set of data items that are required for modeling. In order to extract these data items from the system, a sensor may be placed at the output of the physical device generating the data item. For example, a measurement of outflow of a gas turbine would be acquired using a sensor at the exhaust. The sensor recommendations generator 125 analyzes the DTG 105 to determine if all the required sensors exist in the system design. If any sensors are missing, the sensor recommendations generator 125 recommends that the user 120 place the sensor(s) at the appropriate location(s).

[23] In some embodiments, graph database (GDB) which stores each sub-graph corresponding to a physical machine, structure, or other entity represented in the DTG 105. As is commonly understood in the art, a graph database is a database management system which performs Create, Read, Update and Delete (CRUD) operations on a graph data model. Examples of graph databases that may be utilized include, without limitation, Neo4j, HyperGraphDB, DEX, InfoGrid, Sones, and VertexDB. The GDB of each DTG 105 are further linked such that they collectively amount to the DTG of the entire system. As an alternative to having multiple GDBs, in some embodiments, a single GDB is used and the designation of each sub-graph (i.e., each DT) may be explicitly stored along with information describing the various nodes and edges comprising the DTG. In other embodiments, a SQL or no-SQL database that is not graph-based may be used and custom routines (e.g., implemented in MapReduce in the Data and Simulation Layer 510) may be used to support graph traversal operations. To support portability and human readability of DT information, the subnetwork of each DT may be stored using a graph-based file format such as GXL (Graph exchange Language) or GraphML.

[24] FIG. 2 shows a method 200 for recommending sensors for uses in a system design, according to some embodiments. This method 200 may be implemented generally using any computing system known in the art. For large, complex KGs, a parallel processing system such as described in FIG. 4 may be employed. Starting at step 205 in FIG. 2, the computing system receives KG that describes the design of a system of a particular type. The“type” in this case refers to the product being designed. For example, when designing a new turbine system, the type would be a turbine. Although the KG can be defined from scratch by a user, typically the user will begin design of the KG using one or more templates. In this context a“template” refers to a pre-designed KG that users can use as a starting point for a system design. The template provides the general structure of particular types of systems (e.g., gas turbine) and the user customizes the template by providing implementation details (e.g., size of the intake, compressor characteristics, type of sensors used, etc.). In these embodiments, the information received at step 205 would include the KG itself as well as an indication of the template used to define the KG.

[25] At step 210, the type of the system design is used to identify a set of required data items. These required data items correspond to information typically needed to model systems of the type. In some embodiments, the required data items are defined with respect to a plurality of input parameters required to execute a software or hardware model of the system of the particular type. For example, a model of a gas turbine may require a measurement of the intake flow as a parameter. In this case, an intake flow measurement would be a required data item. The model parameters may be pre-defined based on the type of system being designed. For example, in one embodiment, the KG template is designed such that it expects that the KG will have certain nodes/edges corresponding to model parameters. Alternatively, in some embodiments, the parameters can be determined dynamically at run-time. For example, in one embodiment, the user may define a KG and then select a particular model through a GUI. After the model is selected, its parameters are determined and used to define the required data items at step 210. It should be noted that the method 200 is not necessarily dependent on the use of a model. For example, in some embodiments, an organization may define a set of required data items that must be present in all designs. In other embodiments, machine learning can be used to analyze a library of KGs to learn which types of data items are present in KGs of the type being designed with the method 200.

[26] The KG is analyzed at step 215 to identify one or more missing data items included in the set of required data items but not in the design of the system. For example, the KG can be analyzed on a node-by-node basis, and a record can be created if the node corresponds to a data item included in the set of required data items. Conceptually, this process can be understood as checking items off a list. The“record” in this context would be the equivalent of checking an item off the list to indicate that it was seen in the KG. At the end of the traversal, any of the required data items not recorded as being present as the missing data items are designed as missing. [27] To illustrate one method of analyzing a KG and/or to identify one or more missing data items, FIG. 3 shows a method 300 where a DTG is analyzed. This method is employed for each required data item (see step 210 in FIG. 2). The method 300 starts at step 305 with the computer system identifying a possible device generating the required data item. In many cases, the device will be apparent from the characteristics of the required data item. For example, if the required data item is an outlet flow measurement in a gas turbine system, the physical device will be the turbine exhaust system. Conversely, for a fuel flow measurement, the physical device may be a fuel line connected to the combustor.

[28] Continuing with reference to FIG. 3, the sub-graph within the DTG corresponding to the possible device is identified at step 310. In some embodiments, a data file or other listing may be provided that indicates which sub-graphs are present in the DTG and where each DTG is located. In other embodiments, the DTG permits traversal at the sub-graph level to quickly view the various sub-graphs (and, by extension, digital twins) present in the graph. Once the sub graph corresponding to the possible device is identified, it is traversed at step 315 to determine whether the required data item is represented in the sub-graph. To continue with the previous example, if a sub-graph corresponding to the turbine exhaust system is traversed, the various edges and connecting nodes in the DTG will be evaluated to determine whether outlet flow is measured. If the required data item is not represented in the sub-graph, the required data item is designated at step 320 as one of the missing data items.

[29] Returning to FIG. 2, at steps 220 - 225, a recommendation is generated for each missing data item. More specifically, physical device generating the missing data item is identified at step 220; then, a recommendation is generated at step 225 for placement of a sensor at a corresponding output of the physical device.

[30] Each recommendation is presented to a user at step 230. Various techniques may be used for presenting the recommendation. In some embodiments, each recommendation is presented to the user on a graphical depiction of the KG at a location associated with the corresponding output of the physical device. For example, in one embodiment, the KG is shown in a GUI as a set of nodes, with each node corresponding to a physical device and edges between the device indicating data flows. In this case, the recommendation may be presented as new node on the KG. The node may be highlighted using a particular color, font, etc., to indicate that it’s a recommendation and not yet part of the KG. For example, in some embodiments, the recommended node may be highlighted in red and flash to draw the user’s attention. As an alternative to a visualization, the recommendations may be provided using a textual list that describes the details of where each recommended sensor should be placed.

[31] Continuing with reference to FIG. 2, in response to presenting the recommendation for placement of the sensor, the computer system receives a user request to add the sensor to the system at step 235. For example, where the recommended sensor location is presented on the KG, the user may click on the graphical representation of the recommendation to accept the recommendation. Alternatively, in other embodiments, clicking on the recommended sensor location may bring up a list of options for the user (e.g., add recommended sensor, ignore recommendation, adjust location, etc.).

[32] In response to the user request received at step 235, a new node in the KG corresponding to the sensor is added to the KG at step 240. Then, at step 245, the new node is linked to the corresponding physical device generating the missing data item.

[33] FIG. 4 provides an example of a parallel processing memory architecture 400 that may be utilized to perform computations related to execution of the various workflows discussed herein, according to some embodiments of the present invention. This architecture 400 may be used in embodiments of the present invention where NVIDIA™ CUDA (or a similar parallel computing platform) is used. The architecture includes a host computing unit (“host”) 405 and a graphics processing unit (GPU) device (“device”) 410 connected via a bus 415 (e.g., a PCIe bus). The host 405 includes the central processing unit, or“CPU” (not shown in FIG. 4), and host memory 425 accessible to the CPU. The device 410 includes the graphics processing unit (GPU) and its associated memory 420, referred to herein as device memory. The device memory 420 may include various types of memory, each optimized for different memory usages. For example, in some embodiments, the device memory includes global memory, constant memory, and texture memory.

[34] Parallel portions of a big data platform and/or big simulation platform (see FIG. 5) may be executed on the architecture 400 as“device kernels” or simply“kernels.” A kernel comprises parameterized code configured to perform a particular function. The parallel computing platform is configured to execute these kernels in an optimal manner across the architecture 400 based on parameters, settings, and other selections provided by the user. Additionally, in some embodiments, the parallel computing platform may include additional functionality to allow for automatic processing of kernels in an optimal manner with minimal input provided by the user.

[35] The processing required for each kernel is performed by grid of thread blocks (described in greater detail below). Using concurrent kernel execution, streams, and synchronization with lightweight events, the architecture 400 of FIG. 4 (or similar architectures) may be used to parallelize modification or analysis of the digital twin graph. For example, in some embodiments, the operations of the big data platform may be partitioned such that multiple kernels analyze different sub-graphs or relationships between DTUs simultaneously.

[36] The device 410 includes one or more thread blocks 430 which represent the computation unit of the device 410. The term thread block refers to a group of threads that can cooperate via shared memory and synchronize their execution to coordinate memory accesses. For example, in FIG. 4, threads 440, 445 and 450 operate in thread block 430 and access shared memory 435. Depending on the parallel computing platform used, thread blocks may be organized in a grid structure. A computation or series of computations may then be mapped onto this grid. For example, in embodiments utilizing CUD A, computations may be mapped on one-, two-, or three-dimensional grids. Each grid contains multiple thread blocks, and each thread block contains multiple threads. For example, in FIG. 4, the thread blocks 430 are organized in a two dimensional grid structure with m+ 1 rows and n+ 1 columns. Generally, threads in different thread blocks of the same grid cannot communicate or synchronize with each other. However, thread blocks in the same grid can run on the same multiprocessor within the GPU at the same time. The number of threads in each thread block may be limited by hardware or software constraints.

[37] Continuing with reference to FIG. 4, registers 455, 460, and 465 represent the fast memory available to thread block 430. Each register is only accessible by a single thread. Thus, for example, register 455 may only be accessed by thread 440. Conversely, shared memory is allocated per thread block, so all threads in the block have access to the same shared memory. Thus, shared memory 435 is designed to be accessed, in parallel, by each thread 440, 445, and 450 in thread block 430. Threads can access data in shared memory 435 loaded from device memory 420 by other threads within the same thread block (e.g., thread block 430). The device memory 420 is accessed by all blocks of the grid and may be implemented using, for example, Dynamic Random- Access Memory (DRAM).

[38] Each thread can have one or more levels of memory access. For example, in the architecture 400 of FIG. 4, each thread may have three levels of memory access. First, each thread 440, 445, 450, can read and write to its corresponding registers 455, 460, and 465. Registers provide the fastest memory access to threads because there are no synchronization issues and the register is generally located close to a multiprocessor executing the thread. Second, each thread 440, 445, 450 in thread block 430, may read and write data to the shared memory 435 corresponding to that block 430. Generally, the time required for a thread to access shared memory exceeds that of register access due to the need to synchronize access among all the threads in the thread block. However, like the registers in the thread block, the shared memory is typically located close to the multiprocessor executing the threads. The third level of memory access allows all threads on the device 410 to read and/or write to the device memory. Device memory requires the longest time to access because access must be synchronized across the thread blocks operating on the device. Thus, in some embodiments, the processing of each sub-graph is coded such that it primarily utilizes registers and shared memory and only utilizes device memory as necessary to move data in and out of a thread block.

[39] The embodiments of the present disclosure may be implemented with any combination of hardware and software. For example, aside from parallel processing architecture presented in FIG. 4, standard computing platforms (e.g., servers, desktop computer, etc.) may be specially configured to perform the techniques discussed herein. In addition, the embodiments of the present disclosure may be included in an article of manufacture (e.g., one or more computer program products) having, for example, computer-readable, non-transitory media. The media may have embodied therein computer readable program code for providing and facilitating the mechanisms of the embodiments of the present disclosure. The article of manufacture can be included as part of a computer system or sold separately. [40] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

[41] An executable application, as used herein, comprises code or machine readable instructions for conditioning the processor to implement predetermined functions, such as those of an operating system, a context data acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters.

[42] A graphical user interface (GUI), as used herein, comprises one or more display images, generated by a display processor and enabling user interaction with a processor or other device and associated data acquisition and processing functions. The GUI also includes an executable procedure or executable application. The executable procedure or executable application conditions the display processor to generate signals representing the GUI display images. These signals are supplied to a display device which displays the image for viewing by the user. The processor, under control of an executable procedure or executable application, manipulates the GUI display images in response to signals received from the input devices. In this way, the user may interact with the display image using the input devices, enabling user interaction with the processor or other device.

[43] The functions and process steps herein may be performed automatically or wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to one or more executable instructions or device operation without user direct initiation of the activity.

[44] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the invention to accomplish the same objectives. Although this invention has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the invention. As described herein, the various systems, subsystems, agents, managers and processes can be implemented using hardware components, software components, and/or combinations thereof. No claim element herein is to be construed under the provisions of 35 U.S.C. 112(f), unless the element is expressly recited using the phrase“means for.”

Claims

CLAIMS We claim:

1. A computer- implemented method for recommending sensors for uses in a system design, the method comprising:

receiving a knowledge graph describing a design of a system of a particular type;

identifying a set of required data items typically needed to model systems of the particular type;

analyzing the knowledge graph to identify one or more missing data items included in the set of required data items but not in the design of the system;

for each missing data item, (a) identifying a physical device generating the missing data item and (b) generating a recommendation for placement of a sensor at a corresponding output of the physical device; and

presenting each recommendation to a user.

2. The method of claim 1, further comprising:

in response to presenting the recommendation for placement of the sensor, receiving a user request to add the sensor to the system;

in response to the user request, (a) adding a new node in the knowledge graph

corresponding to the sensor, and (b) linking the new node to the corresponding physical device generating the missing data item.

3. The method of claim 1, wherein the knowledge graph is a digital twin graph comprising a plurality of subgraphs, and each sub-graph comprises a plurality of nodes associated with a distinct physical device.

4. The method of claim 3, wherein the digital twin graph is analyzed to identify one or more missing data items by:

for each required data item,

identifying a possible device generating the required data item;

identifying a particular sub-graph corresponding to the possible device; traversing the particular sub-graph to determine whether the required data item is represented in the sub-graph; and

if the required data item is not represented in the sub-graph, designating the required data item as one of the missing data items.

5. The method of claim 1, wherein the knowledge graph is defined with respect to a knowledge graph template and the set of data items are identified based on the knowledge graph template.

6. The method of claim 5, wherein the one or more missing data items are identified by: traversing each node in the knowledge graph;

as each node is processed during the traversal, if the node corresponds to a data item included in the set of required data items, creating a record that the required data item is present in the knowledge graph; and

at the end of the traversal, designating any of the required data items not recorded as being present as the missing data items.

7. The method of claim 6, wherein the required data items are defined with respect to a plurality of input parameters associated required to execute the model of the system of the particular type.

8. The method of claim 1, further comprising:

analyzing a plurality of existing knowledge graphs to determine the set of data items typically needed to model systems of the particular type.

9. The method of claim 8, wherein the one or more missing data items are identified by: traversing each node in the knowledge graph;

as each node is processed during the traversal, if the node corresponds to a required data item, creating a record that the required data item is present in the knowledge graph; and

at the end of the traversal, designating any of the required data items not recorded as being present as the missing data items.

10. The method of claim 9, wherein the required data items as defined with respect to a plurality of input parameters associated required to execute the model of the system of the particular type.

11. The method of claim 1, wherein each recommendation is presented to the user on a graphical depiction of the knowledge graph at a location associated with the corresponding output of the physical device.

12. The method of claim 1, further comprising:

receiving a user selection of the recommendation on the graphical depiction of the knowledge graph; and

in response to the user selection, adding the sensor associated with the recommendation to the knowledge graph.

13. A computer system comprising one or more processors and a non-volatile memory, wherein the non-volatile memory stores instructions that, when executed by the one or more processors, cause the one or more processors to perform a method comprising:

receiving a knowledge graph describing a design of a system of a particular type;

identifying a set of required data items typically needed to model systems of the particular type;

analyzing the knowledge graph to identify one or more missing data items included in the set of required data items but not in the design of the system;

for each missing data item, (a) identifying a physical device generating the missing data item and (b) generating a recommendation for placement of a sensor at a corresponding output of the physical device; and

presenting each recommendation to a user.

14. The system of claim 13, wherein the method further comprises

in response to presenting the recommendation for placement of the sensor, receiving a user request to add the sensor to the system; in response to the user request, (a) adding a new node in the knowledge graph corresponding to the sensor, and (b) linking the new node to the corresponding physical device generating the missing data item.

15. The system of claim 13, wherein the knowledge graph is a digital twin graph comprising a plurality of subgraphs, and each sub-graph comprises a plurality of nodes associated with a distinct physical device.

16. The system of claim 15, wherein the digital twin graph is analyzed to identify one or more missing data items by:

for each required data item,

identifying a possible device generating the required data item;

identifying a particular sub-graph corresponding to the possible device;

traversing the particular sub-graph to determine whether the required data item is represented in the sub-graph; and

if the required data item is not represented in the sub-graph, designating the required data item as one of the missing data items.

17. The system of claim 13, wherein the knowledge graph is defined with respect to a knowledge graph template and the set of data items are identified based on the knowledge graph template.

18. The system of claim 17, wherein the one or more missing data items are identified by: traversing each node in the knowledge graph;

as each node is processed during the traversal, if the node corresponds to a data item included in the set of required data items, creating a record that the required data item is present in the knowledge graph; and

at the end of the traversal, designating any of the required data items not recorded as being present as the missing data items.

19. The system of claim 13, wherein each recommendation is presented to the user on a graphical depiction of the knowledge graph at a location associated with the corresponding output of the physical device and the method further comprises:

receiving a user selection of the recommendation on the graphical depiction of the knowledge graph; and

in response to the user selection, adding the sensor associated with the recommendation to the knowledge graph.

20. An article of manufacture for recommending sensors for uses in a system design, the article of manufacture comprising a non-transitory, tangible computer-readable medium holding computer-executable instructions for performing a method comprising:

receiving a knowledge graph describing a design of a system of a particular type;

identifying a set of required data items typically needed to model systems of the particular type;

analyzing the knowledge graph to identify one or more missing data items included in the set of required data items but not in the design of the system;

for each missing data item, (a) identifying a physical device generating the missing data item and (b) generating a recommendation for placement of a sensor at a corresponding output of the physical device; and

presenting each recommendation to a user.