Processing device and distributed simulation system

Abstract

To obtain a processing device which can improve efficiency of communication in a distributed simulation system with which a plurality of simulators are connected.SOLUTION: A processing device LRC204 is loaded with middleware which is an RTI for providing service in a distributed simulation system based on an HLA normalized by an IEEE1516, and comprises a simulation data communication control unit 303 which buffers an RO message in which transmission holding time is set to a transmission queue, integrates a plurality of RO messages into a transmission packet to be transmitted on the basis of characteristics of an application for the RO message transmitted by a federate, and transmits the RO message in which no transmission holding time is set or zero is set as the transmission packet without buffering the RO message.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to a processing device used in a distributed simulation system in which a plurality of simulators are linked together, and the distributed simulation system. [Background technology]

[0002] A distributed simulation system is a system in which many sub-simulators are linked via a network with the aim of improving the calculation capacity in a simulation, or a system in which simulators operated by individuals are linked via a network to execute a virtual simulation in which many people participate.HLA (High Level Architecture), disclosed in Non-Patent Documents 1 to 3, is a standard of the IEEE (Institute of Electrical and Electronics Engineers) that standardizes communication methods and synchronization methods between simulators with the aim of improving the development efficiency of distributed simulation systems.

[0003] In the logical configuration of a distributed simulation system based on HLA, the entire system is called a Federation, and the components that make up the Federation, such as multiple simulators, are called Federates. In a Federation, a Federate is not directly connected to other Federates but is connected to infrastructure software called an RTI (Run-Time Infrastructure). The RTI provides the foundational functions of the simulation system (hereinafter referred to as HLA services), such as Federation management, Federate communication, and synchronization between Federates. The Federation Object Model (FOM), which defines the simulation data that each Federate communicates with other Federates and RTIs, is referenced by each Federate and RTI during the execution of the distributed simulation system. Non-Patent Document 1 is a set of regulations that define basic rules for HLA, such as the terminology of HLA, the fact that Federates do not directly connect with each other, and that RTIs provide foundation functions. Non-Patent Document 2 is a set of regulations that define the HLA services that RTIs provide to Federations and Federates, and the APIs (Application Programming Interfaces) that Federates use to use RTIs. Non-Patent Document 3 is a rule that defines how to define FOM.

[0004] In the physical configuration of an HLA-based distributed simulation system, multiple computers connected to a network each have a Federate program installed. An LRC (Local Runtime Component), which implements RTI functions, is linked to each Federate program as a program library. Federate programs can use the RTI functions via the HLAAPI. The FOM is defined in an external FOM definition file. The LRC can read the information in the FOM definition file. Federate programs can reference the contents of the FOM definition file via the HLAAPI. The LRC can communicate with other LRCs linked to other Federate programs on other computers via the network, enabling simulation data communication and processing synchronization between Federate programs.

[0005] RTI controls the network communication of simulation data that a Federate sends and receives with other Federates. In the HLA protocol, simulation data is classified into two types. One type of simulation data is Attribute, which is the attribute information of the simulated object simulated by the Federate. A simulated object is, for example, an aircraft simulated by a flight simulator, and is called an Object in HLA. Attribute information is, for example, the position and speed information of the simulated aircraft. The other type of simulation data is Interaction, which is event information temporarily simulated by the Federate. Event information is, for example, communication information used by a simulated aircraft to communicate with other aircraft. When RTI communicates Attributes and Interactions over the network, the Federation, Federate, etc. can select either HLA Reliable communication, which is reliable communication based on TCP (Transmission Control Protocol) communication, or HLA Best Effort communication, which is efficient communication based on UDP (User Datagram Protocol) multicast communication. The initial settings for the communication method as a federation are set in the FOM for each attribute and interaction type, and while the federate is running, the communication method settings can be changed for each attribute and interaction type using the RTI API. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules (IEEE Std 1516-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) [Non-patent document 3] IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Object Model Template (OMT) Specification (IEEE Std 1516.2-2010) Summary of the Invention [Problem to be solved by the invention]

[0007] The HLA regulations stipulate that HLA reliable communication is communication with guaranteed reliability similar to TCP communication, and that HLA besteffort communication is efficient communication similar to UDP multicast communication, but the details of the communication method are left to the implementation method of RTI.

[0008] For example, in HLAreliable communication, if the RTI simply executes TCP communication each time the Federate requests the RTI to send an Attribute or Interaction, there is a problem in that communication delays become large for the following reasons, and attempts to improve the delay result in a decrease in efficiency.

[0009] TCP communication ensures reliability through ACK transmission, which confirms delivery. However, because it uses the Nagle algorithm and delayed ACK, a delay of up to 200 ms can occur in a typical environment between when an application starts sending data and when the communication actually begins. The Nagle algorithm reduces redundant communication header information and improves communication efficiency by suspending multiple small data requests from an application until an ACK is received or the maximum segment is reached, and then sending them all at once. Delayed ACK is a method of reducing redundant ACK transmission by delaying the timing of transmission rather than sending an ACK each time a data is received. Note that while the above delay can be eliminated by disabling the Nagle algorithm when performing TCP communication, communication efficiency decreases due to the need to transmit small packets each time an application requests transmission and the increased ACK transmission.

[0010] Furthermore, in HLA besteffort communication, if the RTI simply performs UDP multicast communication each time the Federate requests the RTI to send an Attribute or Interaction, there is a problem in that the efficiency of communication deteriorates or the reliability decreases for the following reasons:

[0011] In UDP multicast communication, data requested by an application is transmitted as packets. Therefore, if data whose size is smaller than the maximum value for data transfer in the data link layer, i.e., the frame's Maximum Transmission Unit (MTU), is frequently transmitted, many frames will be transmitted and processed in the data link layer, reducing communication efficiency. On the other hand, data whose size is larger than the MTU is divided into multiple frames for transmission, but because UDP is a communication method with no guaranteed reliability, if even one of the divided frames is lost during transmission, the entire data will be lost, and data that is larger than the MTU will reduce the reliability of communication.

