Methods, devices, equipment and systems for berthing data processing

CN117962911BActive Publication Date: 2026-09-01DEEPAL AUTOMOBILE TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410061812.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-01-15
Publication Date
2026-09-01
Estimated Expiration
2044-01-15

AI Technical Summary

Technical Problem

[0002]随着汽车智能座舱和自动驾驶领域的快速发展,用户对智能汽车的需求也越来越高,在用户需要从泊车模式切换至行车模式,或者需要从行车模式切换至泊车模式的情况下,由于相关技术中行车模式和泊车模式通常运行在不同的系统,其中的数据内容、种类、格式不尽相同(如行车模式场景重构需要道路的高精地图结合车辆行车感知数据的渲染,而泊车模式场景重构需要停车场的高精地图结合泊车感知数据的渲染),导致车辆在行车模式对应的驾驶场景与泊车模式对应的驾驶场景进行切换显示时,需要切换数据源和系统,出现较为明显的割裂(如在数据源和系统的切换过程中的黑屏等),影响用户的驾驶体验

Benefits of technology

[0028](1)本申请提供的行泊数据处理方法中,数据处理模块首先确定车辆在下一时刻的目标驾驶模式,并进一步根据目标驾驶模式调用相应的数据进行处理,得到目标待渲染数据,其中,在目标驾驶模式为行车模式时,获取行车域控制器发送的行车数据进行处理,在目标驾驶模式为泊车模式时,获取泊车域控制器发送的泊车数据进行处理,以使得在车辆在切换驾驶模式的场景下,在数据处理模块完成资源层面的切换(待渲染数据的切换),渲染模块只需要渲染数据处理模块提供的待渲染数据即可,显示设备无需在行车域控制系统提供的渲染后的驾驶场景与泊车域控制系统提供的渲染后的驾驶场景之间切换,降低用户对于不同驾驶模式渲染出的驾驶场景在切换时的感知,实现不同驾驶模式的驾驶场景的无缝切换,也即行泊一体化渲染驾驶场景,提高用户驾驶体验。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117962911B_ABST
    Figure CN117962911B_ABST
Patent Text Reader

Abstract

This application relates to a method, apparatus, device, and system for processing driving and parking data, and pertains to the field of automotive technology. The method includes: a data processing module determining the target driving mode of the vehicle at the current moment and the next moment. Further, when the target driving mode is a driving mode, the data processing module processes driving data received from the driving domain controller based on a standardized interface between the data processing module and the rendering module, and determines the processed driving data as the target data to be rendered; when the target driving mode is a parking mode, the data processing module processes parking data received from the parking domain controller based on a standardized interface, and determines the processed parking data as the target data to be rendered. Further, the data processing module sends the target data to be rendered to the rendering module. This reduces the user's perception of the driving scene transitioning between different driving modes, achieving seamless switching of driving scenes.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of automotive technology, and more particularly to the field of intelligent driving technology for automobiles, specifically to a parking data processing method, apparatus, device, and system. Background Technology

[0002] With the rapid development of intelligent cockpits and autonomous driving, users' demands for intelligent vehicles are also increasing. When users need to switch from parking mode to driving mode, or vice versa, the driving mode and parking mode typically run on different systems with different data content, types, and formats (e.g., driving mode scene reconstruction requires rendering of high-precision road maps combined with vehicle driving perception data, while parking mode scene reconstruction requires rendering of high-precision parking lot maps combined with parking perception data). This results in a noticeable disconnect when the vehicle switches between the driving scene corresponding to driving mode and the driving scene corresponding to parking mode, causing a significant gap (such as a black screen during the data source and system switching process), which affects the user's driving experience. Summary of the Invention

[0003] One of the purposes of this application is to provide a driving data processing method, apparatus, device and system to reduce the user's perception of driving scenarios rendered by different driving modes when switching, and to achieve seamless switching of driving scenarios in different driving modes.

[0004] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0005] According to a first aspect of this application, a parking data processing method is provided, comprising: a data processing module determining the target driving mode of a vehicle at the current moment and the next moment. Further, when the target driving mode is a driving mode, the data processing module processes driving data received from a driving domain controller based on a standardized interface between the data processing module and a rendering module, and determines the processed driving data as target data to be rendered; when the target driving mode is a parking mode, the data processing module processes parking data received from a parking domain controller based on a standardized interface, and determines the processed parking data as target data to be rendered. Further, the data processing module sends the target data to be rendered to the rendering module through the standardized interface, so that the rendering module renders the vehicle's driving scene based on the target data to be rendered.

[0006] Based on the aforementioned technical means, in the driving and parking data processing method provided in this application, the data processing module first determines the target driving mode of the vehicle at the next moment, and further calls the corresponding data for processing according to the target driving mode to obtain the target data to be rendered. Specifically, when the target driving mode is driving mode, driving data sent by the driving domain controller is obtained and processed; when the target driving mode is parking mode, parking data sent by the parking domain controller is obtained and processed. This allows the data processing module to complete the resource-level switching (switching of the data to be rendered) in the scenario where the vehicle switches driving modes. The rendering module only needs to render the data to be rendered provided by the data processing module. The display device does not need to switch between the driving scene rendered by the driving domain control system and the driving scene rendered by the parking domain control system, reducing the user's perception of the driving scene rendered by different driving modes during the switching process. This achieves seamless switching of driving scenes in different driving modes, i.e., integrated driving and parking rendering of driving scenes, improving the user's driving experience.

[0007] In one possible implementation, driving data includes driving perception data and road map data collected by the driving domain controller, and parking data includes parking perception data and parking lot map data collected by the parking domain controller.

[0008] In one possible implementation, the data processing module processes the driving data received from the driving domain controller based on the standardized interface between the data processing module and the rendering module, including: performing data format conversion processing on the driving data based on the data format supported by the standardized interface to obtain processed driving data; the data processing module also processes the parking data received from the parking domain controller based on the standardized interface, including: performing data format conversion processing on the parking data based on the data format supported by the standardized interface to obtain processed parking data.

