Data processing method of dual-optical-path vehicle-mounted ARHUD system based on YTS engine

Abstract

The invention provides a data processing method of a dual-optical-path vehicle-mounted ARHUD system based on a YTS engine, the dual-optical-path vehicle-mounted ARHUD system at least comprises a near-field PGU, a far-field PGU, an edge computing node, the YTS engine and a vehicle-mounted terminal, the vehicle-mounted terminal collects first near-field data according to a first frequency, collects first far-field data according to a second frequency, and uploads the first near-field data to the YTS engine; the YTS engine responds to the data processing request and determines a target node used for executing a data processing task according to received first near-field data or first far-field data, and the target node comprises one of a vehicle-mounted terminal, an edge computing node and the YTS engine; the target node generates corresponding to-be-displayed data based on the received data so as to complete a data processing task; and the near-field PGU or the far-field PGU projects a virtual image in the head-up display area of the vehicle based on the received data to be displayed.

Description

Technical Field

[0001] The present application relates to the field of vehicle-related technologies, and in particular to a data processing method for a dual-light-path vehicle-mounted ARHUD system based on a YTS engine. Background Art

[0002] With the continuous development of automotive intelligent technology, augmented reality head-up display system (ARHUD) as an innovative in-vehicle intelligent system has received widespread attention.

[0003] In a dual-optical path HUD system, different PGUs have different functional divisions, data source dependencies, and technical requirements when displaying image data. This difference may lead to inconsistency in the data displayed by each PGU, affecting the overall display effect and user experience.

[0004] Therefore, how to set the data processing mechanism of different PGUs has become the key to optimizing and enhancing the display effect and ensuring the synchronization of information. Summary of the invention

[0005] The purpose of the embodiment of the present application is to provide a data processing method for a dual-light-path vehicle-mounted ARHUD system based on a YTS engine, and to enhance the synchronization effect of information display of the head-up display system through reasonable data processing management of the head-up display system.

[0006] In a first aspect, the present invention provides a data processing method for a dual-light-path vehicle-mounted ARHUD system, wherein the dual-light-path vehicle-mounted ARHUD system comprises at least a near-field PGU, a far-field PGU, an edge computing node, a YTS engine, and a vehicle-mounted terminal, wherein the vehicle-mounted terminal collects first near-field data according to a first frequency, collects first far-field data according to a second frequency, and uploads the data to the YTS engine; The YTS engine responds to the data processing request and determines a target node for executing the data processing task for the received first near-field data or the first far-field data, where the target node includes one of the vehicle terminal, the edge computing node, and the YTS engine; The target node generates corresponding data to be displayed based on the received data to complete the data processing task; The near-field PGU or the far-field PGU projects a virtual image in the vehicle's head-up display area based on the received data to be displayed.

[0007] In an optional embodiment, when the first near-field data is received, the YTS engine determines the target processing node by: determining whether processing optimization conditions are met; If the processing optimization condition is not met, the data processing request is parsed to determine the data type of the data to be processed; For each data type, determine the execution time of the edge computing node's last execution of the data processing subtask corresponding to the data type, so as to determine the edge computing node with the shortest total execution time as the target processing node.

[0008] In an optional implementation manner, before the step of determining the target processing node, the method further includes: Determine whether the amount of unprocessed tasks in the current data processing task queue of the edge computing node with the shortest total execution time is greater than a preset task amount threshold; If yes, re-determine the pre-selected edge computing node and return to the previous step; If not, the pre-selected edge computing node is determined to be the target processing node.

[0009] In an optional embodiment, when the first far-field data is received, the YTS engine determines the target processing node by: determining whether processing optimization conditions are met; If the processing optimization condition is not met, the data processing request is parsed to determine the data type of the data to be processed; For each data type, determine the execution time of the edge computing node and the YTS engine when they last executed the data processing subtask corresponding to the data type, so as to determine the edge computing node with the shortest total execution time as the target processing node or determine the YTS engine as the target processing node.

