Data transmission method and apparatus, electronic device, and storage medium

By converting and transmitting standardized data at the device access layer and generating business data using preset fusion operators, the problems of code redundancy and high coupling when accessing heterogeneous hardware devices are solved, achieving fast access and efficient data transmission.

CN121940447BActive Publication Date: 2026-06-23SICHUAN AOSSCI TECHNOLOGY CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
SICHUAN AOSSCI TECHNOLOGY CO LTD
Filing Date
2026-03-31
Publication Date
2026-06-23

Smart Images

  • Figure CN121940447B_ABST
    Figure CN121940447B_ABST
Patent Text Reader

Abstract

The application provides a data transmission method and device, electronic equipment and storage medium. The method obtains initial data of at least two target physical devices of a device access layer, converts the initial data into a preset standard data format to obtain standardized data, generates service data based on all the standardized data, and sends the standardized data and the service data to a message middleware to transmit the standardized data and the service data to a data application layer through the message middleware. Thus, an upper-layer application of the data application layer does not need to write fusion code, and a newly-added application does not need to be repeatedly developed, direct service data can be obtained, system coupling degree is reduced, and maintenance cost is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data transmission method, apparatus, electronic device, and storage medium. Background Technology

[0002] In fields such as the Industrial Internet of Things (IIoT), unmanned system integration (e.g., drones, robot dogs, autonomous vehicle collaboration), and smart city construction, systems often need to simultaneously connect to a massive number of heterogeneous hardware devices. These devices are diverse, including but not limited to LiDAR, optoelectronic pods, environmental sensors, and positioning modules (GPS / RTK). These hardware devices are typically manufactured by different companies and exhibit significant differences: communication protocols cover various forms such as TCP, UDP, serial ports (RS232 / RS485), Modbus, and CAN; data formats vary from binary streams and hexadecimal strings to proprietary protocols; even for the same physical quantity (e.g., "longitude"), different devices have significant differences in data type definitions (floating-point vs. integer), units (degrees vs. radians), and precision.

[0003] In related technologies, the technical model of "direct driver connection and upper-layer fusion" is adopted when handling the access and data application of such heterogeneous devices. The specific implementation of this model is as follows: First, at the device access layer, developers need to consult the communication protocol manual of each device and write dedicated driver code (usually using C++ or Python) for each new device. The driver is responsible for establishing physical connections, parsing specific binary data packets, and directly passing the parsed data to the upper-layer application. Second, at the data application layer (such as tactical cloud platforms, ground station systems, etc.), in order to obtain high-level information with business value (such as "the absolute geographic coordinates of the target"), developers need to write complex fusion logic in the application layer code. For example, to calculate the absolute coordinates of a detected target, the application layer needs to simultaneously subscribe to "the UAV's own GPS coordinates," "the attitude angle of the electronic compass," and "the relative distance and angle detected by radar," and then perform time alignment and geometric calculations in the business code.

[0004] In this model, data fusion logic (such as coordinate transformation and multi-sensor correlation) is hard-coded into specific upper-layer applications. If an external system needs to be added (e.g., a data visualization dashboard or third-party command center) that also needs to use the same fused data, developers must rewrite the same fusion logic (fusion code) in the new system. This not only leads to a large amount of code redundancy, but also requires that all related code in the upper-layer applications be modified synchronously if the physical parameters of the underlying devices are slightly adjusted (e.g., a radar of different precision is replaced). This results in high system coupling and extremely high maintenance costs. Summary of the Invention

[0005] This application provides a data transmission method, apparatus, electronic device, and storage medium to solve the technical problems in related technologies, such as the need to write integration code for upper-layer applications, the need for repeated development to directly obtain business data when adding new applications, high system coupling, and high maintenance costs.

[0006] This application provides a data transmission method, the method comprising: acquiring initial data from at least two target physical devices in the device access layer; converting the initial data into a preset standard data format to obtain standardized data; generating business data based on the standardized data of all target physical devices; and sending the standardized data and business data to a message middleware to transmit the standardized data and business data to the data application layer through the message middleware.

[0007] In one embodiment of this application, generating service data based on standardized data of all target physical devices includes: obtaining a preset fusion operator; determining operator input data from the standardized data of all target physical devices according to the input data items of the preset fusion operator; and inputting the operator input data into the preset fusion operator to obtain the service data.

[0008] In one embodiment of this application, determining operator input data from standardized data of all target physical devices based on the input data items of the preset fusion operator includes: obtaining trigger data items of the preset fusion operator, wherein the trigger data items are one of the input data items of the preset fusion operator; if the standardized data includes data of the trigger data items, obtaining the trigger data acquisition time of the standardized data; determining associated input data from the stored standardized data based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data, wherein the associated input data is data of other data items, and the other data items are input data items of the preset fusion operator other than the trigger data items; and generating the operator input data based on the associated input data and the data of the trigger data items.

