System and method for assisting in providing models for use in digital twin simulation

Abstract

To search, at high speed, for an optimal scenario model to be applied to a digital twin simulator even when a scenario has a large number of dimensions.SOLUTION: A system determines a plurality of model classifications on the basis of one or more factors with respect to a scenario model for a digital twin simulator, the factors being identified from asset data, and a result of comparison between a value for each factor and a threshold of each factor. For each model classification and for each of one or more different outcomes with respect to the scenario model, the system receives, from a user, an outcome value range that is a range of a value based on heuristics. The system prepares, for each model classification, a scenario model having an outcome value belonging to the outcome value range received for the model classification. The system selects an optimal scenario model from among the scenario models prepared for each of the model classifications.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates generally to providing models for use in digital twin simulations. [Background technology]

[0002] As a technology relating to digital twin simulation, for example, there is a technology disclosed in Patent Document 1. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] EP3916501A1 Summary of the Invention [Problem to be solved by the invention]

[0004] The real-world objects that digital twins simulate can include various objects, such as vehicles such as trains, devices such as air compressors, or systems that include vehicles or devices (e.g., warehouses or factories).

[0005] A digital twin simulation uses a model. The model can be a machine learning model trained using training data about the real world (e.g., training data having data collected from one or more sensors as input data and data about the state of the real world as output data). Inference is performed using such a machine learning model, specifically, data collected from the real world (e.g., one or more sensors) is input and data representing an estimated state of the real world is output.

[0006] However, the data collected from the real world is not necessarily identical or similar to the input data in the training data, and as a result, the estimated state of the real world in the inference may differ significantly from the actual state of the real world.

[0007] One way to avoid such problems is to use a modeled scenario set instead of the above-mentioned machine learning model. A "scenario set" is a collection of multiple scenarios. A "scenario" is an element of a scenario set, and is data containing values ​​that can be included in input data for each of multiple data items. A scenario set can cover many combinations of multiple values ​​corresponding to multiple data items.

[0008] However, this method has a trade-off problem known as the "curse of dimensionality." That is, the more dimensions (elements) there are in each scenario, the wider the search range of the query for model search. The fewer dimensions there are, the lower the accuracy of the model (the accuracy of the digital twin simulation). [Means for solving the problem]

[0009] The system determines a plurality of model classifications, each of which is a classification of a scenario model, based on one or more model factors that are one or more different factors for a scenario model for a digital twin simulator identified from physical asset data or corresponding digital asset data, and on a comparison result between a value for each of the one or more model factors and a threshold value for the model factor. For each of the plurality of model classifications, the system receives from a user an outcome value range that is a range of values ​​for one or more model outcomes that are one or more different outcomes for the scenario model and that is a value range based on a heuristic. For each of the plurality of model classifications, the system prepares a scenario model having an outcome value that belongs to the outcome value range received for the model classification. The system selects an optimal scenario model from the scenario models prepared for each model classification. [Effects of the Invention]

[0010] According to the present invention, it is possible to quickly search for an optimal scenario model to be applied to a digital twin simulator even if the scenario has a large number of dimensions. [Brief explanation of the drawings]

[0011] [Figure 1] 1 shows the configuration of an entire system including a model provision support system according to an embodiment of the present invention. [Figure 2] 1 shows an example of data in each storage area in a storage device. [Figure 3] 10 shows an example of the structure and relationship of data stored in a metadata area. [Figure 4] An example of the main GUI is shown below. [Figure 5] An example of a scenario definition GUI is shown. [Figure 6] An example of the Heuristics definition GUI is shown below. [Figure 7] An example of a model selection result GUI is shown. [Figure 8] 10 shows an example of processing performed by an asset modeling unit and a scenario modeling unit. [Figure 9] An example of the details of creating a Scenario Set is shown below. [Figure 10] An example of the details of Scenario Model generation is shown below. [Figure 11] 10 shows an example of details of model clustering. [Figure 12] 10 shows an example of processing performed by a caching unit. [Figure 13] 10 shows an example of processing performed by the model selection unit. [Figure 14] An example of the details of decision tree generation will be shown. [Figure 15] A first example of decision tree generation is shown below. [Figure 16] A second example of decision tree generation is shown below. [Figure 17] An example of the details of model selection will be shown below. [Figure 18] An example of CPU monitoring details is shown below. [Figure 19]An example of Asset Health monitoring details is shown below. [Figure 20] An example of the details of data monitoring is shown below. [Figure 21] 10 shows an example of details of query generation. DETAILED DESCRIPTION OF THE INVENTION

[0012] In the following description, an "interface apparatus" may refer to one or more interface devices, which may be at least one of the following: An I / O interface device is one or more I / O (Input / Output) interface devices. The I / O interface device is an interface device for at least one of an I / O device and a remote display computer. The I / O interface device for the display computer may be a communications interface device. The at least one I / O device may be a user interface device, for example, either an input device such as a keyboard and a pointing device, or an output device such as a display device. A communication interface apparatus that is one or more communication interface devices. The one or more communication interface devices may be one or more homogeneous communication interface devices (e.g., one or more NICs (Network Interface Cards)) or two or more heterogeneous communication interface devices (e.g., an NIC and an HBA (Host Bus Adapter)).

[0013] In the following description, "memory" refers to one or more memory devices, which are an example of one or more storage devices, and may typically be a primary storage device. At least one memory device in the memory may be a volatile memory device or a non-volatile memory device.

[0014] In the following description, a "persistent storage device" may refer to one or more persistent storage devices, which are an example of one or more storage devices. A persistent storage device may typically be a non-volatile storage device (e.g., an auxiliary storage device), and specifically may be, for example, a hard disk drive (HDD), a solid state drive (SSD), a non-volatile memory express (NVME) drive, or a storage class memory (SCM).

[0015] In the following description, the term "storage device" may refer to at least one of memory and persistent storage device.

[0016] Furthermore, in the following description, a "processor" may refer to one or more processor devices. The at least one processor device may typically be a microprocessor device such as a CPU (Central Processing Unit), but may also be another type of processor device such as a GPU (Graphics Processing Unit). The at least one processor device may be a single-core or multi-core. The at least one processor device may also be a processor core. The at least one processor device may also be a processor device in a broader sense, such as a circuit that is a collection of gate arrays written in a hardware description language that performs some or all of the processing (for example, an FPGA (Field-Programmable Gate Array), a CPLD (Complex Programmable Logic Device), or an ASIC (Application Specific Integrated Circuit)).