[0010] In an optional implementation, when the time point at which the vehicle-mounted terminal uploads the first near-field data coincides with the time point at which the first far-field data is uploaded, the vehicle-mounted terminal reconstructs the first near-field data and the first far-field data into second near-field data, second far-field data and specific data, where the specific data is data of the same data type as the first far-field data and the first near-field data. The YTS engine determines whether the processing optimization condition is met in the following manner: determining whether specific data is received; If so, it is determined that the processing optimization condition is met.

[0011] In an optional embodiment, when it is determined that the processing optimization conditions are met, the YTS engine determines the target processing node in the following manner: Determining the vehicle-mounted terminal as a first target processing node corresponding to specific data; Determine an edge computing node with the shortest total execution time for the second near-field data as a second target processing node; The YTS engine is determined to be a third target processing node corresponding to the second far-field data and the specific data.

[0012] In an optional implementation, the vehicle-mounted terminal generates the first graphic data based on local specific data. The vehicle-mounted terminal obtains second graphic data generated by the edge computing node according to the second near-field data; The vehicle terminal generates first data to be displayed based on the first graphic data and the second graphic data, and sends the data to the near-field PGU.

[0013] In an optional implementation, the YTS engine generates second data to be displayed based on the second far-field data and the specific data, and sends the second data to the vehicle terminal; The vehicle-mounted terminal forwards the second data to be displayed to the far-field PGU.

[0014] In an optional implementation, the execution time is the time from when the edge computing node receives the data to be processed to when the corresponding graphic data is sent to the vehicle terminal.

[0015] In an optional implementation, the YTS engine converts the 2D second data to be displayed into 3D second data to be displayed.

[0016] The present application provides a data processing method for a dual-light path vehicle-mounted ARHUD system, wherein the dual-light path vehicle-mounted ARHUD system at least includes a near-field PGU, a far-field PGU, an edge computing node, a YTS engine, and a vehicle-mounted terminal, wherein the vehicle-mounted terminal collects first near-field data at a first frequency, collects first far-field data at a second frequency, and uploads them to the YTS engine; the YTS engine responds to a data processing request, and determines a target node for performing a data processing task for the received first near-field data or first far-field data, and the target node includes one of the vehicle-mounted terminal, the edge computing node, and the YTS engine; the target node processes the first near-field data or the first far-field data, generates corresponding data to be displayed, and completes the data processing task; the near-field PGU or the far-field PGU projects a virtual image in the vehicle head-up display area based on the received data to be displayed. Through reasonable data processing management of the head-up display system, the synchronization effect of the information display of the head-up display system is enhanced. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 A schematic diagram of the structure of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine provided in an embodiment of the present application; Figure 2 A flow chart of the communication of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine provided in an embodiment of the present application; Figure 3 A schematic diagram of the projection principle of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine provided in an embodiment of the present application.

[0019] Reference numerals: Vehicle terminal-10, YTS engine-20, edge computing node-30, far-field PGU-40, near-field PGU-50. DETAILED DESCRIPTION

[0020] First, the application scenario of the technical solution of the present application is described. The technical solution of the present application can be applied to the data processing and management of the dual-light path vehicle-mounted ARHUD system.

[0021] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0022] Figure 1 A schematic diagram of the structure of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine provided in an embodiment of the present application. Figure 2 A flow chart of the communication of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine is provided in an embodiment of the present application.

[0023] like Figure 1 As shown, the present invention provides a dual-light-path vehicle-mounted ARHUD system based on a YTS engine. The dual-light-path vehicle-mounted ARHUD system at least includes a near-field PGU, a far-field PGU, an edge computing node, a YTS engine and a vehicle-mounted terminal.

[0024] Among them, the near-field PGU and far-field PGU in the dual-light path vehicle ARHUD system are highly consistent in data source and security requirements, but there are differences in functional positioning, optical design and data processing complexity. The near-field PGU focuses on the high-reliability display of basic information, while the far-field PGU focuses on the dynamic fusion of AR content. The two achieve a more immersive interactive experience through collaborative division of labor. The display principle of the dual-light path vehicle ARHUD system can be as follows: Figure 3 shown.

