Vehicle control method, apparatus and system

Abstract

A vehicle control method, an apparatus and a system. A first server can acquire a first data packet from a first vehicle, the first data packet comprising a first identifier, first data and second data, the first data being used for representing an abnormal road condition on a first driving path of the first vehicle, and the second data being used for representing an avoidance operation of the first vehicle with respect to the abnormal road condition; a second vehicle is determined, the second vehicle being a vehicle of a second vehicle model, and an intelligent configuration corresponding to the second vehicle model being inferior to an intelligent configuration corresponding to a first vehicle model associated with the first identifier; and third data is sent to the second vehicle. The method can provide a standardized data sharing mode applicable to Internet of Vehicles scenarios, such that an intelligent driving sensing and recognition capability of a high-configuration vehicle can be shared with a low-configuration vehicle, thereby improving the driving comfort and safety of the low-configuration vehicle, and improving the competitiveness of vehicles having different configurations.

Description

A vehicle control method, device and system Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a vehicle control method, device and system. Background Technology

[0002] Currently, the driving safety of intelligent vehicles relies on the perception and recognition capabilities of the advanced driver assistance systems (ADAS) installed in the vehicle. For example, if the vehicle is equipped with an automatic emergency braking (AEB) system, AEB will control the vehicle to brake suddenly to avoid a collision in the event of an emergency collision risk. Or, for example, the vehicle's ADAS can detect in advance the presence of other vehicles slowing down or obstacles around the vehicle, and take evasive control measures such as slowing down or detouring to prevent the vehicle from being involved in a collision, thereby ensuring the safety of the vehicle and the lives and property of the driver and passengers.

[0003] However, the intelligent driving capabilities of different models from the same automaker or different models from different automakers vary, and their ability to recognize safety events or road conditions differs. Only some models can use pure vehicle-side intelligent driving assistance capabilities to handle certain vehicle situations well. Models without intelligent driving capabilities or with insufficient intelligent driving capabilities are not capable enough to avoid certain safety events or poor road conditions. Summary of the Invention

[0004] This application provides a vehicle control method, device, and system for providing a standardized data sharing method suitable for vehicle networking scenarios, enabling the intelligent driving perception and recognition capabilities of high-configuration vehicles to be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations.

[0005] Firstly, this application provides a vehicle control method, which can be implemented by a first server. The method includes: acquiring a first data packet from a first vehicle, the first data packet including a first identifier, first data, and second data, wherein the first data is used to characterize abnormal road conditions on a first driving path of the first vehicle, and the second data is used to characterize the first vehicle's avoidance operation of the abnormal road conditions; determining a second vehicle, wherein the second vehicle is a vehicle of a second model, and the intelligent configuration corresponding to the second model is weaker than the intelligent configuration corresponding to the first model associated with the first identifier; and sending the third data to the second vehicle. Exemplarily, the first server is a server of a first telematics service provider (TSP), which can provide telematics services to the second vehicle.

[0006] Using the above method, the first server can determine the third data to be sent to the second vehicle based on the first data packet reported by the high-configuration vehicle (or high-end vehicle), so as to guide the low-configuration vehicle to realize intelligent driving control, thereby achieving the goal of sharing the high-end intelligent assisted driving of the high-configuration vehicle with the low-configuration vehicle, improving the driving comfort and safety of the low-configuration vehicle, and enhancing the competitiveness of vehicles with different configurations.

[0007] In conjunction with the first aspect, in one possible implementation, the first data includes information about the location of the abnormal road condition, and the method further includes: obtaining the driving paths of multiple vehicles of the second vehicle type; determining the second vehicle includes: determining the second vehicle based on the first vehicle type associated with the first identifier, the location of the abnormal road condition, and the driving paths of multiple vehicles of the second vehicle type, wherein the second driving path of the second vehicle includes the location of the abnormal road condition; sending the third data to the second vehicle includes: sending the third data to the second vehicle before the second vehicle passes through the location of the abnormal road condition.

[0008] Using the above method, the first server can combine the location of abnormal road conditions with the driving paths of numerous vehicles of the second model to send anomaly alerts to low-configuration vehicles that are about to pass through the abnormal road condition location.

[0009] In conjunction with the first aspect, in one possible implementation, the first data packet further includes first-level information, which indicates the execution capability level corresponding to the first vehicle's avoidance operation of the abnormal road condition. The method further includes: obtaining execution capability level information of multiple vehicles of the second vehicle type; determining the second vehicle includes: determining the second vehicle that matches the first-level information based on the execution capability level information of the first vehicle type associated with the first identifier and the multiple vehicles of the second vehicle type.

[0010] In conjunction with the first aspect, in one possible implementation, the method further includes: receiving subscription messages from multiple vehicles of the second vehicle type, the subscription messages being used to subscribe to an abnormal traffic condition alarm service from the first server; determining the second vehicle includes: determining the second vehicle subscribing to the abnormal traffic condition alarm service based on the subscription messages from multiple vehicles of the first vehicle type associated with the first identifier and the second vehicle type.

[0011] In conjunction with the first aspect, in one possible implementation, the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model, specifically including: the intelligent driving assistance capability level of the second vehicle model is lower than that of the first vehicle model.

[0012] In conjunction with the first aspect, in one possible implementation, the first data includes perception data obtained through a first sensor mounted on the first vehicle, wherein the intelligent configuration corresponding to the second vehicle model is weaker than the intelligent configuration corresponding to the first vehicle model. Specifically, this includes: the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any of the following: the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any of the following: the first vehicle is equipped with the first sensor, while the second vehicle is not equipped with the first sensor; the number of first sensors mounted on the first vehicle is greater than the number of first sensors mounted on the second vehicle; the perception accuracy of the first sensor mounted on the first vehicle is higher than the perception accuracy of the first sensor mounted on the second vehicle.

[0013] In conjunction with the first aspect, in one possible implementation, the first sensor includes at least one of the following: a camera, a lidar, a millimeter-wave radar, and an ultrasonic radar.

[0014] In conjunction with the first aspect, in one possible implementation, the second data includes vehicle state data obtained by a second sensor mounted on the first vehicle, wherein the second sensor includes an inertial measurement unit (IMU).

[0015] In conjunction with the first aspect, in one possible implementation, the second data includes the acceleration of the first vehicle in at least one dimension when it avoids the abnormal road conditions, the at least one dimension including at least one of the lateral, longitudinal, or vertical directions of the vehicle body.

[0016] In conjunction with the first aspect, in one possible implementation, the first vehicle and the second vehicle correspond to the same vehicle-to-everything (V2X) service provider (TSP), the first server is the server of the TSP for both the first vehicle and the second vehicle, and the step of obtaining the first data packet from the first vehicle includes: receiving the first data packet from the first vehicle.

[0017] In conjunction with the first aspect, in one possible implementation, the first vehicle and the second vehicle correspond to different TSPs, and the acquisition of the first data packet from the first vehicle includes: receiving the first data packet forwarded by a second server via an interconnection service, wherein the second server is the server of the TSP of the first vehicle, and the first server is the server of the TSP of the second vehicle.

[0018] In conjunction with the first aspect, in one possible implementation, the method further includes: sending the first data packet to a third server via an interconnection service, the third server being used to send fourth data determined according to the first data packet to a third vehicle, the first server being a TSP server for the first vehicle, the third server being a TSP server for the third vehicle, the third vehicle being a vehicle of a third model, and the intelligent configuration corresponding to the third model being weaker than the intelligent configuration corresponding to the first model.

[0019] Secondly, this application provides a vehicle control method applied to a second vehicle. The method includes: receiving third data from a first server, wherein the third data is determined by the first server based on a first data packet from the first vehicle, the first vehicle being a first model vehicle, and the intelligent configuration of the second vehicle corresponding to a second model vehicle being weaker than the intelligent configuration of the first model vehicle; and controlling the second vehicle to drive according to the third data.

[0020] In conjunction with the second aspect, in one possible implementation, the second driving path of the second vehicle includes the location of the abnormal road condition detected by the first vehicle, and the receiving of the third data from the first server includes: receiving the third data from the first server before the second vehicle passes through the location of the abnormal road condition.

[0021] In conjunction with the second aspect, in one possible implementation, the first server is the server of the TSP of the second vehicle, and the method further includes: sending the execution capability level information of the second vehicle to the first server.

[0022] In conjunction with the second aspect, in one possible implementation, the method further includes: sending a subscription message to the first server, the subscription message being used to subscribe to an abnormal traffic condition alarm service from the first server.

[0023] In conjunction with the second aspect, in one possible implementation, the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model, specifically including: the intelligent driving assistance capability level of the second vehicle model is lower than that of the first vehicle model.

[0024] In conjunction with the second aspect, in one possible implementation, the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model. Specifically, the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any of the following: the first vehicle is equipped with the first sensor, while the second vehicle is not equipped with the first sensor; the number of the first sensors equipped on the first vehicle is greater than the number of the first sensors equipped on the second vehicle; the perception accuracy of the first sensor equipped on the first vehicle is higher than the perception accuracy of the first sensor equipped on the second vehicle.

[0025] In conjunction with the second aspect, in one possible implementation, the first sensor includes at least one of the following: a camera, a lidar, a millimeter-wave radar, and an ultrasonic radar.

[0026] Thirdly, this application provides a vehicle control device, comprising: an acquisition unit, configured to acquire a first data packet from a first vehicle, the first data packet including a first identifier, first data, and second data, the first data being used to characterize abnormal road conditions on a first driving path of the first vehicle, and the second data being used to characterize the first vehicle's avoidance operation of the abnormal road conditions; a determination unit, configured to determine a second vehicle based on a first vehicle model associated with the first identifier, wherein the second vehicle is a vehicle of a second vehicle model, and the intelligent configuration corresponding to the second vehicle model is weaker than the intelligent configuration corresponding to the first vehicle model; and to determine third data based on the intelligent configuration corresponding to the second vehicle model and the second data, the third data being associated with the second vehicle's avoidance operation of the abnormal road conditions; and a sending unit, configured to send the third data to the second vehicle.

[0027] In conjunction with the third aspect, in one possible implementation, the first data includes information about the location of abnormal road conditions, and the acquisition unit is further configured to: acquire the driving paths of multiple vehicles of the second vehicle type; the determination unit is specifically configured to: determine the second vehicle based on the first vehicle type associated with the first identifier, the location of abnormal road conditions, and the driving paths of multiple vehicles of the second vehicle type, wherein the second driving path of the second vehicle includes the location of abnormal road conditions; the sending unit is configured to: send the third data to the second vehicle before the second vehicle passes through the location of abnormal road conditions.

