Vehicle-mounted equipment data processing method based on multiple chips, vehicle machine system and vehicle

Abstract

The invention relates to the technical field of vehicle data processing, and discloses a multi-chip-based vehicle-mounted equipment data processing method, a vehicle machine system and a vehicle, the method is applied to the vehicle machine system, a main processing chip and an auxiliary processing chip are arranged in the vehicle machine system, and the main processing chip and the auxiliary processing chip are connected through a preset data transmission channel. Comprising the following steps: receiving data processing tasks corresponding to a plurality of vehicle-mounted devices through a main processing chip and an auxiliary processing chip, and monitoring load states of the main processing chip and the auxiliary processing chip; and if the load state meets the preset migration condition, migrating the data processing task corresponding to the at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel, and processing the data processing task corresponding to the corresponding vehicle-mounted device by the auxiliary processing chip.

Description

Technical Field

[0001] This application relates to the field of vehicle data processing technology, and in particular to a multi-chip-based in-vehicle equipment data processing method, vehicle system and vehicle. Background Technology

[0002] With the continuous improvement of automotive intelligence and connectivity, modern vehicles integrate more and more in-vehicle equipment, such as high-definition central control displays, digital instrument panels, advanced driver assistance systems, in-vehicle infotainment systems, 360-degree surround view systems, and vehicle networking modules. These devices generate massive amounts of data processing tasks during operation, placing extremely high demands on the computing power, real-time performance, and reliability of the in-vehicle systems.

[0003] Currently, mainstream in-vehicle infotainment systems typically use a single high-performance main processing chip to centrally process data from all in-vehicle devices. While this centralized processing architecture is simple in structure, its inherent limitations have gradually become apparent in practical applications. As in-vehicle applications become increasingly complex (e.g., simultaneously running high-precision navigation, multi-channel video encoding / decoding, voice recognition, and complex graphics rendering), the computing resources of a single main processing chip can easily reach their bottleneck. When peak data processing tasks occur, the load rate of the main processing chip increases sharply, leading to system response delays, screen stuttering, and task processing failures, severely impacting the user experience and driving safety.

[0004] To enhance system computing power, one existing solution involves adding auxiliary processing chips to the vehicle's infotainment system. However, in traditional multi-chip architectures, task allocation among chips is typically static and fixed. For example, during the system design phase, it's pre-defined that the main chip handles certain specific tasks, while auxiliary chips handle others. This static allocation strategy lacks flexibility and cannot adapt to the dynamic and complex operating conditions during vehicle operation. When the main processing chip is overloaded due to sudden high-load tasks, the auxiliary processing chip may be idle or underloaded, resulting in inefficient use of its computing resources and a waste of overall system computing power. Conversely, if the auxiliary chip is overloaded, it may also affect the performance of its dedicated functions. Summary of the Invention

[0005] In view of the above problems, this disclosure provides a data processing method for in-vehicle devices based on multi-chip technology, an in-vehicle infotainment system, and a vehicle, to solve the following technical problems: How can we achieve dynamic and intelligent scheduling of processing tasks in a multi-chip vehicle infotainment system environment, so as to fully explore and balance the computing potential of each chip, avoid overloading a single chip, and ensure that the system can still maintain smooth, stable and efficient operation under high load conditions?

[0006] To address the aforementioned technical problems, the technical solution of this application is as follows: A data processing method for an in-vehicle device based on a multi-chip architecture, the method being applied to an in-vehicle infotainment system, wherein the in-vehicle infotainment system includes a main processing chip and an auxiliary processing chip, the main processing chip and the auxiliary processing chip being connected through a pre-defined data transmission channel, the method comprising: The main processing chip and the auxiliary processing chip receive data processing tasks corresponding to multiple vehicle-mounted devices and monitor the load status of the main processing chip and the auxiliary processing chip. If the load state meets the preset migration conditions, the data processing task corresponding to at least one vehicle-mounted device will be migrated to the auxiliary processing chip through the data transmission channel, and the auxiliary processing chip will process the data processing task corresponding to the vehicle-mounted device.

[0007] It should be noted that this application fundamentally overcomes the rigidity of static task allocation strategies in existing technologies by establishing a dynamic task migration mechanism based on real-time load status monitoring between the main processing chip and the auxiliary processing chip. Specifically, this method does not fix tasks to specific chips after system initialization, but continuously monitors the load status of both chips. When the load of the main processing chip reaches a preset migration condition (such as approaching an overload threshold), it actively migrates a portion of data processing tasks to the auxiliary processing chip, which may currently have a lower load, through a preset data transmission channel. This dynamic scheduling mechanism transforms computing resources from statically divided islands into a shared resource pool that can be flexibly allocated by the system as a whole. The direct result is a significant improvement in the resource utilization of the auxiliary processing chip, avoiding its potential idle state when the main chip is overloaded, thereby maximizing the overall effective computing power of the system. Ultimately, this invention, through dynamic load balancing of computing resources, enables the vehicle system to maintain a smooth, stable, and efficient working state when facing the ever-increasing data processing demands of in-vehicle devices, enhancing the robustness and reliability of the system under complex operating conditions.

[0008] A vehicle infotainment system includes a main processing chip, an auxiliary processing chip, and a vehicle main control device. The main processing chip and the auxiliary processing chip are connected through a pre-defined data transmission channel. The vehicle infotainment main control device receives data processing tasks corresponding to multiple vehicle devices through the main processing chip and the auxiliary processing chip, and monitors the load status of the main processing chip and the auxiliary processing chip. If the load state meets the preset migration conditions, the vehicle main control device will migrate the data processing task corresponding to at least one vehicle device to the auxiliary processing chip through the data transmission channel, and the auxiliary processing chip will process the data processing task corresponding to the vehicle device.

[0009] A vehicle including the aforementioned vehicle infotainment system.

[0010] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, specific embodiments of this disclosure are described below. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A schematic flowchart of a multi-chip-based vehicle device data processing method provided in an embodiment of this disclosure is shown. Figure 2 This illustration shows a schematic diagram of the structure of a data processing system based on a multi-chip Bluetooth architecture provided in an embodiment of the present disclosure; Figure 3 A schematic diagram of the structure of a vehicle infotainment system provided in an embodiment of this disclosure is shown. Detailed Implementation

