A vehicle end data acquisition method, device and computer program product

Abstract

This invention discloses a vehicle-side data acquisition method, apparatus, and computer program product. The method includes: the vehicle receiving a source acquisition strategy file from the cloud, the source acquisition strategy file being written based on a predefined set of acquisition logic keywords; an interpreter in the vehicle-side data acquisition system reading the source acquisition strategy file and converting it into acquisition information; the interpreter transmitting the acquisition information to an executor via inter-process communication; the executor initiating a corresponding acquisition task based on the acquisition information and performing data acquisition operations; and the executor processing the acquired data and uploading it to the cloud. This invention, through a predefined set of acquisition logic keywords and a custom source acquisition strategy file, decouples the data acquisition strategy from the acquisition requirements, significantly improving the flexibility and scalability of data acquisition.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, specifically to a vehicle-side data acquisition method, device, and computer program product. Background Technology

[0002] With the rapid development of intelligent and connected vehicles, vehicle-side data acquisition systems have become an indispensable infrastructure for realizing functions such as vehicle status monitoring, fault diagnosis, user behavior analysis, and preference analysis. This system provides crucial data support to business partners and cloud platforms by performing data acquisition, processing, and transmission tasks on the vehicle side. However, as business needs continue to evolve, vehicle-side data acquisition systems face the dual challenges of rapidly implementing new requirements and frequently changing old ones.

[0003] Currently, mainstream vehicle-side data acquisition solutions typically employ a design pattern of strong coupling with the communication matrix. This means that business requirements are associated with the communication matrix to determine the information to be collected and then embedded in the code. Although some solutions use automated scripts to generate code for larger-scale applications, the essence remains the same: hard-coding the data collection requirements into the software. This traditional approach has the following significant drawbacks:

[0004] 1. Insufficient flexibility and adaptability: Data collection information, collection strategies, data processing strategies, and upload strategies are all fixed in the code, making it difficult for the system to dynamically adjust the collection behavior according to changes in business needs, thus limiting the flexibility and adaptability of data collection.

[0005] 2. Limited scalability: When new requirements need to be released or existing requirements need to be changed frequently, the system can usually only be upgraded via OTA (Over-The-Air). This not only increases development and maintenance costs, but may also lead to a long iteration cycle, making it difficult to meet rapidly changing market demands.

[0006] Furthermore, in practical applications, vehicle-side data acquisition systems also need to address technical issues such as data acquisition accuracy and upload latency. Existing solutions often exhibit high coupling and low scalability when dealing with complex and ever-changing business scenarios, making it difficult to meet the requirements of high efficiency, flexibility, and scalability for data acquisition systems in the context of intelligent and connected technologies. Summary of the Invention

[0007] The technical problem to be solved by the embodiments of the present invention is to provide a vehicle-side data acquisition method, device and computer program product, so as to realize the dynamic adjustment of the vehicle-side data acquisition strategy and improve the flexibility and scalability of data acquisition.

[0008] To solve the above-mentioned technical problems, the present invention provides a vehicle-side data acquisition method, comprising the following steps:

[0009] The vehicle receives a source acquisition strategy file sent from the cloud. The source acquisition strategy file is written based on a predefined set of acquisition logic keywords.

[0010] The interpreter in the vehicle-side data acquisition system reads the source acquisition strategy file and converts the source acquisition strategy file into acquisition information;

[0011] The interpreter transmits the collected information to the executor through inter-process communication;

[0012] The actuator initiates the corresponding acquisition task based on the acquired information and performs data acquisition operations.

[0013] The actuator processes the collected data and uploads it to the cloud.

[0014] Preferably, the set of collection logic keywords is defined through the following steps:

[0015] Based on the business scenarios, the commonalities of data collection needs are obtained. Specifically, the commonalities of data collection needs are the repetitive logical patterns of data collection needs in different business scenarios.

[0016] Based on the commonality of the data collection requirements, collection logic keywords are defined to trigger the corresponding collection functions on the vehicle and transmit parameters.

[0017] Preferably, the collection logic keywords defined based on the commonalities of the data collection requirements specifically include:

[0018] For scenarios involving signal transitions or signal value matching, define acquisition logic keywords to describe the triggering conditions and the signals to be acquired;

