Intelligent cabin dual-system CPU core dynamic sharing scheduling method, device and system

Abstract

The invention provides an intelligent cabin dual-system CPU core dynamic sharing scheduling method, device and system. The sharing scheduling method comprises the steps that at least one CPU core is selected from cabin chips to serve as a sharing core pool; the CPU utilization rate of the Linux system and the Android system and the foreground application type of the main and co-driver screen are monitored in real time; dynamically adjusting an affiliation system of the shared nuclear pool according to a monitoring result and a preset scheduling condition; and after the affiliation system of the shared nuclear pool is switched each time, locking the current affiliation state of the shared nuclear pool for a first set time length. According to the method and the device, the technical problem that computing resources of dual-system CPUs are wasted due to the fact that CPU resources cannot be flexibly allocated according to real-time loads in an existing CPU allocation scheme is solved. According to the method and the device, the CPU sharing core pool is arranged, and the affiliation system of the sharing core pool is dynamically adjusted, so that efficient utilization of CPU computing resources is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent cockpit, in particular to an intelligent cockpit dual-system CPU core dynamic sharing scheduling method, device and system. BACKGROUND

[0002] With the increasing diversification of intelligent cockpit functions, complex applications such as multi-screen interaction, voice assistants, ADAS assisted driving, and high-end in-vehicle entertainment are integrated. Using Linux and Android dual-system architecture has become the industry mainstream solution. However, this poses higher challenges to the underlying CPU's computing resources. Currently, existing cockpit chips usually use a static allocation scheme, which pre-allocates CPU cores to Linux and Android systems. This allocation method can easily cause resource competition in extreme high-load scenarios, leading to performance lag in one system due to insufficient resources. For example, when the Android system is running a game, it may cause a sudden drop in frame rate; in the Linux system, the display of real-time navigation may be delayed. In addition, since the loads of the dual systems are not always balanced, when one system is at full load, the dedicated CPU cores of the other system are often in a low utilization state, which can cause waste of overall computing resources.

[0003] The existing CPU allocation scheme cannot flexibly allocate CPU resources according to real-time load, resulting in waste of computing resources of dual-system CPUs. SUMMARY

[0004] The present application solves the technical problem that the existing CPU allocation scheme cannot flexibly allocate CPU resources according to real-time load, resulting in waste of computing resources of dual-system CPUs. The present application sets up a CPU shared core pool and dynamically adjusts the attribution system of the shared core pool, achieving efficient use of CPU computing resources.

[0005] To solve the above problems, the present application provides an intelligent cockpit dual-system CPU core dynamic sharing scheduling method, which includes: selecting at least one CPU core as a shared core pool in a cockpit chip; monitoring the CPU utilization of the Linux system and the Android system and the foreground application type of the main and vice driver screens in real time; dynamically adjusting the attribution system of the shared core pool according to the monitoring results and preset scheduling conditions; locking the current attribution state of the shared core pool for a first set time length after each attribution system switch of the shared core pool.

[0006] Compared with the prior art, the technical effects achieved by adopting the technical scheme are: by monitoring the CPU utilization of the two systems in real time and dynamically adjusting the belonging system of the shared core pool, the cabin system can realize more efficient resource utilization under high load conditions, and avoid affecting the overall performance due to overload of a certain system. At the same time, by setting the locking duration of the belonging state of the shared core pool, the system instability caused by frequent switching can be avoided, and a certain time window is provided for the system to facilitate smooth transition between different applications. Moreover, by intelligent scheduling, according to the foreground application type and real-time data of the main and vice driver screens, the load of different systems can be balanced, and the needs of users in the driving and riding processes can be better met.

[0007] In one possible design, when the cockpit chip starts, the shared core pool is wholly or partially attributed to the Linux system.

[0008] Compared with the prior art, the technical effects achieved by adopting the technical scheme are: since the Linux system controls the basic and safety functions of the vehicle, preferentially allocating CPU resources to the Linux system can ensure that critical safety functions can run in time and stably during the startup phase, thereby ensuring driving safety and system reliability. Moreover, the Linux system usually needs to load multiple services and processes during startup, and preferentially allocating CPU cores to the Linux system during the startup phase can speed up its startup, thereby enabling the system to be put into use in a shorter time and improving overall startup efficiency.

