A data processing method for dual-optical-path vehicle-mounted ARHUD system based on YTS engine

Abstract

The present application provides a data processing method for a dual-light-path vehicle-mounted ARHUD system based on a YTS engine. The dual-light-path vehicle-mounted ARHUD system includes 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 them to the YTS engine; the YTS engine responds to a data processing request, and determines a target node for executing a data processing task for the received first near-field data or the 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 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 head-up display area 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 HUD system, different PGUs have different functional divisions, data source dependencies, and technical requirements when displaying image data. This diversity can lead to inconsistent data displayed by each PGU, affecting the overall display quality and user experience.

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

[0005] The purpose of the embodiments 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, thereby enhancing the synchronization effect of information display of the head-up display system through reasonable data processing and 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. The dual-light-path vehicle-mounted ARHUD system includes at least a near-field PGU, a far-field PGU, an edge computing node, a YTS engine, and a vehicle-mounted terminal. The vehicle-mounted terminal collects first near-field data at a first frequency, collects first far-field data at a second frequency, and uploads the data to the YTS engine.

[0007] The YTS engine responds to the data processing request and determines a target node for performing 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;

[0008] The target node generates corresponding data to be displayed based on the received data to complete the data processing task;

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

[0010] In an optional embodiment, when the first near-field data is received, the YTS engine determines the target processing node by:

[0011] determining whether processing optimization conditions are met;

[0012] If the processing optimization conditions are not met, the data processing request is parsed to determine the data type of the data to be processed;

[0013] 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, and determine the edge computing node with the shortest total execution time as the target processing node.

[0014] In an optional embodiment, before the step of determining the target processing node, the method further includes:

[0015] 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;

[0016] If yes, re-determine the pre-selected edge computing node and return to the previous step;

[0017] If not, the pre-selected edge computing node is determined to be the target processing node.

[0018] In an optional embodiment, when the first far-field data is received, the YTS engine determines the target processing node by:

[0019] determining whether processing optimization conditions are met;

[0020] If the processing optimization conditions are not met, the data processing request is parsed to determine the data type of the data to be processed;

[0021] 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.

[0022] In an optional embodiment, when the time point at which the vehicle terminal uploads the first near-field data coincides with the time point at which the first far-field data is uploaded, the vehicle 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 conditions are met in the following manner:

[0023] determining whether specific data has been received;

[0024] If so, it is determined that the processing optimization condition is met.

[0025] 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:

[0026] Determining the in-vehicle terminal as a first target processing node corresponding to specific data;

[0027] Determine, for the second near-field data, an edge computing node with the shortest total execution time as a second target processing node;

[0028] The YTS engine is determined to be a third target processing node corresponding to the second far-field data and the specific data.

[0029] In an optional embodiment, the vehicle-mounted terminal generates the first graphic data based on local specific data.

[0030] The vehicle-mounted terminal obtains second graphic data generated by the edge computing node according to the second near-field data;

[0031] The vehicle terminal generates first data to be displayed based on the first graphic data and the second graphic data, and sends the first data to be displayed to the near-field PGU.

[0032] In an optional embodiment, 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;

[0033] The vehicle terminal forwards the second data to be displayed to the far-field PGU.

[0034] In an optional embodiment, 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.

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

[0036] The present application provides a data processing method for a dual-light-path vehicle-mounted ARHUD system, which includes at least a near-field PGU, a far-field PGU, an edge computing node, a YTS engine, and an on-board terminal, wherein the on-board 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, the target node including one of the on-board terminal, the edge computing node, and the YTS engine; the target node processes the first near-field data or the first far-field data to generate corresponding data to be displayed 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. 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

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. 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 relevant drawings can be obtained based on these drawings without creative work.

[0038] Figure 1 A schematic diagram of the structure of a dual-light-path vehicle-mounted ARHUD system based on the YTS engine provided in an embodiment of the present application;

[0039] Figure 2 A flow chart of communication of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine provided in an embodiment of the present application;

[0040] 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.

[0041] Reference numerals:

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

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

[0044] 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.

[0045] Figure 1 A schematic structural diagram of a dual-light-path vehicle-mounted ARHUD system based on a YTS engine is 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.

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

[0047] Among them, the near-field PGU and far-field PGU in the dual-light path vehicle-mounted ARHUD system are highly consistent in terms of 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 integration 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-mounted ARHUD system can be as follows: Figure 3 shown.