[0012] The present disclosure has been made in view of the above, and has an object to provide a processing device that can improve communication efficiency in a distributed simulation system in which multiple simulators are connected together. [Means for solving the problem]

[0013] In order to solve the above-mentioned problems and achieve the object, the present disclosure provides a processing device equipped with middleware, which is an RTI that provides services in a distributed simulation system based on HLA standardized by IEEE 1516. The processing device buffers RO messages, which are messages sent by a federate and for which a transmission hold time is set, in a transmission queue, and aggregates multiple RO messages into a transmission packet for transmission, based on the characteristics of the application for the RO messages. believe The present invention is characterized by comprising a simulation data communication control unit. [Effects of the Invention]

[0014] The processing device of the present disclosure has the effect of improving communication efficiency in a distributed simulation system in which multiple simulators are connected together. [Brief explanation of the drawings]

[0015] [Figure 1] FIG. 1 is a diagram showing an example of a logical configuration of a distributed simulation system based on an HLA according to a first embodiment. [Figure 2] FIG. 1 is a diagram showing an example of the physical configuration of a distributed simulation system based on HLA according to a first embodiment. [Figure 3] FIG. 1 is a diagram showing an example of a software configuration of an LRC according to a first embodiment; [Figure 4] FIG. 10 is a diagram showing a method for determining a simulation data transmission method based on the HLA protocol in the LRC according to the first embodiment. [Figure 5] 1 is a flowchart showing a transmission process of an RO message (HLAreliable) in an LRC according to the first embodiment. [Figure 6]1 is a flowchart showing a transmission process of a TSO message (HLAreliable) in an LRC according to the first embodiment. [Figure 7] FIG. 1 is a diagram showing an example of the configuration of a processing circuit when the processing circuit included in the LRC according to the first embodiment is realized by a processor and a memory. [Figure 8] FIG. 1 is a diagram showing an example of the configuration of a processing circuit included in an LRC according to the first embodiment when the processing circuit is configured using dedicated hardware; [Figure 9] 10 is a flowchart showing a transmission process of an RO message (HLAbesteffort) in an LRC according to a second embodiment. [Figure 10] 10 is a flowchart showing a transmission process of a TSO message (HLAbesteffort) in an LRC according to a second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] A processing device and a distributed simulation system according to an embodiment of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0017] Embodiment 1 In the first embodiment, an example of HLA reliable communication in a federation using RTI will be described.

[0018] FIG. 1 is a diagram illustrating an example of a logical configuration of an HLA-based distributed simulation system 500 according to the first embodiment. The distributed simulation system 500 includes a Federation 101 and an RTI 103. In the HLA-based distributed simulation system 500, the entire system that actually executes the simulation is called the Federation 101, and the components of the Federation 101, such as multiple simulators, are called Federates 102. Each Federate 102 is not directly connected to other Federates 102, but is connected to platform software called the RTI 103. The RTI 103 provides HLA services. When executing the distributed simulation system 500, each Federate 102 and RTI 103 references an FOM 104 that defines simulation data as common definition data. The RTI 103 controls network communication of the simulation data that each Federate 102 transmits and receives to and from other Federates 102. In the example of FIG. 1, the Federation 101 includes three Federates 102, but may include two, four, or more. In the following explanation, "Federate" may be written as "federation."

[0019] FIG. 2 is a diagram illustrating an example of the physical configuration of an HLA-based distributed simulation system 500 according to the first embodiment. The entire system illustrated in FIG. 2 is a single Federation 101. A plurality of computers 201 connected to a network 206 each have a Federate program 202 installed. An LRC 204, which implements the functions of an RTI 103, is linked to each Federate program 202 as a program library. The Federate program 202 can use the functions of the RTI 103 via the HLAAPI 203. The FOM 104 is defined in an FOM definition file 205, which is an external definition file. The LRC 204 can read information from the FOM definition file 205. The Federate program 202 can refer to the definition contents of the FOM definition file 205 via the HLAAPI 203. The LRC 204 can communicate with other LRCs 204 linked to other Federate programs 202 on other computers 201 via the network 206, thereby performing simulation data communication, processing synchronization, and the like between the Federate programs 202. In the example of FIG. 2, there are two computers 201 connected to the network 206, but there may be three or more computers.

[0020] FIG. 3 is a diagram illustrating an example of the software configuration of the LRC 204 according to the first embodiment. FIG. 3 is also a diagram illustrating functional blocks of the LRC 204. The LRC 204 is a processing device that provides HLA services such as simulation data exchange and synchronization processing with other Federate programs 202 via a network 206 to the Federate program 202. The LRC 204 is a processing device equipped with middleware that is an RTI. In the following description, the HLA service may be simply referred to as a service. The LRC 204 includes an HLAAPI processing unit 301, an HLA service processing unit 302, a simulation data communication control unit 303, and a network communication interface 312. The simulation data communication control unit 303 includes an RO message transmission queue (HLAreliable) 304, a TSO message transmission queue (HLAreliable) 305, an RO message transmission queue (HLAbesteffort) 306, a TSO message transmission queue (HLAbesteffort) 307, an RO message reception queue 308, a TSO message reception queue 309, an HLAreliable communication control unit 310, and an HLAbesteffort communication control unit 311.

[0021] The HLAAPI processing unit 301 processes the HLAAPI 203 that provides an RTI function for the Federate program 202 based on the HLA regulations.

[0022] The HLA service processing unit 302 processes the HLA service provided by the RTI 103 to the Federation 101 and the Federate 102 based on the HLA regulations. The HLA service processing unit 302 processes the HLA service in accordance with the settings of the FOM definition file 205, which is an external setting file.