[0009] In one possible design, the preset scheduling conditions include: when the CPU utilization of the Linux system is less than or equal to a first standard value and lasts for a second set duration, if the main and vice driver screens both run Android foreground applications or the CPU utilization of the Android system of the main driver screen is greater than or equal to a second standard value, the shared core pool is switched from the Linux system to the Android system.

[0010] Compared with the prior art, the technical effects achieved by adopting the technical scheme are: by setting the threshold value and duration of CPU utilization as the switching standard, idle resources can be allocated to the Android system when the load of the Linux system is low, thereby optimizing the performance of the entire system. Moreover, by setting the second set duration, frequent switching of the belonging of the shared core pool due to transient fluctuations can be avoided, which improves the reliability of the system. At the same time, when the main and vice driver screens both run Android foreground applications, computing resources can be intelligently allocated to the Android system to ensure smooth running and improve user satisfaction with entertainment and application experience.

[0011] In one possible design, the preset scheduling condition further includes: when the CPU utilization of the Linux system is greater than or equal to a third standard value and lasts for a third set duration, and both the main driver screen and the copilot screen run the Linux foreground application, the shared core pool is switched from the Android system to the Linux system.

[0012] Compared with the prior art, the technical effects achieved by adopting the technical solution are: by monitoring the CPU utilization of the Linux system, the system can quickly respond when the load increases, ensuring that critical Linux applications can obtain sufficient CPU resources and avoiding performance degradation due to insufficient resources, which improves the overall reliability of the system. Moreover, by setting specific conditions such as the third standard value and the third set duration, the system can dynamically adjust to different time periods and states, maximizing the adaptation to changes in the running environment and ensuring efficient use of resources.

[0013] In one possible design, if the Linux system has a safety-related interrupt or the real-time task latency exceeds a threshold during the locking period, the locking is immediately released and the shared core pool is switched to the Linux system.

[0014] Compared with the prior art, the technical effects achieved by adopting the technical solution are: by monitoring safety-related interrupts in real time, the system can ensure that when potential security threats are detected, the locking is released in time and resources are allocated to the Linux system in priority. This rapid response mechanism can improve the system's resistance to security attacks or abnormal situations and reduce the risk of security incidents. At the same time, monitoring the latency of real-time tasks can ensure that critical applications such as vehicle control systems and sensor data processing receive timely resource support, avoiding delays caused by insufficient resources and ensuring that the system can respond and handle emergency events in real time.

[0015] In one possible design, when selecting CPU cores as the shared core pool, large cores are selected to form the shared core pool.

[0016] Compared with the prior art, the technical effects achieved by adopting the technical solution are: large cores are usually used to handle high-load and complex computing tasks, and they have a clear advantage in performance compared to small cores. Configuring the shared core pool with large cores can provide higher computing power when needed, enabling high-load tasks to be executed more quickly and efficiently. Moreover, large cores usually have higher processing power and faster response time, which is crucial for applications that require low latency and high real-time performance. Prioritizing the use of large cores can ensure that these real-time tasks are processed in time.

[0017] In a possible design, the identification of the foreground application type of the main and copilot screens includes: determining the current foreground application type of the main and copilot screens by monitoring the frame buffer write behavior of each screen and / or querying the foreground application record of the window manager.

[0018] Compared with the prior art, the technical effects achieved by adopting the technical solution are: by directly monitoring the frame buffer write behavior, the content change displayed on the screen can be captured in time, which is more accurate than pure software query, which can reduce the recognition errors caused by application switching delay and provide accurate foreground application state. Moreover, by querying the window manager, the system can quickly obtain the information of the current foreground application, reducing the waiting time for monitoring the state of the application, thereby realizing more efficient resource management and scheduling.

[0019] The application further provides an intelligent cockpit dual-system CPU core dynamic sharing scheduling device, and an intelligent cockpit dual-system CPU core dynamic sharing scheduling method is implemented by using the sharing scheduling device. The sharing scheduling device comprises: a monitoring unit configured to collect the CPU utilization of a Linux system and an Android system and the foreground application state of main and copilot screens in real time; a decision unit configured to generate a shared core scheduling instruction according to the data provided by the monitoring unit and a preset scheduling condition; and an execution unit configured to execute the shared core scheduling instruction and switch the home system of the shared core pool.

