A communication device interface adaptation method and system

Abstract

The present application relates to the technical field of unmanned aerial vehicle communication interface adaptation, in particular to a communication device interface adaptation method and system based on unmanned aerial vehicles, comprising: collecting physical interface configuration data of multi-mode communication devices in the payload cabin of the unmanned aerial vehicle, and generating interface capability descriptors after analysis; then calling a preset interface abstraction layer protocol stack, mapping the interface capability descriptors into a unified virtual communication endpoint to shield hardware differences; finally, based on the virtual communication endpoint, loading a driver adaptation program containing an interface initialization sequence and an interrupt processing rule to establish a logical channel with the flight control system of the unmanned aerial vehicle. The method simplifies the adaptation program development process, realizes driver program reuse, solves the problems of poor compatibility and complicated development of the prior art, ensures stable transmission of control commands and state feedback data, and improves the efficiency and reliability of multi-mode communication device adaptation.

Description

Technical Field

[0001] This invention relates to the field of UAV communication interface adaptation technology, and in particular to a method and system for adapting communication device interfaces. Background Technology

[0002] The payload bay of an unmanned aerial vehicle (UAV) needs to carry various types of multi-mode communication devices to transmit control commands and status feedback data with the flight control system. These multi-mode communication devices have diverse physical interfaces, with different interface type codes, pin definition matrices, and electrical protocol version numbers, resulting in significant differences in their interface capabilities. Existing technologies for interface adaptation of multi-mode communication devices in UAV payload bays employ a targeted development approach, only able to identify the basic interface type. They do not systematically collect complete physical interface configuration data for the multi-mode communication devices, nor can they parse the collected configuration data to obtain comprehensive interface capability information.

[0003] Existing interface adaptation technologies lack a unified interface abstraction layer protocol stack, making it impossible to uniformly map the capabilities of different physical interfaces. This necessitates the development of a dedicated driver adapter for each physical interface, resulting in a large workload and long development cycle. Furthermore, the hardware differences between different physical interfaces cannot be effectively masked, making compatibility issues prone to arise when multi-mode communication devices interface with UAV flight control systems. Simultaneously, the loading of driver adapters in existing technologies is tightly bound to physical interfaces, preventing reuse. The establishment of logical channels lacks a reasonable basis, making it difficult to stably carry control commands and status feedback data, thus failing to meet the actual needs of efficient and stable adaptation for multi-mode communication devices. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a communication device interface adaptation method and system.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a communication device interface adaptation method, comprising:

[0006] Collect physical interface configuration data of the multi-mode communication equipment inside the UAV payload bay. The physical interface configuration data includes interface type code, pin definition matrix and electrical protocol version number.

[0007] The physical interface configuration data is parsed to generate the interface capability descriptor of the multimode communication device. The interface capability descriptor includes the upper limit of data transmission rate, signal modulation method and power supply specifications.

[0008] The pre-built interface abstraction layer protocol stack is invoked to map the interface capability descriptor to a unified virtual communication endpoint, which shields the hardware differences between different physical interfaces.

[0009] Based on the virtual communication endpoint, a driver adapter program matching the multimode communication device is loaded. The driver adapter program includes an interface initialization sequence, interrupt handling rules, and a data frame encapsulation format.

[0010] Based on the running results of the driver adaptation program, a logical channel is established between the multi-mode communication device and the UAV flight control system. The logical channel is used to carry control commands and status feedback data.

[0011] As a further aspect of the present invention, parsing the physical interface configuration data to generate the interface capability descriptor of the multi-mode communication device includes:

[0012] Extract the bus standard identifier from the interface type code to determine whether the multimode communication device supports hot-plugging operation;

[0013] Read the power supply pin position and ground pin position in the pin definition matrix, and calculate the rated operating voltage and maximum operating current of the multimode communication device;

[0014] Retrieve the protocol specification document corresponding to the electrical protocol version number to obtain the handshake signal types and error checking algorithms supported by the version;

[0015] The obtained rated operating voltage, maximum operating current, handshake signal type, and error checking algorithm are structured and encapsulated to generate the interface capability descriptor containing complete electrical characteristics.

[0016] As a further aspect of the present invention, the step of invoking a pre-defined interface abstraction layer protocol stack to map the interface capability descriptor to a unified virtual communication endpoint includes:

[0017] In the interface abstraction layer protocol stack, an object instance of a virtual communication endpoint is created, and the object instance contains an endpoint identifier and a state machine;

[0018] Map the upper limit of the data transmission rate in the interface capability descriptor to the bandwidth allocation parameter of the virtual communication endpoint;

[0019] Convert the signal modulation method in the interface capability descriptor to the link layer coding type supported by the virtual communication endpoint;

[0020] Register the power supply specification in the interface capability descriptor to the power management submodule of the interface abstraction layer protocol stack to complete the resource configuration of the virtual communication endpoint.

[0021] As a further aspect of the present invention, based on the virtual communication endpoint, a driver adapter program matching the multi-mode communication device is loaded, including:

[0022] Inject the interface capability descriptor into the object instance of the virtual communication endpoint to trigger the start of the driver matching engine;

[0023] Traverse the pre-stored driver library to find a driver template that perfectly matches the interface type code and electrical protocol version number;

[0024] If no perfectly matching driver template is found, a driver template that supports backward compatibility is selected, and a patch configuration file is generated based on the differences in the interface capability descriptor.

[0025] The selected driver template is merged and compiled with the patch configuration file to generate an executable driver adapter program.

[0026] As a further aspect of the present invention, the driver adapter program includes an interface initialization sequence, interrupt handling rules, and a data frame encapsulation format. After generating the executable driver adapter program, it further includes:

[0027] The interface initialization sequence in the driver adapter is sent to the firmware layer of the multimode communication device to complete the physical interface reset and self-test.

[0028] Configure the interrupt handling rules to establish a mapping relationship between hardware interrupt signals and software event handling functions of the multi-mode communication device;

[0029] According to the data frame encapsulation format, the uplink status data to the UAV flight control system is packaged, and unpacking and verification are performed when the downlink control command arrives.

[0030] As a further aspect of the present invention, a dynamic reconfiguration step during device switching is also included:

[0031] When a new multimode communication device is detected to be accessing the payload bay, the currently running driver adapter is suspended.

[0032] The physical interface configuration data of the newly accessed multimode communication device is re-collected, and a new interface capability descriptor is generated.

[0033] The original virtual communication endpoint is deregistered through the interface abstraction layer protocol stack, and a new virtual communication endpoint is created based on the new interface capability descriptor;

[0034] A new driver adapter program matching the new device is loaded, and the logical channel between the multi-mode communication device and the UAV flight control system is re-established to achieve communication switching without restarting.

[0035] As a further aspect of the present invention, the step of suspending the currently running driver adapter program when a new multi-mode communication device is detected accessing the payload bay includes:

[0036] Monitor the interface plug-in / plug-out status signals inside the payload compartment. When the status signal changes from disconnected to connected, trigger the equipment switching interruption.

[0037] Freeze the data transmission and reception buffer of the current logical channel, wait for the incomplete data frames to be sent, and then mark the current driver adapter program as paused.

[0038] Reclaim the bandwidth allocation parameters and link layer encoding type resources currently occupied by the virtual communication endpoint to prevent resource conflicts with new devices.

[0039] As a further aspect of the present invention, a periodic self-check step for the interface health status is also included:

[0040] A heartbeat detection mechanism is embedded in the driver adapter program to periodically send link maintenance commands to the multimode communication device;

[0041] Receive the heartbeat response data packet returned by the multi-mode communication device, parse the signal strength indication value and bit error rate statistics value in it, compare the signal strength indication value and bit error rate statistics value with the preset health threshold, and generate an interface connectivity status code;

[0042] The interface connectivity status code is written into the telemetry data stream of the UAV flight control system for ground station fault diagnosis.

[0043] As a further aspect of the present invention, the step of parsing the signal strength indication value and the bit error rate statistics value, comparing the signal strength indication value and the bit error rate statistics value with a preset health threshold, and generating an interface connectivity status code includes:

[0044] If the signal strength indication value is lower than the lower threshold and the bit error rate statistics value is higher than the upper threshold, then the interface connectivity status code is marked as a link interruption.

[0045] If the signal strength indication value is between the upper and lower thresholds and the bit error rate statistics value is normal, then the interface connectivity status code is marked as link degradation;

[0046] If both the signal strength indication value and the bit error rate statistics value are within the normal range, the interface connectivity status code will be marked as a good link.

[0047] The results of link interruption, link degradation, and link quality determination are bound to timestamps and stored in a circular buffer.

[0048] As a further aspect of the present invention, the present invention also includes a communication device interface adaptation system, the system including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein when the processor executes the computer program, it implements the steps of the communication device interface adaptation method described above.

[0049] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0050] By invoking a pre-built interface abstraction layer protocol stack, interface capability descriptors are mapped to unified virtual communication endpoints, shielding the hardware differences between different physical interfaces. With the hardware characteristics of different physical interfaces uniformly abstracted and integrated, there is no need to develop separate adapter programs for each physical interface's hardware differences, simplifying the adapter development process and reducing development costs. The unified virtual communication endpoint standardizes the interface logic between multi-mode communication devices and UAV flight control systems, eliminating interface barriers caused by hardware differences in different physical interfaces, reducing interruptions and signal interference during command transmission, and making the interface between multi-mode communication devices and flight control systems smoother and the adaptation process more efficient.

[0051] A driver adapter program, containing interface initialization sequences, interrupt handling rules, and data frame encapsulation formats, is loaded based on a virtual communication endpoint. The logical channel between the multi-mode communication device and the UAV flight control system is established based on the driver adapter program's execution results. The driver adapter program loading process is decoupled from the physical interface hardware characteristics, allowing the same driver adapter program to be reused on multi-mode communication devices with different physical interfaces, reducing the number of adapter programs developed and maintenance costs. The establishment of the logical channel is based on the actual execution results of the driver adapter program, standardizing the transmission timing of control commands, achieving synchronization of status feedback data reception and processing, reducing the probability of anomalies during data transmission, making the transmission of control commands and status feedback data more stable, and improving the adaptation reliability of the multi-mode communication device. Attached Figure Description

[0052] Figure 1 This is a flowchart of a communication device interface adaptation method according to the present invention;

[0053] Figure 2 A flowchart for mapping virtual communication endpoints;

[0054] Figure 3 Success rate analysis chart for encapsulating data frames of different interface types;

[0055] Figure 4 A comparison chart of performance metrics for dynamic reconfiguration of different interface types;

[0056] Figure 5 A timing analysis diagram for the periodic self-test of the health status of the communication interface. Detailed Implementation

[0057] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0058] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0059] See Figure 1 The system collects physical interface configuration data of the multi-mode communication device inside the UAV payload bay. This data includes interface type encoding, pin definition matrix, and electrical protocol version number. The collected physical interface configuration data is parsed to generate an interface capability descriptor describing the communication capabilities of the multi-mode communication device. This descriptor includes key parameters such as data transmission rate limit, signal modulation method, and power supply specifications. The system calls a pre-built interface abstraction layer protocol stack to map the generated interface capability descriptor to a unified virtual communication endpoint. This virtual endpoint masks the hardware differences between different physical interfaces, providing a consistent access interface for upper-layer software. Based on the created virtual communication endpoint, a driver adapter program matching the specific model and specifications of the current multi-mode communication device is loaded. This driver adapter program includes the necessary interface initialization sequence, interrupt handling rules, and data frame encapsulation format for driving the device. Based on the driver adapter program's execution results, a stable logical channel is established between the multi-mode communication device and the UAV flight control system. This logical channel is specifically used for carrying downlink transmission of flight control commands and uplink transmission of device status feedback data.

