Resource scheduling method and apparatus, chip system, electronic device, and vehicle

Abstract

A resource scheduling method, apparatus, chip system, electronic device, and vehicle are provided in the technical field of intelligent driving.SOLUTION: The resource scheduling method includes determining a first user scenario of a first operating system, and determining, based on the first user scenario, a resource scheduling policy for scheduling a first resource between the first operating system and a second operating system, where the first resource includes a resource shared by the first operating system and the second operating system.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to the technical field of intelligent driving, and in particular to a resource scheduling method and apparatus, as well as a chip system, an electronic device and a vehicle. [Background technology]

[0002] An intelligent connected vehicle may have multiple operating systems, such as an intelligent driving system and a cockpit system. The intelligent driving system is primarily responsible for the vehicle's autonomous driving and safety, including environmental sensing, route planning, decision-making and control. The cockpit system is primarily responsible for the vehicle's internal driving experience and human-computer interaction, including infotainment, meter display, media player, and environmental control.

[0003] Currently, resource scheduling for each operating system is isolated, which leads to problems such as irrational resource allocation and low resource utilization. For example, when an intelligent driving system requires more resources to perform complex route planning, the cockpit system may have free resources, but these free resources cannot be used by the intelligent driving system, resulting in low system resource utilization. Summary of the Invention [Problem to be solved by the invention]

[0004] To improve resource utilization among multiple operating systems, embodiments of the present disclosure provide resource scheduling methods, devices, chip systems, electronic devices, and vehicles. [Means for solving the problem]

[0005] A first aspect of the present application provides a resource scheduling method that can be used in an integrated circuit running at least a first operating system and a second operating system, the method including the steps of: determining a first user scene of the first operating system; and determining a resource scheduling policy for scheduling a first resource between the first operating system and the second operating system based on the first user scene, wherein the first resource includes a resource shared by the first operating system and the second operating system.

[0006] Illustratively, the first operating system is a cockpit system and the second operating system is an intelligent driving system, or the first operating system is an intelligent driving system and the second operating system is a cockpit system.

[0007] A second aspect of the present application provides a resource scheduling device that can be used in an integrated circuit running at least a first operating system and a second operating system, the device including: a scene recognition unit configured to determine a first user scene of the first operating system; and a scheduling management unit configured to determine a resource scheduling policy for scheduling a first resource between the first operating system and the second operating system based on the first user scene, wherein the first resource includes a resource shared by the first operating system and the second operating system.

[0008] A third aspect of the present disclosure provides a chip system including a processor and a memory, wherein the memory stores computer program instructions that, when executed by the processor, cause the chip system to perform steps of a resource scheduling method according to the first aspect of the present disclosure and each implementation thereof.

[0009] A fourth aspect of the present disclosure provides an electronic device that can include the chip system provided in the third aspect of the present disclosure.

[0010] A fifth aspect of the present disclosure provides a vehicle that can include the chip system provided in the third aspect of the present disclosure or the electronic device provided in the fourth aspect of the present disclosure. [Effects of the Invention]

[0011] The technical solution according to the embodiments of the present disclosure can perform resource scheduling between different operating systems based on the user scenarios of each operating system, i.e., realizes resource scheduling between systems based on user scenarios, meets the resource requirements of each operating system in different user scenarios, and not only improves the running stability of the operating systems, but also makes resource allocation more rational and improves resource utilization. [Brief explanation of the drawings]

[0012] The above and other objects, features, and advantages of the present disclosure will become more apparent from the detailed description of the embodiments of the present disclosure with reference to the drawings. The drawings are used to further understand the embodiments of the present disclosure, are constituted as part of the specification, and are used to explain the present disclosure together with the embodiments of the present disclosure, but are not intended to limit the present disclosure. In the drawings, the same reference numerals generally represent the same components or steps. [Figure 1] FIG. 1 is a software and hardware architecture diagram of a cockpit-driving integrated system according to one exemplary embodiment of the present disclosure. [Figure 2] 2 is a flowchart of a resource scheduling method according to one exemplary embodiment of the present disclosure. [Figure 3] 2 is a flowchart of step S200 of a resource scheduling method according to an exemplary embodiment of the present disclosure. [Figure 4] 4 is another flowchart of a resource scheduling method according to one exemplary embodiment of the present disclosure. [Figure 5] 10 is a flowchart of step S250 of a resource scheduling method according to an exemplary embodiment of the present disclosure. [Figure 6] 10 is a flowchart of a first scheduling policy decision-making process according to one exemplary embodiment of the present disclosure. [Figure 7] FIG. 2 is a schematic diagram of implementing a first scheduling policy according to one exemplary embodiment of the present disclosure. [Figure 8] FIG. 10 is another schematic diagram of implementing a first scheduling policy according to one exemplary embodiment of the present disclosure. [Figure 9] FIG. 10 is a schematic diagram of implementing a second scheduling policy according to one exemplary embodiment of the present disclosure. [Figure 10] FIG. 2 is a structural block diagram of a resource scheduling apparatus according to one exemplary embodiment of the present disclosure; DETAILED DESCRIPTION OF THE INVENTION

[0013] Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the drawings. Obviously, it should be understood that the described embodiments are only a part of the embodiments of the present disclosure, but not all of the embodiments of the present disclosure, and the present disclosure is not limited to the exemplary embodiments described herein.

[0014] Unless otherwise specifically stated, the relative arrangement of components and steps, formulas and numerical values ​​described in these examples do not limit the scope of the present disclosure.

[0015] Summary of the application Intelligent connected vehicles are automobiles that are integrated with advanced sensors, controllers, actuators, and communication systems, enabling features such as autonomous driving, Internet of Vehicles, and in-car entertainment. They collect and analyze large amounts of data to deliver a safe, efficient, comfortable, and entertaining driving experience.

[0016] An intelligent connected vehicle includes a wide range of driving and entertainment functions, and to realize these functions, multiple operating systems, such as an intelligent driving system and a cockpit system, are running in the intelligent connected vehicle.

[0017] Among these, an intelligent driving system can realize functions related to the autonomous driving and safety of a vehicle (e.g., a vehicle). The functions of an intelligent driving system include, but are not limited to, environmental sensing, route planning, and / or decision control, thereby realizing functions related to autonomous driving of a vehicle, such as autonomous driving in urban areas / highways, navigate on autopilot (NOA) in urban areas / highways, valet parking, automatic parking, adaptive cruise control (ACC), lane centering control (LCC), etc., as well as functions related to autonomous emergency braking (AEB).

[0018] A cockpit system may provide the interior driving and riding experience of a vehicle and related functions for human-computer interaction, including, but not limited to, infotainment, instrumentation, and / or human-computer interaction.

[0019] In some implementations, the intelligent driving system and the cockpit system can each run on a different chip system. For example, an intelligent connected vehicle may include two chip systems, one running the intelligent driving system and the other running the cockpit system. Each operating system operates independently and can independently schedule resources provided by the chip system in which it is located. That is, the system scheduling of the intelligent driving system and the cockpit system is isolated from each other, and the operating systems cannot share resources with each other, that is, resource scheduling between the systems cannot be realized, resulting in irrational resource allocation and low utilization. For example, if the intelligent driving system requires more resources to perform complex route planning, the cockpit system may have free resources, but these free resources cannot be used by the intelligent driving system, resulting in low resource utilization.

[0020] Exemplary System An embodiment of the present disclosure provides a cockpit-driving integrated system.

[0021] FIG. 1 is a software and hardware architecture diagram of a cockpit-driving integrated system according to one exemplary embodiment of the present disclosure.

[0022] In an embodiment of the present disclosure, the cockpit-driving integrated system can be applied to a vehicle, where the vehicle may include a land vehicle, an air vehicle, a water vehicle, an underwater vehicle, a space vehicle, etc.

[0023] Among these, land vehicles may include, for example, automobiles (e.g., intelligent connected vehicles, trolleybuses, buses, etc.), railway vehicles (e.g., trains, subways, trams, etc.), various mobile robots (e.g., service robots, transport robots, automated guided vehicles (AGVs), unmanned ground vehicles (UGVs), bionic robots (e.g., robot dogs), etc.), various construction machinery, and other mobile land devices. Air vehicles may include, for example, airplanes, low-altitude aircraft, high-altitude aircraft, flying cars, unmanned aerial vehicles, etc. Water vehicles may include ships, motorboats, etc. Underwater vehicles may include submarines, submersibles, underwater detectors, etc. Space vehicles may include spaceships, spacecraft, artificial satellites, etc.

[0024] In some examples, the vehicle may be a driver-operated vehicle, i.e., a manned vehicle, or a non-driver-operated vehicle, i.e., an unmanned vehicle.

[0025] In an embodiment of the present disclosure, the cockpit-driving integrated system is an integrated system that integrates a cockpit system and an intelligent driving system. Compared with independent cockpit systems and intelligent driving systems, the cockpit-driving integrated system has a higher degree of integration and intelligence, which is advantageous for improving the driving safety, comfort, and driving and riding experience of mobile vehicles. In one embodiment, the cockpit-driving integrated system may include a hardware layer, a resource management layer, and a system layer.

[0026] The hardware layer includes the hardware portion of the cockpit-driving integrated system, for example, an integrated circuit, which may be a chip system, such as a system-on-chip (SoC) 110. For example, the SoC 110 may include one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more neural processing units (NPUs), digital signal processors (DSPs), and image signal processors (ISPs). These processors can be used to provide resources to the system layer, for example, by providing computing resources to the cockpit system and the intelligent driving system to support the implementation of the functions of the cockpit system and the intelligent driving system.

