Task scheduling method and device, intelligent device, storage medium and program product

Abstract

The application provides a task arrangement method and device, an intelligent device, a storage medium and a program product. The method comprises the following steps: obtaining task attributes of a plurality of to-be-executed tasks; the task attributes comprise running time, required resources, resource information of a running platform and state information of the running platform; arranging the plurality of to-be-executed tasks based on the task attributes of the plurality of to-be-executed tasks, to obtain initial arrangement information; performing scheduling execution on the plurality of to-be-executed tasks based on the initial arrangement information, to obtain a first scheduling execution result; determining target arrangement information based on the first scheduling execution result and the task attributes of the plurality of to-be-executed tasks; and performing scheduling execution on the plurality of to-be-executed tasks in the target arrangement information based on the target arrangement information.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a task orchestration method and apparatus, intelligent devices, storage media, and program products. Background Technology

[0002] With the development of new energy vehicles and intelligent driving technologies, the number and complexity of tasks that in-vehicle systems need to handle are continuously increasing. Task scheduling and orchestration have become key aspects to ensure the stable and efficient operation of the system. In in-vehicle platforms, tasks typically have diverse triggering mechanisms (such as periodicity, event-driven, and data-driven) and resource requirements. How to achieve efficient and deterministic task scheduling across different hardware platforms has become a core challenge in system design. Summary of the Invention

[0003] This application provides a task orchestration method, task orchestration device, intelligent device, computer storage medium, and computer program product, which are beneficial to realizing the automation, intelligence, and determinism of orchestration of multiple tasks to be executed.

[0004] In a first aspect, embodiments of this application provide a task orchestration method, the method comprising: obtaining task attributes of a plurality of tasks to be executed; the task attributes including: running time, required resources, resource information of the running platform, and status information of the running platform; orchestrating the plurality of tasks to be executed based on the task attributes of the plurality of tasks to be executed to obtain initial orchestration information; scheduling and executing the plurality of tasks to be executed based on the initial orchestration information to obtain an initial scheduling and execution result; determining target orchestration information based on the initial scheduling and execution result and the task attributes of the plurality of tasks to be executed; and scheduling and executing the plurality of tasks to be executed in the target orchestration information based on the target orchestration information.

[0005] It is understood that the task orchestration method provided in this application embodiment obtains the task attributes of multiple tasks to be executed, including runtime, required resources, resource information of the running platform, and status information, thereby providing complete input data for subsequent orchestration. Then, based on these task attributes, the tasks are orchestrated to generate initial orchestration information, realizing the preliminary scheduling arrangement of the tasks to be executed under resource constraints. Next, based on the initial orchestration information, multiple tasks to be executed are scheduled and executed, and the initial scheduling execution result is fed back through actual operation. Finally, combining the initial scheduling execution result with the original task attributes, the target orchestration information is iteratively optimized and determined. In this way, through actual operation verification and optimization of the orchestration strategy based on the actual operation results, the automation, intelligence, and determinism of orchestration of multiple tasks to be executed are achieved, thereby effectively reducing vehicle development costs and cycles, and enabling rapid optimization for different vehicle models.

[0006] In some embodiments, the step of orchestrating the plurality of tasks to be executed based on their task attributes to obtain initial orchestration information includes: determining the plurality of tasks to be executed running in the sub-state of each sub-platform in the vehicle platform; the resource information of the running platform is the resource information of the tasks to be executed in the corresponding sub-state of the sub-platform; and orchestrating the plurality of tasks to be executed based on the resource information of each sub-platform in the sub-state, and the running time and required resources of the plurality of tasks to be executed in the sub-state of each sub-platform to obtain the initial orchestration information.

[0007] It is understood that in the task orchestration method provided in this application embodiment, the tasks to be executed under each sub-state of each sub-platform in the vehicle platform are determined separately. Based on the resource information of each sub-platform in the sub-state, the running time and required resources of multiple tasks to be executed under each sub-platform in the sub-state, multiple tasks to be executed are orchestrated, thereby achieving fine-grained scheduling according to the state dimension. In this way, the problems of resource conflicts or scheduling failures caused by ignoring platform state changes can be avoided, and the adaptability and stability of tasks to be executed in complex vehicle environments can be improved.

[0008] In some embodiments, the initial orchestration information is obtained by orchestrating the plurality of tasks to be executed based on the resource information of each sub-platform in the vehicle platform in a sub-state, and the running time and required resources of the plurality of tasks to be executed on each sub-platform in the sub-state. This includes: determining the duration of the running threads of the plurality of tasks to be executed for each sub-platform in the sub-state; creating running threads for the plurality of tasks to be executed based on the duration; and placing the plurality of tasks to be executed in the running threads based on the resource information of each sub-platform in the vehicle platform in a sub-state, and the running time and required resources of the tasks to be executed on each sub-platform in the sub-state, thereby obtaining the initial orchestration information.

[0009] It is understood that in the task orchestration method provided in the embodiments of this application, for each sub-platform's sub-state, the duration of the running thread in the corresponding sub-platform's sub-state is first determined, and then a running thread is created based on the duration. Subsequently, based on the resource information of each sub-platform in the vehicle platform in the sub-state, as well as the running time and required resources of the tasks to be executed on each sub-platform in the sub-state, a place is reserved in the corresponding running thread, thereby realizing the reasonable distribution of tasks to be executed on the time axis and the orderly management of resource occupation, thereby improving the determinism and efficiency of task scheduling.

[0010] In some embodiments, the step of arranging the plurality of tasks to be executed in the running thread based on the resource information of each sub-platform in the sub-state of the vehicle platform, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state to obtain the initial orchestration information includes: sorting the plurality of tasks to be executed based on the priority and scheduling information of the tasks to be executed by each sub-platform in the sub-state to obtain a sorting result; and arranging the plurality of tasks to be executed in the running thread according to the sorting result, based on the resource information of each sub-platform in the sub-state of the vehicle platform, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state to obtain the initial orchestration information.

[0011] It is understood that in the task orchestration method provided in this application embodiment, the priority and scheduling information of multiple tasks to be executed are sorted, and then combined with the resource information of each sub-platform in the vehicle platform in the sub-state, as well as the running time and required resources of the tasks to be executed in each sub-platform in the sub-state, the running threads are reserved. This is beneficial to achieve reasonable and orderly orchestration of tasks to be executed, thereby improving the determinism and resource utilization of task scheduling in the vehicle system, ensuring the timely execution of critical tasks to be executed, and reducing the complexity and error risk of vehicle system scheduling.

[0012] In some embodiments, the step of arranging the plurality of tasks to be executed in the running thread according to the sorting result, based on the resource information of each sub-platform in the sub-state of the vehicle platform, and the running time and required resources of the task to be executed by each sub-platform in the sub-state, to obtain the initial orchestration information, includes: based on the sorting result, in response to the sub-platform's task to be executed in the sub-state having a running time less than or equal to the running thread's idle time and the remaining platform resources in the platform resources allocated to the running thread in the sub-state of the sub-platform satisfying the required resources of the task to be executed, arranging the task to be executed in the running thread; based on the sorting result, in response to the sub-platform's task to be executed in the sub-state having a running time less than or equal to the running thread's idle time and the remaining platform resources in the platform resources allocated to the running thread in the sub-state of the sub-platform satisfying the required resources of the task to be executed, arranging the task to be executed in the running thread; based on the sorting result, in response to the sub-platform If the running time of the task to be executed in the sub-state is greater than the idle time of the thread, and / or the remaining platform resources allocated to the running thread in the sub-state of the sub-platform do not meet the resource requirements of the task to be executed, a new running thread for the task to be executed is recreated; based on the resource information of the sub-platform corresponding to the un-arranged task to be executed in the sub-state of the vehicle platform, and the running time and required resources of the task to be executed in the sub-state of the sub-platform, the un-arranged task to be executed is placed in the new running thread; based on the task to be executed already placed in the running thread and the un-arranged task to be executed in the new running thread, the initial arrangement information is obtained.

[0013] It is understood that in the task orchestration method provided in this application embodiment, if the running time of a task to be executed does not exceed the idle time of the current running thread and resources are sufficient, the task is reserved in the current running thread to improve the utilization rate of the running thread; if not, a new running thread is created and the task continues to be reserved, ensuring that all tasks to be executed can be scheduled reasonably. This helps to avoid resource waste or scheduling timeouts caused by fixed running thread allocation, thereby ensuring the deterministic execution of tasks to be executed and system stability, and thus improving the overall efficiency and reliability of task scheduling on the sub-platform.

[0014] In some embodiments, determining the duration of the running threads of the plurality of pending tasks includes: determining the duration of the running threads of the plurality of pending tasks that have not been scheduled based on the inverted trapezoidal structure and the running time of the pending task that is first in the sorting result among the unscheduled pending tasks.

[0015] It is understood that in the task orchestration method provided in this application embodiment, an inverted trapezoidal structure is used to determine the duration of multiple task execution threads based on the execution time of the first un-orchestrated task. This ensures that the capacity of the running threads is sufficient to accommodate the execution cycle of the tasks to be executed and reserves buffer space, thereby improving the resource utilization and scheduling efficiency of the running threads, and ultimately contributing to the optimization of overall scheduling performance.

[0016] In some embodiments, determining the target orchestration information based on the initial scheduling execution result and the task attributes of the plurality of tasks to be executed includes: updating the task attributes of at least one of the tasks to be executed based on the initial scheduling execution result; orchestrating the plurality of tasks to be executed based on the updated task attributes of the tasks to be executed to obtain secondary orchestration information; scheduling and executing the plurality of tasks to be executed based on the secondary orchestration information to obtain a secondary scheduling execution result; if the secondary scheduling execution result does not satisfy deterministic scheduling, replacing the initial scheduling execution result with the secondary scheduling execution result, replacing the task attributes of the tasks to be executed with the updated task attributes of the tasks to be executed, iteratively executing the above steps until the secondary scheduling execution result satisfies deterministic scheduling, and determining the secondary orchestration information as the target orchestration information.

[0017] It is understood that in the task orchestration method provided in this application embodiment, the task attributes are updated in reverse based on the initial scheduling execution result, and then secondary orchestration information is generated based on the updated task attributes and verified again; the process continues to iterate when deterministic scheduling is not satisfied until deterministic scheduling is satisfied. In this way, by making full use of actual operating data, automatically correcting task attributes and re-arranging, the practicality and reliability of the target orchestration information are significantly improved, thereby adapting to the dynamic operating environment of the vehicle.

