Calculation system and calculation method

Abstract

To provide a calculation system and calculation method capable of appropriately reducing a calculation load from a viewpoint of a sampling rate and accuracy in an environment using a graph of hierarchical assets as a model and capable of contributing to an economic viewpoint.SOLUTION: A calculation system, in an environment based on a digital twin to which assets are hierarchically connected, executes a simulation regarding the assets on the basis of an output specification regarding a sampling rate and target accuracy that is the target accuracy of calculation processing. The calculation system includes a requirement condition calculation section that calculates an output specification to be required from a downstream hierarchy, and a requirement adjustment section that adjusts the received output specification of a hierarchy on the basis of the requirement received from the downstream hierarchy. The requirement condition calculation section calculates an output specification to be required for an upstream hierarchy on the basis of the output specification adjusted by the requirement adjustment section.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a computing system and a computing method. [Background technology]

[0002] From the perspective of DX (digital transformation), there is a technology known as digital twin, which captures various events, conditions, and environments in the real world as data and creates an environment with identical conditions in a digital space. For example, one possible system would be to create a virtual space in which each piece of equipment in a factory is treated as an asset group, update the status of the asset group in the virtual space based on acquired equipment data, and grasp the status of the real world in real time.

[0003] Here, Patent Document 1 describes the processing of computer hardware metrics, which are closely related to each other. Patent Document 1 also describes that "This relates to a computer-implemented system and method for predicting network resource and / or infrastructure needs for an enterprise computer system employing network servers to host resources (applications, data, etc.) required by network users. Based on the prediction, the network resources can be scaled or provisioned accordingly. That is, for example, the state of the network servers can be dynamically adjusted to meet the user's request needs while reducing excess capacity. The prediction technique of the present invention is also applicable to a cloud computing environment. Based on the prediction, the cloud server pool is dynamically scaled, so that the scale of the system meets changing demands and avoids wasting resources when the system load is low."

[0004] Patent Document 2 describes a technology that can perform processing without affecting vehicle operation. Patent Document 2 discloses a technology that performs different processing in communication between a wireless communication module and an in-vehicle device depending on whether the communication is "normal," "when the gateway 18 is heavily loaded or the bus 22 is heavily loaded," or "when the in-vehicle device 12 is heavily loaded." [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2020-504382 A [Patent Document 2] Patent Publication No. 2021-39681 Summary of the Invention [Problem to be solved by the invention]

[0006] For example, when an environment is constructed based on a hierarchical asset graph model, the amount of calculations may increase explosively. However, Patent Document 1 and Patent Document 2 do not disclose a technique for effectively suppressing the calculation load caused by the increase in the amount of calculations in such an environment.

[0007] Therefore, the present invention aims to provide a calculation system and a calculation method that can appropriately reduce the calculation load in terms of sampling rate and accuracy in an environment modeled on a hierarchical asset graph, and contribute from an economic perspective. [Means for solving the problem]

[0008] According to a first aspect of the present invention, there is provided a computing system as follows. This computing system is a system that executes a simulation related to an asset based on output specifications related to a sampling rate and a target accuracy, which is a target accuracy of a computation process, in an environment based on a digital twin in which assets are hierarchically connected. This computing system includes a request condition calculation unit and a request adjustment unit. The request condition calculation unit calculates output specifications requested of a downstream hierarchical level. The request adjustment unit adjusts the output specifications of the received hierarchical level based on a request received from the downstream hierarchical level. Then, the request condition calculation unit calculates output specifications requested of an upstream hierarchical level based on the output specifications adjusted by the request adjustment unit.

[0009] According to a second aspect of the present invention, there is provided the following calculation method. This calculation method is a method for performing a simulation of an asset based on output specifications related to a sampling rate and a target accuracy, which is a target accuracy of calculation processing, in an environment based on a digital twin in which assets are hierarchically connected. This calculation method is performed using a processor and a storage that stores the output specifications. The processor calculates output specifications required of a downstream hierarchical layer, adjusts the output specifications of the received hierarchical layer based on a request received from the downstream hierarchical layer, and calculates output specifications required of an upstream hierarchical layer based on the adjusted output specifications. Effect of the Invention

[0010] According to the present invention, it is possible to provide a calculation system and a calculation method that can appropriately reduce the calculation load in terms of sampling rate and accuracy in an environment modeled on a hierarchical asset graph, and contribute from an economical point of view. Note that problems, configurations, and effects other than those described above will become clear from the following description of the embodiment of the invention. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram for explaining an overview of a calculation system. [Diagram 2]FIG. 2 is a diagram showing an example of a hardware configuration of a computing system. [Diagram 3] FIG. 4 is a diagram showing an example of a data structure for storing information on a simulation model. [Figure 4] FIG. 4 is a diagram showing an example of a data structure for storing information on a simulation model. [Diagram 5] FIG. 4 is a diagram showing an example of a data structure for storing information on a simulation model. [Figure 6] FIG. 13 is a diagram for explaining an example of a simulation mode. [Figure 7] FIG. 4 is a diagram showing an example of a data structure of a process model. [Figure 8] FIG. 4 is a diagram showing an example of output specifications. [Figure 9] FIG. 4 is a diagram showing an example of an input port. [Figure 10] FIG. 4 is a diagram showing an example of an output port. [Figure 11] FIG. 13 is a diagram showing an example of a SIM list. [Figure 12] FIG. 13 is a diagram for explaining an example of an outline of a calculation process according to a process model during a simulation. [Figure 13] FIG. 4 is a diagram showing an example of input and output of a process model. [Figure 14] FIG. 2 is a diagram for specifically explaining input and output data. [Figure 15] FIG. 4 is a diagram showing an example of input and output of a process model. [Figure 16] FIG. 4 is a diagram showing an example of input and output of a data source. [Figure 17] FIG. 2 is a diagram showing an example of input and output of a data sink. [Figure 18] FIG. 2 is a diagram showing an example of data input / output processing in a data source, a process model, and a data sink. [Figure 19] 10 is a flowchart illustrating an example of a process for outputting a delivery reservation. [Figure 20] 11 is a flowchart illustrating an example of a process for outputting a delivery cancellation. [Figure 21]10 is a flowchart illustrating an example of a process for outputting a data event. [Figure 22] 10 is a flowchart illustrating an example of a process for outputting a request notification. [Figure 23] 10 is a flowchart illustrating an example of a process for outputting sensor data. [Figure 24] 11 is a flowchart illustrating an example of a process for outputting a requirement relaxation request. [Diagram 25] 11 is a flowchart illustrating an example of a process for outputting a request notice using a quality compromise condition table. [Figure 26] FIG. 13 is a diagram for explaining an example of a data structure of a quality compromise condition table. [Figure 27] FIG. 11 is a diagram for explaining an example of a process for changing output specifications. [Figure 28] FIG. 4 is a diagram for explaining an example of an image output to a GUI. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment is an example for explaining the present invention, and appropriate omissions and simplifications are made for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings. As examples of various information, the various information may be described using expressions such as "table," "list," and "queue," but the various information may be expressed using data structures other than these. For example, various information such as "XX table," "XX list," and "XX queue" may be expressed as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are mutually interchangeable. When there are multiple components having the same or similar functions, they may be described by using the same reference numerals with different subscripts, or when there is no need to distinguish between these multiple components, the subscripts may be omitted. In the embodiment, a process performed by executing a program may be described. Here, a computer executes the program using a processor (e.g., CPU, GPU), and performs the process defined by the program while using a storage resource (e.g., memory) and an interface device (e.g., communication port), etc. Therefore, the subject of the process performed by executing the program may be the processor. Similarly, the subject of the process performed by executing the program may be a controller, device, system, computer, or node having a processor. The subject of the process performed by executing the program may be a calculation unit, and may include a dedicated circuit that performs a specific process. Here, the dedicated circuit is, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device), etc. The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and a storage resource for storing the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In addition, in an embodiment, two or more programs may be realized as one program, or one program may be realized as two or more programs.

