Configuration file-based communication method, apparatus, device, medium and product

Abstract

The application relates to the field of simulation communication technology and provides a communication method and device based on a configuration file, equipment, a medium and a product. The method comprises the following steps: in response to the start of a simulation node, loading a configuration file corresponding to the simulation node; the configuration file comprises the enabling identifiers of multiple communication protocols; the enabling identifier of each communication protocol is used for indicating whether the communication protocol is in an enabling state; based on the enabling identifier, loading a first protocol communication component corresponding to the communication protocol currently in the enabling state in the configuration file; registering the communication capability of the first protocol communication component to a preset target communication interface; the target communication interface is irrelevant to the protocol type; and the first protocol communication component is called through the target communication interface to perform data transceiving. The communication method based on the configuration file can effectively improve the protocol compatibility and code reusability and reduce the operation and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of simulation communication technology, and in particular to a communication method, apparatus, device, medium and product based on a configuration file. Background Technology

[0002] In tactical simulation training systems, heterogeneous simulation nodes need to communicate across platforms with low latency, but different vendors support different communication protocols, such as High-Level Architecture (HLA), Data Distribution Service (DDS), Kafka, User Datagram Protocol (UDP) multicast, etc.

[0003] Existing multi-protocol adaptation middleware is mainly geared towards general IoT scenarios and is not optimized for simulation real-time performance, synchronization, and heterogeneous integration. Therefore, existing technologies suffer from poor protocol compatibility, low code reusability, and rigid configuration due to hard-coded protocol parameters, which increases R&D and maintenance costs. Summary of the Invention

[0004] This application provides a communication method, apparatus, device, medium, and product based on a configuration file to solve the problems of poor protocol compatibility, low code reusability, and rigid configuration caused by hard-coded protocol parameters in the prior art.

[0005] This application provides a configuration file-based communication method, including the following steps: In response to the startup of the simulation node, the configuration file corresponding to the simulation node is loaded; the configuration file includes multiple communication protocol enable identifiers, and each communication protocol enable identifier is used to indicate whether the communication protocol is enabled; Based on the activation identifier, load the first protocol communication component corresponding to the communication protocol currently in the enabled state in the configuration file; The communication capabilities of the first protocol communication component are registered to a preset target communication interface; the target communication interface is independent of the protocol type. Data is sent and received by calling the first protocol communication component through the target communication interface.

[0006] According to a method provided in this application, the configuration file further includes a protocol type identifier for each of the communication protocols, and the step of loading the first protocol communication component corresponding to the currently enabled communication protocol in the configuration file based on the enable identifier includes: Based on the activation identifier, determine the communication protocol currently in the enabled state in the configuration file; Obtain the first protocol type identifier from the configuration file; the first protocol type identifier is the protocol type identifier of the communication protocol that is currently enabled. Load the first protocol communication component that matches the first protocol type identifier.

[0007] According to a method provided in this application, the first protocol type identifier includes a high-level architecture (HLA), a data distribution service (DDS), Kafka, or a user datagram protocol (UDP).

[0008] According to a method provided in this application, the configuration file further includes communication parameters for each of the communication protocols, and before registering the communication capabilities of the first protocol communication component to a preset target communication interface, the method further includes: Send the communication parameters of the corresponding communication protocol to the first protocol communication component so that the first protocol communication component can perform an initialization operation.

[0009] According to a method provided in this application, the first protocol communication component includes an HLA communication component, a DDS communication component, a Kafka communication component, or a UDP communication component.

[0010] According to a method provided in this application, the configuration file is in XML format.

[0011] According to a method provided in this application, loading the first protocol communication component corresponding to the communication protocol currently in an enabled state in the configuration file includes: The first protocol communication component is loaded using a dynamic library loading method.

[0012] According to a method provided in this application, the method further includes: In response to the user's modification of the enable flags of each communication protocol in the configuration file, the second protocol communication component corresponding to the communication protocol that is enabled in the modified configuration file is loaded. Register the communication capabilities of the second protocol communication component to the target communication interface; Data is sent and received by calling the second protocol communication component through the target communication interface.

[0013] This application also provides a configuration file-based communication device, including the following modules: The first loading module is used to load the configuration file corresponding to the simulation node in response to the startup of the simulation node; the configuration file includes multiple communication protocol enable identifiers, and each communication protocol enable identifier is used to indicate whether the communication protocol is enabled; The second loading module is used to load the first protocol communication component corresponding to the communication protocol that is currently enabled in the configuration file, based on the enable identifier. The registration module is used to register the communication capabilities of the first protocol communication component to a preset target communication interface; the target communication interface is independent of the protocol type. The transceiver module is used to call the first protocol communication component through the target communication interface to send and receive data.