[0028] In conjunction with the third aspect, in one possible implementation, the first data packet further includes first-level information, which indicates the execution capability level corresponding to the first vehicle's avoidance operation of the abnormal road conditions. The acquisition unit is further configured to: acquire the execution capability level information of multiple vehicles of the second vehicle type; the determination unit is specifically configured to: determine the second vehicle that matches the first-level information based on the execution capability level information of the first vehicle type associated with the first identifier and the multiple vehicles of the second vehicle type.

[0029] In conjunction with the third aspect, in one possible implementation, the apparatus further includes: a receiving unit, configured to receive subscription messages from multiple vehicles of the second vehicle type, the subscription messages being used to subscribe to an abnormal traffic alert service from the first server; the determining unit is specifically configured to: determine the second vehicle subscribing to the abnormal traffic alert service based on the subscription messages of the first vehicle type associated with the first identifier and the multiple vehicles of the second vehicle type.

[0030] In conjunction with the third aspect, in one possible implementation, the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model, specifically including: the intelligent driving assistance capability level of the second vehicle model is lower than that of the first vehicle model.

[0031] In conjunction with the third aspect, in one possible implementation, the first data includes perception data obtained through a first sensor mounted on the first vehicle, wherein the intelligent configuration corresponding to the second vehicle model is weaker than the intelligent configuration corresponding to the first vehicle model. Specifically, this includes: the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any one of the following: the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any one of the following: the first vehicle is equipped with the first sensor, while the second vehicle is not equipped with the first sensor; the number of first sensors mounted on the first vehicle is greater than the number of first sensors mounted on the second vehicle; the perception accuracy of the first sensor mounted on the first vehicle is higher than the perception accuracy of the first sensor mounted on the second vehicle.

[0032] In conjunction with the third aspect, in one possible implementation, the first sensor includes at least one of the following: a camera, a lidar, a millimeter-wave radar, and an ultrasonic radar.

[0033] In conjunction with the third aspect, in one possible implementation, the second data includes vehicle state data obtained by a second sensor mounted on the first vehicle, wherein the second sensor includes an inertial measurement unit (IMU).

[0034] In conjunction with the third aspect, in one possible implementation, the second data includes the acceleration of the first vehicle in at least one dimension when it avoids the abnormal road conditions, the at least one dimension including at least one of the lateral, longitudinal, or vertical directions of the vehicle body.

[0035] In conjunction with the third aspect, in one possible implementation, the first vehicle and the second vehicle correspond to the same vehicle-to-everything (V2X) service provider (TSP), the first server is the server of the TSP for both the first vehicle and the second vehicle, and the acquisition unit is specifically used to: receive a first data packet from the first vehicle.

[0036] In conjunction with the third aspect, in one possible implementation, the first vehicle and the second vehicle correspond to different TSPs, and the acquisition unit is configured to: receive the first data packet forwarded by a second server via an interconnection service, wherein the second server is the server of the TSP of the first vehicle, and the first server is the server of the TSP of the second vehicle.

[0037] In conjunction with the third aspect, in one possible implementation, the sending unit is further configured to: send the first data packet to a third server via an interconnection service, the third server being configured to send fourth data determined according to the first data packet to a third vehicle, the first server being a TSP server for the first vehicle, the third server being a TSP server for the third vehicle, the third vehicle being a vehicle of a third model, and the intelligent configuration corresponding to the third model being weaker than the intelligent configuration corresponding to the first model.

[0038] Fourthly, this application provides a vehicle control device, comprising: a receiving unit for receiving third data from a first server, wherein the third data is determined by the first server based on a first data packet from a first vehicle, the first vehicle being a first model vehicle, and the intelligent configuration of a second model vehicle of the second vehicle being weaker than the intelligent configuration of the first model vehicle; and a control unit for controlling the second vehicle to drive based on the third data.

[0039] In conjunction with the fourth aspect, in one possible implementation, the second driving path of the second vehicle includes the location of the abnormal road condition detected by the first vehicle, and the receiving unit is configured to: receive the third data from the first server before the second vehicle passes through the abnormal road condition location.

[0040] In conjunction with the fourth aspect, in one possible implementation, the first server is the server of the TSP of the second vehicle, and the method further includes: sending the execution capability level information of the second vehicle to the first server.

[0041] In conjunction with the fourth aspect, in one possible implementation, the apparatus further includes: a sending unit, configured to send a subscription message to the first server, the subscription message being used to subscribe to an abnormal traffic condition alarm service from the first server.

[0042] In conjunction with the fourth aspect, in one possible implementation, the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model, specifically including: the intelligent driving assistance capability level of the second vehicle model is lower than that of the first vehicle model.

[0043] In conjunction with the fourth aspect, in one possible implementation, the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model. Specifically, the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any of the following: the first vehicle is equipped with the first sensor, while the second vehicle is not equipped with the first sensor; the number of the first sensors equipped on the first vehicle is greater than the number of the first sensors equipped on the second vehicle; the perception accuracy of the first sensor equipped on the first vehicle is higher than the perception accuracy of the first sensor equipped on the second vehicle.

[0044] In conjunction with the fourth aspect, in one possible implementation, the first sensor includes at least one of the following: a camera, a lidar, a millimeter-wave radar, and an ultrasonic radar.

[0045] Fifthly, this application provides a communication device including at least one processor and an interface circuit, wherein the interface circuit is used to provide data or code instructions to the at least one processor, and the at least one processor is used to implement the method as described in the first aspect and any possible design of the first aspect through logic circuits or executing code instructions, or to implement the method as described in the second aspect and any possible design of the second aspect.

[0046] In a sixth aspect, this application provides a communication system including a server for implementing the method as described in the first aspect and any possible design of the first aspect, and a first vehicle and a second vehicle, the second vehicle being used to implement the method as described in the second aspect and any possible design of the second aspect.

[0047] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the method as described in the first aspect and any possible design of the first aspect, or to perform the method as described in the second aspect and any possible design of the second aspect.

[0048] Eighthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method as described in the first aspect and any possible design of the first aspect, or to perform the method as described in the second aspect and any possible design of the second aspect.

[0049] Based on the implementations provided in the above aspects, the embodiments of this application can be further combined to provide more implementations.

[0050] The technical effects that can be achieved by any possible implementation of any of the second to eighth aspects mentioned above can be described with reference to the technical effects that can be achieved by any possible implementation of the first aspect mentioned above, and the repetitions will not be discussed. Attached Figure Description

[0051] Figure 1 illustrates a schematic diagram of an application scenario applicable to the embodiments of this application;

[0052] Figure 2 shows a schematic diagram of the system architecture applicable to the embodiments of this application;

[0053] Figure 3 shows a schematic diagram of the system architecture applicable to the embodiments of this application;

[0054] Figure 4 shows a schematic diagram of the system architecture applicable to the embodiments of this application;

[0055] Figure 5 shows a schematic flowchart of the vehicle control method according to an embodiment of this application;

[0056] Figure 6 shows a schematic diagram of the data packet format according to an embodiment of this application;

[0057] Figure 7 shows a schematic diagram of the data packet format according to an embodiment of this application;

[0058] Figure 8 shows a schematic flowchart of a vehicle control method according to an embodiment of this application;

[0059] Figure 9 shows a schematic diagram of the modular structure of the system according to an embodiment of this application;

[0060] Figure 10 shows a schematic diagram of the structure of a communication device according to an embodiment of this application;

[0061] Figure 11 shows a schematic diagram of the structure of another communication device according to an embodiment of this application. Detailed Implementation

[0062] This application provides a vehicle control method, apparatus, and system, which offer a standardized data sharing approach suitable for vehicle-to-everything (V2X) scenarios. This allows the intelligent driving perception and recognition capabilities of high-configuration vehicles to be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations. The method and apparatus are based on the same technical concept. Since the principles by which the method and apparatus solve problems are similar, their implementations can be mutually referenced, and repeated details will not be elaborated upon. Furthermore, in the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0063] The vehicle control scheme in this application embodiment can be applied to vehicle-to-everything (V2X), long-term evolution-vehicle (LTE-V), and vehicle-to-vehicle (V2V) communication technologies. For example, it can be applied to vehicles with driving mobility functions, or other devices within a vehicle with driving mobility functions. These other devices include, but are not limited to, on-board terminals, on-board control units, on-board modules, on-board components, on-board chips, on-board units, on-board radar, or on-board cameras, and other sensors. Vehicles can implement the vehicle control method provided in this application embodiment through these on-board terminals, on-board control units, on-board modules, on-board components, on-board chips, on-board units, on-board radar, or on-board cameras. Of course, the control scheme in this application embodiment can also be used in other intelligent terminals with mobility control functions besides vehicles, or installed in other intelligent terminals with mobility control functions besides vehicles, or installed in components of such intelligent terminals. These intelligent terminals can be intelligent transportation equipment, smart home devices, robots, etc. Examples include, but are not limited to, smart terminals or control units, chips, radar or cameras, and other sensors and components within smart terminals.

[0064] In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0065] Furthermore, unless otherwise specified, the ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are used to distinguish multiple objects and are not used to limit the priority or importance of multiple objects. For example, "first vehicle" and "second vehicle" are only used to distinguish different vehicles, and do not indicate that the two types of vehicles have different priorities or importance.

[0066] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0067] Figure 1 illustrates a schematic diagram of an application scenario applicable to the embodiments of this application. In this application scenario, a server 100 and at least one vehicle 200 may be included, denoted as 200_1, 200_2, 200_3, ..., 200_n, where n is an integer greater than or equal to 2. Different vehicles 200 can communicate with the server 100 via a network. In an optional implementation, different vehicles can communicate with each other using V2X technology.

[0068] For any vehicle 200, some or all of its functions are controlled by a computing platform 210. The computing platform 210 may include at least one processor 211, which may be any conventional processor, such as a central processing unit (CPU). Alternatively, the processor 211 may also include a graphics processing unit (GPU), a field-programmable gate array (FPGA), a system-on-chip (SoC), an application-specific integrated circuit (ASIC), or a combination thereof. The processor 211 may execute instructions 213 stored in a computer-readable medium such as memory 212.

[0069] In some embodiments, the computing platform 210 may also be multiple computing devices that control individual components or subsystems of the vehicle 200 in a distributed manner. As shown in FIG2, the vehicle 200 may include, for example, an electronic control unit (ECU) such as an in-vehicle terminal 220, a human-machine interaction (HMI) 230, a body domain controller 240, a cockpit domain controller 250, and a vehicle sensing system 260, as well as an in-vehicle communication network (e.g., CAN bus) for realizing in-vehicle communication. It should be understood that this is only an example of an ECU and not any limitation. In other embodiments, the vehicle may also include ECUs such as a powertrain domain controller 270, a chassis domain controller 280, an intelligent system domain controller, and an autonomous driving domain controller, which will not be described in detail here.