[0023] The simulation data communication control unit 303 controls the simulation data communication in accordance with the processing for the simulation data communication in the HLA service processing unit 302. The simulation data communication control unit 303 controls the simulation data communication in accordance with the settings of the FOM definition file 205, which is an external setting file. The processing for the simulation data communication executed in the HLA service processing unit 302 is processing executed based on the following HLAAPI 203 called by the Federate program 202.

[0024] (1) Sending Object Attribute Update Attribute Values (2) Receiving Object Attribute Reflect Attribute Values (3) Delete and send the Object Instance Delete Object Instance (4) Object Instance deletion reception Remove Object Instance (5) Sending Interactions Send Interaction ·Send Interaction With Regions (6) Receiving Interactions Receive Interaction

[0025] The network communication interface 312 performs network communication using the network 206 with the LRC 204 of another Federate 102 for the simulation data communication control unit 303 and the HLA service processing unit 302. The network communication interface 312 does not use the Nagle algorithm provided by the OS (Operating System) in TCP communication.

[0026] The RO message transmission queue (HLAreliable) 304 is a transmission queue that accumulates RO messages to be transmitted by HLA communication among the RO messages to be transmitted in response to an RO (Received Ordered) message transmission request from the HLA service processing unit 302 in the simulation data communication control unit 303. The RO message is simulation data that is processed in the order of the received real time in the Federate 102, where the simulation program executed by the Federate 102 advances time according to the time in the real world (hereinafter referred to as real time), as defined in the HLA regulations.

[0027] The RO message transmission queue (HLAbesteffort) 306 is a transmission queue that accumulates RO messages to be transmitted by HLAbesteffort communication among RO messages to be transmitted in response to an RO message transmission request from the HLA service processing unit 302 .

[0028] The TSO message transmission queue (HLAreliable) 305 is a transmission queue that accumulates TSO messages to be transmitted by HLA communication among the TSO messages to be transmitted in response to a TSO (Time Stamp Ordered) message transmission request from the HLA service processing unit 302 in the simulation data communication control unit 303. A TSO message is simulation data that is processed in the order of a time stamp, which is the logical time at which the simulation data becomes valid, that is assigned to the simulation data in Federate 102, where the simulation program executed by Federate 102 advances time according to a logical time value (hereinafter referred to as logical time), which is a program variable, as defined in the HLA regulations.

[0029] The TSO message transmission queue (HLAbesteffort) 307 is a transmission queue that accumulates TSO messages to be transmitted by HLAbesteffort communication among the TSO messages to be transmitted in response to a TSO message transmission request from the HLA service processing unit 302 .

[0030] The RO message receiving queue 308 is a receiving queue that receives notification of an RO message received by the network communication interface 312 from the LRC 204 of another Federate 102 in the simulation data communication control unit 303, and stores the received RO message via the HLA reliable communication control unit 310 or the HLA besteffort communication control unit 311. The received RO message stored in the RO message receiving queue 308 is notified to the Federate program 202 via the HLA service processing unit 302 and the HLAAPI processing unit 301 when the Federate 102 becomes able to receive an RO message, based on the operation of the HLAAPI 203 defined in the HLA protocol.

[0031] The TSO message receiving queue 309 is a receiving queue that receives a notification of a TSO message received by the network communication interface 312 from the LRC 204 of another Federate 102 in the simulation data communication control unit 303, and stores the received TSO message via the HLA reliable communication control unit 310 or the HLA besteffort communication control unit 311. The received TSO message stored in the TSO message receiving queue 309 is notified to the Federate program 202 via the HLA service processing unit 302 and the HLAAPI processing unit 301 in accordance with the time stamp of the TSO message that is determined to be valid in accordance with the progress of the logical time of the Federate 102, based on the operation of the HLAAPI 203 defined in the HLA regulations.

[0032] The HLA reliable communication control unit 310 controls HLA reliable communication for the network communication interface 312 .

[0033] The HLA besteffort communication control unit 311 controls the HLA besteffort communication for the network communication interface 312 .

[0034] The simulation data communication control unit setting file 313 is a file used for switching the communication control method and setting parameters in the simulation data communication control unit 303. The simulation data communication control unit setting file 313 is read when the LRC 204 is initialized, and the values ​​set during execution are referenced. The settings in the simulation data communication control unit setting file 313 can also be included in an RID (RTI Initialization Definition) file, which is an initial setting file for the RTI 103 defined in the HLA regulations.

[0035] Next, we will explain the operation of the LRC 204. Note that the first embodiment and the second embodiment described below are directed to the processing, functions, operations, etc., involved in transmitting simulation data by the LRC 204, and therefore the scope of the explanation will be limited to those parts.

[0036] A transmission request for simulation data from the Federate program 202 is made by calling the HLAAPI 203 of the HLAAPI processing unit 301 as described above in (1), (3), and (5). When the HLAAPI 203 is called, the HLA service processing unit 302 determines whether to transmit an RO message or a TSO message based on the arguments of the HLAAPI 203, the setting state of the FOM 104, and the like. Based on the determination by the HLA service processing unit 302, the simulation data communication control unit 303 registers the message to be transmitted in one of the RO message transmission queue (HLAreliable) 304, the RO message transmission queue (HLAbesteffort) 306, the TSO message transmission queue (HLAreliable) 305, and the TSO message transmission queue (HLAbesteffort) 307 of the simulation data communication control unit 303.

