A multi-core-based task scheduling method, apparatus, device, and medium

Abstract

This invention discloses a multi-core-based task scheduling method, apparatus, device, and medium, relating to the field of task processing. The method includes: a main core iterating through the trigger functions of all application tasks via a main task, and determining at least one application task to be scheduled based on the trigger functions; each application task has its corresponding trigger function and task main function; the main task scheduling at least one application task to the main core and / or slave cores according to a task scheduling strategy; the main core and / or slave cores obtaining the at least one application task scheduled by the main task through slave tasks; the slave tasks executing the corresponding application task's task main function according to the application task cycle, and feeding back the task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores to the main core. This invention fully utilizes the computing power of multiple cores to execute user business logic, improving the overall system throughput, reducing the worst-case execution time of tasks, and enhancing real-time performance.

Description

Technical Field

[0001] This invention relates to the field of task processing, and more specifically to a multi-core-based task scheduling method, apparatus, device, and medium. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards domain-centralized and even centrally computed architectures, the computational demands of vehicle domain controllers are becoming increasingly complex. Multi-core microcontroller units (MCUs), due to their powerful parallel processing capabilities, have become the mainstream hardware solution for high-performance vehicle domain controllers. Therefore, how to efficiently and intelligently manage the computing resources on multi-core MCUs has become a key challenge for improving system performance, reliability, and energy efficiency.

[0003] Currently, task scheduling in multi-core MCUs typically uses a static binding approach. During the design phase, developers assign specific vehicle tasks (such as body control, air conditioning management, vehicle communication, etc.) to one or several specific computing cores based on experience or simple calculations. The operating system is responsible for managing task priorities and switching within each core. However, task migration between cores is usually difficult or not supported.

[0004] To ensure system stability during future feature upgrades or peak loads, users have to reserve a certain amount of computing power margin on each core of a multi-core MCU, such as reserving 30% computing power resources for each core, resulting in low hardware resource utilization.

[0005] Meanwhile, during system operation, the triggering conditions and computational load of different vehicle tasks are dynamically changing. Static allocation can easily lead to some cores being under high load for a long time, while other cores are relatively idle. This load imbalance will not only cause increased task processing latency and affect real-time performance, but may also affect chip lifespan and reliability due to local overheating.

[0006] Therefore, how to provide a method for dynamic scheduling and load balancing of computing resources in the process of multi-core MCUs processing vehicle tasks is an important issue that the industry urgently needs to address. Summary of the Invention

[0007] In view of this, embodiments of the present invention provide a multi-core-based task scheduling method, apparatus, device and medium to solve the problem of relying on static scheduling in the process of multi-core MCUs processing vehicle tasks.

[0008] According to a first aspect, embodiments of the present invention provide a multi-core-based task scheduling method, applied to a vehicle domain controller consisting of a master core and at least one slave core, the method comprising:

[0009] The main core iterates through the trigger functions of all application tasks through the main task, and determines at least one application task to be scheduled based on the trigger function. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters.

[0010] The primary task schedules at least one application task to the primary core and / or the secondary core according to the task scheduling policy.

[0011] The main core and / or slave cores obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task's cycle and feeds back the application task's execution status and the real-time remaining computing power of the main core and / or slave core to the main core.

[0012] In conjunction with the first aspect, in the first embodiment of the first aspect, the main core iterates through the trigger functions of all application tasks by the main task, and determines at least one application task to be scheduled based on the trigger functions, specifically including:

[0013] The main core obtains the user's task execution request through the main task, parses the task execution request, and determines all application tasks and the target state of the application tasks.

[0014] The main core iterates through the trigger functions of all application tasks through the main task; the trigger function determines the control target of the application task based on internal and external dependencies and the target state, determines the current state of the application task, and determines whether to trigger the application task based on the difference between the current state and the control target.

[0015] If the difference in the feedback from the trigger function exceeds a preset threshold, the corresponding application task will be identified as an application task to be scheduled.

[0016] If the difference in feedback from the trigger function does not exceed a preset threshold and the corresponding main task function has already run, a task scheduling instruction to shut down the application task is sent to the main core and / or slave core running the corresponding application task; the slave task shuts down the corresponding main task function according to the task scheduling instruction, thereby shutting down the application task.

[0017] In conjunction with the first aspect, in the second embodiment of the first aspect, the main task schedules at least one application task to the main core and / or the slave core according to the task scheduling policy, specifically including:

[0018] The main task acquires the real-time remaining computing power of all cores and determines the task computing power data of each application task to be scheduled; the task computing power data is the maximum computing power resources occupied by the application task.

[0019] Determine the task scheduling strategy based on unscheduled application tasks and vehicle status;

[0020] For each application task to be scheduled, the application task to be scheduled is scheduled and distributed to the main core and / or the slave core according to the real-time remaining computing power and the task scheduling policy.

[0021] In conjunction with the second implementation of the first aspect, in the third implementation of the first aspect, the step of scheduling and distributing each application task to be scheduled to the main core and / or slave cores according to the real-time remaining computing power and the task scheduling strategy specifically includes:

[0022] If the primary scheduling strategy is determined, all application tasks to be scheduled will be scheduled and distributed to the main core.

[0023] When the second scheduling strategy is determined, the application tasks to be scheduled are sequentially scheduled to the main core or slave core with the highest real-time remaining computing power according to the time order in which the application tasks to be scheduled are generated.

[0024] In conjunction with the second implementation of the first aspect, in the fourth implementation of the first aspect, the step of scheduling and distributing each application task to be scheduled to the main core and / or slave cores according to the real-time remaining computing power and the task scheduling strategy specifically includes:

[0025] When the third scheduling strategy is determined, the computing power difference between the task computing power data of the application task to be scheduled and the highest real-time remaining computing power is determined.

[0026] Determine all application tasks currently running on the master core or slave core with the highest real-time remaining computing power, as well as the task computing power data of each application task. Based on the task computing power data and the computing power difference, determine the application tasks to be scheduled in the master core or slave core with the highest real-time remaining computing power.

[0027] Based on the generation time order of the application tasks to be scheduled, the application tasks to be scheduled from the main core or slave core with the highest real-time remaining computing power are sequentially scheduled to the other remaining cores; the total computing power data of the application tasks to be scheduled from the main core or slave core with the highest real-time remaining computing power is not less than the computing power difference.

[0028] In conjunction with the first aspect, in the fifth embodiment of the first aspect, the main core and / or slave core obtain at least one application task scheduled by the main task from the slave task. The slave task executes the corresponding application task's main function according to the application task cycle, and feeds back the task execution status of the application task and the real-time remaining computing power of the main core and / or slave core to the main core. Specifically, this includes:

[0029] The primary core and / or secondary core obtain at least one application task scheduled by the primary task from the task;

[0030] Determine whether the main function of the application task has been executed from the task description.

[0031] If it is determined that the task has not been executed, the task parsing control target is used to execute the corresponding application task's main function according to the application task cycle, and the task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores are fed back to the main core; the task location is used to locate the application task's main function address and input data address library, the task prepares the local context and jumps to the task's main function to start execution, and thus runs the task's main function;

