A co-simulation message synchronization system

Abstract

The present specification provides a joint simulation message synchronization system. In the whole message synchronization process, the messages transmitted between the combat simulation software and the network simulation software are intermediate messages for describing original messages and notification messages carrying the identities of the original messages. The actual application data contents of the original messages do not enter the network simulation software side; the network simulation software creates proxy messages according to the intermediate messages and performs network communication simulation. Therefore, the original message object does not need to be serialized, deserialized, parsed or object-converted across software. Thus, the message synchronization does not depend on the parsing and serialization of the message object, nor on the definition of the message object by the specific model, and the network simulation software does not need to obtain the actual application data contents of the original message nor understand the object definition of the original message, thereby not needing to develop deserialization, parsing and object conversion programs for different message object definitions.

Description

Technical Field

[0001] This specification relates to the field of co-simulation technology, such as a co-simulation message synchronization system. Background Technology

[0002] In the field of joint simulation, combat simulation software and network simulation software typically work together. Combat simulation software is responsible for simulating and extrapolating the combat platform and its applications, and generating and processing upper-layer application messages for the combat platform applications. Network simulation software is responsible for simulating network communication processes below the application layer corresponding to the upper-layer application messages. When the two perform joint simulation, message synchronization is required; that is, messages in one simulation software can be synchronized to the other simulation software, and the other simulation software can continue its simulation based on the synchronized information. This message synchronization usually needs to have bidirectional driving capability: the combat simulation software sends application messages to drive the network communication simulation; when a network node in the network simulation successfully receives a message, the reception result or corresponding message information is fed back to the combat platform application in the combat simulation software to drive the combat simulation to continue.

[0003] Currently, there are two main ways to achieve the above message synchronization.

[0004] The first method is message conversion. The combat simulation software serializes its message object and sends it to the network simulation software via the communication interface. The network simulation software receives the message, deserializes and parses it, and creates its own message object based on the message content. When the network node receives the message, the network simulation software serializes its own message object and sends it back to the combat simulation software. The combat simulation software then deserializes and parses the message object to reconstruct it for use by the application layer. This method requires both interconnecting parties to clearly define each other's message objects. However, simulation message objects are usually defined by specific models and are not standardized data, resulting in significant differences between different models. For example, some tactical data link models add a large amount of tactical message content to their base classes, and some member definitions are not derived from communication standards but are defined by the model itself. Therefore, using message conversion requires developing corresponding serialization, deserialization, parsing, and object conversion programs for different message object definitions, leading to high implementation costs.

[0005] The second method is the message tunneling method. This method uses network simulation messages as a tunnel to pass through combat simulation messages. Although this method does not require the network simulation software to reconstruct all combat simulation message content according to its own message object format, combat simulation message objects are usually program data bodies containing complex structures such as inheritance and pointers, rather than simple messages. Therefore, when passing through across simulation software, it is still necessary to solve the problems of message object serialization, deserialization, and conversion between objects.

[0006] It is evident that both of the above methods treat the upper-layer application message objects of the combat simulation software as objects for cross-software transmission, parsing, or pass-through, failing to separate the actual application data content that the combat simulation software is concerned with from the network transmission characteristics required for network communication simulation by the network simulation software. Due to the complexity and non-standardization of message objects in heterogeneous simulation software, existing message synchronization methods struggle to form standardized, universal, and productized joint simulation message synchronization solutions. Typically, they can only be customized for specific projects, resulting in high development costs. Summary of the Invention

[0007] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0008] Firstly, embodiments of this specification propose a joint simulation message synchronization system, including combat simulation software and network simulation software; wherein, the combat simulation software is used to process upper-layer application messages, and the network simulation software is used to perform network communication simulation on the network transmission process below the application layer corresponding to the upper-layer application messages; The combat simulation software includes a sender model instance and at least one receiver model instance. When the sender model instance obtains the original message to be synchronized to the receiver model instance, it puts the original message into a cache queue and sends an intermediate message to the network simulation software. The intermediate message has network transmission characteristics describing the original message but does not carry the actual application data content of the original message. The network transmission characteristics include at least the identifier of the original message. The network simulation software creates a proxy message based on the network transmission characteristics carried by the intermediate message, and uses the proxy message to perform network communication simulation. After the proxy message is received in the network communication simulation, the network simulation software sends a notification message to the corresponding receiver model instance. The notification message carries the identifier of the original message. The receiver model instance searches for and reads the corresponding original message from the cache queue according to the identifier of the original message carried in the received notification message, thus completing the message synchronization process between the sender model instance and the receiver model instance.