[0018] In some embodiments, determining the target orchestration information based on the initial scheduling execution result and the task attributes of the plurality of tasks to be executed includes: displaying the initial scheduling execution result, the plurality of tasks to be executed, and the task attributes of the plurality of tasks to be executed; receiving the task attributes of the plurality of updated tasks to be executed; orchestrating the plurality of updated tasks to be executed based on the task attributes of the plurality of updated tasks to obtain three orchestration information; scheduling and executing the plurality of updated tasks to be executed based on the three orchestration information to obtain three scheduling execution results; if the three scheduling execution results do not satisfy deterministic scheduling, replacing the initial scheduling execution result with the three scheduling execution results, replacing the task attributes of the tasks to be executed with the updated task attributes of the tasks to be executed, iteratively executing the above steps until the three scheduling execution results satisfy deterministic scheduling, and determining the three orchestration information as the target orchestration information.

[0019] It is understood that the task orchestration method provided in this application embodiment supports manual intervention in the orchestration process. By displaying the initial scheduling result, multiple tasks to be executed, and task attributes, users can edit and update tasks. Then, based on the updated task attributes, a new round of orchestration and verification is performed, achieving human-machine collaborative optimization. This approach balances automation and flexibility in orchestration, is suitable for stages where tasks to be executed change frequently, and effectively shortens the orchestration iteration cycle, thereby improving engineering efficiency.

[0020] In some embodiments, the step of scheduling and executing the plurality of tasks to be executed based on the initial orchestration information to obtain the first scheduling and execution result further includes: generating a scheduling interface for the plurality of tasks to be executed; and scheduling and executing the plurality of tasks to be executed based on the initial orchestration information and the scheduling interface of the plurality of tasks to be executed to obtain the first scheduling and execution result.

[0021] It is understood that in the task orchestration method provided in this application embodiment, a scheduling interface is generated for the tasks to be executed, and multiple tasks to be executed are scheduled and executed based on the initial orchestration information and the scheduling interfaces of multiple tasks to be executed, to obtain the first scheduling execution result. This is beneficial for achieving standardization and automation of task scheduling, thereby decoupling the resource matching problem between the business development team and the specific vehicle platform, and thus improving the engineering level and resource utilization of the entire vehicle system, ensuring the stable operation and functional safety of the vehicle system.

[0022] Secondly, embodiments of this application provide a task orchestration apparatus, comprising: an acquisition module configured to acquire task attributes of a plurality of tasks to be executed; the task attributes including: running time, required resources, resource information of the running platform, and status information of the running platform; an orchestration module configured to orchestrate the plurality of tasks to be executed based on the task attributes of the plurality of tasks to be executed, to obtain initial orchestration information; a first scheduling execution module configured to schedule and execute the plurality of tasks to be executed based on the initial orchestration information, to obtain an initial scheduling execution result; a determination module configured to determine target orchestration information based on the initial scheduling execution result and the task attributes of the plurality of tasks to be executed; and a second scheduling execution block configured to schedule and execute the plurality of tasks to be executed in the target orchestration information.

[0023] Thirdly, embodiments of this application provide an intelligent device, including a memory and a processor. The memory stores a computer program that can run on the processor, and when the processor executes the program, it implements the task orchestration method described in the first aspect.

[0024] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the task orchestration method described in the first aspect.

[0025] Fifthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the task orchestration method described in the first aspect. Attached Figure Description

[0026] Figure 1 A schematic diagram of the implementation process of a task orchestration method provided in this application embodiment. Figure 1 ; Figure 2 This application provides a schematic diagram of an implementation process for obtaining initial arrangement information. Figure 1 ; Figure 3 This application provides a schematic diagram of an implementation process for obtaining initial arrangement information. Figure 2 ; Figure 4 A schematic diagram of an implementation process for determining target orchestration information provided in this application embodiment. Figure 1 ; Figure 5 A schematic diagram of an implementation process for determining target orchestration information provided in this application embodiment. Figure 2 ; Figure 6 A framework diagram of a task scheduling and orchestration tool provided in an embodiment of this application; Figure 7 This application provides a schematic diagram of an implementation process for obtaining initial arrangement information. Figure 3 ; Figure 8 A schematic diagram of an implementation process for determining target orchestration information provided in this application embodiment. Figure 3 ; Figure 9 A schematic diagram of a task orchestration apparatus provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a smart device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described below in conjunction with the accompanying drawings. The embodiments described below are only some embodiments of this application, not all embodiments. Therefore, the described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] In the following description, references to “some embodiments” or “other embodiments” describe a subset of all possible embodiments. However, it is understood that “some embodiments” or “other embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0030] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0032] In a related technology, a method for dynamic orchestration of complex robot tasks is provided. By collecting robot state and event data, constructing a dual matrix and fusing it into a tensor for low-rank decomposition, dynamically generating and optimizing thresholds, calculating task priorities from multiple factors, allocating resources by combining resource constraints and federated learning, and simultaneously performing cross-scenario adaptation, risk pre-planning, and visual feedback optimization during execution, the method achieves dynamic adaptation, efficient collaboration, and stable execution of complex tasks.

[0033] In another related technology, a deterministic task scheduling and orchestration method, system and storage medium based on a time-triggered mechanism are provided, which assigns relative priorities to each task based on task cycle, time and expected priority.

[0034] In their research and analysis of the aforementioned related technologies, the inventors of this application discovered that federated learning in orchestration is a distributed method of "data remains stationary while the model moves," which is not suitable for scenarios involving unified orchestration on intelligent devices; nor is it suitable for deployment on various domain controllers in a real vehicle, as this would consume enormous resources of the orchestration model itself and the system platform. The tasks of in-vehicle platforms are complex and diverse, including not only periodic tasks but also data-triggered and task-dependent situations. The aforementioned related solutions cannot meet the task orchestration needs of in-vehicle platforms.

[0035] In view of this, this application provides a task orchestration method. Figure 1 A schematic diagram of the implementation process of a task orchestration method provided in this application embodiment. Figure 1 ,like Figure 1 As shown, the method includes steps 101 to 105: Step 101: Obtain the task attributes of multiple tasks to be executed; the task attributes include: running time, required resources, resource information of the running platform, and status information of the running platform; Step 102: Based on the task attributes of multiple tasks to be executed, arrange the multiple tasks to be executed to obtain initial arrangement information; Step 103: Based on the initial orchestration information, schedule and execute the multiple tasks to be executed to obtain the first scheduling and execution result; Step 104: Based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed, determine the target orchestration information; Step 105: Based on the target orchestration information, schedule and execute multiple tasks to be executed in the target orchestration information.

[0036] It is understood that the task orchestration method provided in this application embodiment obtains the task attributes of multiple tasks to be executed, including runtime, required resources, resource information of the running platform, and status information, thereby providing complete input data for subsequent orchestration. Then, based on these task attributes, the tasks are orchestrated to generate initial orchestration information, realizing the preliminary scheduling arrangement of the tasks to be executed under resource constraints. Next, based on the initial orchestration information, multiple tasks to be executed are scheduled and executed, and the initial scheduling execution result is fed back through actual operation. Finally, combining the initial scheduling execution result with the original task attributes, the target orchestration information is iteratively optimized and determined. In this way, through actual operation verification and optimization of the orchestration strategy based on the actual operation results, the automation, intelligence, and determinism of orchestration of multiple tasks to be executed are achieved, thereby effectively reducing vehicle development costs and cycles, and enabling rapid optimization for different vehicle models.

[0037] The following sections will describe further optional implementation methods for each of the above steps, as well as related terms.

[0038] In step 101, the task attributes of multiple tasks to be executed are obtained; the task attributes include: running time, required resources, resource information of the running platform, and status information of the running platform.

[0039] In some embodiments, obtaining the task attributes of multiple tasks to be executed includes: during the vehicle development and verification phase, obtaining the task attributes of multiple tasks to be executed running on the vehicle's onboard platform.

[0040] It should be understood that, in this embodiment, the task attributes of the task to be executed are not limited. The task attributes are the basic input data for subsequent automated orchestration. The task attributes of the task to be executed are confirmed by the business development team and / or system architect. The task to be executed refers to an atomic or composite task designed to run on an in-vehicle platform.

[0041] In this embodiment, runtime refers to the time required for the task to be executed to complete one execution on the corresponding vehicle platform. In some embodiments, the runtime is obtained by calling and running the corresponding task to be executed on the vehicle or a test vehicle of the vehicle. For example, in one possible implementation, the task to be executed is called separately on the actual vehicle hardware running platform, simulating all the input data of the task to be executed and running the task to be executed more than one million times. The execution time of each run is counted, and a normal distribution is used to obtain the execution time range that the actual runtime can fall into 99.99% of the time. The maximum execution time in this range is taken as the runtime of the task to be executed. In some embodiments, the runtime of the task to be executed refers to the worst-case execution time (WCET) of the task to be executed.

[0042] In some embodiments, the runtime of the task to be executed includes: the communication time of the task to be executed and / or the jitter time of running the task to be executed.

[0043] It is understood that in this embodiment, the execution time of the task to be executed is extended to include communication time and jitter time, making the orchestration closer to the real operating environment and avoiding scheduling failure due to ignoring communication delays or system jitter. This improves the accuracy and executability of the orchestration results and is suitable for automotive application scenarios with high real-time requirements.

[0044] It should be understood that, in this embodiment, the communication time of the task to be executed refers to the time consumed by data communication during the operation of the task on the vehicle platform. The communication time of the task to be executed includes the latency incurred when the task receives input data or sends output data through a Service-Oriented Architecture (SOA) service-based communication protocol. For example, if the task needs to subscribe to data from a service before it can run, and must wait for the data to arrive before starting the task, this waiting time is part of the communication time of the task to be executed. Furthermore, if the task needs to interact with other tasks or modules during its operation, additional communication time will be incurred during data transmission, protocol parsing, and buffering. The communication time of the task to be executed is affected by factors such as network bandwidth, communication protocol efficiency, data packet size, and communication distance.

[0045] For example, in one possible implementation, in an autonomous driving system, the perception module needs to receive raw data from cameras or radar for the task to be performed. This data is transmitted to the processing module via an in-vehicle Ethernet or Controller Area Network (CAN) bus, and the delay in the transmission process constitutes the communication time of the task to be performed.

[0046] In this embodiment, the jitter time of a task to be executed refers to the fluctuation range of the actual execution time relative to the expected execution time during the scheduling and execution process of the task on the vehicle platform. This jitter time originates from various factors such as system scheduling mechanisms, hardware resource contention, interrupt response latency, and memory access latency. For example, in a periodic task scheduling process, if the expected execution time of the task is 10 milliseconds (ms), but the actual execution time fluctuates between 8ms and 12ms due to the jitter time, the scheduler needs to reserve at least 2ms of buffer time to ensure that the task can be completed on time.

