Task scheduling method, device and system, vehicle and readable storage medium

Abstract

This application relates to the field of vehicle-mounted task scheduling technology, and discloses a task scheduling method, apparatus, system, vehicle, and readable storage medium. It addresses the problems of response delays, resource conflicts, and execution blocking inherent in existing static scheduling methods, which are prone to issues such as multi-task concurrency, platform resource fluctuations, and complex task dependencies in vehicle-mounted systems. The method includes: obtaining the task category of each task in the vehicle-mounted system, including periodic tasks, event-triggered tasks, and logically dependent tasks; constructing a task scheduling table based on task category, including task priority, task resource requirements, task dependencies, and task identifiers; acquiring real-time resource status information of the vehicle-mounted system; and determining whether to add the task to a thread pool for execution based on the task information and resource status information in the task scheduling table. This method combines task attributes with real-time resource status for dynamic scheduling, improving task execution determinism and enhancing the operational stability of the vehicle-mounted system.

Description

Technical Field

[0001] This invention relates to the field of vehicle technology, and more specifically to a task scheduling method, apparatus, system, vehicle, and readable storage medium. Background Technology

[0002] With the development of new energy vehicles and intelligent driving, in-vehicle systems typically use platforms such as Linux, Android, and microcontroller units (MCUs) to perform various tasks, including periodic, event-triggered, and logic-dependent tasks.

[0003] However, existing methods mostly employ static time-triggered or fixed-period scheduling, which are difficult to adapt to real-time fluctuations in resources such as the Central Processing Unit (CPU), memory, and input / output (IO), and also lack continuous monitoring of task execution status. When timeouts, incomplete dependencies, or uneven load distribution between platforms occur, scheduling conflicts, task blocking, and resource contention are likely to occur, affecting execution determinism.

[0004] Therefore, it is necessary to address how to improve the determinism and stability of vehicle-mounted task scheduling in dynamic resource and cross-platform environments. Summary of the Invention

[0005] One objective of this invention is to provide a task scheduling method to improve the determinism and stability of vehicle-mounted task scheduling; a second objective is to provide a task scheduling device; a third objective is to provide a task scheduling system function; a fourth objective is to provide a vehicle; and a fifth objective is to provide a computer-readable storage medium.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A task scheduling method, comprising:

[0008] Obtain the task category for each task in the vehicle system, including periodic tasks, event-triggered tasks, and logically dependent tasks;

[0009] Based on the task category, obtain the task information for each task, which includes task priority, task resource requirements, task dependencies, and task identifier.

[0010] Based on the task information of each task, a task scheduling table for the vehicle system is constructed;

[0011] Real-time acquisition of resource status information of the vehicle system;

[0012] Based on the task information of each task in the task scheduling table and the resource status information, it is determined whether the task should be added to the thread pool for execution.

[0013] A task scheduling device, comprising:

[0014] The category acquisition module is used to acquire the task category of each task in the vehicle system. The task categories include periodic tasks, event-triggered tasks, and logically dependent tasks.

[0015] The information acquisition module is used to acquire task information for each task based on the task category. The task information includes task priority, task resource requirements, task dependencies, and task identifier.

[0016] The construction module is used to construct the task scheduling table of the vehicle system based on the task information of each task;

[0017] The real-time acquisition module is used to acquire the resource status information of the vehicle system in real time.

[0018] The task scheduling module is used to determine whether to add the task to the thread pool for execution based on the task information of each task in the task scheduling table and the resource status information.

[0019] A task scheduling system, comprising:

[0020] The resource acquisition component is used to acquire the resource status information of the vehicle system in real time, as well as the task information of each task in the vehicle system. The task information is used to generate a task scheduling table.

[0021] A task scheduling component is used to determine whether to schedule the task to a thread pool for execution based on the task scheduling table and the resource status information.

[0022] The task monitoring component is used to monitor the execution status of each task during execution and feed it back to the task scheduling component so that the task scheduling component can reschedule the tasks.

[0023] A vehicle includes: a vehicle body, a memory, and a processor;

[0024] The memory stores computer-executed instructions;

[0025] The processor executes the computer execution instructions stored in the memory, causing the processor to perform the above-described task scheduling method.

[0026] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described task scheduling method.

[0027] The beneficial effects of this invention are:

[0028] (1) Based on real-time resource acquisition and task classification rules, this invention enables the vehicle system to achieve deterministic task scheduling in a dynamic resource environment, avoiding task delays or failures caused by resource contention, thereby improving the functional safety and real-time performance of the vehicle system.

[0029] (2) The present invention detects task anomalies (such as timeouts and dependency failures) in real time through a health monitoring component and triggers scheduling strategy adjustments (such as task migration and re-injection into the thread pool) to ensure that the system can maintain the determinism of task execution in abnormal scenarios.

[0030] (3) Through the service-oriented architecture (SOA) service interface, the task scheduling coordination of Linux, Android and Electronic Control Unit (ECU) platforms is realized, and high-priority tasks are dynamically migrated to platforms with sufficient resources for execution (such as Android tasks being migrated to Linux platforms), thereby improving resource utilization and overall system stability. Attached Figure Description

[0031] Figure 1 A flowchart of a task scheduling method provided in an embodiment of this application;

[0032] Figure 2 Deployment diagram of the task scheduling deterministic framework provided in the embodiments of this application;

[0033] Figure 3 A flowchart of periodic task scheduling provided for embodiments of this application;

[0034] Figure 4 This is a flowchart of an event-triggered task scheduling provided in an embodiment of this application;

[0035] Figure 5 A flowchart of logically dependent task scheduling provided for embodiments of this application;

[0036] Figure 6 This application provides an overall flowchart of task scheduling for its embodiments.

[0037] Figure 7 This is a schematic diagram of the vehicle business data flow provided in an embodiment of this application;

[0038] Figure 8 This is a schematic diagram of the task scheduling device structure provided in the embodiments of this application;

[0039] Figure 9 This is a structural diagram of the vehicle provided in this application. Detailed Implementation

[0040] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0041] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0042] With the rapid development of new energy vehicles, smart cockpits, and driver assistance technologies, the in-vehicle electronic and electrical architecture is gradually evolving from traditional distributed control to multi-computing platform collaboration. In this scenario, the in-vehicle system typically deploys a Linux platform, an Android cockpit platform, and a microcontroller unit (MCU) or electronic control unit (ECU) platform, respectively undertaking functions such as driver assistance perception and decision-making, in-vehicle multimedia and human-machine interaction, chassis control and power management.

[0043] Because the types of tasks in a vehicle are highly diverse, including periodic tasks such as chassis control, status refresh, and sensor sampling that are executed at fixed intervals, as well as event-triggered tasks triggered by user operations, external signals, or safety events, and logically dependent tasks that are completed step by step based on preconditions, the vehicle system needs to handle tasks with different priorities, different resource requirements, and different execution constraints simultaneously under a unified scheduling framework.

[0044] At the same time, there are also heterogeneous resources within the various platforms of the vehicle system, such as the central processing unit (CPU), memory, input / output (IO), and graphics processing unit (GPU). Furthermore, there are significant differences in resource usage patterns and real-time requirements between different platforms. This means that task scheduling must not only consider the execution order within a single platform but also take into account the collaborative relationships between cross-platforms.

[0045] During the operation of a vehicle, the in-vehicle system often faces complex operating states such as navigation planning, voice interaction, autonomous driving decision-making, over-the-air (OTA) upgrades, and sleep / wake-up. Therefore, the task scheduling scenario has obvious dynamism, concurrency and security sensitivity, which puts forward high requirements for execution determinism.