[0009] Based on the above technical means, this application realizes the format conversion of driving data sent by the driving domain controller and parking data sent by the parking domain controller in the data processing module, so that the rendering module can receive the data to be rendered sent by the data processing module through a standardized interface and perform rendering processing.

[0010] In one possible implementation, the data processing module determines the target driving mode of the vehicle at the next moment from the current moment, including: determining the target driving mode of the vehicle at the next moment from the current moment based on the vehicle's location information and vehicle operation information, wherein the vehicle operation information includes speed, power-on duration, and steering wheel angle.

[0011] Based on the aforementioned technical means, this application enables the active detection of whether a user intends to switch driving modes during the process of driving a vehicle, and determines the user's driving mode at the current moment and the next moment, so that the subsequent rendering module can render the driving scene corresponding to the target driving mode in a timely manner, and achieve seamless switching between different driving scenes.

[0012] In one possible implementation, the data processing module determines the target driving mode of the vehicle at the next moment from the current moment, including: determining the target driving mode of the vehicle at the next moment from the current moment based on the user's selection operation of the driving mode.

[0013] Based on the aforementioned technical means, this application enables the determination of the user's driving mode at the next moment in response to the user's selection of driving mode during the user's driving process, so that the subsequent rendering module can render the driving scene corresponding to the target driving mode in a timely manner, and achieve seamless switching between different driving scenes.

[0014] According to a second aspect of this application, a vehicle-mounted data processing system is provided. The system is deployed in a vehicle and includes a data processing module, a driving domain controller, a parking domain controller, and a rendering module. The data processing module is connected to the driving domain controller, the parking domain controller, and the rendering module, respectively. The driving domain controller sends driving data to the data processing module. The parking domain controller sends parking data to the data processing module. The data processing module determines the target driving mode of the vehicle at the current moment and the next moment. When the target driving mode is driving mode, the data processing module processes the driving data based on a standardized interface between the data processing module and the rendering module, and determines the processed driving data as the target data to be rendered. When the target driving mode is parking mode, the data processing module processes the parking data based on a standardized interface, and determines the processed parking data as the target data to be rendered. The data processing module also sends the target data to be rendered to the rendering module through the standardized interface. The rendering module is used to render the target data to be rendered, obtain the rendered driving scene, and display the rendered driving scene through the vehicle's display device.

[0015] In one possible implementation, driving data includes driving perception data and road map data collected by the driving domain controller, and parking data includes parking perception data and parking lot map data collected by the parking domain controller.

[0016] In one possible implementation, the rendering module includes a 3D engine plugin layer and a business logic layer. The 3D engine plugin layer is used to render models of multiple elements in the driving scene based on the target data to be rendered. The business logic layer is used to render the driving scene based on the models of the multiple elements rendered by the 3D engine plugin.

[0017] In one possible implementation, the rendering module is also used to render the target data to be rendered in response to the user's driving operation, so as to obtain a driving scene corresponding to the driving operation.

[0018] According to a third aspect of this application, a parking data processing apparatus is provided, comprising a data processing module deployed in a vehicle's parking data processing system. The parking data processing system further includes a driving domain controller, a parking domain controller, and a rendering module. The data processing module is connected to the driving domain controller, the parking domain controller, and the rendering module, respectively. The parking data processing apparatus includes a determining unit and a sending unit. The determining unit is used to determine the target driving mode of the vehicle at the current moment and the next moment. The determining unit is also used, when the target driving mode is a driving mode, to process driving data based on a standardized interface between the data processing module and the rendering module, and to determine the processed driving data as target data to be rendered. The determining unit is also used, when the target driving mode is a parking mode, to process parking data based on a standardized interface, and to determine the processed parking data as target data to be rendered. The sending unit is used to send the target data to be rendered to the rendering module through the standardized interface, so that the rendering module renders the vehicle's driving scene based on the target data to be rendered.

[0019] In one possible implementation, driving data includes driving perception data and road map data collected by the driving domain controller, and parking data includes parking perception data and parking lot map data collected by the parking domain controller.

[0020] In one possible implementation, the data processing apparatus further includes a processing unit, configured to perform data format conversion processing on driving data based on a data format supported by a standardized interface, to obtain processed driving data. The processing unit is also configured to perform data format conversion processing on parking data based on a data format supported by a standardized interface, to obtain processed parking data.

[0021] In one possible implementation, the determining unit is specifically used to determine the target driving mode of the vehicle at the current moment and the next moment based on the vehicle's location information and vehicle operation information, including speed, power-on duration, and steering wheel angle.

[0022] In one possible implementation, the determining unit is specifically configured to determine the target driving mode of the vehicle at the current moment for the next moment based on the user's selection of the driving mode.

[0023] According to the fourth aspect provided in this application, an in-vehicle central control device is provided, deployed in a vehicle. The in-vehicle central control device includes a memory and a processor, the memory and the processor being coupled; the memory is used to store computer program code, the computer program code including computer instructions; when the processor executes the computer instructions, the in-vehicle central control device executes the parking data processing method provided in the first aspect and any possible implementation thereof.

[0024] According to the fifth aspect provided in this application, a computer-readable storage medium is provided, which stores instructions that, when executed on an in-vehicle central control device, cause the in-vehicle central control device to perform the parking data processing method provided in the first aspect and any possible implementation thereof.

[0025] According to the sixth aspect provided in this application, a vehicle is provided, including the parking data processing system provided in the second aspect above.

[0026] According to the seventh aspect provided in this application, a computer program product is provided, the computer program product including computer instructions, which, when executed on an in-vehicle central control device, cause the in-vehicle central control device to execute the parking data processing method provided in the first aspect and any possible implementation thereof.

[0027] Therefore, the above-mentioned technical features of this application have the following beneficial effects:

[0028] (1) In the driving and parking data processing method provided in this application, the data processing module first determines the target driving mode of the vehicle at the next moment, and further calls the corresponding data for processing according to the target driving mode to obtain the target data to be rendered. When the target driving mode is driving mode, the driving data sent by the driving domain controller is obtained and processed. When the target driving mode is parking mode, the parking data sent by the parking domain controller is obtained and processed. This allows the data processing module to complete the resource-level switching (switching of the data to be rendered) in the scenario where the vehicle is switching driving modes. The rendering module only needs to render the data to be rendered provided by the data processing module. The display device does not need to switch between the driving scene rendered by the driving domain control system and the driving scene rendered by the parking domain control system. This reduces the user's perception of the driving scene rendered by different driving modes when switching, realizes the seamless switching of driving scenes of different driving modes, that is, integrated driving and parking rendering of driving scenes, and improves the user's driving experience.

[0029] (2) In the driving and parking data processing method provided in this application, the driving data and parking data are processed by the data processing module, and the rendering module is provided with uninterrupted data support based on a unified standardized interface, so that the driving scene corresponding to the driving mode and the driving scene corresponding to the parking mode are seamlessly connected.

[0030] (3) This application realizes that during the process of a user driving a vehicle, it can actively detect whether the user intends to switch driving modes and determine the user's driving mode at the next moment, so that the subsequent rendering module can render the driving scene corresponding to the target driving mode in a timely manner and achieve seamless switching between different driving scenes.

[0031] It should be noted that the technical effects of any of the implementation methods in aspects two through seven can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0033] Figure 1 This is a schematic diagram illustrating the structure of a berthing data processing system according to an exemplary embodiment;

[0034] Figure 2 This is a flowchart illustrating a berthing data processing method according to an exemplary embodiment;

[0035] Figure 3 This is a rendering diagram of a driving scene according to an exemplary embodiment;

[0036] Figure 4 This is an architecture diagram of a berthing data processing system according to an exemplary embodiment;

[0037] Figure 5 This is a driving scenario architecture diagram illustrated according to an exemplary embodiment;

[0038] Figure 6 This is a parking scenario architecture diagram illustrated according to an exemplary embodiment;

[0039] Figure 7 This is a flowchart illustrating yet another method for processing berth data according to an exemplary embodiment;

[0040] Figure 8 This is a block diagram illustrating a berthing data processing apparatus according to an exemplary embodiment;

[0041] Figure 9 This is a block diagram illustrating an in-vehicle central control device according to an exemplary embodiment. Detailed Implementation

[0042] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

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

[0044] In the description of the embodiments, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a description of 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, and B alone. Furthermore, "at least one" and "more than one" refer to two or more. The terms "first," "second," etc., do not limit the quantity or execution order, and "first," "second," etc., do not necessarily imply that they are different.

[0045] With the rapid development of intelligent cockpits and autonomous driving, users' demands for intelligent vehicles are also increasing. When users need to switch from parking mode to driving mode, or vice versa, the driving mode and parking mode typically run on different systems with different data content, types, and formats (e.g., driving mode scene reconstruction requires rendering of high-precision road maps combined with vehicle driving perception data, while parking mode scene reconstruction requires rendering of high-precision parking lot maps combined with parking perception data). This results in a noticeable disconnect when the vehicle switches between the driving scene corresponding to driving mode and the driving scene corresponding to parking mode, causing a significant gap (such as a black screen during the data source and system switching process), which affects the user's driving experience.

[0046] To address the aforementioned problems, this application proposes a parking data processing method, apparatus, device, and system. This method is applied to the data processing module of a vehicle parking data processing system. The parking data processing system also includes a driving domain controller, a parking domain controller, and a rendering module. The data processing module is connected to the driving domain controller, parking domain controller, and rendering module, respectively. The method includes: the data processing module determining the vehicle's target driving mode for the next moment. Further, when the target driving mode is driving mode, the data processing module processes driving data received from the driving domain controller based on a standardized interface between the data processing module and the rendering module, and determines the processed driving data as the target data to be rendered. When the target driving mode is parking mode, the data processing module processes parking data received from the parking domain controller based on a standardized interface, and determines the processed parking data as the target data to be rendered. Further, the data processing module sends the target data to be rendered to the rendering module through the standardized interface, so that the rendering module renders the vehicle's driving scene based on the target data to be rendered.

[0047] In this way, in the driving and parking data processing method provided in this application, the data processing module first determines the target driving mode of the vehicle at the next moment, and further calls the corresponding data for processing according to the target driving mode to obtain the target data to be rendered. Specifically, when the target driving mode is driving mode, driving data sent by the driving domain controller is obtained and processed; when the target driving mode is parking mode, parking data sent by the parking domain controller is obtained and processed. This allows the data processing module to complete the resource-level switching (switching of the data to be rendered) when the vehicle switches driving modes. The rendering module only needs to render the data to be rendered provided by the data processing module. The display device does not need to switch between the driving scene rendered by the driving domain control system and the driving scene rendered by the parking domain control system, reducing the user's perception of the driving scene rendered by different driving modes during the switching process. This achieves seamless switching of driving scenes for different driving modes, that is, integrated driving and parking rendering of driving scenes, improving the user's driving experience.

[0048] Figure 1 This application discloses a berthing data processing system, and the berthing data processing method provided in the embodiments of this application can be applied to, for example, berthing data processing systems. Figure 1 The parking data processing system shown is designed to reduce the user's perception of driving scenarios rendered in different driving modes during transitions, achieving seamless switching between driving scenarios in different driving modes. For example... Figure 1 As shown, the parking data processing system 10 includes a data processing module 11, a driving domain controller 12, a parking domain controller 13, and a rendering module 14.

[0049] The driving and parking data processing system 10 is deployed in the vehicle, and the data processing module 11 is connected to the driving domain controller 12, the parking domain controller 13 and the rendering module 14 respectively.

[0050] In some embodiments, the data processing module 11 and the rendering module 14 are deployed on the vehicle's central control device. Based on the Ethernet vehicle network connection between the central control device and the driving domain controller 12 and the parking domain controller 13, the data processing module 11 is connected to the driving domain controller 12 and the parking domain controller 13, respectively.

