Simulation data management system and method

Abstract

The present invention performs more efficient simulation execution.　This simulation data management system that manages data for executing a simulation includes: a registration data creation unit that creates management data, which includes definition data and execution data, from data for use in executing the simulation; a data registration unit that assigns, to the management data created by the registration data creation unit, identifiers for identifying the management data; a simulation data management unit that stores the management data to which the identifiers registered by the data registration unit have been assigned; and a data update determination unit that determines, by using the identifiers, whether the management data created by the registration data creation unit is data updated by editing the management data stored by the simulation data management unit.

Description

Simulation Data Management System and Method

[0001] The present invention relates to a technology for managing simulation data such as a system and equipment used for creating a simulation model, a method for managing data of a planning method, and a method for utilizing the same.

[0002] In a cyber-physical system, the physical space is abstracted as one system, data in the real space is collected by a sensor network or the like, and a solution to a problem is output by simulation or mathematical optimization in the cyber space and reflected in the control of the physical space. In the present application, the process of formulating a plan for control by simulation or mathematical optimization in the cyber space is collectively referred to as plan simulation. Further, system configuration information, data, parameters, etc. for defining simulation conditions are collectively referred to as a simulation model.

[0003] Here, for example, in plan simulation which is an example of simulation, as a plan simulation model, it is necessary to define the configuration of the target system, the specifications and behaviors of components, the flow between components, and the simulation method. For example, in a plan simulator for power operation management, it is necessary to define a system configuration that combines equipment such as solar power generation equipment and storage batteries, and assume that electric power flows between the equipment. Therefore, in order to speed up the creation of a simulation model, it is desired to accumulate and utilize data such as simulation settings and equipment as knowledge.

[0004] As a technology for accumulating and managing knowledge to address this point, Patent Document 1 and Patent Document 2 have been proposed. Patent Document 1 discloses a technology for managing a line combining device models in units of cells and enabling utilization in units of cells. Patent Document 2 discloses a version management technology in units of units constituting software.

[0005] Japanese Patent Application Laid-Open No. 2002-68421 Japanese Patent Application Laid-Open No. 2019-168881

[0006] Running a planning simulation requires definitions of information, system / equipment configuration information, and planning data that align with the planning methodology. Therefore, it is necessary to make the accumulated knowledge usable in units of such information. Furthermore, in planning simulations, the simulation results will be the same if the definitions and data combinations are the same. For this reason, when utilizing knowledge, it is necessary to manage it in a way that allows for identification of identical combinations of knowledge. In other words, it is necessary to properly manage management data related to simulations.

[0007] Patent documents 1 and 2 made it difficult to manage and update simulation models in units of planning method definitions and data, and to manage them so that they can be used in combination units during execution. First, patent document 1 does not disclose the specific content of the interconnection information necessary for updating the managed information or determining whether combinations are possible when used. Second, patent document 2 uses software files and units as the management units and cannot support configurations where units are hierarchical. Furthermore, it does not mention the use of managed files or units.

[0008] Therefore, the present invention aims to enable efficient simulation execution by appropriately managing management data related to simulations.

[0009] To achieve this objective, the present invention classifies management data used in the execution of a simulation into definition data relating to the simulation model and execution data (such as time-series data) used in the execution of the simulation, and manages them using identifier information assigned to each. More specifically, the present invention is a simulation data management system for managing data for the execution of a simulation, comprising: a registration data creation unit that creates management data, which is definition data and execution data, from data used in the execution of the simulation; a data registration unit that assigns identifiers to the management data created by the registration data creation unit to identify each of them; a simulation data management unit that stores the management data to which the identifiers registered by the data registration unit have been assigned; and a data update determination unit that determines, using the identifiers, whether the management data created by the registration data creation unit is data that has been edited and updated from the management data stored in the simulation data management unit.

[0010] Furthermore, the present invention also includes a simulation data management method executed by the simulation data management system, a program that enables the simulation data management system to function as a computer, or a storage medium that stores such a program.

[0011] According to the present invention, management data related to simulations can be properly managed, and simulations can be executed efficiently.