[0032] Once it is determined that the task has been executed, the task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores will be fed back to the main core.

[0033] After the main task function has finished executing, the main task closes the main task function.

[0034] In conjunction with the first aspect, in the first embodiment of the first aspect, before the step of the main core traversing all application tasks through the trigger function of the main task and determining at least one application task to be scheduled according to the trigger function, the method further includes:

[0035] The main kernel starts up, and the main kernel loads and runs the main task.

[0036] Start each slave core, and the master core and each slave core load and run their respective slave tasks, register with the master core, and report the readiness status of the slave cores;

[0037] The main kernel reads the description information of all application tasks from the configuration file and constructs a global task descriptor table based on the description information.

[0038] According to a second aspect, embodiments of the present invention also provide a multi-core-based task scheduling device, applied to a vehicle domain controller consisting of a master core and at least one slave core, the device comprising:

[0039] The trigger determination module is used to utilize the main core and traverse the trigger functions of all application tasks through the main task to determine at least one application task to be scheduled based on the trigger functions. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters.

[0040] The task scheduling module is used to schedule at least one application task to the main core and / or the slave core using the main task and according to the task scheduling policy.

[0041] The task execution module is used to utilize the main core and / or the slave core and obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task cycle, and feeds back the task execution status of the application task and the real-time remaining computing power of the main core and / or the slave core to the main core.

[0042] According to a third aspect, embodiments of the present invention also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of any of the multi-core-based task scheduling methods described above.

[0043] According to a fourth aspect, embodiments of the present invention also provide a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multi-core-based task scheduling method described above.

[0044] The multi-core-based task scheduling method, apparatus, device, and medium of this invention determine the application tasks to be scheduled by traversing the trigger functions of each application task through the main task of the main core. Then, the main task schedules and distributes the application tasks to be scheduled to each core through global dynamic scheduling, breaking down the computing power barriers between cores and realizing global management of computing power resources of the vehicle domain controller. This task scheduling method does not require separate reservation of computing power resources for each core, thereby greatly reducing the computing power waste caused by static reservation. It enables more complex application tasks to be carried under the same hardware configuration, and reduces the requirements for the number of cores and performance while meeting the same needs, thereby improving the utilization rate of core computing power and saving costs. The main task, slave tasks, and application tasks are decoupled. The main task in the vehicle domain controller manages the core computing resources and schedules application tasks. Slave tasks execute the most computationally intensive processes within application tasks, while application tasks implement the user's specific business logic. This decoupled, loosely coupled task scheduling approach separates the most computationally intensive processes (i.e., the main function) from the application tasks. These processes can be dynamically scheduled by the main core based on trigger functions, reducing unnecessary computational consumption. The main task schedules tasks based on real-time computing power feedback from each core, automatically allocating new application tasks to the most idle core. This fully utilizes multi-core computing power to execute user business logic, improving overall system throughput, reducing worst-case execution time, and enhancing real-time performance. Furthermore, the decoupling of application tasks from physical cores means they are not bound to any specific core, eliminating the need for software architecture refactoring during scheduling and significantly reducing development and maintenance complexity. Attached Figure Description

[0045] The features and advantages of the invention will be more clearly understood by referring to the accompanying drawings, which are schematic and should not be construed as limiting the invention in any way. In the drawings:

[0046] Figure 1 One of the flowcharts of the multi-core-based task scheduling method provided by the present invention is shown;

[0047] Figure 2 This diagram illustrates the data structure of the main task in the multi-core-based task scheduling method provided by the present invention.

[0048] Figure 3 This diagram illustrates the data structure of application tasks in the multi-core-based task scheduling method provided by the present invention.

[0049] Figure 4 This diagram illustrates the data structure of the core data in the multi-core-based task scheduling method provided by the present invention.

[0050] Figure 5 The second flowchart of the multi-core-based task scheduling method provided by the present invention is shown;

[0051] Figure 6 A schematic diagram of the structure of the multi-core-based task scheduling device provided by the present invention is shown.

[0052] Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] As automotive electronic and electrical architectures evolve towards domain-centralized and even centrally computed architectures, the computing demands of vehicle domain controllers are becoming increasingly complex. The vehicle domain controller is the regional brain of an intelligent vehicle. It takes over the functions originally handled by dozens or even hundreds of distributed small controllers, such as Electronic Control Units (ECUs), consolidating them into several more powerful and intelligent central computers. These central computers are responsible for decision-making, control, and data processing within a specific functional domain. The vehicle domain controller is not merely a hardware integration system; it is the cornerstone for realizing software-defined vehicles, Over-The-Air (OTA) technology upgrades, and advanced intelligent functions.

[0055] Multi-core MCUs, due to their powerful parallel processing capabilities, have become the mainstream hardware solution for high-performance vehicle domain controllers. Therefore, how to efficiently and intelligently manage the computing resources on multi-core MCUs has become a key challenge for improving system performance, reliability, and energy efficiency.

[0056] Currently, task scheduling in multi-core MCUs typically uses a static binding approach. During the design phase, developers assign specific vehicle tasks (such as body control, air conditioning management, vehicle communication, etc.) to one or several specific cores based on experience or simple calculations. The operating system is responsible for managing task priorities and switching within each core. However, task migration between cores is usually difficult or not supported.

[0057] To ensure system stability during future feature upgrades or peak loads, users must reserve a certain amount of computing power margin on each core of a multi-core MCU, for example, reserving 30% computing power resources for each core. For an N-core MCU, this means reserving the equivalent of N times 30% of the core's computing power. Assuming a quad-core MCU reserves 30% of its computing power per core, this results in a waste of the equivalent computing power of 1.2 cores, leading to low hardware resource utilization. This method of reserving computing power for each core is particularly inadequate for current vehicle tasks requiring high computing power, such as assisted driving and road condition recognition, and cannot meet users' actual needs.

[0058] Meanwhile, during system operation, the triggering conditions and computational load of different vehicle tasks are dynamically changing. Static allocation can easily lead to some cores being under high load for a long time, while other cores are relatively idle. This load imbalance will not only cause increased task processing latency and affect real-time performance, but may also affect chip lifespan and reliability due to local overheating.

[0059] In summary, how to provide a method for dynamic scheduling and load balancing of computing resources in the process of multi-core MCUs processing vehicle tasks is an important issue that the industry urgently needs to address.

[0060] To address the aforementioned issues, this specification provides a multi-core-based task scheduling method designed to fully utilize the computing power of multiple cores to execute user business logic. This multi-core-based task scheduling method can be applied to electronic devices, including laptops, desktop computers, smartphones, smart wearable devices, and tablets. Furthermore, this multi-core-based task scheduling method can also be applied to applications running on the aforementioned electronic devices. Figure 1 This is a flowchart illustrating a multi-core-based task scheduling method according to an embodiment of the present invention. This method is applied to a vehicle domain controller, such as... Figure 1 As shown, the method may include the following steps:

[0061] S101. The main core iterates through the trigger functions of all application tasks through the main task, and determines at least one application task to be scheduled based on the trigger functions. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies (inputs) of the application task and is used to indicate whether the application task needs to be triggered. The task main function is the control process of the application task and is used to control the vehicle components to achieve the control objectives of the application task according to the task configuration parameters.