[0027] In an embodiment of the present invention, a resource is a general term for various hardware components used to perform tasks, execute programs, and provide computing power in an integrated circuit (e.g., SoC). Exemplarily, the resource may include processor resources (e.g., CPU resources, GPU resources), memory resources, storage resources, network resources, input / output (I / O) resources, etc.

[0028] In one implementation, each processor (e.g., CPU, GPU, NPU, etc.) may be an independent device. That is, different processors may be located on different chips. Alternatively, at least one processor may be integrated on one chip and at least one other processor may be integrated on another chip; embodiments of the present disclosure are not limited in this regard.

[0029] In addition to the SoC 110, the hardware layer may include other hardware such as a memory 120 and a communication interface 130.

[0030] The memory 120 may be used for system files, application files, and data files (e.g., cache data, high-precision map data) of the intelligent driving system and cockpit system. For example, the memory 120 may include volatile memory such as dynamic random access memory (DRAM) and static random access memory (SRAM), or non-volatile memory (NVM) such as read-only memory (ROM) and flash memory. In some examples, the memory 120 may be a discrete device or may be integrated with at least some devices of a chip system (e.g., at least some processors), for example, integrated into a single SoC. Some of the memory 120 (e.g., cache) may be integrated within the processor and become part of the processor.

[0031] In an embodiment of the present disclosure, the memory 120 further stores computer program instructions, which, when executed by the processor, cause the chip system to perform steps of a resource scheduling method according to an embodiment of the present disclosure.

[0032] The communication interface 130 is used for communication between each piece of hardware in the hardware layer and between the hardware layer and other devices such as sensors, display screens, microphones, and speakers of the vehicle. Illustratively, communication interface 130 may include, for example, a controller area network (CAN) interface, an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a digital video port (DVP), a peripheral component interconnect express (PCI-E) interface, a serial peripheral interface (SPI), a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a local interconnect network (LIN) interface, a FlexRay interface, a media oriented systems transport (MOST) interface, an Ethernet interface, and the like. In one implementation, the communication interface 130 can be integrated into and become part of the SoC to increase the integration of the system.

[0033] The system layer may include multiple operating systems, such as operating system 1, operating system 2, ... operating system N. Different operating systems can be used to realize different functions of the cockpit-driving integrated system. Multiple operating systems can run within an integrated circuit, or in other words, multiple operating systems run within a chip system.

[0034] Here, the multiple operating systems may be operating systems built based on the same system kernel, which is advantageous for data exchange and sharing between the multiple operating systems. Naturally, to facilitate selecting a more appropriate operating system depending on the actual functions to be realized, the multiple operating systems may be operating systems built based on different system kernels, where the system kernel may be, for example, a microkernel, a monolithic kernel, a hybrid kernel, an exokernel, etc. For example, assume that the system layer includes operating system 1 and operating system 2. Operating system 1 and operating system 2 may be the same or different operating systems selected from the group consisting of a real-time operating system (RTOS), a Unix real-time operating system (Quick Unix, QUX), a Linux operating system, and an Android operating system. For example, operating system 1 is the Linux operating system, and operating system 2 is the Android operating system.

[0035] In one implementation, operating system 1 may be a cockpit system for realizing functions related to the driving and riding experience inside a vehicle and human-computer interaction. Operating system 2 may be an intelligent driving system for realizing functions related to the autonomous driving and safety of a vehicle. Alternatively, operating system 1 may be the intelligent driving system and operating system 2 may be the cockpit system. That is, when a system layer includes multiple operating systems, the embodiments of the present disclosure are not limited to the implementation of each operating system.

[0036] In one implementation, at least two operating systems may include an interconnection interface, such as an inter-process communication (IPC) interface. In this manner, different operating systems may communicate with each other via the IPC interface to send and receive messages or share information. Illustratively, different operating systems may share load information, temperature information, computational power requirements, and the like via the IPC interface, although the embodiments of the present disclosure are not specifically limited in this regard.

[0037] In one implementation, at least one operating system may include multiple subsystems. Taking a cockpit system as an example, the cockpit system may include multiple subsystems, and the number and functions of the subsystems in the cockpit system may be determined based on the configuration of the cockpit. For example, taking a cockpit including an instrument panel, a central control screen, and a passenger screen as an example, the cockpit system may include, for example, an instrument panel subsystem, a central control screen subsystem, and a passenger screen subsystem. The instrument panel subsystem may be used to display important vehicle information, such as speed, rotational speed, fuel consumption, power consumption, temperature, warning information, navigation instructions, driver assistance system status, and vehicle malfunction warnings, on the vehicle's instrument panel. The central control screen subsystem can be used to provide vehicle infotainment functions such as audio playback, video playback, navigation systems, Bluetooth connectivity, and smartphone mirroring; vehicle setup functions such as adjusting air conditioning, seats, lamps, driving modes, and power output configurations; vehicle driver assistance functions such as displaying reverse video, displaying 360-degree panoramic video, and displaying related information obtained from other operating systems (e.g., intelligent driving systems); and vehicle human-computer interaction functions such as voice control and gesture control. The passenger screen subsystem can be used to provide entertainment and information services to the passenger, such as playing music and videos, providing game content, and displaying navigation information.

[0038] In some examples, the cockpit system can allocate the obtained resources to each subsystem for use and schedule the resources of each subsystem based on the task execution status of each subsystem, the load and / or resource requirements of each subsystem, etc. For example, if the cockpit system detects that the driver is viewing navigation information using the instrument panel, it can allocate more resources to the instrument panel subsystem. Also, for example, if the cockpit system detects that the passenger in the front seat is watching video using the passenger screen, it can allocate more resources to the passenger seat subsystem.

[0039] The resource management layer is an intermediate layer located between the hardware layer and the system layer, and may be realized by software, hardware, or a combination of software and hardware. The resource management layer is used to allocate resources from the hardware layer to the system layer for use; for example, some resources are allocated to operating system 1 for use, and other resources are allocated to operating system 2 for use.

[0040] In one implementation, at least some of the resources in the hardware layer may be allocated to operating system 1 for use, or may be allocated to operating system 2 for use, i.e., at least some of the resources in the hardware layer may be resources shared by operating system 1 and operating system 2, and this shared resource may be scheduled between operating system 1 and operating system 2. For convenience of explanation, the resource shared by operating system 1 and operating system 2 may hereinafter be referred to as the first resource.

[0041] In one example, the first resource may include all resources in the hardware layer, such as all CPU resources, all GPU resources, all NPU resources, all I / O resources, etc. That is, all resources in the hardware layer are resources shared by operating system 1 and operating system 2. Taking CPU resources in an SoC as an example, assuming that the CPU includes eight cores, the eight cores may be allocated to operating system 1 or operating system 2.

[0042] In another example, the first resource may include some resources of the hardware layer, such as some CPU resources, some GPU resources, some NPU resources, some I / O resources, etc. That is, some resources of the hardware layer are non-shared resources and may be assigned only to operating system 1 or only to operating system 2, while other resources are shared resources and may be assigned to either operating system 1 or operating system 2.

[0043] Taking CPU resources in an SoC as an example, assume that the CPU includes eight cores, for example, core 1 to core 8. Among them, core 1 and core 2 are non-shared resources, core 1 can be assigned to operating system 1, core 2 can be assigned to operating system 2, and cores 3 to 8 are shared resources, i.e., first resources, which may be assigned to either operating system 1 or operating system 2. Here, the first resources may be set fixedly or may be dynamically adjusted; for example, cores 1 to 4 may be adjusted to non-shared resources, and cores 5 to 8 may be adjusted to shared resources.

[0044] Alternatively, 20% of the CPU resources are non-shared resources, of which 10% are allocated only to operating system 1 and another 10% are allocated only to operating system 2. The remaining 80% of the CPU resources are shared resources, i.e., first resources, and may be allocated to operating system 1 or operating system 2. Here, the 80% of the CPU resources may be CPU resources after virtualization, i.e., these 80% of the CPU resources do not correspond to a certain core or any cores of the CPU. Of course, the 80% of the CPU resources may also be resources provided by a specified core of the CPU, for example, resources provided by cores 3 to 8.

[0045] In one implementation, the resource management layer can virtualize resources in the hardware layer and schedule the virtualized resources for use by the system layer. In other words, the resource management layer can establish and manage multiple virtual machine instances based on the resources in the hardware layer, allocate the resources of the hardware layer to each virtual machine instance, and multiple operating systems run on different virtual machine instances.

[0046] For example, the resource management layer may include a virtual machine manager, hypervisor 210, which manages hardware layer resources such as processor, memory, and network resources and allocates these resources to multiple virtual machine instances. Operating systems running on each virtual machine instance can share these resources and operate in isolated virtual environments, ensuring that the operating systems do not interfere with each other and improving the safety and reliability of the integrated cockpit-driving system. Hypervisor 210 can also coordinate requests from each operating system, map these requests to physical hardware in the hardware layer, and return processing results to the corresponding operating systems. Hypervisor 210 can also schedule resources among the virtual machine instances to ensure efficient resource utilization.

[0047] The structures shown in the embodiments of the present disclosure are not intended to specifically limit the integrated cockpit-driving system. In other embodiments of the present invention, the integrated cockpit-driving system may include more or fewer components than those shown in Figure 1, combine some components, separate some components, or have a different component configuration. The components of Figure 1 may be implemented in hardware, software, or a combination of software and hardware.