[0047] In this embodiment, the required resources refer to the system resources actually consumed by the task to be executed during its operation, including CPU utilization, memory usage, input / output (IO) operation frequency, communication bandwidth, etc. For example, in one possible implementation, a navigation map rendering task requires 20% of the total Central Processing Unit (CPU) utilization, 50 megabytes (MB) of memory, and 10 megabits per second (Mbps) of communication bandwidth.

[0048] In this embodiment, the resource information of the running platform refers to the amount of resources available for scheduling on the vehicle's onboard platform where the task to be executed is located, such as the number of CPU cores, available memory size, and network bandwidth limit. For example, in one possible implementation, a domain controller has 8 CPU cores, 4 gigabytes (GB) of memory, and 1 gigabit per second (Gbps) of Ethernet bandwidth under normal operating conditions.

[0049] In this embodiment, the status information of the operating platform refers to the working mode or operating stage of the task to be executed on the vehicle's onboard platform, such as power management status (power on, hibernation, wake-up), driving status (driving, parked), upgrade status (preparing for upgrade, downloading, upgrade completed), diagnostic status, and functional safety anomaly handling status. For example, in one possible implementation, some sensor tasks can be turned off to save power in the parking state, while all must be activated in the driving state.

[0050] In step 102, the multiple tasks to be executed are arranged based on their task attributes to obtain initial arrangement information.

[0051] In some embodiments, the step of orchestrating the plurality of tasks to be executed based on their task attributes to obtain initial orchestration information includes: determining the plurality of tasks to be executed running in the sub-state of each sub-platform in the vehicle platform; the resource information of the running platform is the resource information of the tasks to be executed in the corresponding sub-state of the sub-platform; and orchestrating the plurality of tasks to be executed based on the resource information of each sub-platform in the sub-state, and the running time and required resources of the plurality of tasks to be executed in the sub-state of each sub-platform to obtain the initial orchestration information.

[0052] It is understood that, in this embodiment of the application, the tasks to be executed under each sub-state of each sub-platform in the vehicle platform are determined separately. Based on the resource information of each sub-platform in its sub-state, the running time and required resources of multiple tasks to be executed under each sub-platform in its sub-state, multiple tasks to be executed are orchestrated, thereby achieving fine-grained scheduling by state dimension. In this way, the problems of resource conflicts or scheduling failures caused by ignoring platform state changes can be avoided, and the adaptability and stability of tasks to be executed in complex vehicle environments can be improved.

[0053] It should be understood that, in the embodiments of this application, a sub-platform refers to a hardware or software operating environment within an in-vehicle platform that has independent functional modules or computing units, such as domain controllers (e.g., advanced driver assistance domains, powertrain domains, body domains, etc.), chip cores, virtual machine instances, etc. Each sub-platform can independently run a specific set of tasks and possesses its own resource management capabilities. A sub-state refers to the specific working mode or operating stage of a sub-platform during operation, such as: normal operation, hibernation, upgrade in progress, diagnostic mode, parking state, driving state, fault recovery, etc. These sub-states are defined by the system architecture and are used to distinguish the platform's functional requirements and resource allocation strategies under different scenarios.

[0054] In this embodiment, the resource information of a sub-platform in a sub-state specifically refers to the total amount of resources available for task scheduling on the current sub-platform in that sub-state, including the number and utilization of available CPU cores, available memory size, I / O throughput, communication bandwidth, and cross-chip communication latency. The resource information of a sub-platform in a sub-state is dynamic and adjusts as the sub-state changes. For example, in a hibernation state, some resources may be disabled or have their usage restricted.

[0055] It is understood that, in the embodiments of this application, for each sub-platform sub-state, the tasks to be executed running in the sub-state of the sub-platform are identified, and based on the resource information in the sub-state of the sub-platform, the running time and required resources of multiple tasks to be executed in the sub-state of the sub-platform, the tasks to be executed and the platform state can be accurately matched, thereby avoiding resource waste or system abnormalities caused by scheduling tasks to be executed in inappropriate states, and thus improving the operating efficiency and stability of the vehicle system.

[0056] For example, in one possible implementation, all sub-platforms and their corresponding sub-states are traversed, and for each sub-platform-sub-state combination, a set of tasks to be executed that are allowed to run in the sub-state is extracted. For instance, when the Advanced Driver Assistance Systems (ADAS) domain controller is in driving mode, the vehicle system loads the perception tasks, decision-making tasks, control tasks, etc., that need to run in the sub-state; while in sleep mode, only low-power monitoring tasks are retained.

[0057] In this embodiment of the application, orchestration refers to the process of reasonably arranging multiple tasks to be executed according to the running time, required resources, and resource constraints of the sub-platform in the sub-state, so as to ensure that the tasks to be executed are smoothly scheduled and executed to meet the functional requirements of the vehicle system.

[0058] In some embodiments, Figure 2 This application provides a schematic diagram of an implementation process for obtaining initial arrangement information. Figure 1 ,like Figure 2As shown, the initial orchestration information is obtained by arranging the multiple tasks to be executed based on the resource information of each sub-platform in the vehicle platform in the sub-state, and the running time and required resources of the multiple tasks to be executed by each sub-platform in the sub-state, including the following steps 201 to 203: Step 201: For each sub-state of the sub-platform, determine the duration of the running threads of the plurality of tasks to be executed; Step 202: Based on the duration, create running threads for the multiple tasks to be executed; Step 203: Based on the resource information of each sub-platform in the vehicle platform in the sub-state, and the running time and required resources of the task to be executed by each sub-platform in the sub-state, the multiple tasks to be executed are placed in the running thread to obtain the initial orchestration information.

[0059] It is understood that, in the embodiments of this application, for each sub-platform's sub-state, the duration of the running thread in the corresponding sub-platform's sub-state is first determined, and then a running thread is created based on the duration. Subsequently, based on the resource information of each sub-platform in the vehicle platform in the sub-state, as well as the running time and required resources of the tasks to be executed on each sub-platform in the sub-state, a place is reserved in the corresponding running thread, thereby realizing the reasonable distribution of tasks to be executed on the time axis and the orderly management of resource occupation, thereby improving the determinism and efficiency of task scheduling.

[0060] In some embodiments, determining the duration of the plurality of pending task running threads for each sub-state of the sub-platform includes: creating a thread pool for running a plurality of pending tasks for each sub-state of the sub-platform; determining the duration of the plurality of pending task running threads; and correspondingly, creating running threads for the plurality of pending tasks based on the duration includes: creating running threads for the plurality of pending tasks in the thread pool according to the duration.

[0061] It is understood that in this embodiment of the application, by introducing a thread pool structure, the system overhead caused by frequently creating and destroying threads is reduced, while placeholder operations are used to ensure that tasks are not missed.

[0062] In this embodiment, the running thread of the task to be executed refers to the basic unit of operating system scheduling, used to carry and execute task logic. Creating a running thread for the task to be executed means starting a running thread for the task to be executed in a sub-state of a specific sub-platform to carry the task to be executed.

[0063] In this embodiment, creating running threads for the multiple tasks to be executed refers to initializing an independent execution context at the operating system level, providing a container for the subsequent scheduling and execution of the tasks. After creating running threads for multiple tasks, necessary resources are allocated to them, such as stack space, register context, and scheduling queue position. The creation process is completed by the smart device calling the underlying interface. After creation, the running threads for the tasks to be executed are in a ready state, waiting for the task scheduler to mount them onto the CPU core for execution. In this embodiment, one running thread can carry multiple tasks to be executed, but only one task can be executed at a time (in a single-core scenario).

[0064] In this embodiment, "placement" refers to the process of allocating an execution window for a task to be executed in terms of both timeline and resource dimensions. The placement operation needs to comprehensively consider the running time of the task to be executed, the required resources (CPU, memory, IO, communication bandwidth), and the available resources of the sub-platform corresponding to the task to be executed in the current sub-state.

[0065] In this embodiment of the application, the initial orchestration information refers to the preliminary scheduling scheme generated after the above-mentioned placeholder process, which includes the execution order, start time, and resource consumption of the tasks to be executed in each running thread, and finally forms the initial orchestration information of the tasks to be executed.

[0066] In some embodiments, determining the duration of the running threads of the plurality of pending tasks includes: determining the duration of the running threads of the plurality of pending tasks that have not been scheduled based on the inverted trapezoidal structure and the running time of the pending task that is first in the sorting result among the unscheduled pending tasks.

[0067] It is understood that in this embodiment, an inverted trapezoidal structure is used to determine the duration of multiple task execution threads based on the execution time of the first un-arranged task to be executed. This ensures that the capacity of the running threads is sufficient to accommodate the execution cycles of the tasks to be executed and reserves buffer space, thereby improving the resource utilization and scheduling efficiency of the running threads, and ultimately contributing to the optimization of overall scheduling performance.

[0068] In this embodiment, the inverted trapezoidal structure is a time allocation model. The core idea of ​​this structure is to dynamically determine the duration of a running thread based on the worst-case execution time of the task to be executed. The inverted trapezoidal structure is shaped like an inverted trapezoid, meaning that a shorter execution time corresponds to a shorter duration of the running thread, and a longer execution time corresponds to a progressively longer duration of the running thread. For example, if the WCET of the first task to be executed is 1 millisecond, then the duration of the first running thread is 10 milliseconds; if the WCET of a task to be executed exceeds 10 milliseconds (e.g., 15 milliseconds), then the duration of a newly created running thread is 30 milliseconds.

[0069] In this embodiment, un-arranged tasks refer to the set of tasks that have not yet been assigned to a specific thread pool by the intelligent placeholder algorithm. The task ranked first in the sorting result is the highest priority task that needs to be processed. The execution time of the un-arranged task ranked first directly determines the duration of the running thread, because the longer the execution time of the task, the longer the time window of the required running thread should be, in order to ensure that the task can be executed completely without being interrupted or preempted.

[0070] In some embodiments, the step of arranging the plurality of tasks to be executed in the running thread based on the resource information of each sub-platform in the sub-state of the vehicle platform, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state to obtain the initial orchestration information includes: sorting the plurality of tasks to be executed based on the priority and scheduling information of the tasks to be executed by each sub-platform in the sub-state to obtain a sorting result; and arranging the plurality of tasks to be executed in the running thread according to the sorting result, based on the resource information of each sub-platform in the sub-state of the vehicle platform, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state to obtain the initial orchestration information.