[0012] This is a logical configuration diagram of a simulation data management system in one embodiment of the present invention. This is a diagram showing an example of the hardware configuration of the simulation server 101 in one embodiment of the present invention. This is a diagram showing a scenario definition 301 in one embodiment of the present invention. This is a diagram showing a planning method definition 302 in one embodiment of the present invention. This is a diagram showing a system definition 303 in one embodiment of the present invention. This is a diagram showing planning data 304 in one embodiment of the present invention. This is a diagram showing a flow definition 305 in one embodiment of the present invention. This is a conceptual diagram showing the logical configuration of the system for a planning simulation model in one embodiment of the present invention. This is a diagram showing system data 407 for system 1 in one embodiment of the present invention. This is a diagram showing equipment data 408 for equipment 1 in one embodiment of the present invention. This is a flowchart of the simulation data registration process in one embodiment of the present invention. This is a flowchart of the update determination process in one embodiment of the present invention. This is a flowchart of the ID assignment and registration process in one embodiment of the present invention. This is a flowchart of the related information update process in one embodiment of the present invention. This is a diagram showing an example screen for data editing in one embodiment of the present invention. This is a flowchart of the simulation execution process in one embodiment of the present invention. This is a table showing the simulation execution results in one embodiment of the present invention.

[0013] The following describes one embodiment of the present invention. In this embodiment, the management of management data in a planning simulation will be used as an example of the simulation.

[0014] Figure 1 is a logical configuration diagram of a simulation data management system in one embodiment of the present invention. The simulation data management system of this embodiment includes a simulation server 101 that performs the main processing of this embodiment and a client 111 used by its users.

[0015] The simulation server 101 includes an interface unit 110, a registration data creation unit 102, a data update determination unit 103, a data registration unit 104, a simulation data management unit 105, a data reading unit 106, an execution necessity determination unit 107, a simulation execution unit 108, a simulation execution result management unit 109, and the interface unit 110.

[0016] First, the registration data creation unit 102 creates information for predetermined units (unit-specific information) from the input simulation model. Here, the simulation model includes management data. The information for predetermined units includes definition data and execution data related to the simulation. These will be explained later. The created definition data and execution data are collectively referred to as management data. Here, the input simulation model is an example of data used when running the simulation. Therefore, the registration data creation unit 102 creates management data, which is definition data and execution data, from the data used when running the simulation.

[0017] Furthermore, the data update determination unit 103 determines whether or not unit-specific information, such as definition data and execution data created for each unit, has been updated.

[0018] Furthermore, the data registration unit 104 registers the created unit-specific information to the simulation data management unit 105. At this time, the data registration unit 104 assigns an identifier to each of the created unit-specific pieces of information. The data update determination unit 103 may assign a hash value or the like as an example of an identifier. The simulation data management unit 105 manages data in the simulation, such as management data, and more preferably stores the data.

[0019] Furthermore, the data reading unit 106 reads and outputs data from the simulation data management unit 105 for the use of the registered unit-specific information. The execution necessity determination unit 107 determines whether or not to execute the simulation using the created unit-specific information. If the execution necessity determination unit 107 determines that the simulation must be executed, the simulation execution unit 108 executes the simulation using the unit-specific information.

[0020] Furthermore, the simulation execution result management unit 109 manages the results of the simulation executed by the simulation execution unit 108, and more preferably stores them. In addition, the interface unit 110 connects with the client 111 and receives simulation execution instructions and management data from it.

[0021] Note that the simulation server 101 is an example of a simulation data management device. Therefore, the simulation may be executed on a separate device (for example, a separate server) from the simulation server 101. For this reason, the data reading unit 106, the execution necessity determination unit 107, the simulation execution unit 108, and the simulation execution result management unit 109 can be omitted from the simulation server 101 and provided on a separate device. In this case, the management data 206 can be managed as knowledge.

[0022] Client 111 is operated by the user and connects to the simulation server 101 through the interface unit 110 to perform input and output of various instructions, data, and simulation execution results. In other words, client 111 is used by the user who manages the simulation data and gives instructions for running the simulation. Note that both the simulation server 101 and client 111 can be implemented on a computer. Therefore, each of the above functions is implemented according to the program. For this reason, each part in Figure 1 represents a functional module of the simulation data management program 209 in the simulation server 101. Below, we will describe an example of implementation in which the simulation server 101 is implemented on a computer that functions using the simulation data management program 209.