[0017] Furthermore, while the following description may describe functions such as a checker or a DBMS (Database Management System), the functions may be implemented by one or more computer programs executed by a processor, by one or more hardware circuits (e.g., FPGAs or ASICs), or by a combination thereof. When a function is implemented by a program executed by a processor, the specified processing is performed using a storage device and / or an interface device, etc., as appropriate, and therefore the function may be considered to be at least a part of the processor. Processing described using a function as the subject may also be processing performed by a processor or a device having the processor. A program may be installed from a program source. The program source may be, for example, a program distribution computer or a computer-readable storage medium (e.g., a non-transitory storage medium). The description of each function is merely an example, and multiple functions may be combined into one function, or one function may be divided into multiple functions.

[0018] In the following description, when elements of the same type are described without distinction, common reference symbols are used, and when elements of the same type are described with distinction, reference symbols are used.

[0019] A model provision support system according to an embodiment of the present invention will be described below with reference to the drawings. A model is a model used in a digital twin simulation. In the following description, the following terms are used. The "real world" is the world that the digital twin simulates, or in other words, the world that the digital twin is trying to recreate. A "physical asset" is a physical object in the real world (e.g., a train, a robot, an air compressor, a car, etc.). One or more physical assets exist in the real world, but if there is only one physical asset in the real world, the physical asset and the real world may be synonymous. In the following embodiments, for simplicity of explanation, the physical asset and the real world are synonymous. - A "virtual world" is a world provided by a digital twin, which is a simulation of the real world. A "digital asset," which may also be called a virtual asset, is a digital copy of a physical asset. A digital asset may be an object modeled based on data collected about the real world (e.g., data from sensors). "Feature" refers to a characteristic as a data item (e.g., a variable item). As a data item value (e.g., a variable value), it can be expressed as a "Feature Value."

[0020] FIG. 1 shows the overall configuration of a system including a model provision support system according to one embodiment of the present invention.

[0021] A client terminal 201 and a model provision support system 203 are connected to a communication network (for example, the Internet or a WAN (Wide Area Network)) 15. In addition, communication devices (for example, sensors and gateways) in the real world 67 are also connected to the communication network 15.

[0022] The client terminal 201 is an information processing terminal such as a personal computer or a smartphone, but may also be a virtual information processing terminal (for example, a virtual machine or a virtual desktop). The client terminal 201 executes a computer program such as a web browser. This causes a UI (User Interface) such as a GUI (Graphical User Interface) 104 to be displayed. The client terminal 201 transmits a request to the model provision support system 203 and receives a response from the model provision support system 203. Hereinafter, the operator of the client terminal 201 will be referred to as a "user."

[0023] The model provision support system 203 is a physical computer system, but may also be a logical computer system based on a physical computer system (for example, a cloud service system based on a cloud infrastructure). The model provision support system 203 receives data (for example, data measured by a sensor) from the real world 67. The model provision support system 203 also receives data input via the GUI 104. The model provision support system 203 has an interface device 211, a storage device 212, and a processor 213 connected to them.

[0024] The interface device 211 communicates with the client terminal 201 (and communication devices in the real world 67) via the communication network 15.

[0025] storage device 212 has storage areas such as an external storage area 609, an application storage area 601, and an application memory area 600. 212 stores a computer program that is executed by the processor 213.

[0026] When the processor 213 executes the computer program, functions such as an asset modeling unit 100, a scenario modeling unit 101, a caching unit 102, and a model selection unit 103 are realized.

[0027] FIG. 2 shows an example of data in each storage area in the storage device 212.

[0028] The external storage area 609 stores an Asset Structure Model 610, an Asset Failure Model 611, an Asset Behavior Model 612, and an Expected Behavior 829. The application memory area 600 has a cache area 602, which stores a Scenario Model.

[0029] The application storage area 601 includes a history data area 603 , a scenario area 604 , a model area 605 , a scenario library 607 , a GUI input area 608 , and a metadata area 823 .

[0030] The history data area 603 stores Asset Data 809 of a physical asset. Asset Data 809 may exist for a predetermined period (e.g., daily or monthly). In other words, a history of Asset Data 809 may be stored. Asset Data 809 represents, for each of one or more Features of a physical asset, a feature amount (e.g., a value measured by a sensor) and the date and time the feature amount was acquired. Asset Data 809 may be time-series data of the feature amount for each of one or more Features of a physical asset. Asset Data 809 may be input from GUI 104 or from the real world 67.

[0031] The scenario area 604 stores Scenario Set Data 817. Scenario Set Data 817 exists for each scenario set. Details of Scenario Set Data 817 will be explained later with reference to FIG.

[0032] The model area 605 stores a Scenario Model 613. The scenario library 607 is a library of Scenario Models, and specifically, for example, stores a Scenario Model 614 that is a cluster of the Scenario Models 613 stored in the model area 605.

[0033] The GUI input area 608 stores metadata related to GUI input, specifically, data such as IF-THEN Rules 826, Threshold 820, Range 821, and RSM Design 822, for example.

[0034] The IF-THEN Rules 826 are data referenced in the processing by the model selection unit 103, and represent one or more if-then rules.

[0035] Threshold 820 is data referenced in the processing by model selection unit 103, and indicates a threshold for each of a plurality of data items (for example, failure rate, CPU utilization rate).

[0036] Range 821 is data that indicates a value range for each Feature (for example, a combination of the minimum and maximum values ​​of the feature amount).

[0037] RSM Design 822 is data relating to the specifications or design of an RSM (Response Surface Methodology) model, and indicates, for example, the type of RSM model and parameters that can be used for each of one or more types of RSM models.

[0038] The metadata area 823 stores metadata related to model provision support, specifically, Model_ID 813, Feature_Data 814, RSM_Variable_Data 815, Scenario_Range_Data 816, Feature_Importance_Scores 818, and Query Metadata 819. Details of the data 813 to 816 and 817 will be described later with reference to FIG.

[0039] Query Metadata 819 is metadata of queries received from the client terminal 201. Query Metadata 819 has an entry for each query. The entry indicates Query_Key (the ID or name of the Feature as the Key specified in the query), Query_Value (the value corresponding to the key specified in the query (the Feature IDs of the first and second explanatory variables)), and Count (the number of queries).

[0040] FIG. 3 shows an example of the structure and relationship of the Scenario Set Data 817 and the data in the metadata area 823.

[0041] Model_ID 813 has data indicating the ID for each Scenario Model.

[0042] Feature_Data 814 is data that represents the Feature_ID (the ID of the feature) and Feature_Name (the name of the feature) for each feature.