[0009] In one embodiment of this application, determining associated input data from stored standardized data based on the trigger data acquisition time and the standardized data acquisition time of stored standardized data includes: if the time difference between the standardized data acquisition time of the standardized data corresponding to the other data item and the trigger data acquisition time is less than a preset time difference, determining the standardized data corresponding to the other data item as the associated input data; or, obtaining the standardized data corresponding to the other data item at a standardized data acquisition time before the trigger data acquisition time, denoted as the preceding data, and obtaining the standardized data corresponding to the other data item at a standardized data acquisition time after the trigger data acquisition time, denoted as the following data, determining the fitted data of the other data item at the trigger data acquisition time based on the preceding data, the following data, the trigger data acquisition time, the standardized data acquisition time of the preceding data, and the standardized data acquisition time of the following data, and determining the fitted data as the associated input data.

[0010] In one embodiment of this application, the method further includes: caching the standardized data through a data cache queue based on a sliding time window, wherein standardized data for one input data item corresponds to one data cache queue, and the business data is determined based on standardized data corresponding to at least two input data items.

[0011] In one embodiment of this application, the method for generating the initial data includes: obtaining an initial data packet of the target physical device; obtaining a data extraction rule by matching the device identifier of the target physical device; extracting the original fields in the initial data packet based on the data extraction rule; and generating the initial data based on the original fields.

[0012] In one embodiment of this application, the method further includes: obtaining a configuration modification request, the configuration modification request including at least one of device change information, data extraction rule update information, preset fusion operator change information, and trigger data item change information; if the configuration modification request includes device change information, determining a new target physical device based on the device change information; if the configuration modification request includes data extraction rule update information, determining a new data extraction rule based on the data extraction rule update information, extracting original fields from the initial data packet of the target physical device based on the new data extraction rule, and generating the initial data based on the original fields; if the configuration modification request includes preset fusion operator change information, determining a new preset fusion operator based on the preset fusion operator change information, and determining new service data through the new preset fusion operator and new operator input data; if the configuration modification request includes trigger data item change information, determining a new trigger data item based on the trigger data item change information, and when the standardized data of the new trigger data item is obtained, triggering the step of determining operator input data from the standardized data of all target physical devices based on the input data item of the preset fusion operator.

[0013] This application embodiment also provides a data transmission apparatus, the apparatus comprising: an acquisition module for acquiring initial data from at least two target physical devices in the device access layer; a format conversion module for converting the initial data into a preset standard data format to obtain standardized data; a business data generation module for generating business data based on the standardized data from all target physical devices; and a data transmission module for sending the standardized data and business data to a message middleware, so as to transmit the standardized data and business data to the data application layer through the message middleware.

[0014] This application also provides an electronic device, including: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the steps of the method described in any of the above embodiments.

[0015] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0016] The beneficial effects of this application are as follows: The data transmission method, apparatus, electronic device, and storage medium proposed in the embodiments of this application acquire initial data from at least two target physical devices in the device access layer, convert the initial data into a preset standard data format to obtain standardized data; generate business data based on all the standardized data, and send the standardized data and business data to a message middleware so that the standardized data and business data can be transmitted to the data application layer through the message middleware. In this way, the upper-layer application of the data application layer does not need to write integration code, and when adding new applications, there is no need to repeat development. It can directly acquire business data, reduce system coupling, and reduce maintenance costs. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0018] In the attached diagram:

[0019] Figure 1 A schematic flowchart of a data transmission method provided in an embodiment of this application;

[0020] Figure 2 A schematic diagram of spatiotemporal synchronization provided in an embodiment of the present invention;

[0021] Figure 3 A specific flowchart illustrating a data transmission method provided in an embodiment of this application;

[0022] Figure 4 A schematic diagram of a data transmission apparatus provided in an embodiment of this application;

[0023] Figure 5 A schematic diagram of the structure of a data transmission system provided in an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0026] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0028] Please see Figure 1 , Figure 1 A schematic flowchart of a data transmission method provided in an embodiment of this application is shown below. Figure 1 As shown, the method includes the following steps:

[0029] Step S110: Obtain initial data from at least two target physical devices in the device access layer.

[0030] As an example, this method can be applied to the edge side (middleware layer, or core middleware service layer) by constructing a "virtual device" that does not exist as a physical entity. This virtual device can be a software-defined virtual device (SDVD), a logical device that exists through software configuration rather than physical connection, whose data is derived from data from one or more physical devices.

[0031] As an example, the choice of which physical devices to use can be determined based on the needs of the business data mentioned later, that is, the data source for the virtual devices. For instance, if the business data is the target longitude and latitude, it needs to be determined based on the UAV's GPS data, the magnetic declination data (heading angle (or attitude angle) data) from the electronic compass, and the distance and angle data provided by the lidar. In this case, the target physical devices can be the UAV's GPS module, the electronic compass, and the lidar.

