Method for updating vehicle end data acquisition function, vehicle and server

Abstract

The invention provides a method for updating a vehicle end data acquisition function, the method is applied to a vehicle end, and the method comprises the following steps: step S100, receiving a script and / or configuration containing an acquisition rule sent by a server, the acquisition rule specifying to trigger acquisition of related scene data in a predetermined acquisition scene; step S200, analyzing the received script and / or configuration by means of an interpreter so as to convert an acquisition rule contained in the script and / or configuration into an acquisition instruction executable by the vehicle end; and step S300, according to the converted acquisition instruction, executing a vehicle end data acquisition operation. The application also proposes a vehicle, a server and a computer program product. In the application, only the script or configuration related to the data acquisition function instead of the whole software package needs to be downloaded, so that compared with the OTA technology, the bandwidth is remarkably saved, and the updating period is shortened.

Description

Technical Field

[0001] The present application relates to a method for updating a vehicle-side data collection function. The present application also relates to a vehicle, a server and a computer program product. Background Art

[0002] In modern intelligent vehicle systems, achieving dynamic updates of vehicle-side data collection functions is a key technical challenge. With the development of autonomous driving technology and the increasing need for vehicle software function diagnosis, vehicles must quickly adapt to new data collection requirements to support these advanced functions and services.

[0003] At present, the update of vehicle software functions mainly relies on over-the-air (OTA) technology. Although this technology provides a remote solution, it requires downloading the entire software package to update the vehicle system, resulting in a long update cycle and a large consumption of bandwidth resources, thus limiting the efficiency and security of the vehicle-side data collection function update. Therefore, the existing technology still has shortcomings in the remote update of the vehicle-side data collection function. Summary of the invention

[0004] The purpose of the present application is to provide a method for updating a vehicle-side data collection function on a vehicle side, a method for updating a vehicle-side data collection function on a server side, a server and a computer program product, so as to at least solve some of the problems in the prior art.

[0005] According to a first aspect of the present application, a method for updating a vehicle-side data collection function is provided, the method being applied to a vehicle-side, and the method comprising the following steps:

[0006] Step S100, receiving a script and / or configuration containing a collection rule sent by a server, wherein the collection rule specifies triggering the collection of relevant scene data under a predetermined collection scene;

[0007] Step S200, parsing the received script and / or configuration with the aid of an interpreter to convert the collection rules contained in the script and / or configuration into collection instructions executable by the vehicle side; and

[0008] Step S300, executing the vehicle-side data collection operation according to the converted collection instruction.

[0009] This application particularly includes the following technical concepts: Compared with traditional OTA technology, the method of issuing scripts / configurations allows accurate updates only for specific data collection needs without the need for vehicle-level software updates, thereby responding more quickly to market and technological evolution, and flexibly expanding and optimizing vehicle-side data collection functions. In addition, since only scripts or configurations related to data collection functions need to be downloaded instead of the entire software package, bandwidth is significantly saved and the update cycle is shortened. Overall, this method shows obvious advantages in improving efficiency, ensuring safety, and enhancing flexibility, and provides a more efficient and reliable solution for functional updates of modern intelligent vehicle systems.

[0010] In an exemplary embodiment, the collection rules include at least one of the following: in a scenario where the vehicle fails to park automatically, triggering the collection of vehicle-side data related to automatic parking; in a scenario where the vehicle in front performs emergency braking, triggering the collection of vehicle-side data related to emergency braking; and / or, in a scenario where the vehicle collides, triggering the collection of vehicle-side data related to collision.

[0011] In an exemplary embodiment, a corresponding interpreter is dynamically selected according to the file type received from the server: when a configuration is received from the server, a customized interpreter is used to parse the configuration, and the customized interpreter is implemented to follow the interpretation rules related to the configuration; when a script is received from the server, an interpreter corresponding to the script language of the script is used to parse the script.

[0012] In an exemplary embodiment, step S200 includes: performing serialization and deserialization on the underlying interface communication data on the vehicle side so as to dynamically load and dynamically parse the vehicle-side signals required by the acquisition rules, wherein Protobuf is used as a serialization tool on the vehicle side, and / or the serialization and deserialization methods provided by the ROS framework and / or the Autosar framework are used.