[0071] It is understood that in this embodiment, the priority and scheduling information of multiple tasks to be executed are sorted, and then combined with the resource information of each sub-platform in the vehicle platform in its sub-state, as well as the running time and required resources of the tasks to be executed on each sub-platform in its sub-state, the execution threads are assigned positions. This is beneficial for achieving a reasonable and orderly arrangement of tasks to be executed, thereby improving the determinism and resource utilization of task scheduling in the vehicle system, ensuring the timely execution of critical tasks, and reducing the complexity and error risk of vehicle system scheduling.

[0072] It should be understood that, in the embodiments of this application, the priority of a task to be executed refers to the importance or execution order of the task in the scheduling system, used to determine the order of execution of tasks during resource contention. In an in-vehicle system, the priority of a task to be executed is usually determined by the system architect and / or business development team based on factors such as business requirements, functional safety levels, real-time requirements, and task importance. Task priorities can be numerical (e.g., 1-100) or hierarchical (e.g., high, medium, low). Higher-priority tasks will receive CPU time slices or resource allocations before lower-priority tasks. For example, tasks related to brake control may be assigned the highest priority, while tasks related to the entertainment system may have a lower priority.

[0073] In this embodiment, the scheduling information of the task to be executed refers to a set of parameters describing the scheduling behavior of the task, including one or more of the following: task type (e.g., periodic, data-triggered), triggering conditions, dependencies, and scheduling strategy (e.g., preemptive, non-preemptive). This information collectively determines how the task to be executed is identified by the system, when it is awakened, and how it coordinates with other tasks for execution.

[0074] In this embodiment, the sorting result refers to the execution order sequence formed by logically arranging multiple tasks to be executed according to their priority and scheduling information in the sub-state. The sorting result reflects the recommended execution order of multiple tasks to be executed and serves as the basis for subsequent resource allocation and thread allocation.

[0075] For example, in one possible implementation, in a set containing 5 tasks (i.e., an example of tasks to be executed), the tasks are arranged from high to low priority, and when the priorities of the tasks are the same, the sorting is further refined according to the trigger time or dependency order in the scheduling information, and finally a clear execution order list is generated.

[0076] Furthermore, in some embodiments, the scheduling information of the task to be executed includes: the task to be executed that the task to be executed depends on; the step of sorting the multiple tasks to be executed based on the priority and scheduling information of the task to be executed in the sub-state of the sub-platform to obtain a sorting result includes: sorting the multiple tasks to be executed based on the priority and the task to be executed that the sub-platform depends on in the sub-state to obtain a sorting result.

[0077] It is understood that in this embodiment, by clarifying the data or logical dependencies between each task to be executed during the task orchestration stage, and comprehensively sorting them based on their priority, it is beneficial to avoid data errors or system crashes caused by improper execution order of each task to be executed. This improves the determinism and reliability of scheduling each task to be executed, thereby ensuring that the vehicle system can stably and efficiently execute various functional tasks in a complex and ever-changing operating environment.

[0078] It should be understood that, in the embodiments of this application, the tasks to be executed that a task to be executed depends on refer to other tasks to be executed that must be completed before the current task to be executed can be executed. This dependency relationship constitutes an execution order constraint between tasks to be executed. In some embodiments, the dependency relationship can be identified by the identification number (ID) or name of the task to be executed. If a first task to be executed depends on a second task to be executed, then the second task to be executed must be completed before the first task to be executed. This dependency relationship is common in data stream processing, state transition, or condition triggering scenarios. For example, a camera image preprocessing task depends on the completion of a sensor data acquisition task before it can be started.

[0079] For example, in one possible implementation, the first task to be executed has a priority of 80 and depends on the second task to be executed; the second task to be executed has a priority of 70 and has no dependency. First, it is identified that the second task to be executed must be executed before the first task to be executed. Then, the second task to be executed and the first task to be executed are sorted according to the priority of each task to be executed, and the final sorting result is generated as: [second task to be executed, first task to be executed].

[0080] In some embodiments, the priority of a task to be executed can be set statically or adjusted dynamically. Static priority is suitable for scenarios where the attributes of the task to be executed are stable, while dynamic priority can be automatically adjusted based on real-time load, platform status, or historical execution performance. The representation of other tasks to be executed that the task to be executed depends on can also be varied, such as using a directed graph structure to store other tasks to be executed that the task to be executed depends on, or defining the parent-child relationship between the task to be executed and other tasks to be executed through a configuration file.

[0081] In some embodiments, Figure 3 This application provides a schematic diagram of an implementation process for obtaining initial arrangement information. Figure 2 ,like Figure 3 As shown, according to the sorting result, based on the resource information of each sub-platform in the vehicle platform in the sub-state, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state, the multiple tasks to be executed are placed in the running thread to obtain the initial arrangement information, including the following steps 301 to 304: Step 301: Based on the sorting result, in response to the fact that the running time of the task to be executed in the sub-state of the sub-platform is less than or equal to the idle time of the running thread and the remaining platform resources in the platform resources allocated to the running thread in the sub-state of the sub-platform meet the resource requirements of the task to be executed, the task to be executed is placed in the running thread. Step 302: Based on the sorting results, in response to the fact that the running time of the task to be executed in the sub-state of the sub-platform is greater than the idle time of the thread, and / or that the remaining platform resources in the platform resources allocated to the running thread in the sub-state of the sub-platform do not meet the resource requirements of the task to be executed, a new running thread for the task to be executed is recreated. Step 303: Based on the resource information of the sub-platform corresponding to the un-arranged task to be executed in the sub-state of the vehicle platform, and the running time and required resources of the task to be executed in the sub-state of the sub-platform, the un-arranged task to be executed is placed in the new running thread. Step 304: Based on the pre-placed tasks already in the running thread and the pre-placed tasks not yet scheduled in the new running thread, the initial scheduling information is obtained.

[0082] It is understood that in this embodiment, if the execution time of a task to be executed does not exceed the idle time of the currently running thread and resources are sufficient, the task is reserved in the currently running thread to improve the utilization rate of the running thread; if not, a new running thread is created and the task continues to be reserved, ensuring that all tasks to be executed can be scheduled reasonably. This helps to avoid resource waste or scheduling timeouts caused by fixed running thread allocation, thereby ensuring the deterministic execution of tasks to be executed and system stability, and thus improving the overall efficiency and reliability of task scheduling on the sub-platform.

[0083] It should be understood that, in the embodiments of this application, the idle time of a running thread refers to the time period during which the currently running thread is not occupied within the scheduling cycle, usually expressed in milliseconds. The idle time of a running thread is equal to the period (i.e., duration) set when the running thread is created (e.g., 10 milliseconds, 20 milliseconds, etc.) minus the total running time of the tasks already allocated for execution. For example, if the thread period is 10 milliseconds and the accumulated running time of existing tasks is 7 milliseconds, then the remaining idle time is 3 milliseconds. When the running time of a new task to be executed does not exceed the remaining idle time, and the CPU, memory, IO, and other resources required by the task to be executed do not exceed the upper limit of the idle resources that the current sub-platform can provide in the current sub-state, the task to be executed can be inserted into the running thread to achieve efficient utilization of resources.

[0084] In this embodiment, "remaining platform resources satisfying the required resources" means that the resource requirements of the task to be executed, such as CPU, GPU, memory, and bandwidth, are less than or equal to the remaining platform resources allocated to the running thread in the sub-state of the sub-platform. For example, in a sub-state corresponding to a certain sub-platform, the system may provide 80% of the CPU resources for scheduling tasks for the running thread, while a task to be executed only requires 30% of the CPU, thus satisfying the condition.

[0085] For example, in one possible implementation, if the first task to be executed is an unarranged sorting result, and the task's execution time is ≤10ms and the required resources are ≤ the remaining platform resources allocated to the running thread in the sub-state of the sub-platform, then it is directly placed in place.

[0086] In this embodiment, by determining whether the execution time of the task to be executed is less than or equal to the idle time of the running thread, and whether the remaining platform resources allocated to the running thread in the sub-state of the sub-platform meet the resource requirements of the task to be executed, a decision is made on whether to reserve a slot for the task to be executed in the existing running thread. This avoids resource waste and task scheduling conflicts, thereby improving the utilization rate and scheduling efficiency of the running thread, and ultimately enabling better task orchestration.

[0087] In some embodiments, when the execution time of the task to be executed exceeds the remaining idle time of the running thread, and / or the resources required by the task to be executed exceed the remaining platform resources allocated to the running thread in the sub-state of the sub-platform, the task cannot be placed in the running thread. In this case, a new running thread needs to be created to accommodate the task to be executed.

[0088] In this embodiment of the application, the platform resources allocated to the running thread in the sub-state of the sub-platform refer to the unoccupied platform resources allocated to the running thread in the sub-state of the sub-platform based on the resource information of the sub-platform in the sub-state.

[0089] In this embodiment, the duration of the new running thread follows an inverted trapezoidal structure principle, that is, the duration of the new running thread is dynamically adjusted according to the worst-case execution time of the task to be executed. For example, if the worst-case execution time of the task to be executed is 5ms, then a new running thread with a duration of 30ms is created; if it is 15ms, then a new running thread with a duration of 50ms is created.

[0090] For example, in one possible implementation, when it is detected that a space cannot be reserved in the running thread, a new running thread creation process is initiated, and the scheduling parameters of the new running thread are initialized. The new running thread inherits the state information of the current sub-platform, ensuring that the task to be executed runs stably on the platform corresponding to the new running thread. At the same time, the resource consumption of the new running thread is recorded to provide data support for subsequent iterative optimization.

[0091] In this embodiment of the application, by creating a new running thread when the running time of the task to be executed exceeds the idle time of the running thread and / or when the remaining platform resources allocated to the running thread in the sub-state of the sub-platform do not meet the resource requirements of the task to be executed, the task to be executed can be prevented from being blocked or scheduled to fail, thereby ensuring the deterministic execution of the task to be executed.

[0092] In this embodiment, un-arranged tasks refer to those that failed to secure a running thread. These un-arranged tasks need to be assigned to newly created running threads. Based on the sorting results, the running time and required resources of the un-arranged tasks are evaluated sequentially, and the un-arranged tasks are placed into newly created running threads until the newly created running threads are fully loaded, the available resources corresponding to the running threads are exhausted, or all tasks are arranged.

