Vehicle data transmission control method and system and control equipment
By using data collection commands and signal list data issued by the cloud platform, combined with a shared memory area and a dual-layer storage area, precise data transmission between vehicles and the cloud is achieved, solving the problems of poor flexibility, high cost, and data loss, and improving the efficiency and reliability of data transmission.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHERY AUTOMOBILE CO LTD
- Filing Date
- 2026-02-03
- Publication Date
- 2026-05-01
AI Technical Summary
In existing technologies, the data interaction between vehicles and the cloud is not flexible, the data transmission cost is high, the cloud is under great pressure, and the vehicle's in-vehicle device has limited storage space, which makes it easy to lose data during the transmission process.
By using data acquisition commands and signal list data issued by the cloud platform, the target vehicle is controlled to transmit data precisely. A lookup table is built using a shared memory area to determine signal attribute data and priority data. Based on this data, a queue is built and a transmission strategy is formulated to achieve precise data transmission. A dual-layer storage area is set up in the control device to reduce the probability of data loss.
It enables flexible definition of business requirements, reduces invalid data transmission, reduces data transmission volume, lowers transmission costs, reduces cloud pressure, and improves data transmission reliability.
Smart Images

Figure CN121967472A_ABST
Abstract
Description
Vehicle data transmission control methods, systems and control equipment Technical Field
[0001] This invention relates to the field of vehicle data interaction control, and in particular to a vehicle data transmission control method, system and control device. Background Technology
[0002] As vehicles become increasingly intelligent, the interaction scenarios between vehicles and the cloud are gradually increasing, involving various data and command interactions such as vehicle control, vehicle positioning, vehicle diagnostics, and fault data reporting. The specific implementation process mainly relies on preset trigger conditions to execute data collection and transmission. When business requirements change, the vehicle's firmware needs to be updated, resulting in poor flexibility. Furthermore, due to the limited storage space of vehicle-mounted devices, data loss is easily caused during data transmission. Therefore, full data collection and transmission are often used in vehicle data transmission, leading to high transmission costs and significant cloud pressure. Summary of the Invention
[0003] In view of this, the purpose of this invention is to provide a vehicle data transmission control method, system, and control device. This method controls the target vehicle to transmit data precisely according to the instructions by using data acquisition commands issued by the cloud platform and combining them with signal list data. This enables flexible definition of business requirements and fundamentally avoids the transmission of invalid data, reducing the amount of data transmission. In addition, this method can set up a dual-layer storage area in the control device to retain key data, reducing the probability of data loss. This solves the problems of poor flexibility, high transmission cost, and high cloud pressure in the existing process of data transmission between vehicles and the cloud platform.
[0004] In a first aspect, embodiments of the present invention provide a vehicle data transmission control method, the method comprising: controlling a target vehicle to receive data acquisition instructions and signal list data sent by a cloud platform; controlling the target vehicle to acquire raw data at the vehicle end via the data acquisition instructions, and constructing a lookup table corresponding to the raw data at the vehicle end using a shared memory area corresponding to the control device in the target vehicle; determining the corresponding signal attribute data in the lookup table via an identifier corresponding to the raw data at the vehicle end, and determining the signal physical value, time data, and priority data corresponding to the raw data at the vehicle end using the signal attribute data and the signal list data; constructing queue data corresponding to the raw data at the vehicle end based on the signal physical value, and determining the transmission strategy corresponding to the queue data via the time data and priority data; and controlling the target vehicle to transmit the queue data to the cloud platform according to the transmission strategy.
[0005] Optionally, the steps of controlling the target vehicle to receive data acquisition instructions and signal list data sent by the cloud platform include: obtaining the data interaction server corresponding to the target vehicle, and determining the cloud platform corresponding to the data interaction server through the cloud data transmission interface corresponding to the target vehicle; obtaining the signal identifier, signal name, reporting frequency, and priority parameters corresponding to the target vehicle through the time-series database of the cloud platform; generating data acquisition instructions corresponding to the target vehicle based on the signal identifier, and constructing the signal list data corresponding to the target vehicle using the signal identifier, signal name, reporting frequency, and priority parameters; controlling the first control device of the target vehicle to receive the data acquisition instructions sent by the cloud platform using an asynchronous communication protocol, and controlling the second control device of the target vehicle to receive the signal list data sent by the cloud platform; wherein, the first control device and the second control device interact with each other through a shared memory area.
[0006] Optionally, the steps of controlling the target vehicle to collect raw vehicle-side data via data acquisition commands and constructing a lookup table corresponding to the raw vehicle-side data using the shared memory area corresponding to the control device in the target vehicle include: determining the target bus corresponding to the data acquisition command based on the vehicle network information of the target vehicle, and determining the shared memory area between the first control device and the second control device; controlling the first control device to collect the bus message corresponding to the target vehicle from the target bus via the data acquisition command, and determining the raw vehicle-side data corresponding to the target vehicle based on the bus message; controlling the first control device to transmit the raw vehicle-side data to the second control device using the shared memory area; controlling the second control device to initialize the table entry array corresponding to the raw vehicle-side data according to the extreme value of the signal data corresponding to the target bus; obtaining the message identifier corresponding to the bus message, and updating the table entry array using the signal start bit, signal bit length, signal data type, scaling factor, offset, and reporting timestamp corresponding to the message identifier in the raw vehicle-side data; and constructing a lookup table corresponding to the raw vehicle-side data based on the table entry array.
[0007] Optionally, the steps of determining the corresponding signal attribute data in the query table based on the identifier corresponding to the vehicle-side raw data, and determining the signal physical value, time data, and priority data corresponding to the vehicle-side raw data using the signal attribute data and signal list data, include: determining the identifier corresponding to the vehicle-side raw data based on the message identifier, and obtaining the identifier list corresponding to the signal identifier in the signal list data; if the identifier list contains identifiers, obtaining the signal attribute data corresponding to the identifiers in the query table; wherein, the signal attribute data includes at least: signal start bit, signal bit length, signal data type, scaling factor, offset, and reporting timestamp; determining the data extraction strategy corresponding to the vehicle-side raw data using the signal start bit, signal bit length, and signal data type, and extracting the original signal value corresponding to the target vehicle from the vehicle-side raw data using the data extraction strategy; determining the data conversion strategy corresponding to the vehicle-side raw data using the scaling factor and offset, and converting the original signal value into the signal physical value corresponding to the vehicle-side raw data using the data conversion strategy; obtaining the system time value corresponding to the target vehicle, and determining the time data corresponding to the vehicle-side raw data using the system time value and the reporting timestamp; and determining the priority data corresponding to the vehicle-side raw data using the priority corresponding to the identifier in the signal list data.
[0008] Optionally, the steps of constructing queue data corresponding to the vehicle-side raw data based on signal physical values and determining the transmission strategy corresponding to the queue data through time data and priority data include: determining data tuples corresponding to the vehicle-side raw data using signal physical values, time data, and priority data, and constructing queue data corresponding to the vehicle-side raw data using data tuples; determining the data scheduling strategy corresponding to the queue data using the time difference between the system time value and the reporting timestamp in the time data; determining the data reporting strategy corresponding to the vehicle-side raw data using the priority classification value corresponding to the priority data; and determining the transmission strategy corresponding to the queue data based on the data scheduling strategy and the data reporting strategy.
[0009] Optionally, the step of determining the data reporting strategy corresponding to the vehicle-side raw data using the priority classification value corresponding to the priority data includes: obtaining the first priority classification value, the second priority classification value, and the third priority classification value corresponding to the priority data, and obtaining the total data traffic threshold, mode switching duration, first traffic consumption ratio threshold, and second traffic consumption ratio threshold corresponding to the target vehicle based on the signal identifier; wherein, the first priority classification value is less than the second priority classification value, the second priority classification value is less than the third priority classification value, and the first traffic consumption ratio threshold is less than the second traffic consumption ratio threshold; determining the first vehicle-side data, the second vehicle-side data, and the third vehicle-side data corresponding to the vehicle-side raw data based on the first priority classification value, the second priority classification value, and the third priority classification value respectively; obtaining the real-time data traffic value corresponding to the control device, and obtaining the first reporting frequency, the second reporting frequency, and the third reporting frequency corresponding to the third vehicle-side data respectively using the signal list data; wherein, the first reporting frequency is greater than the second reporting frequency and the third reporting frequency is greater than the second reporting frequency and the third reporting frequency is greater than the third reporting frequency. The reporting frequency is as follows: The traffic consumption ratio for the target vehicle is determined by the ratio of the real-time data traffic value to the total data traffic threshold. If the traffic consumption ratio threshold is less than the first traffic consumption ratio threshold, the first, second, and third reporting frequencies are used to determine the first data reporting strategy for the first, second, and third vehicle-side data. If the traffic consumption ratio threshold is not less than the first and is less than the second traffic consumption ratio threshold, the product of the second reporting frequency and a preset ratio value is obtained, and the first reporting frequency and the product result are used to determine the second data reporting strategy for the first and second vehicle-side data. The preset ratio value is less than 1. If the traffic consumption ratio threshold is not less than the second traffic consumption ratio threshold, the summary data corresponding to the second vehicle-side data within a preset aggregation time is obtained, and the first reporting frequency and aggregation time are used to determine the third data reporting strategy for the first vehicle-side data and the summary data. The summary data includes the extreme value data, average value data, and timestamp data corresponding to the second vehicle-side data within the aggregation time.
[0010] Optionally, the step of controlling the target vehicle to transmit queue data to the cloud platform according to the transmission strategy includes: obtaining a first storage area and a second storage area contained in the control device; wherein, the first storage space corresponding to the first storage area is larger than the second storage space corresponding to the second storage area, and the first data priority corresponding to the first storage area is greater than the second data priority corresponding to the second storage area; after saving the vehicle-side raw data to the first data block corresponding to the first storage area, using the priority data to obtain the second data block corresponding to the first data block in the second storage area, and saving the queue data to the second data block; and using the transmission strategy to control the transmission of the vehicle-side raw data in the first data block and the queue data in the second data block to the cloud platform.
[0011] Optionally, the step of controlling the transmission of vehicle-side raw data in the first data block and queue data in the second data block to the cloud platform using transmission strategies includes: when the target vehicle is detected to be in a turned-off state, and the network connection time of the control device exceeds a preset network connection time threshold, and the power battery charge of the target vehicle is greater than a preset first remaining power threshold, and the data retention time corresponding to the priority data in the first storage area is less than a preset start-up time threshold, respectively, acquiring the first transmission strategy, the second transmission strategy, and the third transmission strategy corresponding to the first priority classification value, the second priority classification value, and the third priority classification value; acquiring the historical data corresponding to the queue data in the second data block, and controlling the target vehicle to transmit the historical data and queue data to the cloud platform using the first transmission strategy; acquiring the first vehicle-side raw data corresponding to the second priority classification value in the first data block, determining the first data to be covered contained in the first vehicle-side raw data, and controlling the target vehicle to transmit the first data to be covered to the cloud platform using the second transmission strategy; if the power battery charge of the target vehicle is greater than a preset second remaining power threshold, acquiring the second vehicle-side raw data corresponding to the third priority classification value in the first data block, and controlling the target vehicle to transmit the second vehicle-side raw data to the cloud platform using the third transmission strategy.
[0012] Secondly, the present invention provides a vehicle data transmission control system, comprising: a data and instruction sending module for controlling a target vehicle to receive data acquisition instructions and signal list data sent by a cloud platform; a data acquisition and construction module for controlling the target vehicle to acquire raw data from the vehicle end through data acquisition instructions, and constructing a lookup table corresponding to the raw data from the vehicle end using the shared memory area corresponding to the control device in the target vehicle; a data query and analysis module for determining the corresponding signal attribute data in the lookup table through the identifier corresponding to the raw data from the vehicle end, and determining the signal physical value, time data, and priority data corresponding to the raw data from the vehicle end using the signal attribute data and the signal list data; a queue data and transmission strategy determination module for constructing queue data corresponding to the raw data from the vehicle end based on the signal physical value, and determining the transmission strategy corresponding to the queue data through the time data and priority data; and a queue data transmission execution module for controlling the target vehicle to transmit the queue data to the cloud platform according to the transmission strategy.
[0013] Thirdly, embodiments of the present invention also provide a control device, which includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of the vehicle data transmission control method provided in the first aspect.
[0014] This invention provides a vehicle data transmission control method, system, and control device. During data transmission between a target vehicle and a cloud platform, the method first controls the target vehicle to collect raw data from the vehicle using the data collection command and signal list data sent by the cloud platform. A lookup table corresponding to the raw data is constructed using the shared memory area of the control device in the target vehicle. Then, the corresponding signal attribute data in the lookup table is determined using the identifier of the raw data. The signal attribute data and signal list data are used to determine the signal physical value, time data, and priority data corresponding to the raw data. Next, queue data corresponding to the raw data is constructed based on the signal physical value, and a transmission strategy corresponding to the queue data is determined using the time data and priority data. Finally, the target vehicle is controlled to transmit the queue data to the cloud platform according to the transmission strategy. This method controls the target vehicle to transmit data precisely according to the instructions by issuing data acquisition commands from the cloud platform and combining them with signal list data. This enables flexible definition of business requirements and fundamentally avoids the transmission of invalid data, reducing the amount of data transmission. In addition, this method can set up a dual-layer storage area in the control device to retain key data, reducing the probability of data loss. This solves the problems of poor flexibility, high transmission cost, and high cloud pressure in the existing process of data transmission between vehicles and the cloud platform.
[0015] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.
[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0018] Figure 1 is a flowchart of a vehicle data transmission control method provided in an embodiment of the present invention; Figure 2 is a flowchart of step S101 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 3 is a flowchart of step S102 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 4 is a flowchart of step S103 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 5 is a flowchart of step S104 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 6 is a flowchart of step S503 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 7 is a flowchart of step S105 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 8 is a flowchart of step S703 in a vehicle data transmission control method provided in an embodiment of the present invention; Figure 9 is a flowchart of a vehicle data transmission control method provided in an embodiment of the present invention; Figure 10 is a schematic diagram of a business data diversion processing flow corresponding to a vehicle data transmission control method provided in an embodiment of the present invention; Figure 11 is a schematic diagram of a dynamic dual-loop storage flow corresponding to a vehicle data transmission control method provided in an embodiment of the present invention; Figure 12 is a structural schematic diagram of a vehicle data transmission control system provided in an embodiment of the present invention; Figure 13 is a structural schematic diagram of a control device provided in an embodiment of the present invention.
[0019] Icons: 100 - Data and instruction sending module; 200 - Data acquisition and construction module; 300 - Data query and analysis module; 400 - Queue data and transmission strategy determination module; 500 - Queue data transmission execution module; 101 - Processor; 102 - Memory; 103 - Bus; 104 - Communication interface. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0021] To facilitate understanding of this embodiment, a vehicle data transmission control method disclosed in this embodiment of the invention will be introduced first. As shown in Figure 1, the method includes: Step S101: Controlling the target vehicle to receive data acquisition instructions and signal list data sent by the cloud platform.
[0022] First, a dedicated cloud management platform for the target vehicle is identified to ensure the targeted and secure transmission of instructions. This cloud platform proactively sends two types of core data to the target vehicle: first, data collection instructions specifying the collection scope and format requirements; and second, a list of signal data indicating the types of signals to be collected, identification rules, and filtering criteria. This provides a basis for subsequent accurate data collection and filtering on the vehicle side, enabling proactive cloud-based control over vehicle-side data collection activities.
[0023] Step S102: Control the target vehicle to collect raw data from the vehicle end through data acquisition instructions, and construct a lookup table corresponding to the raw data from the vehicle end using the shared memory area corresponding to the control device in the target vehicle.
[0024] After receiving instructions from the cloud, the target vehicle activates its on-board sensors, controllers, and other equipment according to the data acquisition commands. It then collects raw data such as engine status, driving parameters, and fault information via the vehicle's relevant data bus. Simultaneously, utilizing a pre-defined shared memory area in the on-board control equipment (offering advantages in efficient read / write and cross-module access), a lookup table corresponding to the raw data is constructed. Key information such as the storage address, identification information, and collection source of the raw data is entered into the table, laying the foundation for rapid data retrieval and matching in the future.
[0025] Step S103: Determine the corresponding signal attribute data in the query table by using the identifier corresponding to the vehicle-side raw data, and use the signal attribute data and signal list data to determine the signal physical value, time data and priority data corresponding to the vehicle-side raw data.
[0026] Using the unique identifier inherent in the vehicle-side raw data as an index, the corresponding signal attribute data is located in the constructed query table. Then, combined with the signal list data distributed from the cloud, the raw data is parsed and processed. Specifically, the raw binary data in the vehicle-side raw data is converted into signal physical values that can be recognized by the business through the signal attribute data. In addition, the timestamp data of the data collection time is extracted through the timestamp in the signal attribute data, and the priority data corresponding to the vehicle-side raw data is obtained by dividing the parameters according to the rules of the signal list.
[0027] Step S104: Construct queue data corresponding to the original data at the vehicle end based on the physical values of the signal, and determine the transmission strategy corresponding to the queue data through time data and priority data.
[0028] Based on the analyzed signal physical values, an ordered queue of data is constructed according to data category, acquisition sequence, and other logical principles to achieve standardized management of data to be transmitted on the vehicle side. Simultaneously, differentiated transmission strategies are formulated by integrating time data and priority data: for example, high-priority data is transmitted first, data of the same priority is transmitted in batches according to timestamp order, or an immediate transmission mechanism is set up for data with high timeliness requirements, while non-urgent data is transmitted using time-division multiplexing to optimize data transmission efficiency.
[0029] Step S105: Control the target vehicle to transmit queue data to the cloud platform according to the transmission strategy.
[0030] According to the established transmission strategy, the vehicle-side control equipment activates the data transmission module, transmitting the data in the queue to the corresponding cloud platform via a vehicle-to-everything (V2X) communication link (such as 5G or automotive-grade WiFi). Data verification is performed simultaneously during transmission to ensure data integrity and accuracy. Upon receiving the data, the cloud platform provides confirmation, forming a closed loop of "distribution-collection-transmission-confirmation," thus completing a precise data transmission process.
[0031] Optionally, step S101, which controls the target vehicle to receive data collection instructions and signal list data sent by the cloud platform, as shown in Figure 2, includes: step S201: obtaining the data interaction server corresponding to the target vehicle, and determining the cloud platform corresponding to the data interaction server through the cloud data transmission interface corresponding to the target vehicle.
[0032] First, a data interaction server that establishes a stable communication link with the target vehicle is acquired. This server serves as the core relay node for data interaction between the vehicle and the cloud. Then, relying on the target vehicle's pre-configured dedicated cloud data transmission interface, the cloud platform to which the data interaction server belongs is accurately located through interface protocol verification and vehicle identity information matching. This ensures that subsequent commands and data are transmitted only between the target vehicle and the corresponding dedicated cloud platform, guaranteeing the security and specificity of the interaction.
[0033] Step S202: Obtain the signal identifier, signal name, reporting frequency, and priority parameters corresponding to the target vehicle through the time-series database of the cloud platform.
[0034] The cloud platform utilizes its built-in time-series database to extract core signal parameters corresponding to the target vehicle based on its unique identifier (such as VIN or device number). These parameters include signal identifiers (used to uniquely distinguish various vehicle-side signals), signal names (describing the corresponding vehicle functional module, such as engine speed signal or brake status signal), preset reporting frequency, and signal priority parameters. This provides foundational data support for subsequent instruction generation and inventory construction. The time-series database is specifically designed for storing time-series vehicle operation data, offering advantages such as efficient querying and time-based retrieval.
[0035] Step S203: Generate data acquisition instructions corresponding to the target vehicle based on the signal identifier, and construct the signal list data corresponding to the target vehicle using the signal identifier, signal name, reporting frequency and priority parameters.
[0036] Based on the extracted signal identifiers and combined with the collection scope and format requirements corresponding to business needs, a data collection instruction specific to the target vehicle is generated, clearly informing the vehicle of the range of raw data to be collected. Simultaneously, the signal identifiers, signal names, reporting frequencies, and priority parameters are structurally integrated to construct a standardized signal list data, clearly defining the rules for data parsing and filtering on the vehicle side, ensuring that the vehicle can accurately process the raw data according to the list. For example, the signal list data can adopt a lightweight structured data format (such as JSON), whose data structure clearly specifies the signal identifier (such as CAN ID), signal name, reporting frequency, and priority parameters (P0 / P1 / P2, where P0 has higher priority than P1, and P1 has higher priority than P2) of the signals to be monitored.
[0037] Step S204: Using an asynchronous communication protocol, the first control device of the target vehicle receives the data acquisition command sent by the cloud platform, and the second control device of the target vehicle receives the signal list data sent by the cloud platform; wherein, the first control device and the second control device interact with each other through a shared memory area.
[0038] Signal list data can be transmitted using an asynchronous communication protocol, avoiding link congestion issues caused by synchronous transmission and improving command issuance efficiency and stability. Specifically, the cloud control platform sends data acquisition commands to the first control device of the target vehicle and simultaneously sends the constructed signal list data to the second control device of the vehicle. The first control device is responsible for performing the data acquisition operation, while the second control device is responsible for data parsing and filtering. The two devices achieve high-speed data interaction through a pre-defined shared memory area on the vehicle, eliminating the need for external links and reducing data interaction latency and the risk of data loss.
[0039] Optionally, step S102, which controls the target vehicle to collect raw data from the vehicle end through a data acquisition command and constructs a lookup table corresponding to the raw data from the vehicle end using the shared memory area corresponding to the control device in the target vehicle, as shown in Figure 3, includes: step S301: determining the target bus corresponding to the data acquisition command based on the vehicle network information of the target vehicle, and determining the shared memory area between the first control device and the second control device.
[0040] First, the vehicle network information of the target vehicle (including bus type, communication protocol, device mounting relationships, etc.) is analyzed. Based on the data acquisition object specified in the data acquisition command, the corresponding target bus (such as CAN bus, LIN bus, corresponding to different vehicle control module data transmission channels) is accurately matched. At the same time, the pre-planned shared memory area between the first control device and the second control device is located. This area is a dedicated data interaction space for the two devices and can be implemented using Direct Memory Access (DMA) technology, which has the characteristics of low latency and high read / write efficiency, providing hardware support for subsequent rapid data transmission.
[0041] Step S302: After controlling the first control device to collect the bus message corresponding to the target vehicle from the target bus through the data acquisition command, determine the original vehicle-side data corresponding to the target vehicle based on the bus message.
[0042] After receiving and parsing the data acquisition command, the first control device starts the bus data acquisition module to capture bus messages (including binary raw data transmitted by various sensors and controllers) generated during the operation of the target vehicle in real time from the target bus. Subsequently, the bus messages are initially filtered to remove invalid interference messages, extract valid messages that match the acquisition command, and then parse to obtain the raw data from the vehicle end, covering core information such as vehicle operating status and component parameters.
[0043] Step S303: Use the shared memory area to control the first control device to transmit the vehicle-side raw data to the second control device.
[0044] Based on the established shared memory area, the first control device writes the extracted raw data from the vehicle into this area according to a preset format, completing the data upload. The second control device synchronously reads the raw data through the real-time monitoring mechanism of the shared memory, without needing to go through the external communication link of the vehicle, effectively reducing data transmission latency and avoiding data loss during transmission, thus ensuring the integrity of the raw data.
[0045] Step S304: Based on the extreme values of the signal data corresponding to the target bus, the second control device initializes the table array corresponding to the original data on the vehicle side.
[0046] The second control device first acquires the extreme values of the signal data corresponding to the target bus (including the maximum and minimum threshold values of each type of signal, preset by the vehicle factory or dynamically configured in the cloud). Combining this with the number and type of signals in the original data, it initializes the corresponding array of entries. The array's length and storage dimensions are adapted to the range of signal extreme values and the scale of the original data, ensuring no overflow in subsequent data storage and laying the foundation for structured data management. Specifically, the lookup table is a fixed-size array, its size determined by the maximum possible number of vehicle bus signals, with a certain number of entries to ensure coverage of all possible message identifiers.
[0047] Step S305: Obtain the message identifier corresponding to the bus message, and update the table entry array using the signal start bit, signal bit length, signal data type, scaling factor, offset and reporting timestamp corresponding to the message identifier in the vehicle end original data.
[0048] Extract the unique message identifier corresponding to the bus message, and use it as an index to associate key attribute information in the vehicle-side raw data, including the signal start bit (identifying the starting position of the signal in the message), signal bit length (defining the number of bits occupied by the signal data), signal data type (such as integer or floating-point), scaling factor and offset (used for subsequent physical value conversion), and reporting timestamp (recording the data acquisition time). Fill this information one by one into the initialized table entry array to complete the structured data content of the array.
[0049] Step S306: Construct a query table corresponding to the original data from the vehicle end based on the array of table entries.
[0050] The populated array of entries is structured and indexed according to dimensions such as message identifier and signal type to construct a lookup table corresponding to the original data from the vehicle. This lookup table enables rapid retrieval, attribute matching, and subsequent updates of the original data, facilitating efficient location and parsing of target signals by the second control device in conjunction with the signal list data, thereby improving overall data processing efficiency. This direct addressing mechanism based on array indexes has a constant time complexity of O(1), independent of the number of signals in the signal list data. On mainstream vehicle control devices, a single lookup takes less than 1 microsecond, meeting the high real-time requirements of vehicle-side processing.
[0051] Optionally, step S103, which involves determining the corresponding signal attribute data in the query table by using the identifier corresponding to the original data at the vehicle end, and determining the signal physical value, time data, and priority data corresponding to the original data at the vehicle end using the signal attribute data and the signal list data, as shown in Figure 4, includes: Step S401: Determine the identifier corresponding to the original data at the vehicle end based on the message identifier, and obtain the identifier list corresponding to the signal identifier in the signal list data.
[0052] First, using the message identifier corresponding to the original data from the vehicle as the core mapping basis, a globally unique signal identifier corresponding to that original data is determined (achieving unified alignment between vehicle-side data and cloud-based signal definitions, avoiding cross-end data identifier confusion). Then, from the signal list data already received and stored by the second control device, a cloud-preset list of signal identifiers is extracted. This list contains all valid signal identifiers that the cloud needs to collect, analyze, and process, providing a clear judgment criterion for subsequent filtering of valid vehicle-side data and elimination of invalid and redundant data.
[0053] Step S402: If the identifier list contains identifiers, then obtain the signal attribute data corresponding to the identifiers in the query table; wherein, the signal attribute data includes at least: signal start bit, signal bit length, signal data type, scaling factor, offset, and reporting timestamp.
[0054] The signal identifiers in the raw data from the vehicle are compared and verified one by one with the identifiers in the signal list. If the identifier exists in the list, it indicates that the data is valid business data required by the cloud, and the query table retrieval process is triggered. Since the query table is constructed by structuring the populated array of entries, it has established dedicated index relationships according to dimensions such as message identifier and signal type. It possesses characteristics such as fast raw data retrieval, accurate attribute matching, and convenient subsequent updates, which can significantly improve the data processing efficiency of the second control device. Based on the efficient indexing capability of this query table, the complete signal attribute data corresponding to the identifier can be quickly extracted, including at least: signal start bit, signal bit length, signal data type, scaling factor, offset, and reporting timestamp. These parameters provide key technical support for subsequent data extraction and conversion.
[0055] Step S403: Determine the data extraction strategy corresponding to the original data at the vehicle end using the signal start bit, signal bit length, and signal data type, and extract the original signal value corresponding to the target vehicle from the original data at the vehicle end using the data extraction strategy.
[0056] Based on the signal start bit, signal bit length, and signal data type obtained from the lookup table, a targeted standardized data extraction strategy is formulated. Specifically, the signal start bit is used to accurately locate the starting storage position of the target signal in the bus message; the signal bit length is used to define the range of bits and bytes occupied by the target signal data; and the signal data type (such as integer, floating-point, or Boolean) is used to standardize the format of the extracted data, avoiding type confusion or data overflow issues. Subsequently, following this data extraction strategy, the original signal values that have not undergone calibration and conversion are accurately extracted from the binary messages of the original data from the vehicle end, while irrelevant and redundant interference data is removed to ensure the accuracy and purity of the original signal values.
[0057] Step S404: Determine the data conversion strategy corresponding to the original data at the vehicle end using the scaling factor and offset, and convert the original signal value into the physical signal value corresponding to the original data at the vehicle end using the data conversion strategy.
[0058] By utilizing the scaling factor and offset in the signal attribute data, a standardized data conversion strategy is formulated. These two parameters are the core key to converting the raw binary signal value into a physical value with practical business significance. The scaling factor is used to calibrate data accuracy and correct the proportional deviation of the signal during acquisition and transmission, while the offset is used to correct the inherent system errors of the on-board equipment. Through relevant conversion formulas (e.g., signal physical value = raw signal value × scaling factor + offset), the extracted raw signal value is converted into a signal physical value that can be directly interpreted in the cloud and has practical business value. For example, binary values are converted into intuitive and easy-to-understand business data such as engine speed (rpm), tire pressure (kPa), and vehicle speed (km / h).
[0059] Step S405: Obtain the system time value corresponding to the target vehicle, and determine the time data corresponding to the original data on the vehicle end by using the system time value and the reported timestamp.
[0060] The system time value is obtained through the target vehicle's onboard system (possessing a unified absolute time identifier to ensure data time reference consistency across vehicles, time periods, and cloud environments). Simultaneously, the reporting timestamp is extracted from the signal attribute data (this timestamp is the vehicle's local relative time at the moment of data acquisition, accurately recording the instantaneous moment of data generation). The system time value and the reporting timestamp are then correlated to obtain the final time data. This provides a reliable time basis for subsequent cloud-based data generation tracking, time-series data analysis, and troubleshooting of vehicle fault timelines.
[0061] Step S406: Determine the priority data corresponding to the original data at the vehicle end by using the priority corresponding to the identifier in the signal list data.
[0062] The system retrieves signal list data from the cloud and uses the signal identifier corresponding to the original data from the vehicle as a unique index to find the priority parameter pre-configured for that signal in the signal list. This priority parameter is uniformly set by the cloud based on the urgency of the business and the importance of the data (e.g., vehicle emergency fault alarm signal priority P0 > vehicle positioning signal priority P1 > normal driving status signal priority P2). Without requiring additional complex calculations on the vehicle side, this priority parameter is directly determined as the priority data corresponding to the original data from the vehicle side, providing a core basis for subsequent development of differentiated data transmission strategies and ensuring the priority transmission of core emergency data.
[0063] Optionally, step S104, which involves constructing queue data corresponding to the vehicle-side original data based on signal physical values and determining the transmission strategy corresponding to the queue data through time data and priority data, as shown in Figure 5, includes: Step S501: Determining the data tuples corresponding to the vehicle-side original data using signal physical values, time data, and priority data, and constructing queue data corresponding to the vehicle-side original data through the data tuples.
[0064] First, the signal physical values, precise time data, and priority data are structured and encapsulated, and a unique identifier corresponding to the original data from the vehicle can be attached, forming a complete and traceable data tuple. This encapsulation method ensures that the data correlation is not lost, facilitating one-stop parsing and verification after cloud reception. Subsequently, the second control device integrates all valid data tuples in an orderly manner according to preset rules (such as initial sorting by priority, followed by timestamp-assisted sorting), constructing the queue data corresponding to the original data from the vehicle. This queue can adopt the basic first-in-first-out (FIFO) storage logic, while reserving a priority queue-jumping scheduling interface, ensuring orderly data storage and providing flexible support for subsequent differentiated transmission.
[0065] Step S502: Determine the data scheduling strategy corresponding to the queue data by the time difference between the system time value and the reported timestamp in the time data.
[0066] First, the time difference between the system time value and the reporting timestamp in the time data is calculated. This difference directly reflects the time elapsed between the completion of data collection and the transmission of the raw data from the vehicle end, and is a core indicator for judging data timeliness. Subsequently, the data scheduling strategy corresponding to the queue data is determined based on this time difference: for example, if the time difference exceeds a preset upper limit for a tuple, the reporting frequency requirement is met, and the reporting timestamp can be updated to the system time value.
[0067] Step S503: Determine the data reporting strategy corresponding to the original data on the vehicle using the priority classification value corresponding to the priority data.
[0068] First, the priority classification values corresponding to the priority data are analyzed (these classification values are preset by the cloud and are usually divided into three levels: high, medium, and low, or more detailed numerical classifications, such as levels 1-5). Different classification values correspond to different levels of business urgency and data importance. Then, based on these priority classification values, the data reporting strategy corresponding to the raw data from the vehicle is determined: for example, high-priority classification values (such as emergency fault alarm data) adopt a strategy of immediate reporting, dedicated communication links, and multiple verifications to ensure that data is transmitted to the cloud quickly and without loss; medium-priority classification values (such as vehicle location and real-time driving data) adopt a strategy of batch aggregation, scheduled reporting, and link reuse to balance transmission efficiency and resource consumption; low-priority classification values (such as routine equipment status and non-critical operating parameters) adopt a strategy of idle-time reporting, aggregation compression, and fault-tolerant transmission to complete the transmission during idle periods of the communication link, avoiding the occupation of core business transmission resources.
[0069] Step S504: Determine the transmission strategy corresponding to the queue data based on the data scheduling strategy and the data reporting strategy.
[0070] The second control device deeply integrates and optimizes the data scheduling strategy (determining how to transmit) and the data reporting strategy (determining when and to whom to transmit), forming the final transmission strategy corresponding to the queued data. Specifically, it is guided by the data reporting strategy and follows the execution order of the data scheduling strategy, while also taking into account real-time information such as the vehicle-side communication link status and cloud-based load feedback, dynamically adjusting transmission details. For example, high-priority data is prioritized for scheduling and immediate reporting, unrestricted by the conventional queue order; medium- and low-priority data are scheduled and sorted according to time differences, and then executed according to the corresponding batch / idle-time reporting strategy; a fallback mechanism is also set up: if the link is abnormal, high-priority data is temporarily stored in a dual-layer storage area and retransmitted first after the link is restored. The final transmission strategy ensures both the priority and integrity of core data transmission and the optimal allocation of transmission resources, laying the foundation for efficient data transmission from the vehicle to the cloud in the future.
[0071] Optionally, step S503, which uses the priority classification value corresponding to the priority data to determine the data reporting strategy corresponding to the original data on the vehicle, as shown in Figure 6, includes: step S601: obtaining the first priority classification value, the second priority classification value, and the third priority classification value corresponding to the priority data, and obtaining the total data traffic threshold, mode switching duration, first traffic consumption ratio threshold, and second traffic consumption ratio threshold corresponding to the target vehicle according to the signal identifier.
[0072] First, from the priority data of the vehicle-side raw data, a preset three-level priority classification value is extracted: the first priority classification value P0, the second priority classification value P1, and the third priority classification value P2. The order of these three values corresponds to a decreasing level of business importance and urgency of the vehicle-side data. Then, using the signal identifier as the core index, the traffic control configuration parameters of the target vehicle are quickly retrieved based on the aforementioned query table. Simultaneously, parameter verification is performed using signal list data. Finally, key parameters are obtained, including: the total data traffic threshold B_total (the maximum communication traffic that the vehicle can consume within a single time period), the mode switching duration (the buffer time for switching traffic policies to avoid frequent switching affecting stability), the first traffic consumption ratio threshold (e.g., 70%), and the second traffic consumption ratio threshold (90%). The structured indexing capability of the query table significantly reduces parameter retrieval time, ensuring efficient data acquisition in the early stages of policy formulation.
[0073] Step S602: Determine the first vehicle-end data, second vehicle-end data, and third vehicle-end data corresponding to the original vehicle-end data based on the first priority classification value, the second priority classification value, and the third priority classification value, respectively.
[0074] Based on the extracted three-level priority classification values, the parsed raw vehicle-side data is accurately batch-classified, clearly defining the data object division: data matching the first priority classification value P0 is classified as first-level vehicle-side data, and data matching P1 and P2 are classified as second-level and third-level vehicle-side data, respectively. During the classification process, the index relationship established by the lookup table based on message identifier and signal type allows for rapid association between data and priority classification values, eliminating the need for item-by-item verification and significantly improving classification efficiency. From a business perspective, this classification directly corresponds to the data priority gradient, providing a clear processing object for the subsequent implementation of differentiated reporting strategies.
[0075] Step S603: Obtain the real-time data flow value corresponding to the control device, and use the signal list data to obtain the first reporting frequency corresponding to the first vehicle-end data, the second reporting frequency corresponding to the second vehicle-end data, and the third reporting frequency corresponding to the third vehicle-end data respectively; wherein, the first reporting frequency is greater than the second reporting frequency and the third reporting frequency.
[0076] On one hand, the communication link status of the vehicle-side control equipment is monitored in real time, and the real-time data traffic value B_used for the current period is dynamically collected. B_used accurately reflects the current traffic consumption progress and load status of the link. On the other hand, signal list data is retrieved, and relying on the attribute matching function of the lookup table, the corresponding preset reporting frequencies are extracted according to the three categories of data: the first vehicle-side data corresponds to the first reporting frequency, and the second and third vehicle-side data correspond to the second and third reporting frequencies, respectively. The core rule is that the first reporting frequency is higher than the second and third reporting frequencies. This setting aims to ensure that the most important first vehicle-side data (such as emergency fault alarms) can be reported at a higher frequency, ensuring that the cloud can monitor the core status of the vehicle in real time. In this process, the lookup table provides efficient support for the accurate matching of frequency and data type.
[0077] Step S604: Determine the traffic consumption ratio of the target vehicle by the ratio of the real-time data traffic value to the total data traffic threshold.
[0078] The real-time data traffic value B_used is compared with the preset total data traffic threshold B_total to obtain the traffic consumption ratio R = B_used / B_total (range 0-1). This value serves as the core indicator for quantifying the link traffic load level: the closer the value is to 1, the closer the traffic consumption is to the upper limit, and the heavier the link load. This quantification transforms abstract traffic usage into a clear judgment criterion, avoiding subjective decisions in policy switching and improving the scientific nature and stability of the reporting strategy.
[0079] Step S605: If the traffic consumption ratio threshold is less than the first traffic consumption ratio threshold, then the first data reporting strategy corresponding to the first vehicle data, the second vehicle data and the third vehicle data is determined using the first reporting frequency, the second reporting frequency and the third reporting frequency.
[0080] Comparing the traffic consumption ratio with the first traffic consumption ratio threshold of 70%, if the traffic consumption ratio is less than 70%, it indicates that the current link traffic load is low, in an idle or lightly used state, and has the resource conditions for full data transmission. In this case, the preset first, second, and third reporting frequencies are directly used to perform full and regular reporting of the three types of vehicle-side data, without adjusting the frequency or compressing the data. This strategy, when traffic resources are sufficient, satisfies the cloud's complete data collection needs for various types without requiring additional vehicle-side computing power to process the data. The lookup table can help quickly verify the correspondence between reporting frequencies and data identifiers, ensuring accurate implementation of the strategy.
[0081] Step S606: If the traffic consumption ratio threshold is not less than the first traffic consumption ratio threshold and less than the second traffic consumption ratio threshold, then obtain the product of the second reporting frequency and the preset ratio value, and use the first reporting frequency and the product result to determine the second data reporting strategy corresponding to the first vehicle-end data and the second vehicle-end data; wherein, the preset ratio value is less than 1.
[0082] If the traffic consumption ratio is greater than or equal to 70% (first traffic consumption ratio threshold) and less than 90% (second traffic consumption ratio threshold), it indicates that the link traffic load is at a moderate level, and traffic consumption needs to be controlled while ensuring core data transmission. In this case, a differentiated adjustment strategy is adopted: priority is given to ensuring the reporting frequency of the first vehicle-end data, which continues to operate at the first reporting frequency; for the second vehicle-end data, the product of its second reporting frequency and a preset ratio (a value less than 1, such as 0.5, preset according to the business timeliness tolerance) is calculated, and this product result is used as the new reporting frequency, reducing its reporting frequency to decrease traffic consumption; regular reporting of the third vehicle-end data is suspended, and will be resumed after the traffic load decreases. This strategy balances core data requirements and link load pressure, and the lookup table can help verify the compatibility between the new reporting frequency and data attributes.
[0083] Step S607: If the traffic consumption ratio threshold is not less than the second traffic consumption ratio threshold, then obtain the summary data corresponding to the second vehicle-end data within the preset aggregation time, and determine the third data reporting strategy corresponding to the first vehicle-end data and the summary data using the first reporting frequency and the aggregation time; wherein, the summary data includes the extreme value data, average value data and timestamp data corresponding to the second vehicle-end data within the aggregation time.
[0084] If the traffic consumption ratio is greater than or equal to 90%, it indicates a high link traffic load, requiring maximum compression of non-core data traffic to prioritize the smooth operation of core channels. The strategy adjustment at this point is as follows: First-vehicle data is still reported in its entirety at the first reporting frequency to ensure uninterrupted core emergency information; for second-vehicle data, the full original data is no longer transmitted, but instead, summary data within a preset aggregation time is extracted (including extreme value data, average data, and key timestamp data within that time period, significantly compressing data volume while retaining core business information); third-vehicle data reporting remains suspended. Subsequently, combining the first reporting frequency and aggregation time, collaborative reporting rules are formulated (such as batch reporting summary data along with first-vehicle data), forming the third data reporting strategy. During this process, the lookup table can quickly extract the original attributes of the second-vehicle data, providing data support for the efficient generation of summary data.
[0085] Optionally, step S105, which controls the target vehicle to transmit queue data to the cloud platform according to the transmission strategy, as shown in Figure 7, includes: step S701: obtaining the first storage area and the second storage area contained in the control device; wherein, the first storage space corresponding to the first storage area is greater than the second storage space corresponding to the second storage area, and the first data priority corresponding to the first storage area is greater than the second data priority corresponding to the second storage area.
[0086] First, the storage management module of the vehicle-side control device is invoked to obtain the preset dual-layer storage areas: a first storage area (regular storage area) and a second storage area (protected storage area). These two areas employ differentiated designs to accommodate different data storage needs. Specifically, the first storage area allocates a larger portion of its storage space (e.g., 80%) than the second storage area (e.g., 20%), and the first data in the first storage area has a higher priority than the second data in the second storage area. Functionally, the first storage area serves as the primary storage area for core data, used to retain critical original vehicle-side data, requiring more space to ensure the storage of all core data. The second storage area serves as an auxiliary backup storage area, used to temporarily store data in the transmission queue, with relatively lower space requirements. This dual-layer storage design is the core hardware support for solving data loss problems, ensuring the priority storage and protection of core data through priority-based tiering.
[0087] Step S702: After saving the original data from the vehicle to the first data block corresponding to the first storage area, use the priority data to obtain the second data block corresponding to the first data block in the second storage area, and save the queue data to the second data block.
[0088] First, the parsed raw vehicle-side data (especially the core data) is categorized by identifier and stored in the corresponding first data block of the first storage area. Simultaneously, a lookup table is used to quickly associate data identifiers with data block addresses, ensuring the orderly and traceable storage of raw data. Then, based on priority data and data identifiers, a second data block in the second storage area that establishes a corresponding mapping relationship with the first data block is retrieved (i.e., the raw data and queue data of the same data are stored in corresponding data blocks for easy synchronization and scheduling). The structured queue data (including signal physical values, time, and priority information) is then saved to this second data block. This process achieves bidirectional backup of raw data and queue data to be transmitted. The first storage area ensures no loss of raw data, the second storage area supports flexible execution of transmission strategies, and the lookup table improves the efficiency of data block association mapping.
[0089] Step S703: Use the transmission strategy to control the transmission of the vehicle-side raw data in the first data block and the queue data in the second data block to the cloud platform.
[0090] Based on an integrated transmission strategy (including rules for priority scheduling, traffic adaptation, and reporting frequency), the communication module of the vehicle-side control device initiates the data transmission process: On one hand, it prioritizes retrieving the original vehicle-side data from the first data block of the first storage area and pushes it to the cloud according to the high-priority data transmission rules in the strategy, ensuring the integrity and real-time performance of the core original data; on the other hand, it synchronously schedules the queue data in the second data block of the second storage area, and transmits it in conjunction with the original data, taking into account traffic load and reporting strategies (such as attaching a second vehicle-side data summary when under high load). During transmission, the data transmission status is checked in real time. If an anomaly such as link interruption occurs, transmission can be retried from either storage area based on the data backup of the two-layer storage area, further reducing the probability of data loss and ultimately achieving secure and efficient closed-loop transmission of vehicle-side data to the cloud platform.
[0091] Optionally, step S703, which uses a transmission strategy to control the transmission of the vehicle-side raw data in the first data block and the queue data in the second data block to the cloud platform, as shown in Figure 8, includes: Step S801: When it is detected that the target vehicle is in a turned-off state, and the network connection time of the control device exceeds a preset network connection time threshold, and the power battery charge of the target vehicle is greater than a preset first remaining power threshold, and the data retention time corresponding to the priority data in the first storage area is less than a preset start-up time threshold, the first transmission strategy, the second transmission strategy, and the third transmission strategy corresponding to the first priority classification value, the second priority classification value, and the third priority classification value are obtained respectively.
[0092] First, the target vehicle's status and equipment parameters are verified from multiple dimensions. Only when all conditions are met is a targeted, tiered transmission process initiated: 1) The target vehicle is detected to be in a powered-off state (non-driving condition, no real-time control data requirement, suitable for batch transmission of existing data); 2) The vehicle-side control device's network connection duration exceeds a preset network connection duration threshold (ensuring stable communication links and preventing data transmission interruptions or loss due to network instability); 3) The vehicle's battery charge is higher than a preset first remaining charge threshold (ensuring sufficient power supply during data transmission and preventing transmission interruptions due to insufficient power); 4) The retention time of the data to be transmitted in the first storage area (divided by priority) is less than a preset start-up time threshold (ensuring data timeliness and preventing expired data from occupying transmission resources). Once all the above conditions are met, the previously integrated tiered transmission strategy is invoked to obtain the transmission strategies corresponding to the first priority classification value P0, the second priority classification value P1, and the third priority classification value P2, providing a clear execution basis for the subsequent transmission of data at different levels.
[0093] Step S802: Obtain the historical data corresponding to the queue data in the second data block, and use the first transmission strategy to control the target vehicle to transmit the historical data and queue data to the cloud platform.
[0094] First, historical data corresponding to the queue data in the second data block of the second storage area is retrieved. This historical data consists of existing queue data that was not fully transmitted and is temporarily stored in the auxiliary storage area. Utilizing the identifier index function of the lookup table, historical data and current queue data can be quickly linked, ensuring the continuity and integrity of data transmission. Then, according to the first transmission strategy (high-priority data transmission rules, such as real-time batch reporting and multiple verifications), the target vehicle is controlled to package and collaboratively transmit the historical data and current queue data to the cloud platform. This clears the backlog of existing data and simultaneously transmits the latest data to be transmitted, maximizing the use of stable network connectivity after engine shutdown.
[0095] Step S803: Obtain the first vehicle-side raw data corresponding to the second priority classification value in the first data block, determine the first data to be covered contained in the first vehicle-side raw data, and use the second transmission strategy to control the target vehicle to transmit the first data to be covered to the cloud platform.
[0096] The system retrieves the first vehicle-side raw data (core non-urgent raw data) corresponding to the second priority classification value P1 from the first data block in the first storage area. It then quickly searches the storage status of this type of data using a lookup table, filtering out the first data to be overwritten by new data (to avoid loss of existing core data due to data updates). Subsequently, following the second transmission strategy (medium-priority data transmission rules, such as batch aggregation reporting and link reuse), the system controls the vehicle to transmit the first data to be overwritten to the cloud, optimizing transmission efficiency and balancing resource usage while ensuring no core data loss.
[0097] Step S804: If the power battery charge of the target vehicle is greater than the preset second remaining power threshold, then obtain the second vehicle-side raw data corresponding to the third priority classification value in the first data block, and use the third transmission strategy to control the target vehicle to transmit the second vehicle-side raw data to the cloud platform.
[0098] The system monitors the remaining battery power of the target vehicle in real time. If the remaining battery power exceeds a preset second remaining battery power threshold (the second threshold is higher than the first threshold to ensure sufficient redundant power for transmitting non-core data, so as not to affect the vehicle's power supply for the next start-up), the third priority data transmission process is initiated. The system retrieves the second type of raw vehicle data (non-core routine data, such as ordinary device status parameters) corresponding to the third priority category value P2 from the first storage area. Following the third transmission strategy (low-priority data transmission rules, such as idle-time aggregation reporting and fault-tolerant transmission), the system controls the vehicle to transmit this type of data to the cloud. If the battery power does not reach the second threshold, the third priority data transmission is paused to prioritize ensuring the vehicle's starting power reserve, and the transmission is resumed when the conditions are met later.
[0099] Specifically, as shown in Figure 9, a flowchart of a vehicle data transmission control method is provided. At the physical level, the target vehicle is equipped with a vehicle-side data acquisition module and a vehicle-side data processing module. The vehicle-side data acquisition module can be deployed on a microcontroller, while the vehicle-side data processing module is deployed on a more powerful on-board processing platform. The two interact with each other based on an inter-process communication mechanism with shared memory.
[0100] The cloud platform comprises a policy management unit and a data application unit. The policy management unit is responsible for generating and sending configurable signal list data. This signal list data uses a lightweight structured data format (such as JSON), and its data structure clearly defines the signal identifier (such as CAN ID), signal name, reporting frequency (report_frequency), and priority parameters (P0 / P1 / P2) of the signals to be monitored. The signal list data can be sent to the target vehicle via an asynchronous communication protocol (such as MQTT), thus decoupling business requirements from the vehicle firmware. The data application unit is responsible for receiving, parsing, and storing various types of data reported by the target vehicle into a time-series database for subsequent analysis.
[0101] The core function of the vehicle-side data acquisition module is to strictly adhere to the AUTOSAR (AUTomotive Open System Architecture) BusMirror standard to acquire raw data packets from various vehicle buses (including CAN, LIN, etc.) in a highly reliable and lossless manner. To achieve high throughput and low latency, this module runs in a high-priority task of the microcontroller and employs Direct Memory Access (DMA) technology to directly write the acquired bus data into a physical memory area shared with the vehicle-side data processing module. Its data acquisition rate can support 10,000 CAN messages per second to meet the real-time requirements of high-speed bus data.
[0102] The vehicle-side data processing module integrates a vehicle event detector, a streaming processing core, and a dynamic dual-ring storage pool. The module reads raw vehicle data from the shared memory area using DMA, and ultimately transmits the queued data as real-time data streams and reported data to the cloud platform's data application unit via the streaming processing core and dynamic dual-ring storage pool, respectively, through the aforementioned vehicle data transmission control method.
[0103] The business data diversion and processing flow in the core of the streaming processing is shown in Figure 10. When the streaming processing core of the vehicle-side data processing module receives a complete message from BusMirror, it processes it according to the following steps: Step S1001: Extract the message identifier.
[0104] The streaming processing core first parses the unique identifier (ID) of the message in the bus protocol from the message frame header.
[0105] Step S1002: Query the signal configuration table.
[0106] The streaming processing core uses the identifier extracted in step S1001 as an index key to directly access a static lookup table pre-built in the control device system memory. This lookup table is dynamically built when the target vehicle starts or after receiving an update list from the cloud. The lookup table is implemented as a fixed-size array, the size of which is set according to the maximum possible number of vehicle bus signals to ensure coverage of all possible message IDs. Each entry is a structure containing all the information needed to parse the physical value of the corresponding signal from the message, such as: signal start bit, signal bit length, signal data type (Signed / Unsigned), scaling factor, offset, and last report timestamp for downsampling.
[0107] Step S1003: Determine whether the table entry is valid.
[0108] This step determines the validity of a query entry by checking the valid flag bit in the accessed query table entry. If the flag bit is true (i.e., the CAN ID exists in the signal list data), then step S1004 is executed; otherwise, the process proceeds to step S1006.
[0109] Step S1004: Analyze the physical values of the signal.
[0110] If the entry is valid, the streaming processing core extracts the original signal value from the byte sequence of the vehicle's raw data through a series of bit operations based on the bit field information defined in the entry. Subsequently, the original value is converted into a physical value according to the scaling factor and offset in the entry.
[0111] Step S1005: Determine whether the reporting frequency has been reached.
[0112] First, the current high-precision system time is obtained, and the difference delta_t between it and the last reported timestamp in the table entry is calculated. If delta_t ≥ (1 / report_frequency), the last reported timestamp is updated to the current time, and the data tuple corresponding to <signal ID, physical value, priority> is placed into the corresponding real-time data reporting queue. By adopting a priority-based queue scheduling method, it is ensured that P0 class security data can obtain transmission resources with priority even when the network is congested, and its queue scheduling delay is strictly controlled within 10 milliseconds.
[0113] Step S1006: Write the raw data to the circular storage pool.
[0114] To ensure data integrity and traceability, regardless of whether the message contains signals requiring real-time monitoring, its complete, unprocessed raw data (including timestamps, CAN IDs, data fields, etc.) is synchronously written to a circular storage pool based on memory-mapped file technology. Specifically, a fixed area (e.g., 8GB) of the vehicle-side storage medium can be directly mapped to the process virtual address space of the streaming processing core. This allows data write operations to bypass the kernel buffer, achieving write performance close to direct memory writes, with an average write latency of less than 100 microseconds, meeting the persistence requirements of high-speed bus data. The storage pool internally employs a lock-free circular buffer mechanism to manage read and write pointers, updating pointers through atomic operations.
[0115] The data storage process in the dynamic dual-ring storage pool is shown in Figure 11. The vehicle-side data processing module logically divides the non-volatile storage space in the target vehicle into two independent management areas with different data retention strategies: the regular storage area and the protected storage area.
[0116] Specifically, the regular storage area occupies 80% of the total storage space (e.g., 6.4GB) and is used to record all raw bus data in a circular overwrite manner. Its management follows a first-in, first-out (FIFO) principle; when the storage space is full, the oldest written data block will be overwritten sequentially by the newest data. Data blocks in this area only include timestamp metadata for basic data backtracking.
[0117] The protected storage area reserves 20% of the total storage space (e.g., 1.6GB) and employs an event-driven, high-priority cyclic overwrite strategy. This area is dedicated to storing data deemed high-value by the system. Only when this area is completely full will the oldest data blocks within it be overwritten according to the least recently used principle. Compared to conventional storage areas, data retention time in the protected storage area can be increased by 5 to 10 times, thus solving the problem of critical fault data being easily overwritten.
[0118] Data in the dynamic dual-ring storage pool interacts using a data promotion mechanism. This mechanism is triggered immediately when the vehicle event detector detects a pre-defined high-risk event based on preset logical conditions (e.g., vehicle speed > 100 km / h & brake pedal depressed). Specifically, a time window [t_event - 30s, t_event + 30s] is defined based on the event occurrence time t_event. The physical data blocks corresponding to the regular storage area within this window are logically linked to the protected storage area by creating hard links or remapping metadata. Simultaneously, this data is marked as high priority, and its compression and reporting tasks are scheduled. Furthermore, the cloud platform can also proactively issue commands through a secure channel after digital certificate signature verification to request access to raw data for a specific time period. After verifying the legitimacy of the command, the target vehicle will extract the corresponding data from the storage pool, compress it using the ZSTD algorithm, and then report it.
[0119] To achieve predictable and refined management of data costs during data transmission, a reporting strategy based on cost budget control can be adopted. Specifically, a monthly total data traffic budget B_total (e.g., 1000MB) can be set for each vehicle. By obtaining the real-time data traffic value B_used of the target vehicle, the traffic consumption ratio R = B_used / B_total is calculated. Then, the following three data reporting strategies are determined based on the traffic consumption ratio R: High-fidelity strategy (R<70%): Under this strategy, all P0, P1, and P2 data are reported; P0 data is reported at the highest configured frequency (e.g., 10Hz); P1 / P2 data are reported according to their list-defined frequency.
[0120] Standard strategy (70% ≤ R < 90%): Under this strategy, basic cost control is implemented; P0 data is reported at the normal frequency; the reporting frequency of P1 data is reduced to 50% of the original frequency; and P2 data is suspended from reporting.
[0121] Economic Strategy (R ≥ 90%): Under this strategy, strict cost control is implemented; P0 data continues to be reported normally; P1 data stops reporting detailed time-series data and instead reports its aggregated summary data (aggregation time window is 5 minutes, content includes maximum, minimum, average and timestamp); P2 data is completely suspended from reporting.
[0122] In specific scenarios, the ratio R of B_used to B_total can be calculated daily, such as at 00:00. When the R value crosses the aforementioned preset threshold, the mode is automatically switched. To maintain system stability and prevent frequent mode oscillations due to fluctuations in traffic statistics near the threshold, a minimum time interval (e.g., 2 hours) is set between mode switching.
[0123] In addition, during data transmission, an idle reporting mechanism that coordinates storage and priority can be used. The trigger condition for this mechanism is a complex logical judgment that must be met simultaneously: the vehicle is in an Ignition Off state; the connection to a trusted low-cost network (such as Wi-Fi) has been continuous for more than 60 seconds; the vehicle battery power (such as SOC>60%) is higher than the safety threshold to ensure the next normal start-up; event data to be reported is detected in the protected storage area, or high-priority P1 data in the regular storage area is expected to have a remaining retention time of less than the next start-up time due to storage cycle.
[0124] Once the above conditions are met, the task scheduling process for low-priority data is executed. The primary task is to report all high-value event data in the protected storage area that failed to be reported successfully due to poor historical network conditions. Secondly, the metadata index of the regular storage area is scanned to identify data blocks belonging to P1 priority that are expected to be overwritten in the next hour, for example, due to their position in the circular buffer, and these data are reported first. Finally, provided that the Wi-Fi network conditions are stable and the battery power is still sufficient, the backlogged P2-class low-priority data is uploaded.
[0125] In addition, to optimize costs from the source of data generation, a preprocessing and caching strategy based on statistical feature prediction can be used. The working principle is as follows: Before the vehicle event detector makes the final judgment, the following is executed in parallel: Feature monitoring: Within the streaming processing core, the dynamic features of specific signals (e.g., the rate of change of the brake pedal signal within a 100-millisecond time window) are continuously monitored in parallel.
[0126] Predictive judgment: When the dynamic characteristics of the signal (such as the rate of change of braking) are detected to exceed the preset warning threshold, the data sequence is judged to have potential high value.
[0127] Preprocessing and caching: For data sequences deemed potentially high-value, an aggregation computation within a micro-time window is immediately initiated. This computation iterates through the raw high-frequency signal data within the window at fixed time intervals (e.g., per second), generating data summaries such as maximum, minimum, and average values. Subsequently, this aggregated summary data is written to a protected storage area or marked as a high-priority reporting queue.
[0128] Collaboration with the vehicle event detector: Scenario A: If the vehicle event detector confirms the occurrence of a corresponding high-priority event (such as ABS triggering) in the subsequent period (e.g., 1 second later), it will promote and report the complete raw data before and after the event; at this time, the cloud platform will receive the complete raw data and summary data at the same time.
[0129] Scenario B: If the vehicle event detector does not trigger within the preset time window, it only reports the previously cached data summary, which provides the cloud platform with the ability to monitor potential risks at a lower cost.
[0130] As can be seen from the above vehicle data transmission control method, this method controls the target vehicle to transmit data precisely according to the instructions by using data acquisition commands issued by the cloud platform and combining them with signal list data. This enables flexible definition of business requirements and fundamentally avoids the transmission of invalid data, reducing the amount of data transmission. In addition, this method can set up a dual-layer storage area in the control device to retain key data, reducing the probability of data loss. This solves the problems of poor flexibility, high transmission cost, and high cloud pressure in the existing process of data transmission between vehicles and the cloud platform.
[0131] Corresponding to the above-described vehicle data transmission control method embodiment, this embodiment of the invention also provides a vehicle data transmission control system, as shown in Figure 12. The system includes: a data and instruction sending module 100, used to control a target vehicle to receive data acquisition instructions and signal list data sent by a cloud platform; a data acquisition and construction module 200, used to control the target vehicle to acquire raw data from the vehicle end via data acquisition instructions, and to construct a lookup table corresponding to the raw data from the vehicle end using the shared memory area corresponding to the control device in the target vehicle; a data query and analysis module 300, used to determine the corresponding signal attribute data in the lookup table via the identifier corresponding to the raw data from the vehicle end, and to determine the signal physical value, time data, and priority data corresponding to the raw data from the vehicle end using the signal attribute data and the signal list data; a queue data and transmission strategy determination module 400, used to construct queue data corresponding to the raw data from the vehicle end based on the signal physical value, and to determine the transmission strategy corresponding to the queue data via the time data and priority data; and a queue data transmission execution module 500, used to control the target vehicle to transmit the queue data to the cloud platform according to the transmission strategy.
[0132] As can be seen from the above vehicle data transmission control system, the system controls the target vehicle to transmit data precisely according to the instructions by using data acquisition commands issued by the cloud platform and combining them with signal list data. This enables flexible definition of business requirements and fundamentally avoids the transmission of invalid data, reducing the amount of data transmission. In addition, the system can set up a dual-layer storage area in the control device to retain key data, reducing the probability of data loss. This solves the problems of poor flexibility, high transmission costs, and high cloud pressure in the existing process of data transmission between vehicles and the cloud platform.
[0133] The vehicle data transmission control system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned vehicle data transmission control method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned vehicle data transmission control method embodiment.
[0134] This embodiment also provides a control device, the structural schematic of which is shown in Figure 13. The device includes a processor 101 and a memory 102. The memory 102 is used to store one or more computer instructions, which are executed by the processor to implement the steps of the above-described vehicle data transmission control method.
[0135] The control device shown in Figure 13 also includes a bus 103 and a communication interface 104. The processor 101, the communication interface 104, and the memory 102 are connected via the bus 103.
[0136] The memory 102 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. The bus 103 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only a single bidirectional arrow is used in Figure 13, but this does not indicate that there is only one bus or one type of bus.
[0137] The communication interface 104 is used to connect to at least one user terminal and other network units through a network interface, and to send encapsulated IPv4 packets or IPv4 packets to the user terminal through the network interface.
[0138] Processor 101 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 101 or by instructions in software form. The processor 101 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this disclosure can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 102. The processor 101 reads the information in memory 102 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.
[0139] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, devices, and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0140] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0141] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0142] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, electronic device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0143] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A vehicle data transmission control method, characterized in that, The method includes: controlling a target vehicle to receive data acquisition instructions and signal list data sent by a cloud platform; controlling the target vehicle to acquire raw data from the vehicle end via the data acquisition instructions, and constructing a lookup table corresponding to the raw data from the vehicle end using the shared memory area corresponding to the control device in the target vehicle; determining the corresponding signal attribute data in the lookup table using the identifier corresponding to the raw data from the vehicle end, and determining the signal physical value, time data, and priority data corresponding to the raw data from the vehicle end using the signal attribute data and the signal list data; constructing queue data corresponding to the raw data from the vehicle end based on the signal physical value, and determining the transmission strategy corresponding to the queue data using the time data and the priority data; and controlling the target vehicle to transmit the queue data to the cloud platform according to the transmission strategy.
2. The vehicle data transmission control method according to claim 1, characterized in that, The steps of controlling a target vehicle to receive data acquisition instructions and signal list data sent by a cloud platform include: obtaining the data interaction server corresponding to the target vehicle; determining the cloud platform corresponding to the data interaction server through the cloud data transmission interface corresponding to the target vehicle; obtaining the signal identifier, signal name, reporting frequency, and priority parameters corresponding to the target vehicle through the time-series database of the cloud platform; generating the data acquisition instructions corresponding to the target vehicle based on the signal identifier, and constructing the signal list data corresponding to the target vehicle using the signal identifier, the signal name, the reporting frequency, and the priority parameters; controlling a first control device of the target vehicle to receive the data acquisition instructions sent by the cloud platform using an asynchronous communication protocol, and controlling a second control device of the target vehicle to receive the signal list data sent by the cloud platform; wherein the first control device and the second control device interact with each other through a shared memory area.
3. The vehicle data transmission control method according to claim 2, characterized in that, The steps of controlling the target vehicle to collect raw vehicle-side data via the data acquisition command and constructing a lookup table corresponding to the raw vehicle-side data using the shared memory area corresponding to the control device in the target vehicle include: determining the target bus corresponding to the data acquisition command based on the vehicle network information of the target vehicle, and determining the shared memory area between the first control device and the second control device; controlling the first control device to collect the bus message corresponding to the target vehicle from the target bus via the data acquisition command, and determining the raw vehicle-side data corresponding to the target vehicle based on the bus message; controlling the first control device to transmit the raw vehicle-side data to the second control device using the shared memory area; controlling the second control device to initialize the table entry array corresponding to the raw vehicle-side data according to the extreme value of the signal data corresponding to the target bus; obtaining the message identifier corresponding to the bus message, and updating the table entry array using the signal start bit, signal bit length, signal data type, scaling factor, offset, and reporting timestamp corresponding to the message identifier in the raw vehicle-side data; and constructing a lookup table corresponding to the raw vehicle-side data based on the table entry array.
4. The vehicle data transmission control method according to claim 3, characterized in that, The steps of determining the corresponding signal attribute data in the query table by using the identifier corresponding to the vehicle-side raw data, and determining the signal physical value, time data, and priority data corresponding to the vehicle-side raw data using the signal attribute data and the signal list data, include: determining the identifier corresponding to the vehicle-side raw data based on the message identifier, and obtaining the identifier list corresponding to the signal identifier in the signal list data; if the identifier list contains the identifier, then obtaining the signal attribute data corresponding to the identifier in the query table; wherein, the signal attribute data includes at least: the signal start bit, the signal bit length, the signal data type, the scaling factor, the offset, and the reporting timestamp; The data extraction strategy corresponding to the vehicle-side raw data is determined using the signal start bit, the signal bit length, and the signal data type. The original signal value corresponding to the target vehicle is extracted from the vehicle-side raw data using the data extraction strategy. The data conversion strategy corresponding to the vehicle-side raw data is determined using the scaling factor and the offset. The original signal value is converted into the signal physical value corresponding to the vehicle-side raw data using the data conversion strategy. The system time value corresponding to the target vehicle is obtained. The time data corresponding to the vehicle-side raw data is determined using the system time value and the reporting timestamp. The priority data corresponding to the vehicle-side raw data is determined using the priority corresponding to the identifier in the signal list data.
5. The vehicle data transmission control method according to claim 4, characterized in that, The steps of constructing queue data corresponding to the vehicle-side raw data based on the signal physical values and determining the transmission strategy corresponding to the queue data using the time data and the priority data include: determining data tuples corresponding to the vehicle-side raw data using the signal physical values, the time data, and the priority data, and constructing queue data corresponding to the vehicle-side raw data using the data tuples; determining the data scheduling strategy corresponding to the queue data using the time difference between the system time value and the reporting timestamp in the time data; determining the data reporting strategy corresponding to the vehicle-side raw data using the priority classification value corresponding to the priority data; and determining the transmission strategy corresponding to the queue data based on the data scheduling strategy and the data reporting strategy.
6. The vehicle data transmission control method according to claim 5, characterized in that, The step of determining the data reporting strategy corresponding to the vehicle-side raw data using the priority classification value corresponding to the priority data includes: obtaining a first priority classification value, a second priority classification value, and a third priority classification value corresponding to the priority data, and obtaining the total data traffic threshold, mode switching duration, first traffic consumption ratio threshold, and second traffic consumption ratio threshold corresponding to the target vehicle based on the signal identifier; wherein, the first priority classification value is less than the second priority classification value, the second priority classification value is less than the third priority classification value; the first traffic consumption ratio threshold is less than the second traffic consumption ratio threshold; determining the first vehicle-side data, the second vehicle-side data, and the third vehicle-side data corresponding to the vehicle-side raw data based on the first priority classification value, the second priority classification value, and the third priority classification value; obtaining the real-time data traffic value corresponding to the control device, and obtaining the first reporting frequency corresponding to the first vehicle-side data, the second reporting frequency corresponding to the second vehicle-side data, and the third reporting frequency corresponding to the third vehicle-side data using the signal list data; wherein, the first reporting frequency is greater than the second reporting frequency and the third reporting frequency; and through the real-time... The ratio of the data traffic value to the total data traffic threshold determines the traffic consumption ratio value corresponding to the target vehicle. If the traffic consumption ratio threshold is less than the first traffic consumption ratio threshold, a first data reporting strategy corresponding to the first vehicle-side data, the second vehicle-side data, and the third vehicle-side data is determined using the first reporting frequency, the second reporting frequency, and the third reporting frequency. If the traffic consumption ratio threshold is not less than the first traffic consumption ratio threshold and is less than the second traffic consumption ratio threshold, the product of the second reporting frequency and a preset ratio value is obtained, and a second data reporting strategy corresponding to the first vehicle-side data and the second vehicle-side data is determined using the first reporting frequency and the product value. The preset ratio value is less than 1. If the traffic consumption ratio threshold is not less than the second traffic consumption ratio threshold, the summary data corresponding to the second vehicle-side data within a preset aggregation time is obtained, and a third data reporting strategy corresponding to the first vehicle-side data and the summary data is determined using the first reporting frequency and the aggregation time. The summary data includes extreme value data, average value data, and timestamp data corresponding to the second vehicle-side data within the aggregation time.
7. The vehicle data transmission control method according to claim 6, characterized in that, The step of controlling the target vehicle to transmit the queue data to the cloud platform according to the transmission strategy includes: obtaining a first storage area and a second storage area contained in the control device; wherein, the first storage space corresponding to the first storage area is larger than the second storage space corresponding to the second storage area, and the first data priority corresponding to the first storage area is larger than the second data priority corresponding to the second storage area; after saving the vehicle-side raw data to the first data block corresponding to the first storage area, using the priority data to obtain the second data block corresponding to the first data block in the second storage area, and saving the queue data to the second data block; and using the transmission strategy to control the transmission of the vehicle-side raw data in the first data block and the queue data in the second data block to the cloud platform.
8. The vehicle data transmission control method according to claim 7, characterized in that, The step of controlling the transmission of the vehicle-side raw data in the first data block and the queued data in the second data block to the cloud platform using the transmission strategy includes: when it is detected that the target vehicle is in a turned-off state, and the network connection time of the control device exceeds a preset network connection time threshold, and the power battery charge of the target vehicle is greater than a preset first remaining power threshold, and the data retention time corresponding to the priority data in the first storage area is less than a preset startup time threshold, respectively, acquiring the first transmission strategy, the second transmission strategy, and the third transmission strategy corresponding to the first priority classification value, the second priority classification value, and the third priority classification value; acquiring the queued data pair in the second data block. Based on historical data, the first transmission strategy is used to control the target vehicle to transmit the historical data and the queue data to the cloud platform; the first vehicle-side raw data corresponding to the second priority classification value in the first data block is obtained, the first data to be covered contained in the first vehicle-side raw data is determined, and the second transmission strategy is used to control the target vehicle to transmit the first data to be covered to the cloud platform; if the power battery charge of the target vehicle is greater than a preset second remaining power threshold, the second vehicle-side raw data corresponding to the third priority classification value in the first data block is obtained, and the third transmission strategy is used to control the target vehicle to transmit the second vehicle-side raw data to the cloud platform.
9. A vehicle data transmission control system, characterized in that, The system includes: a data and instruction sending module for controlling a target vehicle to receive data acquisition instructions and signal list data sent by a cloud platform; a data acquisition and construction module for controlling the target vehicle to acquire raw vehicle-side data through the data acquisition instructions, and constructing a lookup table corresponding to the raw vehicle-side data using the shared memory area corresponding to the control device in the target vehicle; a data query and analysis module for determining the corresponding signal attribute data in the lookup table through the identifier corresponding to the raw vehicle-side data, and determining the signal physical value, time data, and priority data corresponding to the raw vehicle-side data using the signal attribute data and the signal list data; a queue data and transmission strategy determination module for constructing queue data corresponding to the raw vehicle-side data based on the signal physical value, and determining the transmission strategy corresponding to the queue data through the time data and the priority data; and a queue data transmission execution module for controlling the target vehicle to transmit the queue data to the cloud platform according to the transmission strategy.
10. A control device, characterized in that, The control device includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the steps of the vehicle data transmission control method according to any one of claims 1 to 8.