[0070] The vehicle-mounted terminal 220 can serve as an intermediary device between external devices such as the server 100 and mobile terminal 300 and the vehicle's internal ECUs, enabling data processing capabilities related to the vehicle control method of this application embodiment. Inside the vehicle 200, the vehicle-mounted terminal 220 can transmit data with each ECU via the in-vehicle communication network. It should be understood that in this application embodiment, the communication method between the vehicle-mounted terminal 220 and the server 100 or mobile terminal 300 can include wired or wireless communication, and this application embodiment does not limit this.

[0071] The in-vehicle terminal 220, acting as the decision-making unit within the vehicle 200, can acquire at least one type of intelligent driving data from various ECUs within the vehicle via the in-vehicle bus. This data includes, for example, information input by the user at any HMI, status data of vehicle components associated with each ECU, perception data obtained from the vehicle sensing system 260 (e.g., environmental data, other vehicle data, road condition data), and relevant information from other ECUs. The terminal then makes a comprehensive decision and provides relevant intelligent driving data to the server 100 as needed, facilitating the server 100's sharing of the intelligent driving perception capabilities of high-configuration vehicles with low-configuration vehicles. This will be illustrated with examples below and will not be elaborated upon here.

[0072] The vehicle-mounted terminal 220 can be a different unit module from the network communication device (not shown), or it can be the same unit module, such as a telematics box (T-BOX), which can integrate functional modules such as GPS, external communication interface, ECU, microcontroller, mobile communication unit, and memory. Internally, the T-BOX can connect to the vehicle bus (i.e., the vehicle's internal communication network, such as CAN bus); externally, it can achieve information interaction between the vehicle terminal, handheld device, RSU, and public networks using V2V, V2R, V2H, V2S, etc., through a cloud platform. Alternatively, the vehicle-mounted terminal 220 can be a newly added hardware module in the vehicle, which can be configured with relevant judgment logic or algorithms. It can function as an ECU in the vehicle 200, transmitting information with other ECUs through the vehicle's internal communication network to implement the method of this application embodiment. This application embodiment does not limit the product form of the vehicle-mounted terminal 220.

[0073] The vehicle sensing system 260 may include sensors such as cameras and radar. The system can acquire sensing data from inside or outside the vehicle and provide this data to the vehicle-mounted terminal 220, which then provides the data to the server 100. Alternatively, the system can directly provide the sensing data to the server 100 for comprehensive decision-making.

[0074] The HMI 230 is an input / output device within the vehicle 200. The HMI 230 can communicate with the vehicle terminal 220 via the in-vehicle communication network and provides an operating interface for outputting instruction information, receiving input information, etc. The HMI 230 can also provide the acquired input information to the vehicle terminal or other modules. For example, the HMI 230 may include in-vehicle devices such as an in-vehicle display screen (e.g., a touchscreen), or external connected devices such as smartphones or tablets located within the vehicle 200; this embodiment does not limit the scope of the application.

[0075] The mobile terminal 300 can be a smartphone, tablet, or similar device. The mobile terminal 300 can interact with the server 100 via a network, and can also communicate with the in-vehicle terminal 220 and the network communication device of the vehicle 200 via a network. For example, the mobile terminal 300 can have an application installed and running for vehicle management. The vehicle owner (e.g., the vehicle owner) or authorized user of the vehicle can manage the vehicle 200 through the application running on their respective mobile terminals, and can configure vehicle networking services for the vehicle through communication with the server 100. For example, a user can subscribe to intelligent driving data reporting services, notification services, and abnormal road condition alarm services from the server 100 by interacting with at least one of the aforementioned HMI 230 and mobile terminal 300. Alternatively, for example, at least one of the aforementioned HMI 230 and mobile terminal 300 can act as an output device to output reminder information from the server 100, which can be used to guide the vehicle to drive more safely and intelligently. Examples will be provided below, and details will not be elaborated here.

[0076] It should be understood that in this embodiment of the application, the communication method between the vehicle terminal 220 and the server 100 or the mobile terminal 300 may include wired communication or wireless communication, and this embodiment of the application does not limit this.

[0077] In addition to instructions 213, memory 212 may also store data such as road maps, route information, vehicle position, direction, speed, and other vehicle data, as well as other information. This information can be used by vehicle 200 and computing platform 210 during operation of vehicle 200 in autonomous, semi-autonomous, and / or manual modes.

[0078] Among them, manual mode is the manual driving mode, which refers to the mode in which the vehicle completes driving tasks under the direct operation of a human driver. Autonomous mode is the automatic driving mode, which refers to the mode in which the vehicle completes driving tasks autonomously by the automatic driving system installed in the vehicle without the need for direct operation of a human driver. Semi-autonomous mode is the intelligent assisted driving mode, which refers to the mode in which the intelligent assisted driving system installed in the vehicle assists the human driver in completing driving tasks.

[0079] For vehicles that support intelligent driving mode or autonomous driving mode, intelligent driving assistance system (hereinafter referred to as intelligent driving system) is usually deployed on the vehicle's computing platform 210. The intelligent driving system has intelligent driving perception and recognition function. It detects the surrounding environment of the vehicle through at least one sensor installed on the vehicle, and through the processing and calculation of various perception data, it identifies various risk scenarios that exist in the vehicle driving in advance, and controls the vehicle to complete driving avoidance operations to deal with various risks, such as deceleration and detour, so as to avoid affecting the vehicle property and the life safety of the occupants.

[0080] Generally, based on the different configurations of the intelligent driving systems equipped in vehicles, they can be categorized into the following levels:

[0081] (1) Level 1 Driving Assistance: Primarily provides basic driving assistance functions, such as adaptive cruise control (ACC) and lane keeping assist (LKA). ACC automatically adjusts the vehicle's speed based on the speed of the vehicle in front to maintain a preset safe distance. LKA uses cameras or sensors to monitor whether the vehicle is deviating from its lane and corrects it when necessary to keep the vehicle within the lane and prevent traffic accidents.

[0082] (2) Level 2 Partial Automated Driving: Building upon Level 1, this adds more automated functions, including automatic parking assist (APA), traffic sign recognition (TSR), and blind spot monitoring (BSM). Level 2 driver assistance systems can simultaneously control the steering wheel and acceleration / deceleration, requiring the driver to focus on the remaining driving actions. Common Level 2 configurations include adaptive cruise control (ACC), road safety assist (LKA), and automatic emergency braking (AEB). These functions can automate driving tasks to a certain extent, but the driver still needs to maintain control and attention over the vehicle.

[0083] (3) Level 3 Conditional Automated Driving: Level 3 assisted driving means that the vehicle can complete all driving operations under specific driving environments and traffic conditions, such as acceleration, braking, and steering. The driver does not need to operate the car, but still needs to remain highly alert and be ready to take over vehicle control at any time when the artificial intelligence cannot accurately judge or when the system issues a request.

[0084] (4) Level 4 Highly Automated Driving: Level 4 assisted driving enables fully automated driving in most road conditions without continuous driver monitoring. The driver can choose whether to participate in the driving process, but must still take over control when necessary. Level 4 vehicles are typically equipped with more advanced sensors, algorithms, and decision-making systems, enabling them to navigate and avoid obstacles autonomously in complex road environments.

[0085] Different levels of intelligent driving rely on different sensors to achieve intelligent driving perception. For example, some intelligent driving functions rely on high-precision cameras, some rely on a combination of multiple cameras (such as 360° panoramic imaging), some rely on lidar installed on the vehicle, and some rely on a combination of high-precision cameras and lidar.

[0086] Both software and hardware configurations can be considered intelligent vehicle features. Due to differences in cost and application scenarios associated with these intelligent configurations, automakers typically produce vehicles with varying configurations to comprehensively cover the diverse needs of users. For example, "high-end models" and "low-end models" can refer to vehicles with different intelligent configurations (e.g., software / hardware). "High-end" can also mean "high-spec," and "low-end" can mean "low-spec." This means that the intelligent configuration of a high-end model is superior to that of a low-end model, or that the software / hardware configuration of a high-end model is superior to that of a low-end model. Alternatively, the intelligent configuration of a low-end model is weaker than that of a high-end model, or that the software / hardware configuration of a low-end model is weaker than that of a high-end model. "Superior" can be replaced with "higher than," "greater than," or "stronger than," and "weaker than" can be replaced with "lower than," "less than," or "inferior to," etc.

[0087] Taking hardware configuration differences as an example, high-end models are equipped with sensors such as LiDAR, while low-end models are not. Or, for example, the number of LiDAR sensors (m) in a high-end model is greater than the number of LiDAR sensors (n) in a low-end model; for example, m is 4 and n is 2. Or, for example, the number of camera sensors in a high-end model is greater than the number in a low-end model; for example, a high-end model has four cameras, enabling 360-degree surround-view detection, while a low-end model has two cameras, located at the front and rear, only capable of detecting what is in front of and behind the vehicle. Or, for example, the resolution of the cameras in a high-end model is higher than that in a low-end model. Or, for example, the accuracy of the radar in a high-end model is higher than that in a low-end model.

[0088] Taking software configuration differences as an example, for instance, high-end models are equipped with Advanced Driver Assistance Systems (ADAS), while low-end models are not. Or, for example, the software version of the ADAS in high-end models is higher than that in low-end models. Or, for example, the accuracy of the intelligent driving algorithms in high-end models is better than that in low-end models. Or, for example, the level of the intelligent driving algorithms in high-end models is higher than that in low-end models. Or, for example, the number of ADAS subsystems in high-end models is greater than that in low-end models. Or, for example, the accuracy of the ADAS subsystems in high-end models is greater than that in low-end models.

[0089] It should be understood that the above are merely examples of differences in the intelligent configurations of different vehicles and do not constitute any limitation. The vehicle structures in Figures 1 and 2 should not be construed as limitations on the embodiments of this application. Optionally, the vehicle 200 described above can be a car, truck, motorcycle, bus, ship, airplane, helicopter, lawnmower, recreational vehicle, amusement park vehicle, construction equipment, tram, golf cart, train, etc., and the embodiments of this application do not impose any particular limitation. In one embodiment, the server 100 described above can also be implemented using a virtual machine.

[0090] In real-world driving scenarios, intelligent vehicles must navigate actual road conditions and control their movement based on intelligent driving perception and calculations. When vehicle speed and the surrounding environment change, differences in intelligent driving capabilities among vehicles can lead to situations where some vehicles cannot mitigate risks in the same road conditions. For example, lower-end models may be unable to perceive certain safety events or poor road conditions, thus failing to avoid abnormal events or road conditions.

[0091] In this regard, one implementation of this application is to provide a standardized data sharing method suitable for vehicle networking scenarios, so that the intelligent driving perception and recognition capabilities of high-configuration vehicles can be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations.

[0092] In practical implementation, server 100 in Figure 1 or Figure 2 can be implemented as a server for a telematics service provider (TSP), as shown in Figure 3. This TSP server can provide telematics services to vehicles 200_1, 200_2, and 200_3. For example, vehicle 200_1 is a high-configuration vehicle. Vehicle 200_1 can use its own configuration (including hardware and / or software configuration) to identify safety events or road conditions, and then combine the relevant intelligent driving data in a standardized manner and upload it to the TSP server. The TSP server can analyze and process the received intelligent driving data and, as needed, send reminder information to low-configuration vehicles such as vehicle 200_2 or vehicle 200_3. This enables low-configuration vehicles to cope with certain safety events or poor road conditions, thereby compensating for the insufficient intelligent driving capabilities of low-configuration vehicles, improving the user experience of users of low-configuration vehicles, and ensuring the product competitiveness of low-configuration vehicles.

[0093] For example, a high-spec vehicle is designated as Vehicle 1, and a low-spec vehicle as Vehicle 2. The server providing vehicle-to-everything (V2X) services to Vehicle 2 is designated as Server 1. Server 1 can obtain a first data packet from Vehicle 1. This first data packet is a standardized encapsulated data packet containing relevant intelligent driving data, which may include, for example, a first identifier, first data, and second data. The first data may be used to characterize abnormal road conditions on Vehicle 1's first driving path, and the second data may be used to characterize Vehicle 1's avoidance actions in response to abnormal road conditions. After analyzing and processing the first data packet, Server 1 can send third data to Vehicle 2. This third data may be associated with Vehicle 2's avoidance actions in response to abnormal road conditions, enabling Vehicle 2 to cope with these abnormal road conditions.

[0094] It should be noted that the TSPs in Figure 3 can be from the same automaker or include TSPs from different automakers. Different automakers can join automotive alliances to jointly negotiate and formulate unified vehicle connectivity service standards, so as to provide standardized and unified protocols for various application areas such as vehicle body, chassis, powertrain, cabin, intelligent driving, and vehicle control, thereby achieving the standardization of vehicle connectivity services.

[0095] Taking server 100 as an example, which includes servers of TSPs from at least two car manufacturers, as shown in Figure 4, the servers of TSPs from different car manufacturers can be represented as TSP-1, TSP-2, and TSP-3, respectively. Different vehicles in the at least two vehicles 200 in Figure 1 can be provided with vehicle networking services by different TSP servers.

[0096] For example, the services provided by any TSP to a corresponding vehicle may include data reporting services, notification services (such as abnormal road condition alerts), and connectivity services. Data reporting services allow vehicles to utilize their rich and accurate sensors for perception and identification (e.g., road condition detection) and intelligent driving control, then standardize and assemble at least one type of data before reporting it to the TSP's server. Notification services allow the TSP's server to send notifications to vehicles, such as alerts about safety events, poor road conditions, and intelligent driving solutions based on perception results. The collaboration of data reporting and notification services can share the perception and identification capabilities of high-configuration vehicles with those of low-configuration vehicles. Connectivity services are implemented through the TSP's connectivity interface, enabling interaction between TSPs from multiple automakers. This allows for cross-automaker / cross-server sharing of the intelligent driving perception and identification capabilities of a high-configuration vehicle from one automaker with a low-configuration vehicle from another automaker.

[0097] Based on the above solutions, for a single automaker, the capabilities of a high-end intelligent driving model can be shared with lower-end models via the same TSP server. This reduces costs by improving the perception and recognition capabilities of lower-end models, thereby enhancing their competitiveness and improving driving comfort and safety. For automotive alliances, connected services allow for the timely and efficient synchronization of the intelligent driving perception and recognition capabilities of a high-end intelligent driving model from one automaker to vehicles from another automaker. This better leverages connectivity to address the identification and automatic avoidance of abnormal road conditions, improving the user experience.

[0098] Taking server 100 in Figure 1, which includes servers TSP-1 and TSP-2, as an example, and referring to Figure 4, servers TSP-1 and TSP-2 can exchange information through interconnection services. Server TSP-1 can provide vehicle networking services to some of the at least two vehicles 200 (e.g., vehicles 200_1, 200_2, and 200_3), and server TSP-2 can provide vehicle networking services to another portion of the at least two vehicles 200 (e.g., vehicles 200_4 and 200_5). In an optional embodiment, server 100 includes server TSP-3, which can provide vehicle networking services to another portion of the at least two vehicles 200 (e.g., vehicle 200_6).

[0099] In one example, the intelligent configuration of vehicle 200_1 may be superior to that of vehicles 200_2, 200_3, 200_4, 200_5, and 200_6. Alternatively, vehicle 200_1 may possess some intelligent configurations that are lacking in vehicles 200_2, 200_3, 200_4, 200_5, and 200_6. The differences in the individual intelligent configurations of vehicles 200_2, 200_3, 200_4, 200_5, and 200_6 are not limited.

[0100] With the authorization of the user (e.g., the owner) of Vehicle 200_1, and in accordance with the relevant agreements of the Auto Union, Vehicle 200_1 can standardize and encapsulate / combine the relevant intelligent driving data and report it to the TSP-1 server.

[0101] On the one hand, the TSP-1 server can process the received intelligent driving data, record abnormal road condition information, and send the abnormal road condition information to other vehicles of the same car manufacturer that need it, such as vehicle 200_2 and vehicle 200_3, so that vehicle 200_2 and vehicle 200_3 can avoid abnormal road conditions or activate other assisted driving functions to achieve safe and comfortable driving.

[0102] On the other hand, the TSP-1 server can synchronize the received intelligent driving data to the connected service. The connected service, according to the Automotive Alliance protocol, can then synchronize this intelligent driving data to the servers of other TSPs, such as the servers of TSP-2 and TSP-3. Similarly, the TSP-2 server can process the received intelligent driving data, record abnormal road condition information, and distribute this information to other vehicles from the same automaker, such as vehicles 200_4 and 200_5, so that vehicles 200_4 and 200_5 can avoid abnormal road conditions or activate other driver assistance functions to achieve safe and comfortable driving. Likewise, the TSP-3 server can process the received intelligent driving data, record abnormal road condition information, and distribute this information to other vehicles from the same automaker, such as vehicle 200_6, so that vehicle 200_6 can avoid abnormal road conditions or activate other driver assistance functions to achieve safe and comfortable driving.

[0103] It should be understood that the arrows in Figures 3 and 4 are merely examples and do not constitute any limitation. In other embodiments, the roles of different TSPs and different vehicles, or the steps implemented, can be interchanged. For example, in Figure 4, the intelligent configurations of vehicles 200_2 and 200_3 can be superior to those of vehicle 200_1. Vehicle 200_2 or vehicle 200_3 can report at least one type of intelligent driving data to the server of TSP-1 in the same manner. The server of TSP-1 can analyze and process the received intelligent driving data and send reminder information to vehicle 200_1 as needed. For example, in Figure 4, the intelligent configuration of vehicle 200_4 or vehicle 200_5 may be superior to that of vehicle 200_1, vehicle 200_2 or vehicle 200_3. Vehicle 200_4 or vehicle 200_5 may report at least one type of intelligent driving data to the TSP-2 server in the same way. The TSP-2 server may synchronize the at least one type of intelligent driving data to the TSP-1 server through the interconnection service. The TSP-1 server may analyze and process the received intelligent driving data and send reminder information to vehicle 200_1, vehicle 200_2 or vehicle 200_3 as needed. For example, in Figure 4, the intelligent configuration of vehicle 200_6 can be superior to that of vehicle 200_1, vehicle 200_2, vehicle 200_3, vehicle 200_4, or vehicle 200_5. Vehicle 200_6 can report at least one type of intelligent driving data to the server of TSP-3 in the same way. The server of TSP-3 can synchronize the at least one type of intelligent driving data to the server of TSP-1 or the server of TSP-2 through the interconnection service. The server of TSP-1 can analyze and process the received intelligent driving data and send reminder information to vehicle 200_1, vehicle 200_2, or vehicle 200_3 as needed. The server of TSP-2 can analyze and process the received intelligent driving data and send reminder information to vehicle 200_4 or vehicle 200_5 as needed.

[0104] To facilitate understanding, the following descriptions, in conjunction with the accompanying diagrams, illustrate the method steps performed by vehicles and servers with different configurations.

[0105] In this context, the server in TPS-1 in Figure 4 can be represented as the first server. In a scenario where intelligent driving perception and recognition capabilities are shared within a single automaker, taking the example that the intelligent configuration of vehicle 200_1 is superior to that of vehicle 200_2 or vehicle 200_3, the vehicle reporting data to the first server (e.g., vehicle 200_1) can be represented as the first vehicle. This first vehicle has a higher / better / good intelligent configuration and can report a first data packet to the first server. This first data packet can include a first identifier, first data, and second data. The first data is used to characterize abnormal road conditions on the first vehicle's first driving path, and the second data is used to characterize the first vehicle's avoidance operation of these abnormal road conditions. The first identifier can be associated with the first vehicle's first model, and the first server can know the intelligent configuration parameters of different models of the vehicle-to-everything (V2X) services it provides. The first server can analyze and process the first data packet to identify the second vehicle and send third data to it. The second vehicle can be a vehicle of a second model, whose intelligent configuration is weaker than that of the first model. For example, vehicle 200_2 and / or vehicle 200_3 can be the second vehicle. Furthermore, the second vehicle can control its own driving based on the received third data to compensate for its own shortcomings in intelligent driving capabilities. In other words, the first server can guide the low-configuration vehicle to perform intelligent driving control based on some or all of the data in the first data packet reported by the high-configuration vehicle under the same TSP management, so that the intelligent driving perception and recognition capabilities of the high-configuration vehicle can be shared with the low-configuration vehicle, thereby improving the driving comfort and safety of the low-configuration vehicle, as well as enhancing the competitiveness of vehicles with different configurations.

[0106] Alternatively, taking the sharing of intelligent driving perception and recognition capabilities of high-end vehicles in an automotive alliance scenario as an example, the server of TPS-2 in Figure 4 can be represented as the second server. The second server can communicate with the first server through the interconnection service, thereby realizing the sharing of intelligent driving perception and recognition capabilities across TSPs. For example, vehicle 200_4 or vehicle 200_5 can be represented as the first vehicle. Vehicle 200_4 or vehicle 200_5 can send a first data packet to the second server in the same way. The first data packet may include a first identifier, first data, and second data. The second server can synchronously send the first data packet reported by the first vehicle to the first server through the interconnection service. Correspondingly, the first server can receive the first data packet forwarded by the second server through the interconnection service. Furthermore, the first server can analyze and process the first data packet to determine the second vehicle and send third data to the second vehicle. For example, vehicle 200_2 and / or vehicle 200_3 can be the second vehicle. Furthermore, the second vehicle can control its driving based on the received third data to compensate for its own deficiencies in intelligent driving capabilities. In other words, through interconnection services, the first server can guide its low-configuration vehicles to perform intelligent driving control based on some or all of the data in the first data packet reported by high-configuration vehicles managed by other TSPs. This allows the intelligent driving perception and recognition capabilities of high-configuration vehicles from other automakers to be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations.

[0107] Similarly, the server in TPS-3 in Figure 4 can be represented as a third server. This third server can communicate with the first server via an interconnection service, thereby enabling cross-TSP intelligent driving perception and recognition capability sharing. For example, vehicle 200_1 can be represented as a first vehicle. This first vehicle, corresponding to a first model, has a high / excellent / good intelligent configuration and can report a first data packet to the first server. This first data packet may include a first identifier, first data, and second data. The first data characterizes abnormal road conditions on the first vehicle's first driving path, and the second data characterizes the first vehicle's avoidance operation for these abnormal road conditions. The first server can send this first data packet to the third server via the interconnection service. The third server can use the vehicle control method of this application embodiment to analyze and process the first data packet and then send the fourth data determined based on the first data packet to the third vehicle. This third vehicle is a third model vehicle, and the intelligent configuration of the third model is weaker than that of the first model. For example, vehicle 200_6 can be a third vehicle. In other words, the first server can synchronize the first data packet reported by the high-end models it manages to other TSP servers, so that the other TSP servers can share the intelligent driving perception and recognition capabilities of the high-end models with the low-end models, thereby improving the driving comfort and safety of the low-end models and enhancing the competitiveness of vehicles with different configurations.

[0108] When implementing the vehicle control method of this application embodiment, the first server can perform the steps shown in FIG5:

[0109] S510: The first server receives the first data packet from the first vehicle.

[0110] In this embodiment of the application, the first data packet may include a first identifier, first data, and second data. The first data may be used to characterize abnormal road conditions on the first driving path of the first vehicle, and the second data may be used to characterize the first vehicle's avoidance operation of the abnormal road conditions.

[0111] Abnormal road conditions here could be caused by road surface unevenness, wear, cracks, resulting in road bumps or road / bridge damage. Alternatively, abnormal road conditions could be traffic congestion caused by the number and speed of vehicles on the road. Or, abnormal road conditions could be temporary roadblocks caused by road maintenance, traffic accidents, etc. This application does not specifically limit the manner or type of abnormal road conditions.

[0112] Prior to the specific implementation of S510, the first vehicle can utilize its own sensing system to acquire perception data of the surrounding environment, constantly monitoring and collecting data about the vehicle's surroundings. The first vehicle's sensing system can include, but is not limited to, cameras, LiDAR (light detection and ranging), millimeter-wave radar (RADAR), or other sensors. The intelligent driving domain control unit (e.g., the computing unit of a mobile data center (MDC) or an ADAS domain controller (ADC)) integrated into the first vehicle's computing platform 210 can process and calculate various perception data from the sensing system to detect abnormal road conditions along the first vehicle's path, including traffic jams, temporary road obstacles, severe road bumps, and road / bridge damage. The first vehicle's intelligent driving domain control unit can perform intelligent driving control based on the identified abnormal road conditions, such as controlling the first vehicle to perform deceleration or detour maneuvers. The first vehicle's intelligent driving domain control unit can publish first data representing the abnormal road condition and second data representing the first vehicle's avoidance maneuvers for that abnormal road condition. For example, the intelligent driving domain control unit of the first vehicle can encapsulate the first identifier, the first data, and the second data into a first data packet. The intelligent driving domain control unit of the first vehicle can send the first data packet to the server of the corresponding TSP via a T-Box and a network. For example, the first server can be the server of the first vehicle's TSP, and the first vehicle can send the first data packet to the first server. Or, for example, the second server can be the server of the first vehicle's TSP, and the first vehicle can send the first data packet to the second server.

[0113] In this embodiment, if the first server is the TSP server of the first vehicle, in S510, the first server can receive the first data packet from the first vehicle. If the second server is the TSP server of the first vehicle, before S510, the second server can synchronously send the first data packet to the first server through the interconnection service. In S510, the first server can receive the first data packet forwarded by the second server through the interconnection service. This application embodiment does not specifically limit the method by which the first server obtains the first data packet. It should be understood that the dashed arrow in Figure 5 only indicates that the first server can obtain the first data packet from the first vehicle, and does not limit whether the first data packet is directly reported to the first server by the first vehicle or forwarded to the first server by the second server.

[0114] In one example, the first data can be perception data obtained through onboard sensors to characterize abnormal road conditions, or perception results obtained after analysis and processing by the intelligent driving algorithm installed in the vehicle to characterize abnormal road conditions.

[0115] As an example, a first vehicle may be equipped with a first sensor, which may include at least one of the following: a camera, a lidar, a millimeter-wave radar, or an ultrasonic radar. The first data may, for example, include images of abnormal road conditions obtained through a camera. Alternatively, the first data may include point cloud data obtained through lidar detection. Alternatively, the first data may include data obtained through millimeter-wave radar. Alternatively, the first data may include data obtained through ultrasonic radar. Alternatively, the intelligent driving domain control unit of the first vehicle may obtain the location of abnormal road conditions through an onboard global navigation satellite system (GNSS) or onboard maps, and the first data may also include information characterizing the location of the abnormal road conditions. Alternatively, the intelligent driving domain control unit of the first vehicle may also analyze the type of abnormal road conditions based on various detected perception data, and the first data may also include information characterizing the type of abnormal road conditions. Alternatively, the first data may also include the detection time of the abnormal road conditions. This application does not specifically limit the content of the first data.

[0116] In another example, the second data may include vehicle state data detected by a second sensor mounted on the first vehicle. For instance, in response to abnormal road conditions, the intelligent driving domain control unit of the first vehicle may control the first vehicle to perform evasive maneuvers such as deceleration or detour. The second sensor may include an inertial measurement unit (IMU), which can detect the acceleration of the first vehicle in at least one dimension when evading the abnormal road conditions. This at least one dimension includes at least one of the lateral, longitudinal, or vertical directions of the vehicle body. The evasive maneuver data may include at least one of lateral acceleration, longitudinal acceleration, and vertical acceleration. Alternatively, for example, the second sensor may include a speed sensor, which can detect the speed of the first vehicle when evading the abnormal road conditions. The evasive maneuver data may include the magnitude of the vehicle's speed change. Alternatively, for example, in response to abnormal road conditions, the intelligent driving domain control unit of the first vehicle may control the first vehicle to enable certain intelligent driving subsystems (e.g., an air suspension system) to evade abnormal road conditions by adjusting vehicle height and elasticity. The evasive maneuver data may include changed software / hardware parameters. This application does not specifically limit the content of the second data.

[0117] In this embodiment, the Automotive Alliance (AutoNCAP) can provide a standardized encapsulation format for intelligent driving data. During data encapsulation at the vehicle end, the intelligent driving domain control unit of the first vehicle can encapsulate various intelligent driving data sequentially at the corresponding bit positions according to the standardized format provided by the AutoNCAP.

[0118] For example, as shown in Figure 6, the first data packet may include a first identifier, first data, and second data. The first data can be used to characterize abnormal road conditions on the first driving path of the first vehicle. For example, the first data includes perception data obtained through at least one sensor, denoted as first perception data, second perception data, etc. Following the various perception data, the first data may also include information about the location of the abnormal road conditions, such as latitude and longitude. Following the information about the location of the abnormal road conditions, the first data may also include the type of abnormal road conditions, including but not limited to temporary roadblocks, road bumps, and traffic congestion. Following the type of abnormal road conditions, the first data may also include the detection time of the abnormal road conditions. The second data can be used to characterize the first vehicle's avoidance operation of the abnormal road conditions, also called the first vehicle's avoidance operation data. For example, it may include at least one of the lateral acceleration, longitudinal acceleration, and vertical acceleration of the first vehicle when performing an avoidance operation, or data corresponding to other avoidance operations. The first data packet may also be called an alarm data packet.

[0119] It should be understood that Figure 6 is merely an illustrative representation of the data types and encapsulation formats that may be included in the first data packet. It does not limit the number of bits occupied by various data types, nor does it limit the encapsulation order or specific content of the various data types. In practical applications, the auto alliance can determine the format and content of the first data packet through negotiation, which will not be elaborated here.

[0120] Taking the first perception data, which includes LiDAR data, and the second perception data, which includes abnormal image data captured by a camera, as an example, as shown in Figure 7, for abnormal road conditions, the intelligent driving domain control unit of the first vehicle can sequentially encapsulate the vehicle identification, LiDAR data, abnormal image data, latitude and longitude, abnormal road condition type, detection time, and lateral and longitudinal acceleration, etc., according to the format shown in Figure 6, and package them into a first data packet, which is then sent to the server of the TSP providing the vehicle network server for the first vehicle. In specific implementations, for example, the abnormal image data can be used as a base, with other data superimposed on the image data before data packaging. This application embodiment does not specifically limit the implementation form of the first data packet.

[0121] S520: The first server determines the second vehicle.

[0122] In this embodiment, the second vehicle is a vehicle of a second model, and the intelligent configuration corresponding to the second model is weaker than the intelligent configuration corresponding to the first model associated with the first identifier.

[0123] For example, the intelligent driving assistance capability level corresponding to the second vehicle model is lower than that corresponding to the first vehicle model. Alternatively, for example, the first data includes perception data obtained through a first sensor installed on the first vehicle model, and the configuration difference between the second and first vehicle models regarding the first sensor satisfies any of the following: the first vehicle model is equipped with the first sensor, while the second vehicle model is not equipped with the first sensor; the number of first sensors installed on the first vehicle model is greater than the number of first sensors installed on the second vehicle model; the perception accuracy of the first sensor installed on the first vehicle model is higher than the perception accuracy of the first sensor installed on the second vehicle model. The first sensor may include at least one of the following: a camera, a lidar, a millimeter-wave radar, or an ultrasonic radar.

[0124] When implementing S520, the first server may, for example, determine the second vehicle based on the first vehicle model associated with the first identifier.

[0125] In one example, if the first server is the server of the TSP (Transportation Service Provider) of the first vehicle, the first server can obtain the intelligent configuration parameters corresponding to different models of the same automaker from the local storage medium, and determine at least one model whose intelligent configuration is weaker than that of the first model, which is represented as the second model. The first server can determine the second vehicle from the vehicles of the second model.

[0126] For example, the first server can identify all vehicles of the second model as the second vehicle.

[0127] Or, for example, the first server can identify the vehicle that meets the preset conditions among the vehicles of the second model as the second vehicle.

[0128] For example, the first server can identify a vehicle of the second vehicle type that will pass through the abnormal road condition location as the second vehicle. Specifically, before implementing S520, the first server can obtain the travel paths of multiple vehicles of the second vehicle type. When implementing S520, the first server can determine the second vehicle whose second travel path includes the abnormal road condition location based on the first vehicle type associated with the first identifier, the abnormal road condition location, and the travel paths of multiple vehicles of the second vehicle type. That is, the second travel path of the second vehicle includes the abnormal road condition location.

[0129] For example, the first server can identify a vehicle of the second vehicle type that has already subscribed to the abnormal traffic alert service as the second vehicle. Specifically, before implementing S520, the first server can receive subscription messages from multiple vehicles of the second vehicle type, which are used to subscribe to the abnormal traffic alert service from the first server. When implementing S520, the first server can determine the second vehicle subscribing to the abnormal traffic alert service based on the subscription messages of multiple vehicles of the first and second vehicle types associated with the first identifier.

[0130] For example, the first server can identify a vehicle with the relevant intelligent driving function execution capability from among the vehicles of the second model as the second vehicle. Specifically, before implementing S520, the first server can obtain the execution capability level information of multiple vehicles of the second model. When implementing S520, the first server can determine the second vehicle that matches the first level information associated with the first data packet based on the execution capability level information of the first model associated with the first identifier and the multiple vehicles of the second model. The first level information can indicate the execution capability level corresponding to the first vehicle's avoidance operation of the abnormal road condition. This first level information can be added to the first data packet by the first vehicle itself, or it can be analyzed and added by the first server for the first data packet; this embodiment does not specifically limit this.

[0131] In another example, if the second server is the server of the TSP of the first vehicle, the second server can forward the first data packet from the first vehicle to the first server through the interconnection service. Correspondingly, the first server can receive the first data packet forwarded by the second server through the interconnection service. When the first server decapsulates and analyzes the first data packet, it can obtain the intelligent configuration parameters corresponding to the first vehicle model associated with the first identifier from the second server through the interconnection service, compare the intelligent configuration parameters corresponding to the first vehicle model with the intelligent configuration parameters corresponding to different vehicle models of the car companies it manages, and determine at least one vehicle model whose intelligent configuration is weaker than that of the first vehicle model, representing it as the second vehicle model. The first server can determine the second vehicle from the vehicles of the second vehicle model. Similarly, the first server can determine all vehicles of the second vehicle model as the second vehicle, or it can determine vehicles of the second vehicle model that are about to pass through the abnormal road condition location as the second vehicle, or it can determine vehicles of the second vehicle model that have subscribed to the abnormal road condition alarm service as the second vehicle, or it can determine vehicles of the second vehicle model that have the execution capability of relevant intelligent driving functions as the second vehicle. This application embodiment does not specifically limit this.

[0132] Taking the addition of first-level information to the first data packet by the intelligent driving domain control unit of the first vehicle as an example, the first-level information indicates the execution capability level corresponding to the first vehicle's avoidance operation of the abnormal road conditions. As shown in Figure 7, a capability level label is added to the first data packet.

[0133] In one example, the intelligent driving domain control unit of the first vehicle may use the perception data and avoidance operation data carried in the first data packet to calculate the capability level of the first data packet (i.e., the alarm data packet).

[0134] The following example illustrates how this capability level is represented, using the case of whether the first data packet carries lidar data and the evasion operation data as the acceleration data of the first vehicle in the horizontal, vertical, and lateral directions when evading abnormal road conditions.

[0135] For example, for LiDAR data, the data representation can be supplemented by whether the first data packet contains LiDAR data. For example, 0000 represents no LiDAR data, and 0001 represents LiDAR data.

[0136] Taking acceleration data in the horizontal, vertical, and lateral directions as an example for avoidance operations, and using a calculation method shared by all three directions, with each direction calculated according to 10 levels, the levels and corresponding numerical representations are shown in Table 1 below:

[0137] Table 1

[0138] For the horizontal, vertical, and longitudinal directions, 00 represents the horizontal direction, 01 represents the longitudinal direction, and 10 represents the longitudinal direction. Each direction can be distinguished by positive or negative values ​​for front / back, left / right, and up / down. If the acceleration value in a certain direction is positive, the prefix "10" can be added before the corresponding level of numerical representation; if the acceleration value in a certain direction is negative, the prefix "11" can be added before the corresponding level of numerical representation.

[0139] For example, if the first vehicle's evasive maneuver is an emergency braking maneuver, and the detected lateral acceleration is 0, longitudinal acceleration is -6, and vertical acceleration is 0, in meters per second squared (m / s²) 2 or kilometers per second squared (km / s) 2 At this point, the acceleration data in these three dimensions can be calculated to correspond to the following levels: one level horizontally, eight levels vertically, and one level in the vertical direction. After adding directions, the numerical representation of the acceleration data levels in each direction is as follows:

[0140] Horizontal data: 0010 0000 0001;

[0141] Vertical data: 0111 0000 1000;

[0142] Vertical data: 1010 0000 0001;

[0143] For example, in the data "Horizontal data: 0010 0000 0001", the first four values ​​"0010" represent horizontal direction and "10" represents a positive value, while the last eight values ​​"0000 0001" represent level one. Similarly, in the data "Vertical data: 0111 0000 1000", the first four values ​​"0111" represent vertical direction and "11" represents a negative value, while the last eight values ​​"0000 1000" represent level eight. Finally, in the data "Vertical direction: 1010 0000 0001", the first four values ​​"1010" represent vertical direction and "10" represents a positive value, while the last eight values ​​"0000 0001" represent level one.

[0144] Based on the above data assembly and definition methods, in a specific example: if the first vehicle encounters an emergency road condition and performs an emergency avoidance operation based on the detected LiDAR data, the lateral, longitudinal, and vertical accelerations of the first vehicle during the avoidance of the emergency road condition are collected, corresponding to the following levels: lateral is positive level 3 (001000000011), longitudinal is negative level 4 (011100000100), and vertical is positive level 2 (101000000010). The capability level information is obtained by stitching together the data based on the presence or absence of LiDAR data and the lateral, longitudinal, and vertical accelerations, as shown below:

[0145] 0001001000000011011100000100 101000000010;

[0146] The meanings of the values ​​in the information “0001001000000011011100000100 101000000010” from front to back are as follows: “0001” represents that there is LiDAR data, “001000000011” represents horizontal, positive value, level 3, “011100000100” represents vertical, negative value, level 4, and “101000000010” represents vertical direction, positive value, level 2.

[0147] The intelligent driving domain control unit of the first vehicle can encapsulate this capability level information as first-level information in a first data packet. Then, the first vehicle can send this first data packet to its own TSP server to share its high-end intelligent driving perception and recognition capabilities with the low-end second vehicle. Furthermore, during S520, the first server can perform matching calculations based on the first-level information to select a second vehicle from multiple vehicles of the second vehicle model that matches the first-level information, ensuring that the second vehicle is capable of performing the corresponding evasive maneuvers.

[0148] S530: The first server determines the third data based on the intelligent configuration corresponding to the second vehicle model and the second data.

[0149] S540: The first server sends third data to the second vehicle. Accordingly, the second vehicle receives the third data from the first server.

[0150] For example, the third data is sent to the second vehicle before it passes the location of the abnormal road condition. Alternatively, the third data is sent to the second vehicle promptly after analysis and determination, based on the second vehicle's subscription to the abnormal road condition alarm service. Or, the third data is sent to the second vehicle promptly after analysis and determination, based on the execution capability level information reported by the second vehicle. This application embodiment does not specifically limit the timing of sending the third data.

[0151] In this embodiment, the third data can be associated with the second vehicle's avoidance operations in response to the abnormal road conditions. For example, the third data can be intelligent driving commands that the second vehicle can recognize and parse.

[0152] In implementing S530, the first server can, for example, analyze the avoidance operation represented by the second data, and determine whether the second vehicle supports executing the avoidance operation represented by the second data based on the intelligent configuration corresponding to the second vehicle model. If so, the first server can use the second data as the third data. If not, the first server can also generate third data by analyzing the avoidance operation represented by the second data and the intelligent configuration parameters corresponding to the second vehicle model. The avoidance operation represented by the third data can be an operation equivalent to the avoidance operation represented by the second data.

[0153] Taking abnormal road conditions as obstacles and the avoidance operation represented by the second data as an example of adjusting the vehicle height related to the air suspension system, if the second vehicle also has an air suspension system (based on the fact that all first vehicles have air suspension systems but differ in other intelligent configurations), the third data can be an instruction to the second vehicle to adjust its vehicle height. If the second vehicle does not have an air suspension system, in order for the second vehicle to avoid obstacles, the third data can be an instruction to the second vehicle to detour around the obstacles. That is, the first server guides the second vehicle to avoid obstacles in different ways by issuing the third data. Thus, through the above method, the intelligent driving perception and recognition capabilities of high-configuration vehicles can be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations. It should be noted that in this embodiment, two modes can be provided for low-configuration vehicles to enable them to share the intelligent driving perception and recognition capabilities of high-configuration vehicles.

[0154] For example, multiple low-configuration vehicles managed by the first server can pre-report their execution capability level information to the first server. For instance, the first server can obtain the execution capability level information of multiple vehicles of the second model. After receiving the first data packet reported by a high-configuration vehicle (e.g., the first vehicle), the first server can perform matching calculations based on the first-level information (or tag information) carried in the first data packet and the execution capability level information of each low-configuration vehicle. Then, it actively pushes the third data determined based on the alarm data reported by the high-configuration vehicle to the corresponding low-configuration vehicle.

[0155] Alternatively, for example, multiple low-configuration vehicles managed by the first server can pre-subscribe to the first server, such as subscribing to an abnormal road condition alarm service. After receiving the first data packet reported by a high-configuration vehicle (e.g., the first vehicle), the first server can select / generate corresponding alarm data as third data as needed based on the different subscription status of the low-configuration vehicles to the abnormal road condition alarm service, and send the third data to the corresponding low-configuration vehicle so that the low-configuration vehicle can perform the corresponding avoidance operation based on the received third data.

[0156] Therefore, the above method provides a standardized data sharing approach suitable for vehicle networking scenarios, enabling the intelligent driving perception and recognition capabilities of high-configuration vehicles to be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations.

[0157] In another example, the aforementioned first server can be one of multiple TSPs (Through-the-Ticket Providers) that have joined the automotive alliance. This first server is the server for the TSP of the first vehicle. It can also synchronize the first data packet to the servers of other TSPs within the automotive alliance via the interconnection service shown in Figure 4, so as to share the advanced intelligent assisted driving capabilities of the first vehicle with the lower-configuration vehicles managed by other TSPs. Similarly, the servers of other TSPs can also synchronize the second data packet reported by the high-configuration vehicles they manage to the first server using the same method, in order to achieve cross-TSP capability sharing.

[0158] As shown in Figure 8, the method may include the following steps:

[0159] S810: The first server can receive a first data packet from the first vehicle and synchronously forward the first data packet to the third server via the interconnection service. The first data packet includes a first identifier, first data, and second data. The first identifier is associated with the first vehicle's first model. The first data is used to characterize abnormal road conditions on the first vehicle's first driving path. The second data is used to characterize the first vehicle's avoidance operation of the abnormal road conditions. For specific implementation details, please refer to the preceding description in conjunction with S510; it will not be repeated here.

[0160] S820a: The first server determines the second vehicle and the third data based on the first data packet. For specific implementation details, please refer to the preceding introduction combining S520 and S530; they will not be repeated here.

[0161] S820b: The third server determines the third vehicle and the fourth data based on the first data packet.

[0162] The third server is the TSP server of the third vehicle, and the third vehicle is a third-model vehicle with a lower level of intelligent configuration than the first model. For example, the intelligent driving assistance capability level of the third model is lower than that of the first model. Or, for example, the configuration difference between the third vehicle and the first vehicle regarding the first sensor satisfies any of the following: the first vehicle is equipped with the first sensor, while the third vehicle is not equipped with the first sensor; the number of first sensors equipped on the first vehicle is greater than the number of first sensors equipped on the third vehicle; the perception accuracy of the first sensor equipped on the first vehicle is higher than the perception accuracy of the first sensor equipped on the third vehicle. The fourth data can be associated with the third vehicle's avoidance operations in the abnormal road conditions. For example, the fourth data can be intelligent driving commands that the third vehicle can recognize and parse.

[0163] The implementation details of S820b are the same as those of S820a. For details, please refer to the relevant introductions of S520 and S530 mentioned above, which will not be repeated here.

[0164] S830a: The first server sends third data to the second vehicle.

[0165] S830b: The third server sends fourth data to the third vehicle.

[0166] Similarly, a third vehicle, being a lower-configuration vehicle, can also pre-report its own capability level to the third server, or subscribe to abnormal road condition alarm services to share the intelligent assisted driving capabilities of higher-configuration vehicles. Specific implementation details can be found in the preceding introduction combining S520 and S530, and will not be repeated here.

[0167] It should be understood that S820a and S820b can be executed simultaneously, or S820a can be executed first and then S820b, or S820b can be executed first and then S820a. This embodiment of the application does not specifically limit this execution order. Similarly, S830a and S830b can be executed simultaneously, or S830a can be executed first and then S830b, or S830b can be executed first and then S830a. This embodiment of the application does not specifically limit this execution order.

[0168] In an optional implementation, the third server can be replaced by the second server, which can synchronously forward the received first data packet to the first server in accordance with the vehicle control method described above.

[0169] In an optional implementation, the third server can also perform the functions of the second server, for example, synchronously forwarding the second data from the fourth vehicle to the first server, as shown in steps S840-S860 below:

[0170] S840: The third server can receive the second data packet from the fourth vehicle and synchronously send the second data packet to the first server via the interconnection service. Correspondingly, the first server receives the second data packet from the third server via the interconnection service.

[0171] Similar to the first data packet, the encapsulation of the second data packet also follows the Auto Union's standardized format. For example, the second data packet includes a second identifier, fifth data, and sixth data for the fourth vehicle. The fifth data represents abnormal road conditions on the fourth vehicle's driving path, and the sixth data represents the fourth vehicle's evasive maneuvers in response to the abnormal road conditions.

[0172] S850: The first server determines the fifth vehicle and the seventh data based on the second data packet.

[0173] For example, the fifth vehicle is a fifth-model vehicle, and the intelligent configuration corresponding to the fifth model is weaker than the intelligent configuration corresponding to the fourth model of the fourth vehicle. For example, the intelligent driving assistance capability level corresponding to the fifth model is lower than the intelligent driving assistance capability level corresponding to the fourth model. Or, for example, the configuration difference between the fifth vehicle and the fourth vehicle regarding the first sensor satisfies any of the following: the fourth vehicle is equipped with the first sensor, and the fifth vehicle is not equipped with the first sensor; the number of first sensors equipped on the fourth vehicle is greater than the number of first sensors equipped on the fifth vehicle; the perception accuracy of the first sensor equipped on the fourth vehicle is higher than the perception accuracy of the first sensor equipped on the fifth vehicle. The seventh data can be associated with the fifth vehicle's avoidance operation of the abnormal road conditions. For example, the seventh data can be intelligent driving commands that the fifth vehicle can recognize and parse.

[0174] The implementation details of S850 are the same as those of S820a and S820b. For details, please refer to the relevant introductions of S520 and S530 mentioned above, which will not be repeated here.

[0175] S860: The first server sends the seventh data to the fifth vehicle.

[0176] Similarly, the fifth vehicle, as a lower-configuration vehicle, can also pre-report its own capability level information to the first server, or subscribe to abnormal road condition alarm services from the first server, in order to share the intelligent assisted driving capabilities of higher-configuration vehicles. Specific implementation details can be found in the preceding introduction combining S520 and S530, and will not be repeated here.

[0177] Therefore, the above method provides a standardized data sharing approach suitable for vehicle-to-everything (V2X) scenarios. This allows high-configuration vehicles to package and publish information on detected abnormal road conditions and vehicle avoidance to the cloud, which can then be subscribed to or pushed to various low-configuration vehicles. This enables the intelligent driving perception and recognition capabilities of high-configuration vehicles with the same TSP to be shared with low-configuration vehicles, thereby improving the driving comfort and safety of low-configuration vehicles and enhancing the competitiveness of vehicles with different configurations. This ensures that low-cost vehicles can also make up for some of their competitiveness.

[0178] In the context of automotive alliances, the intelligent perception and recognition capabilities of a high-configuration vehicle from one automaker can be shared with a low-configuration vehicle from another automaker through the interconnection service between servers of different TSPs. This allows for better utilization of interconnection capabilities to address the identification and automatic avoidance of abnormal road conditions by low-configuration vehicles, thereby improving the user experience.

[0179] For example, in the convoy off-road mode, each vehicle in the convoy can be a member of the alliance. Through the interconnectivity services provided by the alliance, road condition detection information can be synchronized to vehicles from other automakers within the alliance in a timely and efficient manner, enabling vehicles of different brands to receive road condition warnings and avoidance. At the same time, the interconnectivity service provides standard data interfaces and standard vehicle response interfaces, reducing customization and ensuring that the interconnectivity service is not limited by vehicle brand or configuration.

[0180] To facilitate understanding, the implementation details of the above vehicle control method will be illustrated below in conjunction with the modular structure of the vehicle and the server.

[0181] As shown in Figure 9, a high-configuration vehicle terminal may include a vehicle-side intelligent driving road condition detection unit 10 and a vehicle-side message notification and reporting unit 20. The vehicle-side intelligent driving road condition detection unit 10 can, for example, be implemented as the MDC / ADC computing unit of a high-configuration vehicle. It can detect abnormal road conditions on the driving path based on visual and radar perception data, including but not limited to: traffic jams, temporary road obstacles, severe road bumps, and road / bridge damage. The vehicle-side message notification and reporting unit 20 is responsible for encapsulating the intelligent driving data associated with abnormal road conditions collected by the vehicle-side intelligent driving road condition detection unit 10, obtaining corresponding data packets, and reporting them to the cloud server. This data packet may include, for example, radar data, abnormal road condition images, latitude and longitude (abnormal road condition location), abnormal road condition type, detection time, and vehicle sensor data (e.g., acceleration data in different dimensions).

[0182] The cloud server may include a cloud traffic processing unit 30 and a cloud traffic notification unit 40. The cloud traffic processing unit 30 can process data packets from high-configuration vehicles and update abnormal traffic information records and abnormal traffic recovery detection task records. The cloud traffic notification unit 40 is responsible for sending abnormal traffic information and notifications of abnormal traffic recovery detection tasks to other vehicles of the same manufacturer (such as low-configuration vehicles) and synchronizing the information to the interconnected service unit 60.

[0183] The low-configuration vehicle end may include a vehicle-side message receiving and processing unit 50, which can receive abnormal road condition information and recovery detection tasks sent by the cloud server (only vehicles with intelligent driving systems have recovery detection tasks). In response to abnormal road conditions, the vehicle can control the vehicle to cope with abnormal road conditions through assisted driving functions such as avoidance and automatic activation of air suspension, thereby ensuring safe and comfortable driving of the vehicle.

[0184] The interconnected service unit 60 is responsible for collecting abnormal road condition information reported by the servers of different vehicle manufacturers' TSPs and synchronizing it with the servers of other TSPs according to the alliance protocol. The cloud interconnected message receiving unit 70 in the servers of other TSPs is responsible for receiving the abnormal road condition information synchronized by the interconnected service unit 60 and adding it to the road condition notification list.

[0185] It should be understood that Figure 9 is only a modular description of the method performed by the vehicle or server. For relevant implementation details, please refer to the method embodiments described above in conjunction with Figures 1-8, which will not be repeated here.

[0186] This application also provides a communication device for executing the methods executed by different servers or different vehicles in the above method embodiments. The relevant features can be found in the above method embodiments, and will not be repeated here.

[0187] As shown in Figure 10, the communication device 1000 may include: an acquisition unit 1001, configured to acquire a first data packet from a first vehicle, the first data packet including a first identifier, first data, and second data, the first data being used to characterize abnormal road conditions on a first driving path of the first vehicle, and the second data being used to characterize the first vehicle's avoidance operation of the abnormal road conditions; a determination unit 1002, configured to determine a second vehicle, wherein the second vehicle is a vehicle of a second model, and the intelligent configuration corresponding to the second model is weaker than the intelligent configuration corresponding to the first model associated with the first identifier; and to determine third data based on the intelligent configuration corresponding to the second model and the second data, the third data being associated with the second vehicle's avoidance operation of the abnormal road conditions; and a sending unit 1003, configured to send the third data to the second vehicle. For specific implementation details, please refer to the method steps implemented by the first or second server in the above method embodiments, which will not be repeated here.

[0188] It should be understood that the division of units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a Central Processing Unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functionality of some or all units can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the above units is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through a configuration file, thereby achieving the functionality of some or all of the above units. All units of the above device can be implemented entirely through processor-invoked software, entirely through hardware circuits, or partially through processor-invoked software with the remaining parts implemented through hardware circuits.

[0189] In this application embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships of hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a Neural Network Processing Unit (NPU), Tensor Processing Unit (TPU), or Deep Learning Processing Unit (DPU).

[0190] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0191] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a system-on-a-chip (SOC). The SOC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and artificial intelligence processor, CPU and GPU, etc.