[0013] The computing system of this embodiment will be described with reference to the drawings. This computing system is a system that implements digital twin technology. In this embodiment, as an example, a system will be described that constructs a virtual space for each piece of equipment in a factory, updates the state of assets in the virtual space based on acquired data, and can grasp the state of the real world in real time.

[0014] First, an overview of the calculation system will be described with reference to Fig. 1. The calculation system includes a digital twin system 103 that updates the state of an asset 101 based on sensor data from a sensor 102 that acquires data on factory equipment, thereby realizing a digital twin. Note that the digital twin system 103 may directly acquire data from an actuator 117 (factory equipment) and update the state of the asset 101.

[0015] Here, the asset graph 107 stores data that defines the state of each asset in the digital twin system 103. In this embodiment, the calculation system processes a group of assets defined by a directed graph including assets of three or more hierarchical levels. To explain an example of the connection relationship of assets, in the case where a pump is the target of factory equipment, the group of assets that the calculation system processes may include, for example, an asset indicating a pump, an asset indicating a motor that drives the pump, and an asset indicating an impeller rotated by the motor. And, for example, the pump asset, motor asset, and impeller asset may be arranged in order from the upstream hierarchical level to the downstream hierarchical level.

[0016] In this embodiment, the asset graph 107 stores an ASM 110, an ABM 111, and an AFM 112 as data related to a simulation model when performing a simulation based on the state of an asset. Also, a process model 113 that is referenced in the calculation process is stored. The data (110 to 113) will be described in detail later.

[0017] The computing system may also be connected to a data store 104 in which an RDBMS 108 (software called a relational database management system) is implemented. The data store 104 may store appropriate data, such as time-series data 114 relating to simulation results.

[0018] The computing system may also be connected to an analytics library 105. The analytics library 105 is a library that collects various data used in data analysis. The analytics library 105 is connected to a program library 109, which is a library of programs, and the program library 109 stores, for example, a simulator 115 used to execute a simulation and an estimator 116 used to calculate costs.

[0019] In this example, the above-mentioned sensor 102, digital twin system 103, data store 104, analytics library 105, and actuator 117 are connected by a network 100. The calculation system appropriately inputs and outputs data via the network 100. The calculation system may accumulate data in the data store 104 via the network 100, or may download data from the analytics library 105 and process it. In addition, a user can access the digital twin system 103, the data store 104, and the analytics library 105 by using a GUI 106 (graphics user interface) connected to the network 100, and can input and output various information.