[0046] In related technologies, vehicle task scheduling schemes often employ static time-triggered, fixed-priority queues, or periodic polling methods for management. Typically, task categories, execution cycles, and scheduling orders are pre-configured during the task design phase, and execution simply follows predetermined rules. This approach can meet basic needs when the number of tasks is small and resource load is relatively stable. However, in real-world vehicle environments, platform load fluctuates frequently due to multimedia playback, graphics rendering, network communication, map updates, or background service loading. Fixed scheduling strategies struggle to detect resource changes in a timely manner and cannot dynamically adjust based on task priority and resource usage. Especially when periodic tasks and event-triggered tasks simultaneously compete for CPU resources, static strategies often rely on pre-set priorities for coarse-grained arbitration. This can easily lead to high-priority tasks being squeezed out of their execution windows by low-priority tasks, or multiple tasks queuing simultaneously when resources are insufficient, resulting in execution jitter, response latency, and task blocking. Furthermore, for logically dependent tasks, if a preceding task has not yet completed, subsequent tasks may still be scheduled prematurely due to a lack of fine-grained dependency judgment, leading to execution failures or repeated retries, increasing system burden.

[0047] Furthermore, these related technical solutions lack the ability to continuously monitor task execution status. Once a task times out, lags, or has abnormal dependencies, the scheduler typically cannot identify the source of the anomaly and adjust the scheduling queue in a timely manner, which may ultimately cause local anomalies to spread into overall scheduling imbalance. In cross-platform scenarios, task scheduling between Linux, Android, and ECUs is independent, making it difficult to unify and aggregate resource information and share task status synchronously. This results in idle resources on other platforms not being effectively utilized when resources on one platform are strained, highlighting the fragmentation of resource utilization and further amplifying the uncertainty of task execution and functional safety risks.

[0048] In view of this, how to achieve task execution category identification, task information aggregation, scheduling table construction, resource status awareness, and dynamic judgment of whether a task has entered the thread pool to wait for execution in the multi-tasking, multi-platform, and dynamic resource fluctuation environment of the vehicle system is an urgent technical problem to be solved.

[0049] To address the aforementioned issues, this application proposes a task scheduling scheme. First, it obtains the task category for each task in the vehicle system and, based on the task category, acquires task information such as task priority, resource requirements, dependencies, and task identifiers. Then, it constructs a unified task scheduling table based on this information. Next, it acquires the resource status information of the vehicle system in real time. Finally, based on the task information and resource status information of each task in the task scheduling table, it determines whether to add the task to the thread pool for execution. This approach, which links task category with resource status, transforms the task scheduling process from static preset to dynamic decision-making based on task attributes and real-time resource conditions. This provides a foundation for subsequent deterministic execution of vehicle tasks, mitigation of resource conflicts, and stable scheduling in complex scenarios.

[0050] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0051] Figure 1 This is a flowchart of a task scheduling method provided in an embodiment of this application. This method can be executed by the aforementioned vehicle-mounted system. Figure 1 As shown, the method specifically includes:

[0052] Step 110: Obtain the task category for each task in the vehicle system; the task categories include periodic tasks, event-triggered tasks, and logically dependent tasks;

[0053] Step 120: Based on the task category, obtain the task information for each task; the task information includes task priority, task resource requirements, task dependencies, and task identifier;

[0054] Step 130: Based on the task information of each task, construct the task scheduling table of the vehicle system;

[0055] Step 140: Obtain real-time resource status information of the vehicle system;

[0056] Step 150: Based on the task information and resource status information of each task in the task scheduling table, determine whether to add the task to the thread pool for execution.

[0057] Regarding step 110 above, the vehicle system is the main body for executing the task scheduling method, and is used to carry out task execution, resource management and cross-platform collaborative scheduling. Specifically, it may include heterogeneous execution platforms such as electronic control units, Android cockpit platforms and Linux assisted driving platforms.

[0058] Task categories are used to classify tasks in the vehicle system. Their purpose is to distinguish the scheduling rules applicable to different tasks so that they can be uniformly scheduled according to different task scheduling strategies in the future.

[0059] Periodic tasks refer to tasks that are repeatedly executed at fixed time intervals, corresponding to services with defined execution rhythm requirements such as chassis control, status refresh, sensor sampling, and heartbeat detection. Event-triggered tasks are tasks that are initiated only after an external event, system message, user operation, or status change occurs, corresponding to services such as voice wake-up, user click response, emergency braking signal processing, and fault alarm processing. Logically dependent tasks are tasks that require the completion of prerequisite tasks to be met before execution, corresponding to services such as software initialization chains, navigation planning after map loading, and fusion calculation after sensor calibration.

[0060] In one specific implementation, the task scheduling component reads the task registry, service description file, task configuration file, or task description data generated by the Service-Oriented Architecture (SOA) service toolchain during the system startup phase, and classifies and identifies the execution modes of each task.

[0061] Specifically, for tasks with a fixed period field, a timer trigger field, or a periodic scheduling flag, the scheduling component identifies them as periodic tasks; for tasks containing an event source identifier, a message bus subscription relationship, an interrupt trigger flag, or a user interaction trigger condition, the scheduling component identifies them as event-triggered tasks; and for tasks containing a list of preceding tasks, a dependency completion flag, a dependency state machine, or a task chain node relationship, the scheduling component identifies them as logically dependent tasks.

[0062] To adapt to heterogeneous multi-platform environments, tasks on the Linux platform can be obtained by scanning the service registry through daemons; tasks on the Android platform can be extracted from the service manager, message queue, or component manifest in the application framework; and tasks on the ECU platform can be extracted from the Automotive Open System Architecture (AUTOSAR) task configuration or static scheduling configuration file. Thus, tasks scattered across different platforms are unified into a single scheduling semantic system.

[0063] In another implementation, task category acquisition can be modified by combining runtime behavioral characteristics. For example, after the initial classification, the scheduling component continues to monitor the task's trigger timestamp, call source, dependency wake-up relationship, and execution history. When it finds that a task, although configured with an event entry, exhibits a fixed-cycle triggering characteristic over a long period, it can be marked as an event-triggered task with periodic attributes. When a task, although triggered by an event, always depends on the results of previous processing before execution, it can be marked as an event-triggered task with logical dependency attributes.

[0064] Through the task classification process in step 110, the task execution patterns in the vehicle system can be abstracted first, and then tasks from different platforms and business sources can be merged into a unified category set. This provides a consistent data entry point for the subsequent structured extraction of task information and the construction of a unified scheduling table. In addition, it can also enable the originally discrete, heterogeneous, and difficult-to-manage vehicle tasks to form clear type boundaries in the early stage of scheduling. This can reduce the misscheduling problem caused by inaccurate task category identification in subsequent scheduling decisions, and lay the foundation for the temporal stability of periodic tasks, the timely response of event-triggered tasks, and the correct order of logically dependent tasks.

[0065] Regarding step 120 above, task information is a set of attributes required for a single task to participate in scheduling, which is used to provide a basis for constructing the task scheduling table and subsequent resource arbitration.

[0066] Task priority is used to indicate the execution order of tasks in scheduling, so as to ensure that high-importance tasks get resources and execution opportunities first.

[0067] Task resource requirements represent the system resources required for task execution, which may include CPU time slice requirements, memory usage, I / O bandwidth requirements, graphics processor usage, or bus access usage.

[0068] Task dependencies are used to describe the sequential constraints between tasks, such as prerequisite task identifiers, dependency completion conditions, dependency chain hierarchy, or state transition conditions.

[0069] A task identifier is used to uniquely identify a task. It can be a task ID, service name, process thread combination number, functional module number, or a cross-platform unified global task code.

[0070] In one specific implementation, after completing task category identification, the task scheduling component invokes different information extraction rules according to the task category.

[0071] For periodic tasks, the focus is on extracting the period length, maximum execution time, and CPU budget within the period, and generating corresponding priorities based on the task's functional domain and security level. For event-triggered tasks, the focus is on extracting the event source type, maximum response latency, allowed concurrent instance count, and peak resource requirements, and determining priorities based on the event's security impact level, user awareness, and urgency. Finally, for logically dependent tasks, the focus is on extracting the list of preceding tasks, dependency completion criteria, and hierarchical relationships, while determining the task's execution position in the dependency chain and its required resource quota.

[0072] For example, the chassis torque control task can be assigned a higher priority and a stricter CPU budget, the voice broadcast refresh task can be configured with a medium priority and moderate memory and I / O requirements, and the map route recalculation task can be triggered after the location update and map data loading tasks are completed, and the corresponding CPU and memory requirements can be configured.