[0192] In a simplified embodiment, those skilled in the art will realize that the communication devices in the above embodiments can all take the form shown in FIG11.

[0193] The device 1100 shown in Figure 11 includes at least one processor 1110 and a communication interface 1130. In an alternative design, a memory 1120 may also be included.

[0194] The specific connection medium between the processor 1110 and the memory 1120 is not limited in the embodiments of this application.

[0195] In the device shown in Figure 11, when the processor 1110 communicates with other devices, it can transmit data through the communication interface 1130.

[0196] When the communication device adopts the form shown in FIG11, the processor 1110 in FIG11 can call the computer execution instructions stored in the memory 1120, so that the device 1100 can execute any of the above method embodiments.

[0197] This application also relates to a chip system including a processor for calling a computer program or computer instructions stored in a memory to cause the processor to execute the methods of any of the above embodiments.

[0198] In one possible implementation, the processor can be coupled to the memory via an interface.

[0199] In one possible implementation, the chip system may also directly include a memory in which computer programs or computer instructions are stored.

[0200] For example, the memory can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0201] This application also relates to a processor for calling a computer program or computer instructions stored in a memory to cause the processor to execute the methods described in any of the above embodiments.

[0202] For example, in the embodiments of this application, the processor is an integrated circuit chip with signal processing capabilities. For instance, the processor can be an FPGA, a general-purpose processor, a DSP, an ASIC, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, a system-on-chip (SoC), a CPU, a network processor (NP), a microcontroller unit (MCU), a PLD, or other integrated chips, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0203] It should be understood that embodiments of this application may be provided as methods, systems, or computer program products.