[0009] The co-simulation message synchronization system provided in the embodiments of this specification has at least the following technical effects: Throughout the message synchronization process, the combat simulation software and the network simulation software exchange intermediate messages M, which describe the original message P and are used for network communication simulation, and notification messages M' carrying the identifier of the original message P. The actual application data content of the original message P does not enter the network simulation software side, but is retained in the buffer queue on the combat simulation software side before being read by the receiver. The network simulation software creates a proxy message P' based on the intermediate message M and performs network communication simulation. Therefore, in the above process, there is no need for cross-software serialization, deserialization, parsing, or object conversion of the original message P. Thus, message synchronization does not depend on the parsing and serialization of message objects, nor on the specific model's definition of message objects. The network simulation software does not need to obtain the actual application data content of the original message P, nor does it need to understand the object definition of the original message P, thereby eliminating the need to develop deserialization, parsing, and object conversion programs for different message object definitions. The combat simulation software and the network simulation software each manage their own data. The combat simulation software retains and consumes the original message P, while the network simulation software creates and uses a proxy message P' for network communication simulation. The two simulation software programs are decoupled, reducing coupling between them, and message synchronization is transparent to the upper-layer applications of the combat simulation software. The intermediate message M and the proxy message P' only involve standardized descriptive information or network transmission-related elements such as the identifier, message length, and lower-layer protocol interface control information of the original message P, and are unrelated to the custom message objects defined by the specific model. Therefore, it has good model adaptability and eliminates the need to develop serialization, deserialization, and object conversion programs for different communication protocols or different simulation models, thereby reducing the development cost of joint simulation. Based on the above characteristics, this application enables message synchronization in joint simulation to be implemented in a standardized, universal, and productized manner.

[0010] Furthermore, by setting up twin proxy model instances in the network simulation software that correspond one-to-one with the sender model instance and the receiver model instance, the message synchronization between model instances on the combat simulation software side is mapped to the network communication simulation process between the corresponding proxy model instances on the network simulation software side. This allows the message synchronization process on the combat simulation software side to complete the network communication simulation with the help of the proxy model instances on the network simulation software side.

[0011] Furthermore, when the intermediate message M carries information including message length and lower-layer protocol interface control information, the proxy message P' has the same amount of data as the original message P in the network transmission simulation, and can be sent and processed by the lower-layer protocol, thus enabling the network communication simulation to reflect the network transmission situation under the data volume and interface control conditions corresponding to the original message P.

[0012] Furthermore, when placing the original message P into the cache queue, it is first determined whether the cache queue is full. If the cache queue is full, an alert is sent to the user and the original message P is discarded. This allows the user to be informed of the cache queue being full in a timely manner and avoids system abnormalities caused by cache queue overflow.

[0013] Furthermore, a sequence number is set for the original message P, and the value of the sequence number is the number of receiver model instances corresponding to the original message P. This can record the number of receiver model instances that have not yet completed message synchronization, so that the original message P in the cache queue is not deleted before it is received by the last receiver model instance. When the sequence number is greater than 0, the original message P is read and retained in a copy manner, and when the sequence number is equal to 0, the original message P is retrieved and received. This can ensure that the same original message P can be correctly read and synchronized by multiple receiver model instances in sequence.

[0014] Furthermore, by setting a timestamp for the original message P and performing a traversal and cleanup of the cache queue each time a message is received, and deleting cached messages whose message cache delay time meets the preset cache cleanup conditions, it is possible to prevent some messages from staying in the cache queue for a long time. Moreover, deleting the cached message when the message cache delay time exceeds the preset delay threshold can prevent the cached message from staying in the cache queue indefinitely and continuously occupying cache space.

[0015] The above general description and the descriptions below are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0016] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of a co-simulation message synchronization method based on message transformation in related technologies; Figure 2 This is a schematic diagram of the structure of the co-simulation message synchronization system provided in the embodiments of this specification; Figure 3 This is a flowchart of the sending side's processing flow for the buffer queue provided in the embodiments of this specification; Figure 4 This is a flowchart of the processing flow of the cache queue when the receiver model instance provided in the embodiments of this specification receives a message. Detailed Implementation