[0073] Furthermore, task priorities can be divided into several levels. For example, high-level priorities correspond to security control, fault handling, and real-time awareness tasks; medium-level priorities correspond to user interaction and critical business collaboration tasks; and low-level priorities correspond to log uploading, background cleanup, and non-real-time update tasks. Task resource requirements can be formed by a combination of static configuration and dynamic learning. The static part comes from the quota declaration during the task design phase, while the dynamic part comes from historical execution statistics, such as average CPU utilization, peak memory consumption, average I / O bandwidth usage, and GPU utilization. The scheduling component can integrate static requirements with historical statistics according to weights to form an estimated resource requirement value for the current task, thereby improving the accuracy of scheduling decisions.

[0074] In another implementation, task dependencies can be organized as a directed graph structure. Each task node records the set of predecessor nodes, the set of successor nodes, a dependency completion flag, and anomaly dependency status. When a predecessor task completes, the scheduling component updates the dependency count of its successor tasks. When the dependency count reaches zero and other admission conditions are met, the successor task enters the schedulable state. The task identifier is written as an index key into a unified index table to support fast task lookup, status updates, migration records, and anomaly location.

[0075] Regarding step 130 above, the task scheduling table is a data structure that records task scheduling rules and task attributes, providing a unified data foundation for subsequent scheduling decisions. The task scheduling table records at least the task category, task priority, task resource requirements, task dependencies, and task identifier, and can further record extended fields such as execution status, thread pool mapping, resource reservation, most recent scheduling time, allowed waiting time, historical failure count, and exception flags. By constructing the task scheduling table, task information scattered across different platforms, modules, and description files can be transformed into a unified data view that the scheduling engine can directly read and update.

[0076] For example, Table 1 is a task scheduling table provided in an embodiment of this application, as follows:

[0077] Table 1

[0078]

[0079] In one implementation, the task scheduling table is initially generated automatically by the SOA service-oriented toolchain during the compilation and deployment phase. After system startup, the scheduling component performs secondary adjustments based on the actual platform capabilities, the current software version, and the available thread pool capacity. For example, when a platform does not currently have its GPU acceleration module enabled, GPU-related resource fields can be set to zero or marked as unavailable; when the maximum concurrency of a thread pool changes, the thread pool mapping parameters in the scheduling table are updated synchronously. For cross-platform collaborative tasks, a platform affiliation field, a cross-platform synchronization flag, and a remote dependency status field can be added to the scheduling table to support information linkage between tasks on different execution platforms.

[0080] Regarding step 140, the resource status information is used to reflect the real-time status of the current resource availability of the vehicle system, and is the direct basis for determining whether the task has the conditions for execution.

[0081] For example, resource status information may include CPU utilization, CPU idle rate, core usage distribution, memory usage, available memory, I / O bandwidth usage, disk or flash access latency, GPU usage, bus load, network bandwidth, thread pool queue length, and number of active threads in the thread pool. The focus of resource status information collection may differ for different platforms within an in-vehicle system. For instance, Linux-based driver assistance platforms may prioritize CPU, GPU, and large memory consumption; Android cockpit platforms may focus on graphics rendering, audio / video I / O, and user interaction thread load; and ECU platforms may prioritize CPU availability for critical control tasks, interrupt response usage, and bus communication load.

[0082] Regarding step 150, a thread pool is a pre-created and reusable set of execution threads used to handle scheduled tasks and improve task execution efficiency. Thread pools can be categorized by task type into periodic thread pools, event-driven thread pools, and logic-driven thread pools. Once a task meets the scheduling conditions, it is placed into the corresponding thread pool to await execution.

[0083] The process of placing a task into the thread pool for execution is essentially a process of admission judgment and queuing control based on task information and resource status information. This process directly determines when a task is eligible to be executed and which execution channel it enters.

[0084] The task scheduling method provided in this application first abstracts task categories, then extracts task priorities, resource requirements, dependencies, and task identifiers in a structured manner, and performs dynamic admission judgment by combining a unified scheduling table with real-time resource status. This transforms the scheduling process from static preset rules to a linkage control process oriented towards task attributes and resource changes. Therefore, in a heterogeneous in-vehicle environment where Linux, Android, and ECU platforms coexist, it can provide stable cycle time guarantees for periodic tasks, timely response paths for event-triggered tasks, and the prerequisite for correct execution order for logically dependent tasks, while maintaining high scheduling determinism and resource utilization efficiency under resource fluctuations and complex operating conditions.

[0085] Figure 2 The deployment diagram of the task scheduling deterministic framework provided in the embodiments of this application is as follows: Figure 2 As shown, it includes three components: the deterministic task scheduling component SWC_DTSF; the system resource acquisition component SWC_RCC; and the task health monitoring component SWC_THM.

[0086] The resource acquisition component SWC_RCC is used to acquire real-time resource status information of the vehicle system, as well as task information for each task within the system. This task information is used to generate a task scheduling table. The deterministic task scheduling component SWC_DTSF, which can be simply referred to as the task scheduling component, determines whether to schedule a task to the thread pool for execution based on the task scheduling table and resource status information. The task health monitoring component SWC_THM, which can be simply referred to as the task monitoring component, monitors the execution status of each task and feeds it back to the task scheduling component so that the task scheduling component can reschedule tasks.

[0087] The SWC_DTSF component's main function is to provide three deterministic scheduling strategies for three abstract task types: periodic tasks, event-triggered tasks, and logically dependent tasks: periodic scheduling, one-off scheduling, and logical scheduling. These three strategies, combined with SOA service architecture (where communication protocols are not limited to some / IP or DDS), automatically generate corresponding code to adapt to the three scheduling strategies, enabling rapid adaptation to meet the requirements of iterative engineering development while achieving millisecond-level deterministic scheduling. On Linux, it can support deterministic vehicle control tasks at the 5-millisecond or 10-millisecond level, thus meeting the functional safety ASIL-B requirements.

[0088] When performing deterministic task scheduling, the SWC_DTSF component arbitrates and adapts three scheduling strategies based on the current resource status of the system. This means simultaneously considering the task's execution time, the state of the onboard platform, the CPU, memory, and I / O resources required by the task, and the existing CPU, memory, and I / O resources and their current state on the onboard platform. After arbitration, a decision is made on whether to include the task in the scheduling queue for execution. This ensures the stability and determinism of task execution.

[0089] The SWC_DTSF component develops a corresponding task health monitoring component, SWC_THM, in the deterministic scheduling management of task execution. When various "abnormal scenarios" occur in the vehicle system, affecting the determinism of task execution, such as the number of CPUs, the current platform status, and the worst-case time required for the task to be executed, the corresponding scheduling and operation monitoring management component ensures the determinism of task execution.

[0090] The main function of the SWC_RCC component is to collect various resources related to deterministic scheduling execution, such as CPU, memory, and I / O, at the current system moment. This includes collecting not only the resources of the vehicle system platform itself, but also the resources of the tasks being deterministically scheduled. The tasks require detailed information down to the thread level and are sent to the SWC_DTSF component via SOA service-oriented interface calls.

[0091] The main function of the SWC_THM component is to handle three types of monitoring based on three scheduling strategies: periodic scheduling monitoring (e.g., heartbeat monitoring of task execution at intervals of 5 milliseconds), one-off scheduling monitoring (monitoring the start and end of one-off task execution), and logical scheduling monitoring (where the deterministic execution of the current task depends on the completion of one or more preceding tasks, and subsequent tasks are executed only after the current task has finished). The scheduled tasks send their running information to the SWC_THM component through the code interface generated by SOA service-oriented architecture. The SWC_THM component then judges the information and sends it to the SWC_DTSF component through the SOA service-oriented interface call.

