Distributed simulation system, distributed simulation method, and distributed simulation program

Abstract

To adjust, in parallel discrete event simulation using logical time, the advance of the logical time of a transmission simulator to prevent a message from being unnecessarily transmitted, thereby enhancing the execution performance of the Federation.SOLUTION: A distributed simulation system 90 comprises a control unit 401. The control unit 401 includes: a request update period management unit 404 that calculates, on the basis of a request update period during which a reception simulator executes processing, a reception request time at which the reception simulator requests reception of a message next; and a logical time management unit 405 that controls the current time of a transmission simulator on the basis of the reception request time corresponding to the reception simulator.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a distributed simulation system, a distributed simulation method, and a distributed simulation program. [Background technology]

[0002] Parallel Discrete Event Simulation (PDES) using logical time is a method used to simulate large-scale systems (SoS: System of Systems) that connect subsystems via a communication network. PDES controls the progress of logical time (logical time) in the simulation scenario of multiple simulators that simulate each subsystem. By controlling logical time, each simulator can ensure that it has enough logical time to execute simulation processing in parallel with other simulators. As a result, the processing performance of the entire simulation is improved. Furthermore, when exchanging simulation results between simulators, PDES stops the progress of logical time until communication of the simulation results is complete, thereby preventing inconsistencies in the simulation content of each simulator.

[0003] The logical time progression algorithm in PDES has been incorporated into M&S (Modeling and Simulation) standards, such as HLA (High Level Architecture) shown in Non-Patent Documents 1 and 2. HLA follows the rules that must be observed by distributed simulation systems and each simulator constituting the distributed simulation system, as defined in Non-Patent Document 1. Furthermore, HLA allows the use of three types of algorithms: the Time Step method, the Event Based method, and the Optimistic method, in RTI (Run-Time Infrastructure), which is distributed simulation infrastructure software standardized in Non-Patent Document 2. In this specification, a point in time in logical time progression is referred to as logical time, current time, permitted time, etc. "Logical time" may also be simply referred to as "time." Furthermore, the amount of time elapsed from one logical time to another in logical time progression is referred to as elapsed time. When calculating logical time in the logical time progression algorithm, logical time cannot be added to logical time. On the other hand, logical time can be advanced by adding elapsed time to logical time. In the following description of the logical time progression algorithm, in an algorithm that performs logical time progression such as updating logical time based on a fixed logical time period, the logical time period corresponds to a period corresponding to elapsed time. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] IEEE Standard for Modeling and Simulation(M&S) High Level Architecture(HLA)-Framework and Rules(IEEE Std 1516-2010), IEEE Computer Society, 2010 [Non-patent document 2] IEEE Standard for Modeling and Simulation(M&S) High Level Architecture(HLA)-Federate Interface Specification(IEEE Std 1516.1-2010), IEEE Computer Society, 2010 Summary of the Invention [Problem to be solved by the invention]

[0005] When the Time Step method is used in PDES, there is a problem that messages are sent unnecessarily because there is no function to adjust the logical time progress of the sending simulator based on the receive request time, which is the time when the receiving simulator next requests to receive a message, resulting in a decrease in the execution performance of the Federation. The present disclosure aims to prevent unnecessary message transmission in a parallel discrete event simulation using logical time by adjusting the logical time progress of a sending simulator based on a receiving request time. [Means for solving the problem]

[0006] The distributed simulation system according to the present disclosure comprises: a transmitting simulator that transmits messages, and one or more receiving simulators that periodically receive messages from the transmitting simulator and perform processing using the received messages; A distributed simulation system that executes parallel discrete event simulation using logical time, comprising: a request update period management unit that calculates a reception request time, which is the time when the target reception simulator will next request message reception, based on a request update period, which is the period during which the target reception simulator requests message reception, when each of the one or more reception simulators is a target reception simulator; a logical time management unit that controls the current time of the transmitting simulator based on a requested reception time corresponding to each of the one or more receiving simulators; A control device comprising: Equipped with. [Effects of the Invention]

[0007] According to the present disclosure, a request update period management unit calculates a requested reception time based on the request update period, and a logical time management unit controls the current time of the transmission simulator based on the requested reception time. Therefore, the transmission simulator can transmit a message to the reception simulator based on the requested reception time, i.e., can transmit a message to the reception simulator at the time requested by the reception simulator. Therefore, according to the present disclosure, in a parallel discrete event simulation using logical time, it is possible to prevent unnecessary message transmission by adjusting the logical time progression of the transmission simulator based on the requested reception time. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an overview of a distributed simulation system 90. [Figure 2] FIG. 1 is a diagram illustrating Federate 102. [Figure 3] A diagram explaining the problems with the conventional Time Step method. [Figure 4] FIG. 1 is a diagram showing an example of the configuration of a distributed simulation system 90 according to a first embodiment. [Figure 5] FIG. 4 is a diagram showing an example of the hardware configuration of a control device 401 according to the first embodiment. [Figure 6] FIG. 2 is a diagram for explaining the operation of the distributed simulation system 90 according to the first embodiment. [Figure 7] FIG. 2 is a diagram for explaining the operation of the distributed simulation system 90 according to the first embodiment. [Figure 8] 4 is a flowchart illustrating an algorithm for calculating a permission time according to the first embodiment. [Figure 9] FIG. 2 is a diagram for explaining the operation of the distributed simulation system 90 according to the first embodiment. [Figure 10]FIG. 2 is a diagram for explaining the operation of the distributed simulation system 90 according to the first embodiment. [Figure 11] FIG. 2 is a diagram for explaining the operation of the distributed simulation system 90 according to the first embodiment. [Figure 12] FIG. 10 is a diagram showing an example of the hardware configuration of a control device 401 according to a modification of the first embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] In the description of the embodiments and drawings, the same elements and corresponding elements are given the same reference numerals. The description of elements given the same reference numerals will be omitted or simplified as appropriate. Arrows in the drawings mainly indicate the flow of data or the flow of processing. Furthermore, "unit" may be read as "function," "circuit," "step," "procedure," "process," or "circuitry" as appropriate.

[0010] Below, we will first explain HLA (High Level Architecture), then explain Federate 102 in which logical time progression is controlled by RTI (Run-Time Infrastructure), and then explain the operation of the logical time progression algorithm using the Time Step method.

[0011] First, the HLA will be explained. Fig. 1 shows an example of the configuration of a distributed simulation system 90. The distributed simulation system 90 is a distributed simulation system based on the HLA, and as shown in Fig. 1, includes a Federation 101, a Federate 102, an RTI 103, and an FOM (Federation Object Model) 104. Federation 101 refers to the entire distributed simulation system 90 . The Federate 102 is a federate that refers to each simulator that constitutes the Federation 101 . The RTI 103 is distributed simulation infrastructure software that controls the execution and communication of the Federation 101 and each Federate 102 . The FOM 104 is an FOM that defines messages and the like communicated by each Federate 102 belonging to the Federation 101 in the HLA. The FOM 104 is definition data referenced by each Federate 102 and the RTI 103. Each Federate 102 registers with the RTI 103 publication (Publish in the HLA standard) or subscription (Subscribe in the HLA standard) for messages defined in the FOM 104. The RTI 104 controls message communication between the Federates 102 based on the publication-subscription relationship registered for each message with the Federate 102.

[0012] Next, the Federate 102, whose logical time progress is controlled by the RTI 103, will be described with reference to FIG. The Time-regulating Federate 201 is a Federate 102 that affects the logical time progression in the Federation 101. The logical time at which the Time-regulating Federate 201 is performing simulation processing (hereinafter referred to as the current time) and messages that the Time-regulating Federate 201 sends to other Federates 102 affect other Federates 102 that are affected by the logical time progression. Messages sent by the Time-regulating Federate 201 are timestamped with the logical time at which the message becomes valid. The timestamp indicates a time later than the time at which the Time-regulating Federate 201 to which the timestamp was assigned was sent.

[0013] The Time-constrained Federate 202 is a Federate 102 that is affected by the logical time progression in the Federation 101. The Time-constrained Federate 202 is controlled by the RTI 103 so that it receives all messages with timestamps indicating the times from the current time to the next time in the period from the current time of the Time-constrained Federate 202 to the next time. After advancing to the next time, the Time-constrained Federate 202 executes a simulation process at that time.