[0093] In this embodiment, the placeholder logic in the new running thread is consistent with that of the running thread: First, it checks whether the running time of the task to be executed is less than or equal to the idle time of the new running thread, and verifies whether the resources required by the task to be executed are less than or equal to the remaining platform resources allocated to the new running thread in the sub-state of the sub-platform. If the conditions are met, a placeholder is set; otherwise, if there are still unprocessed tasks to be executed, the next new thread needs to be created until all tasks to be executed are orchestrated.

[0094] For example, in one possible implementation, assume there are 100 tasks to be executed while the vehicle is in motion. The WCET (Time Between Executions) of the first five tasks are 2ms, 3ms, 1ms, 4ms, and 5ms, respectively. The available CPU resources allocated to the running threads in the sub-state of the sub-platform are 80%. First, a running thread for a 10ms task is created, and the first three tasks (2+3+1=6ms) are inserted into this thread. The fourth task requires 4ms; since 6+4=10ms is exactly equal to the duration of the running thread, and the remaining CPU resources in this thread meet the requirements of the fourth task, it successfully takes its place. The fifth task requires 5ms, and it cannot be inserted into the already created thread. Therefore, a new running thread (20ms) is created to continue taking its place. This process continues until all tasks are scheduled.

[0095] In step 103, based on the initial orchestration information, the multiple tasks to be executed are scheduled and executed to obtain the first scheduling and execution result.

[0096] In some embodiments, when the intelligent device is a host computer, the initial orchestration information is imported into the test carrier corresponding to the vehicle, so that the test carrier schedules and executes the multiple tasks to be executed based on the initial orchestration information to obtain the first scheduling and execution result.

[0097] In some embodiments, when the smart device is a vehicle or a test vehicle, the plurality of tasks to be executed are scheduled and executed based on the initial orchestration information to obtain the first scheduling and execution result.

[0098] It should be understood that, in the embodiments of this application, the test vehicle refers to a hardware platform used to simulate the in-vehicle platform environment of a vehicle or a real vehicle corresponding to the vehicle, possessing the same in-vehicle platform architecture, processor model, operating system type, communication protocol stack, and resource configuration as the vehicle. For example, the test vehicle can be a highly realistic test bench equipped with domain controllers, sensor modules, and actuators identical to those in a vehicle, used to verify the effectiveness of the orchestration scheme before the vehicle's formal mass production.

[0099] In some embodiments, the step of scheduling and executing the plurality of tasks to be executed based on the initial orchestration information to obtain the first scheduling and execution result further includes: generating a scheduling interface for the plurality of tasks to be executed; and scheduling and executing the plurality of tasks to be executed based on the initial orchestration information and the scheduling interface of the plurality of tasks to be executed to obtain the first scheduling and execution result.

[0100] It is understood that in this embodiment, by generating a scheduling interface for the tasks to be executed, and based on the initial orchestration information and the scheduling interfaces of multiple tasks to be executed, multiple tasks to be executed are scheduled and executed to obtain the first scheduling execution result. This is beneficial for achieving standardization and automation of task scheduling, thereby decoupling the resource matching problem between the business development team and the specific vehicle platform, and thus improving the engineering level and resource utilization of the whole vehicle system, ensuring the stable operation and functional safety of the vehicle system.

[0101] It should be understood that, in the embodiments of this application, the scheduling interface refers to a set of standardized function interfaces automatically generated based on the task orchestration results. These interfaces are used to control and manage the lifecycle of tasks to be executed on the vehicle platform and to implement communication functions. The scheduling interface includes a creation interface, an initialization interface, an execution interface, an uninitialization interface, a destruction interface, and a communication interface, which correspond to the instantiation, resource binding, execution triggering, resource release, object cleanup, and data communication of the task object to be executed, respectively. For example, the creation interface Create{ABC}Handler is used to instantiate the task ABC object to be executed, the initialization interface Init{ABC}Handler is used to configure the event triggers and asynchronous executors required for the execution of the task ABC object, and the execution interface Run{ABC}Handler is used to actually execute the logic of the task ABC object to be executed.

[0102] In this embodiment, scheduled execution refers to the test platform running multiple tasks to be executed in an orderly, timed, or conditionally triggered manner according to preset initial orchestration information. The scheduled execution process includes stages such as task creation, initialization, scheduled execution, deinitialization, and destruction, ensuring that the tasks to be executed are correctly invoked at specified times or under specified conditions. During scheduled execution, the test platform monitors the running time, resource consumption, and scheduling execution results of the tasks to be executed for subsequent iterative optimization.

[0103] In this embodiment, the initial scheduling execution result refers to the actual operational data obtained after scheduling and executing multiple tasks based on initial orchestration information on a test vehicle or platform. The actual operational data includes key indicators such as the actual execution time, resource consumption, scheduling delay, and task completion rate for each task.

[0104] In step 104, target orchestration information is determined based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed.

[0105] It should be understood that, in the embodiments of this application, when the intelligent device is a host computer, after receiving the initial scheduling execution result returned by the test carrier or vehicle, the target orchestration information is determined based on the initial scheduling execution result and the task attributes of multiple tasks to be executed. This improves the practicality and robustness of the target orchestration information, addressing the issue of fluctuations in actual operation and achieving a smooth transition from theoretical design to engineering implementation.

[0106] In some embodiments, Figure 4 A schematic diagram of an implementation process for determining target orchestration information provided in this application embodiment. Figure 1 ,like Figure 4As shown, determining the target orchestration information based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed includes the following steps 401 to 404: Step 401: Based on the initial scheduling execution result, update the task attributes of at least one of the tasks to be executed; Step 402: Based on the updated task attributes of the tasks to be executed, arrange multiple tasks to be executed to obtain secondary arrangement information; Step 403: Based on the secondary orchestration information, schedule and execute the multiple tasks to be executed to obtain the secondary scheduling and execution result; Step 404: If the result of the secondary scheduling execution does not meet the deterministic scheduling requirement, replace the result of the primary scheduling execution with the result of the secondary scheduling execution, replace the task attributes of the task to be executed with the updated task attributes of the task to be executed, and iterate the above steps until the result of the secondary scheduling execution meets the deterministic scheduling requirement, and determine the secondary orchestration information as the target orchestration information.

[0107] It is understood that in the task orchestration method provided in this application embodiment, the task attributes are updated in reverse based on the initial scheduling execution result, and then secondary orchestration information is generated based on the updated task attributes and verified again; the process continues to iterate when deterministic scheduling is not satisfied until deterministic scheduling is satisfied. In this way, by making full use of actual operating data, automatically correcting task attributes and re-arranging, the practicality and reliability of the target orchestration information are significantly improved, thereby adapting to the dynamic operating environment of the vehicle.

[0108] It should be understood that, in the embodiments of this application, when the initial scheduling execution result indicates that some pending tasks have problems such as timeout, resource contention, or scheduling failure, the task attributes of the corresponding pending tasks are dynamically adjusted according to the initial scheduling execution result. For example, if a pending task times out due to insufficient resources, the CPU resources allocated to the pending task can be appropriately increased or the execution time of the pending task can be extended; if a pending task fails to start due to unmet dependencies, the triggering conditions of the pending task can be optimized or the dependency order of the pending task can be adjusted.

[0109] In this embodiment, secondary orchestration information refers to a new round of scheduling information generated after task attributes are updated and tasks are re-orchestrated. Secondary orchestration information includes detailed information such as task execution order, timing, resource allocation, thread binding, and dependency handling.

[0110] In this embodiment, the smart device recalculates the scheduling window and resource usage of the tasks to be executed based on the updated task attributes and platform resource information. For example, if the execution time of task A is extended, the time conflict between task A and other tasks to be executed is reassessed, and task A may be moved to a new scheduling cycle. At the same time, resources such as CPU and memory are reallocated according to resource changes to ensure that all tasks to be executed can be executed smoothly under constraints.

[0111] In this embodiment of the application, by re-arranging the multiple tasks to be executed based on the updated task attributes, scheduling information that is more in line with the actual operating conditions can be generated, thereby improving the success rate and efficiency of the tasks to be executed, and thus enhancing the overall performance and reliability of the vehicle system.

[0112] In this embodiment, when the intelligent device is a host computer, the generated secondary orchestration information is imported into the vehicle's test platform or vehicle. Upon receiving the information, the test platform or vehicle schedules and executes each task according to the secondary orchestration information. During this process, the test platform or vehicle continuously monitors the execution status, resource usage, and time latency of the tasks to be executed, and summarizes this data to form the secondary scheduling execution result. The secondary scheduling execution result can be used to evaluate the effectiveness of the secondary orchestration information and provide a basis for subsequent iterations.

[0113] In this embodiment, when the intelligent device is a vehicle or a test platform for a vehicle, each task to be executed is scheduled and executed according to the secondary orchestration information. During this process, the test platform or vehicle continuously monitors the execution status, resource usage, and time latency of the tasks to be executed, and summarizes this data to form the secondary scheduling execution result. The secondary scheduling execution result can be used to evaluate the effectiveness of the secondary orchestration information and provide a basis for subsequent iterations.

[0114] In this embodiment of the application, by scheduling and executing multiple tasks to be executed based on secondary orchestration information, the feasibility of secondary orchestration information in a real environment can be verified, thereby obtaining accurate operational feedback and supporting subsequent optimization decisions and closed-loop iterations.

[0115] It should be understood that, in the embodiments of this application, deterministic scheduling refers to the ability of a task to be executed reliably within a predetermined time window in an in-vehicle system, and the high predictability and stability of key indicators such as resource consumption, execution time, and scheduling latency of the scheduling mechanism. Judgment criteria typically include: the task completing on time more than 99.99% of millions of runs, resource consumption not exceeding a preset threshold, and no deadlock or starvation phenomena. Meeting deterministic scheduling implies that the in-vehicle system possesses high reliability and can ensure the safe operation of in-vehicle functions.

[0116] In this embodiment, the intelligent device can automatically evaluate the secondary scheduling execution result. If problems such as task timeout, resource overflow, or scheduling failure are still found, the initial scheduling execution result is replaced with the secondary scheduling execution result, and the task attributes are replaced with the updated task attributes. The iterative process of steps 401 to 403 is executed again until the finally generated secondary orchestration information can stably satisfy deterministic scheduling.