[0025] Near-field PGU usually displays traditional HUD content, is responsible for generating close-range display content (such as vehicle speed, fuel level, simple navigation arrows), focuses on the driver's line of sight (VID is about 2-3 meters), and has a low content update frequency. It usually uses high-brightness micro-display technology (such as DLP, LCoS or laser scanning) to ensure visibility in strong light environments. And adopts a low-latency design (<10ms) to synchronize with vehicle sensors in real time. It can also support dynamic focus to adapt to changes in the driver's line of sight.

[0026] The far-field PGU is responsible for AR enhanced display and generates long-distance augmented reality content (such as lane-level navigation, pedestrian markings, and collision warnings). The virtual image distance is farther (VID ≥ 7.5 meters), and it needs to dynamically match the road environment, and the data update frequency is higher. It usually has a high resolution (such as 1920×720 pixels) to support the precise superposition of virtual images and real scenes. It also has a dynamic distortion correction function to adapt to different vehicle speeds and road curvatures. By combining eye tracking technology, the dynamic position adjustment of the virtual image can be achieved.

[0027] In the dual-optical path HUD system, the image data displayed by different PGUs (picture generation units) have different principles in terms of functional division of labor, data source dependency and technical requirements, resulting in inconsistent data display.

[0028] The edge computing nodes here are responsible for real-time data processing and decision-making to reduce cloud dependence. They are usually equipped with high-performance GPU / ASIC chips to support parallel computing and AI reasoning.

[0029] The YTS (Unity TV Service) engine provides global data support and complex computing resources. It can push lane-level map data in real time to support accurate positioning of AR navigation. It can also predict congestion and accident hotspots and optimize navigation paths. Combined with deep learning technology, it can continuously optimize AR display algorithms (such as target recognition and semantic segmentation). It can remotely update HUD software, interaction logic, and display content library.

[0030] In a specific embodiment, the YTS engine can adopt a distributed cloud service architecture to support vehicle-side and cloud-side collaborative computing (such as uploading some rendering tasks to the cloud).

[0031] The vehicle terminal is the core control unit of the vehicle's electronic and electrical architecture, responsible for system integration and collaborative management. It has multi-system communication functions, including obtaining vehicle status (vehicle speed, steering angle, fault code) through the CAN / LIN bus and interacting with external networks (other vehicles, roadside equipment) through Ethernet / V2X. The vehicle terminal can also dynamically allocate the display content priority of the near-field / far-field PGU (such as emergency warnings covering regular information). The vehicle terminal can also manage the computing power coordination between edge computing nodes and the cloud (local real-time processing + cloud asynchronous computing).

[0032] The in-vehicle terminal can also support multi-modal interactions such as voice, gesture, and touch, and adjust AR display parameters (brightness, position, content density) through touch screen or voice control. It can also store the driver's personalized configuration (such as AR interface layout and information preferences).

[0033] Therefore, the present application provides a data processing management mechanism for a dual-optical path vehicle-mounted ARHUD system to reasonably allocate data processing tasks to improve the display consistency between the two PGUs.

[0034] Specifically, Figure 2 As shown, the present application provides a dual-light path vehicle-mounted ARHUD system that can allocate data processing tasks through the following steps: S1. The vehicle-mounted terminal collects first near-field data according to the first frequency, collects first far-field data according to the second frequency, and uploads them to the YTS engine.

[0035] Here, the first frequency is less than the second frequency. Near-field data may include vehicle speed, fuel level, basic navigation information, etc. Far-field data may include lane-level navigation, pedestrian markings, collision warnings, etc.

[0036] The vehicle-mounted terminal needs to upload the collected data to the YTS engine, which will make comprehensive decisions and reasonably arrange the data processing subjects based on the difficulty and speed of data processing.

[0037] In a specific embodiment, the second frequency may be a multiple of the first frequency. Specifically, the near-field GPU data update frequency is generally 10-30 frames per second. The far-field GPU data update frequency is generally greater than or equal to 60 frames per second and may be synchronized with the camera frame rate.

[0038] S2. The YTS engine responds to the data processing request and determines a target node for executing the data processing task for the received first near-field data or the first far-field data. The target node includes one of the vehicle-mounted terminal, the edge computing node, and the YTS engine.

[0039] In step S2, the YTS engine may select and allocate target nodes based on the attributes of the received data.