[0023] Figure 2 shows an example of the hardware configuration of the simulation server 101 in this embodiment. The simulation server 101 has one or more central processing units (CPUs) 201, memory 202, secondary storage 203, input / output interface 204, and network interface 205 (network I / F).

[0024] In memory 202, each functional module of the simulation data management program 209 is loaded as a computer program from a storage medium such as a secondary storage device 203, and each functional module is executed by the CPU 201. In other words, the CPU 201 executes the functions of the registration data creation unit 102 to the data registration unit 104 and the data reading unit 106 to the simulation execution unit 108 shown in Figure 1, according to the simulation data management program 209. Note that the simulation data management program 209 may omit the functional modules of the data reading unit 106, the execution necessity determination unit 107, and the simulation execution unit 108, which are related to the execution of the simulation.

[0025] Furthermore, the secondary storage device 203 can be implemented as a hard disk or the like, and stores data and execution records managed by the simulation data management program 209. In other words, the secondary storage device 203 stores management data 206 and program code 207. Here, program code 207 refers to the program code of the simulation data management program 209. In addition, the description of the simulation execution results has been omitted in Figure 2. These may be stored not within the simulation server 101, but on an external storage device connected to the simulation server 101 via the network 220. Note that the secondary storage device 203 corresponds to the simulation data management unit 105 and the simulation execution result management unit 109 in Figure 1.

[0026] Furthermore, the input / output interface 204 controls input information from input devices such as keyboards and mice, and output information to output devices such as displays. Note that in the simulation server 101, input devices and output devices can be omitted in addition to the input / output interface 204.

[0027] Furthermore, the network interface 205 connects to the client 111 via the network 220. In other words, the network interface 205 corresponds to the interface unit 110 in Figure 1.

[0028] This concludes the explanation of Figure 2, but the simulation server 101 may be implemented as a virtual machine instead of a physical machine.

[0029] Figures 3A to 3E show the structure of management data 206, such as definition data and execution data, managed by the simulation data management program 209 in this embodiment. These are examples of data created by the registration data creation unit 102, and at least one of these is created. In this embodiment, the data that constitutes the planned simulation model, for example, the management data 206, is the scenario definition 301, planning method definition 302, system definition 303, planning data 304, and flow definition 305 shown in Figures 3A to 3D. Here, definition data is data related to the simulation model, for example, the scenario definition 301, planning method definition 302, system definition 303, and flow definition 305. Execution data is data such as time-series data used to execute the simulation, for example, the planning data 304.

[0030] Each of these data sets shares a common structure: a data ID 3011, a history ID 3012, a data name 3013, and a data class 3014. The data ID 3011 is a string that uniquely identifies each data set. The data name 3013 is a string that allows the data to be identified by a human-readable name.

[0031] Furthermore, the history ID 3012 defines the ID of the source data if the data is derived from other data. The data class 3014 is a string that identifies the type of data schema, such as planning method definition, system definition, or planning data. Each data type is described below.

[0032] First, Figure 3A shows the scenario definition 301 in this embodiment. The scenario definition 301 is data that allows the creation of simulation models with different conditions during simulation execution and to execute them together. The scenario definition 301 has a planning method definition ID 3015 that identifies a list of planning method definition IDs to be executed together for the common structure described above and the planning method definition 302 described later.

[0033] Next, Figure 3B shows the planning method definition 302 in this embodiment. In addition to the common structure described above, the planning method definition 302 has a system data ID 3021, a planning data ID 3022, and method information 3023. First, the system data ID 3021 defines the target system. The planning data ID 3022 defines a list of planning data to be used, and method information 3023 is included for each planning method. In this embodiment, the target is a planning method using mathematical optimization, and the method information 3023 defines, for example, the objective function and solver used in optimization.