[0019] For periodic acquisition scenarios, define acquisition logic keywords to describe the acquisition frequency and the set of signals to be acquired;

[0020] For scenarios involving complex logical combinations, we define collection logic keywords to describe logical operators and combinations of multiple conditions.

[0021] Preferably, the acquisition logic keywords further include:

[0022] Keyword for the data acquisition logic used to activate data processing and uploading functions;

[0023] The acquisition logic keyword is used to activate the periodic acquisition function on the vehicle side, wherein the parameters following the acquisition logic keyword include the set of signals to be acquired and the periodic acquisition time range.

[0024] Preferably, the interpreter converts the source acquisition strategy file into acquisition information, specifically including:

[0025] Lexical analysis is performed on the source acquisition strategy file to extract acquisition logic keywords and parameters;

[0026] Perform syntactic analysis on the extracted collection logic keywords and parameters to generate a syntax tree;

[0027] The configuration is transformed based on the syntax tree to generate acquisition information that the executor can recognize.

[0028] Preferably, the acquisition task initiated by the actuator based on the acquired information includes at least one of the following: a single signal acquisition task; a signal transition triggered acquisition task; or a periodic acquisition task.

[0029] Preferably, when the actuator starts a data acquisition task, for periodic cyclic data acquisition tasks, the time interval between two data acquisition tasks is controlled according to the acquisition frequency parameter in the acquisition information; when the actuator uploads the processed data to the cloud, the time interval between two data uploads is controlled according to the upload frequency parameter in the acquisition information.

[0030] The present invention also provides a vehicle-side data acquisition device, comprising:

[0031] The receiver is used to receive the source acquisition strategy file sent from the cloud. The source acquisition strategy file is written based on a predefined set of acquisition logic keywords.

[0032] An interpreter is used to read the source acquisition strategy file and convert the source acquisition strategy file into acquisition information;

[0033] An executor is used to receive the acquisition information transmitted by the executor through inter-process communication, and to start the corresponding acquisition task according to the acquisition information, perform data acquisition operations, process the acquired data and upload it to the cloud.

[0034] The present invention also provides a computer program product, including computer instructions that instruct a computer device to perform an operation corresponding to the method.

[0035] Implementing this invention offers the following advantages: By defining a complete set of acquisition keywords and combining them with logical syntax features to write a source acquisition strategy file based on a custom language, and then distributing it to the vehicle-side data acquisition system via a cloud backend, this invention decouples data acquisition requirements from code implementation. The vehicle-side interpreter and executor dynamically adjust the data acquisition strategy by parsing and executing the source acquisition strategy file, thereby covering all data acquisition requirements even without updating the communication matrix, and supporting various complex logics and data processing formats. This invention significantly improves the flexibility and scalability of data acquisition, enabling system engineers to independently implement business requirements by writing source acquisition strategy files without modifying the vehicle-side code. This not only reduces the code coupling and development complexity of the vehicle-side data acquisition system but also reduces the workload and manpower costs of software development. Furthermore, it supports real-time distribution and real-time effective dynamic adjustment of acquisition strategies, providing efficient and flexible technical support for vehicle intelligence and connectivity. Attached Figure Description

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

[0037] Figure 1 This is a flowchart illustrating a vehicle-side data acquisition method according to an embodiment of the present invention.

[0038] Figure 2 This is a schematic diagram illustrating the implementation principle of a vehicle-side data acquisition method according to Embodiment 1 of the present invention. Detailed Implementation

[0039] The following description of the embodiments is taken with reference to the accompanying drawings, which illustrate specific embodiments in which the invention can be implemented.

[0040] Please refer to Figure 1 As shown, Embodiment 1 of the present invention provides a vehicle-side data acquisition method, including the following steps:

[0041] The vehicle receives a source acquisition strategy file sent from the cloud. The source acquisition strategy file is written based on a predefined set of acquisition logic keywords.

[0042] The interpreter in the vehicle-side data acquisition system reads the source acquisition strategy file and converts the source acquisition strategy file into acquisition information;

[0043] The interpreter transmits the collected information to the executor through inter-process communication;