[0062] In this embodiment of the invention, the vehicle domain controller is a multi-core MCU, which includes a master core and at least one slave core. The master core and slave cores establish communication through inter-processor communication (IPC). Different cores can exchange data and work collaboratively through IPC. IPC is responsible for rapidly transmitting information between different functional areas of the vehicle domain controller.

[0063] It's understandable that the master core and slave cores can have different computing power and uses. This allows each core to leverage its own computing strengths, achieving optimal task scheduling configuration, significantly improving overall performance, reducing power consumption, and simplifying development. In this case, the core with the best computing power can be used as the core of the vehicle domain controller, with the other cores serving as slave cores. If there are multiple cores with optimal computing power, or if the computing power of all cores in a multi-core MCU is equal, one of the cores with the best computing power or one of the cores with equal computing power can be used as the master core, with the other cores serving as slave cores.

[0064] This master-slave core architecture allows the vehicle domain controller's cores to be divided into master and slave cores based on their respective functions. Depending on the core structure, multiple cores can run the same or different operating systems.

[0065] In this embodiment of the invention, the main core has a relatively complex structure and function. It is responsible for the management and scheduling of global computing resources and tasks, and completes the boot loading of slave cores. Slave cores are managed by the main core and are responsible for running application tasks scheduled by the main core.

[0066] In this embodiment of the invention, the main task is the foundational task within the entire framework. As the cornerstone and manager of task scheduling, the main task runs permanently within the main kernel. It does not directly handle specific user functions but rather provides system-level services. The main task includes, but is not limited to, a lightweight operating system kernel, IPC drivers and management, centralized access agents for peripherals (such as CAN, ETH, and SPI), and, most importantly, global task scheduling. The main task is the first and continuously running task after system startup.

[0067] Please see Figure 2The data in the main task can include an application task data array, a core data array, fixed system input tasks, and fixed system output tasks. The data of all application tasks together constitute the application task data array. The core data of the main core itself and all slave cores that communicate with the main core together constitute the core data array. The fixed system input tasks are the data acquired through peripherals or the communication data transmitted from other modules, such as the acquired temperature data and location data. The fixed system output tasks are the external control commands, such as the control commands for vehicle relays and vehicle switches.

[0068] The main core can be responsible for distributing various application tasks, collecting the real-time remaining computing power of each core (including the main core and slave cores), collecting the internal and external status of vehicle components, and outputting task scheduling instructions through the main task running in it.

[0069] Application tasks are used to implement specific user business logic. Each application task can be designed to control a particular vehicle component, such as air conditioning control, anti-pinch windows, vehicle lights, or diagnostic processing. Application tasks are not bound to any specific core; their execution location is dynamically determined by the main task based on the task scheduling strategy. Each application task is encapsulated as an independent module with a standard interface.

[0070] Please see Figure 3 The data in an application task can include the address of the main task function, the address of the trigger function, the input data address library, the output data address library, the application task cycle, the running flag, and the task computing power data. The address of the main task function enables each core to run the main task function, and the address of the trigger function enables each core to run. The running flag indicates whether the application task runs the trigger function in a certain core. The task computing power data represents the maximum computing power resources used by the application task. The task computing power data is a value pre-determined based on stress testing during the development phase. By conducting stress testing in advance, the maximum computing power resources used by each application task can be pre-determined, and the maximum computing power resources used can be used as the task computing power data of the corresponding application task.

[0071] By determining the computing power data for each task, the main core can pre-calculate whether the computing power allocated to the slave cores is sufficient before scheduling tasks. Suppose an application task needs to be scheduled to the slave core with the highest real-time remaining computing power. If the computing power of the slave core with the highest real-time remaining computing power is still insufficient, the main core can pre-allocate other application tasks running on the slave core with the highest real-time remaining computing power to other slave cores, releasing some computing power resources of that slave core to ensure the computing power requirements of this application task.

[0072] S102. The main task running on the main core schedules at least one application task to the main core and / or the slave core according to the task scheduling policy.

[0073] In this embodiment of the invention, the main core includes and runs the following components:

[0074] Task scheduler: Responsible for maintaining a global list of schedulable application tasks and executing task scheduling strategies periodically or in an event-driven manner. The task scheduler's decision-making basis includes: real-time remaining computing power fed back from each core, task priority, affinity and / or exclusion constraints between tasks, task scheduling strategies, etc.

[0075] IPC server: Responsible for managing communication channels with all slave cores. The master core sends task data and task scheduling instructions to the target slave cores through the IPC server, and receives the task execution status and real-time remaining computing power from the slave cores.

[0076] Peripheral Proxy Service: Provides a unified and secure peripheral access interface for application tasks, avoiding multi-core contention for hardware resources.

[0077] In this embodiment of the invention, the main core is able to run the main task as the basic task through the task scheduler, IPC server and peripheral agent service.

[0078] The master and slave cores also contain and run the following components:

[0079] Slave Task: A lightweight task execution container. The slave task is mainly responsible for receiving task scheduling instructions from the master core through IPC, loading and executing the task main function of the specified application task, and feeding back information such as the slave core's real-time remaining computing power and task execution status to the master core through IPC.

[0080] Each core will run a slave task instance. Not only do slave cores need to run slave task instances, but master cores will also run slave task instances.

[0081] Monitoring component: Used to monitor and calculate the real-time remaining computing power of this core, such as by calculating the ratio of task execution time to total time over a period of time, or the ratio of CPU idle time slices.

[0082] Local execution environment: Provides the stack space, context, etc. required for application tasks to run.

[0083] In this embodiment of the invention, each core is able to run application tasks by means of tasks, monitoring components, and a local execution environment.

[0084] Please see Figure 4Whether it is the main core or the slave core, each core has its own core data. The core data can include data arrays generated by running application tasks, the number of application tasks running in real time, and the real-time remaining computing power.

[0085] In this embodiment of the invention, the real-time remaining computing power of the main core and slave cores is calculated by multiplying the core's computing power resources by the current remaining computing power rate. The current remaining computing power is 100% minus the current occupied computing power rate. The occupied computing power rate is obtained by statistically analyzing the running time and idle time of application tasks. Assuming that a core maintains a 10ms periodic task and runs a total of 4 application tasks, and the current running times of these 4 application tasks are 0.5ms, 1ms, 1ms, and 2ms respectively, then the idle time of this core is 5.5ms, the current computing power utilization rate of this core is 45%, and the current remaining computing power is 55%.

[0086] That is, the current computing power utilization rate = (total running time of application tasks / time of periodic tasks) × 100%, and the current computing power utilization rate can reflect the load rate of the corresponding core.

[0087] Based on the architecture of a multi-core MCU, the clock frequency of each core may be different, and correspondingly, the theoretical maximum computing power resources of each core may also be different. Therefore, the real-time remaining computing power is the computing power resources multiplied by the current remaining computing power rate.

[0088] S103. The main core and / or slave core obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task cycle and feeds back the task execution status of the application task and the real-time remaining computing power of the main core and / or slave core to the main core.