[0017] To provide a more detailed understanding of the features and technical content of the embodiments of this specification, the implementation of the embodiments is described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this specification. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0018] The terms "first," "second," etc., in the description, claims, and accompanying drawings of the embodiments herein are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the present specification described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0019] In the embodiments of this specification, the terms "upper," "lower," "inner," "middle," "outer," "front," and "rear," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily used to better describe the embodiments of this specification and their implementations, and are not intended to limit the indicated devices, elements, or components to having a specific orientation, or to construct and operate in a specific orientation. Furthermore, some of the above terms may be used to indicate other meanings besides orientation or positional relationship; for example, the term "upper" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in the embodiments of this specification according to the specific circumstances.

[0020] Furthermore, the terms "set up," "connect," and "fix" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or it can be an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in the embodiments of this specification according to the specific circumstances.

[0021] Unless otherwise stated, the term "multiple" means two or more.

[0022] In the embodiments described in this specification, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0023] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of this specification can be combined with each other.

[0025] In joint simulations using combat simulation software and network simulation software, messages generated by one simulation software need to be synchronized to the other simulation software to drive its continued simulation. The reason existing message synchronization methods are difficult to standardize, generalize, and productize is fundamentally because these methods treat the message objects generated by the combat simulation software themselves as objects to be transmitted, parsed, or transparently passed across software. Specifically, such as... Figure 1 As shown, when using message conversion, the network simulation software must understand the message object definition of the combat simulation software in order to deserialize, parse, and reconstruct its own message object from the received message. When using message tunneling, although combat simulation messages are transmitted through tunnels, they are still program data bodies containing complex structures such as inheritance and pointers, requiring serialization, deserialization, and object conversion during cross-software transmission. Furthermore, simulation message objects are typically defined by specific models and are not standardized data, resulting in significant differences between models. Therefore, a corresponding conversion program needs to be developed for each message object definition, leading to joint simulation solutions that can only be customized for specific projects, resulting in high costs.

[0026] The inventors recognized that combat simulation software and network simulation software have a hierarchical relationship in joint simulation. This hierarchical relationship does not refer to a master-slave relationship in deployment structure, invocation, or control, but rather to the different simulation levels they correspond to in joint simulation message processing. The combat simulation software runs upper-level business models such as combat platform models, equipment models, or mission models, and the raw messages it generates and consumes belong to upper-level application messages; the network simulation software is used to simulate network communication processes below the application layer corresponding to these upper-level application messages.

[0027] Based on the aforementioned hierarchical relationship, the original message can be decomposed into two layers of information: first, the actual application data content for the upper-layer applications of the combat simulation software; and second, the network transmission-related information for the lower-layer network communication simulation of the network simulation software. The actual application data content expresses the business information between combat platform models, equipment models, or mission models, and drives the upper-layer business model of the receiver to continue simulation after successful reception by the receiving model instance. The network transmission-related information enables the network simulation software to encapsulate, transmit, and receive data packets corresponding to the original message below the application layer.

[0028] Therefore, for network simulation software, the specific operational semantics carried by the original message are not a necessary input for performing network communication simulation. The network simulation software only needs to obtain network transmission-related information that enables it to create and send proxy messages, such as message length and lower-layer protocol interface control information. By establishing a correspondence between these proxy messages and the original messages cached on the combat simulation software side, the software can then use the proxy messages for network communication simulation. The proxy messages only need to represent the original messages at the network transmission layer; they do not need to carry the actual application data content of the original messages, nor do they need to have the same object member definitions, inheritance relationships, pointer relationships, memory storage structures, or code implementations as the original messages.

[0029] Existing message conversion and message tunneling methods do not utilize the aforementioned upper-lower-layer relationship. Instead, they treat the message objects generated by the combat simulation software as the objects for cross-software transmission, parsing, or pass-through. This requires the network simulation software to understand the definition of the message objects on the combat simulation software side and perform serialization, deserialization, parsing, or object conversion. Since simulation message objects are usually defined by specific models, and there are significant differences between message objects of different communication protocols and different simulation models, existing methods are difficult to standardize, generalize, and productize. The joint simulation message synchronization system proposed in the embodiments of this specification utilizes the relationship that upper-layer application content and lower-layer network transmission behavior can be processed separately. It transforms the cross-software synchronization object from the original message object itself into standardized descriptive information of the original message and an identification notification after successful reception.

[0030] To achieve message synchronization without transmitting, parsing, or transparently transmitting message objects from combat simulation software across software, in some examples, such as Figure 2 As shown, this application provides a joint simulation message synchronization system, including combat simulation software 100 and network simulation software 200. The combat simulation software 100 is used to process upper-layer application messages, and the network simulation software 200 is used to simulate network communication processes below the application layer corresponding to the upper-layer application messages. The combat simulation software 100 includes a sender model instance A and at least one receiver model instance B.