[0014] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the configuration file-based communication method described above.

[0015] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the configuration file-based communication method as described above.

[0016] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the configuration file-based communication method as described above.

[0017] This application provides a configuration file-based communication method, apparatus, device, medium, and product. The configuration file contains enable identifiers for multiple communication protocols. Based on the enable identifier, the currently enabled protocol is determined and the corresponding component is loaded. This allows a single simulation node to support multiple protocols on demand, eliminating the need to develop separate access modules for each protocol, reducing protocol compatibility costs, and improving system integration flexibility. The target communication interface is independent of the protocol type; upper-layer services rely solely on this unified interface for data transmission and reception. Switching between protocol communication components does not affect business code, achieving decoupling between communication logic and business logic, improving code reusability and framework versatility. The protocol enable status is controlled by the enable identifier in the configuration file; modifying the enable identifier completes protocol switching without recompiling and deploying, solving the configuration rigidity problem caused by hard-coded protocol parameters and reducing operation and maintenance costs. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating a configuration file-based communication method provided in this application.

[0020] Figure 2 This is a flowchart illustrating a configuration file-based communication system provided in this application.

[0021] Figure 3 This is a schematic diagram of a configuration file-based communication device provided in this application.

[0022] Figure 4 This is a schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] In the field of tactical simulation training systems, with the increasing integration and coordination of systems, the demand for cross-platform, highly dynamic, and low-latency communication between distributed simulation nodes is becoming increasingly prominent. Since simulator networking systems typically need to integrate heterogeneous equipment from different vendors, and each party has varying options and support capabilities for communication protocols, the mainstream distributed simulation communication protocols currently include HLA, DDS, Kafka, and UDP multicast.

[0025] In simulation interconnection schemes based on HLA-Run-Time Infrastructure (RTI), HLA consists of three parts: rules, Object Model Templates (OMTs), and Federation Member Interface Specifications. Each simulation node, as a federation member, exchanges information via RTI software based on the Federation Object Model (FOM). Domestically available hierarchical RTI products (such as StarLink) and multicast-based RTI products (such as BH-RTI) have improved transmission efficiency to some extent. However, the HLA-RTI architecture is relatively closed, with limited compatibility with different protocol stacks, and a strong coupling relationship exists between federation members and RTI, hindering flexible access for heterogeneous systems.

[0026] Data distribution schemes based on DDS employ a data-centric publish / subscribe model, characterized by low latency, high throughput, and high reliability, making them suitable for distributed systems with high real-time requirements. Some research has focused on DDS channel optimization within the TENA architecture. However, existing DDS solutions are typically developed for specific platforms, resulting in high coupling between communication logic and business code, and requiring significant code modifications for protocol switching.

[0027] Kafka-based event streaming networking solutions leverage their high throughput, persistent storage, and excellent horizontal scalability, making them suitable for scenarios such as log collection and event distribution in simulation training. However, existing Kafka solutions also suffer from high coupling between communication logic and business code, requiring synchronous modifications to core business code when the protocol changes.

[0028] There are existing technologies related to multi-protocol adaptation middleware. For example, one patent discloses a multi-communication protocol adaptation middleware for power IoT operating systems, which achieves automatic identification and adaptation of different communication protocols through sub-modules such as protocol feature analysis, protocol library matching, and dynamic protocol adaptation; another patent proposes a client-server communication system that adapts to multiple network protocols, which centrally manages communication policies and issues configuration commands through a configuration management center. However, the above solutions are mainly aimed at general IoT or conventional Internet communication scenarios, and have not been optimized for the special needs of simulators, such as real-time performance, synchronization, and integration of heterogeneous equipment, and cannot complete multi-protocol switching through a single configuration file.

[0029] In summary, the existing technologies have the following shortcomings: First, poor protocol compatibility. Protocol stacks such as HLA, DDS, and Kafka are developed independently and form their own systems. If the same simulation system needs to support multiple protocols, a separate access module must be developed for each protocol, resulting in high R&D costs and long development cycles. Second, low code reusability. Communication logic is deeply coupled with simulation business logic. When the underlying protocol changes, the core business code needs to be modified synchronously, resulting in insufficient framework versatility and scalability. Third, rigid configuration methods. Protocol parameters are usually hard-coded in the program. Modifying the configuration requires recompiling and re-deploying, resulting in high operation and maintenance costs and poor flexibility.