[0020] Compared with the prior art, the technical effects achieved by adopting the technical solution are: the intelligent cockpit dual-system CPU core dynamic sharing scheduling device is used to implement the intelligent cockpit dual-system CPU core dynamic sharing scheduling method of any of the technical solutions of the application, and therefore has all the beneficial effects of the intelligent cockpit dual-system CPU core dynamic sharing scheduling method of any of the technical solutions of the application, which will not be described herein again.

[0021] In a possible design, the execution unit controls the online state of the shared core pool through a kernel hot plug driver on the Linux system side and binds high-priority tasks to the shared core pool through a task affinity setting interface on the Android system side.

[0022] Compared with the prior art, the technical effects achieved by adopting the technical scheme are that the core hot plug driver allows the Linux system to dynamically add or remove CPU cores at runtime, so that the system can adjust CPU resources according to real-time needs, and the flexibility and adaptability of resource scheduling are enhanced. At the same time, by using the task affinity setting interface on the Android system side, high-priority tasks are bound to the shared core pool, which can ensure that these critical tasks are given priority processing, reduce task switching and scheduling delay, and improve the overall response speed of the system. Moreover, by combining the hot plug feature of the Linux system and the task affinity setting of the Android system, the system can more accurately allocate resources to high-load tasks, thereby improving the efficiency of the system in a multi-task environment and ensuring that all applications can run smoothly.

[0023] The application also provides an intelligent cockpit system, and the intelligent cockpit dual-system CPU core dynamic sharing scheduling method is applied to the intelligent cockpit system.

[0024] Compared with the prior art, the technical effects achieved by adopting the technical scheme are that the intelligent cockpit dual-system CPU core dynamic sharing scheduling method of any of the technical solutions of the application is applied to the intelligent cockpit system of the application, so that the intelligent cockpit system of the application has all the beneficial effects of the intelligent cockpit dual-system CPU core dynamic sharing scheduling method of any of the technical solutions of the application, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 A flowchart of the intelligent cockpit dual-system CPU core dynamic sharing scheduling method provided for the embodiments of the application is shown in the figure. Figure 2 A structural schematic diagram of the intelligent cockpit dual-system CPU core dynamic sharing scheduling device provided for the embodiments of the application is shown in the figure. DETAILED DESCRIPTION

[0026] In order to make the above-mentioned purposes, features and advantages of the application more obvious and easy to understand, the specific embodiments of the application will be described in detail below with reference to the accompanying drawings.

[0027] Referring to Figure 1 The application provides an intelligent cockpit dual-system CPU core dynamic sharing scheduling method, which comprises the following steps: selecting at least one CPU core as a shared core pool in a cockpit chip; monitoring the CPU utilization of a Linux system and an Android system and the foreground application type of a main driver screen and a deputy driver screen in real time; dynamically adjusting the attribution system of the shared core pool according to the monitoring result and a preset scheduling condition; and locking the current attribution state of the shared core pool for a first set time length after each attribution system switching of the shared core pool.

[0028] Specifically, the traditional cockpit dual system usually reserves fixed CPU cores for Linux and Android systems, which may cause the CPU cores of one system to be idle while the other system is under low load when one of the systems is stuck due to insufficient resources. The application can allocate a shared core pool to the system with insufficient resources when one of the systems is insufficient in CPU resources and the other system is under low load, thereby improving the computing power and reducing system delays caused by insufficient resources. The application can dynamically adjust the system to which the shared core pool belongs according to actual needs, thereby improving the CPU resource utilization of the cockpit chip and balancing the load demand between different systems.

[0029] The first set time length is 5 seconds. Each time the system to which the CPU core belongs is switched, there is a certain overhead, including context switching, data cache invalidation, system resource reallocation, etc. If the switching is too frequent, these overheads will accumulate and reduce the overall performance of the system. Therefore, setting a lock time of 5 seconds can provide a buffer period for the stable operation of the system before and after switching, ensure that the new scheduling strategy can be effectively executed, and give the system enough time to adapt to the new resource allocation. In extreme cases (such as running games on the Android system and running navigation on the Linux system), the dynamic shared scheduling method can improve the frame rate stability of the Android system by 22% and reduce the navigation response delay of the Linux system by 18%. At the same time, the average idle rate of the CPU core is reduced from 15% to 5%, and the overall resource utilization is improved by 40%. After each switching of the system to which the shared core pool belongs, the current belonging state of the shared core pool is locked for 5 seconds, which can reduce more than 90% of invalid switching and reduce the smart cockpit system by 35%.