[0014] Therefore, the RTI 103 controls the current time of the Time-regulating Federate 201 so that it is equal to or greater than the current time of another Time-constrained Federate 202. A time equal to or greater than a certain time is a time after that certain time. The RTI 103 also controls the current time of the Time-constrained Federate 202 so that it is equal to or less than the time indicated by the timestamp attached to a message that the Time-regulating Federate 201 may send.

[0015] The parameter managed by the RTI 103 to control the current time in each Federate 102 is called GALT (Greatest Available Logical Time). GALT is calculated by [Equation 1] for each Time-constrained Federate 202. Lookahead in [Equation 1] is a parameter registered in the RTI 103 to guarantee the minimum value of the timestamp attached to messages sent by the Time-regulating Federate 201, and corresponds to elapsed time. Lookahead is used to notify the RTI 103 that messages with a timestamp indicating a time equal to or less than {current time + Lookahead} will not be sent.

[0016] [Formula 1] GALT=min((current time of a Time-regulating Federate201 other than your own) + (Lookahead of that Time-regulating Federate201))

[0017] It is possible to set the Lookahead value to 0, but as mentioned above, the time indicated by the timestamp is a time in the future relative to the current time. Therefore, when the Lookahead value is 0, an abstract constant called Epsilon is used instead of Lookahead when calculating elapsed time within the RTI103. Epsilon is a value used by RTI 103 in calculating elapsed time, and is the smallest value that can be expressed in a variable of a programming language. Epsilon is a constant defined as a common specification for the entire Federation 101 when Federate 102 is implemented using a programming language. As a specific example, when an integer type is used as the type of a variable indicating elapsed time in Federation 101, "1", which is the smallest resolution of an integer value, is generally defined as Epsilon.

[0018] The situations of the Time-regulating Federate 201 and the Time-constrained Federate 202 in FIG. 2 will be described. 2, the current time of both the Time-regulating Federate 201 and the Time-constrained Federate 202 is T1. The current time of the Time-regulating Federate 201 only needs to be equal to or greater than the current time of the other Time-constrained Federates 202, so currently the Time-regulating Federate 201 can freely advance its current time.

[0019] In Figure 2, the Lookahead of Time-regulating Federate 201 is 2, so Time-regulating Federate 201 cannot send a message with a timestamp indicating a time smaller than T3 when the current time of Time-regulating Federate 201 is T1. Therefore, Time-regulating Federate 201 sends three messages: msg@T3, msg@T4, and msg@T5. msg@T3 indicates a message with a timestamp indicating T3. msg@T4 and msg@T5 are each the same as msg@T3.

[0020] 2, the current time of the Time-constrained Federate 202 is T1. The Time-constrained Federate 202 cannot receive msg@T3, msg@T4, and msg@T5 when the current time of the Time-constrained Federate 202 is T1. Therefore, the RTI 103 suspends delivery of these messages to the Time-constrained Federate 202. Also, at this point, the GALT of the Time-constrained Federate 202 is T3, which is {current time + Lookahead} of the Time-regulating Federate 201. When advancing to the next time, the Federate 202 can advance the current time up to T3. When the current time of the Time-constrained Federate 202 advances to T3, the Time-constrained Federate 202 can receive msg@T3, the delivery of which has been suspended by the RTI 103.

[0021] There are four operation patterns for each Federate 102: (a) Time-regulating only. (b) Time-constrained only. (c) Time-regulating and time-constrained. (d) It is neither time-regulating nor time-constrained and does not involve logical time progression. Each Federate 102 can notify the RTI 103 of which of the four operation patterns the operation pattern of each Federate 102 is. Of the four operation patterns, (a), (b), and (c) are collectively referred to as logical time progression types.

[0022] Next, we will explain the operation of the logical time progression algorithm based on the Time Step method, which is executed and controlled by the RTI 103. The Time Step method is an algorithm targeted at the Time-constrained Federate 202, which repeatedly executes simulated processing at a fixed logical time period. Time when Federate 202 executes simulated processing in logical time period 3 The operation of the Step method will now be described.

[0023] (1) In the state shown in FIG. 2, the Time-constrained Federate 202 requests the RTI 103 to advance time to T4, which is the next time to advance, based on the logical time period 3. (2) In the state shown in FIG. 2, the GALT of the Time-constrained Federate 202 is T3, so the RTI 103 suspends the time advance to T4. (3) When the GALT of the Time-constrained Federate 202 becomes larger than T4 due to the Time-regulating Federate 201 advancing to T2 or later, the RTI 103 allows the Time-constrained Federate 202 to advance to T4. Then, when the current time of the Time-constrained Federate 202 advances to T4, the Time-constrained Federate 202 can receive each of the msg@T3 and msg@T4 whose delivery was suspended by the RTI 103.

[0024] Here, we will also provide additional information on the Event-Based method and Optimistic method by RTI103. The Event-Based method is an algorithm that executes simulation processing by determining the current time according to the time corresponding to a received message, rather than a fixed logical time period. The RTI 103 permits the Time-constrained Federate 202 to advance to the smaller of the GALT and the minimum value of the time corresponding to each message received by the Time-constrained Federate 202, rather than the time requested by the Time-constrained Federate 202 to advance time. The difference from the Time Step method is that the operations shown in (2) and (3) are different, and the Time-constrained Federate 202 is permitted to advance in time to T3, which is the GALT, instead of T4, at which it requested time advance. Then, when the current time of the Time-constrained Federate 202 advances to T3, the Time-constrained Federate 202 can receive msg@T3.

[0025] The Optimistic method is an algorithm that allows time to progress optimistically or speculatively, and allows the Time-constrained Federate 202 to receive a message with a timestamp indicating a time in the future than the time to which time progress is permitted. The difference from the Time Step method is the operations shown in (2) and (3), where Time-constrained Federate 202 is permitted to advance in time to T3, which is the GALT, rather than to T4, which it requested to advance in time. When the current time of Time-constrained Federate 202 advances to T3, Time-constrained Federate 202 can receive not only msg@T3, but also msg@T4 and msg@T5, which correspond to times later than T3. Furthermore, Time-constrained Federate 202 can perform simulation processing at times later than T3 using msg@T4 and msg@T5, which are given timestamps indicating times later than T3, which has become the current time. However, as a result of future time advancement by Time-constrained Federate 202, there is a possibility that another message with a timestamp indicating a time later than T3 will be sent. Therefore, it may be necessary to re-execute the simulation process at a time later than the permitted time T3. If the time advancement by Time-constrained Federate 202 reveals that the simulation process was incorrect, Time-constrained Federate 202 must cancel the results of the simulation process.

[0026] Here, we will explain the problems with the conventional Time Step method. As mentioned above, the Time Step method is an algorithm targeted at Federate 102, which repeatedly executes simulated processing at a fixed time period in logical time. The Time Step method is generally used to simulate sensor systems that perform monitoring at a fixed period.

[0027] FIG. 3 shows a specific example for explaining the problems of the conventional Time Step method. FIG. 3 shows the logical time progression in a Federation 101 consisting of Federate #1 and Federate #2 that simulate periodic monitoring using sensors, and Federate #3 that simulates a moving target observed by the sensors. Each of Federate #1, Federate #2, and Federate #3 is a Federate 102. Generally, there are few cases of Federates that only send or receive messages, and most Federates perform both message sending and receiving. However, in FIG. 3, to make the operation and problems of the Time Step method easier to understand, each of Federate #1 and Federate #2 is a Time-constrained Federate 202 that only receives messages, and Federate #3 is a Time-regulating Federate 201 that only sends messages. Note that the Lookahead of Federate #3 is set to 1.