[0044] The actuator initiates the corresponding acquisition task based on the acquired information and performs data acquisition operations.

[0045] The actuator processes the collected data and uploads it to the cloud.

[0046] As demonstrated by the above steps, this invention, through a predefined set of acquisition logic keywords and a custom source acquisition strategy file, decouples the data acquisition strategy from the acquisition requirements, significantly improving the flexibility and scalability of data acquisition. The vehicle-side interpreter component can dynamically parse the source acquisition strategy file and convert it into an acquisition configuration recognizable by the executor, thereby supporting acquisition tasks with various complex logics and data processing requirements in multiple formats. This invention avoids the problem of frequent code modifications due to changes in acquisition requirements in traditional solutions. By using a source acquisition strategy file that is issued and takes effect in real time, it achieves dynamic adjustment of the data acquisition strategy, reducing development and maintenance costs while improving the adaptability and response speed of the vehicle-side data acquisition system, providing efficient and reliable technical support for vehicle intelligence and connectivity.

[0047] Specifically, please combine Figure 2 As shown in this embodiment of the invention, the vehicle-side needs to identify common requirements across different business scenarios (such as vehicle status monitoring, fault alarms, and user behavior analysis). It can be understood that the commonalities in data collection requirements are repetitive logical patterns in different business scenarios, abstracted from the common characteristics of data collection rules in specific business scenarios (such as signal transition triggering, signal value matching, periodic collection, and complex logic combinations). These common logics are abstracted into predefined collection logic keywords (such as "eq", "changes", and "periodical_capture"), thus covering the collection requirements of various business scenarios. For example, a real vehicle may have the following requirement scenarios:

[0048] Scenario 1: Tire overheating alarm; when the TPMS_WakeUpByHighTemperature signal is equal to 1, collect this signal and report it to the cloud;

[0049] Scenario 2: Alarm for failed window closing in rainy weather; when the SR_RainCloseSunroofReqExculSt signal is equal to 2, collect this signal and report it to the cloud;

[0050] Scenario 3: Using mode transition events; when the UMM_UsageModeSt signal value changes, collect this signal and report it to the cloud;

[0051] Scenario 4: Left front window opening status event; when the PWL_WinOpeationSt_FLWinSt signal value jumps to 0 / 3 / 4 / 5, upload the PWL_WinCurrentPos_FLWinPst signal value;

[0052] Scenario 5: Monitor the following set of signals (MR_LeftMirrorOpeCmd, MR_LeftMirrorFoldUnfoldCtlReq, MR_MirrAntiGlarePowerOnReq, MR_LeftMirrorXTargetPos, MR_RightMirrorFoldUnfoldCtlReq, MR_LeftMirrorYTargetPos, MR_RightMirrorOpeCmd, MR_RightMirrorXTargetPos, MR_RightMirrorYTargetPos, ACU_LeftMirrorXPosCtlReq, ACU_LeftMirrorYPosCtlReq, ACU_RightMirrorXPosCtlReq, ACU_RightMirrorYPosCtlReq, ACU_FoldUnfoldCtlReq). When any signal transition is detected, collect all signal values ​​for the five seconds before and five seconds after the transition, write them to a file, and upload the file to the cloud.

[0053] By analyzing the first four scenarios, we can see that they all share the commonality of collecting and uploading signal B data when signal A changes to or equals a certain value. Therefore, we can extract their logical commonalities and define a series of keywords. These keywords are similar to syntax elements in programming languages, used to describe the logical rules of data acquisition. For example:

[0054] The keyword "eq" is defined to represent the "equals" logical operator.

[0055] The keyword "changes" is defined to represent signal transitions;

[0056] The keyword "or" is defined to represent the "or" relationship in logical operators, and "and" is used to represent the "and" relationship in logical operators.

[0057] For collecting a single signal, this embodiment of the invention uses JSON format for uploading. Therefore, the keyword "upload_signal_by_json" is defined to activate the data processing and uploading functions.

[0058] These collection logic keywords constitute the programming language for developing the "source collection strategy file." The source collection strategy file is a configuration file that uses these keywords to describe specific collection tasks. Understandably, different business scenarios will correspond to different collection requirements, therefore the programming keywords in the source collection strategy file will also differ. For the five requirement scenarios mentioned above, the source collection strategy file represents them as follows:

[0059]

[0060]

[0061]

[0062] By analyzing the fifth requirement, we can see that its characteristic is that when any signal in a set of signals changes, data within a certain time period needs to be collected, written to a file, and uploaded. Therefore, for this type of requirement, this embodiment of the invention defines the keyword "periodical_capture" to activate the periodic acquisition function on the vehicle side, and the two parameters following it in square brackets represent the "set of signals to be acquired" and the "periodic acquisition time range," respectively.

[0063] For other requirements involving new features, the same approach is used: analyzing and extracting commonalities to define new keywords to ensure that the data acquisition logic can be separated from the vehicle-side data acquisition code. These custom keywords are then implemented in the "source acquisition strategy file." Furthermore, the keywords in the source acquisition strategy file are not only used to trigger specific acquisition functions on the vehicle side, but can also pass parameters. For example, the aforementioned "periodical_capture" keyword can be accompanied by parameters specifying the acquisition time range and signal set.

[0064] It should also be noted that, in this embodiment of the invention, the collection logic keyword set is the minimum complete set for writing the "source collection strategy file," that is, using the fewest necessary keywords to cover all possible collection requirements. The interpreter in the vehicle-side data collection system needs to perform lexical and syntactic analysis on the source collection strategy file, and the collection logic keyword set is the foundation for the interpreter to recognize and parse the file content. The interpreter converts the source collection strategy file into configuration information that the executor can understand by recognizing keywords and their parameters. Simultaneously, the executor starts specific collection tasks based on the configuration information generated by the interpreter, and the key parts of the configuration information (such as task type, parameters, etc.) are defined by the collection logic keyword set. The collection logic keyword set determines the types of tasks and their parameters that the executor can handle.

[0065] Therefore, the set of data acquisition logic keywords is a crucial parameter for achieving adaptive dynamic data acquisition. Its completeness and flexibility directly determine whether the vehicle-side data acquisition system can adapt to different business scenarios and changing needs. This invention defines a set of universal data acquisition logic keywords, extracting the logical rules of data acquisition from the vehicle-side code to form a configurable "source acquisition strategy file." This allows the vehicle-side to flexibly adjust the data acquisition strategy through configuration (rather than code) to adapt to different business scenarios, while avoiding frequent code modifications due to changing requirements, significantly improving the system's flexibility and scalability.

[0066] After being compiled into a source acquisition strategy file based on a predefined set of acquisition logic keywords, it is sent to the vehicle-side data acquisition system via the cloud. Specifically, the cloud forwards the source acquisition strategy file to the Vehicle Cloud Proxy (VCP) module within the vehicle's Central Control Unit (CCU) via the Telematics Box (TBox). The VCP module is the proxy module for communication between the vehicle and the cloud, responsible for receiving the source acquisition strategy file forwarded by the TBox and passing it to the Big Data Collection (BDC) module through service calls.

[0067] The BDC module is responsible for parsing and executing the source acquisition strategy file in the vehicle-side data acquisition system. It will start the interpreter to parse the source acquisition strategy file, specifically including:

[0068] (1) Lexical Analysis

[0069] The interpreter first performs lexical analysis on the source acquisition strategy file to extract basic elements such as acquisition logic keywords and parameters. For example, it identifies keywords such as "eq" and "changes" and their related parameters.

[0070] (2) Syntax Analysis

[0071] Based on lexical analysis, the interpreter performs syntax analysis, checks whether the syntax of the source acquisition strategy file is correct, and generates a syntax tree (a logically structured representation).

[0072] (3) Configuration conversion

[0073] The interpreter converts the source acquisition strategy file into acquisition information that the executor can recognize based on the syntax tree, including acquisition task type (such as periodic acquisition, signal transition triggered acquisition, etc.) and acquisition parameters (such as signal name, time range, etc.).

[0074] As can be seen from the above, this invention distributes the source data collection strategy file from the cloud, allowing the vehicle-side to dynamically adjust the data collection strategy without modifying the code, adapting to different business needs. Simultaneously, the collection logic is decoupled from the vehicle-side code; changes to the collection strategy only require modification of the source data collection strategy file, without the need to recompile or upgrade the vehicle-side software.