[0092] This deterministic scheduling framework not only solves the deterministic task scheduling problem of the current platform itself, but also solves the deterministic scheduling problem of tasks on the vehicle's ECU and the Android platform for user interaction. Because the computing power of the vehicle's ECU is low and limited, and there are functional safety requirements for deterministic scheduling when the ECU has a large number of computing-intensive tasks; when the vehicle's Android platform has tasks that call on underlying GPUs and other resources; or when Android interaction needs to be lightweight, considering overall cost and engineering, a large number of tasks can be transferred to the Linux platform for deterministic scheduling and execution.

[0093] This deterministic scheduling framework addresses scenarios where tasks on an in-vehicle system are scheduled at a predetermined time, and where tasks experience "lag," triggering anomalies, or logical dependency anomalies during execution within a predetermined timeframe; as well as scenarios where the vehicle control ECU and Android platform perform deterministic scheduling tasks. This ensures the stable operation of the in-vehicle system platform, meets the requirements of in-vehicle functional safety, and thus guarantees in-vehicle safety.

[0094] Based on this, in some embodiments, the task scheduling policy corresponding to each task category can be obtained; then, based on the task scheduling policy and the task information corresponding to the task in that task category, it can be determined whether the resource status information meets the task requirements; if the resource status information meets the task requirements, the task is put into the thread pool to wait for execution.

[0095] In this embodiment, the task scheduling strategy is a pre-defined scheduling rule for different types of tasks, used to limit the judgment conditions and execution order before tasks enter the thread pool. Resource status information is used to characterize the availability of resources such as CPU, memory, IO, or GPU in the vehicle system. Task requirements are composed of task resource requirements, task priority requirements, and task dependencies.

[0096] In practical applications, the scheduling component reads the task category from the task scheduling table and maps periodic tasks, event-triggered tasks, and logically dependent tasks to periodic scheduling policies, one-off scheduling policies, and logically dependent scheduling policies, respectively. Scheduling policies can be preset in the task configuration file, written into the scheduling table by the SOA service-oriented toolchain, and can also be modified by the scheduling component during runtime based on historical task execution records to ensure consistent admission rules for similar tasks.

[0097] After obtaining the task scheduling policy, the scheduling component matches and judges resource status information based on task priority, task resource requirements, task dependencies, and task identifier. For periodic tasks, it compares whether the current idle CPU, available memory, and I / O margin have simultaneously reached the threshold based on their execution cycle and resource budget. For event-triggered tasks, the system determines whether resources are sufficient to support immediate execution based on trigger urgency and priority thresholds. For logically dependent tasks, the system first confirms the completion status of the preceding tasks and then determines whether to allow them to be added to the pool based on the current resource margin. If any resource indicator is lower than the task requirement, the scheduling component keeps the task in the pending scheduling state and continues to monitor resource changes.

[0098] When the resource status information meets the task requirements, the scheduling component writes the corresponding task into the waiting queue of the thread pool and records the entry time, target thread pool type and queue number.

[0099] This application embodiment clarifies the scheduling basis of different types of tasks to specific strategies and resource thresholds. Resource status judgment no longer relies on a single static priority, but is matched in coordination with task requirements. Therefore, it can improve the scheduling determinism, resource utilization efficiency and execution stability of the vehicle system in multi-task concurrent scenarios.

[0100] Figure 3 A flowchart of periodic task scheduling provided for embodiments of this application, such as Figure 3 As shown, it includes:

[0101] Step 310: When the task is a periodic task, check whether the first objective condition is met.

[0102] The first objective condition includes that the available resources of the onboard system meet the resource requirements of the periodic tasks, and that the task priority of the periodic tasks meets the first priority requirement. The first priority requirement is determined based on the importance, real-time nature, and security level of the periodic tasks.

[0103] Step 320: If the first objective condition is met, the periodic task will be moved to an idle periodic thread pool to wait for execution.

[0104] In this embodiment, the amount of idle resources refers to the total amount of remaining resources that the vehicle system can currently accommodate for tasks. It can be composed of CPU idle rate, available memory, I / O idle bandwidth, and GPU idle amount, and is used to characterize the resource carrying capacity before a task enters the pool.

[0105] In addition, in some implementations, before the periodic task is loaded into the idle periodic thread pool for execution, it is also necessary to check whether the working state of the vehicle system is the target state. If the working state is the target state, the loading of the periodic task into the idle periodic thread pool for execution is paused. If it is not the target state, the periodic task can be loaded into the idle periodic thread pool for execution.

[0106] The target state includes at least one of the following: hibernation state, system upgrade state, and fault protection state.

[0107] The operating status of the vehicle system is used to characterize the current vehicle operation mode. The target status indicates that the system is in a normal operating mode that allows periodic tasks to be executed, i.e., it has not entered a hibernation, upgrade, or fault protection state.

[0108] In this embodiment, the first priority requirement is used to define the entry threshold for periodic tasks. This threshold can be determined by the task's importance, real-time performance, and security level, ensuring that critical periodic tasks receive priority execution opportunities. Additionally, the periodic thread pool is a collection of thread pools specifically designed to handle periodic tasks. Its idle state indicates that the current capacity limit has not been reached and there are available threads for execution.

[0109] In practice, the scheduler reads the resource requirements and priorities of periodic tasks from the task scheduling table, and simultaneously obtains the amount of idle resources and the current working status of the vehicle system from the resource status information. When the amount of idle resources meets the task resource requirements, the system working status is in the target state, and the task priority reaches the first priority requirement, the scheduler generates an entry instruction, writes the periodic task into the waiting queue of the periodic thread pool, and records the entry time, target thread pool identifier, and queue number.

[0110] Among them, the periodic thread pool can be implemented using a fixed-capacity thread set or a thread set that is dynamically configured according to the number of periodic tasks.

[0111] The task scheduling method provided in this application combines resource conditions, system state conditions, and priority conditions for the admission judgment of periodic tasks. This ensures that tasks only enter the periodic thread pool for execution when they meet the execution window requirements, have sufficient resource capacity, and satisfy scheduling priority requirements. This avoids blindly scheduling periodic tasks under resource constraints or non-target system conditions. Consequently, it reduces the probability of thread pool congestion and improves the scheduling determinism and execution stability of the vehicle system under dynamic load scenarios.

[0112] Furthermore, when adding periodic tasks to a periodic thread pool, this can be achieved using the following method:

[0113] Step 11: Obtain the total execution time of each task in the periodic thread pool, and the total resource requirement of each task in the periodic thread pool.

[0114] Step 12: If the total execution time of the task is less than the running time interval of the periodic thread pool, and the total resource demand of the task is less than the idle resource amount of the vehicle system, then the periodic thread pool is determined to be in an idle state, and periodic tasks are added to the periodic thread pool.

[0115] Step 13: If the total execution time of the task is greater than or equal to the running time interval, or the total resource requirement of the task is greater than or equal to the amount of idle resources, then the periodic thread pool is determined to be in a non-idle state, and a new periodic thread pool is built to transfer the periodic tasks into the new periodic thread pool.

[0116] In this embodiment, the total task execution time refers to the sum of the expected execution time or the historical actual execution time of each task in the periodic thread pool within a running window. The total task resource requirement refers to the sum of the resource requirements of each task for CPU, memory, IO, etc. The running time interval is used to characterize the scheduling window length corresponding to the periodic thread pool. The amount of idle resources is used to characterize the remaining amount of resources that the vehicle system can currently allocate.

[0117] By jointly comparing the total duration with the running time interval, and the total demand with the amount of idle resources, a consistent judgment can be made on the load status of the periodic thread pool.

[0118] When the comparison result indicates that the current periodic thread pool is no longer idle, the thread pool management module will create another periodic thread pool, retaining the original periodic task categories, priority constraints, and resource isolation rules, and mapping subsequent periodic tasks to the new waiting queue. The new periodic thread pool can reuse the same scheduling strategy, or it can reconfigure the number of threads and queue length according to the current vehicle system load, so that different batches of periodic tasks wait in different execution containers, avoiding task backlog caused by timeouts or resource saturation in a single thread pool.