[0043] RSM_Variable_Data 815 is data representing a pair of a response variable and a group of explanatory variables for each Scenario Model. RSM_Variable_Data 815 has an entry for each Scenario Model. The entry has data such as Model_ID, Response_Var, Explanatory_Var1, and Explanatory_Var2. Model_ID represents the ID of the Scenario Model. Response_Var means the response variable, and its value may be the ID of a Feature. Explanatory_Var1 and Explanatory_Var2 mean the first and second explanatory variables, and their respective values ​​may be the ID of a Feature. Specifically, the name of the Feature can be identified from Feature_Data 814 using the ID of the Feature, Response_Var, Explanatory_Var1, or Explanatory_Var2.

[0044] Note that "group of explanatory variables" means one or more explanatory variables, and in the illustrated example, there are two explanatory variables. This is because an example of a Scenario Model is a 3D RSM (Reynolds Stress Model). An Explanatory_Var is provided for each explanatory variable. For example, if the feature serving as the objective variable is "temperature," the feature serving as the first explanatory variable may be "lighting outcome," and the feature serving as the second explanatory variable may be "rotation speed."

[0045] When a model other than the 3D RSM is adopted as the Scenario Model, the number of variables may be more or less than three. The number of variables may be specified from the GUI 104, but in this embodiment, the number of variables is determined by the heuristic logic function (e.g., Heuristics Execution 109 ( Figure 13 The temperature may be determined by the method described above.

[0046] Scenario_Range_Data 816 is data representing the value range of the objective variable (range of feature quantities) and the value range of each explanatory variable for each Scenario Model. The data representing the value range of the objective variable is composed of Response_Var_Min (data representing the minimum value of the objective variable) and Response_Var_Max (data representing the maximum value of the objective variable). The data representing the value range of the first explanatory variable is composed of Explanatory_Var1_Min (data representing the minimum value of the first explanatory variable) and Explanatory_Var1_Max (data representing the maximum value of the first explanatory variable). The data representing the value range of the second explanatory variable is composed of Explanatory_Var2_Min (data representing the minimum value of the second explanatory variable) and Explanatory_Var2_Max (data representing the maximum value of the second explanatory variable). The expression of the value range does not have to be limited to a combination of minimum and maximum values.

[0047] Scenario Set Data 817 has an entry for each scenario. An entry is data representing a scenario, specifically, it has data such as Model_ID, Scenario_ID, Response_Var, Explanatory_Var1, and Explanatory_Var2. Model_ID represents the ID of the Scenario Model corresponding to the scenario. Scenario_ID represents the ID of the scenario. Response_Var represents one of the values ​​that can be taken as the objective variable. Explanatory_Var1 represents one of the values ​​that can be taken as the first explanatory variable. Explanatory_Var2 represents one of the values ​​that can be taken as the second explanatory variable.

[0048] A Scenario Model is based on a scenario set, which is composed of multiple scenarios. The scenario set, which is composed of multiple scenarios, is based on multiple combinations of values ​​of the objective variable, the first explanatory variable, and the second explanatory variable. Specifically, the value represented by any Explanatory_Var1 corresponding to one scenario set is the same as or between the value represented by Explanatory_Var1_Min and the value represented by Explanatory_Var1_Max.

[0049] Feature_Importance_Scores 818 is data representing the ID (Feature_ID) of a feature and the importance of the feature (Feature_Importance_Score) for each feature.

[0050] Examples of the GUI 104 will be described below with reference to Figures 4 to 7. In the following description, any component such as a check box, a text box, or a button may be used as an example of a GUI component.

[0051] FIG. 4 shows an example of the main GUI 104A.

[0052] The main GUI 104A is the top GUI provided (displayed) on the client terminal 201. The main GUI 104A has, for example, a button 500 for accepting a request to load Asset Data 809, a button 501 for accepting a request to define a scenario, a button 502 for accepting a request to build a model, a button 509 for accepting a request to input heuristics, and a button 510 for accepting a request to execute model selection.

[0053] The main GUI 104A also has a GUI component group 503 that accepts input of various thresholds. Examples of thresholds include a threshold related to statistics (e.g., distribution) identified from the Asset Data 809, a threshold for the failure rate identified from the Asset Data 809, and a threshold for the CPU usage rate identified from the Asset Data 809. The thresholds input via the GUI component group 503 are included in Threshold 820.

[0054] Furthermore, the main GUI 104A has a group of GUI components (e.g., a group of text boxes) 505 that accepts input of requirements (range of outcome values) for each of multiple outcomes of the Scenario Model (e.g., accuracy, execution speed, and time required for construction). When requirements for each outcome are input into the group of GUI components 505 and button 502 or button 510 is pressed, the model provision support system 203 constructs or selects a Scenario Model that satisfies the requirements. Alternatively or in addition, an outcome value range associated with each model classification, which will be described later, may be input into the group of GUI components 505.

[0055] For example, when the user presses button 501, a scenario definition GUI 104B (see FIG. 5) is provided to the client terminal 201. Also, when the user presses button 509, a heuristics definition GUI 104C (see FIG. 6) is provided to the client terminal 201. Also, when the user presses button 510, a model selection process is executed, and a model selection result GUI 104D (see FIG. 7) is provided to the client terminal 201.

[0056] FIG. 5 shows an example of the scenario definition GUI 104B.

[0057] The scenario definition GUI 104B is a GUI that accepts input of a definition related to a scenario. The scenario definition GUI 104B includes, for example, a GUI component (e.g., a text box) 51 that accepts input of a scenario name, a GUI component group 52 that accepts input of a variable set as a scenario (e.g., a GUI component group 52 that accepts input of a Feature ID and whether the variable is a target variable or an explanatory variable for each variable as a scenario), a GUI component group 53 that accepts input of a variable value (feature amount) for each variable (Feature), a GUI component group 54 that accepts input of a value range for each variable (e.g., a combination of a minimum value and a maximum value), and a button 4 that accepts a request for scenario creation. 1 9 and 4 buttons 1 When the user presses 9, Scenario Set Data 817 (or Scenario Data, which is an element of Scenario Set Data 817 and is data representing a scenario) is generated according to the data input to the scenario definition GUI 104B.

[0058] FIG. 6 shows an example of the Heuristics Definition GUI 104C.

[0059] Heuristics definition GUI 104C is a GUI that accepts input of heuristics definition data such as if-then rules. For example, if the input rule is if-then rule data, the data is saved as part or all of IF-THEN Rules 826 when button 513 in GUI 104C is pressed.

[0060] FIG. 7 shows an example of the model selection result GUI 104D.

[0061] The model selection result GUI 104D is a GUI that displays the results of the model selection process. As a result, for example, it shows performance information of the Scenario Model found as a selection candidate (for example, specific values ​​of accuracy, execution speed, and model construction time, or the Outcome to which these values ​​belong). The user determines whether or not to select (approve) the Scenario Model that has been selected as a selection candidate from the displayed performance information, and if so, presses button 4 to notify the system 203 of the intention to select. 1 Press 9. Button 4 1 When 9 is pressed, the Scenario Model is recognized as the Scenario Model to be used for digital twin simulation (for example, it is deployed to a simulator that performs digital twin simulation).

[0062] An example of the processing performed in this embodiment will be described below.

[0063] FIG. 8 shows an example of processing performed by the asset modeling unit 100 and the scenario modeling unit 101.

[0064] The asset modeling unit 100 manages Asset Management 824 and Expected Behavior. or Generation 828 is performed.

[0065] In Asset Management 824, the asset modeling unit 100 reads Asset Data 809 of a physical asset, identifies data for each of the models 610-612 from the Asset Data 809, and inputs the identified data into the model. Each of the models 610-612 outputs data obtained based on the input data, and data including the data output from the models 610-612 (for example, data including a time series of predicted sensor data (sensor measurement values)) is Expected Behavior 829.

[0066] Each of the models 610 to 612 may be a model constructed by the asset modeling unit 100 using past Asset Data 809 as at least a portion of the training data. Each of the models 610 to 612 corresponds to a portion of a model of a digital asset corresponding to a physical asset. The model of a digital asset may be configured as a single model, but in this embodiment, it may be a set of models (e.g., machine learning models) prepared for each viewpoint. In this embodiment, the viewpoints are "configuration," "fault," and "normal operation."

[0067] The model corresponding to the "configuration" is the Asset Structure Model 610. The Asset Structure Model 610 is a model that takes telemetry data (e.g., performance time series data) identified from the Asset Data 809 as input and outputs data related to the operation of the physical asset. The telemetry data may include time series of features for all or some of the explanatory variables.

[0068] The model corresponding to "failure" is Asset Failure Model 611. Asset Failure Model 611 is a model that receives failure data (e.g., data representing a failure rate, data representing a feature value indicating a failure and the date and time of the failure occurrence) identified from Asset Data 809 as input and outputs data related to the operation of a physical asset. The failure data may include at least one of a time series of feature values ​​for all or some of the explanatory variables (e.g., explanatory variables other than the explanatory variables included in the telemetry data) and a time series of feature values ​​for the objective variable.

[0069] The model corresponding to "normal operation" is Asset Behavior Model 612. Asset Behavior Model 612 is a model that receives normal operation data (e.g., time series data of features representing normal operation) identified from Asset Data 809 as input and outputs data related to the operation of a physical asset. The normal operation data may include at least one of a time series of features for all or some of the explanatory variables (e.g., explanatory variables other than those included in the telemetry data, or explanatory variables that are the same as those included in the failure data) and a time series of features for the objective variable.

[0070] The asset modeling unit 100 or In generation 828, an Expected Behavior is generated that includes the data output from each of the models 610 to 612. or The asset modeling unit 100 generates the Expected Behavior 829. or 829 to the scenario modeling unit 101. or 829 is data regarding the behavior of a digital asset corresponding to a physical asset (for example, data including a time series of expected feature values ​​for each feature).

[0071] Scenario Modeling Section 101: Expected Behavior or829 is input. The scenario modeling unit 101 performs Scenario Set generation 105, Scenario Model generation 106, and model clustering 107.

[0072] FIG. 9 shows an example of the details of the Scenario Set generation 105.

[0073] The scenario modeling unit 101 performs Feature extraction 302. In Feature extraction 302, the scenario modeling unit 101 identifies a Feature from Asset Data 809 (for example, a time-series CSV file), generates Feature_Data 814 (for example, receives an ID and name for each Feature from the user), and stores the Feature_Data 814 in the metadata area 823.

[0074] The scenario modeling unit 101 performs ID setting 34. In ID setting 34, the scenario modeling unit 101 generates Model_ID 813 as a list of IDs to be assigned to the Scenario Model (for example, generates a list of IDs that are automatically input or manually input), and stores Model_ID 813 in the metadata area 823.

[0075] The scenario modeling unit 101 performs variable setting 306. In variable setting 306, the scenario modeling unit 101 defines a target variable and first and second explanatory variables, generates RSM_Variable_Data 815 including the defined variables (and model IDs), and stores RSM_Variable_Data 815 in the metadata area 823. This definition may be performed based on user input.

[0076] The scenario modeling unit 101 performs scenario setting 308. In the scenario setting 308, the scenario modeling unit 101 generates Scenario Set Data 817 based on RSM_Variable_Data 815, and stores the Scenario Set Data 817 in the scenario area 604. Specifically, for example, the scenario modeling unit 101 refers to Range 821, specifies a value range for each of the dependent variable and the first and second explanatory variables, generates N possible combinations of the value of the dependent variable, the value of the first explanatory variable, and the value of the second explanatory variable (N is an integer of 2 or more), and stores each combination in S c Scenario Set Data 817 is generated with the entries included as Scenario Data.

[0077] FIG. 10 shows an example of the details of the Scenario Model generation 106.

[0078] The scenario modeling unit 101 performs value extraction 303. In the value extraction 303, the scenario modeling unit 101 extracts the expected behavior. or The scenario modeling unit 101 specifies a value range for each of the objective variable and the first and second explanatory variables (for example, specifies the maximum and minimum values ​​of the feature quantity) from 829. The scenario modeling unit 101 generates Scenario_Range_Data 816 that represents the specified value range for each of the objective variable and the first and second explanatory variables, and stores Scenario_Range_Data 816 in the metadata area 823.

[0079] The scenario modeling unit 101 performs approval and adjustment 304. In approval and adjustment 304, the scenario modeling unit 101 displays each value range represented by Scenario_Range_Data 816 and accepts approval or adjustment from the user. In the case of adjustment, the value range is updated according to the user input.

[0080] If approval is given in approval adjustment 304, the scenario modeling unit 101 performs model construction 305. In model construction 305, the scenario modeling unit 101 constructs a Scenario Model 613 as an RSM model based on an RSM Design 822 (one or more parameters of the RSM model), and stores the Scenario Model 613 in the model area 605. The Scenario Model 613 is a model that predicts the value of a dependent variable.

[0081] FIG. 11 shows an example of the model clustering 107 in detail.

[0082] The scenario modeling unit 101 performs Feature Vectors Acquisition 316 by waiting for data 309 (waiting for a sufficient amount of Scenario Set Data 817 to perform model clustering 107) or without waiting for data 309. In Feature Vectors Acquisition 316, the scenario modeling unit 101 generates Feature Vectors 310 from Scenario Set Data 817. The Feature Vectors 316 are vector data of the features contained in the Scenario Set Data 817.

[0083] The scenario modeling unit 101 performs score calculation 312. In score calculation 312, the scenario modeling unit 101 generates Feature_Importance_Scores 818 representing the score for each feature, and stores Feature_Importance_Scores 818 in the metadata area 823. The score for each feature (e.g., the weight of a variable) may be determined by any of the following methods. For each feature, the user inputs a score via the GUI 104. The scenario modeling unit 101 automatically determines the score of each feature (e.g., objective variable, first and second explanatory variables). For example, the scenario modeling unit 101 divides the feature quantities for each feature into k groups (e.g., k = 3) based on the Feature Vectors 316, and generates an RSM model for each group. The value of k may be a value input via the Heuristics Definition GUI 104C (see FIG. 6). The scenario modeling unit 101 calculates the accuracy of the RSM model for each group, and determines the score of the feature based on the level of accuracy.

[0084] The scenario modeling unit 101 performs grouping 314. In grouping 314, the scenario modeling unit 101 divides a plurality of feature quantities of a plurality of features (for example, a response variable, a first and second explanatory variables) into k groups (for example, k=3) based on, for example, Feature Vectors 316.

[0085] The scenario modeling unit 101 performs training 315. In training 315, the scenario modeling unit 101 prepares a Scenario Model (RSM model) for each group based on the Scenario Model generated in FIG. 10 and trains (learns) the Scenario Model. The training (learning) of the Scenario Model may be training according to a regression method, and the training data may be a feature set belonging to the group. The scenario modeling unit 101 identifies an accuracy threshold (e.g., minimum and maximum values) from Threshold 820, and stores the Scenario Model in the model area 605 if the accuracy of the Scenario Model satisfies a condition based on the accuracy threshold (e.g., if the accuracy is equal to or greater than the minimum value and equal to or less than the maximum value). In training, low-accuracy and high-accuracy Scenario Models are generated based on the feature scores (Importance Scores).

[0086] In training 315, the scenario modeling unit 101 clusters the Scenario Models based on their accuracy. For example, when k=3 (k is the number of clusters), a cluster of high-accuracy Scenario Models, a cluster of medium-accuracy Scenario Models, and a cluster of low-accuracy Scenario Models may be generated. An intermediate value of accuracy may be generated based on the maximum and minimum values ​​of the accuracy threshold, and clustering may be performed based on the minimum, intermediate, and maximum values.

[0087] In addition, the scenario modeling unit 101 may apply any clustering algorithm in grouping 314 and training 315 (for example, by applying a clustering algorithm from a GUI) to separate (cluster) models based on one or more criteria such as accuracy, speed, S / N ratio, query hit rate, etc.

[0088] Clustering is also useful for creating multiple models based on different user requirements: for example, a user who does not care about accuracy but wants fast results (up to a limit of, say, 70%) can choose a model with low accuracy and high speed.

[0089] FIG. 12 shows an example of the process performed by the caching unit 102.

[0090] The caching unit 102 performs a read 133. In the read 133, the caching unit 102 reads the Query Metadata 819 Read out.

[0091] The caching unit 102 performs cache empty 134. In cache empty 134, the caching unit 102 empties one or more cache blocks in the cache area 602.

[0092] The caching unit 102 performs caching 135. In the caching 135, the caching unit 102 caches Query Metadata 819Based on this, the Scenario Model corresponding to the query with the largest Count (number of queries) (the Scenario Model from which a value for the key corresponding to the value in the query with the largest Count is obtained) is selected from the Scenario Models 113, and the selected Scenario Model is stored in an empty cache block. The Scenario Models 113 may include Scenario Models generated by the scenario modeling unit 101 and / or the model selection unit 103 (Scenario Models in the model area 605 and / or the scenario library 607).

[0093] FIG. 13 shows an example of the processing performed by the model selection unit 103.

[0094] The model selection unit 103 performs decision tree generation 108, which includes reading out the threshold 820. As a result, multiple model classifications, which are multiple classifications for the Scenario Model, are obtained based on various thresholds.

[0095] The model selection unit 103 executes heuristics 109. In the heuristics execution 109, the model selection unit 103 executes actions according to heuristics (user-defined) such as IF-THEN rules 826.

[0096] The model selection unit 103 performs model selection 110. In model selection 110, the model selection unit 103 selects a Scenario Model.

[0097] The model selection unit 103 performs query generation 834. The model selection unit 103 can automatically form a query and request values ​​from Scenario Models (for example, the scenario library 607).

[0098] FIG. 14 shows an example of the details of the decision tree generation 108.

[0099] The model selection unit 103 performs data reading 1401. In data reading 1401, the model selection unit 103 reads Asset Data 809 and Threshold 820.

[0100] Asset Data 809 may include values ​​for each of a plurality of Factors, such as a value related to the condition of a physical asset, a value for CPU load (e.g., CPU usage rate or number of PCB slots), a value as a sensor measurement value, and a Factor value representing the input type (e.g., whether the input data is calculated data or modeled data). Hereinafter, for each Factor, the Factor may be an item, and the Factor value may be a value for the Factor. For example, if the Factor is CPU load, the Factor value may be the obtained numerical value.

[0101] Threshold 820 may include a threshold for each factor, for example, a threshold for factor values ​​related to conditions, a threshold for CPU usage, a threshold for sensor measurement values, a threshold for factor values ​​representing input types, etc. There are m outcomes under n factors (n and m are each integers equal to or greater than 1 (typically integers equal to or greater than 2)). m = n - 1 may be used. The relationship between m and n is not limited to this example. An outcome may be an attribute of a Scenario Model (such as accuracy (model accuracy), execution speed, and construction time). For each outcome, the outcome may be an item, and the outcome value may be a value for that outcome. For example, if the outcome is accuracy, the outcome value may be a numerical value.

[0102] The model selection unit 103 performs a determination 1402. In the determination 1402, the model selection unit 103 compares each Factor value read in the data read 1401 with the threshold value of the Factor value. In this embodiment, the comparison result between the Factor value and the threshold for each Factor value is either whether or not the Factor value satisfies the condition based on the threshold, and the number of types of Factor values ​​is n (i.e., the number of thresholds is n). Therefore, the number of model classifications X is 2 n (2 to the nth power). In this way, the number of model classifications is based on the number of possible comparison results between the factor value and the threshold and the number of factors. The number of possible comparison results may differ depending on the factor (threshold).

[0103] For each of the m outcomes, an outcome value for that outcome is provided for each model classification. That is, the model selection unit 103 determines the range of outcome values ​​for that outcome for each model classification based on the comparison results (comparison results between factor values ​​and thresholds) corresponding to that model classification. Therefore, there are combinations of outcome value ranges for each model classification (combinations of outcome value ranges for the m outcomes). For each of the m outcomes, the outcome value range may be set by the user via the GUI 104 based on heuristics.

[0104] The model selection unit 103 generates or selects one Scenario Model for each model classification. That is, X Scenario Models are generated or selected (one of these Scenario Models is cached by the caching unit 102). For each model classification, the generated or selected Scenario Model has each Outcome value that belongs to the Outcome value range of the model classification. For at least one Outcome, the Outcome value range may be composed of one Outcome value.

[0105] In the determination 1402, the comparison of the factor values ​​with the thresholds for each of the multiple factors may be performed in parallel, or may be performed serially as shown in Fig. 14. For example, the factors may have priorities, and the factor values ​​may be compared with the thresholds in descending order of priority.

[0106] A first example and a second example of the decision tree generation 108 will be described.

[0107] FIG. 15 shows a first example of decision tree generation 108.

[0108] Let's assume that there are three Factors (Data type, Asset Status, and CPU Status), and two Outcomes (Accuracy and Execution Speed) under the three Factors. Since n=3, eight model classifications are possible (8=2 3 ). Therefore, eight Scenario Models are selected. Specifically, eight Scenario Models are generated in the decision tree generation 108 (they are generated separately from the Scenario Models generated by the scenario modeling unit 101). Note that the "Asset" shown in FIGS. 15 and 16 is a Physical Asset. Furthermore, the "CPU" shown in FIGS. 15 and 16 is a CPU in the real world 67.

[0109] The order of priority for Factor may be Data type → Asset Status → CPU Status. Data type "Common" may mean that the sensor measurement value meets the condition based on its threshold, and Data type "Rare" may mean that the sensor measurement value does not meet the condition based on its threshold. Asset Status "Healthy" may mean that the Factor value related to the condition meets the condition based on its threshold, and Asset Status "Near Breakdown" may mean that the Factor value related to the condition does not meet the condition based on its threshold. CPU Status "Free" may mean that the CPU usage meets the condition based on its threshold, and CPU Status "Busy" may mean that the CPU usage does not meet the condition based on its threshold.

[0110] For each of the two outcomes (Accuracy and Execution Speed), the model selection unit 103 determines an outcome value range for each model classification based on the comparison result (comparison result between the factor value and the threshold) corresponding to that model classification. For each model classification, the model selection unit 103 generates or selects a Scenario Model having an outcome value that falls within each outcome value range of that model classification (for example, by selecting from the model area 605 or the scenario library 607).

[0111] FIG. 16 shows a second example of decision tree generation 108.

[0112] Let's assume that there are four Factors (Input, Data type, Asset Status, and CPU Status), and three Outcomes (Accuracy, Execution Speed, Signal-Noise Ratio) under the four Factors. Since n=4, 16 model classifications are possible (16=2 4 ) Therefore, 16 Scenario Models are selected.

[0113] Input means the input type. Input “Calculated Data” means Asset Data809, and Input “Modeled Data” means Scenario Set The Factor may be Input → Data type → Asset Status → CPU Status in descending order of priority. or 829 helps the system 203 understand the range of values ​​to expect.

[0114] For each of the three outcomes (Accuracy, Execution Speed, and Signal-Noise Ratio), the model selection unit 103 determines an outcome value range for each model classification based on the comparison result (comparison result between the factor value and the threshold) corresponding to that model classification. For each model classification, the model selection unit 103 generates or selects a Scenario Model having an outcome value that falls within each outcome value range of that model classification.

[0115] FIG. 17 shows an example of details of the model selection 110.

[0116] The model selection section 103 is a main GUI 104 A (See FIG. 4) is displayed (reference numeral 830). When the button 500 is pressed, the model selection unit 103 reads out the Asset Data 809.

[0117] Main GUI104 A When the button 501 is pressed (reference numeral 401: Yes), the model selection unit 103 displays the scenario definition GUI 104B (see FIG. 5) (reference numeral 831). 1 If 9 is pressed (code 400: Yes), the model selection unit 103 selects Scenario Set Dat a8 Generates 17 (code 817).

[0118] Main GUI104 AWhen the button 509 is pressed (reference numeral 402: Yes), the model selection unit 103 displays the heuristics definition GUI 104C (FIG. 6) (reference numeral 833).

[0119] Main GUI104 A If the button 502 is pressed (reference number 403: Yes), the model selection unit 103 classifies the Scenario Models into a plurality of clusters based on the Threshold 820 (reference number 406). The Scenario Models 614 may include the classified Scenario Models.

[0120] Main GUI104 A When the button 510 is pressed (sign 404 : Yes), the model selection unit 103 selects a Scenario Model. The selected Scenario Model may be, for example, a Scenario Model corresponding to a manually input query, or, for example, a Scenario Model corresponding to an Outcome value input to the GUI component group 505 of the main GUI 104A. Scenario Models 614 may include this Scenario Model. Scenario Models 614 may also include X Scenario Models generated or selected in decision tree generation 108.

[0121] The model selection unit 103 performs CPU monitoring 408, Asset Health monitoring 410, and Data monitoring 411 in the background of the display of the GUI 104, for example. 9 411. Note that these three monitoring 408, 410 and 9 15. Therefore, when there is an additional Input as shown in FIG. 16 as a Factor, the Monitors 408, 410, and 9In addition to 411, monitoring related to input is also performed. The data checked in each of these monitoring is Asset Data 809. If the results of these monitoring indicate that the correct Scenario Model that matches the current situation has not been selected, switching is required (symbol 405: Yes).

[0122] In CPU monitoring 408, as shown in FIG. 18, the model selection unit 103 reads out a PCB (Process Control Block) (reference numeral 409) and identifies the number of PCB slots being consumed (for example, the number of processes). The model selection unit 103 reads out a PCB slot threshold 820 (data indicating the PCB slot threshold) (reference numeral 411). If the number of consumed PCB slots is equal to or greater than the threshold (reference numeral 412: Yes), the model selection unit 103 determines that the CPU Status is "Busy" (reference numeral 413). If the number of consumed PCB slots is less than the threshold (reference numeral 412: No), the model selection unit 103 determines that the CPU Status is "Busy" (reference numeral 414). o) In this way, the CPU status is monitored, but the CPU status is determined to be "Free" based on other CPU-related values ​​such as the CPU usage rate (reference numeral 414). Being monitored Furthermore, the CPU to be monitored is an example of a processor, and may be a CPU of a system that performs a digital twin simulation. If the system is the model provision support system 203, the CPU to be monitored may be at least a part of the processor 213.

[0123] In Asset Health Monitoring 410, as shown in FIG. 19, the model selection unit 103 acquires a failure rate based on Asset Data 809 (reference numeral 415), and determines Asset Health based on the failure rate and a failure rate threshold value 416 (data representing the failure rate threshold value) (reference numeral 417).

[0124] Data monitoring 9In 411, as shown in FIG. 20, the model selection unit 103 acquires Asset Data (reference numeral 418). This Asset Data may be data acquired from the real world 67 (for example, sensor data) itself or data acquired based on that data. The Asset Data may also be data acquired by inputting the data into the Asset Structure Model 610. The model selection unit 103 inputs the acquired Asset Data into the Asset Failure Model 611 and the Asset Behavior Model 612 to obtain Asset Data 809, and stores the Asset Data 809 in the history data area. 603 The asset data 809 may be the data itself acquired from the real world 67. If the model selection unit 103 has enough data to generate a normal distribution (reference numeral 422: Yes), it generates a normal distribution for the current data point (timestamp) based on the asset data 809 and compares the value obtained from the normal distribution (a value indicating how rare the data is compared to past data) with a threshold 420 (data indicating a threshold value for the normal distribution) (reference numeral 421). The threshold may be a value input via the GUI component group 503 of the main GUI 104A. If the obtained value satisfies the condition based on the threshold (reference numeral 423: Yes), the model selection unit 103 labels the current data point as "Inside" (reference numeral 424). If the obtained value does not satisfy the condition based on the threshold (reference numeral 423: No), the model selection unit 103 labels the current data point as "Outside" (reference numeral 424). The model selection unit 103 generates Data Monitor Metadata 426, which is data including the attached labels and representing the monitoring results, and stores it in the metadata area 823, for example.

[0125] Referring again to Figure 17, the above-mentioned monitors 408, 410 and 9After 411, the model selection unit 103 accepts from the user a change to the elements of the decision tree in the decision tree generation 108 (for example, the number of Factors, the number of Outcomes, and the range of outcome values ​​for at least one Outcome) based on at least one of the IF-THEN Rules 826 and the Threshold 820 (reference numeral 407). As a result, if model switching is necessary (reference numeral 405: Yes), the model selection unit 103 switches the selected Scenario Model to another Scenario Model. Scenario Models 614 may include the Scenario Models after switching.

[0126] The model selection unit 103 displays a GUI (for example, model selection result GUI 104D) showing the processing results based on the Scenario Models 614 (reference numeral 832).

[0127] Depending on user-defined functions (heuristics and / or decision functions), a model can be selected. For example, of A decision tree may be generated based on the definition that "when the CPU is busy, a model with low accuracy is given priority," and the model with low accuracy may be selected preferentially by following the decision tree.

[0128] The difference between the model selected in model selection and the model corresponding to the query in Figure 21 is "clustering." Scenario Model queries are possible, but to help users select the model that best suits their situation, multiple models are classified into multiple clusters (clustered Scenario Models are generated). ) The relationship between the model selected in model selection and the models corresponding to the query in Figure 21 is that a single Scenario Model contains the full data, while clustered Scenario Models contain partial incremental data of the same data. This is done to ensure that each clustered Scenario Model behaves in a way that meets the accuracy level requirements.