[0048] Exemplary Methods An embodiment of the present disclosure provides a resource scheduling method, which may be implemented in the cockpit-driving integrated system shown in FIG. 1 or in other software and hardware systems. For example, the method may be implemented in an integrated circuit, which executes at least a first operating system and a second operating system.

[0049] In the following embodiments, a first operating system and a second operating system are referred to. Here, the first operating system and the second operating system may be any two systems in a cockpit-driving integrated system. For example, the first operating system may be a cockpit system and the second operating system may be an intelligent driving system, or the first operating system may be an intelligent driving system and the second operating system may be a cockpit system.

[0050] Accordingly, the first operating system, the second operating system, and / or the resource management layer may call the processor to execute the steps of the methods according to the embodiments of the present disclosure. For example, some method steps may be executed by the first operating system calling the processor, some method steps may be executed by the second operating system calling the processor, and some method steps may be executed by the resource management layer calling the processor. Specific implementations may be flexibly designed, and the embodiments of the present disclosure are not limited thereto.

[0051] Here, the first operating system, the second operating system and / or the resource management layer calling the processor to perform the steps of each method according to the embodiments of the present disclosure may be described as the first operating system, the second operating system and / or the resource management layer performing the steps of each method according to the embodiments of the present disclosure.

[0052] FIG. 2 is a flowchart of a resource scheduling method according to one exemplary embodiment of the present disclosure.

[0053] As shown in FIG. 2, in some embodiments, the resource scheduling method may include steps S100 and S200.

[0054] In step S100, a first user scene of a first operating system is determined.

[0055] Here, the first user scene may be a current user scene of the first operating system.

[0056] In the embodiment of the present disclosure, the method for setting a user scene may be various.

[0057] In a first implementation, a user scene can be set based on a vehicle state, where the vehicle state may include, for example, a driving state, a parking state, etc. Illustratively, the user scene includes, but is not limited to, at least one of the following: Running scene: The vehicle is running. Parking scene: The vehicle is in a parking state, Intelligent driving scene: The vehicle is moving and the intelligent driving function is on. Manual driving scenario: The vehicle is moving and the intelligent driving function is off.

[0058] In a second implementation, the user scenes can be divided based on the system state of the operating system, where the system state may include, for example, a standby state, a screen-on state, a screen-off state, an active state, a charging state, etc. Illustratively, the user scenes include, but are not limited to, at least one of the following: Standby scene: The operating system is in standby state, Screen lighting scene: The operating system is in standby + screen lighting state, Screen off scene: The operating system is in standby + screen off state, Active Scene: The operating system is playing music, playing video, or running a gaming application.

[0059] In a third implementation, the user scenes can be divided based on the input state of the operating system, where the input state may include, for example, a touch input state, a voice input state, a visual input state, etc. Illustratively, the user scenes include, but are not limited to, at least one of the following: Touch scene: A user is performing a touch operation on the operating system's user interface. Voice Scene: The operating system is performing voice recognition; Visual Scene: The operating system performs visual recognition.

[0060] In a fourth implementation, the user scenes can be divided based on the operating system usage status. Illustratively, the operating system user scenes include, but are not limited to, at least one of the following: Game scene: The operating system is running game applications; Video Scene: The operating system is running a video application; Music scene: The operating system is running a music application, Navigation scene: The operating system is running a map application; Download scene: An operating system application is downloading content.

[0061] In some other implementations, the above-mentioned methods for dividing user scenes can be used in combination, thereby forming a richer user scene. For example, when the dividing methods in the first and fourth implementations are used in combination, the user scene can further include intelligent driving + video scenes, parking + game scenes, etc.

[0062] In some other implementations, the user scene can be further divided to obtain more user scenes. Illustratively, the intelligent driving scene can be further divided into a highway intelligent driving scene, an urban intelligent driving scene, an automatic parking scene, etc.

[0063] In some other implementations, multiple user scenes can be integrated to simplify the number of user scenes. For example, touch scenes, audio scenes, and visual scenes can be integrated into an interaction scene, intelligent driving scenes and manual driving scenes can be integrated into a driving scene, and game scenes, video scenes, music scenes, navigation scenes, and download scenes can be integrated into an active scene.

[0064] The embodiments of the present disclosure do not specifically limit the method of dividing the user scene.

[0065] Although the above describes an exemplary method for setting user scenes, different operating systems may include different user scenes due to different functions. Furthermore, an operating system may include more or fewer user scenes, or may use other methods to divide user scenes. Naturally, users can customize user scenes, and the operating system can update user scenes via methods such as over-the-air download (OTA), thereby constantly enriching the user scenes. None of these go beyond the scope of protection of the embodiments of the present disclosure.

[0066] In one embodiment, step S100 can be performed by the first operating system invoking the processor.

[0067] The first operating system determining the first user scene can be realized in various forms.

[0068] In one implementation, application information running on the first operating system can be obtained, and a first user scene can be determined based on the obtained application information.

[0069] Here, the application information may include the name, package name, and / or process name of the application running in the first operating system. In this way, the first operating system can determine which application is running and further determine the first user scenario based on the acquired application information. For example, the application name of WeChat® may be "WeChat", the package name may be "com.tencent.xin", and the process name may be "WeChat.exe".

[0070] For example, by obtaining application information of an intelligent driving application, it can be determined that the intelligent driving application is running, and then it can be determined that the first usage scenario is an intelligent driving scenario.

[0071] Generally, running applications may include applications running in the foreground and applications running in the background. Here, an application running in the foreground may be referred to as a foreground application, where "running in the foreground" means that the application is running and content is displayed on the display screen. In one example, the foreground application may specifically include a foreground-focused application and a foreground-focused application, where the foreground-focused application includes an application that displays content on the display screen and is operated by a user, and the foreground-focused application includes an application that is displayed on the display screen but is not operated by a user. Accordingly, an application running in the background may be referred to as a background application, where "running in the background" means that the application is running but does not display content on the display screen.

[0072] When an application is running in the foreground, it generally means that this application is currently being used by the user. For example, when a user watches a video (e.g., video scene), the video application runs in the foreground and can play video content, etc. When an application is running in the background, it generally means that this application is not currently being used by the user. For example, when a user does not watch a video, the video application can be switched to the background; when a user does not use navigation, the map application can be switched to the background.

[0073] As can be seen from the above, the foreground application is more helpful in accurately determining the first user scene of the first operating system. Thus, in one implementation, foreground application information in the first operating system can be obtained, and the first user scene can be determined based on the obtained foreground application information.

[0074] The first operating system may also operate multiple applications in the foreground. For example, the first operating system may simultaneously display interfaces of multiple applications on the display screen using a split screen, a card window, or a floating window, e.g., simultaneously displaying an interface of a map application and an interface of a music application. In this case, the foreground application information acquired by the first operating system may include application information of the multiple applications. For example, the application information may include application information of a map application and application information of a music application. In this case, the first user scene determined by the first operating system may include multiple scenes, e.g., the first user scene may include a navigation scene and a music scene.

[0075] In one implementation, the first user scene can be determined based on the state of the vehicle. Illustratively, when the vehicle is in a driving state, for example, when the vehicle is operating in a D shift, the first user scene can be determined to be a driving scene. When the vehicle is in a parking state, for example, when the vehicle is operating in a P shift, the first user scene can be determined to be a parking scene.

[0076] In one implementation, the first user scene can be determined based on the system state of the first operating system. For example, if the first operating system is in a standby state, the first user scene can be determined to be a standby scene. If the first operating system is in a screen-on state, the first user scene can be determined to be a screen-on scene.

[0077] In one implementation, the first user scene can be determined based on an input state of the first operating system. For example, when the first operating system is in a touch input state, for example, responding to a user's touch operation, the first user scene can be determined to be a touch scene. When the first operating system is in a voice input state, for example, receiving or recognizing a user's voice, the first user scene can be determined to be a voice scene.

[0078] In one implementation, the above-described methods for determining the first user scene can be used in combination, and thus the first user scene can be further subdivided to perform resource scheduling at a finer granularity. Exemplarily, the first user scene can be determined based on the vehicle status and usage status. For example, if the vehicle is in a moving state and an intelligent driving application is running, the first user scene can be determined to be an intelligent driving scene. Also, for example, if the vehicle is in a moving state and an intelligent driving application is not running, the first user scene can be determined to be a manual driving scene.

[0079] The above provides an illustrative explanation of how the first user scene is determined. The above examples are only a part of the examples of determining the first user scene, not all of them. When actually using the system, other forms of determining the first user scene can be set based on the usage scenes of the embodiments of the present disclosure, the method of dividing user scenes, the functions of the operating system, etc., and none of these go beyond the scope of protection of the embodiments of the present disclosure.

[0080] In step S200, a resource scheduling policy for scheduling a first resource between a first operating system and a second operating system is determined based on a first user scenario.

[0081] In one embodiment, step S200 can be performed by the first operating system invoking the processor.

[0082] Here, the first resource includes a resource shared by the first operating system and the second operating system.

[0083] Generally, during the initial operation of the chip system, for example, when the chip system is powered on, the resource management layer may initially allocate a first resource to the first operating system and / or the second operating system. During the past operation of the chip system, scheduling may have been performed on the first resource, and the allocation status of the first resource may have been changed. Therefore, before performing step S200, the first resource may have multiple allocation statuses, which will be described below by way of example.