[0030] Based on this, embodiments of this application provide a configuration file-based communication method, which can load the configuration file corresponding to the simulation node in response to the startup of the simulation node; the configuration file includes multiple communication protocol enable identifiers, each communication protocol enable identifier is used to indicate whether the communication protocol is in an enabled state; based on the enable identifier, the first protocol communication component corresponding to the communication protocol currently in an enabled state in the configuration file is loaded; the communication capability of the first protocol communication component is registered to a preset target communication interface; the target communication interface is independent of the protocol type; and the first protocol communication component is called through the target communication interface to send and receive data.

[0031] In the above technical solution, the configuration file contains enable flags for multiple communication protocols. Based on these flags, the currently enabled protocol is determined and the corresponding component is loaded. This allows a single simulation node to support multiple protocols on demand, eliminating the need to develop separate access modules for each protocol. This reduces protocol compatibility costs, improves system integration flexibility, and ensures the target communication interface is independent of protocol type. Upper-layer services rely solely on this unified interface for data transmission and reception. Switching between protocol communication components does not affect business code, achieving decoupling between communication logic and business logic, thus enhancing code reusability and framework versatility. The protocol enable status is controlled by the enable flags in the configuration file; modifying the enable flags completes protocol switching without recompiling and deploying. This solves the configuration rigidity problem caused by hard-coded protocol parameters and reduces operational costs.

[0032] The following is combined with Figures 1 to 4 This application describes the configuration file-based communication method provided.

[0033] Figure 1 This is a flowchart illustrating a configuration file-based communication method provided in this application, such as... Figure 1 As shown, the method includes the following steps S101 to S104.

[0034] It should be noted that the configuration file-based communication method provided in this application embodiment can be executed by middleware, which can also be called multi-protocol networking middleware. In this application embodiment, middleware is a software layer located between the simulation application (or upper-layer business) and various underlying communication protocols. It is used to shield the differences in calling different protocols, provide a unified communication interface to the upper layer, and dynamically select, load, and switch protocols according to the configuration, so that the business code can adapt to multiple protocols without modification. The configuration file-based communication method provided in this application embodiment can also be executed by any electronic device with middleware deployed. For ease of description, the following description uses middleware as the execution subject.

[0035] S101, in response to the startup of the simulation node, loads the configuration file corresponding to the simulation node.

[0036] A simulation node refers to a computing device or software instance that is equipped with the multi-protocol networking middleware provided in the embodiments of this application, and is used to perform simulation tasks and exchange data with other simulation nodes. For example, a simulation node can be a flight simulator, a command and control system, a battlefield environment simulation node, etc.

[0037] The configuration file includes protocol configuration items for multiple communication protocols. For example, the communication protocols may include multiple protocols such as HLA, DDS, Kafka, or UDP.

[0038] Each communication protocol's configuration item can include an enable flag; that is, the configuration file includes an enable flag for each communication protocol. The enable flag indicates whether the corresponding communication protocol is enabled.

[0039] This application embodiment does not specifically limit the information included in the protocol configuration item of each communication protocol. Optionally, in addition to the enable identifier, the protocol configuration item of each communication protocol may also include the protocol type identifier and communication parameters of the corresponding communication protocol. The protocol type identifier is used to uniquely identify the communication protocol type corresponding to the protocol configuration item. The communication parameters are used to provide necessary configuration information when the corresponding protocol communication component is initialized. For example, when the communication protocol is Kafka, the communication parameters may include broker address, port number, consumer group ID, local node ID, platform ID, platform type, and whether to send messages, etc.; when the communication protocol is HLA, the communication parameters may include RTI server address, federation name, federation member name, and whether to send messages, etc.; when the communication protocol is DDS, the communication parameters may include domain ID, topic name, QoS policy, etc.; when the communication protocol is UDP, the communication parameters may include multicast address, port number, and whether to enable broadcast, etc.

[0040] For example, if a configuration file includes both Kafka and HLA communication protocols, the configuration file can be represented as follows: <!--kafka--> <record name="KafkaServer" enable="false" protocol="Kafka" serverIp="127.0.0.1" serverPort="9092" groupID="helicopterSimulator1" localID="1021" platformID="20001' platformType="0x0201" SendMessage="true" / > <i--hla--> <record name="HLAClient" enable="true" protocol="HLA" serverIp="127.0.0.1" HLAFederateName="HLA" HLAFederateSim="MYNAMEF" SendMessage="true" / > In this configuration, `record name` represents the name of the protocol configuration item, used to identify the communication protocol corresponding to that configuration item; `enable` indicates the enable flag; and `protocol` indicates the protocol type flag. In the Kafka protocol configuration item, `serverIp` represents the broker address, `serverPort` represents the port number, `groupID` represents the consumer group ID, `localID` represents the local node ID, `platformID` represents the platform ID, `platformType` represents the platform type, and `SendMessage` indicates whether the node sends messages via Kafka. In the HLA protocol configuration item, `serverIp` represents the RTI server address, `HLAFederateName` represents the federation name, `HLAFederateSim` represents the federation member name, and `SendMessage` indicates whether the node sends messages via HLA.