[0020] Next, an example of a hardware configuration of the computing system will be described with reference to FIG.

[0021] In this example, the calculation system 200 includes a memory 201, a network interface 202, a CPU 203, a user interface 204, and a storage 208. The network interface 202 is an interface that connects to the network 100. The user interface 204 is an interface that connects to devices used by a user, such as a display 205, a keyboard 206, and a mouse 207. The above-mentioned GUI 106 can be realized, as an example, by these configurations (205 to 207).

[0022] The CPU 203 is a main body that processes programs in the calculation system 200, and performs appropriate processing using the memory 201, the network interface 202, the user interface 204, and the storage 208. In this embodiment, the storage 208 appropriately stores programs for realizing the digital twin system 103 and data such as the asset graph 107. The CPU 203 can realize the digital twin system 103 by loading data acquired using the network interface 202 and data in the storage 208 into the memory 201 and performing processing.

[0023] The data store 104 and the analytics library 105 may be realized by the storage 208. On the other hand, the data store 104 and the analytics library 105 may be realized by an external computer or the like that is appropriately configured.

[0024] Next, a simulation model used in a simulation executable by the computing system will be described with reference to Figures 3 to 6. Note that the simulation model can be, for example, a model that predicts whether an appropriate result will be output in response to an input.

[0025] First, an example of an ASM will be described with reference to Fig. 3. The ASM 110 stores basic information of a simulation model. The ASM 300 stores ID information 300 of the simulation model and version information 301 of the simulation model.

[0026] The ASM 110 also stores static attribute information 302. The static attribute information 302 stores information related to the static attributes of the simulation model identified by the ID information 301 and the version information 302. Here, the static attributes store data whose state is maintained throughout the execution of the identified simulation model. In this example, the static attribute information 302 includes a variable name 308 and a variable 309.

[0027] The ASM 110 also stores dynamic attribute information 303. The dynamic attribute information 303 stores information related to the dynamic attributes of the identified simulation model. Here, the dynamic attributes store information that is repeatedly generated and discarded throughout the execution of the identified simulation model. In this example, the dynamic attribute information 303 includes variable names 310, input parameters 311, and data set names 312.

[0028] Here, the input parameter 311 indicates a parameter to be input to the variable indicated by the variable name 310. The data set name 312 stores the name of the variable when the variable is treated as a data set.

[0029] Furthermore, the ASM 110 stores ASM link information 304, ABM link information 305, AFM link information 306, and ancestor ASM link information 307. This information (304 to 307) is information that appropriately summarizes information related to the simulation model identified by the ASM ID information 300.

[0030] The ASM link information 304 stores a role name 313 and ASM ID information 314. These data (313, 314) store information on the identified simulation model summarized from the ASM point of view.

[0031] The ABM link information 305 stores a role name 315 and ABM ID information 316. These data (315, 316) store information on the identified simulation model summarized from the perspective of ABM, which will be described in detail later.

[0032] The AFM link information 306 stores a role name 317 and AFM ID information 318. These data (317, 318) store information on the identified simulation model summarized from the viewpoint of AFM, which will be described in detail later.

[0033] Information on the identified simulation models summarized from the viewpoint of version differences is stored in the ancestor ASM link information 307. The ancestor ASM link information 307 stores ASM ID information 319 as this information.

[0034] Next, an example of the ABM will be described with reference to Fig. 4. The ABM 111 stores information related to the operation of a simulation. The ABM 111 stores ID information 400 of the simulation model and version information 401 of the simulation model.

[0035] The ABM 111 includes a predicted operation definition 402. The predicted operation definition 402 stores information on a predicted operation by a simulation model specified by ID information 400 and version information 401. Here, the predicted operation definition 402 stores an output variable name 404, an input variable name 405, and a simulation name 406.

[0036] The output variable name 404 indicates the name of a variable that outputs a value in the execution of the identified simulation model. The input variable name 405 indicates the name of a variable that inputs a value in the execution of the identified simulation model. For example, in the explanation of FIG. 6 described later, the output variable name 404 corresponds to an upstream asset (e.g., a pump), and the input variable name 405 corresponds to a downstream asset (e.g., a motor, a coupling, an impeller). The simulation name 406 stores the name of the simulation to be executed.

[0037] The ABM 111 stores ASM link information 403. The ASM link information 403 stores a role name 407 and ASM ID information 408. These data (407, 408) store information on the identified simulation model summarized from the ASM perspective.

[0038] Next, an example of the AFM will be described with reference to Fig. 5. The AFM 112 stores information on a simulation model in which a problem (abnormality) has occurred in the simulation result. The AFM 112 stores ID information 500 of the simulation model and version information 501 of the simulation model.

[0039] The AFM 112 stores an effect (reason) 502. The effect (reason) 502 stores the reason for the defect in the identified simulation result (information indicating a failure, deterioration, etc.).

[0040] The AFM 112 stores effect (details) 503. The effect (details) 503 indicates specific content of the above-mentioned effect (reason). The effect (details) 503 stores explanation 505, failure mode ID information 506, output variable name 507, input variable name 508, and simulation name 509.