[0084] In the first allocation state, the first resources are entirely allocated to the first operating system and / or the second operating system. For example, 50% of the first resources are allocated to the first operating system and another 50% of the first resources are allocated to the second operating system. Or, 40% of the first resources are allocated to the first operating system and another 60% of the first resources are allocated to the second operating system. Or, all of the first resources are allocated to the first operating system and the second operating system does not obtain any of the first resources. Or, all of the first resources are allocated to the second operating system and the first operating system does not obtain any of the first resources.

[0085] In the second allocation state, only a portion of the first resources is allocated to the first operating system and / or the second operating system, for example, 40% of the first resources are allocated to the first operating system, another 50% of the first resources are allocated to the second operating system, and the remaining 10% of the first resources are in an unallocated state.

[0086] According to different allocation states of the first resource, there may be multiple resource scheduling policies. Taking scheduling the first resource between the cockpit system and the intelligent driving system as an example, the resource scheduling policies may include: Policy 1: Allocate at least a portion of the first resource already allocated to the cockpit system to the intelligent driving system. Policy 2: Allocate at least a portion of the first resource already allocated to the intelligent driving system to the cockpit system. Policy 3: Schedule at least some of the unallocated first resources to the cockpit system. Policy 4: Schedule at least some of the unallocated first resources to the intelligent driving system.

[0087] Because the resource requirements of the cockpit system and the intelligent driving system are different in different user scenes, a resource scheduling policy can be determined based on a first user scene, and the resource scheduling policy can be used to schedule a first resource between the cockpit system and the intelligent driving system, thereby meeting the resource requirements of the cockpit system and the intelligent driving system in different user scenes.

[0088] Hereinafter, an example of determining a resource scheduling policy based on a first user scene will be described.

[0089] If the first user scene is a driving scene, an intelligent driving scene, or a manual driving scene, it is necessary to ensure that the intelligent driving system obtains more resources as a priority in order to ensure that functions related to intelligent driving or vehicle safety, such as autonomous driving, constant speed driving / following distance control, lane centering (lane keeping) assistance, and automatic emergency braking, can be stably provided. In this case, the cockpit system can schedule the first resource to the intelligent driving system. For this purpose, policy 1 and / or policy 4 can be selected.

[0090] When the first user scene is a parking scene, the intelligent driving system turns off functions related to intelligent driving and enters a standby state or another state other than intelligent driving, and the resource demand is low. In this case, the intelligent driving system can schedule the first resource to the cockpit system. Therefore, policy 2 and / or policy 3 can be selected.

[0091] The resource scheduling method of the embodiment of the present invention provides a mechanism for scheduling resources between systems, and can realize inter-system resource scheduling between a first operating system and a second operating system based on a first user scenario, not only ensuring that the resources obtained by each operating system meet the requirements of the first user scenario, but also making resource allocation more reasonable, improving resource utilization, and improving the efficiency and stability of the operating systems' operations.

[0092] FIG. 3 is a flowchart of step S200 of a resource scheduling method according to one exemplary embodiment of the present disclosure.

[0093] As shown in FIG. 3, in one embodiment, step S200 can be realized by the following steps S210 and S220.

[0094] In step S210, a first resource state of the first operating system is determined.

[0095] Here, step S210 may be performed by the first operating system calling the processor, and after determining the first resource state, the first operating system may transmit the first resource state to the second operating system via the IPC interface.

[0096] In one implementation, the first resource status includes a load status of the first operating system, such as a current load. Specifically, a performance management tool or a load monitoring tool can be executed in the first operating system, and the load status of the first operating system can be monitored and acquired through the performance management tool or the load monitoring tool. For example, the load status of the first operating system may include a usage rate of already acquired resources by the first operating system, such as a CPU usage rate, a GPU usage rate, an NPU usage rate, etc.

[0097] In one implementation, the first resource state may include a load change status of the first operating system within a certain period of time in the future. Here, the certain period of time in the future may be, for example, a few seconds or minutes in the future, and the embodiments of the present disclosure are not limited thereto. In a specific implementation, to predict and obtain the load change status of the first operating system within the certain period of time in the future, the load change status of the first operating system may be estimated based on the first user scenario.

[0098] For example, if the first operating system is a cockpit system and the first user scene is a video scene, when a video application plays a video at a certain resolution, frame rate, bit rate, etc., the resources consumed by the video application can be predicted, and based on this, the load change situation of the cockpit system within a certain period of time in the future (e.g., within the time remaining until the video playback ends) can be predicted. Here, the resources consumed when playing videos with different resolutions, frame rates, and bit rates can be obtained by stating historical data on the local or cloud side, and are not specifically limited here.

[0099] For example, when the first operating system is an intelligent driving system and the first user scenario is an intelligent driving scenario, if the intelligent driving application performs an intelligent driving task on a highway, the resources consumed by the intelligent driving application can be predicted, and based on this, the load change situation of the intelligent driving system within a certain period of time in the future (for example, within the time remaining until the current intelligent driving task ends) can be predicted. Here, the predicted resource consumption of the intelligent driving task on a highway can be obtained by calculating historical data locally or on the cloud side, and is not specifically limited herein.

[0100] For example, when the first operating system is an intelligent driving system and the first user scenario is an intelligent driving scenario, when the intelligent driving application performs an intelligent driving task in an urban area, the resources consumed by the intelligent driving application may fluctuate. For example, the intelligent driving application consumes fewer resources in sections / time periods with fewer vehicles and simpler road conditions (e.g., elevated roads in urban areas / time periods outside of peak morning and evening hours), and consumes more resources in sections / time periods with more vehicles and more complex road conditions (e.g., intersections / peak morning and evening hours). Based on this, the time periods during which the vehicle will pass through each section can be estimated based on the intelligent driving route, thereby predicting the resource consumption of the intelligent driving application in each time period, and further predicting the load change situation of the intelligent driving system within a certain period in the future (e.g., within the time remaining until the current intelligent driving task ends). Here, the predicted resource consumption of the intelligent driving task in an urban area can be obtained by statistically analyzing historical data locally or on the cloud, and is not specifically limited herein.

[0101] In this way, based on the first resource state, the first operating system can determine the proportion of its resources that are free and the proportion of resources that are used, thereby providing a basis for determining a resource scheduling policy.

[0102] In step S220, a resource scheduling policy is determined based on the first user scene and the first resource state.

[0103] Here, step S220 can be performed by the first operating system calling the processor.

[0104] Illustratively, the resource scheduling policy may include scheduling a first resource from a first operating system to a second operating system, or scheduling a first resource from a second operating system to a first operating system.

[0105] Take for example that the first operating system is a cockpit system and the second operating system is an intelligent driving system.

[0106] When the first user scenario is a driving scenario, it is necessary to prioritize resource supply for the second operating system. In this case, it is possible to determine whether resource scheduling needs to be performed based on the first resource status, and if resource scheduling needs to be performed, the resource scheduling policy may include scheduling the first resource from the first operating system to the second operating system.

[0107] If the first user scene is a parking scene, the second operating system turns off functions related to intelligent driving. In this case, the second operating system can determine whether resource scheduling can be performed based on the first resource state. If resource scheduling can be performed, the resource scheduling policy can include scheduling the first resource from the second operating system to the first operating system.

[0108] A method according to an embodiment of the present disclosure determines a resource scheduling policy based on the user scenario and resource status of the first operating system, and can match the resources obtained by the first operating system with the resource requirements in each user scenario, thereby ensuring that each application in the first operating system can run efficiently and stably, and improving the reliability of the system.

[0109] FIG. 4 is another flowchart of a resource scheduling method according to one exemplary embodiment of the present disclosure.

[0110] As shown in FIG. 4, in one embodiment, the resource scheduling method may include steps S100, S210, S230, S240 and S250.

[0111] In step S100, a first user scene of a first operating system is determined.

[0112] In step S210, a first resource state of the first operating system is determined.

[0113] In step S230, a second user scene of the second operating system is determined.

[0114] The second user scene may be the current user scene of the second operating system.

[0115] Here, step S230 may be performed by the second operating system calling the processor, and after determining the second user scene, the second operating system may send the second user scene to the first operating system through the IPC interface.

[0116] The second operating system's determination of the second user scene can be realized in various forms. For example, information about applications running in the second operating system can be acquired, and the second user scene can be determined based on the acquired application information. Information about a foreground application in the second operating system can be acquired, and the second user scene can be determined based on the acquired foreground application information. The second user scene can be determined based on the state of a vehicle. The second user scene can be determined based on the system state of the second operating system. The second user scene can be determined based on the input state of the second operating system.

[0117] Any content that has not been expanded on regarding the determination of the second user scene by the second operating system is realized by referring to the form in which the first operating system determines the first user scene, and redundant explanations will be omitted here.

[0118] Because the first operating system and the second operating system have different functions and run different applications, the first user scene and the second user scene may be the same or different at the same time or within the same time period.

[0119] Take for example that the first operating system is a cockpit system and the second operating system is an intelligent driving system.

[0120] When the vehicle is in a driving state and a video is being played in the first operating system, the first user scene determined by the first operating system may be a video scene, and the second user scene determined by the second operating system may be a driving scene.

[0121] When the vehicle is in a parked state and a game application is running in the first operating system, the first user scene determined by the first operating system may be a game scene, and the second user scene determined by the second operating system may be a parking scene.

[0122] In step S240, a second resource state of the second operating system is determined.

[0123] In one implementation, step S240 may be performed by the second operating system calling the processor, and after determining the second resource state, the second operating system may transmit the second resource state to the first operating system via the IPC interface.