[0030] In an embodiment of the application, when the cockpit chip starts, all or part of the shared core pool belongs to the Linux system.

[0031] Specifically, in the cockpit system, the Linux system is usually used to run key functions such as vehicle control, vehicle body electronics, instrument panel display, navigation, ADX (advanced driving assistance system), etc. These functions are related to driving safety and basic vehicle operation and must be guaranteed high priority and stability. In addition, during the system startup phase, the Linux system needs sufficient CPU resources to complete initialization, load drivers, start various background services, etc. Therefore, pre-allocating a shared core pool to the Linux system can ensure the smooth completion of these key tasks and avoid startup delays or function abnormalities caused by insufficient resources.

[0032] In an embodiment of the present application, the preset scheduling condition comprises: when the CPU utilization of the Linux system is less than or equal to a first standard value and lasts for a second set duration, if the main driver screen and the co-driver screen both run an Android foreground application or the CPU utilization of the Android system of the main driver screen is greater than or equal to a second standard value, the shared core pool is switched from the Linux system to the Android system.

[0033] Specifically, in the embodiment, the first standard value is 80%, the second set duration is 3 seconds, and the second standard value is 90%. When the CPU utilization of the Linux system is less than 80% and lasts for more than 3 seconds, if the main driver screen and the co-driver screen both run an Android foreground application or the CPU utilization of the Android system of the main driver screen is greater than or equal to 90%, the shared core pool is switched from the Linux system to the Android system.

[0034] For example, when the detection unit detects that the main driver screen runs a game of the Android system, and the CPU utilization of the Android system reaches 92% and lasts for more than 3 seconds, and the Linux system runs a navigation, and the CPU utilization of the Linux system is 75%, the shared core pool is triggered to be transferred, and the shared core pool is switched from the Linux system to the Android system. This can improve the game frame rate of the Android system from 45 fps to 60 fps, and the navigation voice broadcast of the Linux system is not stuck.

[0035] In an embodiment of the present application, when the CPU utilization of the Linux system is greater than or equal to a third standard value and lasts for a third set duration, and the main driver screen and the co-driver screen both run a Linux foreground application, the shared core pool is switched from the Android system to the Linux system.

[0036] Specifically, in the embodiment, the third standard value is 85%, and the third set duration is 5 seconds. When the CPU utilization of the Linux system is greater than or equal to 85% and lasts for more than 5 seconds, and the main driver screen and the co-driver screen both run a Linux foreground application, the shared core pool is switched from the Android system to the Linux system.

[0037] For example, when the detection unit detects that the main driver screen and the co-driver screen run a dashboard of the Linux system and a HUD (Head-Up Display) projection of the Linux system, and the CPU utilization of the Linux system reaches 88% and lasts for more than 5 seconds, the shared core pool is triggered to be recycled, and the shared core pool is switched from the Android system to the Linux system. This can reduce the delay of 3D rendering from 50 ms to 30 ms.

[0038] In an embodiment of the present application, if a security-related interruption occurs or the waiting time of a real-time task exceeds a threshold value during the locking, the locking is immediately released and the shared core pool is switched to the Linux system.

[0039] Specifically, the "security-related interruption" generally means that the system detects a potential security threat, such as an intrusion attempt, malicious software behavior, system integrity being compromised, etc. In the intelligent cockpit system, any security problem can lead to serious consequences, such as vehicle control being hijacked, etc. Therefore, for security incidents, response speed is crucial, and CPU resources need to be immediately allocated to the Linux system so that it can timely handle the interruption, start security protection measures, record logs, and even isolate affected components to prevent damage from spreading. At the same time, Linux usually undertakes tasks in the intelligent cockpit with high real-time requirements, such as vehicle control, driving assistance, high-precision navigation, etc., which must be completed within a strict time window, otherwise it may lead to functional failure and affect driving safety. "The waiting time of a real-time task exceeds a threshold value" indicates that a certain key real-time task does not get CPU resources within the preset time, which means that the system may be losing control of some important functions or is about to miss the opportunity for a critical operation. Immediately switching the shared core pool to the Linux system is to ensure that these real-time tasks can obtain CPU execution as soon as possible to avoid system failure or security risks due to delays.