[0012] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0013] Currently, in-vehicle infotainment systems typically connect multiple in-vehicle devices via Bluetooth. These devices can be HID (Human Interface Device) devices, which define standardized specifications for how Bluetooth devices, as input devices (such as keyboards, mice, game controllers, remote controls, and drawing tablets), communicate with host devices (such as computers, mobile phones, tablets, and smart TVs). In a single-chip Bluetooth architecture, when two or more HID devices operate simultaneously, input events are transmitted to the in-vehicle infotainment system via the Bluetooth HID protocol. Because Bluetooth HID data transmission relies on one-to-one parsing of device MAC addresses, and the processing power of a single chip is limited, time-slice conflicts can occur when receiving multiple HID data streams simultaneously. Specifically, if the data transmission intervals of two HID devices differ, and the data arrives at the chip in the same time slice, the chip will prioritize processing the HID data with the shorter interval, causing the data from the HID device with the longer interval to be temporarily ignored. This manifests on the user interface as HID device operation lag or broadcast interruptions, impacting the user experience.

[0014] In existing technologies, single-chip Bluetooth designs cannot fundamentally solve this timing logic problem because their processing logic is based on a single thread or limited resources, making it difficult to handle multiple concurrent data streams simultaneously. Therefore, a new architecture and method are needed to avoid data conflicts and ensure smooth operation of multiple devices.

[0015] To address the time slice conflict problem in existing single-chip automotive Bluetooth systems when processing data from multiple HID devices, this invention provides a data processing method and system based on a multi-chip Bluetooth architecture. By using dynamic device migration and MAC address forwarding mechanisms, parallel processing of multiple HID data is achieved, eliminating operational lag.

[0016] The core concept of this invention is that communication between the vehicle's Bluetooth chip and HID devices relies on the Bluetooth MAC address in the data packet to achieve device positioning and one-to-one data parsing. Based on this principle, after the main chip identifies the device's data characteristics, the communication link of a specific device is dynamically migrated to an auxiliary chip, achieving load balancing and parallel processing.