[0119] This application's embodiments introduce both time- and resource-based criteria to ensure that the entry of periodic tasks into the thread pool matches the actual capacity of the thread pool. When the thread pool is still idle, tasks can continuously enter and maintain stable execution; when the thread pool is nearing saturation, it promptly switches to a new periodic thread pool to handle subsequent tasks, thereby reducing mutual blocking between periodic tasks and improving the scheduling determinism and resource utilization efficiency of the vehicle system under load fluctuation conditions.

[0120] In addition, in some embodiments, after a periodic task is added to the periodic thread pool, the task execution process can be monitored. Specifically, the running frequency of the periodic thread pool and the execution count information of the periodic task can be obtained; then, based on the running frequency and execution count information, it can be determined whether the periodic task has been completed in the historical period; if the periodic task has not been completed in the historical period, the periodic task is deleted from the periodic thread pool and re-added to an idle periodic thread pool to await execution.

[0121] In this embodiment, the execution frequency is a parameter used by the periodic thread pool to trigger the execution of periodic tasks at preset time intervals, representing the scheduling rhythm of the thread pool for the periodic task. The execution count information records the number of times the periodic task has been triggered, run, or completed within the current scheduling cycle, reflecting the execution progress of the task. The previous cycle refers to the time range within which the periodic task most recently participated in scheduling and entered the execution window; this time range can be used to determine whether the task was completed within the predetermined cycle.

[0122] For example, the entire scheduling process for a periodic task is as follows:

[0123] First, it checks whether the current system's CPU, memory, I / O, and other resource availability meets the resource requirements of the current periodic task. It also determines the current system platform state; for example, if the system is undergoing OTA upgrades, calibration, or power hibernation, the current periodic task cannot run, but it needs to run during parking. Additionally, it checks whether the periodic task's priority and scheduling policy are satisfied. If all conditions are met, a thread pool is created, and the current periodic task is added to the periodic task queue.

[0124] Furthermore, the execution interval t of the periodic thread pool is set to create tasks using, for example, a least common multiple of 5 milliseconds (i.e., t = 5 / 10 / 15 / 20 milliseconds). Given the execution times of each periodic task as t1, t2, t3, ..., tn, the logical condition for scheduling execution is: t1 + t2 + t3 + ... + tn ≤ t.

[0125] Meanwhile, CPU, memory, I / O, and other resources must all meet the following condition (taking CPU as an example, others are similar): scpu1 + scpu2 + scpu3 + ... + scpun ≤ scpu (scpun refers to the CPU resources required by the nth periodic task, and scpu refers to the idle CPU in the system). If these conditions are met, the periodic task will be added to the current thread pool for execution; otherwise, a new thread pool task will be created.

[0126] In addition, for periodic tasks in operation, the SWC_THM component needs to collect the thread pool running frequency and task running count information to determine whether the previous cycle was executed deterministically. If not, an error is reported. At the same time, according to the interface generated by the SOA service toolchain configured according to the architecture requirements, the task is deleted or re-injected into the periodic thread pool for execution.

[0127] In addition, when the periodic task no longer needs to be executed, it is removed from the periodic thread pool and its resources are reclaimed and destroyed.

[0128] In this embodiment, when a periodic task times out, gets blocked, or fails to complete across cycles, it will not continuously occupy the original thread pool resources. Instead, it can be promptly removed and re-enter the idle thread pool waiting area to be re-matched with current resource conditions. This mechanism can reduce the backlog of subsequent cycles caused by single execution anomalies of periodic tasks, improve the recovery capability and execution continuity of periodic tasks, and enhance the scheduling stability and real-time performance of the vehicle system under high load scenarios.

[0129] Figure 4 The event-triggered task scheduling flowchart provided in the embodiments of this application is as follows: Figure 4 As shown, it includes:

[0130] Step 410: When the task is an event-triggered task, check whether the second objective condition is met.

[0131] The second objective condition includes ensuring that the available resources of the vehicle system meet the resource requirements of the event-triggered task, and that the task priority of the event-triggered task meets the second priority requirement. The second priority requirement is determined based on the security impact level of the event, the user's awareness of the event, and the urgency of handling the event.

[0132] Step 420: If the second objective condition is met, then check whether the event-triggered task needs to be executed periodically after it is triggered.

[0133] Step 430: If the event-triggered task needs to be executed periodically, then the event-triggered task is placed into an idle periodic thread pool to wait for execution.

[0134] Step 440: If the event-triggered task does not need to be executed periodically, then the event-triggered task is moved to the idle event-class thread pool to wait for execution.

[0135] In this embodiment, the second objective condition is an admission condition set for the event-triggered task, used to determine whether the event-triggered task is qualified to enter the thread pool for execution under the current resource status.

[0136] The idle resource quantity of the in-vehicle system represents the computing and execution resources currently available for event-triggered tasks, which may include CPU idle time, memory availability, I / O availability, and GPU availability. Task resource requirements represent the resources required for an event-triggered task to complete one trigger response; a task priority meeting the second priority requirement indicates that the event-triggered task has reached a preset scheduling priority threshold. The event-type thread pool is used to host event-triggered tasks that do not require periodic repetitive execution.

[0137] In this embodiment, the periodic thread pool and the event-based thread pool can each have independent task queues to avoid interference between one-time event processing and periodic repetitive execution. After the scheduler completes the task entry determination, it can write the entry result back to the task scheduling table and record the entry time, target thread pool type, and waiting status, so that subsequent thread allocation and execution feedback can be managed based on unified scheduling information. In this way, event-triggered tasks can be accurately distributed according to their execution form after triggering, ensuring that tasks that need to be executed periodically can reuse the timing capabilities of the periodic thread pool, and also ensuring that one-time event-triggered tasks can enter the event-based thread pool for rapid response.

[0138] The event-triggered task scheduling method provided in this application allows event-triggered tasks with sufficient resources and met priority to promptly enter the corresponding thread pool for execution. This avoids execution conflicts caused by mixing event-triggered tasks with periodic tasks and reduces the phenomenon of incorrect entry into the pool due to inaccurate execution mode recognition. Furthermore, since the task undergoes joint judgment of resource and priority conditions before entering the pool, the system can maintain high scheduling determinism in resource-constrained scenarios and improve the overall processing efficiency of the vehicle system for event response and continuously running tasks.

[0139] Furthermore, in some embodiments, it is possible to detect whether the event-triggered task has been completed; if the event-triggered task has not been completed, the event-triggered task is removed from the periodic thread pool and then re-introduced into the periodic thread pool that is in an idle state to wait for execution.

[0140] For example, it is possible to directly detect whether the event-triggered task has completed execution in the previous execution time interval. Here, "previous execution time interval" refers to the time window in which the event-triggered task was most recently scheduled and occupied thread pool execution resources. This time window can correspond to the task's scheduling cycle, or it can be set by the system as a monitoring interval that matches the task's execution characteristics, used to determine whether the task has ended within the predetermined window.

[0141] "Execution complete" means that the task has output a completion flag in the window, returned a normal result code, released the thread's occupied resources, or confirmed the end through heartbeat feedback.

[0142] When an event-triggered task fails to complete, it indicates that there may be an exception during the execution of the task, such as interruption or timeout. In this case, the event-triggered task should be deleted from the thread pool of the current cycle or re-added and executed.

[0143] Specifically, after an event-triggered task enters the periodic thread pool, the scheduling component records its entry time, start time, and preset execution interval based on the task identifier, and continuously collects task status bits, completion flag bits, and execution feedback information. When it detects that the current time has reached the boundary of the previous execution interval, the scheduling component determines whether the event-triggered task has been completed. If it has not been completed, it is determined that the event-triggered task has experienced timeout delays, resource contention, or external dependency blocking. Subsequently, it is removed from the task queue of the current periodic thread pool, and its abnormal status or pending rescheduling status is updated in the task scheduling table.

[0144] After removal, the scheduling component further searches for idle periodic thread pools, and then re-sends the event-triggered task into a new periodic thread pool to continue waiting for processing according to the periodic execution constraints.

[0145] In addition, if there are multiple periodic thread pools in the system, the thread pool with the highest idle level can be selected to undertake the event-triggered task based on the thread pool load, remaining time slice, and resource usage.