[0117] In some embodiments, Figure 5 A schematic diagram of an implementation process for determining target orchestration information provided in this application embodiment. Figure 2 ,like Figure 5 As shown, determining the target orchestration information based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed includes the following steps 501 to 505: Step 501: Display the initial scheduling execution result, the multiple tasks to be executed, and the task attributes of the multiple tasks to be executed; Step 502: Receive the updated task attributes of multiple tasks to be executed; Step 503: Based on the three-stage orchestration information, schedule and execute the multiple updated tasks to be executed to obtain the three-stage orchestration information; Step 504: Based on the three orchestration information, schedule and execute multiple updated tasks to be executed to obtain the three scheduling and execution results; Step 505: If the results of the three scheduling executions do not satisfy deterministic scheduling, replace the results of the first scheduling execution with the results of the three scheduling executions, replace the task attributes of the task to be executed with the updated task attributes of the task to be executed, and iterate the above steps until the results of the three scheduling executions satisfy deterministic scheduling, and determine the three orchestration information as the target orchestration information.

[0118] It is understood that the task orchestration method provided in this application embodiment supports manual intervention in the orchestration process. By displaying the initial scheduling result, multiple tasks to be executed, and task attributes, users can edit and update tasks. Then, based on the updated task attributes, a new round of orchestration and verification is performed, achieving human-machine collaborative optimization. This approach balances automation and flexibility in orchestration, is suitable for stages where tasks to be executed change frequently, and effectively shortens the orchestration iteration cycle, thereby improving engineering efficiency.

[0119] In some embodiments, the smart device displays the initial scheduling execution results in a table or graphical format within the user interface, listing all pending tasks and their corresponding task attribute information. For example, through a visual interface, users can intuitively see that a pending task failed to execute on time due to resource conflicts while the vehicle is in motion, thus determining whether to adjust the task attributes or delete the pending task. This visualization helps architects quickly locate problems and improve debugging efficiency.

[0120] It should be understood that, in the embodiments of this application, the updated pending task refers to the task attributes of a pending task that is added, deleted, or modified after the initial orchestration, based on feedback from actual vehicle operation or changes in business requirements. For example, when a new autonomous driving perception module task is added, the newly added autonomous driving perception module task is the updated pending task. The task attributes of the updated pending task include: the updated task attributes of the pending task or the modified parameter configuration of the original pending task that was not deleted, such as adjusting the execution time, increasing resource requirements, or changing trigger conditions.

[0121] In this embodiment, tertiary orchestration information refers to a set of scheduling scheme data generated by re-orchestrating the updated tasks after updating their task attributes. This data includes task scheduling order, thread allocation, resource allocation planning, and execution time windows. Tertiary orchestration information serves as a crucial bridge connecting orchestration logic and test execution, guiding the test platform in subsequent scheduling and execution.

[0122] In this embodiment, the three-stage scheduling execution result refers to the set of operational data obtained by the test vehicle or vehicle after executing the three orchestration information processes. This data includes indicators such as the execution time, resource usage, scheduling success rate, and jitter error for each task to be executed. The three-stage scheduling execution result is used to determine whether the three orchestration information processes meet deterministic scheduling requirements, such as the task being completed on time 99.99% of the time in millions of runs.

[0123] In the embodiments of this application, the target orchestration information refers to the scheduling scheme data that meets the deterministic scheduling requirements and is finally confirmed after iterative optimization. It includes the scheduling sequence of tasks to be executed, thread allocation, resource planning, etc., and is the final configuration deployed to the vehicle platform for actual operation.

[0124] It should be understood that in the embodiments of this application, when the results of the three scheduling executions do not satisfy the deterministic scheduling, the current three scheduling execution results are taken as the first scheduling execution result, and the updated task attributes of the current task to be executed are taken as the new input, and the loop of steps 501 to 504 is re-entered until the deterministic scheduling is satisfied.

[0125] In step 105, based on the target orchestration information, multiple tasks to be executed in the target orchestration information are scheduled and executed.

[0126] It should be understood that, in the embodiments of this application, when the intelligent device is a host computer, the target orchestration information is imported into the vehicle so that the vehicle can schedule and execute multiple tasks to be executed in the target orchestration information based on the target orchestration information.

[0127] In some embodiments, target orchestration information is imported into the vehicle's onboard platform via a secure channel (such as encrypted transmission).

[0128] The following describes an exemplary application of the embodiments of this application in a real-world application scenario.

[0129] As the market share of new energy vehicles gradually increases, the scenarios that in-vehicle systems with assisted driving and intelligent driving technologies need to face are becoming increasingly complex, and the number and complexity of the tasks to be executed are also growing exponentially. This problem requires a systematic and engineering-oriented solution. When these tasks are running on the in-vehicle platform, a deterministic framework is needed for scheduling and execution to achieve determinism. Simultaneously, it is also necessary to address how to optimally and efficiently match these tasks with different in-vehicle platforms for scheduling and operation before deployment to the actual vehicle platform. How to decouple the business development team from the matching of different resources on different in-vehicle platforms? How to efficiently and quickly iterate and match each change to the tasks made by the business development team before deployment on the in-vehicle system platform? After deployment to the actual vehicle, how to use this operational data for automated matching of in-vehicle platform resources to achieve optimal orchestration? And how to automatically match the operational parameters for subsequent addition, deletion, modification, and improvement of tasks for deterministic scheduling to the in-vehicle platform?

[0130] This application provides an orchestration system for deterministic task scheduling on an in-vehicle platform, which is used to automatically orchestrate tasks that require deterministic scheduling on the in-vehicle system and generate corresponding deterministic scheduling information.

[0131] First, based on the requirements of scheduling management within a deterministic scheduling framework, various tables for deterministic task scheduling (i.e., an example of a task to be executed) are designed. Based on this, a deterministic scheduling orchestration tool, DTSF-tool, is developed. The orchestration tool's functions include: integrating algorithms such as intelligent placeholders; automatically orchestrating based on input information (i.e., an example of the task attributes of the task to be executed); generating interface code for corresponding task scheduling execution, various tables for orchestrated deterministic task scheduling, and communication interface code for input / output information required for task execution based on SOA (where communication protocols are not limited to: Scalable service-oriented middleware over Internet Protocol (some / IP), Data Distribution Service (DDS), and shared memory); and automatically iteratively optimizing by importing information recorded during actual vehicle operation.

[0132] Next, the system architect and business development team decomposed the tasks running on various in-vehicle platforms into atomic tasks based on the scenarios. The architect and business team, according to design requirements, initially confirmed various scheduling information, platform resource information (including communication time consumption), and platform status information for each atomic task, generating a corresponding three-dimensional information table. This information was then input into the orchestration tool, where algorithms such as intelligent placeholders automatically generated various deterministic scheduling tables, scheduling interfaces, and corresponding information communication interfaces.

[0133] Finally, these deterministic scheduling tables, scheduling interfaces, and corresponding information communication interfaces are integrated and deployed into various in-vehicle platforms. The deterministic scheduling framework is then used to run the system, yielding an initial version of the results (an example of the initial scheduling results). The results from running the system on a real vehicle or test bench (the actual hardware platform) (an example of the test vehicle) (an example of the initial scheduling results) are then imported into the orchestration tool to check if the deterministic scheduling execution results meet expectations. The criteria for judgment include whether 99.99% of the task execution results from a million runs are scheduled and executed according to a normal distribution. If not, the corresponding parameters are adjusted through the adaptive mechanism in the intelligent placeholder algorithm, and the process is automatically iterated until the criteria are met.

[0134] The orchestration tool can reside on a host computer (i.e., a laptop, tablet, server, etc.), a vehicle, or a vehicle's test platform. Each business development team doesn't need to consider task scheduling, leading to better platformization and engineering of the entire vehicle business development. This decouples business development teams from task orchestration and scheduling execution, allowing them to better leverage their respective expertise. It provides a superior architectural solution for the entire vehicle system architecture, enabling automatic adaptation to various in-vehicle platforms. This results in better utilization of vehicle platform resources, allowing the vehicle to perform more tasks or complete the same tasks more stably using lower-cost chip resources. Simultaneously, it ensures the stable operation of the in-vehicle system platform, meeting in-vehicle functional safety requirements and thus guaranteeing vehicle safety.

[0135] The task scheduling and orchestration tool "DTSF-tool" (Deterministic TaskScheduling Framework tool) developed in this application supports running on Linux, Windows, Android and other systems. Figure 6 A framework diagram of a task scheduling and orchestration tool provided in this application embodiment is shown below. Figure 6 As shown, the task scheduling and orchestration tools include: Define vehicle model project: vehicle platform definition, system type (Linux, QNX, etc.), system scheduling jitter time (in milliseconds or microseconds), platform resource size, system running core information, total CPU, total graphics processing unit (GPU), total memory, I / O, bandwidth, platform communication time consumption (system platform, cross-chip communication time consumption, such as in microseconds or milliseconds).

[0136] Information on the task execution platform, including the CPU, GPU, memory, I / O, and bandwidth used for orchestration tasks; and the platform's various states, such as: power management (power-on process, normal operation, hibernation, hibernation wake-up, etc.), upgrade (preparing for upgrade, upgrade download, upgrade in progress, upgrade completed), diagnostics, driving status, parking status, and functional safety handling anomalies.

[0137] It integrates algorithms such as intelligent placement to perform automated initial arrangement based on input information.

[0138] By orchestrating and generating a deterministic task scheduler, information such as the task scheduling interface and the SOA-based service communication interface is output.

[0139] The output "deterministic scheduling table" is encrypted using an asymmetric encryption method to ensure security and reliability.

[0140] Import vehicle model information that has been initially compiled, perform basic operations such as editing, modifying, and deleting, and make judgments and optimizations based on information recorded during actual vehicle or bench operation to improve the compilation.

[0141] Import information recorded during the actual vehicle or bench operation of the task, and perform iterative orchestration for automated correction and optimization.

[0142] The task deterministic scheduling table output by the orchestration tool is detailed in Table 1.

[0143] Table 1

[0144] The task deterministic scheduling table includes: Task ID: an automatically generated number by the orchestration tool; Task Name: a string selected by the system architect and business development team; Task Type: periodic, data-triggered, or logic-based, selected and entered by the development team in the visual orchestration tool based on the system architecture design; Task Scheduling Strategy: the scheduling strategy provided by the system platform, core binding requirements, and task priority; Platform Resources Consumed by the Task: the CPU, memory, IO, and communication bandwidth consumed by the system platform during task execution; Task Execution Time: the time the task takes to run during scheduling, in milliseconds; obtained after multiple runs on the corresponding platform; Task Trigger Signal: the signal triggered by the availability of data or... Event signals trigger the scheduling of trigger-type tasks. These tasks are executed by subscribing to signals based on SOA service-oriented communication. The execution process may be one-off or periodic. The tasks depend on include: task name or task ID; platform status (defined by system architecture analysis); whether the task is running under the platform status (boolean type); the name of the data receiving service (the service requiring SOA service-oriented communication, including data format and corresponding interfaces, defined by the business team); and the name of the data sending service (the service requiring SOA service-oriented communication, including data format and corresponding interfaces, defined by the business team).