[0031] When sender model instance A receives the original message P to be synchronized to receiver model instance B, sender model instance A does not send the original message P to network simulation software 200. Instead, it places the original message P in the buffer queue 300 for retention and generates an intermediate message M to send to network simulation software 200. This intermediate message M carries information describing the original message P and used for network communication simulation. This information includes the identifier of the original message P, the message length, and the lower-layer protocol interface control information. The intermediate message M does not carry the actual application data content of the original message P. The identifier is used to establish the correspondence between the original message P and the proxy message P', and the message length and the lower-layer protocol interface control information are used to enable network simulation software 200 to create and send the proxy message P'. In other words, the actual application data content of the original message P is retained in the buffer queue 300 on the combat simulation software 100 side. Only the intermediate message M, which describes the original message P and is used for network communication simulation, is transmitted across software. In this way, the network simulation software 200 does not need to obtain the actual application data content of the original message P, nor does it need to understand the object definition of the original message P, thus eliminating the need to develop deserialization, parsing, and object conversion programs for different message object definitions.

[0032] After receiving the intermediate message M, the network simulation software 200 creates a proxy message P' based on the information carried by the intermediate message M, and uses the proxy message P' to perform network communication simulation. Since the proxy message P' is a message object created by the network simulation software 200 based on the information carried by the intermediate message M, used for network communication simulation below the application layer, it only needs to represent a data packet with the same network transmission-related elements as the original message P at the network transmission layer, without needing to carry the actual application data content of the original message P. Therefore, the proxy message P' is not a copy of the original message P; the two only share network transmission-related elements, while other information, memory storage structure, and even code implementation can be completely different.

[0033] In the example using the twin proxy model described below, after the proxy message P' is received in the network communication simulation, the receiver proxy model instance B' in the network simulation software 200 sends a notification message M' to its associated receiver model instance B. This notification message M' carries the identifier of the original message P. Since the proxy message P' and the original message P have the same identifier, the receiver model instance B can find and read the corresponding original message P from the buffer queue 300 based on the identifier carried in the notification message M', thereby completing the message synchronization processing between the sender model instance A and the receiver model instance B. After reading the original message P, the receiver model instance B can continue the simulation based on the actual application data content carried by the original message P. In other words, the backhaul synchronization does not transmit a specific message object, but rather points back to the network reception result of the original message P in the buffer queue 300 in the form of an identifier.

[0034] Therefore, it can be seen that during the entire synchronization process, the only messages transmitted between the combat simulation software 100 and the network simulation software 200 are the intermediate message M, which describes the original message P and is used for network communication simulation, and the notification message M' carrying an identifier. The original message P, as a message object, is never serialized, deserialized, parsed, or converted across software. Thus, this system does not rely on message object parsing and serialization, and is completely transparent to the upper-level applications of the combat simulation software 100. The two simulation software programs manage their own data and are decoupled from each other. Furthermore, since the intermediate message M and the proxy message P' only involve standardized network transmission-related elements and are unrelated to specific model-defined message objects, the model adaptability is good. There is no need to develop serialization, deserialization, and object conversion programs for different communication protocols or different simulation models, thereby reducing the development cost of joint simulation and enabling this message synchronization scheme to become a standardized, universal, and product-oriented solution.

[0035] In some examples, the proxy message P' has the same identifier, message length, and lower-layer protocol interface control information as the original message P, but does not carry the actual application data content of the original message P. The purpose of the network simulation software 200 in creating the proxy message P' is to obtain a data packet with network transmission-related elements consistent with the original message P in its own network simulation environment, so as to encapsulate, transmit, and receive the data packet. As long as the proxy message P' is consistent with the original message P in network transmission-related elements such as identifier, message length, and lower-layer protocol interface control information, the result of the network communication simulation can accurately reflect the transmission of the original message P in the network; as for the actual application data content inside the original message P, it is irrelevant to the network transmission process, so the proxy message P' does not need to carry it.

[0036] In some examples, the intermediate message M carries information including the identifier of the original message P, the message length of the original message P, and lower-layer protocol interface control information. The message length ensures that the proxy message P' created by the network simulation software 200 has the same data volume as the original message P in the network transmission simulation; the lower-layer protocol interface control information is used by the lower-layer protocol to process the transmission of the proxy message P'. In some examples, when using the TCP protocol for network communication simulation, the lower-layer protocol interface control information includes the receiver's port number and IP address.