[0041] Description 505 stores information explaining why a simulation has failed. For example, in a case where a simulation predicting whether a pump will reach a predetermined total discharge amount after a predetermined time has passed due to the operation of the pump has failed, description 505 stores information explaining that the reason for this is, for example, a decrease in the pump discharge amount.

[0042] The failure mode ID information 506 stores information for identifying the reason why the simulation failed. A different ID is assigned to each reason for failure.

[0043] An output variable name 507 indicates the name of a variable that outputs a value in the identified simulation model, and an input variable name 508 indicates the name of a variable that inputs the value in the identified simulation model. A simulation name 509 indicates the name of the executed simulation.

[0044] The failure mode 504 is information that appropriately summarizes information on a simulation model related to the simulation model identified by the AFM ID information 500 and the version information 501. The failure mode 504 stores failure mode ID information 510, its description 511, and ASM ID information 512.

[0045] Next, an example of a simulation mode executed by the computing system will be described with reference to Fig. 6. Fig. 6 shows an example of a simulation that predicts whether the total discharge amount reaches a predetermined amount or more after a predetermined time by driving the pump. In this process, the computing system can appropriately use the analytics library 105 (for example, the simulator 115).

[0046] In this simulation, the dynamic variable names include assets such as a pump (110_1), a motor (110_2), a coupling (110_3), and an impeller (110_4). In terms of the connection relationship, the pump is the upstream asset, and the others are downstream assets.

[0047] In the simulation, the asset status of the pump is updated based on the value (e.g., sensor value) input to the variable name of the pump, and as a result, it is predicted that the pump discharge rate will decrease (503_1) and will not reach a predetermined amount. Then, values ​​indicating the decrease in discharge rate are output from the variable name of the pump to the variable names of the motor, coupling, and impeller.

[0048] Then, a value indicating a decrease in the discharge rate is input to the downstream variable name, and deterioration of the motor (504_2), damage to the coupling (504_3), and damage to the impeller (504_4) are predicted. Information indicating the results (abnormalities) of this simulation is appropriately stored in the AFM 112.

[0049] However, in a digital twin, when the connections between assets become complex (for example, there are connections at three or more levels), the overall calculation load may increase explosively. Therefore, a technique for reducing the calculation load will be described below. In this embodiment, this technique is realized by using the above-mentioned process model for each asset.

[0050] The data structure of the process model will be described with reference to Figures 7 to 11. The process model is a model related to output specifications in calculation processing by a processor (in this embodiment, the CPU 203). Data is input and output between process models 113.

[0051] As shown in FIG. 7, the process model 113 stores a PID 700, an ASM_ID 701, SIM information 702, SIM cost statistics 703, a requested processing time 704, a default output specification 800_1, a requested output specification 800_2, a SIM list 705, an input port 706, and an output port 707.

[0052] The PID 700 stores identification information of the process model 113. Different values ​​are stored depending on the process model 113 applied to the asset.

[0053] ASM_ID 701 stores the ID information 300 of the ASM of the simulation model to which the process model is applied.

[0054] SIM information 702 stores appropriate information on the simulation model identified by ASM_ID 701. SIM cost statistics 703 stores statistical values ​​of the cost (computational cost) required for executing the simulation model identified by ASM_ID 701. Requested processing time 704 stores the processing time required for executing the simulation model identified by ASM_ID 701. Note that values ​​such as cost values ​​are calculated using the estimator 116, as an example.

[0055] The default output specification 800_1 stores output specifications in the default state (in other words, when no request is received from another process model). The requested output specification 800_2 stores output specifications requested from another process model.

[0056] Here, the data structure of the output specifications will be described with reference to Fig. 8. The output specifications 800 store information related to arithmetic processing, and store a sampling rate 801 and accuracy 802 (target accuracy) which is the target accuracy of the calculation processing.

[0057] 9, the input port 706 stores a variable definition 900, a source PID 901, and an input queue 902. The variable definition 900 stores a value input from the source process model. The source PID 901 stores information for identifying the source process model. The input queue 902 stores information on the queue of data input from the source process model.

[0058] 10, the output port 707 stores a variable definition 1000, a requested output specification 800_3, output data 1001, and a delivery destination list 1002. The variable definition 1000 stores a value to be output to the delivery destination process model. The requested output specification 800_3 stores an output specification requested to the delivery destination process model. The output data 1001 stores appropriate information to be output.

[0059] The delivery destination list 1002 is a list that compiles delivery destination information 1003. The delivery destination information 1003 stores a delivery destination PID 1004 and a requested output specification 800_4. The delivery destination PID 1004 stores information for identifying a process model of the delivery destination, and the requested output specification 800_4 stores an output specification required for this process model.

[0060] The SIM list 705 stores information on a simulation model handled by a process model identified by the PID 700. As shown in Fig. 11, the SIM list 705 stores SIM specifications 1100, which are information on specific specifications of a simulation model. This SIM specification 1100 stores a name 1101, parameters 1102, and output specifications 800_5. The name 1101 stores the name of the simulation model. The parameters 1102 store the parameters of the simulation model. The output specifications 800_5 stores information on the output specifications in the execution of a simulation.