[0032] Among them, at least two target physical devices are heterogeneous devices, which are hardware devices with different communication interfaces, transmission protocols, and data formats.

[0033] The device access layer includes multiple physical devices. At least two of these are selected as the target physical devices for the current virtual device based on the defined requirements of the business data. One or more virtual devices can exist in the system architecture, and their configuration is based on the specific needs of the business data.

[0034] In the system architecture, a virtual device logically corresponds to a specific business application requirement. Its output business data can be a single numerical result or a structured data set containing multiple data fields (such as longitude, latitude, and altitude). Correspondingly, the preset fusion operator configured for this virtual device can be a single mathematical calculation formula or a set of complex logical rules composed of multiple algorithms (such as coordinate transformation matrices, filtering algorithms, etc.).

[0035] In one embodiment, the method for generating initial data includes: acquiring an initial data packet of the target physical device; obtaining data extraction rules based on the device identifier of the target physical device; extracting original fields from the initial data packet based on the data extraction rules; and generating initial data based on the original fields.

[0036] Data extraction rules can be formulated in advance by those skilled in the art based on rules such as the data format of the initial data packet.

[0037] As an example, the initial data can be generated using a generic protocol parsing engine, which is responsible for the access of the target physical device. Based on the definitions (data extraction rules) in the "driver configuration," it dynamically identifies the frame structure of the data stream (including the initial data packet), extracts raw fields (such as voltage values, angle values, distance values, etc.), and then uses these raw fields as the initial data. This initial data includes specific data values ​​and the corresponding initial data acquisition time, which is also the standardized data acquisition time mentioned later.

[0038] As an example, this data extraction rule can be implemented using configuration files (such as YAML format), Lua scripts, or Python scripts.

[0039] Step S120: Convert the initial data into a preset standard data format to obtain standardized data.

[0040] The preset standard data format can be defined by those skilled in the art as needed, such as JSON data format. The specific implementation method for converting different data formats into the preset standard data format can be implemented in a way known to those skilled in the art, and will not be elaborated here.

[0041] In one embodiment, the method further includes: caching standardized data through a data cache queue based on a sliding time window, wherein standardized data for one input data item corresponds to one data cache queue, and business data is determined based on standardized data corresponding to at least two input data items.

[0042] The length of the sliding event window can be set according to the needs of those skilled in the art. Standardized data for each input data item is stored separately in a corresponding data cache queue, allowing for quick retrieval of the corresponding data when needed.

[0043] The input data items are the data items corresponding to the data needed to determine the business data later, such as the distance, angle and other data items mentioned above.

[0044] Step S130: Generate business data based on standardized data from all target physical devices.

[0045] In one embodiment, generating service data based on standardized data of all target physical devices includes: obtaining a preset fusion operator; determining operator input data from the standardized data of all target physical devices according to the input data items of the preset fusion operator; and inputting the operator input data into the preset fusion operator to obtain service data.

[0046] As an example, business data can be generated based on standardized data from some or all of the data items of all target physical devices. Specifically, when the output of a target physical device contains multiple data items (i.e., multiple standardized data), one or more data items can be selected as input data for the operator to generate the current business data, according to the requirements of the preset fusion operator. Other unselected data items output by the device can be passed through the message middleware to the upper-layer application for further processing, or used as input to other preset fusion operators to generate another type of business data.

[0047] In one embodiment, the preset fusion operator is implemented through declarative configuration or an executable script. Specifically, the preset fusion operator can be constructed and loaded by parsing configuration files in formats such as YAML and JSON; alternatively, the underlying computational logic of the preset fusion operator can be implemented by dynamically loading interpreted script code such as Lua or Python scripts at runtime. Using these methods, the system can perform hot updates or deploy new fusion logic at runtime without recompilation, thereby achieving dynamic expansion of the operator. When configuring the preset fusion operator, a corresponding trigger data item is configured. Subsequently, after obtaining the standardized data corresponding to the trigger data item, the determination of data for other data items is triggered, that is, the determination of associated input data is triggered, which is also the step of determining the operator input data.

[0048] It is understandable that the preset fusion operator configuration has at least two input data items, one of which is used as the trigger data item, and the other input data items are used as other data items.