[0034] Next, Figure 3C shows the system definition 303 in this embodiment. The system definition 303 is data for the system and the equipment that is a component of the system. Here, the system and the equipment have the same data structure. These are the targets in the simulation and are examples of operating entities. For this reason, in addition to the common structure described above, the system definition 303 has a system type 3031, an input flow 3032, an output flow 3033, a connection network 3034, a component 3035, and behavior data 3036.

[0035] First, the system type 3031 indicates whether the operating entity is a system with constituent elements or equipment without elements. Here, equipment can be identified as an element constituting the system by defining its data ID in the list of components 3035 of the system definition 303. This enables a multi-layered structure in which subsystems are defined as components of the system, and equipment is defined as a component of the subsystem.

[0036] Furthermore, the input flow 312 defines a list of flow IDs that identify flows to be input to the system. In addition, the output flow 313 defines a list of flow IDs that identify flows to be output from the system. Here, the flow ID identifies the flow definition 305. The flow definition 305 will be described later using Figure 3E.

[0037] Furthermore, the behavior data 3036 defines the behavior of the equipment based on its specifications, for example, defining the minimum and maximum output power as time-series data, or defining a conversion formula for converting input to output.

[0038] Next, Figure 3D shows the planning data 304 in this embodiment. The planning data 340 is data for when the system inputs and outputs are given in advance, and data related to the behavior of the equipment. Here, the planning simulation performed in this embodiment is a time-series simulation. For this reason, the planning data 304 targets time-series data such as power demand forecasting. In addition to the common structure, the planning data 304 has a system data ID 3041, a date and time 3042, and parameters 3043. The system data ID 3041 is the same as the system data ID 3021. The date and time 3042 indicates the date or the time period for registering the data per unit period. The parameters 3043 define the time-series data.

[0039] Next, Figure 3E shows the flow definition 305 in this embodiment. The flow definition 305 is information about the data flowing through the system and has a common structure as well as units 3051. The units of the unit-specific information are shown.

[0040] Next, the logical configuration of the system in the planning simulation model in this embodiment will be explained using Figures 4A to 4C. First, as shown in the conceptual diagram of Figure 4A, the system in this example includes equipment 1, equipment 2, and equipment 3. Equipment 1 and equipment 2 are connected to power network 1, where the flow is power, and equipment 2 and equipment 3 are connected to power network 2, where the flow is also power.

[0041] Here, multiple inputs and outputs to the equipment may be defined. They are also defined based on mathematical optimization constraints, such as equal input and output quantities. For example, if equipment 1 represents purchased electricity and power cost calculation is performed in the simulation, the output will be power and cost. Regarding the logical configuration of the system shown in Figure 4A, the system data 407 of system 1 is defined as shown in Figure 4B. The data ID and history ID of system data 407 are set by the data update determination unit 103, which is the ID assignment means. In Figure 4B, there is no output for system 1, so there is no output flow. Note that system data 407 is defined in the system definition 303 in Figure 3C.

[0042] Furthermore, the equipment data 408 of equipment 1, which is one of the system components, is defined as shown in Figure 4C. Similar to the system data 407, the equipment data 408 includes a data ID and a history ID, as well as the items shown in Figure 4C. Although the equipment definition data was omitted in Figures 3A to 3E, it can be used in this embodiment. This equipment definition data can be described with a structure similar to the system definition 303 shown in Figure 3C. However, the system type 3031 is replaced with the equipment type. This concludes the explanation of Figures 4A to 4C, and the processing flow of this embodiment will now be described.

[0043] Figure 5 is a flowchart of the simulation data registration process in this embodiment. In this simulation data registration process, the simulation model is used as input and data is registered to the simulation data management unit 105. The steps of this process flow will be explained below using Figure 5. Note that the processing units of each flowchart, including Figure 5, refer to the configuration in Figure 1.

[0044] First, the interface unit 110 receives a registration data file created by the client 111 according to the user's operation (step S501). Also, the registration data creation unit 102 determines whether the registration data file needs to be split (step S502). As a result, if splitting is necessary (Yes), the process proceeds to step S503. If splitting is not necessary (No), the process proceeds to step S504.