[0089] In this embodiment of the invention, both the main core and the slave core can obtain application tasks scheduled and issued by the main core through the main task. Simultaneously, the main task can schedule multiple application tasks to a single core for execution. After the main core and / or the slave core obtain at least one application task through the slave task, the slave task of the main core and / or the slave core will execute the corresponding application task's main function according to the application task's cycle, for example, 1ms. Since the main function is the control process of the application task, when the main function is executed by the core, it can control vehicle components such as compressors, dampers, and blowers according to the task configuration parameters to achieve the control target and thus realize the application task.

[0090] The core execution of the main task function is the execution of the control process or function calculation process mentioned above. This process will calculate the task configuration parameters, which can be sent to the vehicle components. Executing the main task function requires a lot of computing resources. The execution process of the main task function is the process that consumes the most computing resources in the entire application task, while the execution of the trigger function is the triggering process of the application task and consumes relatively less computing resources.

[0091] In this embodiment of the invention, the application task is separated into a trigger function and a task main function that are executed independently, instead of using a single function to implement the application task. This loosely coupled task scheduling method separates the process of the application task that consumes the most computing resources, namely the task main function. At the same time, the process that consumes the most computing resources can be dynamically decided by the main core based on the trigger function and dynamically scheduled by the main task, reducing unnecessary computing power consumption.

[0092] The multi-core-based task scheduling method of this invention determines the application tasks to be scheduled by traversing the trigger functions of each application task through the main task of the main core. Then, the main task schedules and distributes the application tasks to be scheduled to each core through global dynamic scheduling, breaking down the computing power barriers between cores and realizing global management of computing power resources of the vehicle domain controller. This task scheduling method does not require the separate reservation of computing power resources for each core, thereby greatly reducing the computing power waste caused by static reservation. It enables more complex application tasks to be carried under the same hardware configuration, and reduces the requirements for the number of cores and performance while meeting the same needs, thereby improving the utilization rate of core computing power and saving costs. The main task, slave tasks, and application tasks are decoupled. The main task in the vehicle domain controller manages the core computing resources and schedules application tasks. Slave tasks execute the most computationally intensive processes within application tasks, while application tasks implement the user's specific business logic. This decoupled, loosely coupled task scheduling approach separates the most computationally intensive processes (i.e., the main function) from the application tasks. These processes can be dynamically scheduled by the main core based on trigger functions, reducing unnecessary computational consumption. The main task schedules tasks based on real-time computing power feedback from each core, automatically allocating new application tasks to the most idle core. This fully utilizes multi-core computing power to execute user business logic, improving overall system throughput, reducing worst-case execution time, and enhancing real-time performance. Furthermore, the decoupling of application tasks from physical cores means they are not bound to any specific core, eliminating the need for software architecture refactoring during scheduling and significantly reducing development and maintenance complexity.

[0093] In this embodiment of the invention, step S101 includes:

[0094] S1011. The main core obtains the user's task execution request through the main task, parses the task execution request, and determines all application tasks and the target state of the application tasks.

[0095] By receiving and parsing task execution requests through the main task, the business logic that the user wants to implement, i.e. the user's business requirements, can be determined. At the same time, the user's task execution request can also carry the specific target state that each application task needs to present, and then the target state can be parsed to obtain the target state.

[0096] S1012. The main core iterates through the trigger functions of all application tasks through the main task. The trigger function determines the control target of the application task based on internal and external dependencies and the target state, determines the current state of the application task, and determines whether to trigger the application task based on the difference between the current state and the control target.

[0097] In this embodiment of the invention, each application task has its corresponding internal and external dependencies, and different application tasks can have different internal and external dependencies. For example, if an application task is to control the vehicle's exterior headlights, its trigger function can be designed based on the input from the vehicle's buttons, the battery's state of charge (SOC), and the ambient light level outside the vehicle. That is, the internal and external dependencies of its trigger function are the button input, the battery SOC, and the ambient light level outside the vehicle. If an application task is to control the vehicle's air conditioning, its trigger function can be designed based on the input from the vehicle's buttons, the vehicle's temperature, and the vehicle's humidity. That is, the internal and external dependencies of its trigger function are the input from the vehicle's buttons, the vehicle's temperature, and the vehicle's humidity.

[0098] Since different application tasks have different internal and external dependencies, a control target can be generated based on the specific internal and external dependencies and the target state. The process of generating a control target based on internal and external dependencies and the target state is also known as the task triggering condition.

[0099] In this embodiment of the invention, the main task will also obtain the current state of the application task. For example, when a door switch sensor is triggered, an interrupt is generated and captured by the main task running in the main core. At this time, the current state of the application task will also change.

[0100] S1013. If the difference in the feedback from the trigger function exceeds a preset threshold, the corresponding application task is identified as an application task to be scheduled.

[0101] Implementing a user's business logic depends on at least one input. Therefore, the internal and external dependencies of an application task are not limited to a single element. The control objective of the application task can be determined from the current internal and external dependencies and the target state. For example, if the current state of an application task controlling the vehicle's headlights is determined to be "headlights on," the control objective state of the application task is also determined to be "headlights on." Since the current state equals the control objective state, it is only necessary to maintain the peripheral output state through the main core. It is not necessary to continuously run or execute the application task. If the application task has already been executed, it can be closed. Conversely, if the current state of an application task controlling the vehicle's headlights is determined to be "headlights off," there is a significant difference between the current state and the control objective state, i.e., the difference exceeds a preset threshold. Therefore, the main core's main task determines that this application task is a task that needs to be executed, i.e., it is an application task to be scheduled.

[0102] It should be noted that this step only identifies all application tasks to be scheduled, but does not determine which core(s) these application tasks will be scheduled to.

[0103] S1014. If the difference in feedback from the trigger function does not exceed a preset threshold and the corresponding main task function has already run, a task scheduling instruction to shut down the application task is sent to the main core and / or slave core running the corresponding application task. Based on this task scheduling instruction, the slave task of the main core and / or slave core shuts down the corresponding main task function, thereby shutting down the application task. The task scheduling instruction is a data structure transmitted via IPC.

[0104] In this embodiment of the invention, the difference in feedback from the trigger function does not exceed a preset threshold, which means that the control objective of the application task has been achieved. For example, the control objective of the application task is to control the temperature inside the vehicle to A℃. If the current temperature inside the vehicle reaches A℃, it indicates that the control objective of the application task has been achieved, that is, the difference in feedback from the trigger function does not exceed the preset threshold. Therefore, the application task can be closed accordingly, that is, the corresponding core closes the task main function corresponding to the application task.

[0105] In this embodiment of the invention, step S102 specifically includes:

[0106] S1021. The main task obtains the real-time remaining computing power of all cores and determines the task computing power data of each application task to be scheduled.

[0107] Application tasks can be executed repeatedly. The task computing power data represents the maximum computing power resources used by the application task. The task computing power data is a value determined in advance based on stress testing. By conducting stress testing in advance, the maximum computing power resources used by each application task can be determined in advance, and the maximum computing power resources can be used as the task computing power data of the corresponding application task.

[0108] S1022. Determine the task scheduling strategy based on the unscheduled application tasks and vehicle status.