[0041] It is understood that the above parameters are merely examples. In practical applications, the communication parameters in each protocol configuration item can be added or removed according to the specific requirements of the selected communication protocol. This application embodiment does not limit this.

[0042] For example, after a simulation node starts, the middleware can load the pre-configured configuration file corresponding to that simulation node from a preset path.

[0043] In one example, the configuration file can be in XML format.

[0044] In one example, the configuration file supports nested structures.

[0045] S102, based on the enable identifier, load the first protocol communication component corresponding to the communication protocol that is currently enabled in the configuration file.

[0046] In one example, based on the enable identifier, the first protocol communication component corresponding to the communication protocol currently in the enabled state in the configuration file is loaded. Specifically, this can be implemented as follows: based on the enable identifier, the communication protocol currently in the enabled state in the configuration file is determined; the protocol type identifier of the communication protocol currently in the enabled state, i.e., the first protocol type identifier, is obtained from the configuration file; and the first protocol communication component matching the first protocol type identifier is loaded.

[0047] For example, the enable flag can include an enabled state and a disabled state. After the middleware loads the configuration file, it can parse the configuration file and traverse each protocol configuration item in the configuration file. Based on the enable flag in each protocol configuration item, it determines the communication protocol that is currently enabled. Then, it can extract the corresponding protocol type flag, i.e., the first protocol type flag, from the protocol type field of the currently enabled communication protocol (e.g., "protocol": "HLA" / "DDS" / "Kafka" / "UDP"). The protocol communication component that matches the first protocol type flag, i.e., the first protocol communication component, is then loaded.

[0048] In one example, before loading the first protocol communication component, the configuration file can be syntax-validated. After successful validation, based on the enable flag, the first protocol communication component corresponding to the currently enabled communication protocol in the configuration file is loaded. Optionally, the syntax validation may include, but is not limited to: whether the configuration file conforms to XML format requirements, whether any necessary fields are missing in the protocol configuration items, and whether the protocol type flag belongs to the range of protocol types supported by the middleware. By performing syntax validation on the configuration file, loading failures or runtime anomalies due to configuration errors can be avoided.

[0049] It should be noted that, generally, only one protocol configuration item in the configuration file should be enabled to ensure that the middleware can uniquely identify the protocol communication component that needs to be loaded. If multiple protocol configuration items are enabled in the configuration file, the middleware can select one according to preset rules (such as the order of configuration items, priority fields, etc.) or output a configuration error message. This application embodiment does not specifically limit this.

[0050] In one example, the middleware may include a configuration parsing and driver module, which is used to perform syntax validation and content parsing on the configuration file.

[0051] When the communication protocol includes multiple protocols such as HLA, DDS, Kafka, or UDP, the protocol communication component (also known as the protocol adaptation submodule) may include multiple protocols such as the HLA communication component (also known as the HLA adaptation submodule), the DDS communication component (also known as the DDS adaptation submodule), the Kafka communication component (also known as the Kafka adaptation submodule), or the UDP communication component (also known as the UDP multicast broadcast submodule). Accordingly, the first protocol communication component loaded above can be an HLA communication component, a DDS communication component, a Kafka communication component, or a UDP communication component.

[0052] For example, if the currently enabled communication protocol is HLA, the dynamically loaded first protocol communication component can be an HLA communication component. If the currently enabled communication protocol is DDS, the dynamically loaded first protocol communication component can be a DDS communication component. If the currently enabled communication protocol is Kafka, the dynamically loaded first protocol communication component can be a Kafka communication component. If the currently enabled communication protocol is UDP, the dynamically loaded first protocol communication component can be a UDP communication component.

[0053] As described above, the configuration file can also include communication parameters for different communication protocols. In one example, after loading the first protocol communication component, the corresponding communication parameters can be sent to the first protocol communication component to enable the first protocol communication component to perform initialization operations.

[0054] For example, taking Kafka as the currently enabled communication protocol, after the middleware loads the Kafka protocol communication component, it can read the communication parameters in the Kafka protocol configuration and pass these parameters to the Kafka protocol communication component to complete its initialization. Specifically, the Kafka protocol communication component can connect to the Kafka broker based on the serverIp and serverPort, join the corresponding consumer group based on the groupID, set the identity of this node based on the localID, platformID, and platformType, and determine whether to create a producer instance for message sending based on SendMessage.