[0045] Then, the registration data creation unit 102 splits the registration data file and creates information for each unit (S503). Here, the registration data file describes information in a machine-readable code, such as in the json format. Therefore, the registration data creation unit 102 determines whether splitting is necessary using the keys in the code. Alternatively, the user may be allowed to specify whether it is the entire simulation model or the type of data when registering via the client 111. For example, if the received file matches the definition in terms of data units, such as only the system definition 303 or one type of planning data 304, splitting is not necessary. As described above, the split unit-by-unit information is also referred to as management data 206 and includes definition data and execution data as exemplified in FIGS. 3A to 3E.

[0046] Also, the data update determination unit 103 executes an update determination process for each created unit-by-unit information (step S504). This update determination process includes determining, using an identifier, whether the unit-by-unit information created by the registration data creation unit 102 is data that edits and updates the unit-by-unit information stored in the simulation data management unit 105. The details will be described later using FIG. 6.

[0047] As a result, the data registration unit 104 executes an ID assignment / registration process for the unit-by-unit information for which the update determination process has been performed (step S505). Then, the data registration unit 104 executes a related information update process (S506). This related information update process includes registering each unit-by-unit information (management data 206 such as definition data and execution data) in the simulation data management unit 105. This concludes the description of FIG. 5.

[0048] Next, FIG. 6 is a flowchart of the update determination process in the present embodiment. The update determination process is step S504 in FIG. 5, and for each piece of data to be targeted such as unit-by-unit information, it is derived from the original data and determined whether it has been updated. Hereinafter, each step of the processing flow of the update determination process will be described using FIG. 6.

[0049] First, the data update determination unit 103 determines whether a data ID has been set for the unit-by-unit information that is the target data (step S601). As a result of this, if it is set, the process proceeds to step S602. If it is not set, the process proceeds to step S604.

[0050] Also, the data update determination unit 103 creates a hash value within the range excluding the already set ID (step S602). Here, in creating the hash value, blanks and line breaks that do not affect the meaning of the data are ignored. Note that this hash value is an example of an identifier for the target unit-by-unit information, and a random number other than the hash value may be used. Further, the data update determination unit 103 determines whether the created hash value is different from the existing ID (step S603). Here, regarding the existing ID, the data registration unit 104 stores it in the simulation data management unit 105 when registering the unit-by-unit information. This existing ID is registered as the data ID shown in FIGS. 3A to 3E.

[0051] As a result of step S603, if it is different from the existing ID (Yes), the process proceeds to step S604. If it is the same as the existing ID (No), the process proceeds to step S605. Then, the data update determination unit 103 determines that there is an update for the target data (step S604). Further, the data update determination unit 103 determines that there is no update and discards the target data (step S605). This concludes the description of FIG. 6.

[0052] Next, FIG. 7 is a flowchart of the ID assignment / registration process in the present embodiment. This ID assignment / registration process is step S505 in FIG. 5, and hereinafter, each step of this process will be described using FIG. 7.

[0053] First, the data registration unit 104 sets the generated hash value as the data ID for the data that has been determined to have been updated (step S701). Furthermore, if the data registration unit 104 has an existing ID set as the data ID, it sets that existing ID as the history ID (step S702).

[0054] Furthermore, the data registration unit 104 checks whether data (unit-specific information) with the same data ID has already been registered in the simulation data management unit 105 (step S703). If the result is that it has not been registered (No), the process proceeds to step S704. If it has been registered (Yes), the process proceeds to step S705.

[0055] Then, the data registration unit 104 registers the target data as management data 206 in the simulation data management unit 105 (step S704). Also, the data registration unit 104 discards the target data (step S705). In other words, the target data is not registered. Note that in step S705, the data registration unit 104 may avoid duplicate registration by overwriting the target data in the simulation data management unit 105. This concludes the explanation of Figure 7.

[0056] Next, Figure 8 is a flowchart of the related information update process in this embodiment. This related information update process corresponds to step S506 in Figure 5. The steps of this process will now be explained using Figure 8.