[0129] FIG. 21 shows an example of the details of the query generation 834.

[0130] The model selection unit 103 issues a JSON query (an example of a query) 111 to request a query value via, for example, an API (Application Programming Interface) (reference numeral 124). JSON stands for JavaScript Object Notification (JavaScript is a registered trademark). The requested values ​​may be the values ​​of the first and second explanatory variables, and may be obtained from, for example, Asset Data 809 (or Expected Behavior 829), Js It is set as a value in the on query 111. Js In the on query 111, a target variable is set as a query key. Js The value set in the on query 111 may be manually input.

[0131] The HTTP handler 112 (which may be an example of the function of the model selection unit 103) Js In response to the on query 111, a value (e.g., a Scenario Model or its ID) is obtained from the Scenario Models 113, and the obtained value is stored in the Js An on response 114 (an example of a response to a query) is returned. The Scenario Models 113 may include at least a part of the Scenario Models 614, may include at least one Scenario Model in the model area 605, or may include at least one Scenario Model in the scenario library 607. The Scenario Models 113 may also be a cached Scenario Model (a Scenario Model stored in the cache area 602).

[0132] Js For the query key specified in on query 111, JsIf a value corresponding to a query value (for example, the values ​​of the first and second explanatory variables) specified in the on query can be identified from the Scenario Models 113, the value is Js It is set to on response 114.