[0124] In one implementation, the second resource status includes a load status of the second operating system, such as a current load. In a specific implementation, a performance management tool or a load monitoring tool is executed in the second operating system, and the load status of the second operating system can be monitored and acquired through the performance management tool or the load monitoring tool. Exemplarily, the load status of the second operating system may include, for example, a CPU usage rate, a GPU usage rate, an NPU usage rate, a memory usage rate, a magnetic device usage rate, a network usage rate, etc. of the second operating system.

[0125] In one implementation, the second resource state may include a load change status of the second operating system within a certain period of time in the future. Here, the certain period of time in the future may be, for example, a few seconds or minutes in the future, and the embodiment of the present disclosure is not limited thereto. In a specific implementation, to predict and obtain the load change status of the second operating system within the certain period of time in the future, the load change status of the second operating system may be estimated based on a second user scenario of the second operating system.

[0126] Any content that has not been expanded on regarding the determination of the second resource state by the second operating system can be realized by referring to the form in which the first operating system determines the first resource state, and duplicate explanations will be omitted here.

[0127] In step S250, a resource scheduling policy is determined based on the first user scene, the second user scene, the first resource state, and the second resource state.

[0128] Here, step S250 may be executed by the first operating system calling the processor, or the second operating system calling the processor, or step S250 may be executed in parallel by the first operating system and the second operating system calling the processor, that is, the two operating systems can each determine one resource scheduling policy.

[0129] FIG. 5 is a flowchart of step S250 of a resource scheduling method according to one exemplary embodiment of the present disclosure.

[0130] As shown in FIG. 5, in one embodiment, step S250 may include the following steps S251 and S252.

[0131] In step S251, the priority of the first operating system is determined based on the first user scene, and the priority of the second operating system is determined based on the second user scene.

[0132] In one implementation, a priority rule can be set for each user scene, and the priority rule may include the priority of the cockpit system and / or the intelligent driving system in each user scene, where the priority rule can be flexibly set by an engineer, and the embodiment of the present disclosure is not limited thereto.

[0133] Taking the priority as an example, which includes high priority and low priority, the priority rules may include, for example:

[0134] When the intelligent driving system and / or the cockpit system are in a driving scene, an intelligent driving scene, or a manual driving scene, the intelligent driving system has a high priority and the cockpit system has a low priority, i.e., the priority of the intelligent driving system is higher than the priority of the cockpit system.

[0135] When the intelligent driving system is in the parking scene and the cockpit system is in the touch scene, audio scene, visual scene, game scene, video scene, music scene, or download scene, the intelligent driving system has low priority and the cockpit system has high priority.

[0136] When the intelligent driving system is in the manual driving scene and the cockpit system is in the navigation scene, the intelligent driving system has low priority and the cockpit system has high priority.

[0137] When the cockpit system is in a standby scene or a screen-off scene, the cockpit system is set to low priority.

[0138] When the intelligent driving system is in a standby scene or a screen-off scene, the intelligent driving system has a low priority.

[0139] In this way, the priority of the first operating system and the priority of the second operating system can be determined based on the priority rule.

[0140] For example, if the first operating system is a cockpit system and the second operating system is an intelligent driving system, and the first user scene is a video scene and the second user scene is a driving scene, the first operating system has a low priority and the second operating system has a high priority.

[0141] In one implementation, user scenes can be prioritized and sorted by highest or lowest priority.

[0142] For example, the priority of the user scenes is as follows, in descending order: The sequence may include a driving scene > an interaction scene > an active scene > a parking scene > a screen-on scene > a screen-off scene.

[0143] Among them, the driving scenes may include, for example, intelligent driving scenes and manual driving scenes, the interaction scenes may include, for example, touch scenes, audio scenes and visual scenes, and the active scenes may include, for example, game scenes, video scenes, music scenes, navigation scenes and download scenes.

[0144] In this way, based on the above sorting, the priority of the first user scene can be set as the priority of the first operating system, and the priority of the second user scene can be set as the priority of the second operating system.

[0145] Take the example where the first operating system is a cockpit system and the second operating system is an intelligent driving system, if the first user scene is a video scene and the second user scene is a driving scene, the priority of the first user scene is lower than the priority of the second user scene, and accordingly, the priority of the first operating system is lower than the priority of the second operating system.

[0146] In one embodiment, priority scores may be pre-set for multiple user scenes.

[0147] By way of example, the priority scores of user scenes are shown in Table 1.

[0148] [Table 1]

[0149] It should be noted that the above priority scores are merely illustrative and do not specifically limit the embodiments of the present disclosure. Those skilled in the art can adjust the priority scores of each user scene based on the embodiments of the present disclosure, and any of these adjustments will not exceed the scope of protection of the embodiments of the present disclosure.

[0150] In this way, the priority relationship between the first operating system and the second operating system can be determined based on the priority scores of the first user scene and the second user scene. In other words, the priority score of the first user scene is the priority score of the first operating system, and the priority score of the second user scene is the priority score of the second operating system.

[0151] For example, if the first operating system is a cockpit system and the second operating system is an intelligent driving system, and the first user scene is a video scene with a priority score of 50, and the second user scene is a driving scene with a priority score of 90, then the priority of the first user scene is lower than the priority of the second user scene, and accordingly the priority of the first operating system is lower than the priority of the second operating system.

[0152] In step S252, a resource scheduling policy is determined based on the priority of the first operating system, the priority of the second operating system, the first resource state, and the second resource state.

[0153] In one embodiment, step S252 can be realized by the following steps S2521 to S2523.

[0154] In step S2521, it is determined whether the first operating system has free resources based on the first resource state, and it is also determined whether the second operating system has free resources based on the second resource state.

[0155] For example, the load status of the first operating system can be determined by setting a first load threshold. If the current load of the first operating system is greater than (or equal to) the first load threshold, it can be determined that the first operating system has no free resources. If the current load of the first operating system is less than the first load threshold, it can be determined that the first operating system has free resources.

[0156] For example, the first load threshold may include a utilization threshold for processor resources already acquired by the first operating system, such as a CPU utilization threshold, a GPU utilization threshold, an NPU utilization threshold, etc. The value of the first load threshold may be, for example, 80%, 85%, 88%, 90%, 91%, 92%, 93%, 94%, 95%, 96%, 97%, 98%, 99%, etc. Here, the utilization thresholds corresponding to different processors may be the same or different.

[0157] For example, when the CPU usage threshold is 90%, if the CPU usage is greater than 90%, it can be determined that the first operating system has no free CPU resources, and if the CPU usage is less than 90%, it can be determined that the first operating system has free CPU resources.

[0158] Similarly, a second load threshold can be set for the second operating system, and the second load threshold and the first load threshold can be the same or different. If the current load of the second operating system is greater than (or equal to) the second load threshold, it can be determined that the second operating system has no free resources. If the current load of the second operating system is less than the second load threshold, it can be determined that the second operating system has free resources.

[0159] The details not specifically explained regarding determining whether the second operating system has free resources are implemented by referring to the form of determining whether the first operating system has free resources, and redundant explanations will be omitted here.

[0160] In step S2522, if the second operating system has no free resources and the priority of the first operating system is lower than the priority of the second operating system, determine a first resource scheduling policy, where the first resource scheduling policy includes scheduling the first resource from the first operating system to the second operating system.

[0161] Here, the lack of free resources in the second operating system may include the following two cases:

[0162] In one case, the first operating system has no free resources, and the second operating system also has no free resources. In this case, it is necessary to ensure that the operating system with a higher priority can operate stably. Therefore, if the priority of the first operating system is lower than the priority of the second operating system, the first operating system can schedule the first resource to the second operating system, thereby allowing the second operating system to obtain more resources, avoiding resource shortages, and ensuring the stable operation of the second operating system.

[0163] In another case, when the first operating system has free resources and the second operating system does not, if the priority of the first operating system is lower than that of the second operating system, the first operating system can schedule the first resources to the second operating system, thereby allowing the second operating system to obtain more resources, avoiding resource shortages, and ensuring stable operation of the second operating system. Also, the free first resources in the first operating system can be used by the second operating system, thereby improving resource utilization.

[0164] In step S2523, if the first operating system has no free resources and the priority of the first operating system is higher than the priority of the second operating system, determine a second resource scheduling policy, where the second resource scheduling policy includes scheduling the first resource from the second operating system to the first operating system.

[0165] Here, the absence of free resources in the first operating system may include the following two cases:

[0166] In one case, the first operating system has no free resources, and the second operating system also has no free resources. In this case, it is necessary to ensure that the operating system with a higher priority can operate stably. Therefore, if the priority of the first operating system is higher than the priority of the second operating system, the second operating system can schedule the first resource to the first operating system, thereby allowing the first operating system to obtain more resources, avoiding resource shortages, and ensuring the stable operation of the first operating system.

[0167] In another case, when the second operating system has free resources and the first operating system does not, if the priority of the first operating system is higher than that of the second operating system, the second operating system can schedule the first resource to the first operating system, thereby allowing the first operating system to obtain more resources, avoiding resource shortages, and ensuring stable operation of the first operating system. Also, the free first resource in the second operating system can be used by the first operating system, thereby improving resource utilization.

[0168] FIG. 6 is a flowchart of a first scheduling policy decision-making process according to one exemplary embodiment of the present disclosure.

[0169] In one implementation, the first scheduling policy can be determined by the first operating system, and includes, for example, the following steps S310 to S360.