[0051] Both the driving domain controller 12 and the parking domain controller 13 operate independently in their respective modules or subsystems, and independently send data out in binary form using a protocol buffer.

[0052] The vehicle domain controller 12 connects to multiple vehicle chips and sensors, such as forward-looking cameras, millimeter-wave radar and other sensing devices. It can be used to transmit external data collected by the sensing devices, such as pedestrians, motor vehicles, blind spot warnings, lane lines, road surface effects, road width, slope, ramps, tunnels and other lane scenes, traffic lights, road signs and other traffic sign scenes, adaptive cruise control (ACC), automatic high beam display and automatic lane changing and other driving data.

[0053] The parking domain controller 13 connects to multiple parking chips and sensors, such as fisheye cameras and ultrasonic radar, and can be used to send out parking data collected by the sensing devices for scenarios such as automatic parking, remote parking, one-click tracking, automatic emergency braking, remote vehicle relocation, short-range valet parking, one-click summoning, unmanned remote memory parking, unmanned remote valet parking, and last-mile valet parking.

[0054] The data processing module 11 can be used to parse the driving data or parking data sent by the driving domain controller 12 or the parking domain controller 13 locally, and perform logical checks such as security and timeliness on the parsed data. Furthermore, after the data verification is completed, the data processing module 11 can also be used to standardize the verified data and send the processed data to the rendering module 14 through a standardized API interface.

[0055] The rendering module 14 can be used to render the data sent by the data processing module 11 after receiving the data, and obtain the rendered driving scene of the vehicle. The driving scene of the vehicle can then be displayed on the vehicle's display device through the integrated driving and parking APP.

[0056] The rendering module 14 can also be used to render the driving scene of the vehicle corresponding to the user's driving operation.

[0057] In some embodiments, based on such Figure 1 The parking data processing system 10 shown below implements the following specific execution steps for each device to reduce the user's perception of the driving scene rendered by different driving modes during switching and to achieve seamless switching between driving scenes of different driving modes.

[0058] The vehicle domain controller 12 can be used to send vehicle data to the data processing module 11.

[0059] The parking domain controller 13 can be used to send parking data to the data processing module 11.

[0060] The data processing module 11 can be used to determine the target driving mode of the vehicle at the current moment and the next moment.

[0061] The driving modes include driving mode and parking mode.

[0062] The data processing module 11 is also used to process driving data based on the standardized interface between the data processing module 11 and the rendering module 14 when the target driving mode is driving mode, and to determine the processed driving data as the target data to be rendered.

[0063] The data processing module 11 is also used to process parking data based on a standardized interface when the target driving mode is parking mode, and to determine the processed parking data as the target data to be rendered.

[0064] The data processing module 11 is also used to send the target data to be rendered to the rendering module 14 through a standardized interface;

[0065] The rendering module 14 is used to render the target data to be rendered, obtain the rendered driving scene, and display the rendered driving scene through the vehicle's display device.

[0066] In some embodiments, driving data includes driving perception data and road map data collected by the driving domain controller, and parking data includes parking perception data and parking lot map data collected by the parking domain controller.

[0067] The data processing module 11 is also used to generate target data to be rendered based on the driving perception data and road map data included in the driving data when the target driving mode is driving mode.

[0068] The data processing module 11 is also used to generate target rendering data based on parking perception data and parking lot map data included in the parking data when the target driving mode is parking mode.

[0069] In some embodiments, the rendering module 14 includes a 3D engine plugin layer and a business logic layer.

[0070] The 3D engine plugin layer can be used to obtain the target data to be rendered sent by the data processing module 11 through a standardized API interface, and to model multiple elements such as pedestrians, vehicles, and trees.

[0071] The 3D engine plugin layer can also be used to process multiple rendered elements in the mesh, such as vertex position, normal vector, texture coordinates, face and object material, and then send them to the graphics processing unit (GPU) for rendering.

[0072] The 3D engine plugin layer can also be used to transmit data that needs to be logically controlled and processed by the business logic layer to the business logic layer for processing.

[0073] The business logic layer can be used to obtain rendering data from the 3D engine plugin layer through shared memory or JSB, and then control the display and business logic of 3D rendering business UI components, user touch events, camera angles, etc.

[0074] In summary, the 3D engine plugin layer can be used to render models of multiple elements in a driving scene based on the target data to be rendered.

[0075] The business logic layer can be used to render driving scenarios based on models of multiple elements rendered by the 3D engine plugin.

[0076] The business logic layer can also be used to respond to user driving operations, render the target data to be rendered, and obtain the driving scenario corresponding to the domain driving operation.

[0077] For example, if a user's speed suddenly increases from a low speed (20 km / h) to a high speed (70 km / h), the business logic layer responds to the user's speed-up driving operation by raising the rendered camera's field of view to allow the user to obtain more information through the vehicle's display device. This results in the rendered driving scene including more information to assist the user in driving the vehicle.

[0078] Figure 2 This is a flowchart illustrating a berthing data processing method according to some exemplary embodiments. In some embodiments, the above-described berthing data processing method can be applied to, for example... Figure 1The data processing module 11 in the berthing data processing system 10 shown is illustrated below. Hereinafter, this application embodiment will describe the above-described berthing data processing method by taking the application of the berthing data processing method to the data processing module 11 as an example.

[0079] like Figure 2 As shown, the berthing data processing method provided in this application includes the following steps S201-S204.

[0080] S201, The data processing module determines the target driving mode of the vehicle at the next moment from the current moment.

[0081] The driving modes include driving mode and parking mode.

[0082] As one possible implementation, the data processing module obtains the vehicle's operating parameters at the current moment, inputs the vehicle's operating parameters at the current moment into the preset neural network model based on the preset neural network model used to predict the vehicle's driving mode at the next moment, and determines the output of the preset neural network model as the target driving mode.