[0109] In this embodiment of the invention, the task scheduling strategy is not determined by a single parameter, but rather by the unscheduled application tasks and the vehicle state. Different vehicle states will influence the generated task scheduling strategy. For example, in vehicle parking mode, the task scheduling strategy tends to favor the low-power mode scheduling strategy, while in assisted driving mode, the task scheduling strategy tends to favor the load-balancing mode scheduling strategy. The task scheduling strategy can be: a first scheduling strategy, a second scheduling strategy, a third scheduling strategy, etc., wherein:

[0110] First scheduling strategy: The scheduling strategy in low-power mode. Second scheduling strategy: The scheduling strategy in load balancing mode. Third scheduling strategy: The scheduling strategy for application tasks requiring massive computational power.

[0111] S1023. For each application task to be scheduled, schedule and distribute the application task to the main core and / or slave core according to the real-time remaining computing power and the task scheduling policy.

[0112] To meet the low-power requirements of automobiles, such as static current management and vehicle parking, it is necessary to dynamically shut down some cores based on the vehicle's state, such as when the engine is off or in hibernation mode, thereby reducing functionality. In existing static scheduling schemes, the design of low-power scenarios must strictly plan which application tasks can be merged and which cores can be shut down in the early stages of development. However, if the requirements change later, such as adding a vehicle function that runs during hibernation, it may be necessary to make significant adjustments to the software architecture, resulting in poor flexibility and high maintenance costs.

[0113] Depending on the different task scheduling strategies, step S1023 specifically includes:

[0114] S10231. If the first scheduling strategy is determined, all application tasks to be scheduled are scheduled and distributed to the main core.

[0115] Traditional scheduling methods, if required to run N application tasks in low-power mode, would require all cores of the vehicle domain controller to be online if these N tasks were run on all cores of an N-core MCU, thus failing to achieve minimum power consumption. Based on the first scheduling strategy, all N application tasks can be assigned to the main core, allowing the remaining N-1 slave cores to be shut down, achieving optimal energy consumption. This first scheduling strategy eliminates the need to consider the power consumption of the tasks themselves or determine which tasks are low-power, enabling flexible low-power design.

[0116] In particular, if the real-time remaining computing power of the main core is insufficient to run all the application tasks to be scheduled at the same time, the application tasks to be scheduled can be scheduled and distributed to the main core in batches to ensure that the main core has sufficient computing power resources to process the task main function of the application tasks.

[0117] Under the first scheduling strategy, some slave cores may still have application tasks to execute. These cores will continue to execute the main function of the corresponding application tasks. When a core no longer has any application tasks to execute, it can be shut down, thereby further reducing the overall power consumption of the vehicle domain controller. If the task scheduling strategy changes and a slave core needs to implement a certain vehicle function to realize the user's specific business logic, these slave cores can switch back to the working state from the shut-down state.

[0118] S10232. When the second scheduling strategy is determined, the application tasks to be scheduled are sequentially scheduled to the main core or slave core with the highest real-time remaining computing power according to the time order in which the application tasks to be scheduled are generated.

[0119] Traditional scheduling methods may result in highly uneven load distribution across N cores, with some cores nearing full capacity, potentially impacting task real-time performance. The second scheduling strategy, however, reads the real-time remaining computing power of each core before scheduling application tasks, allocating tasks to the core with the lowest load and highest remaining computing power.

[0120] It should be noted that whenever an application task is scheduled and distributed to a corresponding core, the core with the highest real-time remaining computing power may change. Therefore, before each application task is scheduled, the core with the highest real-time remaining computing power will be determined first, and then the application task will be scheduled to the master core or slave core with the highest real-time remaining computing power.

[0121] S10233. When the third scheduling strategy is determined, determine the computing power difference between the task computing power data of the application task to be scheduled and the highest real-time remaining computing power.

[0122] S10234. Determine all application tasks currently running on the master core or slave core with the highest real-time remaining computing power, as well as the task computing power data of each application task. Based on the task computing power data and the computing power difference, determine the application tasks to be scheduled in the master core or slave core with the highest real-time remaining computing power.

[0123] S10235. Based on the time sequence of the application tasks to be scheduled, the application tasks to be scheduled from the main core or slave core with the highest real-time remaining computing power are sequentially scheduled to the other remaining cores.

[0124] If a computationally intensive application task suddenly appears, and the real-time remaining computing power of a single core is insufficient to meet the task's demands, then based on the third scheduling strategy, the computing power difference between the application task's task computing power data and the highest real-time remaining computing power will be calculated first. This represents the computing power resources that still need to be freed up by the core. Next, all application tasks currently running on the core with the highest real-time remaining computing power, along with the computing power data of each application task, will be determined. This will then determine which application tasks need to be scheduled to other cores. These application tasks that need to be freed up are those scheduled from the main core or slave core with the highest real-time remaining computing power. Specifically, the total computing power data of the application tasks scheduled from the main core or slave core with the highest real-time remaining computing power must not be less than the computing power difference.

[0125] By using a third scheduling strategy, some computing resources of the master or slave core with the highest real-time remaining computing power can be further released, allowing sufficient computing resources to be reserved in the master or slave core to process the application tasks to be scheduled by the master task. Subsequently, the application tasks to be scheduled in the master or slave core with the highest real-time remaining computing power can also be scheduled to other remaining cores in sequence according to the generation time order of the application tasks, such as to the core with the highest real-time remaining computing power among the remaining cores excluding the core with the highest real-time remaining computing power.

[0126] In this embodiment of the invention, assuming that an application task needs to be scheduled from one core to another for execution, the master task will first send a task scheduling instruction to the slave task of the first core. The task scheduling instruction sent to the first core instructs the first core to close the task main function corresponding to the application task, thereby closing the application task. Then, the master task sends another task scheduling instruction to the slave task of the second core. The task scheduling instruction sent to the second core instructs the second core to run the task main function corresponding to the application task, thereby running the application task.

[0127] Specifically, when the first scheduling strategy is determined, a fourth scheduling strategy can also be implemented based on the first scheduling strategy. The fourth scheduling strategy is a low-power integration scheduling strategy in low-power mode. Specifically: when the first scheduling strategy is determined, if the main task determines, based on the sum of the task computing power data of all currently running application tasks and all application tasks to be scheduled, that there is still remaining computing power when the main core runs all these application tasks, that is, when the main core runs all these application tasks, its current computing power utilization rate does not exceed a preset value, then, on the basis of scheduling and distributing all application tasks to be scheduled to the main core, the application tasks currently running on each slave core can be scheduled to the main core. This scheduling method achieves the lowest power consumption and can also change the core running the application tasks.

[0128] It should be noted that the fourth scheduling strategy can also schedule all application tasks uniformly and switch them to a specific core for execution. The specific core can be the primary core, or the primary core plus at least one other secondary core. In short, the purpose of the fourth scheduling strategy is to utilize only the specific core to execute application tasks, while other cores will remain idle.

[0129] Under the fourth scheduling strategy, all cores except for specific cores can be shut down to minimize the overall power consumption of the vehicle domain controller. If the task scheduling strategy changes and a specific vehicle function needs to be implemented from a core to fulfill the user's business logic, these cores can be switched back to the working state from the off state.