[0037] Note that the setting values ​​in the FOM definition file 205 are applied as the initial setting for the FOM setting state, but it is also possible to change the setting while the Federate program 202 is running by calling the HLAAPI 203 from the Federate program 202. If the setting is changed while the Federate program 202 is running, the simulation data communication control unit 303 moves each message that was registered in the corresponding transmission queue before the change to the corresponding transmission queue after the change. A method for determining a simulation data transmission method based on the HLA protocol is shown in Figure 4. Figure 4 is a diagram showing a method for determining a simulation data transmission method based on the HLA protocol in the LRC 204 according to the first embodiment.

[0038] In the first embodiment, an example of HLAreliable communication shown by numbers 1, 2, and 5 in Fig. 4 will be described. First, the process up to transmission of the RO message (HLAreliable) shown by numbers 1 and 2 in Fig. 4 according to the first embodiment will be described with reference to Fig. 5. Fig. 5 is a flowchart showing the transmission process of the RO message (HLAreliable) in the LRC 204 according to the first embodiment.

[0039] First, when the HLA service processing unit 302 requests the simulation data communication control unit 303 to transmit an RO message (HLAreliable), the simulation data communication control unit 303 registers the RO message (HLAreliable) in the RO message transmission queue (HLAreliable) 304 (step S101).

[0040] The simulation data communication control unit 303 determines whether the current real-time time has exceeded (previous transmission time + transmission pending time) (step S102). Here, the transmission pending time is a setting value set in the simulation data communication control unit setting file 313. The previous transmission time is the time when the most recent RO message (HLAreliable) was transmitted. If the previous transmission time has not been set because the RO message (HLAreliable) has not yet been transmitted, it may be replaced by the time when the Federate program 202 started execution, for example. Note that here, the case where the current time is the same as the time to be compared is also considered to be exceeded. The same applies hereinafter.

[0041] If the current time has not exceeded (the previous transmission time + the transmission suspension time) (step S102: No), the simulation data communication control unit 303 waits until the current time exceeds (the previous transmission time + the transmission suspension time), i.e., step S102: Yes. Note that if a request to transmit a new RO message (HLAreliable) is made while waiting for step S102: Yes, the simulation data communication control unit 303 registers the newly requested RO message (HLAreliable) in the RO message transmission queue (HLAreliable) 304.

[0042] If the current time has exceeded (the previous transmission time + the transmission hold time) (step S102: Yes), the simulation data communication control unit 303 retrieves all RO messages (HLAreliable) registered in the RO message transmission queue (HLAreliable) 304. The simulation data communication control unit 303 collects all the retrieved RO messages (HLAreliable) into one transmission packet and transmits the HLAreliable to the HLAreliable communication control unit 310 (step S103). When the HLAreliable transmission is completed, the simulation data communication control unit 303 clears the RO message transmission queue (HLAreliable) 304 (step S104).

[0043] As described above, when transmitting an RO message (HLAreliable), the simulation data communication control unit 303 controls transmission according to the transmission suspension time set in the simulation data communication control unit setting file 313. As a result, the simulation data communication control unit 303 can improve the 200 msec communication delay caused by delayed ACK in general TCP communication by, for example, setting the transmission suspension time to a value greater than or equal to 0 and less than 200 msec. Furthermore, in an application system that tolerates a longer communication delay time, the simulation data communication control unit 303 sets the transmission suspension time according to the tolerable communication delay time. This allows the simulation data communication control unit 303 to aggregate RO messages (HLAreliable) for transmission packets, thereby reducing redundant frame division, header processing, and the like in network layers lower than TCP, thereby improving the efficiency of network communication.

[0044] In this way, the simulation data communication control unit 303 buffers RO messages for which a transmission hold time is set in a transmission queue and aggregates and transmits multiple RO messages as a transmission packet based on the characteristics of the application for the RO messages, which are messages transmitted by the Federate 102. The simulation data communication control unit 303 transmits RO messages for which no transmission hold time is set or for which a transmission hold time is set to 0 as a transmission packet without buffering them.

[0045] Next, a process up to transmission of the TSO message (HLAreliable) shown by number 5 in Fig. 4 according to the first embodiment will be described with reference to Fig. 6. Fig. 6 is a flowchart showing a process of transmitting the TSO message (HLAreliable) in the LRC 204 according to the first embodiment.

[0046] First, when the HLA service processing unit 302 requests the simulation data communication control unit 303 to transmit a TSO message (HLAreliable), the simulation data communication control unit 303 registers the TSO message (HLAreliable) in the TSO message transmission queue (HLAreliable) 305 (step S201).

[0047] The simulation data communication control unit 303 determines whether or not a logical time advance request has been received from the HLA service processing unit 302 (step S202). Here, the logical time advance request is a process to be executed based on the next HLAAPI 203 executed by the Federate program 202.

[0048] (7) Logical time progression request using Time Step time progression method Time Advance Request ·Time Advance Request Available (8) Logical time progression request using Event Base time progression method Next Message Request ·Next Message Request Available (9) Logical time progression request based on Optimistic time progression method Flush Queue Request

[0049] These HLAAPIs 203 are HLAAPIs 203 that Federate 102 executing a simulation based on logical time requests from RTI 103 to advance from the currently executed time to the next time. When these HLAAPIs 203 are executed, RTI 103 calculates the time to which the Federate 102 is permitted to advance based on each time advance method. RTI 103 exchanges TSO messages with Federate 102 that have a time stamp earlier than the calculated permitted time, and then notifies the Federate 102 of time advance permission by a Time Advance Grant of the HLAAPI 203. In other words, TSO messages are exchanged between Federate 102 from the time when Federate 102 makes a time advance request to RTI 103 until it receives time advance permission from RTI 103.