[0049] This approach introduces the concept of "virtual devices" at the middleware layer. Virtual devices do not correspond to specific physical hardware IPs but are logical entities defined through software configuration. The system has a built-in virtual device construction engine that allows users to reference standardized data fields (standardized data) from multiple physical devices as input sources via configuration files and define fusion operators (such as coordinate transformation formulas, Kalman filtering, and other preset fusion operators). The engine automatically calculates and synthesizes the raw data from multiple physical devices in real time into the output data of the virtual device, obtaining the business data. Compared to related technologies that hardcode the fusion logic into upper-layer applications, the method provided in this embodiment pushes the fusion logic down to the middleware, dynamically generating "virtual sensors" through configuration. Upper-layer applications only need to subscribe to the data from these virtual devices without needing to concern themselves with the calculation process. Through "virtual device" technology, complex business calculation logic is encapsulated within the middleware. Upper-layer applications (such as tactical clouds and ground stations) only need to read the "virtual target data" like ordinary sensors, without writing any fusion code. When adding new applications, there is no need for repeated development; direct subscription achieves system decoupling and greatly improves reusability.

[0050] Different physical devices often have different sampling frequencies (e.g., radar at 10Hz, GPS at 5Hz). In related technologies, upper-layer applications typically simply acquire the latest frame of data for calculation, making it difficult to accurately handle microsecond-level time alignment at the edge. This accumulation of spatiotemporal errors leads to significant deviations in the final calculated target positions and other business data. This is especially true in high-speed unmanned system scenarios, where data availability is greatly reduced due to the spatiotemporal asynchrony of heterogeneous data, resulting in decreased data accuracy. To address the aforementioned issues, following the previous embodiments, operator input data is determined from standardized data of all target physical devices based on the input data items of a preset fusion operator. This includes: acquiring trigger data items of the preset fusion operator, where the trigger data item is one of the input data items of the preset fusion operator; if the standardized data includes data from the trigger data item, acquiring the trigger data acquisition time of the standardized data; determining associated input data from the stored standardized data based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data, where the associated input data is data from other data items, and the other data items are input data items of the preset fusion operator other than the trigger data item; and generating operator input data based on the associated input data and the trigger data item data.

[0051] Using multi-source data with significantly different acquisition times to determine business data may lead to poor accuracy. However, multiple target physical devices may have different sampling rates, resulting in differences in the initial data acquisition times. In this case, spatiotemporal synchronization of the multi-source data can be performed to minimize errors caused by time asynchrony. For example, the determination of associated input data can be based on whether standardized data for a triggering data item has been obtained. If standardized data X corresponding to the triggering data item exists (i.e., the standardized data includes the data of the triggering data item), then the standardized data acquisition time of this standardized data X is used as the triggering data acquisition time. Based on this triggering data acquisition time, associated input data can then be found from other data items in other data cache queues. Associated input data can be data acquired closer to the triggering data acquisition time, or it can be obtained by fitting data to the triggering data acquisition time using methods such as interpolation.

[0052] Following the above embodiments, determining associated input data from the stored standardized data based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data includes: if the time difference between the standardized data acquisition time of the standardized data corresponding to other data items and the trigger data acquisition time is less than a preset time difference, the standardized data corresponding to the other data items is determined as the associated input data. It can be understood that if the data acquisition times are sufficiently close, standardized data can be used directly, which can save computing power and improve processing speed.

[0053] Following the above embodiments, the associated input data is determined from the stored standardized data based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data. This includes: obtaining the standardized data corresponding to other data items at a standardized data acquisition time prior to the trigger data acquisition time, denoted as the preceding data; and obtaining the standardized data corresponding to other data items at a standardized data acquisition time following the trigger data acquisition time, denoted as the following data. Based on the preceding data, following data, trigger data acquisition time, the standardized data acquisition time of the preceding data, and the standardized data acquisition time of the following data, the fitted data of other data items at the trigger data acquisition time is determined, and the fitted data is determined as the associated input data. If higher data accuracy is required, or if there is no data with sufficiently close acquisition times, interpolation can also be used to fit the data, which can then be used as the associated input data. A linear function can be fitted based on the preceding data, following data, the standardized data acquisition time of the preceding data, and the standardized data acquisition time of the following data, and then the trigger data acquisition time can be substituted into this function to obtain the fitted data.