[0061] The process model has the above-mentioned data structure as an example. Next, an example of an outline of the calculation process according to the process model during the execution of the simulation will be described with reference to FIG. 12. As shown in FIG. 12, sensor data is input from each sensor 102 to the asset graph 107. Then, the simulator 115 executes a simulation according to the information on the simulation model of the process model 113_1 and the output specifications, using the output value of the data source 113_2 based on the sensor data. Note that the data source 113_2 is assigned to each sensor 102.

[0062] As will be described in detail below, data relating to the required output specifications is appropriately input and output from upstream and downstream, and the output specifications of the process model are appropriately updated.

[0063] The data sink 113_3 synchronizes the results of simulations based on the respective process models 113 and outputs the results to the GUI 106 (more specifically, the display 205). A user can check the results of the simulations output from the data sink 113_3 via the GUI 106. Data relating to the results of the simulations may be output from the data sink 113_3 to the actuator 117. The processor of the actuator 117 may then control the operation of the actuator 117 based on the input data relating to the results of the simulation. In addition, although an example of inputting data from the sensor 102 has been described in the example of FIG. 12, the sensor 102 may be replaced with the actuator 117, and data may be acquired from the actuator 117.

[0064] Next, an example of data input / output between process models will be described with reference to FIGS.

[0065] 13, a data event E01 and a request for relaxation C04 are output from an output port 707 of the process model 113 associated with the upstream asset, and these data are input to an input port of the process model associated with the downstream asset. Also, a delivery reservation C01, a delivery cancellation C02, and a request notification C03 are output from an output port of the process model associated with the downstream asset, and these data are input to an input port 706 of the process model 113 associated with the upstream asset.

[0066] 14, a delivery reservation C01 includes a variable name 1400, a delivery destination ID, and a delivery destination port ID to request data output from the upstream side. Also, a delivery cancellation C02 includes a variable name 1403, a delivery destination ID 1404, and a delivery destination port ID 1405 to cancel data output from the upstream side.

[0067] The request notification C03 includes a variable name 1406, a sampling rate 1407, and an output precision 1408 in order to request output specifications from the upstream side. The request relaxation request C04 includes a variable name 1409, a sampling rate 1410, and an output precision 1411 in order to request relaxation of the output specifications from the downstream side.

[0068] A data event E01 is output from upstream to downstream, and includes a variable name 1412 and a value at time 1413. Data regarding a command response R01 may be input / output between process models, and the command response R01 may include success / error information 1414.

[0069] Next, adjustment of output specifications in a simulation will be described with reference to FIG. 15. The request adjustment unit 1501 adjusts the output specifications (i.e., sampling rate and accuracy) based on the output specifications of a request from the upstream (i.e., the request relaxation request C04) input to the process model 113_1. The request adjustment unit 1501 also adjusts the output specifications based on the output specifications of a request from the downstream (i.e., the request notification C03) input to the process model 113_1. Then, the SIM execution unit 1500 executes a simulation with the output specifications adjusted by the request adjustment unit 1501 based on the input from the simulator 115. The output specifications related to the request relaxation request C04 and the request notification C03 are calculated by a request condition calculation unit (not shown). The request relaxation request C04 and the request notification C03 in the process model are also executed by a control unit (not shown).

[0070] Also, the delivery reservation C01, delivery cancellation C02, and request notification C03 may be input from a process model to which the data source 113_2 outputs data. Also, a data event E01 and a request relaxation request C04 may be output to the process model. The data source 113_2 may also perform a process to adjust the calculation load and relax the output specifications. Next, an example of input / output control in the data source 113_2 will be described with reference to FIG. 16. Although not shown in FIG. 16, an input port to which the delivery reservation C01, delivery cancellation C02, and request notification C03 are input may be stored.

[0071] The request adjustment unit 1600 receives a request notification C03 from a process model associated with a downstream asset to which data from the sensor 102 is input. Then, the request adjustment unit 1600 adjusts the output specifications in the data source based on the request notification C03. Then, the control unit 1601 acquires sensor data from the sensor 102 based on the adjusted output specifications, and performs processing to output the sensor data. In addition, the control unit 1601 outputs a request relaxation request C04 downstream.

[0072] Furthermore, a process model that outputs data to the data sink 113_3 may receive a delivery reservation C01, a delivery cancellation C02, and a request notification C03 from the data sink 113_3. A data event E01 and a request relaxation request C04 may be output from the process model to the data sink 113_3. The data sink 113_3 may also perform a process of adjusting the calculation load and relaxing the output specifications. Next, an example of input / output control in the data sink 113_3 will be described with reference to FIG. 17. Although not shown, an output port to which the delivery reservation C01, the delivery cancellation C02, and the request notification C03 are output may be stored.

[0073] The requirement adjustment unit 1700 receives a requirement relaxation request C04 from a process model associated with an upstream asset. Then, the requirement adjustment unit 1700 adjusts the output specifications in the data sink based on the requirement relaxation request C04. Then, the control unit 1702 performs processing based on the adjusted output specifications.

[0074] The visualization unit 1701 generates data to be output to the GUI 106 (more specifically, the display 205) based on the simulation results. An example of the display screen will be described in detail later. The control unit 1702 also outputs a request notification C03 regarding a request for output specifications to an upstream process model based on the quality compromise condition table 1703. The process using the quality compromise condition table 1703 will be described in detail later.