[0204] In one possible implementation, embodiments of this application provide a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform the method embodiments described above.

[0205] In one possible implementation, this application provides a computer program product that, when run on a computer, causes the computer to execute the above-described method embodiments.

[0206] Therefore, this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0207] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0208] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0209] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations. In the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the various embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

Claims

1. A vehicle control method, characterized in that, Applied to a first server, the method includes: A first data packet is acquired from a first vehicle. The first data packet includes a first identifier, first data, and second data. The first data is used to characterize abnormal road conditions on a first driving path of the first vehicle, and the second data is used to characterize the first vehicle's avoidance operation of the abnormal road conditions. Identify a second vehicle, wherein the second vehicle is a vehicle of a second model, and the intelligent configuration of the second model is weaker than the intelligent configuration of the first model associated with the first identifier; The third data is determined based on the intelligent configuration corresponding to the second vehicle model and the second data, and the third data is associated with the second vehicle's avoidance operation of the abnormal road conditions; The third data is sent to the second vehicle.

2. The method according to claim 1, characterized in that, The first data includes information on the location of abnormal road conditions, and the method further includes: Obtain the driving paths of multiple vehicles of the second model; The determination of the second vehicle includes: The second vehicle is determined based on the first vehicle type associated with the first identifier, the location of the abnormal road condition, and the driving paths of multiple vehicles of the second vehicle type, wherein the second driving path of the second vehicle includes the location of the abnormal road condition. Sending the third data to the second vehicle includes: The third data is sent to the second vehicle before it passes the location of the abnormal road condition.