[0037] In some examples, the cache queue 300 is located on the combat simulation software 100 side. By setting the cache queue 300 on the combat simulation software 100 side, the actual application data content of the original message P is always kept on the side of the combat simulation software 100 that generates and consumes the content. The network simulation software 200 does not access the actual application data content, and the two manage their own data, thereby reducing the coupling between the two simulation software.

[0038] In some examples, the identifier of the original message P is an auto-incrementing integer. Each time the sender model instance A acquires a raw message P to be synchronized, it assigns it an auto-incrementing integer as an identifier, ensuring that each raw message P has a unique identifier. This allows the receiver model instance B to accurately locate the corresponding raw message P from the cache queue 300 based on the identifier. In other examples, provided that a unique correspondence can be guaranteed, the identifier can be a unique message ID; for example, this unique ID is an auto-incrementing integer.

[0039] In some examples, such as Figure 2 As shown, the network simulation software 200 includes a sender proxy model instance A' associated with the sender model instance A, and a receiver proxy model instance B' associated with the receiver model instance B. Specifically, sender model instance A and sender proxy model instance A' are in a one-to-one twin relationship, and receiver model instance B and receiver proxy model instance B' are also in a one-to-one twin relationship.

[0040] Accordingly, when sender model instance A sends an intermediate message M to network simulation software 200, it means that sender model instance A sends intermediate message M to sender proxy model instance A'. When network simulation software 200 creates proxy message P' based on the information carried by intermediate message M and performs network communication simulation, it means that sender proxy model instance A' creates proxy message P' based on the information carried by intermediate message M and synchronizes proxy message P' to receiver proxy model instance B'. Here, proxy message P' does not carry the actual application data content of the original message P. When network simulation software 200 sends notification message M' to receiver model instance B, it means that receiver proxy model instance B' sends notification message M' to its associated receiver model instance B after receiving proxy message P'. By setting up one-to-one corresponding twin proxy model instances for each model instance on the combat simulation software 100 side in network simulation software 200, message synchronization between model instances on the combat simulation software 100 side is mapped to the network communication simulation process between corresponding proxy model instances on the network simulation software 200 side.

[0041] In some examples, the sending agent model instance A' synchronizes the agent message P' to the receiving agent model instance B', including: the sending agent model instance A' encapsulating the agent message P' through a lower-layer protocol and sending it. In some examples, the receiving agent model instance B' receiving the agent message P' means that the agent message P' is successfully received by the application layer model of the receiving agent model instance B' after network communication simulation. During network communication simulation, the agent message P' needs to be encapsulated and transmitted by a lower-layer protocol and finally determined to be successfully received by the application layer model on the receiving side before the subsequent notification message M' is sent back; if the agent message P' is not successfully received in the network communication simulation, the notification message M' is not sent back.

[0042] In some examples, during network communication simulations, the proxy message P' can be simulated for wireless or wired transmission through various lower-layer protocol simulation models. For instance, in the physical layer simulation, antenna gain, signal-to-noise ratio, bit error rate, channel fading, received power, and error distribution can be calculated and verified. After the proxy message P' is received layer by layer, the application layer model on the receiving side ultimately determines whether it has been successfully received.

[0043] The following is combined with Figure 2The scenario illustrated here illustrates the message synchronization process of this system. Sender model instance A generates an original message P to be synchronized to receiver model instances B and C. Sender model instance A places the original message P in buffer queue 300 and sends an intermediate message M to network simulation software 200. In network simulation software 200, sender agent model instance A' creates an agent message P' based on the intermediate message M and synchronizes the agent message P' to receiver agent model instances B' and C' associated with receiver model instances B and C, respectively. After successfully receiving the agent message P', receiver agent model instances B' and C' each send a notification message M' carrying the identifier of the original message P to receiver model instances B and C, respectively. Receiver model instances B and C, based on the identifier in their respective received notification messages M', search for and read the same original message P from buffer queue 300. Thus, the same original message P in buffer queue 300 can be shared and read by multiple receiver model instances.

[0044] In other examples, the co-simulation message synchronization system of this application can also be extended to co-simulation between other discrete event simulation tools and network simulation tools, and the message synchronization process is the same as described above.