[0170] In step S310, a first resource state of the first operating system is determined.

[0171] Here, step S310 can be specifically implemented by referring to step S210, and redundant description will be omitted here. After determining the first resource state, the first operating system can send the first resource state to the second operating system via the IPC interface.

[0172] In step S320, a second resource state of the second operating system is determined.

[0173] Illustratively, the first operating system may receive the second resource state sent from the second operating system via the IPC interface.

[0174] In step S330, it is determined whether the first operating system has free resources based on the first resource status.

[0175] Here, step S330 can be specifically implemented by referring to step S2521, and redundant explanations will be omitted here.

[0176] After the first operating system determines whether there are free resources, it can jump to step S350.

[0177] In step S340, it is determined whether the second operating system has free resources based on the second resource status.

[0178] Here, step S340 can be specifically implemented by referring to step S2521, and redundant explanations will be omitted here. If there are no free resources in the second operating system, the process can jump to step S350. If there are free resources in the second operating system, the process can jump to step S320.

[0179] In step S350, it is determined whether the priority of the first operating system is higher than the priority of the second operating system.

[0180] Here, if the priority of the first operating system is higher than the priority of the second operating system, it can jump to step S320. That is, if the priority of the first operating system is higher than the priority of the second operating system, even if the second operating system has no free resources, the first operating system will not determine the first resource scheduling policy, and therefore will not schedule the first resource from the higher priority operating system to the lower priority operating system.

[0181] If the priority of the first operating system is lower than the priority of the second operating system, a jump can be made to step S360.

[0182] In step S360, a first resource scheduling policy is determined.

[0183] That is, when the priority of a first operating system is lower than the priority of a second operating system, regardless of whether the first operating system has free resources, the first operating system can determine a first scheduling policy, thereby scheduling first resources from the lower priority first operating system to the higher priority second operating system.

[0184] Then, after determining the first resource scheduling policy, the first resource scheduling policy can be implemented to complete resource scheduling. The following provides an exemplary description of how to implement the first resource scheduling policy.

[0185] In one implementation, the first resource scheduling policy may be executed by the first operating system and resource management layer invoking the processor. As shown in FIG. 6, the execution of the first resource scheduling policy may include steps S370 and S380.

[0186] In step S370, based on the resource requirement of the second operating system, a first target resource is released from the first resource already acquired by the first operating system, and the first target resource matches the resource requirement of the second operating system.

[0187] Here, step S370 can be performed by the first operating system calling the processor.

[0188] In one example, if the second operating system has a resource request, the second operating system can send the resource request to the first operating system via the IPC interface. That is, the first operating system can receive the resource request of the second operating system via the IPC interface. Here, the resource request of the second operating system may include the resource type and resource request amount required by the second operating system.

[0189] The resource type may include, for example, a CPU resource, a GPU resource, an NPU resource, a memory resource, etc. The resource requirement may include, for example, a CPU resource requirement, a GPU resource requirement, an NPU resource requirement, etc.

[0190] In one implementation, the second operating system can predict resources required for the second operating system within a certain period of time in the future based on the second user scene to determine the resource requirements of the second operating system, and then send the resource requirements of the second operating system to the first operating system.

[0191] For example, assume that the second operating system is an intelligent driving system and the second user scenario is an intelligent driving scenario. Assume that the second operating system currently acquires 200 TOPS (Tera Operations Per Second, or 1 trillion operations per second) of NPU resources. The intelligent driving application requires 150 TOPS of NPU resources in an elevated section in an urban area, and 250 TOPS of NPU resources in a pedestrian-vehicle coexistence section in an urban area. Therefore, when a vehicle travels from the elevated section in an urban area to the pedestrian-vehicle coexistence section in an urban area, the second operating system needs to acquire at least 50 TOPS of additional NPU resources to meet the computing power requirements of the intelligent driving application. That is, within a certain period of time in the future, for example, within the time remaining until the current intelligent driving reaches its destination, the resource requirement of the second operating system includes at least 50 TOPS of NPU resources.

[0192] After obtaining the resource requirements of the second operating system, the first operating system can determine whether the free resources in the first resource already obtained by the first operating system (hereinafter referred to as the first free resources) match the resource requirements of the second operating system.

[0193] For example, it can be determined whether the type of the first free resource matches the resource type required by the second operating system. For example, if the type of the first free resource is the same as the resource type required by the second operating system, it indicates that the type of the first free resource matches the resource type required by the second operating system. If the type of the first free resource is different from the resource type required by the second operating system, it indicates that the type of the first free resource does not match the resource type required by the second operating system.

[0194] For example, if a first free resource includes a CPU resource and a second operating system requests an NPU resource, the type of the first free resource does not match the resource type requested by the second operating system. If a first free resource includes a CPU resource and a second operating system requests a CPU resource, the type of the first free resource does match the resource type requested by the second operating system.

[0195] For example, it may be determined whether the resource amount of the first free resource matches the resource amount required by the second operating system. For example, if the resource amount of the first free resource is equal to or greater than the resource requirement of the second operating system for the same type of resource, it indicates that the resource amount of the first free resource matches the resource requirement of the second operating system. If the resource amount of the first free resource is smaller than the resource requirement of the second operating system for the same type of resource, it indicates that the resource amount of the first free resource does not match the resource requirement of the second operating system.

[0196] For example, if a first free resource includes an NPU resource of 200 TOPS and a second operating system requests an NPU resource of 100 TOPS, the resource amount of the first free resource matches the resource requirement of the second operating system. If a first free resource includes an NPU resource of 200 TOPS and a second operating system requests an NPU resource of 300 TOPS, the resource amount of the first free resource does not match the resource requirement of the second operating system.

[0197] From the above, if the resource type and resource amount of the first free resource match the resource type and resource requirement amount requested by the second operating system, respectively, it can be determined that the first free resource matches the resource requirement of the second operating system; otherwise, it can be determined that the first free resource does not match the resource requirement of the second operating system.

[0198] In one example, the resource requirement of the second operating system may include a resource requirement time of the second operating system, which may be a preset time or a predicted remaining duration of the current user scene of the second operating system.

[0199] For example, it can also be determined whether the remaining free time of the first free resource matches the resource request time of the second operating system. If the remaining free time of the first free resource is equal to or greater than the resource request time of the second operating system, it indicates that the remaining free time of the first free resource matches the resource request time of the second operating system. If the remaining free time of the first free resource is shorter than the resource request time of the second operating system, it indicates that the remaining free time of the first free resource does not match the resource request time of the second operating system.

[0200] In this case, if the resource type, resource amount, and remaining free time of the first free resource match the resource type, resource request amount, and resource request time requested by the second operating system, respectively, it can be determined that the first free resource matches the resource request of the second operating system; otherwise, it can be determined that the first free resource does not match the resource request of the second operating system.

[0201] Then, if the first free resource matches the resource request of the second operating system, the first operating system releases the first target resource from the first free resource, causing the first target resource to become unallocated, i.e., the released first target resource does not belong to either the first operating system or the second operating system. In some implementations, the release of the first target resource can also be performed by a resource management layer, and is not particularly limited here.

[0202] 7, if the first free resource includes 200 TOPS of NPU resources and the second operating system requests 100 TOPS of NPU resources, the first operating system can release 100 TOPS of NPU resources from the first free resource. Of course, the first operating system can also release more NPU resources from the first free resource, for example, 150 TOPS of NPU resources, and thus subsequently schedule more NPU resources to the second operating system.

[0203] In addition, if the first free resource does not match the resource request of the second operating system, the first operating system can perform internal resource scheduling to obtain the free first target resource and release the first target resource.

[0204] For example, the first operating system may perform internal resource scheduling based on a first user scenario. For example, as shown in FIG. 8, the first operating system may be a cockpit system and the first user scenario may be a video scenario. If the first free resource includes 10% of the total CPU resources and the second operating system requests 20% of the total CPU resources, the first operating system may reduce the video application's CPU resource occupancy by reducing parameters such as the video bit rate, resolution, and frame rate, thereby freeing up more CPU resources. For example, the first operating system may free up another 10% of the total CPU resources, which, combined with the existing first free resource, frees up 20% of the total CPU resources, forming a first target resource. The first target resource may then be released.

[0205] Similarly, if the first user scene is a game scene, the image quality of the game can be reduced, for example, by reducing the frame rate of the game, reducing the resolution, reducing the game image quality, reducing or turning off the motion in the game, etc., thereby reducing the resources occupied by the game application and obtaining more free resources. If the first user scene is a download scene, the download speed of the application can be reduced or the download task can be paused, thereby reducing the resources occupied by the download task and obtaining more free resources.

[0206] The first operating system may also exercise administrative control over background tasks, such as turning off background tasks or reducing resources allocated to background tasks to free up more resources, including turning off background applications that have not been used by the user for a long time, turning off background update tasks, download tasks, etc.

[0207] The embodiments of the present disclosure do not specifically limit the manner in which the operating system frees up more resources.

[0208] In step S380, the first target resource is scheduled to the second operating system.

[0209] In one implementation, step S380 can be performed by the resource management layer calling the processor.

[0210] In one example, after releasing the first target resource, the first operating system can further send a first notification message to the resource management layer, where the first notification message instructs the resource management layer to execute the first resource scheduling policy. In this way, the resource management layer can schedule the first target resource to the second operating system when receiving the first notification message. Here, the first notification message may include, for example, the first resource scheduling policy and a scheduled object (e.g., the first target resource), and is used to instruct the resource management layer to schedule the first target resource to the second operating system.