[0028] In Fig. 3, Federate #1 and Federate #2, which simulate sensors, operate at a logical time period corresponding to the observation period of the sensor they simulate. Specifically, Federate #1 operates at a period of Δt = 3, and Federate #2 operates at a period of Δt = 2. Federate #3 operates at a period of Δt = 1 (the reason for this will be explained later), and transmits a message indicating the position information of the moving target to be observed, to the sensor simulated by Federate #1 and Federate #2, with a timestamp based on the current time and Lookahead (represented as "msg3@(timestamp)" in Fig. 3). The current time of Federate#1 is T3. Federate#1 starts the simulation from T0, and receives msg3@T1, msg3@T2, and msg3@T3 before the time of Federate#1 progresses from T0 to T3. Note that reception of msg3@T4 is pending until the next time progress. The current time of Federate#2 is T2. Federate#2 starts the simulation from T0 and has executed the simulation at T2 in the past, and has received msg3@T1 and msg3@T2 before the time of Federate#2 progresses from T0 to T2.

[0029] First, Federate#3 has the following problem.

[0030] (Task 1) Federate #3 needs to send messages in accordance with the respective logical time periods of Federate #1 and Federate #2, which operate on the premise of receiving periodic messages. Furthermore, Federate 102, which simulates a sensor, may dynamically change its logical time period depending on the status and operating mode of the simulated sensor. Including such cases, Federate 102 needs a function to communicate and adjust the logical time period of each Federate 102 before the start of the simulation and during the simulation. However, since this function is not standardized in standards such as HLA, this function must be considered for each application. Note that a common method for determining the logical time period of a Federate 102 that transmits a message in accordance with the logical time period of a Federate 102 that needs to receive a message, without communicating and adjusting the logical time periods of each Federate 102, is to set the greatest common divisor of the logical time periods of all Federates 102 that need to receive a message as the logical time period of the Federate 102 that transmits the message. Figure 3 shows a situation in which the logical time period of Federate #3 is determined using such a common method, and shows a situation in which Federate #3 operates with Δt=1, which is the greatest common divisor of the logical time periods of Federate #1 and Federate #2. A Federation 101 in which a Federate 102 that determines its logical time period using such a common method participates has the following problems.

[0031] (Task 2) Federate #3 periodically executes a simulation process at Δt=1. Therefore, compared to the other Federates 102, Federate #1 and Federate #2, the logical time of Federate #3 progresses more slowly. Therefore, when Federate #1 and Federate #2 each request time advancement, the period during which time advancement is suspended is extended because GALT updates are not progressing. In other words, in a distributed simulation system 90 that aims to achieve high performance by having each Federate 102 operate in parallel, the period during which parallel processing cannot be executed is extended, resulting in a problem of a decrease in the processing efficiency of the entire distributed simulation system 90 and a deterioration in the execution performance of the Federation 101.

[0032] (Assignment 3) A Federate 102, such as Federate #3, which operates with a logical time period that is the greatest common divisor of the logical time periods of other Federates 102, executes simulated processing and transmits messages with a logical time period that is shorter than the logical time periods of Federates 102 that receive messages, such as Federate #1 and Federate #2. Therefore, a Federate 102 that receives a message receives a message with a timestamp indicating a time that the Federate 102 does not need. As a specific example, in the simulated processing in Federate #1, msg@T1, msg@T2, and msg@T4, whose reception is pending in the situation shown in Figure 3, are all unnecessary. Also, in the simulated processing in Federate #2, msg@T1 and msg@T3 are all unnecessary. When Federate #1 and Federate #2 receive an unnecessary message during the simulation process, they discard the received message. Here, the larger the difference between the logical time period of the sending Federate and the logical time period of the receiving Federate, the more unnecessary messages the receiving Federate may receive, and therefore the processing load required for receiving and discarding messages in the receiving Federate increases. 3, msg@T1 sent by Federate#3 is an unnecessary message for any receiving Federate. Therefore, the simulation process performed by Federate#3 at T0 to generate msg@T1 is essentially unnecessary, and there is a possibility that the processing load on Federate#3 increased unnecessarily. Here, the greater the difference between the logical time period of the sending Federate and the logical time period of the receiving Federate, the more frequently the sending Federate may generate unnecessary messages. In this way, when the greatest common divisor of the logical time periods of the receiving Federates is set as the logical time period of the sending Federate, the processing load on each Federate 102 increases unnecessarily, which causes a problem of deteriorating execution performance of the Federation 101.

[0033] Embodiment 1 Hereinafter, this embodiment will be described in detail with reference to the drawings. This embodiment aims to realize a function for adjusting logical time periods between simulators that can be generally used regardless of application by controlling the time progress of a Time-regulating Federate in an RTI that controls the logical time progress of a Federate and message communication in a PDES. Here, the Time-regulating Federate transmits messages based on a request message update period registered by a Time-constrained Federate that requires periodic message reception. Furthermore, this embodiment aims to suppress unnecessary message reception in the Time-constrained Federate by calculating a timestamp required by the Time-constrained Federate based on the request update period registered by the Time-constrained Federate, and selecting and delivering only messages with the calculated timestamp to the Time-constrained Federate.

[0034] ***Configuration Description*** FIG. 4 shows an example of the configuration of a distributed simulation system 90 according to this embodiment. The distributed simulation system 90 includes a control device 401 and multiple simulators 407. The distributed simulation system 90 executes parallel discrete event simulation using logical time, implementing a parallel simulation method. The distributed simulation system 90 employs a logical time progression method, and multiple simulators 407 are connected to execute parallel processing, thereby achieving efficient logical time progression when executing one simulation scenario. The control device 401 implements a simulation execution platform function.

[0035] The simulator 407 is a simulator equivalent to the Federate 102 . Here, the distributed simulation system 90 can also be considered to include a transmitting simulator and one or more receiving simulators. The transmitting simulator is a simulator 407 that transmits messages. Each receiving simulator is a simulator 407 that periodically receives messages from the transmitting simulator and executes processing using the received messages. Note that the receiving simulator may have a function to transmit messages, and the transmitting simulator may have a function to receive messages. Each of the transmitting simulator and the receiving simulator is appropriately determined based on the message transmission and reception processing performed by each simulator 407. The current time of each of the one or more receiving simulators is typically equal to or less than the current time of the transmitting simulator. Each of the one or more receiving simulators is, as a specific example, a Time-constrained Federate in HLA. As a specific example, the transmitting simulator is, as a Time-regulating Federate in HLA. The transmitting simulator uses an Enable interface in HLA. An optional argument for Time Regulation may request the control device 401 to control the time progression of the transmission simulator based on a requested update period.

[0036] The control device 401 corresponds to the RTI in the HLA, and includes an interface unit 402, a publication / subscription management unit 403, a request update period management unit 404, a logical time management unit 405, and a transmission / reception message management unit 406. The control device 401 executes processing that is an extension of the conventional Time Step method.

[0037] The interface unit 402 has a function of connecting with each simulator 407 .

[0038] The publication / subscription management unit 403 manages the relationship between the sending simulator and the receiving simulator for each message based on the publication and subscription of messages registered from each simulator 407 .

[0039] The request update period management unit 404 manages the request update period for a message, which is a request update period requested by the simulator 407 that has registered a subscription to the message. As a specific example, when each of one or more reception simulators is a target reception simulator, the request update period management unit 404 calculates a request reception time corresponding to the target reception simulator based on the request update period corresponding to the target reception simulator. The request update period corresponding to the target reception simulator is the period at which the target reception simulator requests message reception. The request reception time corresponding to the target reception simulator is the time at which the target reception simulator next requests message reception. As a specific example, the request update period management unit 404 calculates the request reception time corresponding to the target reception simulator based on the request update period registration time corresponding to the target reception simulator and the request update period corresponding to the target reception simulator. The request update period registration time corresponding to the target reception simulator is the time at which the request update period corresponding to the target reception simulator was registered in the control device 401. As a specific example, the request update period and the request update period registration time are notified to the control device 401 by optional arguments of the Subscribe Object Class Attribute and the Subscribe Interaction Class, which are interfaces in the HLA.

[0040] The logical time management unit 405 manages the logical time progression type, current time, GALT, and Lookahead of each simulator 407. Furthermore, the logical time management unit 405 controls the current time of the transmission simulator based on the requested reception times corresponding to each of the one or more receiving simulators. As a specific example, the logical time management unit 405 permits the transmission simulator to advance the current time of the transmission simulator to a time corresponding to a minimum requested reception time, which is the smallest time among the requested reception times corresponding to each of the one or more receiving simulators.