[0013] In an exemplary embodiment, serialization and deserialization are performed on the vehicle side in the following manner: serializing the vehicle-side underlying interface communication data to retrieve a vehicle-side signal set that includes vehicle-side signals required by acquisition rules; and deserializing the vehicle-side signal set to locate the signal name of the vehicle-side signal required by the acquisition rule in the vehicle-side signal set, and extracting the signal value corresponding to the signal name.

[0014] According to a second aspect of the present application, a method for updating a vehicle-side data collection function is provided, and the method is applied to a server side, and the method comprises the following steps: step S10, generating a script and / or configuration containing collection rules according to the update requirements of the vehicle-side data collection function, wherein the collection rules specify triggering the collection of relevant scene data under a predetermined collection scenario; and, step S20, sending the generated script and / or configuration to the vehicle to update the vehicle-side data collection function.

[0015] In an exemplary embodiment, the method further includes the following steps: step S12, verifying and releasing the written script and / or configuration, wherein, if the script and / or configuration passes the unit test and the interface test, the verification and release of the script and / or configuration is allowed; step S14, performing real vehicle testing and simulation testing on the script and / or configuration, wherein the test is considered to have passed at least when the real vehicle test is successful; wherein, when the verification and release and the test pass, execute step S20.

[0016] According to a third aspect of the present application, a vehicle is provided, which is used to execute the method according to the first aspect of the present application, and the vehicle includes: a receiving unit, which is configured to be able to receive a script and / or configuration containing collection rules sent by a server, and the collection rules specify triggering the collection of relevant scene data under a predetermined collection scenario; a parsing unit, which is configured to be able to parse the received script and / or configuration with the help of an interpreter to convert the collection rules contained in the script and / or configuration into collection instructions executable on the vehicle side; and an execution unit, which is configured to be able to execute the vehicle-side data collection operation according to the converted collection instructions.

[0017] According to the fourth aspect of the present application, a server is provided, which is used to execute the method according to the second aspect of the present application, and the server includes: a generation unit, which is configured to generate a script and / or configuration containing collection rules according to the update requirements of the vehicle-side data collection function, and the collection rules specify the collection of relevant scene data triggered under a predetermined collection scenario; and a sending unit, which is configured to send the generated script and / or configuration to the vehicle to update the vehicle-side data collection function.

[0018] According to a fifth aspect of the present application, a computer program product is provided, comprising computer program instructions, wherein when the computer program instructions are executed by a processor, the processor is enabled to perform the method according to the first aspect and / or the second aspect of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The present application will be described in more detail below with reference to the accompanying drawings, so that the principles, features and advantages of the present application can be better understood. The accompanying drawings include:

[0020] Figure 1 A flow chart of a method for updating a vehicle-side data collection function applied to a vehicle-side according to an exemplary embodiment of the present application is shown;

[0021] Figure 2 A schematic diagram showing a process of serializing and deserializing underlying interface communication data at a vehicle end according to an exemplary embodiment of the present application is shown;

[0022] Figure 3 A flowchart showing a method for updating a vehicle-side data collection function applied to a server-side according to an exemplary embodiment of the present application is shown; and

[0023] Figure 4 A schematic diagram of a vehicle and a server according to an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] In order to make the technical problems, technical solutions and beneficial technical effects to be solved by the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and multiple exemplary embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the scope of protection of the present application.

[0025] Figure 1 A flow chart of a method for updating a vehicle-side data collection function applied to a vehicle-side according to an exemplary embodiment of the present application is shown. The method comprises steps S100, S200 and S300.

[0026] In step S100, a script and / or configuration containing collection rules sent by a server is received, wherein the collection rules specify triggering the collection of relevant scene data under a predetermined collection scene.

[0027] In this context, "vehicle side" can refer to, for example, a client vehicle that has been sold and operated by a user, that is, a customer vehicle. This approach is applicable to both single vehicles and multi-vehicle environments. The collected data can be used for a variety of purposes, including but not limited to the research and development of autonomous driving technology, algorithm optimization, and diagnosis of the software functions and performance of user vehicles.