[0146] The event-triggered task detection method provided in this application allows for continuous monitoring of event-triggered tasks during periodic execution. When a task fails to complete on time, it promptly releases the original thread pool resources and migrates the task to a new idle thread pool to await execution again. This prevents a single abnormal task from accumulating subsequent periodic tasks due to prolonged delays. Furthermore, by detecting the completion status within the previous execution interval and deleting and rescheduling incomplete tasks, the availability of periodic thread pools and the recoverability of task execution are improved, and scheduling blocking caused by stalls, timeouts, or insufficient resources is reduced.

[0147] Figure 5 The logical dependency task scheduling flowchart provided for the embodiments of this application is as follows: Figure 5 As shown, it includes:

[0148] Step 510: When the task is a logically dependent task, check whether the third objective condition is met.

[0149] The third objective condition includes that the available resources of the in-vehicle system meet the resource requirements of the logically dependent tasks, and that the task priorities of the logically dependent tasks meet the third priority requirement. The third priority requirement is determined based on the execution status of the preceding tasks of the logically dependent tasks.

[0150] Step 520: If the third objective condition is met, then determine the predecessor tasks of logically dependent tasks based on the task scheduling table.

[0151] Step 530: Check whether the prerequisite tasks have been completed.

[0152] Step 540: If the preceding task has not been completed, the logically dependent task is moved to the idle logical class thread pool and executed after the preceding task is completed.

[0153] In this embodiment, the third objective condition is used to limit the entry threshold for logically dependent tasks before they enter the logical class thread pool.

[0154] The resource requirements of logically dependent tasks correspond to the computing and communication quotas required for their execution. The third priority requirement limits the scheduling level of logically dependent tasks, ensuring they do not compete for execution resources with lower-level tasks before fulfilling their dependency waiting conditions. Prerequisite tasks are identified through the dependency relationship field recorded in the task scheduling table. The logical thread pool is used to handle tasks that have met resource requirements but not yet their dependency completion conditions, and manages their waiting status.

[0155] In its implementation, upon receiving a scheduling request from a logically dependent task, the scheduling component first reads the task priority, resource requirements, and dependency information from the task scheduling table and compares them with the real-time collected resource status information. When the current idle resources of the vehicle system are greater than or equal to the resource requirements of the logically dependent task, and the task priority reaches the third priority requirement, the scheduling component then determines the identifier of the preceding task corresponding to the logically dependent task based on the dependency field and queries the execution status of the preceding task.

[0156] If the preceding task is in an incomplete execution state, the logically dependent tasks are written into the waiting queue of the logic class thread pool that is in an idle state. At the same time, the waiting reason, dependency association identifier and entry time are recorded so that they can be triggered for execution after the preceding task is completed.

[0157] A logical thread pool can consist of multiple pre-created worker threads. Mutexes, condition variables, or lock-free queues can be used to maintain the task waiting relationship between threads to ensure that dependent tasks are not preempted before the preceding tasks are completed.

[0158] When the system detects that a preceding task has been completed, the scheduling component updates the dependency completion flag in the task scheduling table and wakes up the corresponding logical dependency task in the logical class thread pool, allowing it to enter the execution state while the resource conditions are still met. This approach enables the task chain to run in a predetermined dependency order and avoids logical dependency tasks from executing prematurely due to unmet preceding conditions.

[0159] The logically dependent task scheduling method provided in this application allows the scheduling of logically dependent tasks to go beyond solely relying on resource availability. Instead, it combines priority constraints and the completion status of preceding tasks for a comprehensive judgment, enabling tasks in the dependency chain to wait and execute sequentially within acceptable resource limits. This reduces execution failures, repeated retries, and resource waste caused by premature task scheduling, and improves the scheduling determinism and execution stability of the vehicle system in complex task chain scenarios.

[0160] Furthermore, in some embodiments, it is also possible to detect whether there is an exception during the execution of the logical dependency task; if there is an execution exception, the logical dependency task is deleted from the logical class thread pool and then re-into the logical class thread pool that is in an idle state.

[0161] Among them, execution exceptions refer to abnormal states such as timeouts, interruptions, incorrect return results, secondary failures of dependency conditions, thread blocking, or health monitoring alarms that occur during the execution of logically dependent tasks.

[0162] In this embodiment, after a logically dependent task enters the logical thread pool, the scheduler performs anomaly detection based on the task heartbeat, execution receipt, return code, monitoring timeout threshold, and dependency verification results. When the execution time of a logically dependent task exceeds a preset threshold, or the task returns an exception code or the dependency relationship fails again, the scheduler marks the logically dependent task as an abnormal task and immediately removes it from the waiting queue or execution queue of the current logical thread pool to release thread occupation and queue position.

[0163] Subsequently, the scheduler retrieves idle logical thread pools from the thread pool resource view and then adds the logically dependent task back to the waiting queue corresponding to the logical thread pool so that it can be retried and executed after the resource is restored.

[0164] In addition, before logically dependent tasks are re-invoked, the cause of the exception can be recorded, and the exception flag, retry count, and most recent exception time in the task scheduling table can be updated synchronously to avoid exception tasks occupying fixed thread resources for a long time.

[0165] The anomaly detection method for logically dependent tasks provided in this application can promptly exit the original thread pool and re-enter the idle thread pool to wait for re-execution when a logically dependent task encounters an execution error. This prevents the abnormal task from continuously blocking subsequent logical links and from occupying execution thread resources for an extended period. This enhances the fault tolerance and self-recovery capabilities of logically dependent tasks in the vehicle system, reduces the impact of task anomalies on the scheduling efficiency of similar tasks, and improves the overall scheduling stability and execution determinism.

[0166] For example, Figure 6 The overall flowchart of task scheduling provided in the embodiments of this application is as follows: Figure 6 As shown, after the system starts running, the SWC_DTSF component first reads the scheduling table of deterministic tasks and loads the tasks that need to be managed by deterministic scheduling. The SWC_RCC component obtains the current system status, CPU, memory, I / O resources, and various resources of the tasks in real time. After the initialization is complete, the corresponding tasks are loaded into the corresponding queues based on the scheduling table information.

[0167] Figure 7 This is a schematic diagram of the vehicle business data flow provided in an embodiment of this application. The entire task deterministic scheduling framework abstracts three typical platforms for the current vehicle in-vehicle system platform: ECU (vehicle control MCU that meets ASIL-D functional safety requirements), Android (the user interaction cockpit), and Linux (including ADS with driver assistance functions), and deploys them accordingly. Figure 7 As shown, tasks that require deterministic scheduling across other platforms using the chip communicate and are triggered through interfaces uniformly generated by the SOA service toolchain. When a task is completed or when the execution result and signal data need to be exchanged, they are also done through the same interfaces uniformly generated by the SOA service toolchain.

[0168] In particular, the execution time in the scheduling table of the corresponding deterministic task needs to be added to the time consumed by the corresponding communication.

[0169] In this embodiment, a cross-platform communication interface needs to be automatically generated based on the SOA service toolchain; and in response to the task being loaded into the thread pool, the task execution instruction is sent to the target task execution platform in the vehicle system through the cross-platform communication interface to trigger the target task execution platform to execute the task.

[0170] SOA service-oriented toolchain is used to abstract the scattered service capabilities within the vehicle system into a unified service description, and automatically generate communication agents, message encoding and decoding logic and remote call encapsulation code based on the service interface definition, thereby forming a cross-platform communication interface that can be used across Linux platform, Android platform and vehicle control ECU platform.

[0171] This cross-platform communication interface can be built using Some / IP (Scalable Service-Oriented Middleware over IP), Data Distribution Service, or other service-oriented communication protocols. It can carry task identifiers, target platform identifiers, task priorities, execution parameters, and status feedback fields, enabling the scheduling results in the thread pool to be accurately identified by the target task execution platform. During deployment, the cross-platform communication interface can work in conjunction with the platform adaptation layer to convert unified task scheduling information into a call format recognizable by each platform, adapting to the message mechanisms and process communication mechanisms of different operating systems.