[0050] Generally, when the aim is to realize processing of TSO messages as simply as possible, the RTI 103 immediately executes a transmission request from the Federate 102 in TSO message communication between LRCs 204 and stores the message in the TSO message receiving queue 309 of the receiving Federate 102. After a time advance request is made by the receiving Federate 102, the RTI 103 retrieves the TSO message from the TSO message receiving queue 309 according to the permitted time and passes it to the receiving Federate 102. In contrast, the LRC 204 according to this embodiment does not immediately execute transmission processing between LRCs 204, but registers the TSO message (HLAreliable) in the TSO message transmitting queue (HLAreliable) 305 of the transmitting Federate 102 before transmission in order to improve the efficiency of transmission processing by HLAreliable communication of the TSO message.

[0051] If a logical time advance request has not been received from the HLA service processing unit 302 (step S202: No), the simulation data communication control unit 303 waits until a logical time advance request is received from the HLA service processing unit 302, that is, until step S202: Yes. Note that if a request to send a new TSO message (HLAreliable) is made while waiting for step S202: Yes, the simulation data communication control unit 303 registers the newly requested TSO message (HLAreliable) in the TSO message transmission queue (HLAreliable) 305.

[0052] When a logical time advance request is received from the HLA service processing unit 302 (step S202: Yes), the simulation data communication control unit 303 selects a TSO message (HLAreliable) to be transmitted from among the TSO messages (HLAreliable) registered in the TSO message transmission queue (HLAreliable) 305. The simulation data communication control unit 303 collects the selected TSO messages (HLAreliable) to be transmitted into a single transmission packet and transmits the HLAAreliable to the HLA communication control unit 310 (step S203). The simulation data communication control unit 303 uses one of the following selection methods for the TSO messages (HLAreliable) registered in the TSO message transmission queue (HLAreliable) 305. The selection method to be adopted is set in the simulation data communication control unit setting file 313. In other words, the simulation data communication control unit 303 selects a TSO message to be transmitted from among the TSO messages registered in the TSO message transmission queue (HLAreliable) 305 using a selection method set based on the characteristics of the application.

[0053] (A) All registered TSO messages (HLAreliable) (B) A TSO message (HLAreliable) with a time stamp that is equal to or less than the requested time when the sending Federate 102 made a logical time advance request. (C) A TSO message (HLAreliable) with a time stamp that is equal to or less than the permitted time for the logical time advance request made by the sending Federate 102.

[0054] Method (A) can improve communication efficiency because all TSO messages (HLAreliable) registered in the TSO message transmission queue (HLAreliable) 305 are subject to HLAAreliable transmission. However, method (A) has the disadvantage that a large amount of data communication is executed at once, which can take a long time locally when the Federate 102 calls the HLAAPI 203 for a logical time advancement request, and this may hinder smooth execution of the entire system. Method (B) can reduce the number of TSO messages (HLAreliable) to be sent more than method (A). Method (C) can limit the transmission targets to only the minimum number of TSO messages (HLAreliable) necessary for the logical time advancement of the HLA protocol. However, method (C) cannot start transmission processing until the calculation of the permitted time is complete, so it has the disadvantage of having a larger overhead than methods (A) and (B). In this way, the simulation data communication control unit 303, as the aforementioned selection method, targets all TSO messages registered in the TSO message transmission queue (HLAreliable) 305, targets TSO messages that have a time stamp that is equal to or less than the requested time when Federate 102 makes a logical time advancement request, or targets TSO messages that have a time stamp that is equal to or less than the permitted time when Federate 102 makes a logical time advancement request.

[0055] When the HLAreliable transmission in step S203 is completed, the simulation data communication control unit 303 clears the TSO message (HLAreliable) that has been completely transmitted from among the TSO messages (HLAreliable) registered in the TSO message transmission queue (HLAreliable) 305 (step S204).

[0056] As described above, when transmitting a TSO message (HLAreliable), the simulation data communication control unit 303 controls transmission in accordance with the logical time progress being executed in the HLA service processing unit 302. This allows the simulation data communication control unit 303 to aggregate TSO messages (HLAreliable) for transmission packets, thereby reducing redundant frame division, header processing, etc. in network layers lower than TCP, thereby making it possible to improve the efficiency of network communication.

[0057] In this way, the simulation data communication control unit 303 buffers TSO messages, which are messages sent by the Federate 102, in a transmission queue until the Federate 102 advances logical time, and aggregates multiple TSO messages into a transmission packet for transmission.

[0058] Next, the hardware configuration of the LRC 204 according to the first embodiment will be described. In the LRC 204, the HLAAPI processing unit 301, HLA service processing unit 302, simulation data communication control unit 303, and network communication interface 312 are realized by processing circuits. The processing circuit may be a memory that stores programs and a processor that executes the programs stored in the memory, or it may be dedicated hardware. The processing circuit is also called a control circuit.

[0059] FIG. 7 is a diagram illustrating an example of the configuration of a processing circuit 90 when the processing circuit included in the LRC 204 according to the first embodiment is realized by a processor 91 and a memory 92. The processing circuit 90 illustrated in FIG. 7 is a control circuit and includes a processor 91 and a memory 92. When the processing circuit 90 is configured with the processor 91 and the memory 92, each function of the processing circuit 90 is realized by software, firmware, or a combination of software and firmware. The software or firmware is written as a program and stored in the memory 92. In the processing circuit 90, each function is realized by the processor 91 reading and executing the program stored in the memory 92. That is, the processing circuit 90 includes the memory 92 for storing a program that results in the processing of the LRC 204 being executed. This program can also be said to be a program that causes the LRC 204 to execute each function realized by the processing circuit 90. This program may be provided by a storage medium on which the program is stored, or by other means such as a communication medium.

[0060] Here, the processor 91 is, for example, a CPU (Central Processing Unit), a processing device, an arithmetic device, a microprocessor, a microcomputer, or a DSP (Digital Signal Processor), etc. Furthermore, the memory 92 is, for example, a non-volatile or volatile semiconductor memory such as a RAM (Random Access Memory), a ROM (Read Only Memory), a flash memory, an EPROM (Erasable Programmable ROM), or an EEPROM (registered trademark) (Electrically EPROM), a magnetic disk, a flexible disk, an optical disk, a compact disk, a minidisk, or a DVD (Digital Versatile Disc).