[0133] The model selection unit 103 Js Based on the response 114, Query Metadata 819 is generated (reference numeral 2101).

[0134] Also, Js If a value exists in the on response 114 (reference number 126: Yes), the model selection unit 103 acquires that value 130 and updates the digital twin simulator (reference number 131). Specifically, if the model contains an out-of-range value (a value that is not found when queried), the model is replaced with a newly learned model, which is an update of the digital twin simulator.

[0135] on the other hand, Js If the value does not exist in the on response 114 (reference numeral 126: No), the model selection unit 103 calculates the value 128 (reference numeral 127) and updates the digital twin simulator based on the calculated value 128 (reference numeral 131). For example, the model selection unit 103 calculates the value 128 based on the query value and the Scenario Set Dat a8 17, the model selection unit 103 may calculate a value 128 for the query key based on the calculated value 128. The model selection unit 103 generates training data 129 using the calculated value 128 and trains (learns) at least a part of the Scenario Models 113. (code 123) The training data 129 may be, for example, data including query values ​​and calculated values ​​128. Also, Asset Data 809 in the history data area 603 is used to generate Scenario Data from missing query values. A new Scenario Model is trained using this Scenario Data.

[0136] A query for a model may use three variables (e.g., A, B, and C), and at least two values ​​may be required to determine one value. For example, to query the value of C, the values ​​of A and B may be required. C may be obtained by manually entering A and B. However, a query may also be constructed automatically by searching Scenario Data. If the value of A is given and no new input is made, the value of B can be assumed to remain unchanged, so the value of B may be extracted from Scenario Data. In other words, to query the value of C, the values ​​of A and B may be manually entered and the model may be searched. Alternatively, if the input has not changed from Asset Data 809 in the history data area 603, a value of A or B may be manually entered, and the corresponding value may be searched using Scenario Data, thereby automatically constructing a query for the remaining variables.