[0040] In one case, when the YTS engine receives the first near-field data, the YTS engine determines the target processing node by: Determine whether the processing optimization conditions are met. If the processing optimization conditions are not met, parse the data processing request to determine the data type of the data to be processed.

[0041] The data processing request here may be generated by the vehicle terminal and is used to indicate the data to be processed, the data type, the corresponding processing method or algorithm, etc., or may indicate the processing priority and processing difficulty level of the data to be processed. The processing difficulty level here may be determined by the complexity of the corresponding processing algorithm, the requirements for hardware resources, and the execution time, etc.

[0042] For each data type, determine the execution time of the edge computing node's last execution of the data processing subtask corresponding to the data type, so as to determine the edge computing node with the shortest total execution time as the target processing node.

[0043] Here, for different data types, the data processing algorithms are also different. For example, for basic data such as vehicle speed and fuel level, they need to be converted into corresponding graphics. For GPS positioning information, it is necessary to combine it with other information to determine the vehicle's environment and generate the corresponding navigation icon graphics.

[0044] In this way, data of different data types are regarded as a data processing subtask. Different edge computing nodes can be assigned. Specifically, based on the execution time of the last execution of the same type of data processing subtask, the edge computing node with the shortest execution time can be determined as the target processing node for processing the data processing subtask. And it is necessary to ensure that there is a one-to-one processing between the edge computing node and the data processing subtask.

[0045] Finally, the allocation scheme with the shortest total execution time corresponding to all data processing subtasks is obtained.

[0046] Alternatively, for each edge computing node, the total execution time corresponding to the edge computing node processing all data processing subtasks is calculated, and the edge computing node with the shortest execution time is determined as the target processing node.

[0047] The execution time here is the time from when the edge computing node receives the data to be processed to when the corresponding graphic data is sent to the vehicle terminal. In other words, the execution time takes into account the computing resources of the edge computing node, communication delay, and so on.

[0048] Here, different allocation mechanisms can be selected according to the system update speed requirements or data synchronization conditions.

[0049] In the second case, when the first far-field data is received, the YTS engine determines the target processing node in the following manner: Determine whether the processing optimization conditions are met. If the processing optimization conditions are not met, parse the data processing request to determine the data type of the data to be processed.

[0050] For each data type, determine the execution time of the edge computing node and the YTS engine when they last executed the data processing subtask corresponding to the data type, so as to determine the edge computing node with the shortest total execution time as the target processing node or determine the YTS engine as the target processing node.

[0051] Similar to the first far-field data, the far-field data can be processed through edge computing nodes or directly through remote servers. The difference is that the processing algorithm of far-field data is more complex, such as the environment fusion algorithm, which accurately aligns virtual objects (such as arrows) with real scenes through SLAM (simultaneous localization and mapping), and the dynamic calibration algorithm adjusts the position and angle of AR content in real time according to the driver's head position and vehicle movement.

[0052] In the third case, when the time point when the vehicle-mounted terminal uploads the first near-field data coincides with the time point when the vehicle-mounted terminal uploads the first far-field data, the vehicle-mounted terminal reconstructs the first near-field data and the first far-field data into second near-field data, second far-field data and specific data, and the specific data is data of the same data type between the first far-field data and the first near-field data.

[0053] Here, the first near-field data and the first far-field data are uploaded at the same time, and the vehicle terminal will first analyze and reorganize the data. If there is duplicate data, the first near-field data and the first far-field data will be reconstructed into the second near-field data, the second far-field data and specific data. For example, the specific data can be the vehicle's posture data (steering angle, acceleration and other parameters), which is needed for the determination of simple navigation icons and also for the determination of AR navigation. At this time, the YTS engine can determine whether the processing optimization conditions are met in the following ways: Determine whether specific data is received, and if so, determine that the processing optimization condition is met. When it is determined that the processing optimization condition is met, the YTS engine can determine the target processing node in the following manner: Determine the vehicle terminal as the first target processing node corresponding to the specific data. Determine the edge computing node with the shortest total execution time for the second near-field data as the second target processing node. Determine the YTS engine as the third target processing node corresponding to the second far-field data and the specific data.

[0054] When the processing optimization conditions are met, in order to further optimize the allocation of computing resources, specific data can be retained in the vehicle terminal for processing, thus eliminating the uploading step and reducing the use of communication resources.