[0083] It should be noted that the preset neural network model can be set in advance in the data processing module by the operation and maintenance personnel of the parking data processing system. The preset neural network model can be trained in a supervised manner based on the user's historical driving data, the driving data at the first moment and the driving mode at the second moment. The second moment is the moment after the first moment. This application embodiment does not make specific limitations on this.

[0084] In some embodiments, the data processing module determines the target driving mode of the vehicle at the next moment, and may further include:

[0085] The data processing module acquires the vehicle's location information and vehicle operation information, including speed, power-on time, and steering wheel angle.

[0086] Furthermore, the data processing module determines the vehicle's target driving mode for the next moment based on the vehicle's location information and vehicle operation information.

[0087] For example, if the data processing module obtains the vehicle's location information and finds that the vehicle is inside the parking lot, and the vehicle's power-on time is less than a first preset time and its speed is less than a first preset speed, then it determines that the vehicle is in the scenario of parking out of the parking lot, and thus determines that the target driving mode for the vehicle in the next moment is the parking mode.

[0088] Furthermore, if the data processing module determines that the vehicle's location is at the intersection of the parking lot and the road, and the steering wheel is pointing towards the road, then the data processing module determines that the vehicle is about to leave the parking lot and enter the road, thus determining that the vehicle's target driving mode for the next moment is the driving mode.

[0089] If the data processing module determines that the vehicle's location information is on the road and its speed is greater than the second preset speed, then the data processing module determines that the vehicle is in a road driving scenario, and thus determines that the target driving mode for the vehicle in the next moment is the driving mode.

[0090] If the data processing module determines that the vehicle's location information is on a road and there is a parking lot within the first preset range, then if the steering wheel angle is pointing towards the parking lot, the data processing module determines that the vehicle is in a scenario of entering the parking lot for parking, and thus determines that the target driving mode for the vehicle in the next moment is the parking mode; if the steering wheel angle is pointing towards the road driving direction, then the vehicle is in a road driving scenario, and thus determines that the target driving mode for the vehicle in the next moment is the driving mode.

[0091] In some examples, if a user's historical driving behavior is relatively fixed—for instance, the user typically starts the vehicle within a first preset time period, drives from the first parking lot onto the road, and enters the second parking lot within a second preset time period (e.g., the user starts the vehicle between 8:00-8:15 AM to drive from the first parking lot to the company, and enters the company's second parking lot to park between 8:30-8:45 AM)—then the data processing module, based on the user's historical driving data, determines the target driving mode as parking mode after the vehicle starts, as driving mode when about to leave the first parking lot, and as parking mode when about to enter the second parking lot.

[0092] It should be noted that the first preset duration, the first preset speed, the second preset speed, and the first preset range can be preset in the data processing module by the operation and maintenance personnel of the Xingbo data processing system. This application embodiment does not specifically limit this.

[0093] In some embodiments, the data processing module determines the target driving mode of the vehicle at the next moment, and may further include:

[0094] The data processing module responds to the user's active switching of driving modes and determines the vehicle's target driving mode for the next moment.

[0095] For example, the data processing module determines the vehicle's target driving mode for the next moment based on the user's selection of the driving mode.

[0096] It should be noted that the user's operation of selecting the driving mode can be exemplified by clicking the driving mode selection control on the vehicle's display device, by the user issuing a voice command to select the driving mode, or by selecting the driving mode using the driving mode selection button set on the vehicle. This application embodiment does not specifically limit this.

[0097] For example, if a user selects to switch to parking mode while the vehicle is in motion, the data processing module determines that the target driving mode for the next moment is parking mode; if a user selects to switch to driving mode while the vehicle is in motion, the data processing module determines that the target driving mode for the next moment is driving mode.

[0098] If the user issues a command to switch driving modes while the vehicle is in motion, the data processing module determines the current driving mode. If the current driving mode is driving mode, the data processing module determines the target driving mode for the vehicle in the next moment to be parking mode. If the current driving mode is parking mode, the data processing module determines the target driving mode for the vehicle in the next moment to be driving mode.

[0099] S202. When the target driving mode is driving mode, the data processing module processes the driving data received from the driving domain controller based on the standardized interface between the data processing module and the rendering module, and determines the processed driving data as the target data to be rendered.

[0100] As one possible implementation, the data processing module determines the data format supported by the standardized interface between the data processing module and the rendering module. Based on the target driving mode determined in step S201 above, when the target driving mode is driving mode, the driving data received from the driving domain controller is converted into a data format that is supported by the standardized interface, and the processed driving data is determined as the target data to be rendered.

[0101] In some embodiments, the driving domain controller is configured to send the collected driving data to the data processing module after receiving driving data collected by each sensing device in the driving subsystem.

[0102] Optionally, driving data includes driving perception data collected by various sensing devices in the driving subsystem and road map data.

[0103] In some embodiments, when the target driving mode is determined to be a driving mode, the data processing module parses the driving data received from the driving domain controller and performs logical checks such as security and timeliness on the parsed data. Further, after the data checks are completed, the data processing module converts the driving data according to the data format supported by the interface protocol of the standardized interface between the data processing module and the rendering module, and determines the processed driving data as the target data to be rendered, so that the rendering module can render the vehicle's driving scene after receiving the target data to be rendered from the data processing module.

[0104] S203. When the target driving mode is parking mode, the data processing module processes the parking data received from the parking domain controller based on a standardized interface, and determines the processed parking data as the target data to be rendered.

[0105] As one possible implementation, the data processing module determines the data format supported by the standardized interface between the data processing module and the rendering module. Based on the target driving mode determined in step S201 above, when the target driving mode is parking mode, the parking data received from the parking domain controller is converted into a parking data format that is supported by the standardized interface, and the processed parking data is determined as the target data to be rendered.

[0106] In some embodiments, the parking domain controller is configured to send the collected parking data to the data processing module after receiving parking data collected by each sensing device in the parking subsystem.

[0107] Optionally, parking data includes parking perception data collected by various sensing devices in the parking subsystem and parking lot map data.

[0108] It should be noted that the data interaction between the data processing module and the driving domain controller is independent of the data interaction between the data processing module and the parking domain controller and does not affect each other.