[0055] Taking HLA as an example of the currently enabled communication protocol, after the middleware loads the HLA protocol communication component, it can read the communication parameters in the HLA protocol configuration items and pass these parameters to the HLA protocol communication component to complete its initialization. Specifically, the HLA protocol communication component can connect to the RTI server based on the serverIp, join a specified federation based on HLAFederateName, set the federation member name of this node based on HLAFederateSim, and determine whether to publish an interactive class or object class based on SendMessage.

[0056] Taking DDS as an example of the currently enabled communication protocol, after the middleware loads the DDS protocol communication component, it can read the communication parameters in the DDS protocol configuration items and pass these parameters to the DDS protocol communication component to complete its initialization. Specifically, the DDS protocol communication component can create a DomainParticipant based on the domain ID, register a Topic based on the Topic name, configure DataWriter and DataReader according to the QoS policy, and complete the creation of publishers and subscribers.

[0057] Taking UDP as an example, which is currently in use, after the middleware loads the UDP protocol communication component, it can read the communication parameters in the UDP protocol configuration and pass these parameters to the UDP protocol communication component to complete its initialization. Specifically, the UDP protocol communication component can create a Socket and join the multicast group based on the multicast address and port number, determine the sending mode based on whether broadcasting is enabled, and complete the initialization of the data transmission and reception buffers.

[0058] The initialization process described above is encapsulated within each protocol communication component. The middleware only needs to pass the corresponding communication parameters to the protocol communication component without needing to concern itself with the specific initialization details. In this way, the protocol communication components are independent and pluggable, and changes in the communication parameters of one protocol or upgrades to another protocol will not affect the normal use of other protocol communication components.

[0059] In one example, the first protocol communication component can be loaded via dynamic library loading.

[0060] Specifically, the middleware can call the dynamic library loading interface provided by the operating system, such as calling the `dlopen` function on Linux and the `LoadLibrary` function on Windows, to load the dynamic library file corresponding to the first protocol type identifier. The dynamic library file encapsulates the implementation code of the first protocol communication component. After loading, the middleware creates an instance of the first protocol communication component through the preset entry function in the dynamic library file to realize the loading of the first protocol communication component.

[0061] For example, all dynamic libraries for protocol communication components can uniformly adopt a 64-bit version and be compiled based on the C++17 compilation standard to ensure interface compatibility between protocol communication components and middleware.

[0062] S103, register the communication capabilities of the first protocol communication component to the preset target communication interface.

[0063] The target communication interface refers to the unified interface exposed by middleware to upper-layer emulated applications or business code for data transmission and reception. The target communication interface is protocol-independent; that is, regardless of whether the underlying communication protocol is HLA, DDS, Kafka, or UDP, the interface form, function name, parameter list, and return value called by the upper-layer business code remain consistent. The business code does not need to be aware of the specific type of the underlying protocol or the details of the call.

[0064] The target communication interface can be predefined in the middleware, and this application embodiment does not limit the specific form of the target interface. For example, the target communication interface may include a sending interface, a receiving interface, a topic publishing interface, and a topic subscription interface. Specifically, the sending interface (sendData()) is used to send business data to other simulation nodes; the receiving interface (receiveData()) is used to receive data from other simulation nodes; the topic publishing interface (publishTopic()) is used to publish data to a specified topic; and the topic subscription interface (subscribeTopic()) is used to subscribe to data for a specified topic.

[0065] The above interface is only an example. In actual applications, the form of the target communication interface can be added or removed according to the simulation service requirements, as long as the interface remains stable for the upper layer services and does not change with the protocol type.

[0066] Registering the communication capabilities of the first protocol communication component to a preset target communication interface means that after loading and initializing the first protocol communication component, the communication capabilities, such as the sending and receiving functions implemented within the first protocol communication component, are bound or mapped to the target communication interface. After registration, every data transmission and reception call initiated by the upper-layer business through the target communication interface will be forwarded to the corresponding specific implementation in the first protocol communication component.

[0067] Through the aforementioned registration mechanism, the middleware attaches the specific communication capabilities of the protocol communication components to a unified interface, while the upper-layer business logic only faces the fixed target communication interface, thus achieving complete decoupling between communication logic and business logic. When the underlying protocol changes, the middleware only needs to load the new protocol communication component and re-register its communication capabilities to the same target communication interface, and the upper-layer business code can continue to use it without any modifications.