[0075] Next, an example of data input / output processing in the process model 113_1, the data source 113_2, and the data sink 113_3 will be described with reference to Fig. 18. Processing (F_C01) is related to the output of the delivery reservation C01, and in this example, the delivery reservation C01 is output from the process model 113_1 to the data source 113_2. Processing (F_C02) is related to the output of the delivery cancellation C02, and in this example, the delivery cancellation C02 is output from the process model 113_1 to the data source 113_2. Processing (F_E01) is related to the output of the data event E01, and in this example, the data event E01 is output from the process model 113_1 to the data sink 113_3. Processing (F_C03) is related to the output of the request notification C03, and in this example, the request notification C03 is output from the process model 113_1 to the data source 113_2. The process (F_C04, F_C04_2) is related to the output of the request relaxation request C04 and the output of the request notification C3, and in this example, the request relaxation request C04 is output from the process model 113_1 to the data sink 113_3, and the request notification C3 is output from the data sink 113_3 to the process model 113_1. The process (F_Timer) is related to the process of outputting sensor data from the data source 113_2 to the process model 113_1.

[0076] Next, the details of each process shown in Fig. 18 will be described with reference to Fig. 19 to Fig. 27. Note that the main body of the process is a processor (for example, the CPU 203).

[0077] First, an example of the output process of the delivery reservation C01 (F_C01) will be described in detail with reference to Fig. 19. As shown in Fig. 19, the CPU 203 registers a delivery destination ID and a port ID in the output port of the target output variable (STEP 1901). Next, the CPU 203 searches the ABM 111 for input variables for the target output variable (STEP 1902).

[0078] Then, the CPU 203 searches the ASM 110 for the delivery source ID and port ID of the input variables (STEP 1903), and issues a delivery reservation C01 to the target process model (STEP 1904). The CPU 203 repeats the process until all input variables are processed (STEP 1905).

[0079] When performing processing to issue the delivery reservation C01 from the process model 113_1 to the data source 113_2, and when performing processing to issue the delivery reservation C01 from the data sink 113_ to the process model 113_1, the CPU 203 performs similar processing.

[0080] Next, an example of the process (F_C02) of outputting the delivery cancellation C02 will be described in detail with reference to Fig. 20. As shown in Fig. 20, the CPU 203 removes the delivery destination ID and the port ID from the output port of the target output variable (STEP 2001). Then, the CPU 203 judges whether the output port of the target output variable is empty (STEP 2002). If it is judged that the target output variable is empty (YES in STEP 2002), the process proceeds to STEP 2003, otherwise, the process ends. The CPU 203 searches the ABM 111 for an input variable for the target output variable (STEP 2003).

[0081] The CPU 203 searches the ASM 110 for the delivery source ID and port ID of the input variables (STEP 2004), and issues a delivery cancel C02 to the target process model (STEP 2005).The CPU 203 then repeats the process until all variable inputs have been processed (STEP 2007).

[0082] When the process model 113_1 issues a delivery cancellation C02 to the data source 113_2, and when the data sink 113_ issues a delivery cancellation C02 to the process model 113_1, the CPU 203 performs similar processing. When the delivery cancellation C02 is issued to the data source, the input of sensor data related to the target input variable is stopped (S2006).

[0083] Next, an example of the process (F_E01) of outputting the data event E01 will be described in detail with reference to Fig. 21. As shown in Fig. 21, the CPU 203 adds the data event E01 to be output to the input queue. Next, the CPU 203 determines whether the requested output specification 800_2 (sampling rate in this example) is satisfied (STEP 2102), and if the requested output specification 800_2 is satisfied, adds the result to the output data 1001 (STEP 2103).

[0084] The CPU 203 measures the processing time of the simulation and updates the SIM cost statistics 703 (STEP 2104). The CPU 203 also determines whether the SIM cost exceeds the threshold (STEP 2105), and if it determines that the SIM cost exceeds the threshold, issues a requirement relaxation request C04 to the entire distribution list (STEP 2106).

[0085] Further, the CPU 203 judges whether the requested output specification 800_4 is satisfied (STEP 2107), and if the requested output specification 800_4 is satisfied, delivers the result of the simulation as a data event E01 (STEP 2108). The CPU 203 executes this process for the entire delivery list (STEP 2109).

[0086] Next, an example of the process (F_C03) of outputting the request notification C03 will be described in detail with reference to Fig. 22. As shown in Fig. 22, the CPU 203 updates the requested output specification 800_4 (STEP 2201). Next, the CPU 203 updates the requested output specification 800_3 from the requested output specification 800_4 of the entire distribution list in the output port (STEP 2202). Next, the CPU 203 selects the simulator having the smallest output specification 800_5 that satisfies the requested output specification 800_3 as the simulator to be executed (STEP 2203). The CPU 203 repeats the process of STEP 2203 for the entire SIM list (STEP 2204).

[0087] The CPU 203 updates the output specification 800_5 of the selected simulator as the requested output specification 800_3 (STEP 2205). The CPU 203 issues a request notification C03 with the requested output specification 800_3 as an argument (STEP 2206). The CPU 203 repeats the process of STEP 2206 for all the delivery source PIDs (STEP 2207).