[0028] The types of data covered by vehicle-side data collection include, for example, environmental data, vehicle status data, algorithm-generated structured data, and log data. These data can be obtained in a variety of ways, including, for example, collecting from vehicle sensors (such as cameras, radar sensors, vehicle status sensors, etc.), extracting from the vehicle's runtime program, or retrieving from interface calls and specific storage locations (such as log files).

[0029] The collection rules define the specific update content of the vehicle-side data collection function to guide the vehicle to perform data collection or collect new types of data according to new logic and methods.

[0030] In one embodiment, the collection rules are designed to expand and define new or currently unknown data collection scenarios and the types of data to be collected in these specific scenarios. For example, the collection rules may include at least one of the following:

[0031] - In the scenario where the vehicle fails to park automatically, trigger the collection of vehicle-side data related to automatic parking. The data types to be collected may include vehicle location information, environmental perception data (such as lidar point cloud data, images captured by cameras, etc.), parking system control instructions and feedback, and parking operation timestamps, etc.

[0032] - In the scenario where the vehicle ahead performs emergency braking, the vehicle-side data collection related to emergency braking is triggered. The collected data may involve the speed and distance information of the vehicle ahead, the speed and deceleration of the vehicle, the response time of the braking system, and related driving behavior data.

[0033] - In the event of a vehicle collision, the vehicle-side data collection related to the collision is triggered. The data types to be collected may include vehicle speed, driving direction, airbag deployment status, vehicle acceleration and deceleration data, and collision intensity and duration in the period before and after the collision.

[0034] In another embodiment, the update of the collection rules may also involve the adjustment of multiple key configurations and parameters of the vehicle-side data collection function, which may include, for example, the collection frequency, trigger conditions, duration, data type, and data volume. For example, by issuing new scripts or configurations, the vehicle can dynamically adjust the collection frequency of the sensor according to the real-time traffic conditions, such as increasing the collection frequency of GPS positioning data when driving at high speeds to enhance the accuracy of the location information. In addition, the updated collection rules can also be set to automatically trigger the data collection of the vibration sensor when the vehicle detects abnormal vibration, so as to further analyze and diagnose potential mechanical problems.

[0035] In the lightweight remote update method involved in this application, there are two main ways: receiving a script sent down, or receiving a configuration sent down. The main difference between the two is that sending scripts allows the vehicle to use existing scripting languages ​​and load the corresponding interpreter on the vehicle side to execute these scripts to achieve specific functions; while sending configurations requires the vehicle to have custom rules and interpreters to parse these configurations, treating the configuration as a new customized scripting language to achieve the required functions. In actual applications, the most appropriate update method can be selected according to the specific needs of the project.

[0036] Optionally, before executing step S100, the vehicle may actively initiate an update request to the server, and then receive the script and / or configuration sent by the server. In addition, the server may also actively push updates to the vehicle according to the update cycle as needed.

[0037] Next, in step S200, the received script and / or configuration is parsed with the aid of an interpreter to convert the collection rules contained in the script and / or configuration into collection instructions executable by the vehicle side.

[0038] The acquisition instructions are a series of commands that instruct computer hardware on how to operate. They need to be converted into a machine-readable format, which usually involves a conversion process from high-level language to low-level language, and finally executed on the hardware in the form of binary encoding.

[0039] In one embodiment, the interpreter may include, for example, a Python interpreter, a lua interpreter, and a JavaScript engine, which is responsible for converting high-level language instructions in the script or configuration into instructions executable by the vehicle in real time. This may involve importing relevant library files, receiving vehicle-side information, obtaining required signal values, and using them for logical judgment and executing acquisition actions. For example, the script sent down may contain conditional statements to specify that when the vehicle needs to dynamically adjust the sensor acquisition frequency according to traffic conditions, the interpreter will parse these conditions and activate the corresponding data acquisition process when specific conditions are met.