[0060] In one embodiment of the present invention, after acquiring the physical interface configuration data of the multimode communication device, the data is parsed to generate an interface capability descriptor. The parsing process first extracts the bus standard identifier contained in the interface type code of the physical interface configuration data, and determines whether the current multimode communication device supports hot-plugging based on this identifier. Simultaneously, the power supply pin position and ground pin position information recorded in the pin definition matrix are read, and the rated operating voltage and maximum operating current of the multimode communication device are calculated based on the definitions and layout of these pins. Subsequently, the system retrieves the corresponding standard protocol specification document based on the electrical protocol version number in the physical interface configuration data, and obtains the specific handshake signal types and specified error checking algorithms supported by that protocol version from the document. Finally, the calculated rated operating voltage, maximum operating current, and the handshake signal types and error checking algorithms obtained from the protocol document are structured and encapsulated to generate an interface capability descriptor containing complete electrical characteristic parameters.

[0061] In practical implementation, the process of parsing physical interface configuration data and generating interface capability descriptors can be illustrated using a specific example of a multimode communication device, which is a serial communication module supporting the RS-422 standard. In the physical interface configuration data collected by the system, the interface type is encoded as "RS422_V1.2," the pin definition matrix is ​​an 8x8 matrix explicitly recording the function of each pin, and the electrical protocol version number is "RS-422Rev.3." After the parsing process begins, the system first extracts the bus standard identifier "RS422" from the interface type code "RS422_V1.2" in the physical interface configuration data. In some embodiments, the system internally maintains a mapping table between known bus standard identifiers and hot-plug capabilities. The mapping table records that the "RS422" standard does not support hot-plugging operations, therefore determining that this multimode communication device does not support hot-plugging operations. It can be understood that the mapping table is a pre-built static data structure within the system, used for quickly querying bus characteristics.

[0062] In practice, the parsing process then reads the pin definition matrix information from the physical interface configuration data. In the pin definition matrix, the element in the 3rd row and 5th column is labeled "VCC_PWR," representing the location of the power supply pin, and the element in the 7th row and 1st column is labeled "GND," representing the location of the ground pin. Based on the index of the power supply pin "VCC_PWR" in the matrix, the system queries the associated hardware specification document to obtain the rated operating voltage of 5 volts DC for that pin definition. It can be understood that the relationship between pin location and electrical parameters is stored in a separate hardware description file. Simultaneously, the system needs to calculate the maximum operating current, a calculation process involving the number of power supply pins in the pin definition matrix and the current supply capacity of each pin. The formula for calculating the maximum operating current is as follows:

[0063]

[0064] Where: symbol This represents the calculated maximum operating current of the multimode communication device, denoted by [symbol]. This indicates the total number of power supply pins identified in the pin definition matrix, with the symbol... Indicates the first Each power supply pin has a rated power as defined in the hardware specifications document, symbol... This indicates the rated operating voltage. For example, if there are two power supply pins in the pin definition matrix, each power supply pin... It is 2.5 watts. If it is 5 volts, then substituting it into the formula will yield the result. Ampere. In some embodiments, rated power information is directly encoded in an additional attribute field of the pin definition matrix, without the need for additional documentation lookup.

[0065] In practice, the parsing process then searches the local or connected protocol specification library based on the electrical protocol version number "RS-422Rev.3" in the physical interface configuration data. The system retrieves the protocol specification document that perfectly corresponds to the version number "RS-422Rev.3". From the "Handshake Signals" section of the document, it obtains the supported handshake signal type as "RTS / CTS hardware handshake" and the specified error checking algorithm as "Cyclic Redundancy Check algorithm with CRC-16-CCITT generator polynomial" from the "Error Control" section. Optionally, the protocol specification library can be deployed in the cloud, and the system obtains the required document fragments via a secure connection. Optionally, all protocol specification documents are fully cached in local storage during system initialization. The final stage of the parsing process is structured encapsulation. The system uses the rated operating voltage "5V", maximum operating current "1A", handshake signal type "RTS / CTS hardware handshake", and error checking algorithm "Cyclic Redundancy Check algorithm with CRC-16-CCITT generator polynomial" obtained and calculated in the preceding steps as data fields. These data fields are encapsulated according to a predefined structure format to generate an interface capability descriptor containing complete electrical characteristics. The interface capability descriptor is a data structure object instantiated in memory, containing all the parsed key information such as bus type, electrical parameters, and protocol characteristics, used in subsequent processes.

[0066] In one embodiment of the present invention, after generating the interface capability descriptor, a preset interface abstraction layer protocol stack is invoked to create a virtual communication endpoint. See also... Figure 2This process creates an object instance of the virtual communication endpoint in the memory space of the Interface Abstraction Layer (API) protocol stack. This object instance contains an endpoint identifier to uniquely identify the endpoint and a state machine to manage its lifecycle. After creating the object instance, the upper limit of the data transmission rate recorded in the interface capability descriptor is mapped and set as the bandwidth allocation parameter of the virtual communication endpoint. Simultaneously, the signal modulation method described in the interface capability descriptor is converted to the link layer coding type supported by the virtual communication endpoint using preset conversion rules within the protocol stack. Furthermore, the power supply specifications detailed in the interface capability descriptor are registered to the power management submodule within the API protocol stack. This submodule then uniformly allocates and manages power resources, thereby completing the configuration of all resources required by the virtual communication endpoint.

[0067] In practical implementation, the process of calling the interface abstraction layer protocol stack to create a virtual communication endpoint can be illustrated using the "RS-422 standard serial communication module" and its generated interface capability descriptor as a specific example. The interface capability descriptor contains fields such as the upper limit of data transmission rate, signal modulation method, and power supply specifications. The upper limit of data transmission rate is "9600 bits per second," the signal modulation method is "NRZ-L encoding," and the power supply specifications include "rated operating voltage of 5 volts" and "maximum operating current of 1 ampere." After receiving this interface capability descriptor, the interface abstraction layer protocol stack begins to allocate memory in the global resource pool managed by the protocol stack, creating an object instance of the virtual communication endpoint. This object instance is assigned a globally unique endpoint identifier upon creation, which can be a 128-bit UUID. Simultaneously, the object instance initializes a state machine internally, which manages the virtual communication endpoint's lifecycle states such as "uninitialized," "ready," "busy," and "error." It can be understood that the object instance is an implementation of object-oriented programming concepts at the system's underlying level, used to encapsulate data and behavior.