[0055] For the second near-field data, these basic information can be processed by the edge computing node. At the same time, the edge computing node with a closer physical distance can be selected as the second target processing node.

[0056] For the third near-field data, it can be uploaded to the YTS engine through a high-speed network, using the AI ​​technology installed in the cloud to achieve rapid response to complex data processing and avoid misleading caused by information delays (such as the AR navigation arrow being out of sync with the actual steering action of the vehicle).

[0057] Such a resource allocation mechanism can not only alleviate the problem of communication resource competition, but also improve the data processing rate, reflecting the rationality of resource allocation.

[0058] S3. The target node generates corresponding data to be displayed based on the received data to complete the data processing task.

[0059] Specifically, the vehicle terminal generates first graphic data based on local specific data. The vehicle terminal obtains second graphic data generated by the edge computing node based on the second near-field data. The vehicle terminal generates first data to be displayed based on the first graphic data and the second graphic data, and sends it to the near-field PGU. The YTS engine generates second data to be displayed based on the second far-field data and specific data, and sends it to the vehicle terminal. The vehicle terminal forwards the second data to be displayed to the far-field PGU.

[0060] In step S3, for near-field data, the vehicle terminal or edge computing node usually processes the near-field data to generate corresponding 2D graphics data. For far-field data, the edge computing node or YTS engine can convert the 2D second data to be displayed into 3D second data to be displayed. This can meet the dynamic data display of the far-field GPU. In order to meet the computing power requirements of far-field data, the edge computing node and the YTS engine can be built based on independent chips (such as NPU).

[0061] S4. The near-field PGU or the far-field PGU projects a virtual image in the vehicle head-up display area based on the received data to be displayed.

[0062] In the dual-optical system, the near-field PGU and far-field PGU belong to different focal planes. Near-field information (such as instruments) and far-field AR information (such as road arrows) need to be projected in layers to avoid visual interference. The overall FOV is expanded through dual optical paths (for example, 10° near field + 20° far field) to cover a wider display area. The virtual image distance (VID) of the near-field PGU is generally 2 to 3 meters. The virtual image distance of the far-field PGU is generally more than 7.5 meters.

[0063] The dual-optical path vehicle-mounted ARHUD system provided in the present application can not only alleviate the problem of communication resource competition but also improve the data processing rate through reasonable data processing management of the head-up display system, reflecting the rationality of resource allocation, enhancing the synchronization effect of information display of the head-up display system, and improving the safety of user driving.

[0064] In a specific embodiment of the present application, taking the scenario of a sharp turn ahead prompted by AR navigation as an example, the vehicle terminal collects all types of data, including static data and dynamic data, at the corresponding frequency. For example, path information is obtained from the navigation system, and real-time road conditions are received through V2X. Static data is sent to the edge computing node or the vehicle terminal for preliminary processing. Dynamic data is uploaded to the YTS engine through a high-speed network for real-time processing.

[0065] The edge computing node receives static data and performs preprocessing. The processing results are sent back to the vehicle terminal. Specifically, the edge computing node can fuse the vehicle posture data (steering angle, acceleration) and calculate the dynamic projection trajectory of the AR arrow.

[0066] At the same time, the YTS engine receives dynamic data and processes it in real time. The processing results are sent back to the vehicle terminal through a high-speed network. Specifically, the cloud pushes a high-precision 3D map of the road section to assist the far-field PGU in generating virtual guide lines that match the road curvature.

[0067] The vehicle terminal receives data from the edge computing node and the YTS engine. The integrated data is sent to the two PGUs through the appropriate protocol. The near-field PGU displays static data processed by the edge computing node. The far-field PGU displays dynamic data processed by the YTS engine. Specifically, the near-field PGU synchronously displays the vehicle speed reminder, and the vehicle terminal monitors the driver's attention (through the DMS camera) and triggers an audible and visual alarm when necessary.