[0109] In some embodiments, when the target driving mode is determined to be parking mode, the data processing module parses the parking data received from the parking domain controller and performs logical checks such as security and timeliness on the parsed data. Further, after the data checks are completed, the data processing module converts the parking data according to the data format supported by the interface protocol of the standardized interface between the data processing module and the rendering module, and determines the processed parking data as the target data to be rendered, so that the rendering module can render the vehicle's driving scene after receiving the target data to be rendered from the data processing module.

[0110] S204. The data processing module sends the target data to be rendered to the rendering module through a standardized interface, so that the rendering module can render the vehicle's driving scene based on the target data to be rendered.

[0111] As one possible implementation, after the data processing module determines the target data to be rendered based on the above steps S202 or S203, it sends the target data to be rendered to the rendering module through the standardized interface between the data processing module and the rendering module.

[0112] Correspondingly, the rendering module receives the target data to be rendered sent by the data processing module through a standardized interface, and renders the vehicle's driving scene based on the target data to be rendered.

[0113] For example, Figure 3 This diagram illustrates a driving scene rendering in a parking scenario. Based on parking perception data (parking lines, vehicles, buildings, etc.) collected by the parking domain controller and high-precision parking lot map data, the driving scene of the vehicle is reconstructed on the vehicle's display device to assist the user in parking the vehicle.

[0114] In some embodiments, the elements included in scene reconstruction rendering in the driving scenario of a vehicle in driving mode are shown in Table 1 below.

[0115] Table 1: Rendering Element Table

[0116]

[0117]

[0118]

[0119] It should be noted that in the driving scenario of a vehicle in driving mode, the elements included in the scene reconstruction rendering are not limited to the elements corresponding to each function shown in Table 1 above. Table 1 is only an example showing some elements, and this application embodiment does not make specific limitations on them.

[0120] Understandably, in the driving and parking data processing method provided in the above embodiments of this application, the data processing module first determines the target driving mode of the vehicle at the next moment, and further calls the corresponding data for processing according to the target driving mode to obtain the target data to be rendered. Specifically, when the target driving mode is driving mode, driving data sent by the driving domain controller is obtained and processed; when the target driving mode is parking mode, parking data sent by the parking domain controller is obtained and processed. This allows the data processing module to complete the resource-level switching (switching of the data to be rendered) when the vehicle is switching driving modes. The rendering module only needs to render the data to be rendered provided by the data processing module. The display device does not need to switch between the rendered driving scene provided by the driving domain control system and the rendered driving scene provided by the parking domain control system, reducing the user's perception of the driving scene rendered by different driving modes during the switching process. This achieves seamless switching of driving scenes of different driving modes, that is, integrated driving and parking rendering of driving scenes, improving the user's driving experience.

[0121] In some embodiments, Figure 4 An architecture diagram of a parking data processing system is shown, including a driving domain controller 31, a parking domain controller 32, and a central control device 33. The central control device 33 is connected to both the driving domain controller and the parking domain controller via an in-vehicle Ethernet connection.

[0122] The central control device 33 includes: a hardware layer 331 that carries the operating system, a framework layer 332 that provides software support, a data processing module 333, an interface layer 334, a rendering module 335, and an integrated APP layer 336 that provides display support; the rendering module 335 includes a 3D engine C++ plugin layer for data preprocessing, mesh calculation and other functions, and a transaction script (TS) business logic layer that provides data conversion, GPU acceleration and other functions.

[0123] After acquiring driving data or parking data via Ethernet and processing it using the method described in the above embodiments, the data processing module 333 transmits it to the rendering module 335 via the interface layer 334.

[0124] The data processing module 333 includes several functions, such as the Data Parse method, the Verify method, and the Fusion method.

[0125] In rendering module 335, the 3D engine C++ plugin layer obtains driving or parking data through a standardized interface, performs 3D rendering preprocessing and mesh calculation on the data, and then passes it to the TS business logic layer through the interface bound to the TS business logic layer.

[0126] The TS business logic layer obtains rendering data from the 3D engine C++ plugin layer through shared memory or JavaScript bindings (JSB), and then controls the display and business logic of the 3D rendering page UI components, user touch events, camera angles, etc.

[0127] Specifically, the TS business logic layer obtains rendering data from the 3D engine C++ plugin layer through shared memory or JSB, converts it into the corresponding entity class, object or byte array of TS, and then, after processing based on UI display logic, calls the underlying engine library function to convert it into GPU quality for GPU accelerated rendering.

[0128] The Xingbo Integrated APP layer 336 provides a display window for the TS business logic layer and interacts with it, transmitting underlying hardware data and status, responding to user operation commands in the TS business logic layer, and combining 2D display View components and Java functional logic code to complete the rendering of the entire business module.

[0129] The integrated APP layer 336 provides a display window for the rendering module 335 through SurfaceView / TextureView, and completes command transmission and state synchronization with the 3D rendering module through the EngineEffect interface. The integrated APP layer 336 integrates 2D UI components or Activity pages, functional logic and other modules. The integrated APP layer 336 is also used to pass the user's touch events to the rendering module 335 through the window, and to send back the instructions processed by the rendering module 335 to the integrated APP layer 336.

[0130] In some embodiments, Figure 5 The diagram illustrates a driving scenario architecture, which includes a driving domain controller and a central control device. The driving domain controller is connected to the central control device via an in-vehicle Ethernet network.

[0131] The driving domain controller includes stored high-precision maps and perception data collected through vehicle system detection / monitoring. The perception data includes positioning information, cruise data, driving data, collision avoidance data, drivable areas, and other data.

[0132] The central control device includes a hardware layer, an engine core layer, a 3D engine capability layer, and an application layer.

[0133] The hardware layer includes in-vehicle infotainment (IVI) systems, sensors, etc.; the engine core layer includes engine configuration, memory, asset manager, and rendering scene, etc.; the 3D engine capability layer includes engine components, rendering, audio, profiling and debugging, etc.; and the application layer includes driving rendering applications.