[0088] When the process model 113_1 issues the request notification C03 to the data source 113_2, the CPU 203 similarly issues the request notification C3 with the requested output specification 800_3 as an argument. When the request notification C3 is issued to the data source, the sensor measurement period is set using the output specification based on this request notification C03, and measurement starts (STEP 2208).

[0089] Next, an example of the sensor data output process (F_Timer) will be described in detail with reference to Fig. 23. As shown in Fig. 23, the CPU 203 (in other words, the control unit 1601) measures the latest value from the sensor and adds the result to the output data 1001 (STEP 2301). Next, the CPU 203 judges whether the required output specification 800_4 is satisfied (STEP 2302), and if the required output specification is satisfied, delivers the result as a data event E01 (STEP 2203). The CPU 203 performs the processes related to STEP 2302 and STEP 2303 for the entire delivery list (STEP 2304).

[0090] Next, an example of the process (F_C04) of outputting the request relaxation request C04 will be described in detail with reference to Fig. 24. As shown in Fig. 24, the CPU 203 judges whether the sampling rate 1410 satisfies the requested output specification 800_4 (STEP 2401). If the CPU 203 judges that the requested output specification 800_4 is not satisfied, it issues the request relaxation request C04 with the sampling rate 1410 as an argument (STEP 2402). The CPU 203 repeats the processes of STEP 2401 and STEP 2402 for all distribution lists (STEP 2403).

[0091] Next, an example of the process (F_C04_2) of outputting the request notification C3 will be described in detail with reference to Fig. 25. As shown in Fig. 25, the CPU 203 judges whether the sampling rate 1410 satisfies the requested output specification 800_4 (STEP 2501). If the CPU 203 judges that the requested output specification 800_4 is not satisfied, the CPU 203 selects the top condition of the quality compromise condition table 1703 (STEP 2502) and removes the selected item of the quality compromise condition table 1703 (STEP 2503). Then, the CPU 203 issues the request notification C3 based on an appropriate selected item (for example, the next selected item removed) of the quality compromise condition table 1703 (STEP 2504).

[0092] Here, an example of the data structure of the quality compromise condition table used in the process (F_C04_2) will be described with reference to Fig. 26. As shown in Fig. 26, the quality compromise condition table 1703 stores a PID 2600, a variable name 2601, a sampling rate 2602, and an accuracy 2603.

[0093] Next, an example of a process for changing the output specifications will be described with reference to Fig. 27. In this example, an asset 2600, an asset 2601, an asset 2602, and a data sink 2603 are connected from the upstream side.

[0094] 27, in a simulation, when the calculation time for an asset 2600 collapses (i.e., when the calculation resources are insufficient for the calculation cost), a requirement relaxation request C04 is issued from the process model of the upstream asset 2600 to the process model of the downstream asset 2602. Also, a requirement adjustment unit adjusts the output specifications in the process model of the asset 2602 based on the output specifications of the requirement relaxation request C04, and a requirement condition calculation unit calculates requirement conditions (requested output specifications) based on the adjusted output specifications. Then, a control unit outputs the requirement relaxation request C04 from the process model of the asset 2602 to a data sink 2603.

[0095] The quality compromise condition table of the data sink 2603 is referenced, a request notification C3 that satisfies the quality is output to the process model of the asset 2602, and the request adjustment unit updates the request conditions of the output specifications. The request condition calculation unit calculates the request conditions based on the adjusted (updated) output specifications. The control unit then outputs the request notification C3 to the process model of the asset 2600 and the process model of the asset 2601, and the request adjustment unit similarly updates the request conditions of the output specifications for the asset 2600 and the asset 2601.

[0096] In this process, the requirement calculation unit calculates requirement conditions (output specifications) that will not cause a breakdown in calculation time (i.e., will not cause a shortage of calculation resources in the simulation) from the actual calculation amount in the simulation, and the control unit outputs the requirement conditions as a requirement notification C3 or a requirement relaxation request C4.

[0097] Therefore, by changing the output specifications in response to a request for relaxing requirements C04 from the upstream side and in response to a request notification C03 from the downstream side, it becomes possible to adjust the output specifications automatically or at low cost, and it becomes possible to reduce the overall calculation burden. For example, through this process, an asset with a large time constant (for example, an asset that is considered to change slowly, such as the oil temperature or oil deterioration degree in an air compressor) is adjusted not to predict at a high sampling rate (for example, not to predict in seconds). On the other hand, it is also possible to measure the quality of the simulation results by setting output specifications that guarantee quality in the quality compromise condition table.

[0098] The output specifications may be calculated, for example, from domain knowledge, simulation capabilities, and a time constant determined from the simulation results. For example, in the case of the degree of oil deterioration in an air compressor as described above, a daily sampling rate may be specified from a domain name related to the "degree of oil deterioration". In addition, the output specifications may be calculated based on the execution period of the calculation in the simulation as the simulation capabilities. For example, in a simulation in which calculations are performed on a daily basis, a daily sampling rate may be specified. In addition, the sampling rate may be specified according to a time constant based on the simulation results.