[0068] In practical implementation, after creating the virtual communication endpoint object instance, the Interface Abstraction Layer (API) protocol stack performs parameter mapping. The API stack reads the data transmission rate limit "9600 bits per second" from the interface capability descriptor and directly maps this value to the bandwidth allocation parameter of the virtual communication endpoint object. In some embodiments, the bandwidth allocation parameter is used internally by the API stack for traffic shaping and scheduling arbitration to ensure fairness when multiple virtual communication endpoints share physical bandwidth. The mapping process follows a linear transformation relationship, which can be expressed as:

[0069]

[0070] Where: symbol Indicates the actual number of allocable bandwidth units obtained by the virtual communication endpoint after mapping, symbol This represents the raw numerical value of the upper limit of the data transfer rate read from the interface capability descriptor, with the symbol... This represents the bandwidth unit conversion coefficient defined within the interface abstraction layer protocol stack, with the symbol... This indicates the floor function. For example, if... It is 9600. If it is 0.1, then the calculation yields... A bandwidth unit. In some embodiments, a bandwidth unit is the smallest unit of granularity for managing resources within the protocol stack.

[0071] In practical implementation, the Interface Abstraction Layer (API) protocol stack then handles the conversion of signal modulation methods. The API reads the signal modulation method "NRZ-L encoding" from the interface capability descriptor and queries the pre-built encoding type conversion table within the stack. This table establishes a correspondence between various physical layer signal modulation methods and several standard link layer encoding types supported by the API stack. The table records the conversion of "NRZ-L encoding" to "binary amplitude encoding type." The API assigns the "binary amplitude encoding type" to the link layer encoding type attribute of the virtual communication endpoint object. Optionally, the encoding type conversion table supports dynamic updates to adapt to new physical layer modulation technologies. Optionally, when no perfectly matching modulation method is found, the API selects a compatible default encoding type and logs an alarm. The final step in resource configuration is registering the power supply specifications. The API reads the power supply specifications from the interface capability descriptor, which includes "rated operating voltage 5 volts" and "maximum operating current 1 ampere." The interface abstraction layer protocol stack calls the registration interface of the internal power management submodule, passing the power supply specifications as parameters. The power management submodule calculates the required power based on the rated operating voltage and maximum operating current, using the product of voltage and current, and reserves the corresponding power allowance in the system power budget. Essentially, the power management submodule is an independent software component responsible for the unified management of power requests and allocations for all virtual communication endpoints. After successful registration, the power management submodule returns a power handle to the virtual communication endpoint object instance. The virtual communication endpoint object instance stores the power handle in its resource list, indicating that all bandwidth allocation parameters, link layer encoding type, and power resources required by the virtual communication endpoint have been configured, and the virtual communication endpoint enters a state where it can be used by the driver adapter.

[0072] In one embodiment of the present invention, a matching driver adapter needs to be loaded for the created virtual communication endpoint. The loading process first injects the generated interface capability descriptor into the object instance of the virtual communication endpoint. This operation triggers the system's driver matching engine to start. The driver matching engine traverses the pre-stored driver library, searching for a driver template that perfectly matches the interface type code and electrical protocol version number in the interface capability descriptor. If no perfectly matching driver template is found in the driver library, the engine selects a backward-compatible driver template as a base and dynamically generates a patch configuration file based on the differences between the current interface capability descriptor and the selected driver template. Then, the system merges and compiles the selected base driver template with this patch configuration file, ultimately generating a driver adapter that can be directly executed in the current hardware environment. After the driver adapter is generated, its interface initialization sequence is sent to the firmware layer of the multi-mode communication device for execution, completing the physical interface reset and self-test operations. Simultaneously, according to the interrupt handling rules defined within the driver adapter, a mapping relationship is established between the hardware interrupt signals of the multi-mode communication device and the software event handling functions within the system. During data transmission, the device status data that needs to be sent uplink to the UAV flight control system is packaged according to the data frame encapsulation format specified by the driver adapter. When the downlink control command is received from the flight control system, the corresponding unpacking and data verification process is executed.

[0073] See Figure 3 In the performance analysis of the driver adaptation program for multi-mode communication equipment in UAVs, the data frame encapsulation success rate directly reflects the reliability of upper-layer data transmission for different physical interfaces after driver adaptation. The figure uses interface type as the horizontal axis and data frame encapsulation success rate as the vertical axis, clearly presenting the distribution of encapsulation success rates for five typical interfaces—RS232, CAN, Ethernet, 4G, and 5G—through a red line and area-filled visualization. The Ethernet interface ranks first with a success rate of 99.5%, demonstrating its excellent reliability in stable wired transmission scenarios. The CAN interface follows closely with 99.0%, also exhibiting the high stability of an industrial-grade bus. The RS232 and 5G interfaces reach 98.0% and 98.5% respectively, maintaining reliable encapsulation efficiency in their respective application scenarios. The 4G interface, with an encapsulation success rate of 97.0%, is relatively low among the five interfaces, indirectly reflecting that data encapsulation is more significantly affected by factors such as signal fluctuations and protocol overhead in wireless mobile scenarios.

[0074] In specific implementation, the program that loads and executes the driver adapter based on the virtual communication endpoint continues to use the "RS-422 standard serial communication module" and its created virtual communication endpoint as a specific example. The virtual communication endpoint has been configured with an endpoint identifier, bandwidth allocation parameters, link layer encoding type, and power handle. The loading process begins by injecting the previously generated interface capability descriptor into the object instance of the virtual communication endpoint. The interface capability descriptor contains the interface type code "RS422_V1.2" and the electrical protocol version number "RS-422Rev.3". The injection action triggers the startup of the independent driver matching engine in the system. The driver matching engine begins to traverse the pre-stored driver library, which is organized in an index structure. The driver matching engine uses the interface type code and the electrical protocol version number as a composite key for lookup. The goal of the lookup is to find a driver template with the interface type code "RS422_V1.2" and the electrical protocol version number "RS-422Rev.3". In some embodiments, the driver library is stored in the system's non-volatile memory, and the driver matching engine uses a hash table for fast retrieval. In some embodiments, if a perfectly matching driver template exists in the driver library, such as a template file identified as "DRV_RS422_VER3", the driver matching engine will directly load this driver template.