[0040] Here, unlike compiling a complete program, compiled languages ​​such as C or C++ need to convert the complete source code into machine code before execution to generate a program that can run independently. In the interpreter mode involved in this application, scripting languages ​​such as Python and JavaScript do not need to be pre-compiled. They are converted into machine code line by line by the interpreter at runtime. This method makes the update of the vehicle-side data acquisition function not dependent on OTA technology and has high flexibility.

[0041] In one embodiment, the corresponding interpreter can be dynamically selected according to the file type received from the server. For example, the vehicle end is pre-installed with multiple types of interpreters and is equipped with a corresponding switching mechanism to select a suitable interpreter according to the file type sent by the server (whether it is a script file or a configuration file, or a script file written in a different language). For example, when a configuration is received from a server, a customized interpreter can be used to parse the configuration, and the customized interpreter is designed and implemented to follow the interpretation rules related to the configuration. When a script is received from a server, an interpreter corresponding to the script language of the script can be used to parse the script.

[0042] In one embodiment, step S200 may further include: performing serialization and deserialization on the underlying interface communication data on the vehicle side, so as to dynamically load and dynamically parse the vehicle side signals required by the acquisition rules. Exemplarily, Protobuf is used as a serialization tool on the vehicle side, and / or the serialization and deserialization methods provided by the ROS framework and / or the Autosar framework are used.

[0043] Since the scripts and configurations sent from the cloud are unknown, the vehicle side cannot predict or embed the specific logic of these scripts and configurations at compile time. These scripts and configurations may be written in any language, not necessarily the same as the programming language used by the vehicle side system (such as C++). Therefore, the vehicle side relies on serialization and deserialization mechanisms to dynamically obtain the necessary interface information, so that dynamic loading of scripts and configurations can be achieved.

[0044] In general, "dynamic loading" and "dynamic parsing" refer to the process of loading and parsing interface communication data in real time based on unknown scripts and configuration information sent from the cloud when the program is running. Unlike static loading and parsing, where all code and resources are determined at compile time and cannot be changed once compiled, the dynamic method allows the vehicle-side system to flexibly adapt to new configurations or scripts at runtime without knowing their specific content in advance.

[0045] The detailed implementation process of serialization and deserialization will be combined below. Figure 2 Further elaboration.

[0046] In step S300, the vehicle-side data collection operation is performed according to the converted collection instruction.

[0047] These machine-readable instructions specify in detail all aspects of data collection, including the type of data to be collected, the frequency of collection, the time point, and the pre-processing and storage methods of the data. The vehicle's hardware and software systems follow these instructions to automatically activate sensors, sample data, and send the collected data to a data processing unit or directly store it for subsequent analysis and use.

[0048] For example, the vehicle's system constantly monitors the vehicle state and external environment to identify whether the data collection scenarios defined in the script or configuration file are met. This may include specific driving patterns, geographic locations, vehicle status, time conditions, or specific event triggers. Once a scenario that meets the collection rules is detected, the vehicle's control unit activates one or more related software modules or hardware devices. For example, specific sensors are started to collect data, or data processing software inside the vehicle is activated to prepare for data collection and processing. The collected data can be pre-processed, such as filtering, formatting, or compression, for easy storage and transmission. The processed data can be stored in the vehicle's local storage system, or directly transmitted to the data processing unit for further analysis, or sent to the cloud for storage and analysis.

[0049] Figure 2 A schematic diagram is shown of a process of serializing and deserializing underlying interface communication data at a vehicle end according to an exemplary embodiment of the present application.

[0050] In modern intelligent vehicle systems, the vehicle-side underlying interface 202 integrates serialization / deserialization middleware (such as Protobuf). Figure 2 Briefly describe the general process of serialization and deserialization.

[0051] exist Figure 2 In the embodiment shown, the vehicle receives a script / configuration from a server (cloud), and then follows Figure 1 The described process uses an interpreter to read the script / configuration and extract the following collection rule business code 102:

[0052] Receive message

[0053] Extract signals

[0054] Judgment:"signal1*signal2+signal3<0"

[0055] Collect Data