[0048] Near-field PGUs typically display traditional HUD content. They generate content for short-range displays (such as vehicle speed, fuel level, and simple navigation arrows), focusing on the driver's field of view (approximately 2-3 meters for a VID). These displays update less frequently. They typically utilize high-brightness microdisplay technologies (such as DLP, LCoS, or laser scanning) to ensure visibility in bright sunlight. They also employ low latency (<10ms) for real-time synchronization with vehicle sensors. They also support dynamic focus adjustment to adapt to changes in the driver's field of view.

[0049] The far-field PGU is responsible for AR enhanced display and generates long-range augmented reality content (such as lane-level navigation, pedestrian markings, and collision warnings). The virtual image is displayed at a greater distance (VID ≥ 7.5 meters), requires dynamic adaptation to the road environment, and requires a higher data update frequency. It typically features a high resolution (e.g., 1920×720 pixels) to accurately overlay the virtual image with the real scene. It also features dynamic distortion correction to adapt to varying vehicle speeds and road curvature. By integrating eye tracking technology, the virtual image's dynamic position adjustment can be achieved.

[0050] In a 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.

[0051] Edge computing nodes are responsible for real-time data processing and decision-making, reducing cloud reliance. They are typically equipped with high-performance GPUs or ASIC chips, supporting parallel computing and AI reasoning.

[0052] The Unity TV Service (YTS) engine provides global data support and complex computing resources. It can push lane-level map data in real time, supporting precise positioning for AR navigation. It can also predict congestion and accident hotspots, optimizing navigation paths. Incorporating deep learning technology, it continuously optimizes AR display algorithms (such as object recognition and semantic segmentation). HUD software, interaction logic, and display content libraries can be updated remotely.

[0053] 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).

[0054] The onboard terminal is the core control unit of the vehicle's electrical and electronic architecture, responsible for system integration and collaborative management. It features multi-system communication capabilities, including access to vehicle status (speed, steering angle, fault codes) via the CAN / LIN bus and interaction with external networks (other vehicles, roadside equipment) via Ethernet / V2X. The onboard terminal can also dynamically prioritize the display content of near-field and far-field PGUs (e.g., emergency alerts overlaying regular information). The onboard terminal also manages the coordinated computing power of edge computing nodes and the cloud (local real-time processing combined with asynchronous cloud computing).

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

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

[0057] Specifically, such as 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:

[0058] 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.

[0059] The first frequency here is lower 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.

[0060] The on-board 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.

[0061] 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 can be synchronized with the camera frame rate.

[0062] S2. The YTS engine responds to the data processing request and determines the 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.

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

[0064] In one case, when the YTS engine receives the first near-field data, the YTS engine determines the target processing node by:

[0065] 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.

[0066] The data processing request can 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. It can also indicate the processing priority and processing difficulty level of the data to be processed. The processing difficulty level can be determined by the complexity of the corresponding processing algorithm, the hardware resource requirements, and the execution time.

[0067] 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, and determine the edge computing node with the shortest total execution time as the target processing node.

[0068] Different data types require different data processing algorithms. For example, basic data like vehicle speed and fuel level must be converted into corresponding graphics. GPS location information, on the other hand, must be combined with other information to determine the vehicle's surroundings and generate corresponding navigation icon graphics.

[0069] In this way, data of different data types is considered a data processing subtask. Different edge computing nodes can be assigned to these subtasks. Specifically, based on the execution time of the previous data processing subtask of the same type, the edge computing node with the shortest execution time can be identified as the target processing node for this data processing subtask. Furthermore, it is necessary to ensure a one-to-one relationship between edge computing nodes and data processing subtasks.

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

[0071] 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.

[0072] The execution time here is the time from when the edge computing node receives the data to be processed to when it sends the corresponding graphics data to the vehicle terminal. In other words, the execution time takes into account the computing power resources of the edge computing node, communication delays, and other factors.

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

[0074] In the second case, when the first far-field data is received, the YTS engine determines the target processing node in the following manner:

[0075] 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.

[0076] 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.

[0077] Similar to the first type of far-field data, far-field data can be processed by edge computing nodes or directly by remote servers. The difference is that the processing algorithms for far-field data are more complex, such as environmental fusion algorithms that precisely align virtual objects (such as arrows) with the real scene through SLAM (Simultaneous Localization and Mapping), and dynamic calibration algorithms that adjust the position and angle of AR content in real time based on the driver's head position and vehicle movement.

[0078] 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.

[0079] Here, the first near-field data and the first far-field data are uploaded simultaneously. 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 determining simple navigation icons and also for determining AR navigation. At this time, the YTS engine can determine whether the processing optimization conditions are met in the following ways:

[0080] Determine whether specific data is received. 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 way:

[0081] The vehicle terminal is determined as the first target processing node corresponding to the specific data. The edge computing node with the shortest total execution time is determined as the second target processing node for the second near-field data. The YTS engine is determined as the third target processing node corresponding to the second far-field data and the specific data.

[0082] 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 upload step and reducing the use of communication resources.

[0083] 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.

[0084] For the third near-field data, it can be uploaded to the YTS engine via a high-speed network, and the AI technology on the cloud can be used to achieve rapid response to complex data processing, avoiding misleading information caused by information delays (such as the AR navigation arrow being out of sync with the vehicle's actual steering action).

[0085] 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.

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

[0087] 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 and 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.

[0088] In step S3, for near-field data, the vehicle terminal or edge computing node typically 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 display data into 3D second display data. This allows for dynamic data display on the far-field GPU. To meet the computing power requirements of far-field data, the edge computing node and YTS engine can be built using independent chips (such as an NPU).

[0089] 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.

[0090] In a dual-optical system, the near-field PGU and far-field PGU reside in different focal planes. Near-field information (such as instrumentation) and far-field AR information (such as road arrows) are projected in layers to avoid visual interference. The dual optical paths expand the overall FOV (for example, 10° near-field + 20° far-field), covering a wider display area. The virtual image distance (VID) of the near-field PGU is typically 2 to 3 meters. The virtual image distance of the far-field PGU is typically 7.5 meters or more.

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

[0092] In a specific embodiment of this application, using an AR navigation prompt indicating a sharp turn ahead as an example, the vehicle terminal collects all types of data, including static and dynamic data, at the corresponding frequencies. For example, it obtains route information from the navigation system and receives real-time road conditions via V2X. Static data is sent to an edge computing node or vehicle terminal for preliminary processing. Dynamic data is uploaded to the YTS engine via a high-speed network for real-time processing.

[0093] The edge computing node receives static data and preprocesses it. The results are then sent back to the vehicle terminal. Specifically, the edge computing node can integrate vehicle posture data (steering angle, acceleration) to calculate the dynamic projection trajectory of the AR arrow.

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

[0095] The onboard terminal receives data from the edge computing node and the YTS engine. The integrated data is sent to two PGUs via 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 simultaneously displays speed reminders, while the onboard terminal monitors driver attention (via the DMS camera) and triggers audible and visual warnings when necessary.

[0096] The system provided in the embodiments of this application utilizes a dual-optical layered display, ensuring that near-field information (static / low-frequency updates) and far-field AR (dynamic / high-frequency updates) do not interfere with each other, reducing visual fatigue. A rational computing resource allocation mechanism allows edge computing nodes to handle real-time tasks while the cloud focuses on non-real-time global optimization, improving system response efficiency. A vehicle-cloud-road collaborative architecture is also formed, enabling ultra-low-latency communication via 5G / V2X, expanding the application scenarios of AR HUDs (such as intersection blind spot warnings).

[0097] In the embodiments provided in this 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 interface, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0098] In addition, the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across 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.

[0099] Furthermore, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0100] 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 existing technology, 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 and includes a number of instructions for enabling 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 code.

[0101] 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 actual relationship or order between these entities or operations.

[0102] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. For those skilled in the art, various modifications and variations of the present application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection 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 includes at least a near-field PGU, a far-field PGU, an edge computing node, a YTS engine and a vehicle-mounted terminal, wherein: The on-board terminal collects first near-field data according to the first frequency and collects first far-field data according to the second frequency, and uploads them to the YTS engine. When the time point when the on-board terminal uploads the first near-field data coincides with the time point when the on-board terminal uploads the first far-field data, the on-board 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 responds to the data processing request and determines whether the specific data is received for the received first near-field data or the first far-field data. If so, the vehicle-mounted terminal is determined to be the first target processing node corresponding to the specific data, and the edge computing node with the shortest total execution time is determined for the second near-field data as the second target processing node. The YTS engine is determined to be the third target processing node corresponding to the second far-field data and the specific data. The target node generates corresponding data to be displayed based on the received data to complete the data processing task. The target node includes the vehicle terminal, edge computing node, and YTS engine; The near-field PGU or 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 conditions are 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, and 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 determining the target processing node, the following steps are also included: 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, wherein 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 conditions are 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 1, wherein 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.

6. The method according to claim 5, characterized in that 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.

7. 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 it sends the corresponding graphic data to the vehicle terminal.

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

Images