[0041] The transmission / reception message manager 406 manages messages transmitted and received by each simulator 407. Specifically, the transmission / reception message manager 406 transmits a message generated by a process executed by a transmission simulator at a time corresponding to a minimum reception request time to a reception simulator corresponding to the minimum reception request time. Furthermore, the transmission and reception message management unit 406 may execute filtering processing to not send to the target reception simulator messages corresponding to times that are greater than the requested update period registration time and less than the time obtained by adding the requested update period corresponding to the target reception simulator to the requested update period registration time. As a specific example, the filtering processing is realized by the transmission and reception message management unit 406 executing Reflect Attribute Values ​​and Receive Interaction, which are interfaces in HLA, to send messages to the target reception simulator only for messages that have a request timestamp that indicates the requested reception time corresponding to the target reception simulator.

[0042] In the following description, RTI in HLA is used as a specific example of the control device 401, and Federate in HLA is used as a specific example of the simulator 407.

[0043] 5 shows an example of the hardware configuration of control device 401 according to this embodiment. Control device 401 is made up of a computer. Control device 401 may also be made up of multiple computers.

[0044] As shown in the figure, the control device 401 is a computer including hardware such as a processor 11, a memory 12, an auxiliary storage device 13, an input / output IF (Interface) 14, and a communication device 15. These pieces of hardware are appropriately connected via signal lines 19.

[0045] The processor 11 is an integrated circuit (IC) that performs arithmetic processing and controls the hardware of the computer. Specific examples of the processor 11 include a central processing unit (CPU), a digital signal processor (DSP), or a graphics processing unit (GPU). The control device 401 may include a plurality of processors that take the place of the processor 11. The plurality of processors share the role of the processor 11.

[0046] The memory 12 is typically a volatile storage device, specifically a random access memory (RAM). The memory 12 is also called a primary storage device or a main memory. Data stored in the memory 12 is saved in the secondary storage device 13 as needed.

[0047] The auxiliary storage device 13 is typically a non-volatile storage device, and specific examples thereof include a ROM (Read Only Memory), an HDD (Hard Disk Drive), or a flash memory. Data stored in the auxiliary storage device 13 is loaded into the memory 12 as needed. The memory 12 and the auxiliary storage device 13 may be integrated into one unit.

[0048] The input / output IF 14 is a port to which an input device and an output device are connected. A specific example of the input / output IF 14 is a USB (Universal Serial Bus) terminal. Specific examples of the input device are a keyboard and a mouse. A specific example of the output device is a display.

[0049] The communication device 15 is a receiver and a transmitter, and is, for example, a communication chip or a network interface card (NIC).

[0050] Each unit of the control device 401 may use the input / output IF 14 and the communication device 15 as appropriate when communicating with other devices.

[0051] The auxiliary storage device 13 stores a distributed simulation program. The distributed simulation program is a program that causes a computer to realize the functions of each unit included in the control device 401. The distributed simulation program is loaded into the memory 12 and executed by the processor 11. The functions of each unit included in the control device 401 are realized by software.

[0052] Data used when executing the distributed simulation program and data obtained by executing the distributed simulation program are stored in a storage device as appropriate. Each part of the control device 401 uses a storage device as appropriate. As a specific example, the storage device comprises at least one of the memory 12, the auxiliary storage device 13, a register in the processor 11, and a cache memory in the processor 11. Note that the terms "data" and "information" may have the same meaning. The storage device may be independent of the computer. The functions of the memory 12 and the auxiliary storage device 13 may be realized by other storage devices.

[0053] The distributed simulation program may be recorded on a computer-readable non-volatile recording medium. Specific examples of the non-volatile recording medium include an optical disk and a flash memory. The distributed simulation program may be provided as a program product.

[0054] ***Explanation of Operation*** The operation procedure of the distributed simulation system 90 corresponds to a distributed simulation method, and the program that realizes the operation of the distributed simulation system 90 corresponds to a distributed simulation program.

[0055] Fig. 6 shows an example of operation in the initial state of a parallel simulation system using a control device 401. In Fig. 6, each of Federate #1 and Federate #2 is a Federate 102 that simulates the detection of a moving target based on a message of position information of the moving target received from an external Federate 102. Each of Federate #1 and Federate #2 calculates a requested progress time from its own logical time period in the same way as the Time Step method, in accordance with the observation period of the sensor that it respectively simulates, with Federate #1 at Δt = 5 and Federate #2 at Δt = 3, and requests the control device 401 to progress to the calculated requested progress time, and then operates by being permitted to progress to the requested time. Federate #3 is a Federate 102 that simulates the moment-to-moment position of a moving target and transmits it as a message. Unlike the Time Step method, Federate #3 operates by calculating the time at which the control device 401 executes the simulation based on the requested update period requested by other Federates 102 that subscribe to the messages sent by Federate #3, and by allowing progress to the calculated time.

[0056] The logical time progress and message communication of each simulator 407 are controlled by the control device 401. Here, each of Federate #1 and Federate #2 is a Time-constrained Federate 202 because it is a simulator 407 whose time progress is constrained by the time progress of the external Federate #3 and the time corresponding to the message. Furthermore, Federate #3 is a Time-regulating Federate 201 because it constrains the time progress of each of the external Federate #1 and Federate #2 by the current time of the moving target simulated by Federate #3 and the time corresponding to the message sent by Federate #3. Note that the Time-regulating Federate 201 needs to register a numerical value of 0 or more as Lookahead in the control device 401 depending on the process simulated by the Time-regulating Federate 201. Below, a specific example will be described in which Lookahead of Federate #3 is 1.

[0057] Each Federate 102 notifies the control device 401 of a time-regulating enable request (in the HLA standard of Non-Patent Document 2, Enable Time Regulation of Time Management is defined as an interface) or a time-constrained enable request (in the HLA standard of Non-Patent Document 2, Enable Time Constrained of Time Management is defined as an interface), and as a result, permission for the current time is obtained (in the HLA standard of Non-Patent Document 2, interfaces are defined as Time Regulation Enabled and Time Constrained Enabled of Time Management), thereby enabling logical time progression.

[0058] 6, notification 504 indicates that Federate #1 has notified the control device 401 of a time-constrained validity request. Notification 505 is a notification transmitted as a result of notification 504, and indicates that Federate #1 has obtained permission for the current time from the control device 401. Although not shown in FIG. 6, Federate #2, like Federate #1, also notifies the control device 401 of a time-constrained validity request, and as a result, obtains permission for the current time.

[0059] First, when the control device 401 receives a notification of a Time-constrained validity request from the Federate 102, it notifies the logical time management unit 405 via the interface unit 402 of information indicating the received notification. As a specific example, a process will be described in which a time-constrained valid request is made by a requesting Federate, which is a certain Federate 102, and the time-constrained valid request is notified to the logical time management unit 405. In this case, if the requesting Federate is a time-regulating Federate 201, the logical time management unit 405 sets the current time of the requesting Federate as the current time of the requesting Federate. Furthermore, if the requesting Federate is not a time-regulating Federate 201, the logical time management unit 405 calculates a GALT from the {current time + Lookahead} value of another time-regulating Federate 201, and sets a time equal to or less than the calculated GALT as the current time of the requesting Federate. Thereafter, the logical time management unit 405 permits the requesting Federate to use the set current time via the interface unit 402.

[0060] Next, although not shown in Fig. 6, Federate #3 notifies the control device 401 of a time-regulating validity request. In this embodiment, Federate #3 is a special time-regulating Federate 201 in which the control device 401 requests the permission time based on the request update period requested by another Federate 102. Therefore, in the time-regulating validity request, Federate #3 notifies the control device 401 of information indicating that time progress control based on the request update period is to be received as an argument in addition to Lookahead, which is an argument defined in the HLA standard. That is, Federate #3 notifies the control device 401 of the following information.