[0075] In practical implementation, consider another scenario: the driver matching engine fails to find a perfectly matching driver template after traversing the driver library. For example, the driver library may contain only one driver template with an interface type encoding of "RS422_V1.2" but an electrical protocol version number of "RS-422Rev.2". In this case, the driver matching engine's analysis logic will evaluate whether the "RS-422Rev.2" driver template declares backward compatibility to "RS-422Rev.3", based on the compatibility list in the driver template's metadata. Optionally, the driver template's metadata may include an explicit "supported_versions" field. If the evaluation passes, the driver matching engine selects this "RS-422Rev.2" driver template as the basis and initiates a difference analysis. The difference analysis is performed by comparing the current interface capability descriptor with the default interface capability descriptor expected by the "RS-422Rev.2" driver template. The comparison reveals that the handshake signal type in the current interface capability descriptor is "RTS / CTS hardware handshake," while the "RS-422Rev.2" driver template expects "XON / XOFF software handshake" by default. There are also differences in the error checking algorithm. Based on these differences, the driver matching engine dynamically generates a patch configuration file. The patch configuration file records the configuration items that need to be modified in a structured text format, such as "handshake_type:RTS_CTS" and "crc_polynomial:0x1021". Optionally, the patch configuration file can be in JSON or YAML format. It can be understood that the difference analysis ensures that the driver adaptation behavior is aligned with the actual hardware characteristics of the new device.

[0076] In practice, generating the final executable driver adapter requires a compilation step. The system submits the source code of the selected base driver template, namely the "RS-422Rev.2" driver template, along with the dynamically generated patch configuration file, to the built-in compilation toolchain. The compilation toolchain first parses the patch configuration file and applies the configuration changes to the corresponding macro definitions or constant areas in the driver template source code. The merging and compilation process can be described by a configuration integration function. The integration function handles all differences, and its operation can be formally represented as:

[0077]

[0078] Where: symbol This represents the final, executable set of source code for the driver adapter, symbolic. Represents the set of source code for the selected base driver template, symbol Represents the set of differences described in the patch configuration file, symbol This refers to the configuration integration and source code generation functions executed by the compilation toolchain. The task is to traverse Each item in, in Find the corresponding configuration points and modify or replace them, finally outputting the integrated result. The compilation and linking of the driver adapter follows a standard process, ultimately generating a binary executable module.

[0079] In practice, after the driver adapter is generated, the system executes its interface initialization sequence. The interface initialization sequence is a series of predefined control command byte streams sent to the firmware layer of the multi-mode communication device, such as "0x55,0xAA,0x01,0x00". The system sends the interface initialization sequence to the firmware layer of the RS-422 communication module through the underlying physical interface carried by the virtual communication endpoint. The firmware layer receives and executes these commands, completing the physical interface reset, internal register configuration, and self-test operations. A successful self-test signal is returned through the status register. The firmware layer can be understood as the underlying software running on the communication module's microcontroller. Configuring interrupt handling rules means establishing a mapping relationship in the system kernel's interrupt descriptor table. For example, mapping the interrupt signal of the RS-422 communication module's hardware interrupt line "IRQ_12" to the address of a software event handling function named "rs422_data_ready_handler" in the driver adapter. Optionally, interrupt handling rule configuration includes setting the interrupt trigger mode to edge-triggered.

[0080] In practice, the encapsulation and unpacking of data frames are performed according to the data frame encapsulation format defined in the driver adapter. The data frame encapsulation format specifies the structure of each uplink data frame, such as "[frame header 2 bytes][data length 1 byte][payload N bytes][CRC16 checksum 2 bytes]". When status data needs to be sent uplink to the UAV flight control system, the packet assembly function in the driver adapter adds a frame header and length field before the status data payload according to this format, calculates and appends a CRC16 checksum field after the payload, forming a complete data frame and sending it through the logical channel. When downlink control commands arrive from the flight control system, the unpacking function in the driver adapter first identifies the frame header, then extracts the data length field, then extracts the payload data according to the length, and finally uses the specified CRC-16-CCITT algorithm to perform checksum calculations on the frame header and payload, and compares the calculation result with the checksum field attached to the frame tail. If the checksum passes, the payload, i.e., the valid control command, is delivered to the upper-layer application logic; if the checksum fails, the frame is discarded and a retransmission mechanism may be triggered. Optionally, the unpacking function updates the error status counter of the virtual communication endpoint when a frame format error is detected.

[0081] In one embodiment of the present invention, the method includes a step of dynamic reconfiguration during device switching. When the system detects that a new multi-mode communication device has been connected to the UAV payload bay, it immediately suspends the currently running driver adapter program. Dynamic reconfiguration first monitors the interface plug-in / plug-out status signal inside the payload bay. When the status signal changes from disconnected to connected, a device switching interrupt is triggered. In response to the interrupt, the system freezes the data transmission and reception buffer of the current logical channel, waits for all incomplete data frames to be sent, and then marks the running status of the current driver adapter program as paused. At the same time, it reclaims the bandwidth allocation parameters and link layer encoding type resources occupied by the current virtual communication endpoint to prevent conflicts with the resources that the new device will request. Subsequently, the system re-collects the physical interface configuration data of the newly connected multi-mode communication device and generates a new set of interface capability descriptors based on this data. Then, it unregisters the original virtual communication endpoint through the interface abstraction layer protocol stack and creates a new virtual communication endpoint based on the newly generated interface capability descriptors. Finally, it loads a new driver adapter program that matches the new device and re-establishes the logical channel between the multi-mode communication device and the UAV flight control system, thereby achieving communication link switching without restarting the entire system.