[0045] While the aforementioned cross-layer proxy synchronization mechanism avoids cross-software conversion of message objects, it introduces additional overhead for message caching compared to message conversion and message tunneling methods because the original message P is stored in the cache queue 300 and only read according to its identifier after successful reception by the receiver. This overhead mainly stems from two aspects: first, the original message P sent by the sender model instance A may be broadcast to multiple receiver model instances, and a single original message P may be received by multiple receiver model instances; second, due to network routing, different receiver model instances may receive the same original message P at different times. For these reasons, the original message P in the cache queue 300 must be cleared only after all receiver model instances have completed receiving it. To manage the cache queue 300 and control the aforementioned caching overhead, in some examples, this application employs the following cache management mechanism for the cache queue 300.

[0046] Figure 3 The following examples illustrate the processing flow of the sender side to buffer queue 300. For instance... Figure 3 As shown, when sender model instance A sends the original message P, it first checks whether the buffer queue 300 is full. If the buffer queue 300 is full, it alerts the user and discards the original message P. If the buffer queue 300 is not full, it sets an identifier, sequence number, and timestamp for the original message P and puts the original message P into the buffer queue 300. The following explains each of the above processes.

[0047] In some examples, such as Figure 3As shown, when sender model instance A puts the original message P into buffer queue 300, it first checks whether buffer queue 300 is full: if buffer queue 300 is not full, it puts the original message P into buffer queue 300; if buffer queue 300 is full, it alerts the user and discards the original message P. In this way, when the capacity of buffer queue 300 is insufficient, the user is promptly informed of the full buffer queue 300 through an alert, and the current original message P is discarded, thereby avoiding system abnormalities caused by buffer queue 300 overflow.

[0048] Since the same original message P may be received by multiple receiver model instances, in order to prevent the original message P in the cache queue 300 from being deleted before being received by the last receiver model instance, in some examples, such as Figure 3 As shown, when sender model instance A places the original message P into buffer queue 300, it sets a sequence number for the original message P. The value of this sequence number is the number of receiver model instances. This sequence number is used to record the number of receiver model instances that have not yet completed message synchronization. For example, the number of receiver model instances can be the total number of communicators identical to sender model instance A in the simulation minus 1. That is, among the communicators in the simulation, except for the communicator where sender model instance A is located, all other communicators are receivers of the original message P.

[0049] To further control the additional overhead of the cache queue 300 and prevent some original messages P from remaining in the cache queue 300 for a long time, in some examples, such as Figure 3 As shown, when the sender model instance A puts the original message P into the buffer queue 300, it sets a timestamp for the original message P. This timestamp is the simulation time when the original message P is put into the buffer queue 300. This timestamp is used to subsequently calculate the retention time of the original message P in the buffer queue 300.

[0050] Figure 4 The following examples illustrate the processing flow of the buffer queue 300 when a receiver model instance receives messages. For instance... Figure 4 As shown, the receiver model instance finds the corresponding original message P in the cache queue 300 based on the identifier carried in the notification message M', decrements the sequence number of the original message P by 1, and performs retrieval or copying processing on the original message P based on whether the sequence number is 0; thereafter, the receiver model instance traverses other cached messages in the cache queue 300 and deletes cached messages whose message cache delay time meets the preset cache cleanup conditions.

[0051] Accordingly, in some examples, such as Figure 4As shown, when a receiver model instance searches for and reads the corresponding original message P from the cache queue 300, it decrements the sequence number of the original message P by 1 after finding it. If the sequence number is greater than 0, it indicates that there may be other receiver model instances that have not yet received the message, so the original message P is copied to obtain a copied message (i.e., ...). Figure 4 The original message P remains in the cache queue 300, and the receiving model instance receives the copied message. When the sequence number is 0, it indicates that the current receiving model instance is the last receiver, so the original message P is retrieved from the cache queue 300 and received. Since the original message P in the cache queue 300 is read and retained by copying when the sequence number is greater than 0, the original message P will not be deleted prematurely before it is determined whether there are other receiving model instances that will receive it, thus ensuring that the same original message P can be correctly read by each receiving model instance in sequence.

[0052] Based on setting this timestamp, in some examples, such as Figure 4 As shown, each time the receiver model instance receives a message, it also performs a cleanup of the cache queue 300: it iterates through all cached messages in the cache queue 300 except for the currently found original message P; for each cached message, it calculates the message cache delay duration, which is the difference between the current simulation time and the timestamp of the other cached message; if the message cache delay duration meets the preset cache cleanup conditions, it deletes the other cached message. In this way, by triggering a cleanup every time a message is received, cached messages whose retention time meets the preset cache cleanup conditions are deleted from the cache queue 300, thereby limiting the additional overhead of the cache queue 300.