[0211] Illustratively, the first operating system may send a first notification message to the virtual machine manager hypervisor, and after receiving the first notification message, the virtual machine manager hypervisor schedules the released first target resource to the second operating system.

[0212] 7, after the first operating system releases 100 TOPS of NPU resources, the first operating system may send a first notification message to the virtual machine manager hypervisor, which instructs the virtual machine manager hypervisor to schedule the 100 TOPS of NPU resources to the second operating system. The virtual machine manager hypervisor receives the first notification message, performs resource scheduling, and schedules the 100 TOPS of NPU resources to the second operating system.

[0213] 8, the first operating system may release 20% of the total CPU resources and then send a first notification message to the virtual machine manager hypervisor, instructing the virtual machine manager hypervisor to schedule 20% of the total CPU resources to the second operating system. The virtual machine manager hypervisor receives the first notification message, performs resource scheduling, and schedules 20% of the total CPU resources to the second operating system.

[0214] In one implementation, the second scheduling policy can be determined by the second operating system, and the second resource scheduling policy can be executed by the second operating system and the resource management layer. The second operating system's determination of the second scheduling policy can be implemented by referring to the first operating system's determination of the first scheduling policy, and the second operating system and the resource management layer's execution of the second scheduling policy can be implemented by referring to the first operating system and the resource management layer's execution of the first scheduling policy, and redundant explanations will be omitted here.

[0215] For example, as shown in Figure 9, the first operating system is a cockpit system, the first user scene is an audio scene, the second operating system is an intelligent driving system, and the second user scene is a parking scene.

[0216] Generally, intelligent driving tasks require execution in the second operating system, so that most or all of the NPU resources are allocated to the second operating system by default, and the first operating system can only obtain a small amount of NPU resources or no NPU resources, which means that when the second user scene is a parking scene, the second operating system has a large amount of free NPU resources.

[0217] At the same time, when the first user scene is a voice scene, the voice recognition application of the first operating system may need to understand the voice content input by the user through a local large-scale model and then provide a corresponding reply. This means that the first operating system needs a large amount of NPU resources to meet the computational requirements of the local large-scale model. In this case, the free NPU resources (i.e., second free resources) of the second operating system can be released and scheduled for the first operating system.

[0218] For example, if the second free resource includes 400 TOPS of NPU resources and the first operating system's resource requirement is 300 TOPS of NPU resources, the second operating system can release 300 TOPS of NPU resources from the second free resource. Of course, the second operating system may release more NPU resources from the second free resource, for example, release 350 TOPS of NPU resources or release 400 TOPS of NPU resources, that is, release all of the free NPU resources.

[0219] After releasing the 300 TOPS of NPU resource, the second operating system can send a second notification message to the virtual machine manager hypervisor, which instructs the virtual machine manager hypervisor to schedule the 300 TOPS of NPU resource to the first operating system. The virtual machine manager hypervisor receives the second notification message, performs resource scheduling, and schedules the 300 TOPS of NPU resource to the first operating system.

[0220] As can be seen from the above technical solutions, the method according to the embodiments of the present disclosure can perform resource scheduling between different operating systems based on the resource requirements of each operating system in different user scenarios, that is, realize inter-system resource scheduling based on user scenarios, meet the resource requirements of each operating system in different user scenarios, and not only improve the running stability of the operating systems, but also make resource allocation more rational and improve resource utilization.

[0221] Exemplary Apparatus The resource scheduling method according to the embodiment of the present disclosure has been described above. The cockpit-driving integrated system (e.g., the first operating system, the second operating system, and the resource management layer in the cockpit-driving integrated system) includes software modules corresponding to the execution of each function to realize the above functions.

[0222] Of course, those skilled in the art can easily conceive that the present disclosure can be realized in the form of hardware or a combination of hardware and computer software, in accordance with the steps of the resource scheduling method described in each embodiment of the present disclosure. Whether a function is performed by hardware or by software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can realize the described functions using different methods for each specific application, but such realization should not be considered as going beyond the scope of the present disclosure.

[0223] FIG. 10 is a structural block diagram of a resource scheduling apparatus according to one exemplary embodiment of the present disclosure.

[0224] An embodiment of the present disclosure provides a resource scheduling apparatus for use in an integrated circuit running at least a first operating system and a second operating system.

[0225] In one embodiment, as shown in Figure 10, a resource scheduling device for implementing each step of the resource scheduling method may include a scene recognition unit 710, a scheduling management unit 720, and a scheduling execution unit 730. The functions of each unit may be implemented in a first operating system and / or a second operating system. Take the case where the functions of each unit are implemented in the first operating system as an example.

[0226] The scene recognition unit 710 is configured to determine a first user scene of the first operating system and send the first user scene to the scheduling management unit 720. For example, the scene recognition unit 710 can determine the first user scene based on application information running in the first operating system.

[0227] The scheduling management unit 720 is configured to determine a resource scheduling policy based on the first user scene.

[0228] In one implementation, the scene recognition unit 710 is configured to determine a first resource state of the first operating system and send the first resource state to the scheduling management unit 720. The scheduling management unit 720 is configured to determine a resource scheduling policy based on the first user scene and the first resource state.

[0229] In one implementation, the scheduling management unit 720 is configured to communicate with the second operating system, for example, via an IPC interface, to obtain a second user scene and a second resource state of the second operating system, and to determine a resource scheduling policy based on the first user scene, the second user scene, the first resource state, and the second resource state.

[0230] In one implementation, the scheduling management unit 720 is configured to determine a priority of a first operating system based on a first user scene, determine a priority of a second operating system based on a second user scene, and determine a resource scheduling policy based on the priority of the first operating system, the priority of the second operating system, the first resource state, and the second resource state.

[0231] In one implementation, the scheduling management unit 720 is configured to determine whether the first operating system has free resources based on the first resource state, determine whether the second operating system has free resources based on the second resource state, and, if the second operating system has no free resources and the priority of the first operating system is lower than the priority of the second operating system, determine a first resource scheduling policy, where the first resource scheduling policy includes scheduling the first resource from the first operating system to the second operating system.

[0232] In one implementation, the scheduling management unit 720 is configured to obtain a resource request of the second operating system, and when the free resources in the first resource already obtained by the first operating system do not match the resource request of the second operating system, determine an internal scheduling policy of the first operating system and send the internal scheduling policy of the first operating system to the scheduling execution unit 730. The scheduling execution unit 730 is configured to execute the internal scheduling policy of the first operating system and perform internal resource scheduling for the first operating system to obtain the free first target resource.

[0233] In one implementation, the scheduling execution unit 730 is further configured to release the first target resource and cause the first target resource to be in an unallocated state.

[0234] In one implementation, the resource scheduling apparatus further includes a resource management unit 810.

[0235] The scheduling management unit 720 is configured to send a resource scheduling policy (e.g., a first resource scheduling policy) to the resource management unit 810. The resource management unit 810 can be configured to implement the resource scheduling policy and perform resource scheduling between systems, for example, implement the first resource scheduling policy and schedule a first target resource to a second operating system.

[0236] In one implementation, the resource management unit 810 is configured to release the first target resource and put the first target resource into an unallocated state, that is, the release of the first target resource may be performed by the scheduling execution unit 730 or by the resource management unit 810.

[0237] In one implementation, the scheduling management unit 720 is configured to predict resources required for the first operating system within a predetermined time in the future based on the first user scene and determine resource requirements of the first operating system.

[0238] In one implementation, the scheduling management unit 720 is configured to send the first user scene, the first resource state, and the resource requirements of the first operating system to the second operating system, etc.

[0239] In one implementation, the function of any unit in the resource scheduling device can be realized by cooperation of multiple units, i.e., the resource scheduling device may include more units. For example, the resource scheduling device may include a cross-domain scheduling unit, and at least some functions of the scheduling management unit 720 can be realized by the cross-domain scheduling unit.

[0240] Exemplarily, the scheduling management unit 720 is configured to send the first user scene and the first resource state to the cross-domain scheduling unit, or the scene recognition unit 710 may send the first user scene and the first resource state to the cross-domain scheduling unit, and the cross-domain scheduling unit is configured to determine a resource scheduling policy based on the first user scene and the first resource state.

[0241] Illustratively, the cross-domain scheduling unit is configured to communicate with the second operating system to obtain a second user scene and a second resource state of the second operating system, and to determine a resource scheduling policy based on the first user scene, the second user scene, the first resource state, and the second resource state.

[0242] Illustratively, the cross-domain scheduling unit is configured to obtain resource requirements of the second operating system, and send the resource scheduling policy and the resource requirements of the second operating system to the scheduling management unit 720. In this way, the scheduling management unit 720 can determine an internal scheduling policy of the first operating system based on the resource scheduling policy and the resource requirements of the second operating system.

[0243] Illustratively, the cross-domain scheduling unit may be configured to send a resource scheduling policy (eg, a first resource scheduling policy) to the resource management unit 810, and cause the resource management unit 810 to implement the resource scheduling policy.

[0244] In one implementation, the functions of multiple units in the resource scheduling device may be realized in one unit, for example, at least two units among the scene recognition unit 710, the scheduling management unit 720, and the scheduling execution unit 730 are integrated into one unit, that is, the resource scheduling device may include fewer units, all of which do not exceed the scope of protection of the embodiments of the present disclosure.