[0134] In some embodiments, Figure 6 This diagram illustrates a parking scenario architecture, which includes a parking domain controller, a central control unit, and a cloud server. The parking domain controller is connected to the central control unit via an in-vehicle Ethernet network, and the central control unit is connected to the cloud server via a network.

[0135] The parking domain controller includes a smart chip (SVDC) and a remote valet parking system (APA). The SVDC is used for file uploads, big data uploads, Ethernet signal uploads, vehicle status signal uploads, and map uploads. It also supports over-the-air (OTA) downloads, map list downloads, mobile phone control, and setting signal distribution. The remote valet parking system supports positioning modules, OD monitoring, garage navigation, parking space location information, drivable area information, cruise control, parking functions, collision avoidance, and other functions. It also supports perception data generated by vehicle system detection / monitoring, including global path planning, predictive decision-making, local path planning, trajectory, vehicle speed, acceleration, and control. The remote valet parking system also supports OTA, firmware OTA (FOTA), and software OTA (SOTA).

[0136] The central control unit includes HZP memory parking map application, automated valet parking (AVP) map application, and global navigation satellite system (GNSS) map application. It also includes receiving parking instructions sent by users and interacting with cloud services (payment integration and parking space reservation, etc.).

[0137] The cloud server is used to respond to control signals or request signals issued by the central control equipment, providing high-precision road map data from map providers and high-precision parking map data from parking lot operators. High-precision road map data includes road information, parking space information, and positioning elements, while high-precision parking map data includes garage roads, merchant information, parking space vacancy status, gate opening and closing, and video surveillance data.

[0138] In one design, the berthing data processing method provided in the above embodiments of this application and Figure 4 The berthing data processing system shown, the berthing data processing method is as follows: Figure 7 As shown, it also includes S401-S405.

[0139] The S401, driving domain controller, and parking domain controller send driving data and parking data to the central control equipment via the vehicle Ethernet, respectively.

[0140] S402, the data processing module acquires driving data and parking data, performs parsing, verification, and data format conversion, and sends the processed data to the 3D engine C++ plugin for rendering through a standardized interface.

[0141] The S403 and 3D engine C++ plugins receive the data to be rendered through standardized interfaces, perform 3D rendering preprocessing and mesh calculation on the data, and then send it to the TS business logic layer through the interface bound to the TS business logic layer.

[0142] After acquiring data, the S404 and TS business logic layers control the display and business logic of 3D rendering page UI components, user touch events, camera angles, etc.

[0143] The S405 and the integrated APP layer provide a display window for the TS business logic layer and interact with it, transmitting underlying hardware data and status, responding to user operation commands from the TS business logic layer, and combining 2D display window components and Java functional logic code to complete the rendering and display of driving scenarios.

[0144] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the data processing module includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0145] This application embodiment can, based on the above method, exemplarily divide the data processing module into functional modules. For example, the data processing module may include various functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0146] Figure 8 This is a schematic diagram of a berthing data processing device provided in an embodiment of this application. This berthing data processing device is used to execute the above-described berthing data processing method. Figure 8 As shown, the berthing data processing device 50 includes a determining unit 501 and a sending unit 502.

[0147] The determining unit 501 is used to determine the target driving mode of the vehicle at the current moment and the next moment.

[0148] The determining unit 501 is also used to process driving data based on the standardized interface between the data processing module and the rendering module when the target driving mode is driving mode, and to determine the processed driving data as the target data to be rendered.

[0149] The determining unit 501 is also used to process parking data based on a standardized interface when the target driving mode is parking mode, and to determine the processed parking data as the target data to be rendered.

[0150] The sending unit 502 is used to send the target data to be rendered to the rendering module through a standardized interface, so that the rendering module can render the driving scene of the vehicle based on the target data to be rendered.

[0151] Optionally, driving data includes driving perception data and road map data collected by the driving domain controller, and parking data includes parking perception data and parking lot map data collected by the parking domain controller.

[0152] Optionally, the data processing device 50 may also include a processing unit 503.

[0153] The processing unit 503 is used to perform data format conversion processing on the driving data based on the data format supported by the standardized interface, so as to obtain the processed driving data.

[0154] The processing unit 503 is also used to perform data format conversion processing on the parking data based on the data format supported by the standardized interface, so as to obtain the processed parking data.

[0155] Optionally, the determining unit 501 is specifically used to determine the target driving mode of the vehicle at the current moment and the next moment based on the vehicle's location information and vehicle operation information. The vehicle operation information includes speed, power-on duration, and steering wheel angle.

[0156] Optionally, the determining unit 501 is specifically used to determine the target driving mode of the vehicle at the current moment and the next moment based on the user's selection operation of the driving mode.

[0157] Figure 9 This is a block diagram illustrating an in-vehicle central control device according to an exemplary embodiment. For example... Figure 9 As shown, the in-vehicle central control device 60 includes, but is not limited to, a processor 601 and a memory 602.

[0158] The memory 602 described above is used to store the executable instructions of the processor 601. It is understood that the processor 601 is configured to execute instructions to implement the berthing data processing method in the above embodiments.

[0159] It should be noted that those skilled in the art will understand that Figure 9 The structure of the in-vehicle central control device shown does not constitute a limitation on the in-vehicle central control device; the in-vehicle central control device may include, but is not limited to, other types of devices. Figure 9 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0160] The processor 601 is the control center of the in-vehicle central control device. It connects various parts of the device via interfaces and lines, and executes software programs and / or modules stored in the memory 602, as well as calling data stored in the memory 602, to perform various functions and process data, thereby providing overall monitoring of the in-vehicle central control device. The processor 601 may include one or more processing units. Optionally, the processor 601 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0161] The memory 602 can be used to store software programs and various data. The memory 602 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0162] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 602 including instructions, which can be executed by a processor 601 of an in-vehicle central control device 60 to implement the parking data processing method in the above embodiments.