[0068] S104, the first protocol communication component is called through the target communication interface to send and receive data.

[0069] After completing the registration operation described in S104, the communication capabilities of the first protocol communication component are mapped to the target communication interface. The upper-layer business code can directly initiate data sending requests or obtain received data through the target communication interface without needing to understand the underlying communication protocol and its specific calling process.

[0070] For example, in the data sending direction, when the upper-layer business calls the send function (e.g., sendData(data)) in the target communication interface, it can forward the send request to the corresponding send implementation function in the registered first protocol communication component. After receiving the data to be sent, the first protocol communication component processes the data according to its encapsulated protocol logic. For example: for the HLA protocol communication component, it encapsulates the data into an HLA interaction class or updates object class attributes and sends it to the RTI; for the DDS protocol communication component, it writes the data into the corresponding DDS topic; for the Kafka protocol communication component, it produces the data as a message to the specified Kafka topic; for the UDP protocol communication component, it encapsulates the data into a UDP packet and sends it via multicast or broadcast. The above process is entirely implemented internally by the first protocol communication component; the middleware and the target communication interface are unaware of the specific protocol details.

[0071] In this way, the target communication interface unifies and abstracts the data transmission and reception process between the upper-layer business and the first protocol communication component. The upper-layer business only faces a fixed interface call method; all data encapsulation, parsing, transmission, and synchronization logic related to the specific protocol is encapsulated within the protocol communication component. Therefore, when the underlying protocol changes, it is only necessary to load the new protocol communication component according to the above process and re-register it to the target communication interface. The upper-layer business code can continue to send and receive data through the same target communication interface without any modification, thus achieving decoupling between business logic and communication logic.

[0072] In one example, in response to a user's modification of the enable flags of each communication protocol in the configuration file, the system can load the second protocol communication component corresponding to the communication protocol that is enabled in the modified configuration file, register the communication capabilities of the second protocol communication component to the target communication interface, and call the second protocol communication component through the target communication interface to send and receive data.

[0073] In practical applications, when simulation training tasks change, the current node needs to switch from one communication protocol to another. For example, a node that previously exchanged data with other members in the federation via the HLA protocol now needs to switch to the DDS protocol to access another DDS-based simulation subsystem. In this case, the user does not need to modify any business code; only the enable flag in the configuration file needs to be modified.

[0074] For example, each protocol configuration item in the configuration file includes an enable flag. A user can change the enable flag of a currently enabled protocol configuration item (e.g., the HLA protocol configuration item) from true to false, while simultaneously changing the enable flag of a target protocol configuration item (e.g., the DDS protocol configuration item) from false to true. In the modified configuration file, the HLA protocol will be disabled, and the DDS protocol will be enabled.

[0075] After the modification is completed, the middleware can reload the modified configuration file and, in accordance with the method described in S102-S104 above, load the protocol communication component corresponding to the communication protocol that is enabled in the modified configuration file, namely the second protocol communication component, and register the communication capability of the second protocol communication component to the target communication interface, and call the second protocol communication component through the target communication interface to send and receive data.

[0076] In one example, modifications to the configuration file do not take effect immediately; the modified configuration file will only be read and applied after the middleware (or simulation node) is restarted.

[0077] Through the above process, protocol switching only involves modifying the enable flag in the configuration file and reloading the middleware; no changes are required to the business code, thus achieving the effect of switching based on configuration. It should be noted that the above example uses HLA to DDS as an illustration. In practical applications, switching between any two protocols can be achieved in the same way. This application does not limit the specific protocol types before and after the switch.

[0078] Figure 2 A schematic diagram of a configuration file-based communication system provided in this application embodiment is shown below. Figure 2 As shown, the communication system may include a simulation application layer, middleware, and underlying communication devices.

[0079] The simulation application layer can include multiple simulation nodes, such as Figure 2 The simulation nodes shown are A, B, and C. Each simulation node runs a simulation application program to perform specific simulation tasks and exchanges data with other simulation nodes through middleware.

[0080] The middleware is located between the simulation application layer and the underlying communication device, and includes a standardized communication application programming interface (API) interface layer, a configuration parsing and driver module, a protocol adaptation layer, and a cross-platform adaptation layer.

[0081] The standardized communication API interface layer is used to provide a unified, protocol-independent communication interface for upper-layer simulation applications, namely the target communication interface, such as the sendData() interface, the receiveData() interface, the publishTopic() interface, and the subscribeTopic() interface. It receives data transmission and reception requests from simulation applications and calls the configuration parsing and driver modules to complete protocol adaptation, thereby shielding the calling differences of different underlying protocol stacks.