3. The method according to claim 1 or 2, characterized in that, The first data packet also includes first-level information, which indicates the execution capability level of the first vehicle's avoidance operation of the abnormal road condition. The method further includes: Obtain the execution capability level information of multiple vehicles of the second model; The determination of the second vehicle includes: Based on the execution capability level information of multiple vehicles of the first vehicle type and the second vehicle type associated with the first identifier, the second vehicle that matches the first level information is determined.

4. The method according to claim 1 or 2, characterized in that, The method further includes: Receive subscription messages from multiple vehicles of the second vehicle type, the subscription messages being used to subscribe to the abnormal road condition alarm service from the first server; The determination of the second vehicle includes: Based on the subscription messages of multiple vehicles of the first vehicle type and the second vehicle type associated with the first identifier, the second vehicle subscribing to the abnormal road condition alarm service is determined.

5. The method according to any one of claims 1-4, characterized in that, The intelligent features of the second model are weaker than those of the first model, specifically including: The intelligent driving assistance capability level of the second vehicle model is lower than that of the first vehicle model.

6. The method according to any one of claims 1-5, characterized in that, The first data includes perception data obtained through a first sensor mounted on the first vehicle, wherein the intelligent configuration of the second vehicle model is weaker than that of the first vehicle model, specifically including: the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any one of the following: The first vehicle is equipped with the first sensor, while the second vehicle is not equipped with the first sensor. The number of the first sensors installed on the first vehicle is greater than the number of the first sensors installed on the second vehicle; The sensing accuracy of the first sensor installed on the first vehicle is higher than that of the first sensor installed on the second vehicle.