[0017] Meanwhile, to enhance the flexibility and intelligence of link migration, this solution adds three core mechanisms: 1) a dual-chip load real-time monitoring mechanism, which collects parameters such as the number of chip connections and CPU (Central Processing Unit) utilization, sets load thresholds (e.g., 85% is the high load threshold) to trigger dynamic adjustments; 2) a device priority dimension, which sets priority rules based on user-defined criteria and device type (e.g., navigation devices have higher priority than multimedia devices) to ensure that core devices respond first; and 3) an intelligent predictive migration and scheduling mechanism, which builds predictive models based on historical interaction data (e.g., users' device usage habits during daily commutes), predicts high-concurrency scenarios in advance, and activates auxiliary chips to reduce migration latency.

[0018] Therefore, this application provides a flowchart illustrating a data processing method for in-vehicle devices based on multi-chip technology, as shown below. Figure 1 As shown, this process can be executed by the vehicle's infotainment system, which includes a main processing chip and an auxiliary processing chip connected via a pre-defined data transmission channel. Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.

[0019] The method flow steps of this application embodiment are as follows: S101, the main processing chip and the auxiliary processing chip receive data processing tasks corresponding to multiple vehicle-mounted devices, and monitor the load status of the main processing chip and the auxiliary processing chip.

[0020] In the embodiments described in this specification, when the system starts up, the vehicle's main control unit can assign unique identifiers to different in-vehicle devices. Data processing tasks generated by each in-vehicle device are initially assigned to either the main processing chip or an auxiliary processing chip according to a preset strategy. The initial assignment strategy in these embodiments can be based on device priority; for example, tasks with high real-time requirements (such as dashboard displays) are always received by the main processing chip, while tasks with low real-time requirements (such as background data updates) can be initially assigned to the auxiliary processing chip.

[0021] Run a lightweight monitoring program (or utilize a feature built into the operating system kernel). This monitoring program periodically (e.g., every 100 milliseconds) or event-triggered, collects key performance indicators to quantify load status. These indicators primarily include: CPU utilization: The percentage of time the chip core spends processing tasks.

[0022] Memory usage: The percentage of total memory that has been used.

[0023] I / O (Input / Output) throughput: The rate at which data is exchanged through data transmission channels and other interfaces.

[0024] The embodiments in this specification can aggregate the collected data and temporarily store it in a shared memory area for use by the decision-making logic (which can run on the main processing chip).

[0025] S102, if the load state meets the preset migration conditions, the data processing task corresponding to at least one vehicle-mounted device is migrated to the auxiliary processing chip through the data transmission channel, and the auxiliary processing chip processes the data processing task corresponding to the vehicle-mounted device.

[0026] In the embodiments of this specification, the preset migration conditions can be defined as a series of configurable logical rules. A typical and concise condition is: the condition is met when the load state of the main processing chip > a first preset threshold and the load state of the auxiliary processing chip < a second preset threshold. The first preset threshold is typically set at a high level (e.g., 80% utilization), indicating that the main processing chip is overloaded; the second preset threshold is set at a low level (e.g., 30% utilization), indicating that the auxiliary processing chip has sufficient idle resources. The decision logic continuously compares the real-time load state monitored in S101 with these preset thresholds. Once the condition is met, the migration process is triggered, as follows: The system's vehicle-mounted main control unit selects one or more data processing tasks from the task list currently being processed by the main processing chip, based on a preset strategy (such as selecting the lowest priority or tasks with infrequent data interaction). The main processing chip packages the current execution state of the selected task (such as memory image, register values, program counter, and other context information). This task context data packet is then sent to the auxiliary processing chip via the data transmission channel. Upon receiving the data packet, the auxiliary processing chip reconstructs the task's execution environment internally and resumes execution of the data processing task from the point of interruption. To ensure that subsequent data can be delivered directly, the system notifies the corresponding vehicle-mounted device to modify the destination address of its subsequent data stream to the address of the auxiliary processing chip (e.g., modifying the destination MAC address at the network layer).

[0027] It should be noted that this application fundamentally overcomes the rigidity of static task allocation strategies in existing technologies by establishing a dynamic task migration mechanism based on real-time load status monitoring between the main processing chip and the auxiliary processing chip. Specifically, this method does not fix tasks to specific chips after system initialization, but continuously monitors the load status of both chips. When the load of the main processing chip reaches a preset migration condition (such as approaching an overload threshold), it actively migrates a portion of data processing tasks to the auxiliary processing chip, which may currently have a lower load, through a preset data transmission channel. This dynamic scheduling mechanism transforms computing resources from statically divided islands into a shared resource pool that can be flexibly allocated by the system as a whole. The direct result is a significant improvement in the resource utilization of the auxiliary processing chip, avoiding its potential idle state when the main chip is overloaded, thereby maximizing the overall effective computing power of the system. Ultimately, this invention, through dynamic load balancing of computing resources, enables the vehicle system to maintain a smooth, stable, and efficient working state when facing the ever-increasing data processing demands of in-vehicle devices, enhancing the robustness and reliability of the system under complex operating conditions.

[0028] Optionally, in the process of receiving data processing tasks corresponding to multiple vehicle-mounted devices through the main processing chip and the auxiliary processing chip, the core objective is to allocate corresponding processing chips to different vehicle-mounted device data processing tasks in the initial stage of task reception, i.e., according to preset priority rules, so as to establish an orderly processing environment that ensures the performance of critical tasks during system initialization. The method flow steps of this application embodiment are as follows: S201, obtain the pre-set priority of each vehicle-mounted device.

[0029] In the embodiments described in this specification, a priority list for in-vehicle devices can be created during the system development or configuration phase. This list is stored in the non-volatile memory of the vehicle system in the form of a database, configuration file, or hard-coded constants.

[0030] In this list, each in-vehicle device is assigned a specific priority value or level by its unique device ID (e.g., level 1 is the highest priority, corresponding to safety-critical devices; level 3 is the lowest priority, corresponding to infotainment devices). During the vehicle system startup initialization process, the operating system or resource management service reads the in-vehicle device priority list from the memory and loads it into the system memory for quick access by the task scheduler.

[0031] S202, based on a pre-set priority rule, the main processing chip and the auxiliary processing chip receive data processing tasks corresponding to the vehicle-mounted devices that meet the corresponding priorities.

[0032] In the embodiments of this specification, the pre-defined priority rules can be a strategy that maps the priority of vehicle-mounted devices to processing chips. A typical rule is: "The data processing tasks corresponding to the highest priority (such as level 1 and 2) vehicle-mounted devices are assigned to the main processing chip for reception and processing by default; the tasks with lower priority (such as level 3) are assigned to the auxiliary processing chip for reception and processing by default." When an onboard device powers on and requests to start its data processing task, the system task scheduler intercepts the request. The scheduler first queries the priority list loaded in S201 to obtain the priority of the device. Then, based on the priority rules mentioned above, the scheduler determines which chip should receive the task.

[0033] The scheduler can bind the execution context (such as a process, thread, or service) of the data processing task to the computing core of the target chip (main processing chip or auxiliary processing chip). Simultaneously, it configures system interrupts to ensure that the data stream generated by the device is directly directed to the I / O interface of the target chip.

[0034] It should be noted that this application introduces and implements a priority-based initial task allocation strategy on top of the underlying mechanism of dynamic load balancing, thereby systematically improving the intelligence and reliability of vehicle system resource management. Specifically, this method does not simply hand over tasks to any available chip for processing after they are generated, but rather allocates them according to pre-set device priority rules at the initial stage of task reception. This design allows data processing tasks generated by high-priority in-vehicle devices to be preferentially guided to the main processing chip with more stable and robust processing performance, or to ensure that they receive the most timely resource response. This priority-based initial allocation establishes a pre-emptive guarantee mechanism for the system, ensuring that critical tasks are in a guaranteed execution environment from the beginning of their lifecycle, reducing the risk of delays caused by them competing for resources with low-priority tasks (such as entertainment system updates).

[0035] Optionally, before migrating the data processing tasks corresponding to at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel, the core objective is to intelligently and selectively determine which tasks to migrate after deciding to migrate, so as to minimize the negative impact of the migration operation itself on system performance, while ensuring that the migration can effectively alleviate the pressure on the main processing chip. The method flow steps of this application embodiment are as follows: S301, parse the data packets sent by each vehicle-mounted device to obtain the data transmission interval parameters of each vehicle-mounted device.

[0036] In the embodiments described in this specification, a monitoring module is embedded in the network protocol stack or packet processing engine of the main processing chip. This module does not interrupt normal data processing; instead, it parses and records the header information of each data packet sent by the vehicle-mounted device. The key information parsed is the timestamp of the data packet. This module records the time difference between the arrival of two consecutive data packets from the same vehicle-mounted device. Based on the continuously recorded timestamps, the monitoring module dynamically calculates and maintains the data transmission interval parameter for each vehicle-mounted device. This parameter can be a statistical value, such as the average interval or typical interval over a recent period. This parameter characterizes the frequency and regularity of the data tasks generated by the device. For example, real-time video streaming devices have extremely short and stable intervals, while event-triggered sensors (such as tire pressure monitoring) have longer and irregular intervals.

[0037] S302, determine the number of vehicle-mounted devices to be migrated based on the load status.

[0038] In the embodiments described in this specification, the system reads the real-time load status of the current main processing chip (e.g., CPU utilization 85%), which is continuously monitored in the main process S101. This real-time load status is compared with the preset migration conditions that trigger migration (e.g., load greater than 80%) to calculate the current "overload" level (e.g., 85% - 80% = 5% overload). The system internally presets a mapping relationship or calculation formula to map the above "overload" level to the amount of tasks that need to be migrated, i.e., the number of vehicle-mounted devices to be migrated.

[0039] For example, the rule might be simplified to "for every 1% overload, one low-load-characteristic vehicle device task needs to be migrated." Based on this example, a 5% overload would determine the number of vehicle devices to be migrated to be 1. This number is intended to reduce the load on the main processing chip just below a safe threshold, avoiding over-migration.

[0040] S303, based on the data transmission interval parameter and the number of vehicle-mounted devices to be migrated, determine the data processing task corresponding to the target vehicle-mounted device to be migrated.

[0041] In the embodiments described in this specification, the system obtains the data transmission interval parameter list for each device obtained in S301 and the number of vehicle-mounted devices to be migrated determined in S302 (e.g., N=1). The system executes a filtering algorithm whose core principle is to prioritize vehicle-mounted devices with larger "data transmission interval parameters". This is because migrating such devices (e.g., devices that send data only once every few seconds or minutes) results in minimal continuous communication and processing overhead and the lowest disturbance to the overall system performance.

[0042] Based on the above filtering strategy, the system selects the top N devices (i.e., the number of in-vehicle devices to be migrated) with the largest interval parameters from the list of all in-vehicle device tasks processed by the main processing chip. These selected devices are identified as target in-vehicle devices, and the data processing tasks they are currently running on the main processing chip are the target tasks to be migrated.

[0043] It should be noted that after deciding to migrate tasks, this application introduces a refined screening layer based on objective device characteristics and real-time system requirements. This ensures that the task migration process itself is optimized, rather than blind or brute-force, significantly improving the efficiency of load balancing operations and system stability. Specifically, this method does not simply randomly select several tasks from the currently high-load chip for migration. Instead, it performs two key steps before migration: First, it parses the data packets of each vehicle device to obtain its inherent "data transmission interval parameter," which objectively reflects the frequency and regularity of the data tasks generated by the device. Second, it combines this static characteristic representing the device's own behavior pattern with the system requirement of "the number of devices to be migrated," dynamically calculated based on real-time "load status," to jointly determine the "target vehicle devices." This screening mechanism allows the system to prioritize the migration of device tasks with relatively large data transmission intervals, i.e., more intermittent rather than continuous data flows. This is because the additional overhead of migrating such tasks (such as frequent switching of communication link states established through data transmission channels, saving and restoring task context information, etc.) is relatively small, and the disturbance to the overall system performance is also lower. Therefore, this method enables each task migration operation to effectively alleviate the load pressure on the target chip while minimizing the system performance loss and communication overhead introduced by the migration operation itself, thereby maximizing the load balancing efficiency and ensuring that the system can quickly and smoothly reach a new efficient and stable state after reconfiguring resources.

[0044] Optionally, the aforementioned task selection process (S303) can be optimized and refined. Based on the original decision-making criteria (data transmission interval parameters, number of vehicle-mounted devices to be migrated), the key dimension of "priority corresponding to each vehicle-mounted device" is introduced, thereby forming a more complete and intelligent migration target selection strategy. The method flow steps of this embodiment are as follows: S401, based on the priority of each vehicle-mounted device, the data transmission interval parameter, and the number of vehicle-mounted devices to be migrated, determine the data processing task corresponding to the target vehicle-mounted device to be migrated.

[0045] In the embodiments described in this specification, the system pre-defines a more refined target selection rule. The core principle of this rule is: given the required number of on-board devices to be migrated, priority is given to migrating on-board device tasks with the lowest priority and the largest data transmission interval parameter. This means that during decision-making, "priority" is considered the primary filtering condition to ensure that critical system tasks are not affected; the "data transmission interval parameter" is used as a secondary optimization condition to select the target with the lowest migration cost among tasks with similar priorities. The specific filtering process is as follows: Initial screening is performed based on priority. The system first filters out onboard device tasks with priorities below a certain threshold (e.g., all "low priority" and "medium priority" tasks) from the list of all tasks currently being processed by the main processing chip, forming a "candidate migration task pool". The highest priority tasks (such as those directly related to vehicle safety) are excluded at this stage to ensure stability.

[0046] The system optimizes the sorting based on the data transmission interval. It obtains the data transmission interval parameter calculated in S301 by the on-board equipment corresponding to each task in the "candidate migration task pool", and sorts the tasks in the pool in descending order based on this parameter (i.e., the tasks with larger interval parameters are ranked first).

[0047] The final target is determined by quantity. Based on the number of on-board devices to be migrated as determined in S302 (e.g., N=2), the system selects the first N tasks from the top of the sorted list (i.e., the tasks with the lowest priority and the largest data transmission interval).

[0048] The N tasks ultimately selected represent the data processing tasks corresponding to the target vehicle-mounted equipment that needs to be migrated. This list will then be passed to the subsequent migration execution module.

[0049] It should be noted that this application, based on task migration screening based on device behavior characteristics (data transmission interval) and system immediate needs (number of devices to be migrated), further incorporates the key decision dimension of "priority of each vehicle-mounted device," thereby constructing a multi-factor collaborative, hierarchical migration target decision model. This allows load balancing operations to pursue efficiency while ensuring the functional safety and continuity of critical services. Specifically, this method considers three factors collaboratively: "priority" representing task importance, "data transmission interval parameter" reflecting task communication patterns, and "number of vehicle-mounted devices to be migrated" indicating system load pressure. These factors serve as the joint judgment basis for determining the final migration target. This mechanism ensures that the system can execute an optimized selection strategy during task migration: given the requirement of a certain number of devices to be migrated, the system tends to prioritize the migration of tasks corresponding to devices with "relatively low priority" and "relatively large data transmission intervals." This is because migrating low-priority tasks has the least impact on the core functions of the system; even if there are minor delays during the migration process or subsequent processing, they will not jeopardize the vehicle's safety-critical functions. Furthermore, selecting tasks with large data transmission intervals helps reduce the overhead of communication link switching caused by the migration itself.

[0050] Optionally, the load state satisfies preset migration conditions, including: the load state of the main processing chip is greater than a first preset threshold; the load state of the auxiliary processing chip is less than a second preset threshold, wherein the first preset threshold is greater than or equal to the second preset threshold.

[0051] It should be noted that the first preset threshold is used to determine whether the main processing chip is overloaded. This threshold is set at a relatively high level, for example, corresponding to 80% CPU utilization, indicating that the main chip's resources are becoming strained. The second preset threshold is used to determine whether the auxiliary processing chip has the ability to receive additional tasks. This threshold is set at a relatively low level, for example, corresponding to 30% CPU utilization, indicating that the auxiliary chip has sufficient idle resources.

[0052] It should be noted that this application achieves a key benefit by setting a set of interrelated load threshold conditions with clear comparative relationships for task migration, ensuring that load balancing operations are timely, effective, and do not cause secondary performance impacts on the system. Specifically, the migration conditions do not simply monitor whether the main processing chip is overloaded, but add a parallel evaluation of the current remaining processing capacity of the auxiliary processing chip. It requires that the two prerequisites of "the main processing chip load is greater than a first preset threshold" and "the auxiliary processing chip load is less than a second preset threshold" be met simultaneously. Furthermore, by limiting "the first preset threshold to be greater than or equal to the second preset threshold," it logically ensures that the migration behavior is triggered only under a reasonable difference in conditions where the main processing chip is indeed busier than the auxiliary processing chip. This dual-condition constraint mechanism ensures that the system's task migration decisions are prudent and efficient. On the one hand, it prevents ineffective or even harmful migration operations when the main processing chip is under high load but the auxiliary processing chip is also nearing saturation, avoiding potential overload of the auxiliary processing chip and subsequent global performance fluctuations caused by blind migration. On the other hand, it also prevents premature or unnecessary migration from being initiated when the auxiliary processing chip is idle and the main processing chip's load has not reached the critical point where external assistance is truly needed, thereby reducing unnecessary task scheduling overhead and communication interruptions. Therefore, the design of this migration condition ensures that load balancing actions are always triggered within an optimal time window where they are "truly necessary" and "the receiving party has the capability," ensuring that each migration operation can successfully alleviate the pressure on the main processing chip with a high probability, while not disrupting the original task stability of the auxiliary processing chip. This significantly improves the intelligence level of dynamic resource scheduling in the entire vehicle system and ultimately enhances its overall performance.

[0053] Optionally, the method flow steps of migrating the data processing task corresponding to at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel are as follows: S501, the main processing chip sends a response data packet to the at least one vehicle-mounted device, and modifies the vehicle terminal MAC (Media Access Control Address) address in the response data packet to the MAC address of the auxiliary processing chip, so that the at least one vehicle-mounted device can directly send data to the auxiliary processing chip in subsequent communications, thereby completing the migration of the data processing task corresponding to the at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel.

[0054] In the embodiments described in this specification, after the system decides to initiate migration based on the judgment in S102, the resource management module on the main processing chip obtains the list of target vehicle devices that need to be migrated. The main processing chip obtains the MAC address (physical address) of the auxiliary processing chip through the configuration information known within the system.

[0055] The main processing chip waits for an appropriate opportunity to establish network communication with the target vehicle device. Typically, this occurs after the target vehicle device sends a request data packet to the system (whose current communication partner is the main processing chip). When preparing to respond to the request, the main processing chip generates the content of a response data packet according to the standard procedure. However, during the construction of the data link layer frame of the data packet, a critical operation is performed: the "source MAC address" field is modified from its own MAC address to the MAC address of the auxiliary processing chip obtained in step 1. Subsequently, the main processing chip sends this response data packet with the modified "source address" to the target vehicle device normally.

[0056] The target vehicle's network controller receives this response packet. According to standard network protocols, this could be ARP (Address Resolution Protocol), which the device will learn and record. The physical address (MAC address) of the "vehicle infotainment system" (corresponding to an IP address) communicating with it has been changed to the address of the auxiliary processing chip. Thereafter, all subsequent data packets generated by the target vehicle will be directly sent to the new MAC address, i.e., the network interface of the auxiliary processing chip, at the data link layer. Data will then be delivered directly through network switches and other devices, bypassing the main processing chip.

[0057] Once the data stream is successfully redirected, the auxiliary processing chip begins receiving and independently processing the data processing tasks of the target vehicle-mounted device. The corresponding task instance on the main processing chip automatically becomes idle and can be safely terminated as it no longer receives data. Through this "communication link redirection" mechanism, the task migration target required by S102 is achieved efficiently.

[0058] It should be noted that this application achieves task migration by modifying the network layer address (MAC address), resulting in the core benefits of efficient and thorough migration with minimal resource consumption on the main processing chip. Specifically, this method does not internally forward data already received by the main processing chip; instead, the main processing chip replaces its own MAC address with the MAC address of the auxiliary processing chip in the response data packet sent to the vehicle-mounted device. This operation essentially reconstructs the communication link between the vehicle-mounted device and the vehicle system, allowing the network controller of the vehicle-mounted device to automatically direct the destination address of subsequent data frames to the auxiliary processing chip at the hardware level after receiving the modified response. The advantage of this migration mechanism lies in its fundamental nature: once the MAC address switch is complete, subsequent data flows completely bypass the main processing chip's network interface and are directly delivered to the auxiliary processing chip for processing via the physical link. This not only avoids the additional memory copy overhead and computational resource consumption caused by large-scale data transfer between the main and auxiliary processing chips but also completely relieves the main processing chip of the burden of receiving and forwarding data for migrated tasks, allowing the main processing chip's computational resources to be immediately and completely released to other critical tasks.

[0059] Optionally, embodiments of this application can shift from passively responding to load changes to actively predicting load peaks and eliminating system response latency by preparing resources in advance, thereby achieving a smoother performance experience. The specific method and steps are as follows: S601, Construct a usage behavior prediction model based on historical interaction data, wherein the historical interaction data includes the daily device connection time period, operation frequency and data transmission interval parameter change patterns.

[0060] In the embodiments described in this specification, the system has a built-in data logging service that continuously collects and stores long-term historical interaction data. This data includes at least: Daily device connection time periods: It can record the connection and disconnection events of each in-vehicle device (such as mobile phone Bluetooth, navigation system) at different time periods every day.

[0061] Operation frequency: This function can record the number of times a user operates on a specific function (such as voice assistant or seat adjustment) over time.

[0062] Data transmission interval parameter variation pattern: It can record the dynamic variation pattern of the data transmission interval parameter obtained in S301 under different scenarios (such as weekdays / weekends, morning and evening peak hours).

[0063] This data is timestamped and stored in a structured form in the vehicle system's non-volatile memory.

[0064] The system runs a lightweight analytics engine that periodically analyzes accumulated historical interaction data (e.g., once every 24 hours when the system is idle). This engine builds a behavior prediction model by identifying patterns in the data (e.g., "Every Monday to Friday at 8 AM, the navigation system and mobile phone Bluetooth automatically connect and begin high-speed data transmission"). This model is essentially a set of rules or a simple prediction function that, based on inputs such as "current time" and "day of the week," predicts the future activation probability of a specific in-vehicle device and the expected data processing workload.

[0065] S602, when it is predicted that the load status within a future preset time window will meet the preset migration conditions, the auxiliary processing chip will be activated in advance through the data transmission channel to enter the standby state.

[0066] In the embodiments of this specification, the system takes the current moment and the nearest future preset time window (e.g., the next 5 minutes) as input in real time or periodically and feeds them into the usage behavior prediction model constructed in S601.

[0067] The model outputs a prediction of the load status of the main processing chip and the auxiliary processing chip within the future time window.

[0068] Conditional Judgment: The system compares the predicted future load state with the preset migration conditions defined in the main process (i.e., the predicted main chip load > the first preset threshold, and the predicted auxiliary chip load < the second preset threshold). If the prediction result meets the condition, a preparatory action is triggered.

[0069] The main processing chip sends a specific wake-up or preparation command to the auxiliary processing chip via the data transmission channel. Upon receiving the command, the auxiliary processing chip switches from sleep or low-power mode to normal operating mode, completes operating system initialization, loads necessary drivers and runtime libraries, and puts its computing core in a ready state. At this time, the auxiliary chip does not handle actual vehicle equipment tasks, but is ready to immediately receive migration tasks; this state is called the standby state.

[0070] It should be noted that this application, by introducing a predictive decision-making mechanism based on historical data, brings the key benefit of upgrading system load management from passive response to proactive prevention, thereby significantly enhancing the smoothness and real-time performance of the system in handling foreseeable load peaks. Specifically, this method no longer relies solely on monitoring the current instantaneous load state, but instead constructs a "usage behavior prediction model" by analyzing "historical interaction data" containing patterns such as daily device connection times and operation frequencies. This allows the system to intelligently predict the load state that may occur in specific future time windows (e.g., daily commuting peaks, times when users habitually open complex applications). When the load is predicted to meet the migration conditions, the system does not wait for the actual load peak to arrive before initiating the migration process, but instead takes proactive action by "activating the auxiliary processing chip in advance to enter a standby state." This preparatory action allows the auxiliary processing chip to complete the initialization, related driver loading, and computing resource warm-up work in advance, from a low-power sleep state to a running state. The direct result is that when the predicted load peak actually arrives, the system no longer needs to waste valuable response time waiting for the auxiliary processing chip to start, and can achieve instantaneous and seamless task migration and processing. This prediction-based preparation mechanism effectively eliminates the delay window between the load threshold trigger and the auxiliary chip being fully ready, enabling the system to smoothly pass through load peaks with near-zero latency. This avoids the instantaneous stuttering or slow response that may be caused by the chip wake-up and initialization process, thereby fundamentally improving the system's intelligence level in dealing with periodic or habitual high-load scenarios and the smoothness of the user experience.

[0071] Optionally, after the system experiences high load, computing resources can be intelligently reclaimed and refocused, while idle chips are placed in a low-power state to optimize system energy efficiency. The specific steps are as follows: S701, periodically monitor the load status of the main processing chip and the auxiliary processing chip.

[0072] In the embodiments described in this specification, the resource manager collects real-time load data from the dual chips at fixed time intervals (e.g., per second). Monitoring metrics include key performance parameters such as CPU utilization, memory usage, and I / O load. The collected load status data is aggregated into a unified resource management database. The monitoring process is continuous, providing real-time data support for migration decisions.

[0073] S702, if the load of the main processing chip drops below the third preset threshold, and the auxiliary processing chip is running a data processing task corresponding to a low-priority vehicle device, then the data processing task corresponding to the low-priority vehicle device is migrated back to the main processing chip, and the auxiliary processing chip is controlled to enter a low-power state.

[0074] In the embodiments described in this specification, the resource manager compares the real-time load status of the main processing chip with a preset third threshold, while simultaneously checking the task priorities running on the auxiliary processing chip. When the conditions are met, the system selects a low-priority task from the auxiliary processing chip and migrates its execution context and data processing status back to the main processing chip via the data transmission channel. The data communication target address of the migrated task is redirected to the main processing chip to ensure that subsequent data is sent directly to the main processing chip. After confirming that there are no active tasks on the auxiliary processing chip, a low-power state switching command is sent to the auxiliary processing chip, causing it to enter a sleep or low-power operation mode.

[0075] By introducing a load-state-based task rollback mechanism and its associated chip power consumption control, this method achieves key benefits such as dynamic on-demand allocation of system resources and overall energy efficiency optimization. Specifically, this method does not create static resource occupancy after task migration. Instead, it continuously senses the overall system's busy / idle status by periodically monitoring the load state of the two chips. When the system detects that the load on the main processing chip has dropped below a third preset threshold, it indicates that the main chip has recovered sufficient processing power. At this point, if the auxiliary processing chip is still running data processing tasks corresponding to low-priority in-vehicle devices, the system will actively migrate these tasks back to the main processing chip. The significance of this rollback operation lies in reversing temporary load balancing measures, returning processing tasks to the main computing core, and freeing up the main chip's computing power for potentially new high-priority tasks. Furthermore, its deeper value lies in creating a crucial prerequisite for the state management of the auxiliary processing chip: after tasks are cleared, the system can immediately control the auxiliary processing chip to enter a low-power state. This eliminates the need for the auxiliary chip to operate at full power during task intervals, significantly reducing the idle power consumption of the entire vehicle system.

[0076] Figure 2 This is a schematic diagram of a data processing system based on a multi-chip Bluetooth architecture, specifically including: Bluetooth Chip A (Main Processing Chip): Supports Bluetooth 5.3 and above protocols, and has the ability to connect to multiple devices simultaneously. Its core functions include: initial HID data reception, multi-device interval parameter judgment, target device MAC address identification, response data packet encapsulation and MAC address modification, and sending of chip B start control commands.

[0077] Bluetooth Chip B (Auxiliary Processing Chip): This is a Bluetooth module from the same series as Chip A. It features low power consumption and high-efficiency data processing. Its core functions include: responding to the startup command of Chip A, receiving and processing HID data from the migrated device, and interacting with the vehicle system.

[0078] High-speed data transmission channel: Built using high-speed communication protocols such as UART (Universal Asynchronous Receiver / Transmitter) or SPI (Serial Peripheral Interface), it enables real-time command and data interaction between chip A and chip B, ensuring timely device migration and data transmission.

[0079] Load monitoring module: Integrated into the vehicle's main control unit, it collects load parameters (including the number of currently connected devices, CPU utilization, and data throughput) from chip A and chip B in real time, sets load thresholds (high load: number of connections ≥ 85% of chip's rated value or CPU utilization ≥ 90%; low load: number of connections ≤ 50% of chip's rated value and CPU utilization ≤ 60%), and sends a trigger signal to chip A when the load parameters exceed the threshold.

[0080] Priority configuration module: Provides dual priority rules, including user-defined and system default rules. The default rules are divided by device type (navigation remote control > driver assistance remote control > multimedia remote control > ordinary HID device). Users can adjust the priority through the vehicle interface; the rule data is synchronized to the control logic of chip A.

[0081] Predictive scheduling module: Based on historical data, a predictive model is built. The core input parameters include: daily device connection time period, device operation frequency, and interval parameter change pattern. When it is predicted that multiple devices will be connected concurrently within the next 5 seconds (such as users accustomed to starting navigation and music at the same time during commuting peak hours), a pre-start command is sent to chip A in advance, triggering chip B to enter standby state.

[0082] The data processing flow is as follows: Based on the above system, the processing steps for data from multiple HID devices are as follows: 1. System initialization and rule configuration: After the vehicle system is powered on, chip A and chip B complete the UART handshake; the priority configuration module loads the default priority rules (which can be manually modified by the user); the load monitoring module initializes the threshold parameters; the prediction scheduling module starts loading historical data and initializing the model. After completion, chip B enters a low-power standby state, and chip A starts Bluetooth scanning.

[0083] 2. Intelligent prediction and pre-start: The prediction and scheduling module analyzes the device connection trend in real time. If it identifies high-frequency concurrent periods such as "morning peak 7:30-8:30", or detects that the Bluetooth signal strength of high-priority devices (such as navigation remote controllers) is continuously increasing (indicating that they will connect soon), it immediately sends a pre-start command to chip A. Chip A activates chip B to enter standby state through the high-speed channel, shortening the subsequent migration response time.

[0084] 3. Initial Data Reception and Multi-dimensional Judgment: When chip A receives two or more HID data simultaneously, it performs a triple judgment: ① Parse the HID protocol to extract the interval parameters of each device; ② Obtain the priority level of each device through the priority configuration module; ③ Receive the current load data of chips A and B fed back by the load monitoring module.

[0085] 4. Target device screening and decision-making: Chip A performs migration decisions based on the results of the triple judgment: Basic rule: Prioritize devices with larger interval values; Priority constraint: Even if the interval is short, high-priority devices (such as navigation remote controllers) will be retained on chip A if the load on chip A is ≥70%, and low-priority devices with long intervals will be migrated. Load balancing: If the load of chip A is ≥85%, regardless of the interval size, low-priority devices will be migrated to chip B first; if the load of chip B is ≤50%, multiple low-priority long-interval devices can be migrated simultaneously.

[0086] 5. Response data packet encapsulation and MAC address modification: Chip A encapsulates a response data packet for the target device, modifies the MAC address of the vehicle's terminal from its own to that of chip B, and sends it to the target device.

[0087] 6. Device communication link migration: After the target device parses the response, all subsequent data is assembled and sent using the MAC address of chip B.

[0088] 7. Chip B Startup and Data Processing: Chip A synchronously sends a startup command to Chip B (skipping if pre-started). Chip B receives and processes the target device data, and simultaneously provides real-time feedback on its own load to the load monitoring module.

[0089] 8. Dynamic load adjustment (cyclic execution): The load monitoring module collects the dual-chip load every 100ms. ① If the load on chip A drops below 50%, and there are low-priority devices on chip B, chip A sends a migration command to migrate the device link back to chip A, and chip B resumes low power consumption. ② If the load of chip B is ≥90%, chip A will stop migrating devices to it, prioritize processing high-priority data, and resume migration after the load of chip B decreases; ③ If a high-priority device is connected, chip A will release the resources occupied by low-priority devices first, and forcibly migrate low-priority devices to chip B if necessary.

[0090] In this embodiment, the following specific implementation plan can be adopted: 1. Chip A uses a vehicle-grade Bluetooth 5.3 or higher main chip, which supports up to 8 HID devices to connect at the same time and has peripheral interfaces such as UART and SPI. 2. Chip B uses the same series of Bluetooth chips, which have low power consumption characteristics and data processing speed matching that of chip A; 3. Chip A and Chip B establish a data transmission channel through the UART interface, with the baud rate set to 115200bps and the data transmission format configured as 8 data bits, 1 stop bit, and no parity bit to ensure real-time transmission of instructions and data.

[0091] 4. The load monitoring module, priority configuration module, and predictive scheduling module are integrated into the vehicle's main control chip (model: Qualcomm Snapdragon 8155) through software, occupying ≤5% of system resources and not affecting the operation of other functions.

[0092] In this embodiment, the following specific operation steps can be followed: This embodiment uses the simultaneous operation of three HID remote controllers: Remote 1 (priority 1, interval = 15ms), Remote 2 (priority 1, interval = 20ms), and Remote 3 (priority 1, interval = 25ms). The specific operation steps are as follows: 1. System initialization and pre-start: After the vehicle system is powered on, chips A and B complete the UART handshake; the priority configuration module loads the corresponding rules (1>2>3); the prediction and scheduling module identifies the current time period, sends a pre-start command to chip A, and chip B enters the standby state.

[0093] 2. Multi-device connection and load triggering: When the user connects remote control 1, remote control 2 and remote control 3 in sequence, chip A receives operation data from the three devices simultaneously. When the load monitoring module collects data and chip A's load reaches 88% (6 / 8 of the connections), it sends a high load signal to chip A.

[0094] 3. Multidimensional decision-making and target determination: Chip A extracts parameters (remote controller 1 / priority 1, remote controller 2 / priority 2, remote controller 3 / priority 3), and combines them with the high load state of chip A to make the following decision: retain the high-priority navigation remote controller in chip A, and migrate remote controller 2 (medium priority long interval) and remote controller 3 (low priority longest interval) to chip B.

[0095] 4. Response frame transmission and device migration: Chip A encapsulates two response data packets, modifies the MAC address of the vehicle terminal to the address of chip B, and sends them to remote controller 2 and remote controller 3; simultaneously, it sends a device migration list (including the MAC addresses of the two devices) to chip B.

[0096] 5. Parallel processing and dynamic adjustment: Chip A focuses on processing the instructions of remote controller 1 (with minimal response latency); Chip B receives and processes the instructions of remote controller 2 and remote controller 3. At this time, the load monitoring module collects the load of chip B; after 10 seconds, the operating frequency of remote controller 1 decreases, and the load of chip A decreases at the same time. At this time, chip A sends a backhaul instruction to backhaul the link of the medium-priority remote controller 2, and chip B retains only remote controller 3, and the load decreases.

[0097] Figure 3 This is a schematic diagram of a vehicle infotainment system. The system includes a main processing chip 301, an auxiliary processing chip 302, and a main control unit 303. The main processing chip and the auxiliary processing chip are connected through a pre-defined data transmission channel. The vehicle main control device 303 receives data processing tasks corresponding to multiple vehicle devices through the main processing chip 301 and the auxiliary processing chip 302, and monitors the load status of the main processing chip 301 and the auxiliary processing chip 302. If the load state meets the preset migration conditions, the vehicle main control device 303 will migrate the data processing task corresponding to at least one vehicle device to the auxiliary processing chip 302 through the data transmission channel, and the auxiliary processing chip 302 will process the data processing task corresponding to the vehicle device.

[0098] Optionally, the vehicle main control device receives data processing tasks corresponding to multiple vehicle devices through the main processing chip and the auxiliary processing chip, including: an operating system and a system task scheduler; The operating system obtains the pre-set priorities corresponding to each in-vehicle device; The system task scheduler receives data processing tasks corresponding to the vehicle-mounted devices that meet the corresponding priorities through the main processing chip and the auxiliary processing chip, based on pre-set priority rules.

[0099] Optionally, before the vehicle-mounted main control device migrates the data processing task corresponding to at least one in-vehicle device to the auxiliary processing chip through the data transmission channel, it further includes: a monitoring module; The monitoring module parses the data packets sent by each vehicle-mounted device to obtain the data transmission interval parameters of each vehicle-mounted device; The vehicle's main control unit determines the number of on-board devices to be migrated based on the load status. The vehicle control unit determines the data processing task corresponding to the target vehicle device to be migrated based on the data transmission interval parameter and the number of vehicle devices to be migrated.

[0100] Optionally, the vehicle control unit determines the data processing task corresponding to the target vehicle device to be migrated based on the data transmission interval parameter and the number of vehicle devices to be migrated, including: The vehicle control unit determines the data processing task corresponding to the target vehicle device to be migrated based on the priority of each vehicle device, the data transmission interval parameter, and the number of vehicle devices to be migrated.

[0101] Optionally, the load state satisfies preset migration conditions, including: The load state of the main processing chip is greater than a first preset threshold. The load state of the auxiliary processing chip is less than the second preset threshold, and the first preset threshold is greater than or equal to the second preset threshold.

[0102] Optionally, the vehicle-mounted main control device migrates the data processing tasks corresponding to at least one in-vehicle device to the auxiliary processing chip through the data transmission channel, including: The vehicle-mounted main control device sends a response data packet from the main processing chip to the at least one vehicle-mounted device, and modifies the MAC address of the vehicle-mounted terminal in the response data packet to the MAC address of the auxiliary processing chip, so that the at least one vehicle-mounted device will send data directly to the auxiliary processing chip in subsequent communications, thereby completing the migration of the data processing task corresponding to the at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel.

[0103] Optional, also includes: The vehicle's main control unit builds a usage behavior prediction model based on historical interaction data, which includes the daily device connection time period, operation frequency, and data transmission interval parameter variation patterns. When the vehicle's main control unit predicts that the load status within a preset time window will meet the preset migration conditions, it will activate the auxiliary processing chip in advance through the data transmission channel to enter a standby state.

[0104] Optional features also include: System Explorer; The resource manager periodically monitors the load status of the main processing chip and the auxiliary processing chip; If the load on the main processing chip drops below the third preset threshold, and the auxiliary processing chip is running a data processing task corresponding to a low-priority vehicle device, the vehicle main control device will migrate the data processing task corresponding to the low-priority vehicle device back to the main processing chip and control the auxiliary processing chip to enter a low-power state.

[0105] This disclosure provides a schematic diagram of the structure of a vehicle according to an embodiment. The vehicle includes: Figure 3 The vehicle infotainment system shown.

[0106] The same or similar parts between the various embodiments in this specification can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.

[0107] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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.

[0108] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device 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 system, or some features may be ignored or not executed. Furthermore, the 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.

[0109] The units described as separate components may or may not be physically separate. 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 can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] 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 aforementioned units can be implemented in hardware or software.