[0082] See Figure 4 In the dynamic reconfiguration performance analysis of UAV multi-mode communication equipment, this graph quantifies the core performance indicators of five typical interfaces—RS232, CAN, Ethernet, 4G, and 5G—during device handover using a combined visualization method. The graph uses purple bars to represent device handover time, reflecting the time cost of different physical interfaces completing link suspension, resource reclamation, and reinitialization. Green and red lines correspond to resource reclamation rate and handover success rate, respectively, demonstrating the integrity of system resource release and the continuity of link services during dynamic reconfiguration. Data shows that the Ethernet interface achieves optimal levels in handover time, resource reclamation rate, and handover success rate, verifying its high efficiency in dynamic adaptation under wired environments. The CAN and RS232 interfaces perform stably, with handover success rates both above 98%. While the 4G interface has the shortest handover time, its resource reclamation rate and handover success rate are relatively low, which is related to the wireless link protocol negotiation mechanism and environmental interference. The 5G interface shows a balanced performance in handover time and resource reclamation efficiency. This figure comprehensively verifies the effectiveness of the dynamic reconfiguration mechanism and the performance differences between different interfaces from three dimensions: time overhead, resource utilization, and link stability. It provides quantitative support for ensuring the business continuity of the UAV payload cabin in multi-device switching scenarios.

[0083] In practical implementation, the dynamic reconfiguration process for device switching can be illustrated using a specific scenario of hot-switching from an "RS-422 standard serial communication module" to a "CAN bus communication module." Currently, the system is stably running the driver adapter program based on the RS-422 device and maintaining a logical channel with the UAV flight control system. The system periodically monitors the insertion / removal status signals of the interface connectors inside the payload bay. The monitoring logic reads the electrical status pins of the interface connectors via polling or interrupts. When a new "CAN bus communication module" is inserted into the interface socket of the payload bay, the electrical connection status of the interface connector changes from logic "0" to logic "1," and this level transition generates an edge signal. In some embodiments, this edge signal is directly connected to the external interrupt pin of the flight control main processor. The system captures this level transition signal, triggering a high-priority device switching interrupt, marking the start of the dynamic reconfiguration process.

[0084] In practical implementation, after a device switching interrupt is triggered, the system immediately suspends the currently running driver adapter program serving the RS-422 communication module. The suspension operation first freezes the data transmission and reception buffers of the current logical channel. Freezing means no new upper-layer application data will be accepted for writing to the transmission buffer, but the last incomplete data frame in the transmission buffer is allowed to continue being transmitted. The system queries the status register of the transmission buffer, waiting until the status register displays the "transmission idle" flag, confirming that the last data frame has been physically transmitted. The status register can be understood as a storage unit within the hardware controller reflecting the operating status. After data transmission is complete, the system changes the status variable within the current RS-422 driver adapter program from "running" to "paused," and saves the program counter and register context to the stack frame. Reclaiming the resources occupied by the current virtual communication endpoint is a crucial step in preventing conflicts. The system sends a resource release command to the interface abstraction layer protocol stack, which includes the endpoint identifier. Based on this, the interface abstraction layer protocol stack unregisters the 960 bandwidth allocation parameter units originally occupied by the endpoint from the bandwidth scheduler and releases the "binary amplitude encoding type" resource from the link layer encoding type resource pool. Optionally, the bandwidth allocation parameter unit is a virtualized time slot resource. Optionally, resource release is an atomic operation, ensuring that the reclamation process is not interrupted by requests from new devices.

[0085] In practice, after recovering the old resources, the system begins configuring the new device. The system re-acquires the physical interface configuration data of the newly connected CAN bus communication module via physical layer signals. Assume the acquired physical interface configuration data includes the interface type code "CAN_2.0B", a new pin definition matrix, and the electrical protocol version number "CAN2.0". The system parses this new data to generate a new interface capability descriptor for the CAN bus communication module. This new descriptor may include "1Mbps data transmission rate limit", "NRZ signal modulation method", and "5V / 500mA power supply specification". Subsequently, the system initiates a deregistration operation using the endpoint identifier of the old RS-422 virtual communication endpoint through the interface abstraction layer protocol stack. The interface abstraction layer protocol stack destroys the corresponding object instance and reclaims memory. Next, based on the new interface capability descriptor of the CAN bus communication module, the system calls the creation routine of the interface abstraction layer protocol stack to create a new virtual communication endpoint. The new endpoint obtains a new endpoint identifier and completes the resource configuration of bandwidth, encoding, and power supply according to the new descriptor. Refer to Table 1, which shows a comparison of key parameters between the old and new equipment, explaining why a complete reconfiguration process is necessary.

[0086] Table 1: Comparison of Key Parameters Before and After Equipment Switching

[0087] Interface type encoding RS422_V1.2 CAN_2.0B Data transmission rate 9600bps 1Mbps Signal coding type Binary amplitude encoding Non-return-to-zero encoding Power requirements 5V / 1A 5V / 0.5A Data Link Protocol Character-oriented Message-oriented

[0088] In practice, after creating a new virtual communication endpoint, the system loads a new driver adapter program that matches the CAN bus communication module. The driver matching engine uses "CAN_2.0B" and "CAN2.0" as keys to search for and load the corresponding driver template in the driver library, compiling it into an executable CAN driver adapter program. After successful loading, the system executes the interface initialization sequence in the new driver adapter program, configuring the CAN controller hardware, establishing a new interrupt mapping relationship, and setting packet assembly and depacketization rules according to the CAN protocol's data frame encapsulation format. Finally, the system uses the new driver adapter program and the new virtual communication endpoint to establish a new, independent logical channel between the CAN bus communication module and the UAV flight control system. This new logical channel carries control commands and status feedback data in CAN protocol format, thus achieving a seamless switch from RS-422 communication to CAN bus communication. Throughout the entire switchover process, the upper-level application software of the flight control system only perceives a brief data link interruption and does not need to worry about the changes in the underlying physical devices and drivers. The completeness of resource reclamation can be verified using a checksum. When deregistering an old endpoint, the interface abstraction layer protocol stack calculates and verifies whether all allocated resources have been completely released. This calculation can be represented as:

[0089]

[0090] Where: symbol Represents the resource recycling integrity checksum, symbol This represents the collection of various resources previously allocated to the old virtual communication endpoints, symbolized by... This represents the set of resources successfully reclaimed during the cancellation operation. The summation operation here is logical, representing a comparison of the differences between the sets. When A zero vector indicates that all resources have been fully reclaimed, and new resources can be safely allocated. It is understandable that resource reclamation integrity verification is a crucial mechanism to prevent resource leakage.