[0057] First, the data registration unit 104 identifies data whose reference identifier, the referenced ID, refers to an existing ID for the data registered in step S704 (step S801). For example, if equipment definition data is updated, the data registration unit 104 identifies the system definition 303 that references the data ID of that equipment definition data in the component.

[0058] Furthermore, the data registration unit 104 updates the referenced ID of the data identified in step S801 to the changed data ID (step S802). The data registration unit 104 also creates a hash value excluding the existing IDs that have been set (step S803). Step S803 is performed in order to treat the identified data as updated data.

[0059] Then, the data registration unit 104 sets the existing ID as the history ID (step S804). The data registration unit 104 also checks if data with the same data ID is already registered in the simulation data management unit 105 (step S805). If the result is not (No), the process proceeds to step S806. If it is (Yes), the process proceeds to step S807.

[0060] Then, the data registration unit 104 registers the target data in the simulation data management unit 105 (step S806). The target data is discarded (step S807). In other words, the target data is not registered. Note that in step S807, the data registration unit 104 may avoid duplicate registration by overwriting the target data in the simulation data management unit 105. After the series of processes, the data registration unit 104 returns the newly assigned ID or the ID that was already registered in the simulation data management unit 105 to the client 111 as a response to the registration request.

[0061] Regarding the system definition 303 and equipment definition, since multiple pieces of equipment included in the system may be updated, the system performs update determination and ID assignment for the referenced equipment data, followed by related information update processing. Similarly, regarding the planning data 304, since the planning method may reference multiple pieces of planning data, the system performs update determination and ID assignment for the referenced planning data 304, followed by the data registration unit 104 performing related information update processing as shown in Figure 8.

[0062] Furthermore, if client 111 creates a simulation model with all new data, including system definitions and equipment definitions, client 111 will either request registration of the individual definitions or request registration of the simulation model as a single scenario.

[0063] Furthermore, when a request is made using individual definitions, specifying the data class and registering it will set a new data ID in the simulation data management program 209 (or the configuration shown in Figure 2) and register it in the simulation data management unit 105. When registration of a simulation model is requested, the scenario data, planning method data, system definition, equipment definition, flow definition, and planning data are individually registered as data in the management unit as a single scenario, and are created as information referenced by each ID.

[0064] Next, we will explain the process of creating a simulation model using the data managed by the simulation data management unit 105.

[0065] Upon receiving a data usage request from client 111, the data reading unit 106 reads data from the simulation data management unit 105 and outputs it to a file or screen. For model creation requests, the data reading unit 106 accepts requests for scenarios, systems, equipment, planning methods, planning data, or flows, using data IDs or data names. In the reading process, the data reading unit 106 reads a list of data for the specified data class, or data that is hierarchically referenced within the data. For example, planning method data is referenced from the scenario definition, and system / equipment definition data is read from the planning method data.

[0066] Here, the data reading unit 106 also reads out the plan data, as it is referencing it. The data reading unit 106 may also accept a specification to read out history data by specifying a particular data ID or data name. In that case, during the data reading process, the data reading unit 106 traces back the history ID contained in the specified data and reads out all related source data.

[0067] Furthermore, client 111 can edit the output data. Client 111 selects the data to be used from the data output from simulation server 101 through processing by simulation data management program 209 and uses it to create a model. Also, if client 111 selects planning method data, simulation server 101 will use the data in units that include the referenced system / equipment definitions and planning data. It is also possible to select and combine multiple data. When using the data, processing such as modifying some parts may be performed, and client 111 will send a registration request to simulation server 101, which has simulation data management program 209, again for the modified data. Here, simulation data management program 209 may provide a function to manage data editing. In this case, an interface is provided for client 111 to select, edit, and register data.

[0068] This interface will now be explained. Figure 9 is a diagram of an example screen for editing data in this embodiment. In Figure 9, the left side of the screen 901 outputs the scenario definition to be managed, the planning method definition referenced by the scenario definition, the system definition referenced by the planning method definition, the planning data definition, and the equipment definition when the system is composed of multiple pieces of equipment. The upper part of the left side of the screen 901 is an example of hierarchical output, and the lower part of the left side of the screen 901 is an example of list output for each definition. The right side of the screen is an example of the user editing screen. The definition selected by the user is output as a system configuration definition diagram 903 and data details 904. After the user creates a new definition or edits a selected definition, they submit a registration request, and the data registration unit 104 saves the definition to the simulation data management unit 105.