[0061] 8 is a diagram showing an example of the configuration of the processing circuit 93 when the processing circuit included in the LRC 204 according to the first embodiment is configured with dedicated hardware. The processing circuit 93 shown in FIG. 8 corresponds to, 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 processing circuit 93 may be partially realized with dedicated hardware and partially realized with software or firmware. In this way, the processing circuit 93 can realize each of the above-described functions by dedicated hardware, software, firmware, or a combination thereof.

[0062] As described above, according to this embodiment, in the LRC 204, when the network communication method for messages sent by the Federate 102 is HLAreliable communication conforming to TCP communication, the simulation data communication control unit 303 buffers the data communication according to the logical time progression, disables the Nagle algorithm of the TCP communication, and aggregates multiple messages into a transmission packet for transmission. This enables the simulation data communication control unit 303 to improve communication efficiency in the distributed simulation system 500 in which multiple simulators are connected.

[0063] Embodiment 2 In the second embodiment, an example of HLA besteffort communication in the Federation 101 using the RTI 103 will be described. Note that the HLA besteffort communication corresponds to numbers 3, 4, and 6 in the above-mentioned FIG.

[0064] First, the process up to transmission of the RO message (HLAbesteffort) shown by numbers 3 and 4 in Fig. 4 according to the second embodiment will be described with reference to Fig. 9. Fig. 9 is a flowchart showing the process of transmitting the RO message (HLAbesteffort) in the LRC 204 according to the second embodiment.

[0065] First, when the HLA service processing unit 302 requests the simulation data communication control unit 303 to transmit an RO message (HLAbesteffort), the simulation data communication control unit 303 registers the RO message (HLAbesteffort) in the RO message transmission queue (HLAbesteffort) 306 (step S301).

[0066] The simulation data communication control unit 303 determines whether the current real time has exceeded (the previous transmission time + the transmission hold time) (step S302). The processing performed here is the same as the processing in the processing flow for transmitting the RO message (HLAreliable) described in FIG. 5 of the first embodiment.

[0067] If the current time has not exceeded (the previous transmission time + the transmission hold time) (step S302: No), the simulation data communication control unit 303 waits until the current time exceeds (the previous transmission time + the transmission hold time), i.e., step S302: Yes. Note that if a request to transmit a new RO message (HLAbesteffort) is made while waiting for step S302: Yes, the simulation data communication control unit 303 registers the newly requested RO message (HLAbesteffort) in the RO message transmission queue (HLAbesteffort) 306.

[0068] If the current time exceeds (the previous transmission time + the transmission hold time) (step S302: Yes), the simulation data communication control unit 303 divides all RO messages (HLAbesteffort) registered in the RO message transmission queue (HLAbesteffort) 306 into the smallest transmission unit of simulation data communication defined by the HLA protocol (step S303). Here, the smallest transmission unit of simulation data communication defined by the HLA protocol is the attribute unit in the case of attribute communication. For example, if two attributes are set in one RO message corresponding to one object, the message is divided into two RO messages, each with one attribute set for the same object. Note that in the case of interaction communication, no division is necessary because the interaction unit is the smallest transmission unit of simulation data communication.

[0069] The simulation data communication control unit 303 sorts the RO messages (HLAbesteffort) in ascending order of data size, i.e., ascending order, in the RO message transmission queue (HLAbesteffort) 306 in which the RO messages (HLAbesteffort) divided into the minimum transmission units of the simulation data communication are registered (step S304). This is a process to minimize the number of transmissions in the process from step S306 onwards, specifically, in the process of sequentially registering the RO messages (HLAbesteffort) in the transmission packet buffer and then transmitting the transmission packet buffer so that the transmission packet buffer size does not exceed the minimum MTU of the network 206.

[0070] The simulation data communication control unit 303 prepares an empty transmission packet buffer with no data registered therein, that is, a size of 0, to be used for HLA besteffort communication (step S305).

[0071] The simulation data communication control unit 303 sorts the RO messages (HLAbesteffort) divided into the smallest transmission units of the simulation data communication in ascending order of data size, and starts a loop process in which the RO messages (HLAbesteffort) are processed sequentially from the first registered RO message (HLAbesteffort) in the registered RO message transmission queue (HLAbesteffort) 306 (step S306).

[0072] In the loop process of step S306, the simulation data communication control unit 303 acquires one RO message (HLAbesteffort) that has been the target of the loop process (step S307).

[0073] The simulation data communication control unit 303 determines whether the size obtained by adding the transmission packet buffer size, the RO message size of the RO message (HLAbesteffort), and the communication header size required for communication is less than or equal to the minimum MTU in the network 206 (step S308).

[0074] Here, the communication header size required for communication is, for example, the sum of the UDP header size required for HLA besteffort communication, the IP (Internet Protocol) header size, the header size required for communication encryption processing, and the like. The value of the communication header size required for communication is set in the simulation data communication control unit setting file 313. Furthermore, the MTU is the maximum frame size used for communication at the data link layer in the network hierarchy; for example, the MTU in standard Ethernet (registered trademark) communication is 1500 bytes. A transmission packet that exceeds the MTU is divided into multiple frames in the network layer above the data link layer and communicated. Dividing a transmission packet into multiple frames for communication is called fragmentation of the transmission packet.

[0075] The minimum MTU in network 206 refers to the minimum MTU value of each subnetwork in a network in which multiple subnetworks are relayed, and is represented as sMTU in Fig. 9. The sMTU value used is the value investigated by network communication interface 312 of LRC 204 using path MTU discovery, but in the case of a network in which path MTU discovery is not available, the value set in simulation data communication control unit setting file 313 may be used.