[0130] Under the first or fourth scheduling strategy, the vehicle's power management unit can be used to turn the core on and off.

[0131] In this embodiment of the invention, some application tasks frequently access shared data. Scheduling them to the same core (affinity) by the main task can utilize in-core caching to reduce IPC communication overhead. Conversely, some application tasks competing for resources may need to be distributed across different cores (exclusion). By pre-setting task affinity and / or exclusion constraint labels for each application task, the task affinity / exclusion between application tasks can be determined. If it is necessary to change the core running the application task, the above process can be followed.

[0132] In this embodiment of the invention, the main task not only schedules tasks based on the real-time remaining computing power of each core, but also combines the historical computing power consumption and triggering patterns of each application task to predict the computing power changes of each core in the near future, and performs forward scheduling to further smooth load fluctuations. Here, historical computing power consumption refers to the core computing power actually consumed by the application task during its historical execution.

[0133] Each core can also run a lightweight real-time operating system that manages the priority and resource preemption among multiple application tasks scheduled to this core.

[0134] In this embodiment of the invention, step S103 includes:

[0135] S1031, the primary core and / or secondary core obtain at least one application task scheduled by the primary task from the secondary task.

[0136] S1032. Determine whether the main function of the application task has been executed from the task.

[0137] S1033. If execution is not confirmed, the task resolution control target is determined, and the corresponding application task's main function is executed according to the application task cycle. The task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores are fed back to the main core. Specifically, the task locates the application task's main function address and input data address library, prepares the local context from the task, and jumps to the task's main function to start execution.

[0138] S1034. If it is determined that the task has been executed, the task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores are fed back to the main core.

[0139] The running flag of an application task can be used to determine whether its main function has been executed and which core has executed it. When a core executes the main function of an application task, the application task can be considered to be in a running state.

[0140] S1035. After the main task function is completed, the main task closes the main task function to clean up and release the local computing resources occupied by this run, and waits for the next application task to be scheduled and issued by the main task.

[0141] Figure 5 Another flowchart of an embodiment of the present invention is shown, the method may further include:

[0142] S201. After the vehicle domain controller is powered on, the main core starts up. The main core loads and runs the main task. This process can initialize components such as the task scheduler, IPC server, peripheral agent service, monitoring components, and local execution environment.

[0143] S202. Start each slave core. The master core and each slave core load and run their respective slave tasks, register with the master core, and report the readiness status of the slave cores. This process can also initialize components such as slave tasks, monitoring components, and local execution environments.

[0144] S203. The main kernel reads the description information of all application tasks from the configuration file and constructs a global task descriptor table based on the description information. At this time, all application tasks are in an unscheduled state.

[0145] In this embodiment of the invention, the global task descriptor table can be located in shared memory or the main core management area. Each entry in the global task descriptor table describes an application task, and each entry can contain information such as application task ID, task priority, task main function address, trigger function address, input data address library, output data address library, application task cycle, running flag bit, and task computing power data.

[0146] The initialization settings of the vehicle domain controller can be completed through steps S201 to S203.

[0147] S204. The main kernel iterates through the trigger functions of all application tasks via the main task, and determines at least one application task to be scheduled based on the trigger functions. For details, please refer to... Figure 1 As shown in step S101.

[0148] S205. The primary task running on the main core will schedule at least one application task to the main core and / or a secondary core according to the task scheduling policy. See details below. Figure 1 As shown in step S102.

[0149] S206. The main core and / or slave cores obtain at least one application task scheduled by the main task through slave tasks. The slave task executes the corresponding application task's main function according to the application task's cycle and feeds back the application task's execution status and the real-time remaining computing power of the main core and / or slave cores to the main core. For details, please refer to... Figure 1 As shown in step S103.

[0150] The following describes the multi-core-based task scheduling device provided in the embodiments of the present invention. The multi-core-based task scheduling device described below and the multi-core-based task scheduling method described above can be referred to and correspond to each other.

[0151] To address the aforementioned issues, this specification provides a multi-core-based task scheduling device designed to fully utilize the computing power of multiple cores to execute user business logic. Figure 6 This is a schematic diagram of a multi-core task scheduling device according to an embodiment of the present invention. This device is applied to a vehicle domain controller, such as... Figure 6 As shown, the device may include:

[0152] The trigger determination module 10 is used to utilize the main core and traverse the trigger functions of all application tasks through the main task to determine at least one application task to be scheduled based on the trigger functions. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is the control process of the application task and is used to control vehicle components according to task configuration parameters to achieve the control objectives of the application task.

[0153] In this embodiment of the invention, the vehicle domain controller is a multi-core MCU, which includes a master core and at least one slave core. The master core and slave cores communicate with each other via IPC. Different cores can exchange data and work collaboratively through IPC. IPC is responsible for rapidly transmitting information between different functional areas of the vehicle domain controller.

[0154] It's understandable that the master core and slave cores can have different computing power and uses. This allows each core to leverage its own computing strengths, achieving optimal task scheduling configuration, significantly improving overall performance, reducing power consumption, and simplifying development. In this case, the core with the best computing power can be used as the core of the vehicle domain controller, with the other cores serving as slave cores. If there are multiple cores with optimal computing power, or if the computing power of all cores in a multi-core MCU is equal, one of the cores with the best computing power or one of the cores with equal computing power can be used as the master core, with the other cores serving as slave cores.

[0155] This master-slave core architecture allows the vehicle domain controller's cores to be divided into master and slave cores based on their respective functions. Depending on the core structure, multiple cores can run the same or different operating systems.

[0156] In this embodiment of the invention, the main core has a relatively complex structure and function. It is responsible for the management and scheduling of global computing resources and tasks, and completes the boot loading of slave cores. Slave cores are managed by the main core and are responsible for running application tasks scheduled by the main core.

[0157] In this embodiment of the invention, the main task is the foundational task within the entire framework. As the cornerstone and manager of task scheduling, the main task runs permanently within the main kernel. It does not directly handle specific user functions but rather provides system-level services. The main task includes, but is not limited to, a lightweight operating system kernel, IPC drivers and management, centralized access agents for peripherals (such as CAN, ETH, and SPI), and, most importantly, global task scheduling. The main task is the first and continuously running task after system startup.

[0158] The main core can be responsible for distributing various application tasks, collecting the real-time remaining computing power of each core (including the main core and slave cores), collecting the internal and external status of vehicle components, and outputting task scheduling instructions through the main task running in it.

[0159] Application tasks are used to implement specific user business logic. Each application task can be designed to control a particular vehicle component, such as air conditioning control, anti-pinch windows, vehicle lights, or diagnostic processing. Application tasks are not bound to any specific core; their execution location is dynamically determined by the main task based on the task scheduling strategy. Each application task is encapsulated as an independent module with a standard interface.

[0160] By determining the computing power data for each task, the main core can pre-calculate whether the computing power allocated to the slave cores is sufficient before scheduling tasks. Suppose an application task needs to be scheduled to the slave core with the highest real-time remaining computing power. If the computing power of the slave core with the highest real-time remaining computing power is still insufficient, the main core can pre-allocate other application tasks running on the slave core with the highest real-time remaining computing power to other slave cores, releasing some computing power resources of that slave core to ensure the computing power requirements of this application task.