[0069] Next, the simulation execution process in the simulation data management program 209 will be described. The client 111 sends a simulation execution request to the simulation server 101 in response to user operations. In response, the simulation server 101, using the simulation execution unit 108, which corresponds to the simulation data management program 209, executes the simulation using the requested planning method definition, its system definition, and planning data. At this time, the execution necessity determination unit 107 may determine whether or not to execute the simulation and may execute the simulation according to this result.

[0070] The simulation execution unit 108 then stores the results of the executed simulation in the simulation execution result management unit 109. Here, in the execution of a planned simulation, if all model definitions and data are the same, the simulation results will be the same. The details of the simulation are described below.

[0071] Figure 10 is a flowchart of the simulation execution process in this embodiment. First, the interface unit 110 receives a simulation execution request from the client 111 (step S1001). Here, the client 111 creates a simulation model and then specifies the scenario definition ID obtained as a response to the registration request to the simulation server 101.

[0072] Furthermore, the execution necessity determination unit 107 determines whether there is an execution result with the same system definition ID as the received scenario definition ID in the simulation execution result management unit (step S1002). If there is (No), the system proceeds to step S1003. If there is no (Yes), the system proceeds to step S1004. If there is an execution result with the same ID, the system retrieves that execution result (S1003).

[0073] Furthermore, the data reading unit 106 reads the data for the scenario definition ID from the simulation data management unit 105 (S1004). The execution necessity determination unit 107 then checks the simulation execution result management unit 109 to see if there are any execution results for the same planning method definition ID referenced in the scenario definition indicated by the read scenario definition ID (S1005). If there are no execution results (Yes), the process proceeds to step S1006. If there are execution results (No), the process proceeds to step S1008.

[0074] Then, the simulation execution unit 108 executes the simulation (step S1006). The simulation execution unit 108 also saves the execution result from step S1006 to the simulation execution result management unit 109 (step S1007). The simulation execution unit 108 retrieves the simulation execution result from the simulation execution result management unit 109 (step S1008).

[0075] Furthermore, the simulation execution unit 108 checks whether the simulation execution results for all the planning method definitions defined in the scenario are available (step S1009). If the results are not available, the process returns to step S1005 and repeats the subsequent processing. If the results are available, the process proceeds to step S1010. In other words, the simulation execution unit 108 returns the simulation execution results to the client 111 via the interface unit 110 (step S1010). This concludes the explanation of Figure 10, and the simulation execution results performed in this process will now be explained.

[0076] Figure 11 is a table showing the execution results of the simulation in this embodiment. The table in Figure 11 contains the execution date and time 1101, the scenario definition ID 1102, the planning method definition ID 1103 and its system definition ID 1104 defined and executed in the scenario, the planning data ID 1105, and the execution result data 1106 for each planning method definition. Records for these are provided for each scenario. This is because the simulation is executed on a scenario-by-scenario basis.

[0077] This concludes the description of this embodiment, but this embodiment also includes the following aspects. As an alternative method in the simulation execution process, the client may, in addition to the scenario definition ID, read a series of simulation model data related to the scenario definition ID from the simulation data management program and attach it to the execution request before sending it. In this case, the simulation data management program does not read the reference ID information from the simulation data management unit, but uses the information provided in the request to check the execution result management unit for results with the same ID and to perform the simulation.

[0078] As another method in the simulation execution process, we will describe the process when a client creates a simulation model by editing data that has been newly created or read from the simulation data management unit, and then executes the simulation without registering it with the data management unit. The client attaches the data of the created simulation model to the execution request and sends it. Since no registration process has been performed, in the case of newly created data, no data ID is assigned, and in the case of reuse, the data ID is the ID that was assigned before editing. The simulation management program receives the execution request and first creates a hash value and assigns or updates an ID for each definition. After that, similar to the flowchart in Figure 10, it checks the execution result management unit to see if there is an execution result with the same ID, and if there is an existing result, it processes it to use it as the execution result.