[0076] If (transmission packet buffer size + RO message size + communication header size) is less than or equal to sMTU (step S308: Yes), the simulation data communication control unit 303 adds the RO message (HLAbesteffort) to the transmission packet buffer (step S309) and executes the next loop processing.

[0077] If (transmission packet buffer size + RO message size + communication header size) exceeds the sMTU (step S308: No), the simulation data communication control unit 303 transmits all messages registered in the transmission packet buffer to the HLAbesteffort communication control unit 311 (step S310). After completing the HLAbesteffort transmission, the simulation data communication control unit 303 clears the transmission packet buffer, registers the RO message (HLAbesteffort) (step S311), and executes the next loop process.

[0078] When the loop processing is completed (step S312), the simulation data communication control unit 303 determines whether the transmission packet buffer size is 0 (step S313). If the transmission packet buffer size is not 0 (step S313: No), the simulation data communication control unit 303 transmits all messages registered in the transmission packet buffer to the HLAbesteffort communication control unit 311 (step S314). If the transmission packet buffer size is 0 (step S313: Yes), or after the HLAbesteffort transmission in step S314 is completed, the simulation data communication control unit 303 clears the RO message transmission queue (HLAbesteffort) 306 (step S315).

[0079] As described above, when transmitting an RO message (HLAbesteffort), the simulation data communication control unit 303 first aggregates the RO message (HLAbesteffort) for transmission packets by controlling transmission in accordance with the transmission suspension time set in the simulation data communication control unit setting file 313. Next, the simulation data communication control unit 303 controls the size of the packets to be transmitted so that it does not exceed the smallest MTU in the network 206, thereby aggregating data smaller than the MTU, thereby improving communication efficiency. Furthermore, the simulation data communication control unit 303 can improve communication reliability in UDP communication by suppressing fragmentation of transmission packets as much as possible.

[0080] Next, a process up to transmission of the TSO message (HLAbesteffort) shown by number 6 in Fig. 4 according to the second embodiment will be described with reference to Fig. 10. Fig. 10 is a flowchart showing a process of transmitting the TSO message (HLAbesteffort) in the LRC 204 according to the second embodiment.

[0081] First, when the HLA service processing unit 302 requests the simulation data communication control unit 303 to transmit a TSO message (HLAbesteffort), the simulation data communication control unit 303 registers the TSO message (HLAbesteffort) in the TSO message transmission queue (HLAbesteffort) 307 (step S401).

[0082] The simulation data communication control unit 303 determines whether or not a logical time advance request has been received from the HLA service processing unit 302 (step S402). The processing performed here is the same as the processing in the processing flow for transmitting the TSO message (HLAreliable) described in FIG. 6 of the first embodiment.

[0083] If a logical time advance request has not been received from the HLA service processing unit 302 (step S402: No), the simulation data communication control unit 303 waits until a logical time advance request is received from the HLA service processing unit 302, that is, until step S402: Yes. Note that if a request to send a new TSO message (HLAbesteffort) is made while waiting for step S402: Yes, the simulation data communication control unit 303 registers the newly requested TSO message (HLAbesteffort) in the TSO message transmission queue (HLAbesteffort) 307.

[0084] When a logical time advance request is received from the HLA service processing unit 302 (step S402: Yes), the simulation data communication control unit 303 registers the TSO message (HLAbesteffort) to be transmitted, among the TSO messages (HLAbesteffort) registered in the TSO message transmission queue (HLAbesteffort) 307, in the TSO message transmission queue (HLAbesteffort) (for transmission), and deletes it from the TSO message transmission queue (HLAbesteffort) 307 (step S403). Note that the method by which the simulation data communication control unit 303 selects the TSO message (HLAbesteffort) to be transmitted is the same as the method by which the TSO message (HLAreliable) is selected in step S203 of FIG. 6 in the first embodiment.

[0085] The subsequent processing is the same as the processing in the flowchart of the transmission processing of the RO message (HLAbesteffort) explained in Fig. 9. The simulation data communication control unit 303 divides all TSO messages (HLAbesteffort) registered in the TSO message transmission queue (HLAbesteffort) (for transmission) into the smallest transmission unit of simulation data communication defined by the HLA regulations (step S404).

[0086] The simulation data communication control unit 303 sorts the TSO messages (HLAbesteffort) in the TSO message transmission queue (HLAbesteffort) (for transmission) in which the TSO messages (HLAbesteffort) divided into the smallest transmission units of the simulation data communication are registered, in ascending order of the data size of the TSO messages (step S405).

[0087] The simulation data communication control unit 303 prepares an empty transmission packet buffer with no data registered therein, that is, a size of 0, to be used for HLA besteffort communication (step S406).

[0088] The simulation data communication control unit 303 sorts the TSO messages (HLAbesteffort) divided into the smallest transmission units of the simulation data communication in ascending order of data size, and starts a loop process in which the TSO messages (HLAbesteffort) are processed sequentially from the TSO message (HLAbesteffort) registered at the top of the registered TSO message transmission queue (HLAbesteffort) (for transmission) (step S407).

[0089] In the loop process of step S407, the simulation data communication control unit 303 acquires one TSO message (HLAbesteffort) that is the target of the loop process (step S408).

[0090] The simulation data communication control unit 303 determines whether the size obtained by adding the transmission packet buffer size, the TSO message size of the TSO message (HLAbesteffort), and the communication header size required for communication is equal to or less than sMTU, which is the minimum MTU in the network 206 (step S409).

[0091] If (transmission packet buffer size + TSO message size + communication header size) is less than or equal to sMTU (step S409: Yes), the simulation data communication control unit 303 adds the TSO message (HLAbesteffort) to the transmission packet buffer (step S410) and executes the next loop processing.