[0111] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

Claims

1. A data processing method for vehicle-mounted equipment based on multi-chip technology, characterized in that, The method is applied to an in-vehicle infotainment system, which includes a main processing chip and an auxiliary processing chip. The main processing chip and the auxiliary processing chip are connected through a pre-defined data transmission channel. The method includes: The main processing chip and the auxiliary processing chip receive data processing tasks corresponding to multiple vehicle-mounted devices and monitor the load status of the main processing chip and the auxiliary processing chip. If the load state meets the preset migration conditions, the data processing task corresponding to at least one vehicle-mounted device will be migrated to the auxiliary processing chip through the data transmission channel, and the auxiliary processing chip will process the data processing task corresponding to the vehicle-mounted device.

2. The method according to claim 1, characterized in that, The process of receiving data processing tasks corresponding to multiple vehicle-mounted devices through the main processing chip and the auxiliary processing chip includes: Obtain the pre-set priority of each vehicle-mounted device; Based on pre-set priority rules, the main processing chip and the auxiliary processing chip receive data processing tasks corresponding to the vehicle-mounted devices that meet the corresponding priorities.

3. The method according to claim 2, characterized in that, Before migrating the data processing task corresponding to at least one vehicle-mounted device to the auxiliary processing chip via the data transmission channel, the method further includes: Parse the data packets sent by each vehicle-mounted device to obtain the data transmission interval parameters of each vehicle-mounted device; The number of on-board devices to be migrated is determined based on the load status. Based on the data transmission interval parameter and the number of vehicle-mounted devices to be migrated, the data processing task corresponding to the target vehicle-mounted device to be migrated is determined.