[0075] The interpreter transmits the collected information from memory to the executor via inter-process communication (IPC). The executor then initiates the corresponding data acquisition task based on this information to perform the necessary data acquisition. Specifically, the executor initiates the corresponding data acquisition task based on the task type and parameters in the data acquisition information. Task types include:

[0076] Signal transition trigger acquisition: When the value of a signal changes, relevant data is acquired;

[0077] Condition-triggered acquisition: When a signal meets a specific condition (such as being equal to a certain value), relevant data is acquired;

[0078] Periodic data collection: Data is collected periodically at fixed time intervals.

[0079] For periodic data acquisition tasks, the acquired information includes a acquisition frequency parameter, which controls the time interval between two acquisition tasks. For example, a acquisition frequency parameter of 1 second means that the executor performs data acquisition once every 1 second. The executor starts a timer according to the acquisition frequency parameter. After the timer expires, it performs the data acquisition operation and restarts the timer after completion, forming a periodic cycle. By using the acquisition frequency parameter, the system can flexibly adjust the data acquisition time interval according to business needs, such as acquiring critical signals at high frequency or non-critical signals at low frequency.

[0080] The interpreter and executor collaborate through inter-process communication, decoupling the acquisition logic from the acquisition execution, which facilitates system expansion and maintenance.

[0081] After the actuator completes data acquisition, it processes the data (such as format conversion and packaging), and then uploads the processed data to the cloud via data stream or binary file. Similarly, when uploading the processed data to the cloud platform, the actuator controls the time interval between two data uploads based on the upload frequency parameter in the acquisition information.

[0082] Corresponding to the vehicle-side data acquisition method described in Embodiment 1 of the present invention, Embodiment 2 of the present invention also provides a vehicle-side data acquisition device, comprising:

[0083] The receiver is used to receive the source acquisition strategy file sent from the cloud. The source acquisition strategy file is written based on a predefined set of acquisition logic keywords.

[0084] An interpreter is used to read the source acquisition strategy file and convert the source acquisition strategy file into acquisition information;

[0085] An executor is used to receive the acquisition information transmitted by the executor through inter-process communication, and to start the corresponding acquisition task according to the acquisition information, perform data acquisition operations, process the acquired data and upload it to the cloud.

[0086] Corresponding to the vehicle-side data acquisition method described in Embodiment 1 of the present invention, Embodiment 3 of the present invention also provides a vehicle-side data acquisition device, comprising:

[0087] One or more processors;

[0088] Memory;

[0089] One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the vehicle-side data acquisition method.

[0090] Corresponding to the vehicle-side data acquisition method described in Embodiment 1 of the present invention, Embodiment 4 of the present invention also provides a computer program product, including computer instructions, which instruct a computer device to perform the operation corresponding to the vehicle-side data acquisition method described in Embodiment 1 of the present invention.

[0091] Preferably, the computer instructions can be divided into one or more modules / units (such as computer program 1, computer program 2, ...), and the one or more modules / units are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing a specific function, and the instruction segments are used to describe the execution process of the computer program in the device.

[0092] Preferably, the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor, or the processor can be any conventional processor. The processor is the control center of the device, connecting various parts of the device through various interfaces and lines.

[0093] The memory mainly includes a program storage area and a data storage area. The program storage area can store the operating system, applications required for at least one function, etc., while the data storage area can store related data, etc. Furthermore, the memory can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard drive, a SmartMedia Card (SMC), a Secure Digital (SD) card, and a Flash Card, or other volatile solid-state storage devices.

[0094] It should be noted that the above-mentioned devices may include, but are not limited to, processors and memory, as will be understood by those skilled in the art.

[0095] For the working principle and process of the above embodiments, please refer to the description of Embodiment 1 of the present invention, which will not be repeated here.