[0091] In one embodiment of the present invention, the method further includes a step of periodically self-checking the health status of the interface. A heartbeat detection mechanism is embedded in the driver adapter program, which periodically sends link maintenance commands to the multi-mode communication device. The system receives the heartbeat response data packets returned by the multi-mode communication device, parses the signal strength indicator value and bit error rate statistics value therein, compares the parsed signal strength indicator value and bit error rate statistics value with preset health thresholds, and generates an interface connectivity status code based on the comparison result. When generating the interface connectivity status code, if the signal strength indicator value is lower than a preset lower threshold and the bit error rate statistics value is higher than a preset upper threshold, the interface connectivity status code is marked as a link interruption. If the signal strength indicator value is between the preset upper and lower thresholds and the bit error rate statistics value is within the normal range, the interface connectivity status code is marked as a link degradation. If both the signal strength indicator value and the bit error rate statistics value are within the preset normal range, the interface connectivity status code is marked as a good link. Finally, the results of link interruption, link degradation, and link quality are bound to the current timestamp and stored in a fixed-size circular buffer. At the same time, the interface connectivity status code is written into the telemetry data stream of the UAV flight control system for real-time monitoring and fault diagnosis by the ground control station.

[0092] See Figure 5In the periodic self-check mechanism for the health status of the multi-mode communication device interface of UAV, this graph presents the dynamic changes of signal strength and bit error rate within a 60-minute monitoring period in a biaxial broken line form, and introduces a preset health threshold as a benchmark for link status judgment. The left vertical axis of the graph represents signal strength. The blue line visually reflects the real-time attenuation and recovery process of the received signal: Within 0–10 minutes, the signal strength remains in the excellent range of 85–90 dB. Then, in the 15–30 minute period, it drops significantly, reaching a low of 60 dB, below the preset lower signal strength threshold. Correspondingly, the bit error rate (BER) rises to 0.05% during this period, exceeding the upper BER threshold, meeting the criteria for "link interruption." After 30 minutes, the signal strength gradually recovers, and the BER decreases accordingly. In the 30–55 minute period, the signal strength recovers to the 70–90 dB range, and the BER falls back to 0.01–0.03%, meeting the criteria for "link degradation." Finally, in the 55–60 minute period, the signal strength recovers to 92 dB, and the BER drops to 0.005%, returning to the "excellent link" state. The right vertical axis represents the BER. The red line shows a clear negative correlation with the signal strength line, visually verifying the direct impact of signal quality on data transmission reliability. This diagram fully reproduces the dynamic evolution of the link health status under the periodic self-inspection mechanism, providing a quantitative basis for ground stations to conduct fault early warning and link optimization.

[0093] In practical implementation, the periodic self-check step of the interface health status can be explained in conjunction with the monitoring scenario of the "RS-422 standard serial communication module" during continuous operation. After the driver adapter is successfully loaded and the logical channel is established, the heartbeat detection mechanism embedded in the driver adapter starts working. The heartbeat detection mechanism sends a link maintenance command to the multimode communication device, i.e., the RS-422 communication module, at a fixed time period. The link maintenance command can be a query frame with a specific format, such as containing the command code 0xA5 and a sequence number. After receiving the link maintenance command, the firmware of the RS-422 communication module immediately generates a heartbeat response data packet and returns it. In addition to the command response code, the heartbeat response data packet also encapsulates the real-time signal strength indicator value read from the hardware register and the bit error rate statistics calculated in the previous statistical period. In some embodiments, the signal strength indicator value may be an RSSI value representing the received signal level, and the bit error rate statistics are the ratio of the physical layer's count of received bit errors to the total number of bits. It can be understood that the heartbeat detection mechanism is a necessary means to maintain the logical connection of the link and detect the physical layer status.

[0094] In practical implementation, the system receives and parses the heartbeat response data packets returned by the RS-422 communication module, extracting the raw values ​​of the signal strength indicator (SSI) and bit error rate (BER) statistics from the specified fields of the data packets. The system internally presets health thresholds for assessing link health, including a lower threshold for the SSI, an upper threshold for the BER, and a lower threshold for the SSI. The system compares the parsed real-time SSI and BER with these preset health thresholds and generates an interface connectivity status code representing the current link quality based on the comparison result. The logic for generating the interface connectivity status code follows clear judgment rules: if the real-time SSI is lower than the preset lower threshold and the BER is higher than the preset upper threshold, the interface connectivity status code is marked as "link interrupted." If the real-time SSI is between the preset lower and upper thresholds and the BER is not higher than the upper threshold, the interface connectivity status code is marked as "link degraded." If the real-time SSI is higher than the upper threshold and the BER is lower than the upper threshold, the interface connectivity status code is marked as "link excellent." It is understandable that the preset health threshold needs to be calibrated experimentally based on the specifications of the communication module and the communication environment. In some embodiments, this determination logic can be expressed by a state determination function Φ:

[0095]

[0096] Where: symbol This represents a state determination function, whose output is a state code, symbol... Indicates the real-time signal strength indication value, symbol Represents the real-time bit error rate statistics, symbol The preset lower threshold value for signal strength indication is represented by the symbol. The symbol represents the preset upper limit threshold of the signal strength indication value. This represents the preset upper limit threshold for the bit error rate statistics, symbol [symbol missing]. It represents the logical AND operation.

[0097] In practice, each generated interface connectivity status code needs to be bound to a timestamp at the time of generation. The timestamp is derived from the system's global high-precision clock. The bound "status code-timestamp" data pair is stored in a fixed-capacity circular buffer. The circular buffer operates in a first-in, first-out (FIFO) manner; when the buffer is full, new data overwrites the oldest data. Optionally, the timestamp precision is in the millisecond range. Optionally, the capacity of the circular buffer can be configured to store the results of the most recent 1000 self-tests. Simultaneously, the interface connectivity status code itself is written in real-time to a dedicated field in the telemetry data stream of the UAV flight control system. The telemetry data stream is continuously transmitted to the ground station via a wireless link. The ground station's monitoring software parses this field, thereby enabling remote, real-time monitoring and historical trend review of the RS-422 communication interface connectivity status, and providing status information for operators to diagnose faults. It can be understood that the circular buffer is used for local storage of historical status records, while writing to the telemetry data stream is for remote monitoring.