[0163] In actual implementation, Figure 8 The functions of the determining unit 501, the sending unit 502, and the processing unit 503 can all be provided by... Figure 9 The processor 601 calls the computer program stored in the memory 602 to implement the process. The specific execution process can be found in the description of the berthing data processing method in the previous embodiment, and will not be repeated here.

[0164] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0165] In an exemplary embodiment, this application also provides a vehicle including the above-described in-vehicle central control device.

[0166] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 601 of the vehicle central control device to complete the parking data processing method in the above embodiments.

[0167] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of the vehicle central control device, they implement the various processes of the above-described parking data processing method embodiment and can achieve the same technical effect as the above-described parking data processing method. To avoid repetition, they will not be described again here.

[0168] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0169] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0170] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the classified units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0171] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0172] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, essentially, or the part that contributes to the prior art, or a complete or partial classification of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0173] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for processing data of a ship, characterized by, The method includes: Determine the target driving mode for the vehicle in the next moment from the current moment; When the target driving mode is driving mode, the driving data received from the driving domain controller is processed based on the standardized interface between the data processing module and the rendering module, and the processed driving data is determined as the target data to be rendered. When the target driving mode is parking mode, the parking data received from the parking domain controller is processed based on the standardized interface, and the processed parking data is determined as the target data to be rendered. The target data to be rendered is sent to the rendering module through the standardized interface, so that the rendering module can render the driving scene of the vehicle based on the target data to be rendered.

2. The method of claim 1, wherein, The driving data includes driving perception data and road map data collected by the driving domain controller, and the parking data includes parking perception data and parking lot map data collected by the parking domain controller.

3. The berthing data processing method according to claim 1, characterized in that, The standardized interface between the data processing module and the rendering module is used to process the driving data received from the vehicle domain controller, including: Based on the data format supported by the standardized interface, the driving data is converted to obtain the processed driving data. The process of processing parking data received from the parking domain controller based on the standardized interface includes: Based on the data format supported by the standardized interface, the parking data is converted to obtain the processed parking data.

4. The berthing data processing method according to any one of claims 1-3, characterized in that, Determining the target driving mode for the vehicle at the current moment and the next moment includes: Based on the vehicle's location information and vehicle operation information, the target driving mode of the vehicle at the next moment is determined. The vehicle operation information includes speed, power-on duration, and steering wheel angle.

5. The berthing data processing method according to any one of claims 1-3, characterized in that, Determining the target driving mode for the vehicle at the current moment and the next moment includes: Based on the user's selection of driving mode, the target driving mode of the vehicle at the next moment is determined.

6. A berthing data processing system, characterized in that, The driving and parking data processing system is deployed in the vehicle and includes a data processing module, a driving domain controller, a parking domain controller, and a rendering module. The data processing module is connected to the driving domain controller, the parking domain controller, and the rendering module, respectively. The vehicle domain controller is used to send vehicle data to the data processing module; The parking domain controller is used to send parking data to the data processing module; The data processing module is used to determine the target driving mode of the vehicle at the current moment and the next moment. The data processing module is also used to process the driving data based on the standardized interface between the data processing module and the rendering module when the target driving mode is driving mode, and to determine the processed driving data as the target data to be rendered. The data processing module is also used to process the parking data based on the standardized interface when the target driving mode is parking mode, and to determine the processed parking data as the target data to be rendered. The data processing module is also used to send the target data to be rendered to the rendering module through the standardized interface; The rendering module is used to render the target data to be rendered, obtain the rendered driving scene, and display the rendered driving scene through the vehicle's display device.

7. The berthing data processing system according to claim 6, characterized in that, The driving data includes driving perception data and road map data collected by the driving domain controller, and the parking data includes parking perception data and parking lot map data collected by the parking domain controller.

8. The berthing data processing system according to claim 6 or 7, characterized in that, The rendering module includes a 3D engine plugin layer and a business logic layer. The 3D engine plugin layer is used to render models of multiple elements in the driving scene based on the target data to be rendered; The business logic layer is used to render driving scenes based on models of multiple elements rendered by the 3D engine plugin.

9. The berthing data processing system according to claim 6 or 7, characterized in that, The rendering module is also used to render the target data to be rendered in response to the user's driving operation, so as to obtain a driving scene corresponding to the driving operation.

10. A berthing data processing device, characterized in that, A data processing module is deployed in a vehicle parking data processing system. The parking data processing system further includes a vehicle domain controller, a parking domain controller, and a rendering module. The data processing module is connected to the vehicle domain controller, the parking domain controller, and the rendering module, respectively. The parking data processing device includes a determining unit and a sending unit. The determining unit is used to determine the target driving mode of the vehicle at the current moment and the next moment. The determining unit is further configured to, when the target driving mode is driving mode, process the driving data based on the standardized interface between the data processing module and the rendering module, and determine the processed driving data as the target data to be rendered. The determining unit is further configured to, when the target driving mode is parking mode, process the parking data based on the standardized interface, and determine the processed parking data as the target data to be rendered. The sending unit is used to send the target data to be rendered to the rendering module through the standardized interface, so that the rendering module can render the driving scene of the vehicle based on the target data to be rendered.

11. A vehicle-mounted central control device, characterized in that, Including memory and processor; The memory and the processor are coupled; The memory is used to store computer program code, which includes computer instructions; When the processor executes the computer instructions, the vehicle-mounted central control device performs the parking data processing method as described in any one of claims 1-5.

12. A computer-readable storage medium storing instructions, characterized in that, When the instruction is executed on the vehicle-mounted central control device, the vehicle-mounted central control device performs the parking data processing method as described in any one of claims 1-5.

13. A vehicle, characterized in that, Including the vehicle-mounted central control device as described in claim 11.

Citation Information

Patent Citations

  • Self-Driving Simulation Rendering Method and Apparatus, Device, and Readable Medium

    US20230351685A1

  • Automatic driving vehicle, Anti-theft system of automatic driving vehicle, Anti-theft program of automatic driving vehicle, terminal control program, and rental method of automatic driving vehicle

    WO2015056530A1