[0161] The task scheduling module 20 is used to utilize the main task running on the main core and to schedule at least one application task to the main core and / or the slave core according to the task scheduling policy.

[0162] In this embodiment of the invention, the main core includes and runs the following components:

[0163] Task scheduler: Responsible for maintaining a global list of schedulable application tasks and executing task scheduling strategies periodically or in an event-driven manner. The task scheduler's decision-making basis includes: real-time remaining computing power fed back from each core, task priority, affinity and / or exclusion constraints between tasks, task scheduling strategies, etc.

[0164] IPC server: Responsible for managing communication channels with all slave cores. The master core sends task data and task scheduling instructions to the target slave cores through the IPC server, and receives the task execution status and real-time remaining computing power from the slave cores.

[0165] Peripheral Proxy Service: Provides a unified and secure peripheral access interface for application tasks, avoiding multi-core contention for hardware resources.

[0166] In this embodiment of the invention, the main core is able to run the main task as the basic task through the task scheduler, IPC server and peripheral agent service.

[0167] The master and slave cores also contain and run the following components:

[0168] Slave Task: A lightweight task execution container. The slave task is mainly responsible for receiving task scheduling instructions from the master core through IPC, loading and executing the task main function of the specified application task, and feeding back information such as the slave core's real-time remaining computing power and task execution status to the master core through IPC.

[0169] Each core will run a slave task instance. Not only do slave cores need to run slave task instances, but master cores will also run slave task instances.

[0170] Monitoring component: Used to monitor and calculate the real-time remaining computing power of this core, such as by calculating the ratio of task execution time to total time over a period of time, or the ratio of CPU idle time slices.

[0171] Local execution environment: Provides the stack space, context, etc. required for application tasks to run.

[0172] In this embodiment of the invention, each core is able to run application tasks by means of tasks, monitoring components, and a local execution environment.

[0173] Whether it is a primary core or a secondary core, each core has its own core data. The core data can include data arrays generated by running application tasks, the number of application tasks running in real time, and the real-time remaining computing power.

[0174] Based on the architecture of a multi-core MCU, the clock frequency of each core may be different, and correspondingly, the theoretical maximum computing power resources of each core may also be different. Therefore, the real-time remaining computing power is the computing power resources multiplied by the current real-time remaining computing power rate.

[0175] The task execution module 30 is used to utilize the main core and / or the slave core and obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task cycle, and feeds back the task execution status of the application task and the real-time remaining computing power of the main core and / or the slave core to the main core.

[0176] In this embodiment of the invention, both the main core and the slave core can obtain application tasks scheduled and issued by the main core through the main task. Simultaneously, the main task can schedule multiple application tasks to a single core for execution. After the main core and / or the slave core obtain at least one application task through the slave task, the slave task of the main core and / or the slave core will execute the corresponding application task's main function according to the application task's cycle, for example, 1ms. Since the main function is the control process of the application task, when the main function is executed by the core, it can control vehicle components such as compressors, dampers, and blowers according to the task configuration parameters to achieve the control target and thus realize the application task.

[0177] The core execution of the main function is the execution of the control process or function calculation process mentioned above. Executing the main function requires a lot of computing resources, and the execution of the main function is the process that consumes the most computing resources in the entire application task. In contrast, the execution of the trigger function is the triggering process of the application task, which consumes relatively less computing resources.

[0178] In this embodiment of the invention, the application task is separated into a trigger function and a task main function that are executed independently, instead of using a single function to implement the application task. This loosely coupled task scheduling method separates the process of the application task that consumes the most computing resources, namely the task main function. At the same time, the process that consumes the most computing resources can be dynamically decided by the main core based on the trigger function and dynamically scheduled by the main task, reducing unnecessary computing power consumption.

[0179] The multi-core-based task scheduling device of the present invention determines the application tasks to be scheduled by traversing the trigger functions of each application task through the main task of the main core. Then, the main task schedules the application tasks to be scheduled and distributes them to each core through global dynamic scheduling. This breaks down the computing power barriers between cores and realizes global management of computing power resources of the vehicle domain controller. This task scheduling method does not require the separate reservation of computing power resources for each core, thereby greatly reducing the computing power waste caused by static reservation. It enables more complex application tasks to be carried under the same hardware configuration, and reduces the requirements for the number of cores and performance while meeting the same needs, thereby improving the utilization rate of core computing power and saving costs. The main task, slave tasks, and application tasks are decoupled. The main task in the vehicle domain controller manages the core computing resources and schedules application tasks. Slave tasks execute the most computationally intensive processes within application tasks, while application tasks implement the user's specific business logic. This decoupled, loosely coupled task scheduling approach separates the most computationally intensive processes (i.e., the main function) from the application tasks. These processes can be dynamically scheduled by the main core based on trigger functions, reducing unnecessary computational consumption. The main task schedules tasks based on real-time computing power feedback from each core, automatically allocating new application tasks to the most idle core. This fully utilizes multi-core computing power to execute user business logic, improving overall system throughput, reducing worst-case execution time, and enhancing real-time performance. Furthermore, the decoupling of application tasks from physical cores means they are not bound to any specific core, eliminating the need for software architecture refactoring during scheduling and significantly reducing development and maintenance complexity.

[0180] Figure 7 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 7As shown, the electronic device may include: a processor 710, a communication interface 720, a memory 730, and a communication bus 740, wherein the processor 710, the communication interface 720, and the memory 730 communicate with each other through the communication bus 740. The processor 710 can call logical commands from the memory 730 to execute a multi-core-based task scheduling method applied to a vehicle domain controller consisting of one master core and at least one slave core. This method includes:

[0181] The main core iterates through the trigger functions of all application tasks through the main task, and determines at least one application task to be scheduled based on the trigger function. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters.

[0182] The primary task schedules at least one application task to the primary core and / or the secondary core according to the task scheduling policy.

[0183] The main core and / or slave cores obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task's cycle and feeds back the application task's execution status and the real-time remaining computing power of the main core and / or slave core to the main core.

[0184] Furthermore, the logical instructions in the aforementioned memory 730 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0185] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, wherein when the program instructions are executed by a computer, the computer is able to execute the multi-core-based task scheduling method provided by the above methods, applied to a vehicle domain controller consisting of a master core and at least one slave core, the method comprising:

[0186] The main core iterates through the trigger functions of all application tasks through the main task, and determines at least one application task to be scheduled based on the trigger function. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters.

[0187] The primary task schedules at least one application task to the primary core and / or the secondary core according to the task scheduling policy.

[0188] The main core and / or slave cores obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task's cycle and feeds back the application task's execution status and the real-time remaining computing power of the main core and / or slave core to the main core.

[0189] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is implemented to perform the aforementioned multi-core-based task scheduling methods, applied to a vehicle domain controller consisting of a master core and at least one slave core, the method comprising:

[0190] The main core iterates through the trigger functions of all application tasks through the main task, and determines at least one application task to be scheduled based on the trigger function. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters.

[0191] The primary task schedules at least one application task to the primary core and / or the secondary core according to the task scheduling policy.