[0079] Hash values ​​are created starting with the equipment definition, which is a lower-level system component. The equipment definition portion is extracted, and a hash value is created excluding the data ID of the equipment definition. If it differs from an existing data ID, the data ID is updated and the existing data ID is set as the history ID. If it is the same as an existing data ID, it is not updated. After updating the ID of the equipment definition, a hash value is created for the system definition, excluding the data ID portion of the scenario definition. The simulation execution result management unit is checked to see if there are any execution results with the same scenario ID as the created hash value. If there are execution results with the same scenario ID, they are returned as execution results. If there are no results with the same scenario ID, the following processing is performed for each planning method definition included in the received scenario definition. A hash value is created excluding the data ID of the planning method definition. The simulation execution result management unit is checked to see if there are any execution results with the same planning method definition ID as the created hash value. If there are execution results with the same planning method definition ID, they are obtained to be used as execution results. If there are no execution results with the same planning method definition ID, the simulation is executed and the created hash value is registered in the execution result management table as the planning method definition ID.

[0080] As described above, it is possible to define the planning methodology necessary for creating a planning simulation model, manage data in units of system / equipment configuration information and planning data, and create a simulation model using the managed data. Furthermore, by managing the simulation execution results and using the managed execution results to return the results when the model perfectly matches during simulation execution, simulation execution can be made more efficient.

[0081] 101: Simulation server, 102: Registration data creation unit, 103: Data update determination unit, 104: Data registration unit, 105: Simulation data management unit, 106: Data reading unit, 107: Execution necessity determination unit, 108: Simulation execution unit, 109: Simulation execution result management unit, 110: Interface unit, 111: Client, 201: CPU, 202: Memory, 203: Secondary storage device, 204: Input / output interface, 205: Network interface, 206: Management data, 207: Program code, 209: Simulation data management program, 220: Network

Claims

1. A simulation data management system for managing data for executing a simulation, comprising: a registration data creation unit that creates management data which is definition data and execution data from data used when executing the simulation; a data registration unit that assigns identifiers to the management data created by the registration data creation unit to identify each of them; a simulation data management unit that stores the management data to which the identifiers registered by the data registration unit are assigned; and a data update determination unit that uses the identifiers to determine whether the management data created by the registration data creation unit is data that has been edited and updated from the management data stored in the simulation data management unit.

2. A simulation data management system according to claim 1, further comprising a simulation execution unit that performs the simulation using the management data.

3. A simulation data management system according to claim 2, wherein the simulation is a planning simulation for formulating a plan for the operation of a system combining equipment.

4. A simulation data management system according to claim 1, wherein the registration data creation unit creates at least one of the following as management data: a simulation scenario definition, a planning method definition, a system definition, planning data, and a flow definition.

5. A simulation data management system according to claim 1, wherein the data registration unit updates the management data and the identifier referenced by the management data.

6. A simulation data management system according to claim 1, wherein the data registration unit assigns a hash value as the identifier.

7. A simulation data management method for managing data for executing a simulation using a simulation data management system, comprising: a registration data creation unit creating management data which is definition data and execution data from data used when executing the simulation; a data registration unit assigning identifiers to the management data created by the registration data creation unit; a simulation data management unit storing the management data to which the identifiers registered by the data registration unit are assigned; and a data update determination unit determining, using the identifiers, whether the management data created by the registration data creation unit is data updated by editing the management data stored in the simulation data management unit.

8. A simulation data management method according to claim 7, further comprising a simulation execution unit executing the simulation using the management data.

9. The simulation data management method according to claim 8, wherein the simulation is a planning simulation for formulating a plan for the operation of a system combining equipment.

10. A simulation data management method according to claim 7, wherein the registration data creation unit creates at least one of the following as management data: a simulation scenario definition, a planning method definition, a system definition, planning data, and a flow definition.

11. A simulation data management method according to claim 7, wherein the data registration unit updates the management data and the identifier referenced by the management data.

12. A simulation data management method according to claim 7, wherein the data registration unit assigns a hash value as the identifier.

Images