[0137] Although one embodiment has been described above, this is merely an example for explaining the present invention, and the scope of the present invention is not limited to this embodiment. The present invention can be implemented in various other forms.

[0138] The above description can be summarized, for example, as follows: The following summary may include supplementary explanations and explanations of variations of the above description.

[0139] The model provision support system 203 includes an interface device 211 that receives physical asset data (e.g., Asset Data) related to physical assets (e.g., the real world 67), a storage device 212 in which the physical asset data is stored, and a processor 213 connected to the interface device 211 and the storage device 212. The processor 213 determines multiple model classifications, each of which classifies a scenario model, based on one or more model factors that are different factors for a scenario model for a digital twin simulator identified from the Asset Data (or corresponding digital asset data) and a comparison result between the value of the model factor and its threshold for each of the one or more model factors. For each of the multiple model classifications, the processor 213 receives from the user an outcome value range, which is a range of values ​​for the model outcome and a value range based on a heuristic, for each of one or more model outcomes that are different outcomes for the scenario model. For each of the multiple model classifications, the processor 213 prepares a scenario model having an outcome value that belongs to the outcome value range received for the model classification. The processor 213 selects the optimal scenario model from the scenario models prepared for each model classification. In this way, even if the number of dimensions of the scenario is large, it is possible to quickly search for the optimal scenario model to be applied to the digital twin simulator.