[0056] To describe it in natural language, this can be understood as: receiving the vehicle-side signal set, capturing the signal values ​​of specific signals with signal names "signal1", "signal2", and "signal3" from the vehicle-side signal set, and determining whether signal1*signal2+signal3<0 is satisfied. If so, vehicle-side data collection is triggered.

[0057] like Figure 2As shown, when the script's business code 102 needs to call the vehicle-side underlying interface 202 to obtain the corresponding information. The vehicle-side underlying interface 202 is responsible for communicating with various different systems and modules, which requires that the data exchange format must be standardized so that different systems can interact seamlessly. The serialization and deserialization middleware integrated in the vehicle-side underlying interface 202 provides the ability to convert data structures into standardized formats, ensuring data compatibility and consistency.

[0058] For example, the vehicle-side underlying interface 202 first converts the structured data into a byte stream through a serialization operation 21. This process implements the retrieval of the vehicle-side signal set, which contains the specific vehicle-side signals required for parsing the collection rules. Exemplarily, the script service code 102 can request to obtain the vehicle-side signal set through a receive message statement, which triggers the call to the vehicle-side underlying interface 202.

[0059] Here, the role of serialization 21 can be understood more specifically as follows: different programming languages ​​may have different data representation methods. For example, the vehicle-side system is based on the C++ programming language, while the script sent from the cloud may be based on another language. For example, the vehicle speed is defined by "speed" in the script, but the vehicle speed actually has other representations in the vehicle-side system, and it does not exist alone but may be defined as being in structured data together with other signal types. By serializing the underlying interface communication data into a byte stream, the data format can be standardized so that different component modules can interact and process data in a consistent manner.

[0060] Subsequently, after the corresponding vehicle-side signal set is retrieved, the retrieved byte stream data is converted back into readable structured data through the deserialization operation 22, so as to locate the specific signal name of the vehicle-side signal required for parsing the collection rule in the vehicle-side signal set, and extract the corresponding signal value. For example, the signal names of the specific signals captured from the vehicle-side signal set are defined in the script as signal1, signal2, and signal3. With the help of appropriate serialization tools (such as Protobuf), the signal name "signal1" of the vehicle-side signal required for the collection rule can be located in the vehicle-side signal set (for example, through descriptor->FindFieldByName(signal1)), and then the signal value corresponding to the signal name "signal1" can be extracted (for example, through reflection->GetString(signal1)). By analogy, a similar process can also be implemented for the captured signals signal2 and signal3. After obtaining the corresponding signal values, they can be used for logical judgment in the collection rules, so as to control the vehicle to perform the collection action when the corresponding conditions are met.

[0061] It should be pointed out that although the general process of serialization and deserialization is introduced above by way of Protobuf, in actual vehicle applications, the serialization and deserialization mechanisms provided by the ROS framework or the Autosar framework can also be used. These mechanisms are similar to Protobuf in basic principles, but in terms of specific implementation and use, since they are tailored for their respective frameworks, they differ in definition and operation details and need to be adapted to the corresponding frameworks.

[0062] Figure 3 A flow chart of a method for updating vehicle-side data collection function applied to a server according to an exemplary embodiment of the present application is shown. The method includes steps S10 and S20, and also includes optional steps S12 and S14.

[0063] In step S10, according to the update requirements of the vehicle-side data collection function, a script and / or configuration including collection rules is generated, wherein the collection rules specify the collection of relevant scene data to be triggered under a predetermined collection scenario.

[0064] According to the update requirements of the vehicle-side data collection function, the development team first writes scripts / configurations to implement new functions or improvements. These scripts / configurations contain collection rules, which are used to trigger data collection in specific collection scenarios.

[0065] The update requirements include, but are not limited to: collecting sensor data in specific scenarios or specific types for autonomous driving functions, recording vehicle performance data in specific driving modes, or capturing real-time vehicle status information and environmental information when abnormal driving behavior is detected. Through these update requirements, it is ensured that the collected data can support key tasks such as function development, performance optimization and fault diagnosis.

[0066] As mentioned above, the vehicle can actively request updates from the server and then receive the scripts and / or configurations issued, or the server can actively push necessary updates based on real-time monitoring and analysis results.