7. The method according to claim 6, characterized in that, The first sensor includes at least one of the following: Cameras, lidar, millimeter-wave radar, and ultrasonic radar.

8. The method according to any one of claims 1-7, characterized in that, The second data includes vehicle status data obtained by a second sensor mounted on the first vehicle, wherein the second sensor includes an inertial measurement unit (IMU).

9. The method according to claim 8, characterized in that, The second data includes the acceleration of the first vehicle in at least one dimension when it avoids the abnormal road conditions, and the at least one dimension includes at least one of the horizontal, longitudinal, or vertical directions of the vehicle body.

10. The method according to any one of claims 1-9, characterized in that, The first vehicle and the second vehicle correspond to the same vehicle-to-everything (TSP) service provider. The first server is the server of the TSP for both the first vehicle and the second vehicle. Obtaining the first data packet from the first vehicle includes: Receive the first data packet from the first vehicle.

11. The method according to any one of claims 1-9, characterized in that, The first vehicle and the second vehicle correspond to different TSPs. The step of obtaining the first data packet from the first vehicle includes: The system receives the first data packet forwarded by the second server via an interconnection service. The second server is the TSP server of the first vehicle, and the first server is the TSP server of the second vehicle.

12. The method according to any one of claims 1-9, characterized in that, The method further includes: The first data packet is sent to a third server via an interconnection service. The third server is used to send the fourth data determined according to the first data packet to a third vehicle. The first server is the TSP server of the first vehicle, and the third server is the TSP server of the third vehicle. The third vehicle is a vehicle of a third model, and the intelligent configuration of the third model is weaker than that of the first model.