[0099] Next, an example of an image output to the GUI will be described with reference to Fig. 28. In this example, from the upstream side, an asset of air compressor input power, an asset of air compressor oil viscosity, an asset of air compressor oil temperature, an asset of air compressor thermal efficiency, and an asset of air compressor oil degradation degree are connected.

[0100] 28, in SIM1, a simulation is performed using parameters from the air compressor input power and parameters from the air compressor oil degradation level as inputs, according to a process model of the air compressor oil viscosity and a process model of the air compressor oil temperature, and the results are output. In addition, in SIM2 and SIM3, a simulation is performed using parameters from the air compressor oil viscosity and the air compressor oil temperature as inputs, according to a process model of the air compressor thermal efficiency and a process model of the air compressor oil degradation level, and the results are output.

[0101] Then, an image showing the calculation resource and the calculation cost is displayed as information about SIM1 to 3. Therefore, the occupancy rate of the calculation time in the simulation is visualized, and by checking this information, the calculation cost in the simulation can be confirmed. Also, an image showing the simulation result (degree of abnormality) for each asset is displayed, and in this embodiment, an image of a graph correlating the degree of abnormality with the sampling rate is displayed. Note that in this example, a circle is displayed with the position of the result of the simulation as the center and the accuracy as the diameter. Therefore, by checking the circle, the range of error in the simulation result can be confirmed. Note that the user may input an adjustment value for the sampling rate, etc. based on the visualized data, and adjust the sampling rate, etc. in each simulation.

[0102] Furthermore, the computing system may use a charge calculation unit (a program, not shown, provided in the computing system) to calculate a charge for using the digital twin service based on the difference between the current simulation interval (i.e., sampling rate) and accuracy (target accuracy) and the simulation interval and accuracy requested by the user. Here, the charge increases as the simulation interval and accuracy requested by the user increase and the difference from the current simulation interval and accuracy increases. Furthermore, when a user requests a simulation interval or accuracy, the charge may be output to the GUI.

[0103] It should be noted that the display unit (a program (not shown) included in the computing system) executes the above-described GUI (more specifically, the display 205) to output the screen.

[0104] Although the embodiments of the present invention have been described above in detail, the present invention is not limited to the above-described embodiments, and various design changes can be made without departing from the spirit of the present invention described in the claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those having all of the configurations described. In addition, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace a part of the configuration of each embodiment with another configuration. [Explanation of symbols]

[0105] 200 Calculation System 201 Memory 202 Network Interface 203 CPU (processor) 204 User Interface 205 Display 208 Storage

Claims

1. A computing system that executes a simulation of an asset based on an output specification regarding a sampling rate and a target accuracy, which is a target accuracy of a calculation process, in an environment based on a digital twin in which assets are hierarchically connected, a requirement calculation unit that calculates output specifications required for a downstream layer; a request adjustment unit that adjusts the output specification of the received hierarchical layer based on the request received from the downstream hierarchical layer, The requirement calculation unit Calculating output specifications to be requested of an upstream hierarchical level based on the output specifications adjusted by the request adjustment unit; 1. A computing system comprising:

2. 2. The computing system of claim 1, The requirement calculation unit Calculating the output specifications based on one of the domain knowledge of the asset, a duration of the calculations in the simulation, and a time constant based on the simulation results; 1. A computing system comprising:

3. 2. The computing system of claim 1, The requirement calculation unit Calculate output specifications that do not cause a shortage of computational resources in the simulation based on the actual computational volume in the simulation.

1. A computing system comprising:

4. 2. The computing system of claim 1, A billing amount calculation unit is provided for calculating a billing amount for using the digital twin service based on a difference between a current output specification for the simulation and an output specification requested by a user.

1. A computing system comprising:

5. 2. The computing system of claim 1, A display unit is provided for displaying an image showing the computational resources and computational costs in the simulation, and an image showing the simulation results for each asset.

1. A computing system comprising:

6. A calculation method for performing a simulation of an asset based on an output specification regarding a sampling rate and a target accuracy, which is a target accuracy of a calculation process, in an environment based on a digital twin in which assets are hierarchically connected, comprising: The calculation method includes: a method implemented using a processor and storage for storing an output specification, The processor, Calculate the output specifications required for the lower hierarchical levels, Adjust the output specifications of the received layer based on the request received from the downstream layer, Calculate the output specifications required for the upper layer based on the adjusted output specifications. A calculation method comprising:

7. 7. The method of claim 6, further comprising: The processor, Calculating the output specifications based on one of the domain knowledge of the asset, a duration of the calculations in the simulation, and a time constant based on the simulation results; A calculation method comprising:

8. 7. The method of claim 6, further comprising: The processor, Calculate output specifications that do not cause a shortage of computational resources in the simulation based on the actual computational volume in the simulation. A calculation method comprising:

9. 7. The method of claim 6, further comprising: The processor, Calculate the charge for using the digital twin service based on the difference between the current output specifications for the simulation and the output specifications requested by the user; A calculation method comprising:

10. 7. The method of claim 6, further comprising: The processor, outputting, to a display, data showing an image indicating the computational resources and computational costs in the simulation, and data showing an image indicating the simulation results for each asset; A calculation method comprising:

Images