[0067] In optional step S12, the written script and / or configuration is verified and released on the server side. For example, the script / configuration can be unit tested and interface tested. Unit testing focuses on verifying the functionality of a single module or function in the script to ensure that each part runs as expected. Interface testing evaluates the interaction between the script and other system components of the vehicle (such as databases, services, or hardware interfaces) to ensure the accuracy of data communication and exchange. These tests focus more on the correctness and functionality at the code level and are usually completed by the development team during the development cycle to ensure the quality of the code. For example, only when the scripts and configurations pass these tests successfully are they allowed to be verified and released to ensure that the updated collection rules are reliable and effective before actual deployment.

[0068] In optional step S14, the script and / or configuration is subjected to real vehicle testing and simulation testing. Simulation testing is performed in a simulated environment, using software models to reproduce the operating environment and behavior of the vehicle, allowing testers to evaluate the performance and functionality of the script / configuration without the need for a real vehicle, including performance under different conditions such as extreme weather and traffic congestion. Real vehicle testing is performed on a real vehicle to verify the performance of the script / configuration in the actual driving environment and provide the most realistic data. Real vehicle testing is a crucial step in the verification process because it is directly related to the safety and functional performance of the vehicle. Therefore, for example, it can be stipulated that the test is considered to have passed at least if the real vehicle test is successful.

[0069] In one embodiment, step S20 is performed only when the release script / configuration has been successfully verified in step S12 and has passed the test in step S14. In step S20, the generated script and / or configuration is sent to the vehicle to update the vehicle-side data collection function.

[0070] Figure 4 A schematic diagram of a vehicle 1 and a server 5 according to an exemplary embodiment of the present application is shown.

[0071] In this embodiment, the communication between the vehicle 1 and the server 5 follows the vehicle-cloud data interaction specification. The vehicle 1 can establish a connection with the cloud platform 5 using a 4G or 5G network, for example. The cloud platform 5 responds to the function request of the vehicle 1 or actively sends a script / configuration to the vehicle 1, and the vehicle 1 executes these suggestions according to its own state to achieve the update of the vehicle-side data collection function.

[0072] Server 5 can be a server deployed in the cloud or a dedicated server set up in the data center of the vehicle manufacturer. In addition, server 5 can also be an edge server or a local server deployed near vehicle 1. Server 5 includes a generation unit 51 and a sending unit 52. The generation unit 51 is used to generate a script and / or configuration containing collection rules according to the update requirements of the vehicle-side data collection function. The collection rules specify the collection of relevant scene data triggered under a predetermined collection scenario. The sending unit 52 is used to send the generated script and / or configuration to vehicle 1 so as to update the vehicle-side data collection function. Regarding the generation and distribution of scripts / configurations, it has been described in detail in the previous section. Figure 3 The relevant methods are described in detail in the text, which will not be repeated here for the sake of brevity.

[0073] Vehicle 1, for example, refers to a customer vehicle that has been sold and used by a user, and includes, for example, a receiving unit 100, a parsing unit 200, and an execution unit 300. The receiving unit 100 is used to receive a script and / or configuration containing collection rules sent by the server 5, wherein the collection rules specify triggering the collection of relevant scene data under a predetermined collection scenario. The parsing unit 200, for example, includes an interpreter, so that the received script and / or configuration can be parsed with the aid of the interpreter to convert the collection rules contained in the script and / or configuration into collection instructions executable on the vehicle side. The execution unit 300 is used to execute vehicle-side data collection operations according to the converted collection instructions. The process of receiving, parsing, and executing the script / configuration and vehicle-side data collection operations has been described in detail. Figure 1 to Figure 2 The relevant methods are described in detail in the text, which will not be repeated here for the sake of brevity.

[0074] Although the specific embodiments of the present application are described in detail herein, they are provided for the purpose of explanation only and should not be considered to limit the scope of the present application. Various substitutions, changes and modifications may be conceived without departing from the spirit and scope of the present application.

Claims