[0172] Once a task is added to the thread pool, the thread pool manager submits the task's entry status, target platform information, and execution context to the communication sending module. The communication sending module then generates the corresponding task execution instructions based on the target task execution platform recorded in the task scheduling table and sends them out through the cross-platform communication interface.

[0173] After receiving the task execution instruction, the target task execution platform wakes up the local task execution unit according to the task identifier and execution parameters carried in the instruction, and starts the process, thread or control routine corresponding to the task.

[0174] In addition, in some embodiments, the execution status of the task on the target task execution platform can be obtained through a cross-platform communication interface. The execution status is used to determine whether the task has encountered execution errors or has successfully completed execution, specifically including at least one of the following: execution error status, non-error status, execution completion status, and non-completion status.

[0175] In this embodiment, the execution status is the feedback information from the target task execution platform on the task execution result, which is used to characterize the current status of the task, such as startup, running, completion, timeout, failure, or exception.

[0176] In practice, after a task is started, the target task execution platform can bind the task identifier to the execution status and periodically report the status information through a cross-platform communication interface, or trigger a report when the status changes.

[0177] After receiving the execution status, the scheduler matches it with the task identifier in the task scheduling table and then uses a preset status mapping relationship to determine if there is any execution abnormality. When the execution status is timeout, failure, lag, or abnormal interruption, the scheduler can mark the task as an abnormal status and trigger rescheduling, resource reclamation, or alarm handling accordingly. When the execution status is completed and the completion code is valid, the task is marked as successfully completed and the completion record in the task scheduling table is updated.

[0178] In addition, in some embodiments, when the resource status information of the target task execution platform is detected to be unsatisfactory to the task requirements, the task is migrated to other task execution platforms for execution through a cross-platform communication interface.

[0179] Among them, other task execution platforms are task execution platforms in the vehicle system other than the target task execution platform, and the resource status information of other task execution platforms meets the task requirements.

[0180] In this embodiment, the target task execution platform is the in-vehicle computing platform currently carrying out task execution, which can be any of the Linux platform, Android cockpit platform, or vehicle control ECU platform. The resource status information of the target task execution platform is used to characterize the current available CPU, memory, IO, GPU, and bus load of the platform. When the available resources of the target task execution platform are lower than the threshold required by the task, it indicates that the platform no longer has the conditions to continue carrying out the task.

[0181] This application embodiment triggers task migration when the target platform's resources are insufficient, enabling tasks to be relocated to other platforms with sufficient resources to continue execution, thus avoiding prolonged task blocking due to local resource shortages. Since the migration target is limited to platforms within the vehicle system whose resource status meets the requirements, it can improve task execution continuity, reduce the risk of timeouts, stuttering, and failures caused by single-platform overload, and enhance resource utilization efficiency and scheduling stability in multi-platform collaborative scenarios.

[0182] Figure 8 This is a schematic diagram of the task scheduling device structure provided in the embodiments of this application, such as... Figure 8 As shown, the task scheduling device 800 includes:

[0183] The category acquisition module 810 is used to acquire the task category of each task in the vehicle system. The task categories include periodic tasks, event-triggered tasks, and logically dependent tasks.

[0184] The information acquisition module 820 is used to acquire task information for each task based on the task category. The task information includes task priority, task resource requirements, task dependencies, and task identifier.

[0185] Module 830 is used to build the task scheduling table of the vehicle system based on the task information of each task;

[0186] The real-time acquisition module 840 is used to acquire resource status information of the vehicle system in real time.

[0187] The task scheduling module 850 is used to determine whether to add a task to the thread pool for execution based on the task information and resource status information of each task in the task scheduling table.

[0188] Optionally, the task scheduling module 850 can be used to: obtain the task scheduling policy corresponding to the task category; then, based on the task scheduling policy and the task information, determine whether the resource status information meets the task requirements; if the resource status information meets the task requirements, then the task is put into the thread pool to wait for execution.

[0189] Optionally, the task scheduling module 850 can be specifically used for:

[0190] When a task is a periodic task, if the available resources of the vehicle system meet the resource requirements of the periodic task and the periodic task meets the first priority requirement, then the periodic task will be moved to the idle periodic thread pool to wait for execution; the first priority requirement is determined based on the importance, real-time performance, and security level of the periodic task.

[0191] When the task is an event-triggered task, if the available resources of the vehicle system meet the resource requirements of the event-triggered task and the event-triggered task meets the second priority requirement, then the event-triggered task will be moved to an idle event-type thread pool or periodic-type thread pool to wait for execution. The second priority requirement is determined based on the security impact level of the event, the user's perception of the event, and the urgency of the event's handling.

[0192] When a task is a logically dependent task, if the available resources of the vehicle system meet the resource requirements of the logically dependent task and the logically dependent task meets the third priority requirement, then the logically dependent task will be moved into the idle logical class thread pool to wait for execution; the third priority requirement is determined based on the execution status of the preceding task of the logically dependent task.

[0193] Optionally, the task scheduling device further includes a status detection module, used to: detect whether the working status of the vehicle system is the target status; if the working status is the target status, then pause the periodic task being loaded into the periodic thread pool that is in an idle state to wait for execution. The target status includes at least one of the following: hibernation state, system upgrade state, and fault protection state.

[0194] Optionally, the task scheduling module 850 can be specifically used to: obtain the total execution time of each task in the periodic thread pool and the total resource requirement of each task in the periodic thread pool; if the total execution time of the task is less than the running time interval of the periodic thread pool and the total resource requirement of the task is less than the idle resource amount of the vehicle system, then the periodic thread pool is determined to be in an idle state, and periodic tasks are added to the periodic thread pool; if the total execution time of the task is greater than or equal to the running time interval, or the total resource requirement of the task is greater than or equal to the idle resource amount, then the periodic thread pool is determined to be in a non-idle state, and a new periodic thread pool is constructed to add periodic tasks to the new periodic thread pool.

[0195] Optionally, the task scheduling system 800 also includes a completion detection module, used to: obtain the running frequency of the periodic thread pool and the running count information of the periodic tasks; determine whether the periodic tasks have been completed in the historical period based on the running frequency and running count information; if the periodic tasks have not been completed in the historical period, then the periodic tasks are deleted from the periodic thread pool and the periodic tasks are re-entered into the periodic thread pool that is in an idle state to wait for execution.

[0196] Optionally, the task scheduling system 800 also includes a periodic task exception handling module, used to: detect whether the event-triggered task needs to be executed periodically after it is triggered; if the event-triggered task needs to be executed periodically, then the event-triggered task is placed into an idle periodic thread pool to wait for execution; if the event-triggered task does not need to be executed periodically, then the event-triggered task is placed into an idle event thread pool to wait for execution.

[0197] Optionally, the task scheduling module 850 can be used to: detect whether the event-triggered task has been completed; if the event-triggered task has not been completed, remove the event-triggered task from the periodic thread pool and re-introduce the event-triggered task into the periodic thread pool that is in an idle state to wait for execution.

[0198] Optionally, the task scheduling module 850 can be used to: determine the pre-task of a logically dependent task based on the task scheduling table; detect whether the pre-task has been completed; if the pre-task has not been completed, the logically dependent task is loaded into an idle logical thread pool and executed after the pre-task is completed.

[0199] Optionally, the task scheduling system 800 also includes a logical dependency task exception handling module, which is used to detect whether there is an exception during the execution of the logical dependency task; if there is an execution exception in the logical dependency task, the logical dependency task is deleted from the logical class thread pool and re-sent to the logical class thread pool that is in an idle state.

[0200] Optionally, the task scheduling system 800 also includes a task sending module, which is used to automatically generate cross-platform communication interfaces based on the SOA service toolchain; in response to a task being loaded into the thread pool, the task execution instruction is sent to the target task execution platform in the vehicle system through the cross-platform communication interface to trigger the target task execution platform to execute the task.