[0061] [Notification from Federate #3 to control device 401] Time-regulating validity request Argument 1: Lookahead=1 Argument 2: RURB=True

[0062] Here, the argument 2 "RURB (Request Update Rate Base)" registered when Time-regulating is enabled is an extended argument in the control device 401 according to this embodiment. RURB is flag information for notifying the control device 401 whether the Time-regulating Federate 201 that notified RURB is subject to time progress control based on the request update period (RURB=True) or not (RURB=False). "RURB" is an optional argument that can be omitted. If "RURB" is omitted, the control device 401 is notified that RURB=False, that is, that the Time-regulating Federate 201 is a normal Time-regulating Federate 201 that is not subject to time progress control based on the request update period.

[0063] When the control device 401 receives a notification of a time-regulating valid request from the Federate 102, it notifies the logical time management unit 405 via the interface unit 402 of information indicating the received notification. As a specific example, when a time-regulating valid request is requested from a requesting Federate, which is a certain Federate 102, and the time-regulating valid request is notified to the logical time management unit 405, the logical time management unit 405 sets the current time of the requesting Federate to a time that is equal to or greater than the maximum value of the current time of another Time-constrained Federate 202. The logical time management unit 405 also updates the GALT of another Time-constrained Federate 202 based on {current time + Lookahead} of the requesting Federate. Note that when the requesting Federate notifies {RURB=True}, the logical time management unit 405 uses the request update period set by another Federate 102 for the message sent by the requesting Federate when calculating the permitted time when the requesting Federate advances time. Thereafter, the logical time management unit 405 permits the current time set to the requesting Federate via the interface unit 402.

[0064] The situation shown in Fig. 6 is the initial state of the Federation 101. In Fig. 6, since none of the Federates 102 have advanced to the next time, T0 is permitted by the control device 401 as the current time of each Federate 102. In addition, since the Lookahead of Federate #3 is 1, the GALTs of Federate #1 and Federate #2 are both T1.

[0065] 7, the message publishing request (in the HLA standard of Non-Patent Document 2, the Publish Object Class Attribute and Publish Interaction Class of Declaration Management are defined as interfaces) and the message subscription request (in the HLA standard of Non-Patent Document 2, the Declaration Management This section explains the time advance request (in the HLA standard of Non-Patent Document 2, the Time Advance Request and Time Advance Request Available of Time Management are defined as interfaces for time advance requests using the Time Step method) and the time advance request (in the HLA standard of Non-Patent Document 2, the Time Advance Request and Time Advance Request Available of Time Management are defined as interfaces for time advance requests using the Time Step method).

[0066] A notification 601 is a notification indicating a message subscription request and a time advance request by Federate#1. A notification 602 is a notification indicating a message subscription request and a time advance request by Federate#2. The following information is notified to the control device 401 by each of notifications 601 and 602. Note that for a "message subscription request," the actual interface defined by the HLA standard defines multiple arguments according to the type of message, etc., and optional arguments. However, since these arguments are not directly related to the explanation of this embodiment, only the arguments corresponding to the request will be expressed here in the form of message names.

[0067] [Information provided by Notification 601] Message subscription request Argument 1: Message = (location information of moving target) Argument 2: Request update period = 5 Argument 3: Request update cycle registration time = T0 Time advance request Argument 1: Progress request time = T5 [Information provided by Notification 602] Message subscription request Argument 1: Message = (location information of moving target) Argument 2: Request update cycle = 3 Argument 3: Request update cycle registration time = T0 Time advance request Argument 1: Progress request time = T3

[0068] Here, the argument 2 "request update period" and the argument 3 "request update period registration time" registered in each message subscription request are each extended arguments in the control device 401 according to this embodiment. These arguments are valid only when the Federate 102 requesting the message subscription request is a Time-constrained Federate 202. The "request update period" is a logical time period that a Time-constrained Federate 202 that receives messages periodically, such as Federate #1 and Federate #2, expects from the Time-regulating Federate 201 as a reception period. The "request update period registration time" is the time when the requesting Federate registers the request update period and starts periodic processing. The "request update period registration time" must be equal to or greater than the current time of the Federate 102 that notified the "request update period registration time" at the time when the Federate 102 notified the control device 401 of the message subscription request. These arguments are optional arguments. If the "request update period" and "request update period registration time" are omitted, the control device 401 is notified that this is a normal message subscription request that does not affect the time progress control of the Time-regulating Federate 201. Furthermore, if only the "request update period registration time" among these arguments is omitted, the current time at the time when the Federate 102 that notified the message subscription request with the "request update period registration time" omitted notifies the control device 401 of the message subscription request is registered as the "request update period registration time." The interface for message subscription requests based on the HLA standard defines an optional argument called "Optional update rate designator" with a name very similar to "request update period." This argument indicates the update period in real time, not in logical time, and therefore does not affect the logical time progress control according to this embodiment.

[0069] When the control device 401 receives a message subscription request from the Federate 102, it notifies the publication / subscription management unit 403 via the interface unit 402 of information indicating the received notification. As a specific example, when a message subscription request is made by a requesting Federate, which is a certain Federate 102, and the message subscription request is notified to the publish / subscribe management unit 403, the publish / subscribe management unit 403 checks the relationship between the subscription message, which is the message to which the requesting Federate subscribed, and the message published by another Federate 102. After that, the publish / subscribe management unit 403 registers the sending / receiving relationship between the Federates 102 so that when the Federate 102 that published the subscription message sends a subscription message, the subscription message is delivered to the requesting Federate and the requesting Federate can receive the subscription message. Furthermore, if the optional arguments "request update period" and "request update period registration time" according to this embodiment are set in the message subscription request, the publication / subscription management unit 403 notifies the request update period management unit 404 of the requesting Federate, the message, the "request update period", and the "request update period registration time". The request update period management unit 404 then registers {"request update period registration time" + "request update period"} as the timestamp (request timestamp) at which the requesting Federate requests to next receive a subscription message. In the situation shown in FIG. 7, the next request timestamp is registered.

[0070] [Federate#1 request timestamp] Message = (location information of moving target) Request timestamp=T5 [Federate#2 request timestamp] Message = (location information of moving target) Request timestamp=T3

[0071] When the control device 401 receives a notification of a time advance request from the Federate 102, it notifies the logical time management unit 405 via the interface unit 402 of information indicating the received notification. As a specific example, when a time advance request based on the Time Step method and a requested advance time are notified to the logical time management unit 405 from a requesting Federate that is a Time-constrained Federate 202 such as Federate #1 or Federate #2, the logical time management unit 405 compares the GALT of the requesting Federate with the requested advance time. In FIG. 7, the GALT of each of Federate #1 and Federate #2 is smaller than the requested advance time. Therefore, the logical time management unit 405 does not notify Federate #1 or Federate #2 via the interface unit 402 and suspends the time advance. Note that this comparison between the GALT and the requested advance time is performed every time the GALT is updated in response to the time advance of another Federate 102 or the appearance of a new Time-regulating Federate 201.

[0072] 7, notification 603 indicates a "message publication request" and a "time advance request" notified by Federate #3. The following information is notified to the control device 401 as notification 603. Note that for the "message publication request," an interface defined by the actual HLA standard defines multiple arguments depending on the type of message, etc. However, since these arguments are not directly related to the description of this embodiment, only the arguments corresponding to the request will be expressed here in the form of a message name.

[0073] [Information provided by Notification 603] Message publishing request Argument 1: Message = (location information of moving target) Time advance request Argument 1: Progress request time = T8

[0074] Next, the time advance request of Federate #3 will be described. Federate #3 is a time-regulating Federate 201 that receives time advance control based on a request update period according to this embodiment. Therefore, the time advance of Federate #3 is controlled not only based on the advance request time at which Federate #3 requests time advance, but also based on the "request update period" and "request update period registration time" registered by other Federates 102 in their message subscription requests. Therefore, the advance request time in the time advance request of Federate #3 does not need to be a time that takes into account the greatest common divisor period of the update periods of other Federates 102, as a specific example, and may be the maximum time allowed by Federate #3 alone. Here, in FIG. 7, Federate #3 operates independently with Δt=8. Below, as a specific example, a case where the advance request time of Federate #3 is T8 will be described.

[0075] When the control device 401 receives a message publication request notification from the Federate 102, it notifies the publication / subscription management unit 403 via the interface unit 402 of information indicating the received notification. As a specific example, when a message publication request is made by a requesting Federate, which is a certain Federate 102, and the message publication request is notified to the publication and subscription management unit 403, the publication and subscription management unit 403 checks the relationship between the message published by the requesting Federate and the subscription message, which is a message to which another Federate 102 has subscribed. Thereafter, the publication and subscription management unit 403 registers the sending and receiving relationship between the Federates 102 so that when the requesting Federate sends a subscription message, the transmitted subscription message is delivered to the Federate 102 that has subscribed to the subscription message, and the Federate 102 can receive the subscription message.

[0076] Furthermore, when the control device 401 receives a time advance request from the Federate 102, it notifies the logical time management unit 405 via the interface unit 402 of information indicating the received notification. As a specific example, when a requesting Federate, which is Federate 102, notifies the logical time management unit 405 of a time advance request based on the Time Step method and the requested advance time, and the time advance request and the requested advance time are notified, the logical time management unit 405 permits the requesting Federate to advance time to the requested advance time via the interface unit 402 if the requesting Federate is not a Time-constrained Federate 202. Here, Federate #3 is a Time-regulating Federate 201 that is subject to time advance control based on the request update period according to this embodiment. Therefore, the logical time management unit 405 calculates the permitted time using the algorithm shown in FIG. 8 and permits Federate #3 to advance time to the calculated permitted time.

[0077] The permitted time calculation algorithm of the Time-regulating Federate 201 that is subject to time progress control based on the request update period according to this embodiment will be described with reference to FIG.

[0078] (Step S701) The logical time management unit 405 evaluates the Lookahead (LH) of a requesting Federate such as Federate #3, and proceeds to step S702 if the value of Lookahead is 0. Otherwise, the logical time management unit 405 proceeds to step S703. In the following description of this flowchart, Lookahead refers to the Lookahead evaluated in this step.

[0079] (Step S702) The logical time management unit 405 replaces the value of Lookahead with Epsilon.

[0080] (Step S703) The logical time management unit 405 extracts the minimum value of the request timestamps of messages published by the requesting Federate from the minimum values ​​registered in the request update period management unit 404, and sets the extracted value as the value of MinTS.

[0081] (Step S704) The logical time management unit 405 determines the time obtained by subtracting the Lookahead of the requesting Federate from MinTS as a candidate time (CandidateTime) for the permission time.

[0082] (Step S705) The logical time management unit 405 evaluates the candidate time. If the candidate time is equal to or less than T0, the logical time management unit 405 proceeds to step S706. Otherwise, the logical time management unit 405 proceeds to step S707.

[0083] (Step S706) If the candidate time is less than or equal to the initial time (T0), it cannot be set as the permitted time, so the logical time management unit 405 updates the value of MinTS by adding the requested update rate (RequestUpdateRate) of the message to which the timestamp corresponding to the minimum value extracted in step S703 is attached to the current value of MinTS.The requested update rate management unit 404 then returns to step S704 and uses the updated value of MinTS. The request update cycle management unit 404 performs this step until the candidate time becomes greater than T0.

[0084] (Step S707) The logical time management unit 405 sets the candidate time as the granted time (Granted Time).

[0085] (Step S708) The logical time management unit 405 updates the value of MinTS by adding RequestUpdateRate to the current value of MinTS.

[0086] FIG. 9 shows the situation after the permitted time of Federate#3 is calculated from the situation shown in FIG. 7 by the algorithm shown in FIG. 8, and time progress is permitted based on the calculated permitted time. In FIG. 9, notification 801 is the permission time calculated by the logical time management unit 405 of the control device 401, and indicates that the permission time for Federate #3 has been notified to Federate #3 via the interface unit 402 of the control device 401. Here, the permission time is T2, which is the time obtained by subtracting 1, which is the Lookahead of Federate #3, from the minimum value (specifically, T3 by Federate #2) of the request timestamp of a message published by Federate #3 and indicating (position information of a moving target). T2 corresponds to the time corresponding to the minimum reception request time. Note that the request timestamp of Federate #2 is updated when the permission time is calculated. The updated request timestamp is managed in the request update period management unit 404 as follows.

[0087] [Federate#1 request timestamp] Message = (location information of moving target) Request timestamp=T5 [Federate#2 request timestamp] Message = (location information of moving target) Request timestamp=T6

[0088] Furthermore, the logical time management unit 405 updates the GALT of each of Federate #1 and Federate #2, which are Time-constrained Federates 202, as a result of updating the current time of Federate #3, which is a Time-regulating Federate 201. Specifically, each GALT is updated to T3. Note that in Federate #2, the requested progress time T3 and the GALT have the same value, and the GALT has not yet become greater than the requested progress time. Therefore, time advance permission is not granted to Federate #2.

[0089] In FIG. 9, when Federate #3 advances in time to T2, Federate #3 updates the position information of the moving object and notifies the control device 401 of a message transmission request regarding the position information of the moving object at T3, which is Lookahead minutes after T2 (in the HLA standard of Non-Patent Document 2, Update Attribute Values ​​and Send Interaction of Object Management are specified as interfaces for message transmission requests). When Federate #3 finishes the simulation process at T2, it notifies the control device 401 of a request to proceed to the next time. Here, since Federate #3 operates at Δt=8, the requested progress time is T10 as shown in FIG. 9. In the example shown in FIG. 9, Lookahead of Federate #3 is 1. Here, if Lookahead of Federate 102 is 0, a timestamp is calculated using Epsilon instead of Lookahead. 9, notification 802 indicates the notification from Federate #3 mentioned above. The following information is notified by notification 802. Note that for the "message transmission request," the actual interface defined by the HLA standard defines multiple arguments according to the message type, etc., and optional arguments. However, since these arguments are not directly related to the description of this embodiment, only the arguments corresponding to the request are expressed here in the form of message name values.

[0090] [Information provided by Notification 802] Message Send Request Argument 1: Message = (location information of moving target) Argument 2: Timestamp = T3 Time advance request Argument 1: Progress request time = T10

[0091] When the control device 401 receives a message transmission request from the Federate 102, it notifies the transmission / reception message manager 406 via the interface unit 402 of information indicating the received notification. As a specific example, when a message transmission request is made by a requesting Federate, which is a certain Federate 102, and the message transmission request is notified to the transmission / reception message manager 406, the message indicated by the message transmission request sent by the requesting Federate is registered in the transmission / reception message manager 406 in the reception queue of another Federate 102 that is registered as the recipient of the message in the publication / subscription manager 403. A reception queue is prepared for each Federate 102, and each message with a timestamp is registered in the reception queue. Here, if the Federate 102 corresponding to the reception queue is a Time-constrained Federate 202, each message is registered in the reception queue in the time order indicated by the timestamp assigned to each message. Also, if the Federate 102 corresponding to the reception queue is not a Time-constrained Federate 202, each message is registered in the reception queue in the order in which it was registered in the reception queue. In the situation shown in FIG. 9, the messages indicated by the message transmission requests are registered in the receiving queues of Federate#1 and Federate#2 in the time order indicated by the timestamps attached to the messages. The process for the time advance request indicated by the notification 802 is the same as the process for the time advance request indicated by the notification 603.

[0092] Next, with reference to FIG. 10, a situation will be described after the permitted time of Federate#3 is calculated from the situation shown in FIG. 9 by the algorithm shown in FIG. 8 and Federate#3 is permitted to advance in time to T4. In Fig. 10, notification 901 indicates a time advance permission for a time advance request from Federate #3. The granted time corresponding to the time advance permission is T4, which is a time obtained by subtracting 1, which is the Lookahead of Federate #3, from the minimum value of the request timestamps (specifically, T5 by Federate #1) corresponding to messages published by Federate #3 and indicating the position information of a moving target. Note that the request timestamp of Federate #2 is updated as a result of the calculation of the granted time. The updated request timestamps are managed in the request update period management unit 404 as follows.

[0093] [Federate#1 request timestamp] Message = (location information of moving target) Request timestamp=T10 [Federate#2 request timestamp] Message = (location information of moving target) Request timestamp=T6

[0094] The logical time management unit 405 updates the GALT of each of Federate #1 and Federate #2, which are time-constrained Federates 202, as a result of the update of the current time of Federate #3, which is a time-regulating Federate 201. Specifically, each GALT is updated to T5. Here, since the GALT of Federate #2 is greater than T3, which is the requested progress time, the logical time management unit 405 instructs the sent and received message management unit 406 to deliver messages that are registered in the receive queue of Federate #2 and that have timestamps indicating times up to T3, which is the requested progress time. The sent and received message management unit 406 causes Federate #2 to receive messages that have timestamps indicating times up to T3 via the interface unit 402 (the HLA standard in Non-Patent Document 2 specifies the Reflect Attribute Values ​​and Receive Interaction of Object Management as interfaces for message reception). When the transmission / reception message management unit 406 finishes delivering the message with a timestamp indicating the time up to T3, the logical time management unit 405 notifies Federate #2 via the interface unit 402 of time advance permission, with T3 as the permitted time. In Fig. 10, a notification 902 indicates "message reception" and "time advance permission" notified from the control device 401 to Federate #2. Specifically, the following information is notified by the notification 902. Note that the message indicated by the notification 902 corresponds to a message generated by the processing executed by the transmission simulator at the time corresponding to the minimum reception request time.

[0095] [Information provided by Notification 902] Message Reception Argument 1: Message = (value of moving target's position information) Argument 2: Timestamp = T3 Time advance permission Argument 1: Permission time = T3

[0096] When Federate#3 advances in time to T4, Federate#3 updates the position information of the moving object and notifies the control device 401 of a message transmission request regarding the position information of the moving object at T5, which is Lookahead minutes after T4. After that, when Federate#3 finishes the simulation process at T4, it notifies the control device 401 of a request to proceed to the next time. Here, since Federate#3 operates at Δt=8, the requested progress time is T12 as shown in FIG. 10. In FIG. 10, notification 903 indicates a notification by Federate#3. Specifically, the following information is notified by notification 903.

[0097] [Information provided by Notification 903] Message Send Request Argument 1: Message = (location information of moving target) Argument 2: Timestamp = T5 Time advance request Argument 1: Progress request time = T12

[0098] Next, with reference to FIG. 11, a situation will be described after the permitted time of Federate#3 is calculated from the situation shown in FIG. 10 by the algorithm shown in FIG. 8 and Federate#3 is permitted to advance in time to T5. 11, notification 911 indicates a time advance permission for the time advance request of Federate #3. The granted time is T5, which is calculated based on the minimum value of the requested timestamps (specifically, T6 by Federate #1) as a result of processing similar to that described in FIG. 10. The requested timestamps are updated by processing similar to that described in FIG. 10, but a description of this processing will be omitted here.

[0099] The logical time management unit 405 updates the GALT of each of Federate #1 and Federate #2, which are time-constrained Federates 202, as a result of the update of the current time of Federate #3, which is a time-regulating Federate 201. Specifically, the GALT is updated to T6. Here, since the GALT of Federate #1 is now greater than the progress request time T5, the logical time management unit 405 instructs the sent and received message management unit 406 to deliver messages that are registered in the receiving queue of Federate #1 and that have timestamps indicating times up to T5, which is the progress request time. Here, the receiving queue of Federate #1 contains messages registered by notification 802 and whose corresponding timestamp indicates T3, and messages registered by notification 903 and whose corresponding timestamp indicates T5. In the normal time step method, all messages with time stamps indicating times up to T5, which is the requested progress time, are received by the receiving Federate 102. On the other hand, in the control device 401 according to this embodiment, the transmission / reception message management unit 406, based on the value of the request time stamp registered in the request update period management unit 404, does not allow the receiving Federate 102 to receive messages with time stamps indicating unrequested times, and discards the messages from the reception queue. That is, according to this embodiment, reception of messages corresponding to times that are unnecessary for the Federate 102 that requests periodic message reception is filtered. In FIG. 11, a notification 912 indicates "message reception" and "time progress permission" notified from the control device 401 to Federate #1. Specifically, the notification 912 notifies the following information:

[0100] [Information provided by Notification 912] Message Reception Argument 1: Message = (value of moving target's position information) Argument 2: Timestamp = T5 Time advance permission Argument 1: Permission time = T5

[0101] When Federate #3 advances in time to T5, Federate #3 notifies the control device 401 of a request to send a message regarding the position information of the moving object at T6, which is Lookahead minutes after T5. After that, when Federate #3 finishes the simulation process at T5, it notifies the control device 401 of a request to proceed to the next time. In Fig. 11, notification 913 indicates a notification by Federate #3. Since notification 913 is similar to notification 903, a description thereof will be omitted here.

[0102] ***Explanation of the effect of the first embodiment*** As described above, according to this embodiment, the control device 401 controls the time progress of the Time-regulating Federate 201 that transmits messages based on the request update period of the Time-constrained Federate 202 that requests periodic message reception. As a result, the time when simulation processing is required in each Federate 102 is notified from the RTI 103 as the permitted time. Therefore, according to this embodiment, it is possible to adjust the processing period of each Federate 102 on the transmitting side and the receiving side. Furthermore, according to this embodiment, as a specific example, the Time-regulating Federate 201 does not need to operate at a period that is the greatest common divisor of the processing periods of multiple Time-constrained Federates 202. Therefore, according to this embodiment, the processing efficiency of the entire Federation 101 is improved. Furthermore, based on the requested update period of the Time-constrained Federate 202 that requests periodic message reception, the control device 401 according to this embodiment filters reception of messages that have timestamps indicating times that are not required by the Time-constrained Federate 202. Therefore, according to this embodiment, the load of message reception processing on the Time-constrained Federate 202 can be reduced.

[0103] In this embodiment, an example of an extension to the processing and interface based on the Time Step method defined in the HLA standard is shown. The processing and optional arguments of the interface described in this embodiment do not affect the processing and interface of the existing HLA standard. Therefore, this embodiment can coexist with Federate, which performs logical time progression using at least one of the Time Step method, Event Based method, and Optimistic method included in conventional RTI. Furthermore, even in a parallel discrete simulation system that performs logical time progression control using the Time Step method without complying with the HLA standard, the processing efficiency of the entire parallel discrete simulation system can be improved by applying the logical time progression algorithm shown in FIG. 8 and the filtering process shown in FIG. 11 to the parallel execution control function of the simulator.

[0104] ***Other Configurations*** <Variation 1> FIG. 12 shows an example of the hardware configuration of a control device 401 according to this modification. The control device 401 includes a processing circuit 18 in place of the processor 11, the processor 11 and memory 12, the processor 11 and auxiliary storage device 13, or the processor 11, memory 12, and auxiliary storage device 13. The processing circuit 18 is hardware that realizes at least a part of each unit included in the control device 401 . The processing circuitry 18 may be dedicated hardware or may be a processor that executes a program stored in the memory 12 .

[0105] When processing circuitry 18 is dedicated hardware, processing circuitry 18 may be, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination thereof. The control device 401 may include a plurality of processing circuits that replace the processing circuit 18. The plurality of processing circuits share the role of the processing circuit 18.

[0106] In the control device 401, some functions may be realized by dedicated hardware, and the remaining functions may be realized by software or firmware.

[0107] Processing circuitry 18 is illustratively implemented in hardware, software, firmware, or a combination thereof. The processor 11, memory 12, auxiliary storage device 13, and processing circuit 18 are collectively referred to as "processing circuitry." In other words, the functions of the functional components of the control device 401 are realized by the processing circuitry.

[0108] ***Other embodiments*** Although the first embodiment has been described, it is also possible to combine multiple parts of this embodiment. Alternatively, it is also possible to implement this embodiment in part. In addition, this embodiment may be modified in various ways as needed, and may be implemented in any combination, either as a whole or in part. The above-described embodiments are essentially preferred examples and are not intended to limit the scope of the present disclosure, its applications, and uses. The procedures described using flowcharts and the like may be modified as appropriate.

[0109] Various aspects of the present disclosure are summarized below as appendices.

[0110] (Appendix 1) a transmitting simulator that transmits messages, and one or more receiving simulators that periodically receive messages from the transmitting simulator and perform processing using the received messages; A distributed simulation system that executes parallel discrete event simulation using logical time, comprising: a request update period management unit that calculates a reception request time, which is the time when the target reception simulator will next request message reception, based on a request update period, which is the period during which the target reception simulator requests message reception, when each of the one or more reception simulators is a target reception simulator; a logical time management unit that controls the current time of the transmitting simulator based on a requested reception time corresponding to each of the one or more receiving simulators; A control device comprising: A distributed simulation system comprising:

[0111] (Appendix 2) The distributed simulation system according to claim 1, wherein the request update period management unit calculates the reception request time corresponding to the target receiving simulator based on a request update period registration time, which is the time when the request update period corresponding to the target receiving simulator is registered, and the request update period corresponding to the target receiving simulator.

[0112] (Appendix 3) a current time of each of the one or more receiving simulators is less than or equal to a current time of the transmitting simulator; 3. The distributed simulation system according to claim 1, wherein the logical time management unit permits the transmitting simulator to advance the current time of the transmitting simulator to a time corresponding to a minimum requested reception time, which is the smallest time among the requested reception times corresponding to each of the one or more receiving simulators.

[0113] (Appendix 4) The distributed simulation system further comprises: a transmission / reception message management unit that transmits a message generated by a process executed by the transmission simulator at a time corresponding to the minimum reception request time to the reception simulator corresponding to the minimum reception request time; 4. The distributed simulation system of claim 3, comprising:

[0114] (Appendix 5) The distributed simulation system described in Appendix 4, wherein the transmission and reception message management unit does not transmit to the target receiving simulator a message corresponding to each time that is greater than a request update period registration time, which is the time when the request update period corresponding to the target receiving simulator is registered, and is less than a time obtained by adding the request update period corresponding to the target receiving simulator to the request update period registration time.

[0115] (Appendix 6) the distributed simulation system is a distributed simulation system based on HLA (High Level Architecture), the control device is a Run-Time Infrastructure in the HLA, each of the one or more receiving simulators is a Time-Constrained Federate in the HLA; A distributed simulation system according to claim 2 or 5, wherein the request update period and the request update period registration time are notified to the control device by optional arguments of Subscribe Object Class Attribute and Subscribe Interaction Class, which are interfaces in the HLA.

[0116] (Appendix 7) the distributed simulation system is a distributed simulation system based on HLA (High Level Architecture), the control device is a Run-Time Infrastructure in the HLA, The transmission simulator is a Time-regulating Federate in the HLA and is an Enable Time 7. A distributed simulation system according to any one of appendices 1 to 6, wherein an optional argument of Regulation requests the control device to control the time progress of the transmitting simulator based on the requested update period.

[0117] (Appendix 8) the distributed simulation system is a distributed simulation system based on HLA (High Level Architecture), the control device is a Run-Time Infrastructure in the HLA, each of the one or more receiving simulators is a Time-Constrained Federate in the HLA; The distributed simulation system described in Appendix 5, wherein the transmission and reception message management unit transmits messages to the target receiving simulator by executing Reflect Attribute Values ​​and Receive Interaction, which are interfaces in the HLA, only for messages that have a request timestamp that indicates a reception request time corresponding to the target receiving simulator. [Explanation of symbols]

[0118] 11 Processor, 12 Memory, 13 Auxiliary storage device, 14 Input / output interface, 15 Communication device, 18 Processing circuit, 19 Signal line, 90 Distributed simulation system, 101 Federation, 102 Federate, 103 RTI, 104 FOM, 201 Time-regulating Federate, 202 Time-constrained Federate, 401 Control device, 402 Interface section, 403 Publish / subscribe management section, 404 Request update period management section, 405 Logical time management section, 406 Send / receive message management section, 407 Simulator, 504,505,601,602,603,801,802,901,902,903,911,912,913 Notification.

Claims

1. a transmitting simulator for transmitting messages, and one or more receiving simulators for periodically receiving messages from the transmitting simulator and performing processing using the received messages; A distributed simulation system that executes parallel discrete event simulation using logical time, comprising: a request update period management unit that calculates a reception request time, which is the time when the target reception simulator will next request message reception, based on a request update period, which is the period during which the target reception simulator requests message reception, when each of the one or more reception simulators is a target reception simulator; a logical time management unit that controls the current time of the transmitting simulator based on a requested reception time corresponding to each of the one or more receiving simulators; A control device comprising: A distributed simulation system comprising:

2. 2. The distributed simulation system according to claim 1, wherein the request update period management unit calculates the reception request time corresponding to the target receiving simulator based on the request update period registration time, which is the time when the request update period corresponding to the target receiving simulator is registered, and the request update period corresponding to the target receiving simulator.

3. a current time of each of the one or more receiving simulators is less than or equal to a current time of the transmitting simulator; 3. The distributed simulation system according to claim 1, wherein the logical time management unit permits the transmitting simulator to advance the current time of the transmitting simulator to a time corresponding to a minimum requested reception time, which is the smallest time among the requested reception times corresponding to each of the one or more receiving simulators.

4. The distributed simulation system further comprises: a transmission / reception message management unit that transmits a message generated by a process executed by the transmission simulator at a time corresponding to the minimum reception request time to the reception simulator corresponding to the minimum reception request time; The distributed simulation system of claim 3 , comprising:

5. 5. The distributed simulation system according to claim 4, wherein the transmission / reception message management unit does not transmit to the target receiving simulator a message corresponding to each time that is greater than the request update period registration time, which is the time when the request update period corresponding to the target receiving simulator is registered, and is less than the request update period registration time plus the request update period corresponding to the target receiving simulator.

6. the distributed simulation system is a distributed simulation system based on HLA (High Level Architecture), the control device is a Run-Time Infrastructure in the HLA, each of the one or more receiving simulators is a time-constrained federated in the HLA; 3. The distributed simulation system according to claim 2, wherein the requested update period and the requested update period registration time are notified to the control device by optional arguments of Subscribe Object Class Attribute and Subscribe Interaction Class, which are interfaces in the HLA.

7. the distributed simulation system is a distributed simulation system based on HLA (High Level Architecture), the control device is a Run-Time Infrastructure in the HLA, 3. The distributed simulation system according to claim 1, wherein the transmission simulator is a Time-regulating Federate in the HLA, and requests the control device to control the time progress of the transmission simulator based on the requested update period using an optional argument of Enable Time Regulation, which is an interface in the HLA.

8. the distributed simulation system is a distributed simulation system based on HLA (High Level Architecture), the control device is a Run-Time Infrastructure in the HLA, each of the one or more receiving simulators is a time-constrained federated in the HLA; 6. The distributed simulation system according to claim 5, wherein the transmission / reception message management unit transmits messages to the target receiving simulator by executing Reflect Attribute Values ​​and Receive Interaction, which are interfaces in the HLA, only for messages to which a request timestamp indicating a reception request time corresponding to the target receiving simulator is attached.

9. a transmitting simulator for transmitting messages, and one or more receiving simulators for periodically receiving messages from the transmitting simulator and performing processing using the received messages; A distributed simulation method executed by a control device, which is a computer included in a distributed simulation system that executes parallel discrete event simulation using logical time, comprising: When the control device designates each of the one or more receiving simulators as a target receiving simulator, it calculates a request reception time, which is the time when the target receiving simulator will next request message reception, based on a request update period, which is the period during which the target receiving simulator requests message reception; A distributed simulation method in which the control device controls the current time of the transmitting simulator based on a request reception time corresponding to each of the one or more receiving simulators.

10. a transmitting simulator for transmitting messages, and one or more receiving simulators for periodically receiving messages from the transmitting simulator and performing processing using the received messages; A distributed simulation program executed by a control device, which is a computer included in a distributed simulation system that executes parallel discrete event simulation using logical time, comprising: a request update period management process for calculating a reception request time, which is the time when the target reception simulator will next request message reception, based on a request update period, which is the period during which the target reception simulator requests message reception, when each of the one or more reception simulators is a target reception simulator; a logical time management process for controlling the current time of the transmitting simulator based on a requested reception time corresponding to each of the one or more receiving simulators; A distributed simulation program that causes the control device to execute the above.

Images