1. A method for updating a vehicle-side data collection function, the method being applied to a vehicle-side (1), the method comprising the following steps: Step S100, receiving a script and / or configuration containing collection rules sent by the server (5), wherein the collection rules specify triggering the collection of relevant scene data under a predetermined collection scene; Step S200, parsing the received script and / or configuration with the aid of an interpreter to convert the collection rules contained in the script and / or configuration into collection instructions executable by the vehicle end (1); as well as Step S300, executing the vehicle-side data collection operation according to the converted collection instruction.

2. The method according to claim 1, wherein: The collection rules include at least one of the following: In the scenario where the vehicle fails to park automatically, trigger the vehicle-side data collection related to automatic parking; In the scenario where the vehicle ahead performs emergency braking, trigger the vehicle-side data collection related to emergency braking; and / or In the scenario of a vehicle collision, the vehicle-side data collection related to the collision is triggered.

3. The method according to claim 1 or 2, wherein: The corresponding interpreter is dynamically selected based on the file type received from the server (5): When receiving a configuration from a server (5), parsing the configuration using a customized interpreter, the customized interpreter being implemented to follow interpretation rules associated with the configuration; When a script is received from a server (5), the script is parsed using an interpreter corresponding to the script language of the script.

4. The method according to any one of claims 1 to 3, wherein: The step S200 comprises: performing serialization (21) and deserialization (22) on the underlying interface communication data at the vehicle side (1) so as to dynamically load and dynamically parse the vehicle side signals required by the acquisition rules, wherein at the vehicle side (1), Protobuf is used as a serialization tool, and / or a serialization and deserialization method provided by a ROS framework and / or an Autosar framework is used.

5. The method according to claim 4, wherein: On the vehicle side (1), serialization (21) and deserialization (22) are performed in the following way: The vehicle-side bottom layer interface communication data is serialized (21) to retrieve a vehicle-side signal set including the vehicle-side signals required by the collection rule; as well as The vehicle-side signal set is deserialized (22) to locate the signal name of the vehicle-side signal required by the acquisition rule in the vehicle-side signal set, and extract the signal value corresponding to the signal name.

6. A method for updating a vehicle-side data collection function, the method being applied to a server side (5), the method comprising the following steps: Step S10, generating a script and / or configuration including collection rules according to the update requirements of the vehicle-side data collection function, wherein the collection rules specify triggering the collection of relevant scene data under a predetermined collection scene; as well as Step S20, sending the generated script and / or configuration to the vehicle (1) to update the vehicle-side data acquisition function.

7. The method according to claim 6, wherein: The method further comprises the following steps: Step S12, verifying and publishing the script and / or configuration, wherein if the script and / or configuration passes the unit test and the interface test, the verification and publishing of the script and / or configuration is permitted; Step S14, performing a real vehicle test and a simulation test on the script and / or configuration, wherein the test is considered to have passed only when the real vehicle test is successful; If the verification is released and the test is passed, step S20 is executed.

8. A vehicle (1), the vehicle (1) being configured to perform the method according to any one of claims 1 to 5, the vehicle (1) comprising: A receiving unit (100) configured to receive a script and / or configuration containing a collection rule sent by a server (5), wherein the collection rule specifies triggering the collection of relevant scene data under a predetermined collection scene; A parsing unit (200) configured to parse the received script and / or configuration with the aid of an interpreter, so as to convert the collection rules contained in the script and / or configuration into collection instructions executable by the vehicle end (1); as well as The execution unit (300) is configured to execute the vehicle-side data collection operation according to the converted collection instruction.

9. A server (5), the server (5) being configured to execute the method according to claim 6 or 7, the server (5) comprising: A generating unit (51) is configured to generate a script and / or configuration containing a collection rule according to an update requirement of the vehicle-side data collection function, wherein the collection rule specifies triggering the collection of relevant scene data under a predetermined collection scene; as well as A sending unit (52) is configured to send the generated script and / or configuration to the vehicle (1) so as to update the vehicle-side data collection function.

10. A computer program product comprising computer program instructions, wherein: The computer program instructions, when executed by a processor, enable the processor to perform a method according to any one of claims 1 to 7.

Images