[0145] The orchestration tool outputs interfaces for scheduling by the deterministic scheduling framework, including: create, initialize, execute, deinitialize, and destroy interfaces. Details are as follows, where ABC represents the task name: (1) Create interface: Create{task_name}Handler, the parameter is a string array: task_name + parameters specified in the configuration file; returns a pointer to a task object, or a null pointer if object creation fails. Example as follows: extern void CreateABCHandler(const std::vector <std::string>&); (2) Initialization interface: Init{task name}Handler, the first parameter is a pointer to the task object created by the creation interface, the second parameter is the event task execution trigger, and the third parameter is the function asynchronous executor; the return value indicates whether the initialization was successful. An example is as follows: extern bool InitABCHandler(void , const TaskRunTrigger&, constAsyncExecTrigger&); (3) Execution interface: Run{task name}Handler, the first parameter is a pointer to the task object created by the creation interface, the second parameter is the execution data (currently empty), and there is no return value. An example is shown below: extern void RunABCHandler(void void ); (4) Deinitialization interface: Deinit{task name}Handler, the parameter is a pointer to the task object created by the creation interface, and it has no return value. An example is shown below: extern void DeinitABCHandler(void ); (5) Destroy interface: Delete{task name}Handler, the parameter is a pointer to the task object created by the creation interface, and it has no return value. Example as follows: extern void DeleteABCHandler(void ).

[0146] In some embodiments, automatic task orchestration is based on a three-dimensional information table compiled and confirmed by the architect and business team: the status dimension of the task execution platform (X-axis), the various resources of the task execution platform (Y-axis), and the resources required for task execution (Z-axis).

[0147] First, based on the vehicle chip platform's resource and performance information, the platform system scheduling accuracy, and the required jitter error for scheduling, the creation time for the task execution thread pool is determined according to an inverted trapezoidal structure. The determination method is as follows: if the worst-case execution time (WCET) of a task is 1 or 2 milliseconds, the first thread created will have a time limit of 10 milliseconds. A single thread (i.e., an example of a running thread) can insert multiple tasks; the basic calculation formula is: T ≥ WCET. N (N≥2) is rounded up based on system scheduling accuracy and jitter error, and T is the duration of the thread.

[0148] Once the time for the first thread pool thread is determined, the system resources provided by the system in each state are loaded according to the first dimension (X-axis), which is the state dimension of the task execution platform. The system resources provided in each state are loaded according to the second dimension (Y-axis). The third dimension, task information, which is the resources required for task execution, is calculated based on the first two dimensions.

[0149] For example, in one possible implementation, a thread is created for each state in the first dimension. Then, the tasks in the third dimension are sorted according to scheduling policies, priorities, and other information. Simultaneously, the system resource information (CPU, GPU, memory, etc.) for each state provided by the second dimension is loaded. If the resources required by the first task in the third dimension after sorting are less than or equal to the resources allocated to the corresponding thread based on the resource information of the second dimension, then the intelligent placeholder algorithm "inserts" the third-dimensional task into the first created thread. Taking the task WCET (time t1) in the third dimension (which includes communication time if the task needs to receive or send data) and the required CPU (scpu1) as an example, the following conditions must be met: t1 ≤ 10 milliseconds, scpu1 ≤ scpu (resources providing deterministic task scheduling for threads in this state). By extrapolating from this, if t1+t2+t3+……tn≤10 milliseconds, and scpu1+scpu2+scpu3+……scpun≤scpu (scpun refers to the CPU resources required by task n, and scpu refers to the idle CPU of the system), then the thread is "inserted". When the condition is no longer met, a new thread is created, and subsequent tasks are inserted into the orchestration as placeholders.

[0150] When the WCET (time period) of the task in the third dimension is greater than 10 milliseconds, the newly created thread (an example of a newly running thread) will have a time period of 20 milliseconds, increasing according to the gradient value. This logic is repeated until the insertion condition is no longer met, at which point placeholder insertion stops.

[0151] The method for obtaining the execution time of the orchestration task involves separately calling the task on the actual vehicle hardware platform, simulating all input data for the task to run more than a million times, and statistically analyzing the execution time of each run. Using a normal distribution, the execution time range that the actual running time falls into in 99.99% of cases is obtained, and the maximum execution time within this range is taken as the execution time of the task.

[0152] Finally, by importing the result data from all scenarios of real-vehicle operation into the orchestration tool, the actual resource usage and execution time required for the task under various platform states are matched with the output of the previous orchestration. Corresponding intelligent placeholder and other algorithm models are invoked for learning and iterative orchestration of tasks for inclusion or removal. The function expressed by the task may differ under different platform states, and the actual time required may also vary. This orchestration can better match the development of the platform and application, decoupling the development architecture thinking of the task development team.

[0153] Figure 7 This application provides a schematic diagram of an implementation process for obtaining initial arrangement information. Figure 3 ,like Figure 7 As shown, the initial arrangement information can be obtained through the following steps 701 to 707; Step 701: Collect information on the platform and tasks; The task information includes a three-dimensional information table of the input tasks (periodic tasks, data-triggered tasks, and logic-based tasks); the platform information is vehicle platform information. Step 702: Calculate the thread creation time based on the input task information; Step 703: Create a task thread pool; Step 704: Determine whether the insertion condition is met based on the task information; if the insertion condition is met, proceed to step 705; otherwise, proceed to step 707. Step 705: Call the intelligent placeholder algorithm to complete task orchestration; Step 706 yields the periodic task scheduling table, the data-triggered task scheduling table, the logical task scheduling table, the task data receiving service, the task data sending service, and the task scheduling interface code. Step 707: Increase the time for creating new threads according to the "inverted trapezoid" shape, and then execute step 703; The initial orchestration information is obtained once all tasks are orchestrated.

[0154] In some embodiments, invoking algorithms such as smart placeholders includes orchestrating (training) models.

[0155] Figure 8 A schematic diagram of an implementation process for determining target orchestration information provided in this application embodiment. Figure 3 ,like Figure 8 As shown, the target arrangement information can be determined through the following steps 801 to 807: Step 801: Import actual vehicle operation scheduling information; Step 802: Compare with the previous round of arrangement expectations; if not, proceed to step 803; otherwise, end. Step 803: Has the code been manually edited and perfected? If so, proceed to step 804; otherwise, proceed to step 805. Step 804: Obtain the updated task orchestration information; Step 805: Automatically update task orchestration information; Step 806: Invoke algorithms such as intelligent placeholders and orchestrate (train) the model; Step 807 yields the periodic task scheduling table, the data-triggered task scheduling table, the logical task scheduling table, the task data receiving service, the task data sending service, and the task scheduling interface code. The content obtained in step 807 is compared with the scheduling information obtained in step 807 in the next round, and is used as the scheduling expectation of the previous round corresponding to the next round.

[0156] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of this application without departing from the spirit and scope of the technical solutions of this application, and all such modifications or substitutions should be covered within the protection scope of this application.

[0157] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that these steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps; or steps from different embodiments may be combined into a new technical solution. Based on the foregoing embodiments, this application provides an apparatus comprising the included modules and the units included in each module, which can be implemented by a processor; of course, it can also be implemented by specific logic circuits; in implementation, the processor can be an AI acceleration engine (such as an NPU), a graphics processing unit (GPU), a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP), or a field-programmable gate array (FPGA), etc.

[0158] Figure 9 This is a schematic diagram of a task orchestration device provided in an embodiment of this application, as shown below. Figure 9 As shown, the task orchestration device 90 includes: an acquisition module 901, an orchestration module 902, a first scheduling execution module 903, a determination module 904, and a second scheduling execution module 905; wherein, The acquisition module 901 is configured to acquire the task attributes of multiple tasks to be executed; the task attributes include: running time, required resources, resource information of the running platform, and status information of the running platform; The orchestration module 902 is configured to orchestrate the multiple tasks to be executed based on their task attributes to obtain initial orchestration information; The first scheduling and execution module 903 is configured to schedule and execute the multiple tasks to be executed based on the initial orchestration information, and obtain the first scheduling and execution result; The determination module 904 is configured to determine target orchestration information based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed; The second scheduling and execution module 905 is configured to schedule and execute multiple tasks to be executed in the target orchestration information based on the target orchestration information.

[0159] In some embodiments, the orchestration module 902 is further configured to determine the plurality of tasks to be executed running in the sub-state of each sub-platform in the vehicle platform; the resource information of the running platform is the resource information of the tasks to be executed in the corresponding sub-state of the sub-platform; based on the resource information of each sub-platform in the sub-state of the vehicle platform, and the running time and required resources of the plurality of tasks to be executed in the sub-state of each sub-platform, the plurality of tasks to be executed are orchestrated to obtain the initial orchestration information.

[0160] In some embodiments, the orchestration module 902 is further configured to determine the duration of the running threads of the plurality of tasks to be executed for each of the sub-states of the sub-platform; create running threads for the plurality of tasks to be executed based on the duration; and place the plurality of tasks to be executed in the running threads based on the resource information of each sub-platform in the sub-state, as well as the running time and required resources of the tasks to be executed on each sub-platform in the sub-state, to obtain the initial orchestration information.

[0161] In some embodiments, the orchestration module 902 is further configured to sort the plurality of tasks to be executed based on the priority and scheduling information of the tasks to be executed by the sub-platform in the sub-state, and obtain a sorting result; according to the sorting result, based on the resource information of each sub-platform in the sub-state, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state, the plurality of tasks to be executed are placed in the running thread to obtain the initial orchestration information.

[0162] In some embodiments, the orchestration module 902 is further configured to, based on the sorting result, in response to the sub-platform's task-to-be-executed running time being less than or equal to the idle time of the running thread in the sub-state and the remaining platform resources in the platform resources allocated to the running thread in the sub-state of the sub-platform satisfying the resource requirements of the task-to-be-executed, place the task-to-be-executed in the running thread; based on the sorting result, in response to the sub-platform's task-to-be-executed running time being greater than the idle time of the thread in the sub-state, and / or, in the sub-state of the sub-platform... If the remaining platform resources allocated to the running thread do not meet the resource requirements of the task to be executed, a new running thread for the task to be executed is created. Based on the resource information of the sub-platform corresponding to the un-arranged task to be executed in the sub-state of the vehicle platform, and the running time and required resources of the task to be executed in the sub-state of the sub-platform, the un-arranged task to be executed is placed in the new running thread. Based on the task to be executed that has been placed in the running thread and the un-arranged task to be executed in the new running thread, the initial arrangement information is obtained.