[0201] Optionally, the task scheduling system 800 also includes a status feedback module, which is used to obtain the execution status of the task on the target task execution platform through a cross-platform communication interface. The execution status includes at least one of execution exception status, non-exception status, execution completion status, and non-completion status.

[0202] Optionally, the task scheduling system 800 also includes a task transfer module, used to migrate the task to other task execution platforms for execution via a cross-platform communication interface when the resource status information of the target task execution platform does not meet the task requirements. These other task execution platforms are those in the vehicle system other than the target task execution platform, and their resource status information meets the task requirements.

[0203] The event handling device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0204] Figure 9 This is a structural diagram of the vehicle provided in this application. Figure 9 As shown, the vehicle 90 provided in this embodiment includes: a vehicle body 901, at least one processor 902, and a memory 903. Optionally, the vehicle 90 also includes a communication interface 904. The processor 902, memory 903, and communication interface 904 are connected via a bus 905.

[0205] In a specific implementation, at least one processor 902 executes computer execution instructions stored in memory 903, causing at least one processor 902 to perform the above-described method.

[0206] The specific implementation process of processor 902 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0207] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0208] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0209] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0210] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0211] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0212] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0213] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0214] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0215] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0216] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, 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 of the various embodiments of this 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.

[0217] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0218] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

[0219] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A task scheduling method, characterized in that, include: Obtain the task category for each task in the vehicle system, including periodic tasks, event-triggered tasks, and logically dependent tasks; Based on the task category, obtain the task information for each task, which includes task priority, task resource requirements, task dependencies, and task identifier. Based on the task information of each task, a task scheduling table for the vehicle system is constructed; Real-time acquisition of resource status information of the vehicle system; Based on the task information of each task in the task scheduling table and the resource status information, it is determined whether the task should be added to the thread pool for execution.

2. The method according to claim 1, characterized in that, The step of determining whether to add the task to the thread pool for execution based on the task information of each task in the task scheduling table and the resource status information includes: Obtain the task scheduling strategy corresponding to the task category; Based on the task scheduling strategy and the task information, it is determined whether the resource status information meets the task requirements. If the resource status information meets the task requirements, the task will be added to the thread pool for execution.

3. The method according to claim 1 or 2, characterized in that, The step of determining whether to add the task to the thread pool for execution based on the task information of each task in the task scheduling table and the resource status information includes: When the task is a periodic task, if the idle resources of the vehicle system meet the resource requirements of the periodic task and the periodic task meets the first priority requirement, then the periodic task will be moved into the idle periodic thread pool to wait for execution; the first priority requirement is determined based on the importance, real-time performance, and security level of the periodic task. When the task is an event-triggered task, if the idle resources of the vehicle system meet the resource requirements of the event-triggered task, and the event-triggered task meets the second priority requirement, then the event-triggered task will be moved to an idle event-type thread pool or periodic-type thread pool to wait for execution; the second priority requirement is determined based on the security impact level of the event, the user's perception of the event, and the urgency of handling the event; When the task is a logically dependent task, if the idle resources of the vehicle system meet the resource requirements of the logically dependent task, and the logically dependent task meets the third priority requirement, then the logically dependent task will be moved into the idle logical class thread pool to wait for execution; the third priority requirement is determined based on the execution status of the preceding task of the logically dependent task.

4. The method according to claim 3, characterized in that, Before the periodic task is placed into an idle periodic thread pool to await execution, the method further includes: Detect whether the operating state of the vehicle system is a target state, the target state including at least one of sleep state, system upgrade state and fault protection state; If the working state is the target state, then the periodic task is paused and moved to an idle periodic thread pool to wait for execution.

5. The method according to claim 4, characterized in that, The step of placing the periodic task into an idle periodic thread pool for execution includes: Obtain the total execution time of each task in the periodic thread pool, and the total resource requirement of each task in the periodic thread pool; If the total execution time of the task is less than the running time interval of the periodic thread pool, and the total resource requirement of the task is less than the idle resource amount of the vehicle system, then the periodic thread pool is determined to be in an idle state, and the periodic task is loaded into the periodic thread pool. If the total execution time of the task is greater than or equal to the running time interval, or the total resource requirement of the task is greater than or equal to the amount of idle resources, then the periodic thread pool is determined to be in a non-idle state, and a new periodic thread pool is constructed to transfer the periodic task to the new periodic thread pool.

6. The method according to claim 4, characterized in that, After the periodic task is placed into an idle periodic thread pool to await execution, the method further includes: Obtain the running frequency of the periodic thread pool and the running count information of the periodic tasks; Based on the running frequency and the running count information, it is determined whether the periodic task was completed and executed in the historical cycle; If the periodic task is not completed in the historical period, the periodic task is removed from the periodic thread pool and then re-added to an idle periodic thread pool to wait for execution.

7. The method according to claim 3, characterized in that, The step of placing the event-triggered task into an idle event-type thread pool or periodic-type thread pool for execution includes: Detect whether the event-triggered task needs to be executed periodically after it is triggered; If the event-triggered task needs to be executed periodically, then the event-triggered task will be placed into a periodic thread pool that is in an idle state to wait for execution. If the event-triggered task does not need to be executed periodically, it will be placed into an idle event-type thread pool to wait for execution.

8. The method according to claim 7, characterized in that, The method further includes: Detect whether the event-triggered task has been completed; If the event-triggered task is not completed, the event-triggered task will be removed from the periodic thread pool and then re-added to an idle periodic thread pool to wait for execution.

9. The method according to claim 3, characterized in that, The step of placing the logically dependent task into an idle logical class thread pool to await execution includes: Based on the task scheduling table, determine the prerequisite tasks for the logically dependent tasks; Detect whether the preceding task has been completed; If the preceding task has not been completed, the logically dependent task will be moved to an idle logical thread pool and executed after the preceding task has been completed.

10. The method according to claim 9, characterized in that, The method further includes: Detect whether there are any anomalies during the execution of the logically dependent tasks; If the logically dependent task experiences an execution exception, the logically dependent task will be removed from the logical class thread pool and then re-added to an idle logical class thread pool.

11. The method according to claim 1, characterized in that, The method further includes: Automatically generate cross-platform communication interfaces based on SOA service-oriented toolchain; In response to the task being loaded into the thread pool, a task execution instruction is sent to the target task execution platform in the vehicle system through the cross-platform communication interface to trigger the target task execution platform to execute the task.

12. The method according to claim 11, characterized in that, The method further includes: The execution status of the task on the target task execution platform is obtained through the cross-platform communication interface. The execution status includes at least one of the following: execution error status, non-error status, execution completed status, and non-complete status.

13. The method according to claim 11, characterized in that, The method further includes: When it is detected that the resource status information of the target task execution platform does not meet the task requirements, the task is migrated to another task execution platform for execution through the cross-platform communication interface; wherein, the other task execution platform is a task execution platform in the vehicle system other than the target task execution platform, and the resource status information of the other task execution platform meets the task requirements.

14. A task scheduling device, characterized in that, include: The category acquisition module is used to acquire the task category of each task in the vehicle system. The task categories include periodic tasks, event-triggered tasks, and logically dependent tasks. The information acquisition module is used to acquire task information for each task based on the task category. The task information includes task priority, task resource requirements, task dependencies, and task identifier. The construction module is used to construct the task scheduling table of the vehicle system based on the task information of each task; The real-time acquisition module is used to acquire the resource status information of the vehicle system in real time. The task scheduling module is used to determine whether to add the task to the thread pool for execution based on the task information of each task in the task scheduling table and the resource status information.

15. A task scheduling system, characterized in that, include: The resource acquisition component is used to acquire the resource status information of the vehicle system in real time, as well as the task information of each task in the vehicle system. The task information is used to generate a task scheduling table. A task scheduling component is used to determine whether to schedule the task to a thread pool for execution based on the task scheduling table and the resource status information. The task monitoring component is used to monitor the execution status of each task during execution and feed it back to the task scheduling component so that the task scheduling component can reschedule the tasks.

16. A vehicle, characterized in that, include: Vehicle body, memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-13.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-13.

Images