[0053] In some examples, the preset cache cleanup condition is: the message cache latency exceeds a preset latency threshold; in other examples, the preset cache cleanup condition is: the message cache latency is greater than or equal to the latency threshold. Both the latency threshold and the size of the cache queue 300 are preset values. When the message cache latency of a cached message meets the preset cache cleanup condition, the cached message is deleted to prevent it from indefinitely remaining in the cache queue 300 and continuously occupying cache space. Both the latency threshold and the size of the cache queue 300 can be pre-configured by the user according to simulation needs.

[0054] The aforementioned cache capacity management, sequence number counting and copying / retrieval, and cache timeout cleanup together constitute the cache management mechanism of cache queue 300. Cache capacity management prevents cache queue 300 from overflowing, sequence number counting and copying / retrieval ensure that the same original message P can be received sequentially by multiple receiver model instances, and cache timeout cleanup limits the space occupied by cache queue 300. All of the above cache management mechanisms are executed by software.

[0055] Compared with existing message synchronization schemes that employ message conversion and message tunneling methods, the co-simulation message synchronization system provided in this application has at least the following technical advantages: Throughout the message synchronization process, the combat simulation software and the network simulation software exchange intermediate messages M, which describe the original message P and are used for network communication simulation, and notification messages M' carrying the identifier of the original message P. The actual application data content of the original message P does not enter the network simulation software side, but is retained in the buffer queue on the combat simulation software side before being read by the receiver. The network simulation software creates a proxy message P' based on the intermediate message M and performs network communication simulation. Therefore, in the above process, there is no need for cross-software serialization, deserialization, parsing, or object conversion of the original message P. Thus, message synchronization does not depend on the parsing and serialization of message objects, nor on the specific model's definition of message objects. The network simulation software does not need to obtain the actual application data content of the original message P, nor does it need to understand the object definition of the original message P, thereby eliminating the need to develop deserialization, parsing, and object conversion programs for different message object definitions. The combat simulation software and the network simulation software each manage their own data. The combat simulation software retains and consumes the original message P, while the network simulation software creates and uses a proxy message P' for network communication simulation. The two simulation software programs are decoupled, reducing coupling between them, and message synchronization is transparent to the upper-layer applications of the combat simulation software. The intermediate message M and the proxy message P' only involve standardized descriptive information or network transmission-related elements such as the identifier, message length, and lower-layer protocol interface control information of the original message P, and are unrelated to the custom message objects defined by the specific model. Therefore, it has good model adaptability and eliminates the need to develop serialization, deserialization, and object conversion programs for different communication protocols or different simulation models, thereby reducing the development cost of joint simulation. Based on the above characteristics, this application enables message synchronization in joint simulation to be implemented in a standardized, universal, and productized manner.

[0056] Furthermore, by setting up twin proxy model instances in the network simulation software that correspond one-to-one with the sender model instance and the receiver model instance, the message synchronization between model instances on the combat simulation software side is mapped to the network communication simulation process between the corresponding proxy model instances on the network simulation software side. This allows the message synchronization process on the combat simulation software side to complete the network communication simulation with the help of the proxy model instances on the network simulation software side.

[0057] Furthermore, when the intermediate message M carries information including message length and lower-layer protocol interface control information, the proxy message P' has the same amount of data as the original message P in the network transmission simulation, and can be sent and processed by the lower-layer protocol, thus enabling the network communication simulation to reflect the network transmission situation under the data volume and interface control conditions corresponding to the original message P.

[0058] Furthermore, when placing the original message P into the cache queue, it is first determined whether the cache queue is full. If the cache queue is full, an alert is sent to the user and the original message P is discarded. This allows the user to be informed of the cache queue being full in a timely manner and avoids system abnormalities caused by cache queue overflow.

[0059] Furthermore, a sequence number is set for the original message P, and the value of the sequence number is the number of receiver model instances corresponding to the original message P. This can record the number of receiver model instances that have not yet completed message synchronization, so that the original message P in the cache queue is not deleted before it is received by the last receiver model instance. When the sequence number is greater than 0, the original message P is read and retained in a copy manner, and when the sequence number is equal to 0, the original message P is retrieved and received. This can ensure that the same original message P can be correctly read and synchronized by multiple receiver model instances in sequence.

[0060] Furthermore, by setting a timestamp for the original message P and performing a traversal and cleanup of the cache queue each time a message is received, and deleting cached messages whose message cache delay time meets the preset cache cleanup conditions, it is possible to prevent some messages from staying in the cache queue for a long time. Moreover, deleting the cached message when the message cache delay time exceeds the preset delay threshold can prevent the cached message from staying in the cache queue indefinitely and continuously occupying cache space.