[0040] In an embodiment of the present application, when selecting a CPU core as a shared core pool, a big core is selected to form the shared core pool.

[0041] Specifically, in modern multi-core processors, in order to achieve the best balance between performance and power consumption, a heterogeneous multi-processing (HMP) architecture, also known as a big-little architecture, is usually adopted. Among them, the big core is usually a CPU core with larger cache and more powerful instruction execution unit, which can provide higher computing power to handle tasks with high performance requirements. The little core is usually a CPU core with relatively low performance, lower frequency, and lower power consumption, which provides basic computing power to handle background tasks that do not require high performance but need to run for a long time. Therefore, selecting a big core to form a shared core pool is to ensure that the shared core pool has sufficient computing power to maintain stable, smooth and safe operation when facing high performance requirements and sudden high load.

[0042] In an embodiment of the present application, the identification of the front application type of the main and copilot screens includes: determining the current front application type of the main and copilot screens by monitoring the frame buffer writing behavior of each screen and / or querying the front application record of the window manager.

[0043] Specifically, the identification of the foreground application type of the main and co-pilot screen is to find out what type of application is being displayed and run on the main driver screen, for example, navigation, media playback, vehicle settings, games, etc., and what type of application is being displayed and run on the co-pilot screen. In the intelligent cockpit, the main driver screen and the co-pilot screen usually have independent frame buffers, and each application writes new pixel data to the corresponding frame buffer when updating its display content. The system can continuously monitor which processes are performing write operations to a specific frame buffer, and by tracking the source process ID of the write operation, the corresponding application program name and type can be found. The window manager is a core component of the operating system, which is responsible for managing all application windows, including their creation, layout, layering order, focus management, and rendering. The window manager log records which window is currently in focus, i.e. the active window being operated by the user, which is the foreground application. By combining these two or one of the methods, the intelligent cockpit system can accurately determine which type of application is currently running and interacting with the main driver and co-pilot screens, thereby providing a key basis for subsequent CPU core dynamic sharing scheduling. The system detects the foreground application type with a granularity of 1 second, ensuring timely response.

[0044] Referring to Figure 2 The application also provides an intelligent cockpit dual-system CPU core dynamic sharing scheduling device. The intelligent cockpit dual-system CPU core dynamic sharing scheduling method is implemented through the sharing scheduling device. The sharing scheduling device comprises a monitoring unit, a decision unit, and an execution unit. The monitoring unit is configured to collect the CPU utilization of the Linux system and the Android system and the foreground application state of the main and co-pilot screens in real time. The decision unit is configured to generate a shared core scheduling instruction according to the data provided by the monitoring unit and a preset scheduling condition. The execution unit is configured to execute the shared core scheduling instruction and switch the belonging system of the shared core pool.

[0045] Specifically, the intelligent cockpit dual-system CPU core dynamic sharing scheduling device of the application is used to implement the intelligent cockpit dual-system CPU core dynamic sharing scheduling method of any technical solution of the application, and therefore has all the beneficial effects of the intelligent cockpit dual-system CPU core dynamic sharing scheduling method of any technical solution of the application, which will not be described here.

[0046] In an embodiment of the application, the execution unit controls the online state of the shared core pool through a kernel hot plug driver on the Linux system side and binds high-priority tasks to the shared core pool through a task affinity setting interface on the Android system side.

[0047] Specifically, in the Linux kernel, the "hot-plug" mechanism allows hardware devices to be added or removed dynamically at runtime without rebooting the system; for CPU cores, the kernel hot-plug function allows the system to dynamically bring online or offline CPU cores at runtime. When a CPU core is brought offline, it stops executing tasks and enters a low-power state, and all tasks running on it are migrated to other online CPU cores. When a CPU core is brought online, it is reactivated and can start scheduling tasks. Therefore, through hot-plug, the physical isolation and complete allocation of the shared core pool at the Linux system level can be achieved. Among them, the task affinity setting interface is a feature of the operating system scheduler, which allows a process or thread to be bound to a specific CPU core or a group of CPU cores for execution. Once the task is bound, the operating system scheduler will only schedule the task to the specified CPU core and will not schedule it to other CPU cores. Therefore, by binding critical high-priority tasks to the shared core pool, it can be ensured that they have sufficient computing resources.