4. The method according to claim 3, characterized in that, The step of determining the data processing task corresponding to the target vehicle-mounted device to be migrated based on the data transmission interval parameter and the number of vehicle-mounted devices to be migrated includes: Based on the priority of each vehicle-mounted device, the data transmission interval parameter, and the number of vehicle-mounted devices to be migrated, the data processing task corresponding to the target vehicle-mounted device to be migrated is determined.

5. The method according to claim 1, characterized in that, The load state meets preset migration conditions, including: The load state of the main processing chip is greater than a first preset threshold. The load state of the auxiliary processing chip is less than the second preset threshold, and the first preset threshold is greater than or equal to the second preset threshold.

6. The method according to claim 1, characterized in that, The step of migrating the data processing task corresponding to at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel includes: The main processing chip sends a response data packet to the at least one vehicle-mounted device, and modifies the vehicle terminal MAC address in the response data packet to the MAC address of the auxiliary processing chip, so that the at least one vehicle-mounted device can directly send data to the auxiliary processing chip in subsequent communications, thereby completing the migration of the data processing task corresponding to the at least one vehicle-mounted device to the auxiliary processing chip through the data transmission channel.

7. The method according to claim 1, characterized in that, The method further includes: A behavior prediction model is constructed based on historical interaction data, which includes the daily device connection time period, operation frequency and data transmission interval parameter variation patterns. When the predicted load state within a future preset time window meets the preset migration conditions, the auxiliary processing chip is activated in advance through the data transmission channel to enter a standby state.

8. The method according to claim 1, characterized in that, The method further includes: The load status of the main processing chip and the auxiliary processing chip is periodically monitored; If the load on the main processing chip drops below the third preset threshold, and the auxiliary processing chip is running a data processing task corresponding to a low-priority vehicle device, then the data processing task corresponding to the low-priority vehicle device is migrated back to the main processing chip, and the auxiliary processing chip is controlled to enter a low-power state.

9. A vehicle infotainment system, characterized in that, The vehicle infotainment system includes a main processing chip, an auxiliary processing chip, and a vehicle infotainment main control unit. The main processing chip and the auxiliary processing chip are connected through a pre-defined data transmission channel, including: The vehicle infotainment main control device receives data processing tasks corresponding to multiple vehicle devices through the main processing chip and the auxiliary processing chip, and monitors the load status of the main processing chip and the auxiliary processing chip. If the load state meets the preset migration conditions, the vehicle main control device will migrate the data processing task corresponding to at least one vehicle device to the auxiliary processing chip through the data transmission channel, and the auxiliary processing chip will process the data processing task corresponding to the vehicle device.

10. A vehicle, characterized in that, Including the vehicle infotainment system as described in claim 9.

Images