[0245] Furthermore, in the first operating system or the second operating system, each unit of the resource scheduling device can be implemented in various forms, and the embodiments of the present disclosure are not limited thereto. Take, for example, an Android system as the first operating system. The scene recognition unit 710 may be located in an application framework layer of the Android system, the scheduling management unit 720 may be located in a native layer of the Android system, the scheduling execution unit 730 may be located in a kernel layer of the Android system, and the resource management unit 810 may be located in a resource management layer of the cockpit-driving integrated system. For example, the resource management unit 810 may be a virtual machine manager hypervisor of the resource management layer.

[0246] The resource scheduling device according to the embodiment of the present disclosure can perform resource scheduling between different operating systems based on the resource requirements of each operating system in different user scenarios, i.e., realizes resource scheduling between systems based on user scenarios, meets the resource requirements of each operating system in different user scenarios, and not only improves the running stability of the operating systems, but also makes resource allocation more rational and improves resource utilization.

[0247] Exemplary Electronic Devices An embodiment of the present disclosure provides an electronic device, which can be used in a vehicle, for example, an intelligent connected vehicle, and may be, for example, an on-board computing device, an on-board computing platform, an on-board computing unit, an intelligent driving computing platform, etc.

[0248] In one embodiment, an electronic device may include a chip system according to an embodiment of the present disclosure, which can execute at least one operating system, for example, an intelligent driving system and a cockpit system, to implement related functions of an integrated cockpit-driving system.

[0249] In one embodiment, the electronic device may include a housing, a power supply module, a heat dissipation module, and an external interface.

[0250] The enclosure is used to house and mount each hardware unit of an electronic device, protect each hardware unit from the effects of dust and water, and improve the reliability of the electronic device.

[0251] The power supply module is used to supply power to each hardware unit of the electronic device.

[0252] Heat dissipation modules include, for example, heat dissipation fans and liquid-cooled heat dissipation devices, and are used to dissipate heat from hardware units of electronic devices, thereby reducing the operating temperature of each hardware unit and improving the operating stability of each hardware unit.

[0253] The external interface is used to connect to each sensor in the vehicle, such as a camera, lidar, millimeter wave radar, ultrasonic radar, etc., to send commands to each sensor or receive data returned from the sensor. The external interface can also connect to each actuator in the vehicle, such as a drive system, braking system, steering system, etc., to send control commands to each system and receive feedback from each system.

[0254] Exemplary vehicles An embodiment of the present disclosure provides a vehicle, and the vehicle may include a land vehicle, an air vehicle, a water vehicle, an underwater vehicle, a space vehicle, etc. For specific details about the vehicle, reference may be made to the above-described embodiment, and redundant description will be omitted here.

[0255] A vehicle may include a chip system or electronic device according to an embodiment of the present disclosure to implement a resource scheduling method according to an embodiment of the present disclosure. In this way, when a user uses the vehicle, for example, driving the vehicle, or using the vehicle to watch videos, listen to music, or play games, the vehicle can perform inter-system resource scheduling between the cockpit system and the intelligent driving system based on the user scenario, providing a better user experience.

[0256] Exemplary Computer Program Products and Computer-Readable Storage Media In addition to the above methods and apparatus, embodiments of the present disclosure may be a computer program product including computer program instructions that, when executed by a processor, cause the processor to perform steps in the resource scheduling methods according to various embodiments of the present disclosure described above in the "Example Method" section of this specification.

[0257] The computer program product may have program code for carrying out operations of embodiments of the present disclosure written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and traditional procedural programming languages ​​such as "C" or similar programming languages. The program code may execute entirely on a user's computing device, partially on a user's device, as separate software packages, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0258] Additionally, an embodiment of the present disclosure may be a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, cause the processor to perform steps in the resource scheduling method according to various embodiments of the present disclosure described in the "Example Method" section above.

[0259] The computer-readable storage medium can be any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable medium may include, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include an electrical connection having one or more leads, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), fiber optics, a compact disc read-only memory (CD-ROM), an optical storage element, a magnetic storage element, or any suitable combination of the above.

[0260] Although the basic principles of the present disclosure have been described above with reference to specific embodiments, the benefits, advantages, effects, etc. mentioned in the present disclosure are not limited but merely illustrative, and these benefits, advantages, effects, etc. do not necessarily exist in each embodiment of the present disclosure. Furthermore, the specific details disclosed above are not limited but merely serve to serve as examples and to facilitate understanding, and the above details do not necessarily limit the present disclosure to be realized by the above specific details.

[0261] Those skilled in the art can make various modifications and variations to the present disclosure without departing from the spirit and scope of the present disclosure. Thus, if these modifications and variations of the present disclosure fall within the scope of the claims of the present disclosure and their equivalents, the present disclosure also intends to include these modifications and variations.

Claims

1. 1. A resource scheduling method for use in an integrated circuit running at least a first operating system and a second operating system, comprising: determining a first user scene of the first operating system; determining a resource scheduling policy for scheduling a first resource between the first operating system and the second operating system based on the first user scenario, wherein the first resource includes a resource shared by the first operating system and the second operating system.

2. The resource scheduling method of claim 1 , wherein the first operating system is a cockpit system and the second operating system is an intelligent driving system.

3. determining the resource scheduling policy for scheduling the first resource between the first operating system and the second operating system based on the first user scenario, determining a first resource state of the first operating system; and determining the resource scheduling policy based on the first user scene and the first resource state.

4. determining a second user scene of the second operating system; determining a second resource state of the second operating system; The resource scheduling method of claim 3 , further comprising: determining the resource scheduling policy based on the first user scene, the second user scene, the first resource state, and the second resource state.

5. determining the resource scheduling policy based on the first user scene, the second user scene, the first resource state, and the second resource state, determining a priority of the first operating system based on the first user scenario and determining a priority of the second operating system based on the second user scenario; determining the resource scheduling policy based on a priority of the first operating system, a priority of the second operating system, the first resource state, and the second resource state.

6. determining the resource scheduling policy based on the priority of the first operating system, the priority of the second operating system, the first resource state, and the second resource state, determining whether the second operating system has free resources based on the second resource state; 6. The resource scheduling method of claim 5, further comprising: if the second operating system has no free resources and the priority of the first operating system is lower than the priority of the second operating system, determining a first resource scheduling policy, the first resource scheduling policy including scheduling the first resource from the first operating system to the second operating system.

7. Releasing a first target resource from the first resource already acquired by the first operating system based on a resource request of the second operating system, wherein the first target resource matches the resource request of the second operating system; 7. The resource scheduling method of claim 6, further comprising the step of: scheduling the first target resource to the second operating system.

8. 8. The resource scheduling method of claim 7, further comprising: when an available resource in the first resource already acquired by the first operating system does not match the resource request of the second operating system, performing internal resource scheduling on the first operating system to acquire an available first target resource.

9. 8. The resource scheduling method of claim 7, further comprising predicting resources required by the second operating system within a predetermined time period in the future based on the second user scene to determine resource requirements of the second operating system.

10. determining whether the first operating system has free resources based on the first resource state; 7. The resource scheduling method of claim 6, further comprising: if the first operating system has no free resources and the priority of the first operating system is higher than the priority of the second operating system, determining a second resource scheduling policy, the second resource scheduling policy including scheduling the first resource from the second operating system to the first operating system.

11. Releasing a second target resource from the first resource already acquired by the second operating system based on the resource request of the first operating system, wherein the resource amount of the second target resource matches the resource request of the first operating system; 11. The resource scheduling method of claim 10, further comprising the step of: scheduling the second target resource to the first operating system.

12. 12. The resource scheduling method of claim 11, further comprising: when a resource amount of an available resource in the first resource already acquired by the second operating system is smaller than a resource amount of the second target resource, performing internal resource scheduling on the second operating system to acquire the available second target resource.

13. 12. The resource scheduling method of claim 11, further comprising predicting resources required by the first operating system within a predetermined time period in the future based on the first user scene to determine resource requirements of the first operating system.

14. The step of determining the first user scene of the first operating system includes: determining the first user scene based on application information running on the first operating system; The step of determining the second user scene of the second operating system includes: The resource scheduling method according to any one of claims 4 to 13, further comprising the step of determining the second user scene based on information of applications running in the second operating system.

15. 2. The resource scheduling method of claim 1, wherein the first operating system and the second operating system communicate via an inter-process communication IPC interface.

16. 1. A resource scheduling apparatus for use in an integrated circuit running at least a first operating system and a second operating system, comprising: a scene recognition unit configured to determine a first user scene of the first operating system; a scheduling management unit configured to determine a resource scheduling policy for scheduling a first resource between the first operating system and the second operating system based on the first user scene; The resource scheduling device, wherein the first resource includes a resource shared by the first operating system and the second operating system.

17. The resource scheduling apparatus of claim 16, wherein the first operating system is an intelligent driving system and the second operating system is a cockpit system.

18. the scene recognition unit is configured to determine a first resource state of the first operating system; The resource scheduling device according to claim 16 or 17, wherein the scheduling management unit is configured to determine the resource scheduling policy based on the first user scene and the first resource state.

19. 20. The resource scheduling device of claim 18, wherein the scheduling management unit is configured to obtain a second user scene and a second resource state of the second operating system, and to determine the resource scheduling policy based on the first user scene, the second user scene, the first resource state, and the second resource state.

20. A chip system comprising a processor and a memory, the memory storing computer program instructions that, when executed by the processor, cause the chip system to perform the steps of the method of any one of claims 1 to 13.

21. An electronic device comprising the chip system of claim 20.

22. 21. A vehicle comprising the chip system of claim 20.

Images