[0054] Please see Figure 2 , Figure 2 A schematic diagram of spatiotemporal synchronization provided in an embodiment of the present invention, as shown below. Figure 2 As shown, when performing spatiotemporal synchronization of standardized data (multi-source heterogeneous data) from different target physical devices, taking physical device A, physical device B, and physical device C as examples, the horizontal axis represents the data acquisition time. Physical device A (UAV GPS): provides latitude and longitude fields (i.e., Figure 2 In the Lat and Lon fields, the sampling rate is 5Hz; Physical device B (electronic compass): provides the heading field (i.e., ... Figure 2 (Heading in the image), sampling rate 20Hz; physical device C (LiDAR, i.e. Figure 2 The radar in the middle, as the main trigger: provides the distance and angle fields (i.e., Figure 2The data is located at Dist and Angle, with a sampling rate of 10Hz. In this embodiment, the LiDAR data collected by physical device C is used as the trigger data item. During the time window of 00.000-00.050, data frame A1 (T=0ms) from physical device A and data frame B1 (T=0ms) from physical device B are collected; during the time window of 00.050-00.100, data frame B2 (T=50ms) from physical device B is collected; during the time window of 00.100-00.150, data frame B3 (T=100ms) from physical device B and data frame C1 (arriving at T=110ms) from physical device C are collected. At this time, the time window of 00.100-00.150 is designated as window 1 (C1), and data from physical devices A and B are used to match C1. During the time window of 00.150-00.200, data frame B4 (T=150ms) from physical device B is acquired. During the time window of 00.200-00.250, data frame B5 (T=200ms) from physical device B, data frame A2 (T=200ms) from physical device A, and radar frame C2 (arriving at T=210ms) are acquired. The time window of 00.200-00.250 is then designated as window 2 (C2), and data from physical devices A and B are used to match C2. For window 1, as an example, the compass data obtained from the data frame B3 with the closest timestamp can be directly used as the associated input data. However, the acquisition time of the data frame (A1) corresponding to physical device A is relatively far back; therefore, interpolation can be used to determine the fitted data corresponding to T=110ms as the associated input data. For window 2, as an example, the standardized data obtained from the data frames B5 and A2 with the closest timestamps can be directly used as the associated input data. By specifying a device (e.g., ... Figure 2 The system uses data from a trigger-type LiDAR as a synchronization time reference. When the reference data arrives, the system selects the closest data frame in time from the data buffer queues of other sensors, according to a preset time window (considering transmission and processing delays). The matched multi-source data is then sent out as a "time-aligned" dataset for use by upper-layer applications, thus ensuring that the fusion algorithm processes the environmental state at the same moment.

[0055] By designing a spatiotemporal synchronization and alignment mechanism for multi-source heterogeneous data, and addressing the issue of inconsistent sampling frequencies among different physical devices, a sliding time window mechanism is employed to cache input data (standardized data) from various sources. When the primary trigger source (such as radar data or data from trigger data items) arrives, the system automatically searches the cache for other auxiliary data (such as GPS, attitude, and other related input data) with the closest timestamps, or generates data slices at alignment moments using linear interpolation algorithms, ensuring that the data participating in the fusion calculation are strictly synchronized in the time dimension. This underlying synchronization mechanism significantly improves the accuracy of data fusion, achieving the requirement for precise alignment of heterogeneous frequency data. A microsecond-level spatiotemporal synchronization mechanism can be preset, which can solve the time jitter problem in multi-sensor fusion and ensure the accuracy of the final output data.

[0056] Step S140: Send standardized data and business data to the message middleware so that the standardized data and business data can be transmitted to the data application layer through the message middleware.

[0057] As an example, standardized data and business data can be obtained from upper-layer applications in the data application layer through a subscription method.

[0058] As an example, message middleware could be other message middleware such as MQTT message bus, Kafka, ZeroMQ, or DDS (Data Distribution Service).

[0059] In one embodiment, the method further includes: obtaining a configuration modification request, the configuration modification request including at least one of device change information, data extraction rule update information, preset fusion operator change information, and trigger data item change information; if the configuration modification request includes device change information, determining a new target physical device based on the device change information; if the configuration modification request includes data extraction rule update information, determining a new data extraction rule based on the data extraction rule update information, extracting original fields from the initial data packet of the target physical device based on the new data extraction rule, and generating initial data based on the original fields; if the configuration modification request includes preset fusion operator change information, determining a new preset fusion operator based on the preset fusion operator change information, and determining new service data through the new preset fusion operator and new operator input data; if the configuration modification request includes trigger data item change information, determining a new trigger data item based on the trigger data item change information, and when the standardized data of the new trigger data item is obtained, triggering the step of determining operator input data from the standardized data of all target physical devices based on the input data item of the preset fusion operator.

[0060] In related technologies, connecting any new device requires a cumbersome process of "coding-compiling-deployment," typically taking 3-7 working days. This is an unacceptable bottleneck for emergency scenarios or agile development scenarios that require rapid integration of multiple payloads, resulting in high connection costs and an inability to adapt to rapid on-site deployment. The aforementioned method, however, can be adjusted through configuration management. Configuration modification requests can be used to modify the target physical device, data extraction rules, preset fusion operators, and trigger data items, making implementation simpler and significantly reducing the technical requirements for personnel. Based on a configuration-driven general protocol parsing and end-to-end decoupled architecture, the hard-coded approach can be abandoned, and declarative configuration (YAML / JSON) can be used to describe device protocols (frame header, length, field offsets). The general parsing engine dynamically extracts data based on the configuration to obtain initial data. Simultaneously, both the standardized data obtained from the original data of physical devices and the fused data (business data) of virtual devices are published through a unified MQTT message bus, achieving zero-coding across the entire link from access to distribution, and completely decoupling data producers (physical / virtual devices) and consumers (applications). In this way, field engineers can combine new "business devices" (such as fusing new temperature and humidity sensors with location information) in minutes by modifying text configuration files, without recompiling the software, which greatly improves the system's adaptability to the field and increases development efficiency.

[0061] The data transmission method provided in the above embodiments obtains initial data from at least two target physical devices in the device access layer, converts the initial data into a preset standard data format to obtain standardized data, generates business data based on all the standardized data, and sends the standardized data and business data to a message middleware. The message middleware then transmits the standardized data and business data to the data application layer. This eliminates the need for upper-layer applications in the data application layer to write integration code, and avoids redundant development when adding new applications. It enables direct acquisition of business data, reduces system coupling, and lowers maintenance costs. It achieves zero-code rapid access to heterogeneous hardware devices, eliminating the cumbersome process of traditional driver development.

[0062] By adopting a two-tier architecture of "configuration-driven (the system's behavior logic is mainly determined by external configuration files rather than hard-coded in the program) access + software-defined virtual device (SDVD)", the system can achieve automatic alignment and real-time fusion of multi-source heterogeneous data by directly building "virtual devices" without physical entities at the edge (middleware layer). This will eliminate the dependence of upper-layer applications on the complex computing logic of the lower layer and achieve "one-time fusion, multiple reuse".

[0063] Please see Figure 3 , Figure 3A specific flowchart illustrating a data transmission method provided in an embodiment of this application is shown below. Figure 3 As shown, taking the construction of a "fusion target detection virtual device" as an example, the method includes:

[0064] First, define the input source and fusion logic (configuration phase). The user defines a virtual device with the ID FUSION_TARGET_01 in the configuration file. The heterogeneous physical devices (input layer) whose data sources are specified in the configuration include:

[0065] Physical device A (drone GPS): provides latitude (Lat) and longitude (Lon) fields (GPS data), with a sampling rate of 5Hz.

[0066] Physical device B (electronic compass): provides a Heading field (compass data) with a sampling rate of 20Hz.

[0067] Physical device C (LiDAR): Provides distance (Dist), Angle field (radar data), sampling rate 10Hz.

[0068] At the same time, the fusion formula (preset fusion operator) is written in the configuration, describing how to use the above fields to calculate the absolute coordinates of the target.

[0069] Then, multi-source data acquisition and standardized mapping (parsing phase) are performed. After the system starts, the general protocol parsing engine establishes connections with devices A, B, and C respectively, performs format conversion and standardized mapping, parses the binary stream in real time (based on data extraction rules), and pushes the standardized JSON data (standardized data) stream to the system's internal data bus.

[0070] Then, spatiotemporal synchronization and data alignment (synchronization phase) are performed. The virtual device engine listens for relevant data streams. Due to different device sampling rates (5Hz vs 20Hz vs 10Hz), the engine enables a sliding time window to cache the most recently received data packets. Each normalized stream is stored in its corresponding cache queue: GPS data is cached in the GPS data cache queue, compass data in the compass data cache queue, and radar data in the radar data cache queue. It determines whether the primary trigger source radar data has arrived; in this example, the radar data is configured as the "Trigger Source." Whenever a frame of radar data is received (at time T0), the engine immediately locks onto that frame and searches it in the GPS and compass data cache queues, matching the frame whose timestamp is closest to T0 (or performing linear interpolation to calculate an estimate of time T0, followed by time window matching / interpolation fitting). This process ensures that all variables involved in the calculation are at the same physical time, resulting in an aligned data set (at time T0), which is the operator input data.

[0071] Next comes the fusion computing and virtual deployment (deployment phase). The fusion computing engine substitutes the aligned data sets into a predefined fusion formula (the figure only shows an example of one formula) to calculate Target_Latitude and Target_Longitude (the absolute coordinates of the target).

[0072] The engine then encapsulates these two results (the absolute coordinates of the target) into a standard JSON message and assigns it the virtual device ID FUSION_TARGET_01.

[0073] The message is published to the MQTT topic snai / devices / FUSION_TARGET_01 / data to publish data services.

[0074] Finally, the upper-layer application (data application layer / message middleware) can subscribe to snai / devices / FUSION_TARGET_01 / data to directly obtain high-precision absolute coordinates of the target, without needing to know which sensors are connected at the lower level or to handle complex spatiotemporal synchronization algorithms. As an example, the upper-layer application could be a ground station system or a cloud platform.

[0075] In one embodiment, a data transmission apparatus is provided, which is used to perform the data transmission method provided in any of the above embodiments. See also... Figure 4 , Figure 4 A schematic diagram of a data transmission apparatus provided in an embodiment of this application is shown below. Figure 4As shown, the data transmission device 400 includes: an acquisition module 410 for acquiring initial data from at least two target physical devices in the device access layer; a format conversion module 420 for converting the initial data into a preset standard data format to obtain standardized data; a business data generation module 430 for generating business data based on the standardized data from all target physical devices; and a data transmission module 440 for sending the standardized data and business data to a message middleware, so that the standardized data and business data can be transmitted to the data application layer through the message middleware.

[0076] In one embodiment, the device further includes a spatiotemporal synchronization submodule, used to acquire trigger data items of a preset fusion operator, wherein the trigger data items are one of the input data items of the preset fusion operator; if the standardized data includes data of the trigger data items, acquire the trigger data acquisition time of the standardized data; determine associated input data from the stored standardized data based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data, wherein the associated input data is data of other data items, and the other data items are input data items of the preset fusion operator other than the trigger data items; and generate operator input data based on the associated input data and the trigger data items.

[0077] Please see Figure 5 , Figure 5 A specific structural diagram of a data transmission system provided in an embodiment of this application is shown below. Figure 5 As shown, the data transmission system mainly consists of four layers from bottom to top: hardware access layer (physical device layer, device access layer), core middleware service layer (including configuration management, protocol parsing, and virtual device engine), unified message bus layer, and application interface layer.

[0078] The hardware access layer includes, but is not limited to, target physical devices such as robot dogs, GPS, and radar. The robot dog uses the TCP protocol for data transmission, the GPS uses Serial (serial communication) for data transmission, and the radar uses the UDP protocol.

[0079] In the core middleware service layer:

[0080] The configuration management module is the control center of the system, responsible for loading and parsing all configuration files (such as YAML format configuration files, JSON configuration files, etc.). The configuration files are divided into two categories: one is the "driver configuration (including data extraction rules)" which describes the communication protocol of physical devices, and the other is the "virtual device configuration (including preset fusion operators)" which describes the multi-source data fusion logic.

[0081] The general protocol parsing engine is responsible for the access of physical devices. Based on the definitions in the "driver configuration," it performs multi-protocol communication adaptation, dynamically identifies the frame structure of the data stream, extracts raw fields (such as voltage and angle values), and converts them into a system-unified standard data format. It can achieve multi-protocol communication adaptation, parse binary streams, and then perform standardization mapping (format conversion module) to obtain standardized data (i.e.,...). Figure 5 (Standardized raw data in the data).

[0082] The Software-Defined Virtual Device (SDVD) build engine (an implementation of the business data generation module) is the core component. It comprises two sub-modules:

[0083] Spatiotemporal synchronization module (spatiotemporal synchronization submodule): Used to receive data streams from multiple physical devices of the parsing engine and time-align the data of heterogeneous frequencies according to a preset strategy (nearest neighbor matching or interpolation).

[0084] The converged computing module executes arithmetic logic or complex algorithms defined in the configuration file (executing preset converged operators), subscribes to standardized data (raw data) from the unified message bus, and generates business data for the virtual device. After generating the business data, it publishes the virtual data (business data) to the message bus.

[0085] One example of a preset fusion operator is:

[0086] ,

[0087] Where Target_Lat is the target latitude obtained by fusion calculation, GPS_Lat is the current device latitude extracted from GPS data, Distance is the relative detection distance in lidar data, Angle is the heading angle in electronic compass data, and C is a preset metric conversion coefficient for converting distance to latitude difference (for example, a constant of 111320 meters / degree).

[0088] Unified Message Bus (MQTT Broker): Used for data distribution and unified data exchange. This module can decouple data producers and consumers through a publish / subscribe (Pub / Sub) model. As an example, the parsing results (standardized data) of physical devices can be published to a first-class preset topic (e.g., root node / devices / phy / {physical_id} / data), while the fusion results (business data) of virtual devices can be published to a second-class preset topic (e.g., root node / devices / virtual / {virtual_id} / data).

[0089] The application interface layer connects to upper-layer applications, such as tactical cloud platforms, ground station systems, and data dashboards. These upper-layer applications can subscribe to business data and underlying standardized data from the unified message bus according to actual business needs, thereby enabling the direct acquisition and display of multi-dimensional situational information.

[0090] For specific limitations regarding the data transmission device, please refer to the limitations on the data transmission method above, which will not be repeated here. Each module in the aforementioned data transmission device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the electronic device, or stored in software in the memory of the electronic device, so that the processor can call and execute the operations corresponding to each module.

[0091] In this embodiment, the data transmission device is essentially configured with multiple modules to execute the data transmission method in any of the above embodiments. The specific functions and technical effects can be referred to in the above embodiments, and will not be repeated here.

[0092] See Figure 6 , Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown below. Figure 6 As shown, this embodiment of the invention also provides an electronic device 600, including a processor 601, a memory 602, and a communication bus 603; the communication bus 603 is used to connect the processor 601 and the memory 602; the processor 601 is used to execute a computer program stored in the memory 602 to implement the method described in any of the above embodiments.

[0093] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0094] This application also provides a non-volatile readable storage medium storing one or more modules (programs) that, when applied to a device, enable the device to execute the instructions included in the steps provided in this application.

[0095] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0096] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0097] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0098] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0099] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0100] It should be understood that the terms "first," "second," etc., used in this application are used to distinguish similar objects and do not necessarily indicate a specific order or sequence. The technical features to which these terms are used can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0101] It should be understood that although the flowcharts provided in the embodiments of this application indicate the various steps with arrows, the order indicated by the arrows does not necessarily limit the implementation order of these steps. Those skilled in the art can perform these steps in other orders according to different implementation scenarios and requirements.