[0163] In some embodiments, the orchestration module 902 is further configured to determine the duration of the running threads of the plurality of unorchestrated tasks based on the inverted trapezoidal structure and the running time of the task that is first in the sorting result among the unorchestrated tasks.

[0164] In some embodiments, the determining module 904 is configured to update the task attributes of at least one of the tasks to be executed based on the initial scheduling execution result; orchestrate the plurality of tasks to be executed based on the updated task attributes of the tasks to be executed to obtain secondary orchestration information; schedule and execute the plurality of tasks to be executed based on the secondary orchestration information to obtain a secondary scheduling execution result; if the secondary scheduling execution result does not satisfy deterministic scheduling, replace the initial scheduling execution result with the secondary scheduling execution result, replace the task attributes of the tasks to be executed with the updated task attributes of the tasks to be executed, and iteratively execute the above steps until the secondary scheduling execution result satisfies deterministic scheduling, and determine the secondary orchestration information as the target orchestration information.

[0165] In some embodiments, the determining module 904 is configured to display the initial scheduling execution result, the plurality of tasks to be executed, and the task attributes of the plurality of tasks to be executed; receive the task attributes of the plurality of updated tasks to be executed; based on the task attributes of the plurality of updated tasks to be executed, orchestrate the plurality of updated tasks to be executed to obtain three orchestration information; based on the three orchestration information, schedule and execute the plurality of updated tasks to be executed to obtain three scheduling execution results; if the three scheduling execution results do not satisfy deterministic scheduling, replace the initial scheduling execution result with the three scheduling execution results, replace the task attributes of the tasks to be executed with the updated task attributes of the tasks to be executed, iteratively execute the above steps until the three scheduling execution results satisfy deterministic scheduling, and determine the three orchestration information as the target orchestration information.

[0166] In some embodiments, the task orchestration device 90 further includes: a generation module; the generation module is configured to generate a scheduling interface for the plurality of tasks to be executed; and based on the initial orchestration information and the scheduling interface of the plurality of tasks to be executed, schedules and executes the plurality of tasks to be executed to obtain the first scheduling execution result.

[0167] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0168] It should be noted that the module division in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or have two or more units integrated into one unit. The integrated units can be implemented in hardware, as software functional units, or a combination of software and hardware.

[0169] It should be noted that, in the embodiments of this application, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, 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 smart device to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0170] This application provides an embodiment of a smart device. Figure 10 This is a schematic diagram of the structure of a smart device provided in an embodiment of this application, such as... Figure 10 As shown, the smart device 100 includes a memory 1001 and a processor 1002; the memory 1001 stores a computer program that can run on the processor 1002, and when the processor 1002 executes the program, it executes the task scheduling method provided in this application.

[0171] It should be noted that the memory 1001 is configured to store instructions and applications that can be executed by the processor 1002, and can also cache data to be processed or already processed in the processor 1002 and various modules in the smart device 100. It can be implemented through flash memory or random access memory (RAM).

[0172] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method provided in the above embodiments.

[0173] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the steps in the method provided in the above-described method embodiments.

[0174] It should be noted that the descriptions of the storage medium and smart device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and smart device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0175] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0176] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

[0177] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or intelligent device. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or intelligent device that includes that element.

[0178] In the embodiments provided in this application, it should be understood that the disclosed smart devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces. The indirect coupling or communication connection between smart devices or modules can be electrical, mechanical, or other forms.

[0179] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules. They may be located in one place or distributed across multiple network units. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0180] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0181] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0182] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium.

[0183] Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, 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 smart device to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0184] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0185] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0186] The features disclosed in the several methods or smart device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or smart device embodiments.

[0187] The above are merely embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.< / std::string>

Claims

1. A task orchestration method, characterized in that, The method includes: Obtain the task attributes of multiple tasks to be executed; the task attributes include: running time, required resources, resource information of the running platform, and status information of the running platform; Based on the task attributes of the multiple tasks to be executed, the multiple tasks to be executed are arranged to obtain initial arrangement information; Based on the initial orchestration information, the multiple tasks to be executed are scheduled and executed to obtain the first scheduling and execution result; Based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed, the target orchestration information is determined; Based on the target orchestration information, multiple tasks to be executed in the target orchestration information are scheduled and executed.

2. The task orchestration method according to claim 1, characterized in that, The process of orchestrating the multiple tasks to be executed based on their task attributes to obtain initial orchestration information includes: For each sub-state of the vehicle platform, the multiple tasks to be executed running in each sub-state of the sub-platform are determined; the resource information of the running platform is the resource information of the tasks to be executed in the corresponding sub-state of the sub-platform. Based on the resource information of each sub-platform in the vehicle platform in the sub-state, and the running time and required resources of the multiple tasks to be executed by each sub-platform in the sub-state, the multiple tasks to be executed are arranged to obtain the initial arrangement information.

3. The task orchestration method according to claim 2, characterized in that, Based on the resource information of each sub-platform in the vehicle platform in a sub-state, and the running time and required resources of the plurality of tasks to be executed on each sub-platform in the sub-state, the plurality of tasks to be executed are arranged to obtain the initial arrangement information, including: For each sub-state of the aforementioned sub-platform, determine the duration of the execution threads for the plurality of tasks to be executed; Based on the duration, running threads are created for the multiple tasks to be executed; Based on the resource information of each sub-platform in the vehicle platform in the sub-state, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state, the multiple tasks to be executed are placed in the running thread to obtain the initial orchestration information.

4. The task orchestration method according to claim 3, characterized in that, Based on the resource information of each sub-platform in the vehicle platform in a sub-state, and the running time and required resources of the tasks to be executed on each sub-platform in the sub-state, the multiple tasks to be executed are allocated in the running thread to obtain the initial orchestration information, including: Based on the priority and scheduling information of the tasks to be executed in the sub-state of the sub-platform, the multiple tasks to be executed are sorted to obtain a sorting result; Based on the sorting results, and considering the resource information of each sub-platform in the vehicle platform under its sub-state, as well as the running time and required resources of the tasks to be executed by each sub-platform under its sub-state, the multiple tasks to be executed are placed in the running thread to obtain the initial orchestration information.

5. The task orchestration method according to claim 4, characterized in that, According to the sorting result, based on the resource information of each sub-platform in the vehicle platform in the sub-state, and the running time and required resources of the tasks to be executed by each sub-platform in the sub-state, the multiple tasks to be executed are allocated in the running thread to obtain the initial orchestration information, including: Based on the sorting result, in response to the sub-platform having a running time less than or equal to the idle time of the running thread in the sub-state and the remaining platform resources in the platform resources allocated to the running thread in the sub-state of the sub-platform meeting the resource requirements of the task to be executed, the task to be executed is placed in the running thread. Based on the sorting result, in response to the sub-platform having a running time greater than the idle time of the thread in the sub-state, and / or the remaining platform resources allocated to the running thread in the sub-state of the sub-platform not meeting the resource requirements of the task to be executed, a new running thread for the task to be executed is recreated. Based on the resource information of the sub-platform corresponding to the un-arranged task to be executed in the sub-state of the vehicle platform, and the running time and required resources of the task to be executed in the sub-state of the sub-platform, the un-arranged task to be executed is placed in the new running thread. The initial orchestration information is obtained based on the pre-placed tasks in the running thread and the pre-placed tasks that have not been orchestrated in the new running thread.

6. The task orchestration method according to claim 3, characterized in that, Determining the duration of the running threads of the plurality of tasks to be executed includes: Based on the inverted trapezoidal structure and the running time of the task that is first in the sorting result among the un-arranged tasks to be executed, the duration of the running threads of the multiple un-arranged tasks to be executed is determined.

7. The task orchestration method according to any one of claims 1 to 6, characterized in that, The determination of target orchestration information based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed includes: Based on the initial scheduling execution result, update the task attributes of at least one of the tasks to be executed; Based on the updated task attributes of the tasks to be executed, the multiple tasks to be executed are arranged to obtain secondary arrangement information; Based on the secondary orchestration information, the multiple tasks to be executed are scheduled and executed to obtain the secondary scheduling and execution result; If the result of the secondary scheduling execution does not satisfy deterministic scheduling, the result of the primary scheduling execution is replaced with the result of the secondary scheduling execution, and the task attributes of the task to be executed are replaced with the updated task attributes of the task to be executed. The above steps are iteratively executed until the result of the secondary scheduling execution satisfies deterministic scheduling, and the secondary orchestration information is determined as the target orchestration information.

8. The task orchestration method according to any one of claims 1 to 6, characterized in that, The determination of target orchestration information based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed includes: Display the initial scheduling execution result, the multiple tasks to be executed, and the task attributes of the multiple tasks to be executed; Receives task attributes from multiple updated pending tasks; Based on the task attributes of the multiple updated tasks to be executed, the multiple updated tasks to be executed are arranged to obtain three arrangement information; Based on the three orchestration information, the multiple updated tasks to be executed are scheduled and executed to obtain the three scheduling and execution results. If the results of the three scheduling executions do not satisfy deterministic scheduling, the first scheduling execution result is replaced with the results of the three scheduling executions, and the task attributes of the task to be executed are replaced with the updated task attributes of the task to be executed. The above steps are iteratively executed until the results of the three scheduling executions satisfy deterministic scheduling, and the three orchestration information is determined as the target orchestration information.

9. The task orchestration method according to any one of claims 1 to 6, characterized in that, The step of scheduling and executing the plurality of tasks to be executed based on the initial orchestration information to obtain the first scheduling and execution result further includes: Generate a scheduling interface for the multiple tasks to be executed; Based on the initial orchestration information and the scheduling interface of the multiple tasks to be executed, the multiple tasks to be executed are scheduled and executed to obtain the first scheduling and execution result.

10. A task orchestration device, characterized in that, The device includes: The acquisition module is configured to acquire the task attributes of multiple tasks to be executed; the task attributes include: running time, required resources, resource information of the running platform, and status information of the running platform; The orchestration module is configured to orchestrate the multiple tasks to be executed based on their task attributes, thereby obtaining initial orchestration information. The first scheduling and execution module is configured to schedule and execute the multiple tasks to be executed based on the initial orchestration information, and obtain the first scheduling and execution result; The determination module is configured to determine target orchestration information based on the initial scheduling execution result and the task attributes of the multiple tasks to be executed. The second scheduling execution block is configured to schedule and execute multiple tasks to be executed in the target orchestration information based on the target orchestration information.

11. A smart device, the smart device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the method described in any one of claims 1 to 9.

Images