[0140] The one or more model factors may include at least one of processor load (e.g., CPU Status), asset status (e.g., Asset Status), data point rarity (e.g., Data Type), and input data type (e.g., Input). The one or more model outcomes may include at least one of accuracy, execution speed, construction time, and signal-to-noise ratio. These examples of model factors and model outcomes contribute to quickly searching for an optimal scenario model to apply to the digital twin simulator, even if the scenario has a large number of dimensions.

[0141] The processor 213 may generate a decision tree in which multiple model classifications are each represented as a leaf node. In the decision tree, a root node or an intermediate node is a comparison between a value obtained for a model factor corresponding to the node and a threshold value corresponding to the model factor, and the next node may be determined based on the result of the comparison. The processor 213 may monitor values ​​for each of the multiple model factors. The optimal scenario model may be determined by tracing the decision tree based on the monitored value and threshold value for each model factor. This contributes to quickly searching for an optimal scenario model to be applied to the digital twin simulator, even if the scenario has a large number of dimensions.

[0142] The optimal scenario model can be the one with the highest query hit rate, which contributes to quickly searching for the optimal scenario model to be applied to the digital twin simulator even if the scenario has a large number of dimensions.

[0143] Each scenario model may be a Response Surface Methodology (RSM) model to predict the response.

[0144] Furthermore, each scenario model may be a model generated based on a scenario set including multiple scenarios, each of which is a combination of a response variable value and one or more explanatory variable values. The processor 213 may generate digital asset data, which is data corresponding to the physical asset data and is input to the digital twin simulator, by inputting the physical asset data into an asset model for each perspective, and may identify a value range for each variable based on the digital asset data to construct a scenario model. The response variable value may be an output value as a calculation result of the digital twin simulation, and the explanatory variables may be feature quantities identified from the data input to the digital twin simulation.