[0102] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A data transmission method, characterized by, The method includes: Acquire initial data from at least two target physical devices at the device access layer; The initial data is converted into a preset standard data format to obtain standardized data; Business data is generated based on standardized data from all target physical devices; The standardized data and business data are sent to the message middleware so that the standardized data and business data can be transmitted to the data application layer through the message middleware. This includes generating business data based on standardized data from all target physical devices, including: Obtain the preset fusion operator; The operator input data is determined from the standardized data of all target physical devices according to the input data items of the preset fusion operator, wherein the preset fusion operator is configured with at least two input data items; The operator input data is input into the preset fusion operator to obtain the business data.

2. The data transmission method of claim 1, wherein, Based on the input data items of the preset fusion operator, the operator input data is determined from the standardized data of all target physical devices, including: Obtain the trigger data item of the preset fusion operator, wherein the trigger data item is one of the input data items of the preset fusion operator; If the standardized data includes data from the trigger data item, obtain the trigger data collection time of the standardized data; Based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data, the associated input data is determined from the stored standardized data. The associated input data is data from other data items, which are input data items other than the trigger data item in the input data items of the preset fusion operator. The operator input data is generated based on the associated input data and the data from the trigger data items.

3. The data transmission method of claim 2, wherein, Based on the trigger data acquisition time and the standardized data acquisition time of the stored standardized data, the associated input data is determined from the stored standardized data, including: If the time difference between the standardized data collection time of the standardized data corresponding to the other data items and the trigger data collection time is less than a preset time difference, the standardized data corresponding to the other data items will be determined as the associated input data. or, Obtain the standardized data corresponding to other data items at a standardized data collection time one time before the triggering data collection time, denoted as the preceding data; and obtain the standardized data corresponding to other data items at a standardized data collection time one time after the triggering data collection time, denoted as the following data. Based on the preceding data, following data, triggering data collection time, standardized data collection time of preceding data, and standardized data collection time of following data, determine the fitted data of the other data items at the triggering data collection time, and determine the fitted data as the associated input data.