[0098] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A communication device interface adaptation method, characterized in that, The method includes: Collect physical interface configuration data of the multi-mode communication equipment inside the UAV payload bay. The physical interface configuration data includes interface type code, pin definition matrix and electrical protocol version number. The physical interface configuration data is parsed to generate the interface capability descriptor of the multimode communication device. The interface capability descriptor includes the upper limit of data transmission rate, signal modulation method and power supply specifications. The pre-built interface abstraction layer protocol stack is invoked to map the interface capability descriptor to a unified virtual communication endpoint, which shields the hardware differences between different physical interfaces. Based on the virtual communication endpoint, a driver adapter program matching the multimode communication device is loaded. The driver adapter program includes an interface initialization sequence, interrupt handling rules, and a data frame encapsulation format. Based on the running results of the driver adaptation program, a logical channel is established between the multi-mode communication device and the UAV flight control system. The logical channel is used to carry control commands and status feedback data.

2. The communication device interface adaptation method according to claim 1, characterized in that, Parse the physical interface configuration data to generate the interface capability descriptor of the multimode communication device, including: Extract the bus standard identifier from the interface type code to determine whether the multimode communication device supports hot-plugging operation; Read the power supply pin position and ground pin position in the pin definition matrix, and calculate the rated operating voltage and maximum operating current of the multimode communication device; Retrieve the protocol specification document corresponding to the electrical protocol version number to obtain the handshake signal types and error checking algorithms supported by the version; The obtained rated operating voltage, maximum operating current, handshake signal type, and error checking algorithm are structured and encapsulated to generate the interface capability descriptor containing complete electrical characteristics.

3. The communication device interface adaptation method according to claim 2, characterized in that, The invocation of the pre-defined interface abstraction layer protocol stack maps the interface capability descriptor to a unified virtual communication endpoint, including: In the interface abstraction layer protocol stack, an object instance of a virtual communication endpoint is created, and the object instance contains an endpoint identifier and a state machine; Map the upper limit of the data transmission rate in the interface capability descriptor to the bandwidth allocation parameter of the virtual communication endpoint; Convert the signal modulation method in the interface capability descriptor to the link layer coding type supported by the virtual communication endpoint; Register the power supply specification in the interface capability descriptor to the power management submodule of the interface abstraction layer protocol stack to complete the resource configuration of the virtual communication endpoint.

4. The communication device interface adaptation method according to claim 3, characterized in that, Based on the virtual communication endpoint, a driver adapter program matching the multi-mode communication device is loaded, including: Inject the interface capability descriptor into the object instance of the virtual communication endpoint to trigger the start of the driver matching engine; Traverse the pre-stored driver library to find a driver template that perfectly matches the interface type code and electrical protocol version number; If no perfectly matching driver template is found, a driver template that supports backward compatibility is selected, and a patch configuration file is generated based on the differences in the interface capability descriptor. The selected driver template is merged and compiled with the patch configuration file to generate an executable driver adapter program.

5. The communication device interface adaptation method according to claim 4, characterized in that, The driver adapter program includes an interface initialization sequence, interrupt handling rules, and a data frame encapsulation format. After generating the executable driver adapter program, it further includes: The interface initialization sequence in the driver adapter is sent to the firmware layer of the multimode communication device to complete the physical interface reset and self-test. Configure the interrupt handling rules to establish a mapping relationship between hardware interrupt signals and software event handling functions of the multi-mode communication device; According to the data frame encapsulation format, the uplink status data to the UAV flight control system is packaged, and unpacking and verification are performed when the downlink control command arrives.

6. The communication device interface adaptation method according to claim 5, characterized in that, It also includes a dynamic reconfiguration step during device switching: When a new multimode communication device is detected to be accessing the payload bay, the currently running driver adapter is suspended. The physical interface configuration data of the newly accessed multimode communication device is re-collected, and a new interface capability descriptor is generated. The original virtual communication endpoint is deregistered through the interface abstraction layer protocol stack, and a new virtual communication endpoint is created based on the new interface capability descriptor; A new driver adapter program matching the new device is loaded, and the logical channel between the multi-mode communication device and the UAV flight control system is re-established to achieve communication switching without restarting.

7. A communication device interface adaptation method according to claim 6, characterized in that, When a new multi-mode communication device is detected accessing the payload bay, the currently running driver adapter program is suspended, including: Monitor the interface plug-in / plug-out status signals inside the payload compartment. When the status signal changes from disconnected to connected, trigger the equipment switching interruption. Freeze the data transmission and reception buffer of the current logical channel, wait for the incomplete data frames to be sent, and then mark the current driver adapter program as paused. Reclaim the bandwidth allocation parameters and link layer encoding type resources currently occupied by the virtual communication endpoint to prevent resource conflicts with new devices.

8. The communication device interface adaptation method according to claim 7, characterized in that, It also includes periodic self-check steps for the health status of the interface: A heartbeat detection mechanism is embedded in the driver adapter program to periodically send link maintenance commands to the multimode communication device; Receive the heartbeat response data packet returned by the multi-mode communication device, parse the signal strength indication value and bit error rate statistics value in it, compare the signal strength indication value and bit error rate statistics value with the preset health threshold, and generate an interface connectivity status code; The interface connectivity status code is written into the telemetry data stream of the UAV flight control system for ground station fault diagnosis.

9. A communication device interface adaptation method according to claim 8, characterized in that, The process involves parsing the signal strength indicator and bit error rate statistics, comparing them with a preset health threshold, and generating an interface connectivity status code, including: If the signal strength indication value is lower than the lower threshold and the bit error rate statistics value is higher than the upper threshold, then the interface connectivity status code is marked as a link interruption. If the signal strength indication value is between the upper and lower thresholds and the bit error rate statistics value is normal, then the interface connectivity status code is marked as link degradation; If both the signal strength indication value and the bit error rate statistics value are within the normal range, the interface connectivity status code will be marked as a good link. The results of link interruption, link degradation, and link quality are bound to timestamps and stored in a circular buffer.

10. A communication device interface adaptation system, 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 steps of the communication device interface adaptation method according to any one of claims 1 to 9.

Images