[0092] If (transmission packet buffer size + TSO message size + communication header size) exceeds the sMTU (step S409: No), the simulation data communication control unit 303 transmits all messages registered in the transmission packet buffer to the HLAbesteffort communication control unit 311 (step S411). After completing the HLAbesteffort transmission, the simulation data communication control unit 303 clears the transmission packet buffer, registers the TSO message (HLAbesteffort) (step S412), and executes the next loop process.

[0093] When the loop processing is completed (step S413), the simulation data communication control unit 303 determines whether the transmission packet buffer size is 0 (step S414). If the transmission packet buffer size is not 0 (step S414: No), the simulation data communication control unit 303 transmits all messages registered in the transmission packet buffer to the HLAbesteffort communication control unit 311 (step S415). If the transmission packet buffer size is 0 (step S414: Yes), or after the HLAbesteffort transmission in step S415 is completed, the simulation data communication control unit 303 clears the TSO message transmission queue (HLAbesteffort) (for transmission) (step S416).

[0094] As described above, when transmitting a TSO message (HLAbesteffort), the simulation data communication control unit 303 first aggregates the TSO message (HLAbesteffort) into transmission packets by controlling transmission in accordance with the logical time progress being executed in the HLA service processing unit 302. Next, the simulation data communication control unit 303 controls the size of the packets to be transmitted so that it does not exceed the smallest MTU in the network 206, thereby aggregating data smaller than the MTU, thereby improving communication efficiency. Furthermore, the simulation data communication control unit 303 can improve communication reliability in UDP communication by minimizing fragmentation of transmission packets.

[0095] As described above, according to this embodiment, in the LRC 204, when the network communication method for messages sent by the Federate 102 is HLA besteffort communication conforming to UDP multicast communication, the simulation data communication control unit 303 buffers the data communication so that the size of the transmission packet is equal to or smaller than the minimum MTU of the network, and aggregates multiple messages into a transmission packet for transmission. This allows the simulation data communication control unit 303 to improve communication efficiency in the distributed simulation system 500 in which multiple simulators are connected.

[0096] The configurations shown in the above embodiments are merely examples, and may be combined with other known technologies, or different embodiments may be combined with each other. It is also possible to omit or modify parts of the configurations as long as they do not deviate from the gist of the invention. [Explanation of symbols]

[0097] 101 Federation, 102 Federate, 103 RTI, 104 FOM, 201 Computer, 202 Federate program, 203 HLAAPI, 204 LRC, 205 FOM definition file, 206 Network, 301 HLAAPI processing unit, 302 HLA service processing unit, 303 Simulation data communication control unit, 304 RO message transmission queue (HLAreliable), 305 TSO message transmission queue (HLAreliable), 306 RO message transmission queue (HLAbesteffort), 307 TSO message transmission queue (HLAbesteffort), 308 RO message reception queue, 309 TSO message reception queue, 310 HLAreliable communication control unit, 311 HLAbesteffort communication control unit, 312 Network communication interface, 313 Simulation data communication control unit setting file, 500 Distributed simulation system.

Claims

1. A processing device equipped with middleware that is a run-time infrastructure that provides services in a distributed simulation system based on the High Level Architecture standardized by the Institute of Electrical and Electronics Engineers 1516, a simulation data communication control unit that buffers Received Ordered messages, which are messages sent by a federate, in a transmission queue, each Received Ordered message having a transmission hold time set therefor, based on application characteristics of the Received Ordered messages, and aggregates and transmits a plurality of Received Ordered messages in a transmission packet; A processing device comprising:

2. the simulation data communication control unit transmits the Received Ordered message, for which no transmission hold time is set or for which 0 is set, as a transmission packet without buffering it; 2. The processing device according to claim 1.

3. A processing device equipped with middleware that is a run-time infrastructure that provides services in a distributed simulation system based on the High Level Architecture standardized by the Institute of Electrical and Electronics Engineers 1516, a simulation data communication control unit that buffers Time Stamp Ordered messages, which are messages transmitted by a federate, in a transmission queue until the federate performs logical time progress, and aggregates a plurality of the Time Stamp Ordered messages into a transmission packet and transmits the packet; Equipped with the simulation data communication control unit selects the Time Stamp Ordered Message to be transmitted from the Time Stamp Ordered Messages registered in the transmission queue using a selection method set based on characteristics of an application; A processing device characterized by:

4. the simulation data communication control unit selects all of the Time Stamp Ordered messages registered in the transmission queue as the selection method; 4. The processing device according to claim 3.

5. the simulation data communication control unit selects, as the selection method, the Time Stamp Ordered message to which a Time Stamp that is equal to or less than the requested time when the federate makes a logical time advance request, is assigned; 4. The processing device according to claim 3.

6. the simulation data communication control unit selects, as the selection method, the Time Stamp Ordered message to which a Time Stamp that is equal to or less than the permitted time when the federate makes a logical time advancement request, is assigned; 4. The processing device according to claim 3.

7. the simulation data communication control unit disables the Nagle algorithm and aggregates and transmits a plurality of the messages in a transmission packet when the network communication method of the messages transmitted by the federate is High Level Architecture reliable communication conforming to Transmission Control Protocol communication; 2. The processing device according to claim 1.

8. the simulation data communication control unit aggregates the plurality of messages into a transmission packet and transmits the transmission packet so that the size of the transmission packet is equal to or smaller than the minimum Maximum Transmission Unit in the network when the network communication method of the messages transmitted by the federate is High Level Architecture besteffort communication conforming to User Datagram Protocol multicast communication; 2. The processing device according to claim 1.

9. A processing device according to any one of claims 1 to 8; Multiple federates; A distributed simulation system comprising:

Images