[0048] The application also provides an intelligent cockpit system, and the intelligent cockpit dual-system CPU core dynamic sharing and scheduling method is applied to the intelligent cockpit system.

[0049] Specifically, the intelligent cockpit dual-system CPU core dynamic sharing and scheduling method of any of the technical solutions of the application is applied to the intelligent cockpit system of the application, and therefore the intelligent cockpit system of the application has all the beneficial effects of the intelligent cockpit dual-system CPU core dynamic sharing and scheduling method of any of the technical solutions of the application, which will not be repeated here.

[0050] Although the application is disclosed as above, the application is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the application, and therefore the protection scope of the application should be subject to the scope defined by the claims.

Claims

1. A method for dynamic shared scheduling of CPU cores in a dual-system intelligent cockpit, characterized in that, include: Select at least one CPU core in the cockpit chip as a shared core pool; Real-time monitoring of CPU utilization in Linux and Android systems, as well as the types of foreground applications on the driver and passenger screens; Based on monitoring results and preset scheduling conditions, the ownership system of the shared core pool is dynamically adjusted; Each time the shared core pool's ownership system changes, the current ownership status of the shared core pool is locked for a first set duration.

2. The intelligent cockpit dual-system CPU core dynamic sharing scheduling method according to claim 1, characterized in that, When the cockpit chip starts up, the shared kernel pool is used entirely or partially by the Linux system.

3. The intelligent cockpit dual-system CPU core dynamic sharing scheduling method according to claim 1, characterized in that, The preset scheduling conditions include: If the CPU utilization of the Linux system is less than or equal to the first standard value and continues for a second set period of time, and if both the driver and passenger screens are running Android foreground applications or the CPU utilization of the Android system on the driver screen is greater than or equal to the second standard value, then the shared kernel pool will be switched from the Linux system to the Android system.

4. The intelligent cockpit dual-system CPU core dynamic sharing and scheduling method according to claim 3, characterized in that, The preset scheduling conditions also include: When the CPU utilization of the Linux system is greater than or equal to the third standard value and continues for the third set duration, and both the driver and passenger screens are running Linux foreground applications, the shared kernel pool will be switched from the Android system to the Linux system.

5. The intelligent cockpit dual-system CPU core dynamic sharing scheduling method according to claim 1, characterized in that, If a security-related interruption occurs in the Linux system or the real-time task wait time exceeds a threshold during the lockout period, the lockout will be immediately lifted and the shared kernel pool will be switched to the Linux system for use.

6. The intelligent cockpit dual-system CPU core dynamic sharing scheduling method according to claim 1, characterized in that, When selecting CPU cores as the shared core pool, large cores are selected to form the shared core pool.

7. The intelligent cockpit dual-system CPU core dynamic sharing scheduling method according to claim 1, characterized in that, The identification of the foreground application type of the driver and passenger screens includes: determining the current foreground application type of the driver and passenger screens by monitoring the frame buffer write behavior of each screen and / or querying the foreground application records of the window manager.

8. A dynamic shared scheduling device for dual-system CPU cores in an intelligent cockpit, characterized in that, The intelligent cockpit dual-system CPU core dynamic shared scheduling method as described in any one of claims 1-7 is implemented through a shared scheduling device, which includes: The monitoring unit is used to collect real-time data on the CPU utilization of the Linux and Android systems and the status of foreground applications on the driver and passenger screens. The decision-making unit is used to generate shared core scheduling instructions based on the data provided by the monitoring unit and preset scheduling conditions; The execution unit is used to execute the shared core scheduling instructions and switch the system to which the shared core pool belongs.

9. The intelligent cockpit dual-system CPU core dynamic sharing scheduling device according to claim 8, characterized in that, The execution unit controls the online status of the shared kernel pool on the Linux system side through the kernel hot-swappable driver, and binds high-priority tasks to the shared kernel pool on the Android system side through the task affinity setting interface.

10. An intelligent cockpit system, characterized in that, The intelligent cockpit dual-system CPU core dynamic sharing scheduling method as described in any one of claims 1-7 is applied to an intelligent cockpit system.

Images