[0082] The configuration parsing and driver module receives call requests from the standardized communication API interface layer, loads the configuration file, and performs syntax validation and content parsing on the configuration file to extract information such as protocol type identifiers and communication parameters. It can also determine which protocol communication component to load based on the enable flag in the configuration file and drive the initialization of that protocol's communication component in the protocol adaptation layer according to the communication parameters of each protocol.

[0083] The protocol adaptation layer includes multiple protocol communication components, such as the HLA communication component, DDS communication component, Kafka communication component, and UDP communication component. The HLA communication component encapsulates the standard HLA-RTI call flow, including federation member creation, object publishing / subscription, interactive class sending / receiving, and time-based management, abstracting the complex HLA interface into a standardized API. The DDS communication component encapsulates the Fast DDS publish / subscribe model, including DomainParticipant creation, Topic registration, DataWriter / DataReader configuration, and QoS policy settings. The Kafka communication component encapsulates the KafkaProducer / Consumer call logic, including broker connection, topic subscription, message production, and consumption. The UDP communication component encapsulates UDP Socket communication, supporting multicast and broadcast sending modes, suitable for lightweight communication scenarios with simple architecture and low adaptation costs.

[0084] Each protocol communication component encapsulates the standard calling process of the corresponding communication protocol. They are independent and pluggable, and connect to the middleware through a unified internal interface. After initialization, they register communication capabilities with the standardized communication API interface layer so that the upper-layer simulation application can send and receive data through the standardized API.

[0085] The cross-platform adaptation layer is located below the protocol adaptation layer. It is used to encapsulate the differences between different operating systems in dynamic library calls, thread management, network interfaces, etc., and to provide a unified operating system call interface for each protocol adaptation submodule, so as to ensure that the same code can be compiled and run normally on different operating system platforms.

[0086] The underlying communication equipment provides actual physical communication capabilities. The protocol adaptation layer interacts with the underlying communication equipment through the cross-platform adaptation layer to enable data transmission and reception under different protocols.

[0087] The configuration file-based communication method provided in this application dynamically loads corresponding protocol communication components through protocol type identifiers and enable identifiers in the configuration file, and registers the communication capabilities of these components to target communication interfaces independent of protocol types. This allows upper-layer simulation services to complete data transmission and reception by interacting with fixed, standardized interfaces. As a result, communication logic and business logic are completely decoupled, and no business code needs to be modified when switching protocols, effectively solving the problems of deep binding between protocols and business logic and low code reusability in traditional solutions. Simultaneously, the configuration file centrally manages the enable status and communication parameters of each protocol, and protocol selection and parameter configuration are completely externalized. Deploying or switching protocols only requires modifying the configuration file and reloading it, avoiding the cumbersome process of recompiling and deploying under hard-coding methods, significantly reducing operation and maintenance costs, and improving the system's flexibility and versatility.

[0088] Furthermore, this embodiment encapsulates the differences in dynamic library calls, thread management, and network interfaces across different operating systems by setting up a cross-platform adaptation layer. This allows the same middleware code to be compiled and run directly on different operating system platforms, eliminating the need to maintain multiple sets of platform code. The protocol communication components in the protocol adaptation layer adopt an independent and pluggable architecture. When adding support for a new protocol, only the corresponding protocol communication component needs to be added, without affecting existing components or upper-layer business logic, demonstrating excellent scalability. Moreover, the dependent dynamic libraries of each protocol communication component uniformly adopt 64-bit versions and the C++17 compilation standard, eliminating compilation or runtime conflicts caused by version inconsistencies and improving system stability. The above solution encapsulates network communication capabilities into a standardized middleware product, which can be directly reused in different subsequent simulation projects without the need for repeated development and debugging of network programs, significantly reducing the integration cost and development cycle of the distributed simulation system overall.

[0089] The configuration file-based communication device provided in this application will be described below. The configuration file-based communication device described below can be referred to in correspondence with the configuration file-based communication method described above.

[0090] Figure 3 A schematic diagram of a configuration file-based communication device provided in this application embodiment is shown below. Figure 3 As shown, the device includes: The first loading module 301 is used to load the configuration file corresponding to the simulation node in response to the startup of the simulation node; the configuration file includes multiple communication protocol enable identifiers, and each communication protocol enable identifier is used to indicate whether the communication protocol is enabled; The second loading module 302 is used to load the first protocol communication component corresponding to the communication protocol that is currently enabled in the configuration file based on the enable identifier. The registration module 303 is used to register the communication capabilities of the first protocol communication component to a preset target communication interface; the target communication interface is independent of the protocol type. The transceiver module 304 is used to call the first protocol communication component through the target communication interface to send and receive data.