4. The data transmission method as described in claim 1, characterized in that, The method further includes: caching the standardized data through a data cache queue based on a sliding time window, wherein standardized data for one input data item corresponds to one data cache queue, and the business data is determined based on standardized data corresponding to at least two input data items.

5. The data transmission method according to any one of claims 1-4, characterized in that, The initial data is generated in the following ways: Obtain the initial data packet of the target physical device; Data extraction rules are obtained by matching the device identifier of the target physical device, and the original fields in the initial data packet are extracted based on the data extraction rules. The initial data is generated based on the original fields.

6. The data transmission method according to any one of claims 1-4, characterized in that, The method further includes: Obtain a configuration modification request, wherein the configuration modification request includes at least one of the following: device change information, data extraction rule update information, preset fusion operator change information, and trigger data item change information; If the configuration modification request includes device change information, determine the new target physical device based on the device change information; If the configuration modification request includes data extraction rule update information, a new data extraction rule is determined according to the data extraction rule update information, and the original fields of the initial data packet of the target physical device are extracted based on the new data extraction rule to generate the initial data based on the original fields; If the configuration modification request includes preset fusion operator change information, a new preset fusion operator is determined based on the preset fusion operator change information, and new business data is determined through the new preset fusion operator and the new operator input data; If the configuration modification request includes trigger data item change information, a new trigger data item is determined based on the trigger data item change information. When the standardized data of the new trigger data item is obtained, the step of determining the operator input data from the standardized data of all target physical devices based on the input data item of the preset fusion operator is triggered.

7. A data transmission device, characterized in that, The apparatus, applied to the data transmission method as described in any one of claims 1-6, comprises: The acquisition module is used to acquire initial data from at least two target physical devices in the device access layer; The format conversion module is used to convert the initial data into a preset standard data format to obtain standardized data. The business data generation module is used to generate business data based on standardized data from all target physical devices. The data transmission module is used to send the standardized data and business data to the message middleware, so that the standardized data and business data can be transmitted to the data application layer through the message middleware.

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

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.