[0061] The foregoing description and accompanying drawings fully illustrate embodiments of this specification to enable those skilled in the art to practice them. Other embodiments may include structural and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included or substituted for parts and features of other embodiments. The embodiments of this specification are not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from their scope. The scope of this specification is limited only by the appended claims.

Claims

1. A co-simulation message synchronization system, characterized in that, It includes combat simulation software and network simulation software; wherein, the combat simulation software is used to process upper-layer application messages, and the network simulation software is used to perform network communication simulation on the network transmission process below the application layer corresponding to the upper-layer application messages; The combat simulation software includes a sender model instance and at least one receiver model instance. When the sender model instance obtains the original message to be synchronized to the receiver model instance, it puts the original message into a cache queue and sends an intermediate message to the network simulation software. The intermediate message has network transmission characteristics describing the original message but does not carry the actual application data content of the original message. The network transmission characteristics include at least the identifier of the original message. The network simulation software creates a proxy message based on the network transmission characteristics carried by the intermediate message, and uses the proxy message to perform network communication simulation. After the proxy message is received in the network communication simulation, the network simulation software sends a notification message to the corresponding receiver model instance. The notification message carries the identifier of the original message. The receiver model instance searches for and reads the corresponding original message from the cache queue according to the identifier of the original message carried in the received notification message, thus completing the message synchronization process between the sender model instance and the receiver model instance.

2. The co-simulation message synchronization system according to claim 1, characterized in that, The network simulation software includes a sender proxy model instance associated with the sender model instance and a receiver proxy model instance associated with the receiver model instance; wherein, the sender model instance and the sender proxy model instance have a one-to-one twin relationship, and the receiver model instance and the receiver proxy model instance have a one-to-one twin relationship. The sending of intermediate messages by the sender model instance to the network simulation software includes: the sending of intermediate messages by the sender model instance to the sender proxy model instance; The network simulation software creates a proxy message based on the network transmission characteristics and uses the proxy message to perform network communication simulation, including: the sender proxy model instance creates the proxy message based on the network transmission characteristics carried by the intermediate message, and synchronizes the proxy message to the receiver proxy model instance; wherein, the proxy message does not carry the actual application data content of the original message; The network simulation software sends a notification message to the receiver model instance, including: after receiving the proxy message, the receiver proxy model instance sends the notification message to the receiver model instance associated with it.

3. The co-simulation message synchronization system according to claim 1, characterized in that, The network transmission characteristics also include at least the message length of the original message and the lower-layer protocol interface control information.

4. The co-simulation message synchronization system according to claim 1, characterized in that, The sender model instance places the original message into a cache queue, including: Determine whether the cache queue is full; If not, the original message is placed in the cache queue; If so, alert the user and discard the original message.

5. The co-simulation message synchronization system according to claim 1, characterized in that, The sender model instance is also used to set a sequence number for the original message when the original message is placed in the cache queue, and the value of the sequence number is the number of receiver model instances.

6. The co-simulation message synchronization system according to claim 1, characterized in that, The sender model instance is also used to set a timestamp for the original message when it is placed in the cache queue. The timestamp is the simulation time when the original message is placed in the cache queue.

7. The co-simulation message synchronization system according to claim 5, characterized in that, The receiver model instance searches for and reads the corresponding original message from the cache queue, including: After locating the original message, decrement the sequence number of the original message by 1; When the sequence number is greater than 0, the original message is copied to obtain a copied message, and the original message is stored in the cache queue. The receiver model instance receives the copied message.

8. The co-simulation message synchronization system according to claim 7, characterized in that, The receiver model instance searches for and reads the corresponding original message from the cache queue, and also includes: When the sequence number is 0, the original message is retrieved from the cache queue and received.

9. The co-simulation message synchronization system according to claim 6, characterized in that, The receiver model instance is also used to clean up the cache queue once each time a message is received, the cleanup including: Iterate through the cached messages in the cache queue, excluding the original message; Calculate the message cache delay duration of the other cached messages, where the message cache delay duration is the difference between the current simulation time and the timestamp of the other cached messages; When the message cache delay time meets the preset cache cleanup conditions, the other cached messages are deleted.

10. The co-simulation message synchronization system according to claim 9, characterized in that, The preset cache cleanup condition is: the message cache delay duration exceeds a preset delay threshold; wherein, the delay threshold and the size of the cache queue are both preset values.

Images