[0091] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4 As shown, the electronic device may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a configuration file-based communication method. This method includes: in response to the startup of a simulation node, loading a configuration file corresponding to the simulation node; the configuration file includes multiple communication protocol enable identifiers, each enabling identifier indicating whether the communication protocol is enabled; based on the enable identifier, loading a first protocol communication component corresponding to the currently enabled communication protocol in the configuration file; registering the communication capabilities of the first protocol communication component to a preset target communication interface; the target communication interface is independent of the protocol type; and calling the first protocol communication component through the target communication interface to send and receive data.

[0092] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0093] On the other hand, this application also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the configuration file-based communication method provided by the above methods. The method includes: loading a configuration file corresponding to the simulation node in response to the startup of the simulation node; the configuration file includes multiple communication protocol enable identifiers, each of which indicates whether the communication protocol is enabled; loading a first protocol communication component corresponding to the currently enabled communication protocol in the configuration file based on the enable identifier; registering the communication capability of the first protocol communication component to a preset target communication interface; the target communication interface is independent of the protocol type; and calling the first protocol communication component through the target communication interface to send and receive data.

[0094] In another aspect, this application also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program is implemented to perform the configuration file-based communication method provided by the above methods. The method includes: in response to the startup of a simulation node, loading a configuration file corresponding to the simulation node; the configuration file includes multiple communication protocol enable identifiers, each of which indicates whether the communication protocol is in an enabled state; based on the enable identifier, loading a first protocol communication component corresponding to the currently enabled communication protocol in the configuration file; registering the communication capability of the first protocol communication component to a preset target communication interface; the target communication interface is independent of the protocol type; and calling the first protocol communication component through the target communication interface to send and receive data.

[0095] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0097] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A communication method based on a configuration file, characterized in that, The method includes: In response to the startup of the simulation node, the configuration file corresponding to the simulation node is loaded; the configuration file includes multiple communication protocol enable identifiers, and each communication protocol enable identifier is used to indicate whether the communication protocol is enabled; Based on the activation identifier, load the first protocol communication component corresponding to the communication protocol currently in the enabled state in the configuration file; The communication capabilities of the first protocol communication component are registered to a preset target communication interface; the target communication interface is independent of the protocol type. Data is sent and received by calling the first protocol communication component through the target communication interface.

2. The method according to claim 1, characterized in that, The configuration file also includes a protocol type identifier for each of the communication protocols. The step of loading the first protocol communication component corresponding to the currently enabled communication protocol in the configuration file, based on the enable identifier, includes: Based on the activation identifier, determine the communication protocol currently in the enabled state in the configuration file; Obtain the first protocol type identifier from the configuration file; the first protocol type identifier is the protocol type identifier of the communication protocol that is currently enabled. Load the first protocol communication component that matches the first protocol type identifier.

3. The method according to claim 1 or 2, characterized in that, The configuration file also includes communication parameters for each of the communication protocols. Before registering the communication capabilities of the first protocol communication component to the preset target communication interface, the method further includes: Send the communication parameters of the corresponding communication protocol to the first protocol communication component so that the first protocol communication component can perform an initialization operation.

4. The method according to claim 1 or 2, characterized in that, The configuration file is in XML format.

5. The method according to claim 1 or 2, characterized in that, The loading of the first protocol communication component corresponding to the communication protocol currently enabled in the configuration file includes: The first protocol communication component is loaded using a dynamic library loading method.

6. The method according to claim 1 or 2, characterized in that, The method further includes: In response to the user's modification of the enable flags of each communication protocol in the configuration file, the second protocol communication component corresponding to the communication protocol that is enabled in the modified configuration file is loaded. Register the communication capabilities of the second protocol communication component to the target communication interface; Data is sent and received by calling the second protocol communication component through the target communication interface.

7. A communication device based on a configuration file, characterized in that, The device includes: The first loading module is used to load the configuration file corresponding to the simulation node in response to the startup of the simulation node; the configuration file includes multiple communication protocol enable identifiers, and each communication protocol enable identifier is used to indicate whether the communication protocol is enabled; The second loading module is used to load the first protocol communication component corresponding to the communication protocol that is currently enabled in the configuration file, based on the enable identifier. The registration module is used to register the communication capabilities of the first protocol communication component to a preset target communication interface; the target communication interface is independent of the protocol type. The transceiver module is used to call the first protocol communication component through the target communication interface to send and receive data.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the configuration file-based communication method as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the configuration file-based communication method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the configuration file-based communication method as described in any one of claims 1 to 6.

Images