[0145] The multiple model classifications may be multiple model clusters based on one or more specified criteria, and each model cluster may be a collection of one or more scenario models. [Explanation of symbols]

[0146] 203: Model provision support system

Claims

1. an interface device that accepts physical asset data, which is data related to a physical asset; a storage device in which the physical asset data is stored; a processor connected to the interface device and the storage device; Equipped with the processor: determining a plurality of model classifications, each of which is a classification of the scenario model, based on one or more model factors, which are one or more different factors for a scenario model for a digital twin simulator identified from the physical asset data or the corresponding digital asset data, and a comparison result between a value for each of the one or more model factors and its threshold value; for each of the plurality of model classifications, for each of one or more model outcomes that are different outcomes for a scenario model, receiving from a user an outcome value range that is a range of values ​​for the model outcome and that is based on a heuristic; providing a scenario model for each of the plurality of model classes, the scenario model having an outcome value that falls within an outcome value range accepted for the model class; Select the most appropriate scenario model from the scenario models prepared for each model classification. Model provision support system.

2. the one or more model factors include at least one of processor load, asset condition, data point rarity, and input data type; the one or more model outcomes include at least one of accuracy, execution speed, build time, and signal-to-noise ratio; The model provision support system according to claim 1 .

3. The processor generates a decision tree having the plurality of model classifications as leaf nodes, In the decision tree, a root node or an intermediate node is a comparison between a value obtained for a model factor corresponding to the node and a threshold value corresponding to the model factor, and a next node is determined depending on the result of the comparison; The processor monitors a value for each of the plurality of model factors; The optimal scenario model is a scenario model determined by tracing the decision tree based on the monitored values ​​and thresholds for each model factor. The model provision support system according to claim 1 .

4. The optimal scenario model is the scenario model with the highest query hit rate. The model provision support system according to claim 1 .

5. Each scenario model is a Response Surface Methodology (RSM) model. The model provision support system according to claim 1 .

6. Each scenario model is a model generated based on a scenario set including multiple scenarios that are combinations of a response variable value and one or more explanatory variable values, The processor: By inputting the physical asset data into an asset model for each viewpoint, digital asset data is generated, which corresponds to the physical asset data and is input to a digital twin simulator; Based on the digital asset data, a value range is specified for each variable, and a scenario model is constructed. The model provision support system according to claim 1 .

7. The value of the objective variable is the output value as the calculation result of the digital twin simulation, Explanatory variables are features identified from the data input into the digital twin simulation. The model provision support system according to claim 6.

8. the plurality of model classifications are a plurality of model clusters based on one or more specified criteria; Each model cluster is a collection of one or more scenario models. The model provision support system according to claim 1 .

9. The computer determines a plurality of model classifications, each of which is a classification of the scenario model, based on one or more model factors, which are different one or more factors for a scenario model for the digital twin simulator, identified from the physical asset data or the corresponding digital asset data, and a comparison result between a value for each of the one or more model factors and its threshold value; the computer receives, for each of the plurality of model classifications, an outcome value range from a user for one or more model outcomes that are different one or more outcomes for a scenario model, the outcome value range being a range of values ​​for the model outcome that is based on a heuristic; a computer preparing a scenario model for each of the plurality of model classifications, the scenario model having an outcome value that falls within an outcome value range accepted for the model classification; The computer selects the most appropriate scenario model from the scenario models prepared for each model classification. Model provision support method.

Images