[0068] The system provided in the embodiment of the present application adopts dual-optical path layered display, and the near-field information (static / low-frequency update) and the far-field AR (dynamic / high-frequency update) do not interfere with each other, which can reduce visual fatigue. The computing resource allocation mechanism is reasonable, the edge computing nodes handle real-time tasks, and the cloud focuses on non-real-time global optimization to improve the system response efficiency. It also forms a vehicle-cloud-road collaborative architecture, realizes ultra-low latency communication through 5G / V2X, and expands the application scenarios of AR HUD (such as intersection blind spot warning).

[0069] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0070] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0071] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0072] It should be noted that if the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0073] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0074] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A data processing method for a dual-light-path vehicle-mounted ARHUD system based on a YTS engine, characterized in that: The dual-optical path vehicle-mounted ARHUD system at least includes a near-field PGU, a far-field PGU, an edge computing node, a YTS engine and a vehicle-mounted terminal, wherein: The vehicle-mounted terminal collects first near-field data according to the first frequency, collects first far-field data according to the second frequency, and uploads them to the YTS engine; The YTS engine responds to the data processing request and determines a target node for executing the data processing task for the received first near-field data or the first far-field data, wherein the target node includes one of the vehicle-mounted terminal, the edge computing node, and the YTS engine; The target node generates corresponding data to be displayed based on the received data to complete the data processing task; The near-field PGU or the far-field PGU projects a virtual image in the vehicle's head-up display area based on the received data to be displayed.

2. The method according to claim 1, characterized in that When receiving the first near-field data, the YTS engine determines the target processing node by: determining whether processing optimization conditions are met; If the processing optimization condition is not met, the data processing request is parsed to determine the data type of the data to be processed; For each data type, determine the execution time of the edge computing node's last execution of the data processing subtask corresponding to the data type, so as to determine the edge computing node with the shortest total execution time as the target processing node.

3. The method according to claim 2, characterized in that Before the step of determining the target processing node, it also includes: Determine whether the amount of unprocessed tasks in the current data processing task queue of the edge computing node with the shortest total execution time is greater than a preset task amount threshold; If yes, re-determine the pre-selected edge computing node and return to the previous step; If not, the pre-selected edge computing node is determined to be the target processing node.

4. The method according to claim 1, characterized in that: When receiving the first far-field data, the YTS engine determines the target processing node by: determining whether processing optimization conditions are met; If the processing optimization condition is not met, the data processing request is parsed to determine the data type of the data to be processed; For each data type, determine the execution time of the edge computing node and the YTS engine when they last executed the data processing subtask corresponding to the data type, so as to determine the edge computing node with the shortest total execution time as the target processing node or determine the YTS engine as the target processing node.

5. The method according to claim 2 or 4, characterized in that: When the time point at which the vehicle-mounted terminal uploads the first near-field data coincides with the time point at which the first far-field data is uploaded, the vehicle-mounted terminal reconstructs the first near-field data and the first far-field data into the second near-field data, the second far-field data and specific data, wherein the specific data is data of the same data type as the first far-field data and the first near-field data. The YTS engine determines whether the processing optimization conditions are met in the following manner: determining whether the specific data is received; If so, it is determined that the processing optimization condition is met.

6. The method according to claim 5, characterized in that When it is determined that the processing optimization conditions are met, the YTS engine determines the target processing node in the following way: Determining the vehicle-mounted terminal as a first target processing node corresponding to specific data; Determine an edge computing node with the shortest total execution time for the second near-field data as a second target processing node; The YTS engine is determined to be a third target processing node corresponding to the second far-field data and the specific data.

7. The method according to claim 6, characterized in that The vehicle-mounted terminal generates first graphic data based on local specific data, The vehicle-mounted terminal obtains second graphic data generated by the edge computing node according to the second near-field data; The vehicle terminal generates first data to be displayed based on the first graphic data and the second graphic data, and sends it to the near-field PGU.

8. The method according to claim 7, characterized in that The YTS engine generates second data to be displayed according to the second far-field data and the specific data, and sends the second data to the vehicle terminal; The vehicle-mounted terminal forwards the second data to be displayed to the far-field PGU.

9. The method according to claim 4, characterized in that The execution time is the time from when the edge computing node receives the data to be processed to when the corresponding graphic data is sent to the vehicle terminal.

10. The method according to claim 8, characterized in that The YTS engine converts the 2D second data to be displayed into 3D second data to be displayed.

Images