[0192] The main core and / or slave cores obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task's cycle and feeds back the application task's execution status and the real-time remaining computing power of the main core and / or slave core to the main core.

[0193] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0194] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0195] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-core-based task scheduling method, characterized in that, Applied to a vehicle domain controller consisting of a master core and at least one slave core, the method includes: The main core iterates through the trigger functions of all application tasks through the main task, and determines at least one application task to be scheduled based on the trigger function. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters. The primary task schedules at least one application task to the primary core and / or the secondary core according to the task scheduling policy. The main core and / or slave core obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task's cycle and feeds back the application task's execution status and the real-time remaining computing power of the main core and / or slave core to the main core. The main core iterates through the trigger functions of all application tasks by the main task, and determines at least one application task to be scheduled based on the trigger functions, specifically including: The main core obtains the user's task execution request through the main task, parses the task execution request, and determines all application tasks and the target state of the application tasks. The main core iterates through the trigger functions of all application tasks through the main task; the trigger function determines the control target of the application task based on internal and external dependencies and the target state, determines the current state of the application task, and determines whether to trigger the application task based on the difference between the current state and the control target. If the difference in the feedback from the trigger function exceeds a preset threshold, the corresponding application task will be identified as an application task to be scheduled. If the difference in the feedback from the trigger function does not exceed a preset threshold and the corresponding main task function has already run, a task scheduling instruction to shut down the application task is sent to the main core and / or slave core running the corresponding application task; the slave task shuts down the corresponding main task function according to the task scheduling instruction, thereby shutting down the application task. The primary task schedules at least one application task to the primary core and / or secondary core according to the task scheduling policy, specifically including: The main task acquires the real-time remaining computing power of all cores and determines the task computing power data of each application task to be scheduled; the task computing power data is the maximum computing power resources occupied by the application task. Determine the task scheduling strategy based on unscheduled application tasks and vehicle status; For each application task to be scheduled, the application task to be scheduled is scheduled and distributed to the main core and / or the slave core according to the real-time remaining computing power and the task scheduling policy.

2. The multi-core-based task scheduling method according to claim 1, characterized in that, For each application task to be scheduled, the application task to be scheduled is scheduled and distributed to the main core and / or slave cores according to the real-time remaining computing power and the task scheduling policy, specifically including: If the primary scheduling strategy is determined, all application tasks to be scheduled will be scheduled and distributed to the main core. When the second scheduling strategy is determined, the application tasks to be scheduled are sequentially scheduled to the main core or slave core with the highest real-time remaining computing power according to the time order in which the application tasks to be scheduled are generated.

3. The multi-core-based task scheduling method according to claim 1, characterized in that, For each application task to be scheduled, the application task to be scheduled is scheduled and distributed to the main core and / or slave cores according to the real-time remaining computing power and the task scheduling policy, specifically including: When the third scheduling strategy is determined, the computing power difference between the task computing power data of the application task to be scheduled and the highest real-time remaining computing power is determined. Determine all application tasks currently running on the master core or slave core with the highest real-time remaining computing power, as well as the task computing power data of each application task. Based on the task computing power data and the computing power difference, determine the application tasks to be scheduled in the master core or slave core with the highest real-time remaining computing power. Based on the generation time order of the application tasks to be scheduled, the application tasks to be scheduled from the main core or slave core with the highest real-time remaining computing power are sequentially scheduled to the other remaining cores; the total computing power data of the application tasks to be scheduled from the main core or slave core with the highest real-time remaining computing power is not less than the computing power difference.

4. The multi-core-based task scheduling method according to claim 1, characterized in that, The main core and / or slave cores obtain at least one application task scheduled by the main task from the slave task. The slave task executes the corresponding application task's main function according to the application task's cycle, and feeds back the task execution status of the application task and the real-time remaining computing power of the main core and / or slave core to the main core. Specifically, this includes: The primary core and / or secondary core obtain at least one application task scheduled by the primary task from the task; Determine whether the main function of the application task has been executed from the task description. If it is determined that the task has not been executed, the task parsing control target is used to execute the corresponding application task's main function according to the application task cycle, and the task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores are fed back to the main core; the task location is used to locate the application task's main function address and input data address library, the task prepares the local context and jumps to the task main function to start execution, and thus runs the task main function; Once it is determined that the task has been executed, the task execution status of the application task and the real-time remaining computing power of the main core and / or slave cores will be fed back to the main core. After the main task function has finished executing, the main task closes the main task function.

5. The multi-core-based task scheduling method according to claim 1, characterized in that, The method further includes, before the main core iterates through the trigger functions of all application tasks via the main task and determines at least one application task to be scheduled based on the trigger functions: The main kernel starts up, and the main kernel loads and runs the main task. Start each slave core, and the master core and each slave core load and run their respective slave tasks, register with the master core, and report the readiness status of the slave cores; The main kernel reads the description information of all application tasks from the configuration file and constructs a global task descriptor table based on the description information.

6. A multi-core-based task scheduling device, characterized in that, An application to a vehicle domain controller consisting of a master core and at least one slave core, the device comprising: The trigger determination module is used to utilize the main core and traverse the trigger functions of all application tasks through the main task to determine at least one application task to be scheduled based on the trigger functions. Each application task has its corresponding trigger function and task main function. The trigger function is determined based on the internal and external dependencies of the application task and is used to indicate whether the application task needs to be triggered. The task main function is used to control vehicle components to achieve the control objectives of the application task according to the task configuration parameters. The task scheduling module is used to schedule at least one application task to the main core and / or the slave core using the main task and according to the task scheduling policy. The task execution module is used to utilize the main core and / or the slave core and obtain at least one application task scheduled by the main task through the slave task. The slave task executes the corresponding application task's main function according to the application task cycle, and feeds back the task execution status of the application task and the real-time remaining computing power of the main core and / or the slave core to the main core. The trigger determination module specifically includes: The main core obtains the user's task execution request through the main task, parses the task execution request, and determines all application tasks and the target state of the application tasks. The main core iterates through the trigger functions of all application tasks through the main task; the trigger function determines the control target of the application task based on internal and external dependencies and the target state, determines the current state of the application task, and determines whether to trigger the application task based on the difference between the current state and the control target. If the difference in the feedback from the trigger function exceeds a preset threshold, the corresponding application task will be identified as an application task to be scheduled. If the difference in the feedback from the trigger function does not exceed a preset threshold and the corresponding main task function has already run, a task scheduling instruction to shut down the application task is sent to the main core and / or slave core running the corresponding application task; the slave task shuts down the corresponding main task function according to the task scheduling instruction, thereby shutting down the application task. The task scheduling module specifically includes: The main task acquires the real-time remaining computing power of all cores and determines the task computing power data of each application task to be scheduled; the task computing power data is the maximum computing power resources occupied by the application task. Determine the task scheduling strategy based on unscheduled application tasks and vehicle status; For each application task to be scheduled, the application task to be scheduled is scheduled and distributed to the main core and / or the slave core according to the real-time remaining computing power and the task scheduling policy.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the multi-core-based task scheduling method as described in any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-core-based task scheduling method as described in any one of claims 1 to 5.

Images