[0096] As described above, compared with existing technologies, the advantages of this invention are as follows: This invention achieves decoupling between data acquisition requirements and code implementation by defining a complete set of acquisition keywords, combining logical syntax features to write a source acquisition strategy file based on a custom language, and then distributing it to the vehicle-side data acquisition system via a cloud backend. The vehicle-side interpreter and executor dynamically adjust the data acquisition strategy by parsing and executing the source acquisition strategy file, thereby covering all data acquisition requirements even without updating the communication matrix, and supporting various complex logics and data processing formats. This invention significantly improves the flexibility and scalability of data acquisition, enabling system engineers to independently implement business requirements by writing source acquisition strategy files without modifying the vehicle-side code. This not only reduces the code coupling and development complexity of the vehicle-side data acquisition system but also reduces the workload and manpower costs of software development. Simultaneously, it supports real-time distribution and real-time effective dynamic adjustment of acquisition strategies, providing efficient and flexible technical support for vehicle intelligence and connectivity.

[0097] The above description is merely a preferred embodiment of the present invention and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of the present invention are still within the scope of the present invention.

Claims

1. A method for collecting vehicle-side data, characterized in that, Includes the following steps: The vehicle receives a source acquisition strategy file sent from the cloud. The source acquisition strategy file is written based on a predefined set of acquisition logic keywords. The interpreter in the vehicle-side data acquisition system reads the source acquisition strategy file and converts the source acquisition strategy file into acquisition information; The interpreter transmits the collected information to the executor through inter-process communication; The actuator initiates the corresponding acquisition task based on the acquired information and performs data acquisition operations. The actuator processes the collected data and uploads it to the cloud.

2. The method according to claim 1, characterized in that, The set of logical keywords for data collection is defined through the following steps: Based on the business scenarios, the commonalities of data collection needs are obtained. Specifically, the commonalities of data collection needs are the repetitive logical patterns of data collection needs in different business scenarios. Based on the commonality of the data collection requirements, collection logic keywords are defined to trigger the corresponding collection functions on the vehicle and transmit parameters.

3. The method according to claim 2, characterized in that, Based on the commonalities of the aforementioned data collection requirements, the specific keywords for the data collection logic include: For scenarios involving signal transitions or signal value matching, define acquisition logic keywords to describe the triggering conditions and the signals to be acquired; For periodic acquisition scenarios, define acquisition logic keywords to describe the acquisition frequency and the set of signals to be acquired; For scenarios involving complex logical combinations, we define collection logic keywords to describe logical operators and combinations of multiple conditions.

4. The method according to claim 3, characterized in that, The data acquisition logic keywords also include: Keyword for the data acquisition logic used to activate data processing and uploading functions; The acquisition logic keyword is used to activate the periodic acquisition function on the vehicle side, wherein the parameters following the acquisition logic keyword include the set of signals to be acquired and the periodic acquisition time range.

5. The method according to claim 1, characterized in that, The interpreter converts the source acquisition strategy file into acquisition information, specifically including: Lexical analysis is performed on the source acquisition strategy file to extract acquisition logic keywords and parameters; Perform syntactic analysis on the extracted collection logic keywords and parameters to generate a syntax tree; The configuration is transformed based on the syntax tree to generate acquisition information that the executor can recognize.

6. The method according to claim 1, characterized in that, The acquisition tasks initiated by the actuator based on the acquired information include at least one of the following: a single signal acquisition task; a signal transition triggered acquisition task; and a periodic acquisition task.

7. The method according to claim 6, characterized in that, When the actuator starts a data acquisition task, for periodic data acquisition tasks, it controls the time interval between two data acquisition tasks according to the acquisition frequency parameter in the acquisition information; when the actuator uploads the processed data to the cloud, it controls the time interval between two data uploads according to the upload frequency parameter in the acquisition information.

8. A vehicle-mounted data acquisition device, characterized in that, include: The receiver is used to receive the source acquisition strategy file sent from the cloud. The source acquisition strategy file is written based on a predefined set of acquisition logic keywords. An interpreter is used to read the source acquisition strategy file and convert the source acquisition strategy file into acquisition information; An executor is used to receive the acquisition information transmitted by the executor through inter-process communication, and to start the corresponding acquisition task according to the acquisition information, perform data acquisition operations, process the acquired data and upload it to the cloud.

9. A vehicle-side data acquisition device, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the vehicle-side data acquisition method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes computer instructions that instruct a computer device to perform an operation corresponding to the method as described in any one of claims 1 to 7.

Images