13. A vehicle control method, characterized in that, Applied to a second vehicle, the method includes: Receive third data from a first server, wherein the third data is determined by the first server based on a first data packet from a first vehicle, the first vehicle being a vehicle of a first model, and the intelligent configuration of the second model of the second vehicle being weaker than the intelligent configuration of the first model. The second vehicle is controlled to move according to the third data.

14. The method according to claim 13, characterized in that, The second driving path of the second vehicle includes the locations of abnormal road conditions detected by the first vehicle, and the receiving of third data from the first server includes: Before the second vehicle passes through the location of the abnormal road condition, the third data is received from the first server.

15. The method according to claim 13 or 14, characterized in that, The first server is the server of the TSP of the second vehicle, and the method further includes: Send the execution capability level information of the second vehicle to the first server.

16. The method according to claim 13 or 14, characterized in that, The method further includes: A subscription message is sent to the first server, the subscription message being used to subscribe to the abnormal traffic condition alarm service from the first server.

17. The method according to any one of claims 13-16, characterized in that, The intelligent features of the second model are weaker than those of the first model, specifically including: The intelligent driving assistance capability level of the second vehicle model is lower than that of the first vehicle model.

18. The method according to any one of claims 13-17, characterized in that, The intelligent configuration of the second vehicle model is weaker than that of the first vehicle model, specifically including: the configuration difference between the second vehicle and the first vehicle regarding the first sensor satisfies any one of the following: The first vehicle is equipped with the first sensor, while the second vehicle is not equipped with the first sensor. The number of the first sensors installed on the first vehicle is greater than the number of the first sensors installed on the second vehicle; The sensing accuracy of the first sensor installed on the first vehicle is higher than that of the first sensor installed on the second vehicle.

19. The method according to claim 18, characterized in that, The first sensor includes at least one of the following: Cameras, lidar, millimeter-wave radar, and ultrasonic radar.

20. A vehicle control device, characterized in that, include: The acquisition unit is used to acquire a first data packet from a first vehicle. The first data packet includes a first identifier, first data, and second data. The first data is used to characterize abnormal road conditions on a first driving path of the first vehicle, and the second data is used to characterize the first vehicle's avoidance operation of the abnormal road conditions. The determining unit is configured to determine a second vehicle based on a first vehicle model associated with the first identifier, wherein the second vehicle is a vehicle of a second vehicle model, and the intelligent configuration corresponding to the second vehicle model is weaker than the intelligent configuration corresponding to the first vehicle model; and to determine third data based on the intelligent configuration corresponding to the second vehicle model and the second data, wherein the third data is associated with the second vehicle's avoidance operation of the abnormal road conditions; The transmitting unit is used to transmit the third data to the second vehicle.

21. A vehicle control device, characterized in that, include: A receiving unit is configured to receive third data from a first server, wherein the third data is determined by the first server based on a first data packet from a first vehicle, the first vehicle being a vehicle of a first model, and the intelligent configuration of the second model of the second vehicle being weaker than the intelligent configuration of the first model. The control unit controls the movement of the second vehicle based on the third data.

22. A communication device, characterized in that, It includes at least one processor and an interface circuit, the interface circuit being used to provide data or code instructions to the at least one processor, the at least one processor being used to implement the method as described in any one of claims 1-12, or to implement the method as described in any one of claims 13-19, through logic circuits or executing code instructions.

23. A communication system, characterized in that, It includes a server for implementing the method as described in any one of claims 1-12, and a first vehicle and a second vehicle, the second vehicle being used to implement the method as described in any one of claims 13-19.

24. A computer-readable storage medium, characterized in that, The computer-readable medium stores program code that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1-12, or the method as described in any one of claims 13-19.

25. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-12, or the method as described in any one of claims 13-19.

Images