Characteristic scheduling method and device and readable storage medium

Abstract

The invention relates to a characteristic scheduling method and device and a readable storage medium, and relates to the technical field of system scheduling, and the method comprises the steps: obtaining system characteristic key levels of a plurality of operable entities; mapping the plurality of runnable entities into a plurality of tasks according to the system characteristic key levels; carrying out a schedulability test on the plurality of tasks; if the schedulability test passes, scheduling the plurality of runnable entities according to the mapping relation of the plurality of tasks; and if the schedulability test does not pass, remapping the plurality of runnable entities into the plurality of tasks as mapping units, and carrying out the schedulability test again. According to the method, the calculation chain delay is shortened, fault isolation between modules is realized, the scheduling efficiency and the resource utilization rate are improved, and meanwhile, the development complexity and test dependence are reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of system scheduling, and in particular to a characteristic scheduling method, device and readable storage medium. Background Art

[0002] With the development of intelligent connected vehicles, automotive electronic and electrical architecture is evolving from distributed to domain-centralized and central-centralized, and real-time operating systems are widely used in these stages. However, the current engineering development of real-time operating systems still uses the standards under distributed architectures, making it difficult to adapt to the new requirements of domain-centralized and central-centralized architectures.

[0003] In distributed architecture, CP AUTOSAR framework is often used for real-time system development. The theoretical basis of the current real-time operating system scheduling method is still the classic monotonic rate scheduling (RM) algorithm proposed by Liu and Layland in 1973. The basic idea of ​​this algorithm is that the priority of a task and its period are expressed as a monotonic function. The smaller the period of the task, the higher the priority, to ensure that the tasks required by the hard real-time system must be completed before the deadline. In the specific implementation, the runnable entities (runnable) of all software modules (SWC) will be coordinated, and a group of runnables with the same period will be assigned to a fixed-priority OS task (task). The smaller the period, the higher the priority.

[0004] Under the new domain-centralized and centrally-centralized electronic and electrical architecture, the real-time operating system, whether it exists in the traditional distributed ECU or the domain-controlled ECU, needs to interact with the intelligent driving operating system and the vehicle operating system, and support a variety of application services for intelligent connected vehicles.

[0005] Traditional real-time scheduling methods have many limitations, including excessive critical section protection leading to increased CPU blocking and consumption time, long end-to-end computing chain delay, lack of fault isolation between modules leading to increased interference, large deviations between RM algorithms and actual applications increasing the risk of unschedulable tasks, and frequent parameter debugging during development that consumes a lot of work. In addition, CPU utilization testing requires reserved resources, which limits the system's scheduling efficiency and resource utilization. Summary of the invention

[0006] In view of the shortcomings of the prior art described above, the present invention provides a feature scheduling method, device and readable storage medium, which can effectively reduce CPU blocking and consumption time, shorten the calculation chain delay, realize fault isolation between modules, improve scheduling efficiency and resource utilization, and reduce development complexity and test dependency.

[0007] A first aspect of the present invention provides a feature scheduling method, comprising: Obtaining criticality levels of system characteristics for multiple runnable entities; Mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics; Performing schedulability test on the multiple tasks; If the schedulability test passes, scheduling the multiple executable entities according to the mapping relationship of the multiple tasks; If the schedulability test fails, the plurality of executable entities are remapped as mapping units to the plurality of tasks, and the schedulability test is performed again.

[0008] In a possible implementation, obtaining the system characteristic criticality levels of the plurality of executable entities includes: Identify system characteristics based on system architecture design; Assign a unique criticality level number to each system characteristic based on the system functional safety requirements; According to the software architecture design, the software modules and executable entities corresponding to each system feature are identified.

[0009] In a possible implementation, assigning a unique criticality level number to each system characteristic according to the system functional safety requirements includes: Sum the functional safety levels of all system requirements under each system characteristic; Normalize the sum result to obtain the critical level value of the system characteristic.

[0010] In a possible implementation, mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristic includes: Traversing the plurality of executable entities in order of system characteristic criticality from low to high; Map runnable entities with the same system characteristic criticality level into the same task.

[0011] In a possible implementation, the performing schedulability test on the multiple tasks includes: Use response time analysis to calculate the worst-case response time for each task; Determine whether the worst-case response time of each task is less than or equal to its deadline.

[0012] In a possible implementation, the using the response time analysis method to calculate the worst-case response time of each task includes: Calculate the worst execution time of the task itself; Calculate the sum of the execution time of all high-priority tasks within the response time of this task; Calculate the blocking factor of this task.

[0013] In a possible implementation, the method further includes: Orders runnables mapped to the same task.

[0014] In a possible implementation, the sorting of executable entities mapped to the same task includes: Use directed acyclic graphs to represent precedence relationships between runnable entities; Apply the search tree algorithm to traverse the directed acyclic graph to obtain the scheduling path; The execution order of runnable entities is determined according to the dispatch path.

[0015] In a possible implementation, the method further includes: Adjusts the offset value of runnables mapped to the same task.

[0016] In a possible implementation, adjusting the offset value mapped to the executable entity in the same task includes: Determining an offset value based on a jitter requirement of the runnable entity; Ensure that the offset value adjustment does not change the execution order of the runnable entities; Ensure that the offset value adjustment does not affect the schedulability of the task.

[0017] A second aspect of the present invention provides a characteristic scheduling device, comprising: A level determination module, for obtaining at least a system characteristic criticality level of a plurality of operable entities; A task mapping module, at least used for mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics; A scheduling test module, at least used to perform a schedulability test on the plurality of tasks; A task execution module is used to schedule the multiple executable entities according to the mapping relationship of the multiple tasks at least when the schedulability test passes; wherein, if the schedulability test fails, the multiple executable entities are remapped to the multiple tasks as mapping units and the schedulability test is re-performed.

[0018] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a computer, the method according to the first aspect of the embodiment of the present invention is executed.

[0019] The present invention introduces the critical level of system characteristics to divide and prioritize executable entities, greatly reducing the coupling degree between tasks, reducing the consumption of CPU resources by critical area protection measures, and shortening the computing chain delay, realizing fault isolation between modules, and improving the stability and reliability of scheduling; utilizing heuristic scheduling algorithms and recursive schedulability tests to avoid the limitations of repeated parameter adjustment and CPU utilization reservation in traditional methods, thereby improving the adaptability, efficiency and resource utilization of scheduling, and providing a more flexible solution for task scheduling of complex real-time systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 It is a flowchart of a specific embodiment of a characteristic scheduling method of the present invention.

[0022] Figure 2 It is a flow chart of a specific embodiment of a characteristic scheduling method of the present invention.

[0023] Figure 3 It is a flowchart of another specific embodiment of a characteristic scheduling method of the present invention.

[0024] Figure 4 It is a schematic diagram of a specific embodiment of a characteristic scheduling method of the present invention.

[0025] Figure 5 It is a schematic diagram of another specific embodiment of a characteristic scheduling method of the present invention.

[0026] Figure 6 It is a flowchart of another specific embodiment of a characteristic scheduling method of the present invention.

[0027] Figure 7 It is a schematic diagram of a specific implementation scenario of the characteristic scheduling method of the present invention.

[0028] Figure 8 It is another specific implementation scenario schematic diagram of the characteristic scheduling method of the present invention.

[0029] Fig. 9 It is a structural diagram of a specific embodiment of a characteristic scheduling system of the present invention. DETAILED DESCRIPTION

[0030] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application. In addition, it should be understood that the specific implementation methods described herein are only used to illustrate and explain the present application, and are not used to limit the present application.

[0031] It should be noted that the description order of the following embodiments is not intended to limit the preferred order of the embodiments of the present application. In addition, in the following embodiments, the description of each embodiment has its own emphasis, and for parts not described in detail in one embodiment, reference can be made to the relevant description of other embodiments.

[0032] The method steps described in the embodiments of the present invention may be executed in the order described in the specific implementation manner, or the execution order of each step may be adjusted according to actual needs and on the premise that the technical problem can be solved, which will not be listed here one by one.

[0033] The present disclosure relates to a real-time system scheduling mechanism, in particular, a scheduling method based on the AUTOSAR platform on an automotive microcontroller (MCU). With the development of intelligent connected vehicles, automotive electronic and electrical architecture is evolving from distributed to domain-centralized and centrally centralized. In this process, real-time operating systems face new challenges. Traditional scheduling algorithms may lead to too many critical area protection measures, long end-to-end computing chain delays, insufficient fault isolation between modules, and other problems. In addition, when there are many interactions between tasks, there may be deviations between traditional algorithm models and actual engineering applications, and even make the system unschedulable.

[0034] The present invention provides a scheduling method based on the critical level of system characteristics. The method can map runnable entities with the same critical level of system characteristics to the same task, thereby reducing the critical area protection mechanism between tasks, shortening the computing chain delay, and improving the fault isolation between modules. The method also combines the Audsley algorithm and the response time analysis (RTA) method, and can achieve the mapping and priority allocation of runnable entities to tasks under the premise of ensuring schedulability.

[0035] In one embodiment, the method can obtain a schedulable result by mapping once. In some other embodiments, the method may need to be recursive, re-mapping and schedulability testing with runnable entities as mapping units. In addition, the method may also include sorting and offset value adjustment of runnable entities in the same task to further optimize the scheduling effect.

[0036] Reference Figure 1, an embodiment of the present invention discloses a characteristic scheduling method, comprising the following steps.

[0037] S1, obtain the criticality level of system characteristics of multiple runnable entities.

[0038] Specifically, first, all system characteristics in the project are identified through system architecture design, and the critical level of each system characteristic is calculated according to the functional safety requirements (ASIL level). The critical level is assigned a unique number by summing the weights and normalizing them; secondly, the mapping relationship between system characteristics and software modules is clarified through software architecture design, and executable entities are extracted from each module to ensure high cohesion and low coupling; finally, the functional safety level and system characteristics are combined to establish a system characteristics table (SFT), and the critical level of system characteristics of each executable entity is determined by table lookup to provide basic data for subsequent mapping tasks.

[0039] S2: Mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics.

[0040] Specifically, based on the system characteristic critical level determined in step S1, a group of executable entities with the same system characteristic critical level are used as mapping units and mapped to the lowest priority task in order from low to high; then, new tasks are created to process higher priority mapping units, and the mapping of all executable entities to tasks is gradually completed; in the mapping process, a default offset value and sequence value are initially assigned to each task so that they can be optimized and adjusted in subsequent schedulability tests to ensure that the mapping relationship can meet the system characteristic allocation and scheduling requirements.

[0041] S3, performing schedulability test on the multiple tasks.

[0042] Specifically, the response time analysis method (RTA) is used to perform schedulability tests on multiple tasks that have completed mapping, and the worst response time (WCRT) of each task is calculated specifically; the WCRT is iteratively solved through a recursive formula, including the worst execution time of the task itself, the cumulative execution time of all high-priority tasks during the current WCRT period, and the blocking time caused by critical section protection; if the WCRT of all tasks is less than or equal to their corresponding deadlines, the task set is determined to be schedulable, otherwise it is considered unschedulable, providing a basis for the next step of optimizing the mapping relationship.

[0043] S4: If the schedulability test passes, scheduling the multiple executable entities according to the mapping relationship between the multiple tasks.

[0044] Specifically, when the schedulability test passes, the runnable entities are scheduled according to the determined task mapping relationship, the priority is assigned according to the critical level of the system characteristics of the task, and the execution order and offset value of the task are optimized according to the mapping relationship; the priority relationship between the runnable entities within the task is analyzed using a directed acyclic graph (DAG), and a scheduling path that meets the shortest computing chain delay is found by establishing a search tree; finally, the task scheduling table is adjusted according to the optimized sequence value and offset value to ensure that the runnable entities can be efficiently scheduled and fault isolated as required.

[0045] S5: If the schedulability test fails, re-map the multiple executable entities as mapping units to the multiple tasks, and re-perform the schedulability test.

[0046] Specifically, when the schedulability test fails, multiple runnable entities are remapped as mapping units, specifically, the task mapping unit is adjusted from the system characteristic critical level to a single runnable entity, and is tried to be assigned to the task one by one according to their priority and mutual exclusion relationship; the schedulability test is re-executed, and if the test passes, the mapping relationship is confirmed, otherwise the mapping unit is continued to be adjusted recursively until a schedulable result is obtained or the system is determined to be unschedulable; during the adjustment process, the priority allocation and mapping relationship of the task are dynamically optimized to ensure the flexibility of scheduling and the stability of the overall system.

[0047] In some implementations, the task scheduling strategy problem in real-time theory can be transformed into a mapping strategy problem from runnable entities to tasks in engineering projects under the AUTOSAR architecture. The solution steps are as follows: Step 1: Formalize the model of runnable entities and tasks; Step 2: Convert to an optimization problem, determine constraints, optimization objectives, optimization algorithms, inputs and outputs.

[0048] In some implementations, the constraint condition refers to an informal premise assumption set in advance to ensure the simplification of the model and the executability of the algorithm when implementing the scheduling method, such as a fixed task period, a zero offset value, a deadline equal to the period, etc., specifically including: 1) All tasks have a fixed period, and the period value of all tasks is an integer multiple of the minimum period value; 2) The offset value of all tasks is 0; 3) The deadline of all tasks is equal to their period; 4) All tasks are preemptible; different tasks are assigned different priorities; except for initialization and idle tasks, periodic tasks are all extended types; and the scheduling table is used uniformly for scheduling; 5) The critical area protection measures for tasks on the same core use the following two mechanisms recommended by AUTOSAR: a. Sequential scheduling strategy: scheduling runnable entities sequentially in a task can ensure data consistency without any protection strategy; b. Interrupt blocking strategy, prohibit interruption; 6) The scheduling unit is an executable entity, and the executable entity only considers the time trigger type.

[0049] In some implementations, the optimization goal is to minimize the critical section execution time of the task, minimize the computing link latency of the task, and minimize the fault interference of the task.

[0050] In some embodiments, the input is a formal software module model of an executable entity (r_swc i ), all attributes are defined in the model, and these attributes are pre-known conditions or parameters. These known attributes include the offset value, trigger period, worst case execution time (WCET), deadline, characteristic value, etc. of the runnable entity, providing a complete input data basis for the execution of the subsequent scheduling algorithm and task mapping.

[0051] In some embodiments, the output is a formal mapping model of executable entities (r_map i ) and a formal model of the task (τ j ).

[0052] In some embodiments, the optimization algorithm uses a heuristic algorithm, which aims to quickly approach the optimal solution through heuristic rules and avoid the high computational complexity of traditional optimization methods. The algorithm is based on the critical level of system characteristics, and groups executable entities with the same characteristic level into tasks, thereby reducing the coupling degree and scheduling complexity between tasks; at the same time, combined with the priority allocation mechanism of the Audsley algorithm, the schedulability test is dynamically performed in the process of gradually allocating task priorities from low to high, ensuring that the task set achieves the optimal scheduling effect under system constraints. This method is both efficient and flexible and is suitable for complex real-time system task scheduling problems.

[0053] In some embodiments, reference Figure 2 , the module model of the runnable entity is as follows: r_swc i (c i ,t i ,d i ); The mapping model for runnable entities is as follows: r_map i (o i ,c i ,t i ,d i ,f i ,m i ,k i ); Among them, r i Represents the i-th runnable entity; o i Represents its offset value, which is determined by the specific project characteristics and functions; c i represents its worst execution time, which refers to the WCET time of independent operation. It is a known input quantity of the model and is determined by combining test methods and estimation methods during the design of the SWC module; t i represents its triggering period, which is a known input quantity of the model and is determined when the SWC module is designed; d i represents its relative cut-off time, which is assumed to be equal to its period value in this embodiment; i Represents its feature, which is affected by the critical level of system features, the mutual exclusion relationship and priority relationship between runnable entities, and mainly determines the mapping relationship between runnable entities and tasks; m i The number of the task mapped to the current runnable entity; k i It is the order value of the current runnable entity in its task, which affects the signal chain latency target.

[0054] In summary, among the parameters of the above runnable entities, c i ,t i ,d i The known quantity input to the model; f i The feature number will be determined in the early steps of the algorithm solution; m i The mapping relationship between runnable entities and tasks will be determined in the middle step of the algorithm solution; o i ,k i The specific feature requirements and signal chain delays will be determined in the later steps of the algorithm solution.

[0055] In some embodiments, reference Figure 2 , the task formalization model is established as follows: τ j (O j ,C j ,T j ,D j ,π j ); Among them, O j is the offset value of the task; C j Its WCET worst execution time; Tj For its cycle; D j is its relative cut-off time, which is specified to be the same as its period value in this embodiment; j is the priority of the jth task.

[0056] Based on the above models, the task scheduling strategy problem can be transformed into a mapping strategy problem from runnable entities to tasks.

[0057] Further, as an implementation mode of the present invention, obtaining the system characteristic criticality levels of multiple executable entities includes: Identify system characteristics based on system architecture design; Assign a unique criticality level number to each system characteristic based on the system functional safety requirements; According to the software architecture design, the software modules and executable entities corresponding to each system feature are identified.

[0058] Specifically, the system feature is a system-level concept, and the embodiment of the present invention regards the system feature as an attribute of an executable entity. A system feature often corresponds to multiple software modules, and a software module often corresponds to multiple executable entities, so these highly cohesive and highly dependent executable entities often share a system feature value.

[0059] In some implementations, the system feature classification of the executable entities needs to consider the following factors to construct a system feature table (SFT). The subsequent algorithm can query this table (SFT) to obtain the system feature criticality level (SFCL) of each executable entity.

[0060] In some embodiments, identifying system features based on system architecture design includes: In a project, the system architecture is developed by a system engineer, and the system engineer pre-lists all system feature functions supported by the project. The features of the runnable entity first need to refer to the features defined in the system architecture. This step requires identifying all system features in a project.

[0061] In some implementations, when assigning a unique criticality level number to each system characteristic according to the system functional safety requirements, the runnable entity does not care about the specific content of the system characteristic, but numbers the characteristics according to the system characteristic criticality level (SFCL). The larger the number, the higher the criticality level of the characteristic, and the value range is [1,254]. The criticality level of the system characteristic depends on the ASIL level of each system requirement corresponding to the system characteristic specified by functional safety, but the granularity of the ASIL level division is finer. The higher the ASIL level, the larger the criticality level value of the characteristic. Characteristics of the same ASIL level need to be further subdivided according to the system architecture definition until each system characteristic criticality level has a unique number. This step requires assigning unique numbers to all system characteristics in a project.

[0062] In some embodiments, a feasible method for solving the critical level is to sum the ASIL levels: let ASIL levels QM, ASIL A, ASIL B, ASIL C, and ASIL D correspond to weight values ​​0, 1, 2, 3, and 4 respectively, and calculate the sum of the functional safety level weight values ​​of all system requirements under each system characteristic, and finally normalize them to obtain the critical level value of the system characteristic.

[0063] In some embodiments, the software module and its executable entity corresponding to each system feature are identified according to the software architecture design. The software architecture design is formulated by the software architect and generally includes information such as the static architecture and dynamic architecture of the software module. A feature is a set of software modules with a high degree of correlation. Coupling and cohesion are often used as standards for measuring module independence in software design, and high cohesion and low coupling are often the standards for evaluating software module design. A measure of the functional strength of a cohesive module, that is, a measure of the degree of tightness of the combination of program segments within a module. If the program segments are closely connected, the cohesion is high. Coupling refers to a measure of the degree of close connection between the modules of a software system. The looser the connection between the modules, the lower the coupling. According to the definition of high cohesion and low coupling, it can be seen that the executable entities within the module have a high degree of correlation. And the feature is a set of software modules with a high degree of correlation, so the executable entities between these modules also have a relatively high degree of correlation. This step needs to identify the mapping relationship between system features and software modules, as well as the executable entities of each software module, thereby preliminarily confirming the characteristic value of each executable entity.

[0064] Exemplarily, the determination of the system characteristic criticality levels of the executable entities r1, r2, r3, and r4 is shown in Table 1: Table 1

[0065] Among them, according to the system architecture design, the system features are identified by referring to column C in Table 1, and two system features are identified as System Feature 1 and System Feature 2.

[0066] According to the system functional safety requirements, each system characteristic is assigned a unique critical level number. Refer to Table 1. First, identify all system requirements and their functional safety levels corresponding to the system characteristic in column D, and then use the summation method to score all system requirements according to their ASIL levels in column E to obtain the weight score of the system characteristic. Finally, normalize in column F to obtain the critical level value of the system characteristic.

[0067] According to the software architecture design, the software modules and executable entities corresponding to each system feature are identified as shown in columns A to C of Table 1. SWC1 and SWC2 are identified for System Feature1, and SWC3 is identified for System Feature2. Corresponding to SWC1, executable entities r1 and r2 are identified; corresponding to SWC2, executable entity r3 is identified.

[0068] Further, as an implementation mode of the present invention, step S2, mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics, comprises: Traversing the plurality of executable entities in order of system characteristic criticality from low to high; Map runnable entities with the same system characteristic criticality level into the same task.

[0069] Specifically, in some implementations, a heuristic scheduling algorithm is used to implement task mapping, sorting and offsetting of runnable entities. The input is the runnable entity module parameters, and the final output is the schedulability flag, runnable entity mapping parameters and task parameters. It can be divided into the following sub-steps: In the first step, the input is the runnable entity module parameters, and the output is the schedulability flag, the preliminary runnable entity mapping parameters and task parameters. If the schedulability test passes, proceed to the next step. If it fails, it directly returns to unschedulable. The first step is the mapping of runnable entities to tasks based on the Audsley algorithm, which will further call the RTA schedulability test algorithm to make schedulability judgments; In the second step, the input is the runnable entity mapping parameters and task parameters. This step will analyze the priority relationship of the runnable entity and adjust its order value accordingly. At the same time, the jitter requirements of the runnable entity will be analyzed and its offset value will be adjusted accordingly. These adjustments will not affect the previous step and the overall schedulability.

[0070] In some implementations, the heuristic scheduling algorithm uses an Audsley-based task priority allocation algorithm and targets the criticality level of system characteristics, and determines the mapping relationship of executable entities and the priority allocation of tasks using the RTA schedulability testing method.

[0071] Specifically, the module model parameters of the runnable entity are first assigned to the mapping model parameters. The system characteristic key level values ​​need to be assigned based on the model table lookup, and sorted from small to large to ensure that they correspond to the priority, and the offset value and sequence value are assigned default initial values.

[0072] Then the runnable entities are mapped to tasks.

[0073] In some embodiments, it is traversed to see if there are any executable entities that are not mapped to the task. If so, only among these executable entities without mapping relationships, a group of executable entities with the same system characteristic key level value are used as mapping units, and these mapping units are tried in turn to assign them to the current lowest priority task. The current task is tested for schedulability. If it is schedulable, the current executable entity mapping relationship and task model are maintained, and a new high-priority task is created to prepare for the next traversal. Otherwise, it is necessary to delete the current executable entity mapping relationship and task model parameters, and try the next group of mapping units. If no mappable units exist in the end, it is considered to be unschedulable and the algorithm is directly exited.

[0074] Further, as an implementation mode of the present invention, step S3, performing schedulability test on the plurality of tasks includes: Use response time analysis to calculate the worst case response time (WCRT) for each task; Determine whether the worst-case response time of each task is less than or equal to its deadline.

[0075] Furthermore, as an embodiment of the present invention, the use of the response time analysis method to calculate the worst-case response time of each task includes: calculating the worst-case execution time (WCRT) of the task itself; calculating the sum of the execution times of all high-priority tasks within the response time of the task; and calculating the blocking factor of the task.

[0076] In some embodiments, when calculating WCRT, it is assumed that: tasks are preemptive; each task has a unique priority; there is no offset; the deadline is less than or equal to the period; and blocking time is considered (dependencies between tasks, there may be low-priority tasks entering the critical section protection due to shared resources, causing the current task to enter the waiting state).

[0077] Then WCRT is equal to its own WCET time, plus the sum of the WCETs of all high-priority tasks released multiple times during this WCRT time, plus the blocking factor of this task. The recursive formula for calculating WCRT and the schedulability conditions are as follows: (Schedulable(τ j )==True)≡(R j ≤D j ); Among them, j, k, l represent the jth, kth, and lth tasks; hp(j) represents the set of tasks with a priority greater than task j; lp(j) represents the set of tasks with a priority less than or equal to task j; exc(j) represents the set of tasks that have a critical section exclusive relationship with task j; R represents the WCRT time of the task; C represents the maximum execution time WCET (worst case execution time) of the task, which is equal to the sum of the WCETs of all runnable entities mapped to this task; T represents its task period, which is equal to the greatest common divisor of the periods of all runnable entities mapped to this task; CS represents the duration of the critical section moment.

[0078] In some implementations, one solution to the above WCRT recursive formula is to convert it into the following formula and perform n (n=0, 1, 2, ...) iterations: when When

[0079] Further, as an embodiment of the present invention, refer to Figure 3 , the characteristic scheduling method described in the embodiment of the present invention further includes: S6, sorts the runnable entities mapped to the same task.

[0080] Further, as an implementation mode of the present invention, step S6, sorting the executable entities mapped to the same task includes: using a directed acyclic graph to represent the priority relationship between the executable entities; applying a search tree algorithm to traverse the directed acyclic graph to obtain a scheduling path; and determining the execution order of the executable entities according to the scheduling path.

[0081] The principle of minimum computational chain latency requires distinguishing the priority relationship of runnable entities, that is, the input, processing, and output processes of a computational chain often correspond to different runnable entities. If the order values ​​(k) of these runnable entities are arranged according to input-processing-output, the propagation latency of the computational chain can be minimized. The sorting and offset processing range of runnable entities is based on tasks, that is, the sorting and offset relationships of runnable entities between tasks are not considered.

[0082] In some implementations, all tasks are traversed. If a runnable entity has no priority relationship with other runnable entities, it is ignored; otherwise, a predecessor graph is used to represent the priority relationship between runnable entities. A predecessor graph (PG) is a directed acyclic graph (DAG) that describes the order of program execution in the computer field. The predecessor graph consists of two parts: nodes and directed edges. Each node represents a program, process, program segment or statement, and the directed edges between nodes represent the predecessor relationship between nodes.

[0083] For example, refer to Figure 4 , r0's successor tasks are r1 and r2, and r1's predecessor task is r0. Execution starts from r0. After r0 is executed, r1 and r2 can be executed. There is no priority relationship between r1 and r2. Finally, r3 can be executed only after r1 and r2 are executed. For a given predecessor graph, apply the relevant search strategy to traverse the DAG graph to establish a search tree.

[0084] In some embodiments, for the search tree (SearchTree), each layer corresponds to a time unit, that is, its depth corresponds to the scheduling cycle. The search tree starts from the root node, and all the edges outward from each node are all feasible search paths for the current node. Finally, each complete path from the root node to each leaf node in the search tree is a feasible scheduling path, which satisfies the predecessor relationship and can be completed before the deadline. Different paths may have different total execution times. Apply the relevant traversal strategy to traverse the search tree, select a complete path with the shortest execution time, and obtain a unique scheduling path (SchedulePath).

[0085] In some implementations, the execution order of the runnables in the task is arranged based on the scheduling path in the above implementation, that is, the k value.

[0086] For example, refer to Figure 5 , and finally generate the search tree shown in the figure. The left and right branches of the tree are both feasible scheduling paths with the same execution time: r0-r1-r2-r3 or r0-r2-r1-r3.

[0087] Further, as an embodiment of the present invention, refer to Figure 6 , the characteristic scheduling method described in the embodiment of the present invention further includes: S7, adjust the offset value of the runnable entity mapped to the same task.

[0088] Further, as an implementation of the present invention, step S7, adjusting the offset value of the executable entity mapped to the same task, includes: Determining an offset value based on a jitter requirement of the runnable entity; Ensure that the offset value adjustment does not change the execution order of the runnable entities; Ensure that the offset value adjustment does not affect the schedulability of the task.

[0089] In some implementations, the following provisions are made for adjusting the runnable entity offset value: 1) Only the runnable entity value range is a multiple of the task period, so that the offset value of the task is always 0; 2) The adjustment of the offset value of a runnable entity cannot change its order value. Therefore, when the offset value of a runnable entity is adjusted, other runnable entities with a predecessor relationship may also be adjusted accordingly. 3) Adjustment of the runnable entity offset value does not affect schedulability. Since the calculation of the WCET of a task is the sum of the WCETs of all its runnable entities, and the task period is the greatest common divisor of the periods of all its runnable entities, the scheduling point of each task will not schedule all the runnable entities. That is, the WCET of the task has enough margin to support the runnable entity to adjust the offset value as needed.

[0090] In some implementations, whether the offset value of an executable entity in a task is adjusted depends on the jitter requirements of the specific project. For example, in real-time system requirements, there are strict requirements for the jitter of communication message sending, and the general jitter range needs to be less than 10% of the period value. At this time, in order to ensure the accurate scheduling of the executable entity sending the communication message, it is necessary to add an offset value to it to ensure that its scheduling time is not affected by the actual running time of the dynamically changing executable entities of other predecessor relationships.

[0091] For example, a specific implementation scenario of the characteristic scheduling method of the present invention is as follows: Figure 7 As shown in the figure, when mapping runnable entities to tasks, the system characteristic criticality level is used as the mapping unit, and the schedulability is obtained at one time without recursion. This situation is a high-probability scenario in actual projects, because actual projects generally reserve CPU utilization and will not run at full load. In this example, the CPU utilization is defined as 70%.

[0092] Reference Figure 7 On the upper side, the software module SWC1 has two executable entities: r_swc1 (c1 = 1ms, t1 = 5ms, d1 = 5ms), The software module SWC2 has two executable entities: r_swc3 (c3=0.5ms, t3=5ms, d3=5ms), r_swc4 (c4=0.5ms, t4=10ms, d4=10ms).

[0093] If the traditional RM algorithm is used, refer to Figure 7 The limitations of the medial side are: 1. In this example, a single critical section protection takes 0.5ms (the shaded part in the figure), which is divided into 0.25ms of CPU consumption time and 0.25ms of shared resource access time. Since the execution time of r2 is shorter, the critical section protection mechanism of r1 and r2 does not cause CPU blocking time each time; 2. The computation chain delay of the task is relatively long, which is 7ms; 3. This feature cannot achieve fault isolation. If r3 of SWC2 fails and task2 enters a faulty state, r1 of SWC1 on task2 cannot be called and run, and fault isolation between SWC1 and SWC2 cannot be achieved.

[0094] If the characteristic scheduling method described in the embodiment of the present invention is adopted, refer to Figure 7 On the lower side, then: 1. Since r1 and r2 share a task, they will not share a resource, so the critical section protection strategy is desirable; each time it saves 0.25ms of CPU consumption time, and only 0.25ms of shared resource access time is required (the dotted line part in the figure). The CPU idle rate increases from 30% to 37.5%; 2. Since r1 and r2 share a task, and r3 and r4 share a task, the computing chain delay of r1-r2 and r3-r4 are each guaranteed by the internal tasks, and the total computing chain delay is reduced to 5ms; 3. Since r3 and r4 share a task, if r3 fails, it will only affect Task1, that is, the SWC2 module; the SWC1 module will not be affected, thus achieving fault isolation between the two modules.

[0095] For example, in Figure 7 In the characteristic scheduling scenario shown, the characteristic scheduling method described in the embodiment of the present invention implements the following steps: 1. According to the module model of the runnable entity, the corresponding initial value of the mapping model is as follows: r_map1(o1=0ms, c1=1ms, t1=5ms, d1=5ms, f1=2, m1=0, k1=0); r_map2(o2=0ms, c2=3.5ms, t2=10ms, d2=10ms, f2=2, m2=0, k2=0); r_map3(o3=0ms, c3=0.5ms, t3=5ms, d3=5ms, f3=1, m3=0, k3=0); r_map4(o4=0ms, c4=0.5ms, t4=10ms, d4=10ms, f4=1, m4=0, k4=0); 2. Traverse all runnable entities in order from low to high according to the criticality of system characteristics. First, select r_map3 and r_map4 with the lowest criticality of system characteristics, and obtain their further model values ​​and a task model value of the lowest priority as follows: r_map3(o3=0ms, c3=0.5ms, t3=5ms, d3=5ms, f3=1, m3=1, k3=1); r_map4(o4=0ms, c4=0.5ms, t4=10ms, d4=10ms, f4=1, m4=1, k4=2); τ1 (O1=0ms, C1=1ms, T1=5ms, D1=5ms, π1=1); 3. Scheduling of computing task τ1: 3.1. Map all remaining runnable entity feature groups to a hypothetical higher priority task τ x ; 3.2, then the highest priority task τ x The WCET time is C x =0.75ms+3.25ms=4ms, WCRT is R x =C x +CS1=4ms+0=4ms; 3.3, then the calculation method of WCRT of the second highest priority task τ1 is: because Finally, we get R1=5ms≤D1=5ms, so the task is schedulable at this time; 4. Create the next higher priority task τ2 and check whether there are any unmapped runnable entities. If found, continue to traverse these unmapped runnable entities in order from low to high system characteristic criticality. Here, select r_map1 and r_map2 with higher system characteristic criticality, and obtain their further model values ​​and the model value of a task with the lowest priority as follows: r_map1(o1=0ms, c1=1ms, t1=5ms, d1=5ms, f1=2, m1=2, k1=1); r_map2(o2=0ms, c2=3.5ms, t2=10ms, d2=10ms, f2=2, m2=2, k2=2); τ2 (O2=0ms, C2=4.5ms, T2=5ms, D2=5ms, π2=2); 5. Schedulability of computing tasks: 5.1. Determine that there are no unmapped executable entities; 5.2, then the WCRT calculation method for this high priority task is: Obtain So the task is schedulable at this time; 6. Check again whether there is an unmapped runnable entity. If no runnable entity is found, exit the algorithm. Get the runnable entity mapping model parameter r_map i , task model parameter τ i , Schedulability is true; 7. Since there are fewer executable entities with priority relationships in actual projects, and most of them are linear relationships, this embodiment uses manual methods to calculate the predecessor graph, search tree and scheduling path. Finally, the current sequence value is compared to match the scheduling path, so no sequence value adjustment is made. At the same time, this example does not have a jitter requirement, so no offset value adjustment is made; 8. The whole algorithm ends. Finally, the runnable entity mapping model parameter r_map is obtained i , task model parameter τ i , the output when Schedulability is true.

[0096] For example, another specific implementation scenario of the characteristic scheduling method of the present invention is as follows: Figure 8 As shown, in abnormal cases (CPU utilization is high, such as 80%, refer to Figure 8 In the middle side, the schedulability test is not passed in the initial task mapping based on the critical level of system characteristics. At this time, the algorithm needs to use recursive scheduling based on a single runnable entity to ensure the same schedulability as the traditional RM algorithm, but the scheduling performance advantages (such as low latency and fault isolation) are reduced.

[0097] When mapping runnable entities to tasks, the mapping unit is not schedulable when the system characteristic criticality level is used as the mapping unit (refer to Figure 8 In order to ensure schedulability, a recursion is required (step S5), and the runnable entity is used as the mapping unit to obtain a schedulability result or a final unschedulable result, wherein the schedulable result is similar to or the same as the result of the traditional RM algorithm.

[0098] This scenario is a low-probability scenario in actual projects. It only occurs when the CPU utilization is very high. There is no quantitative value for the specific CPU utilization threshold, which depends on the quality of the actual runnable entities. For example, runnable entities with low system characteristic criticality levels and short deadlines are likely to cause the first unschedulability.

[0099] In this implementation scenario with a low probability of occurrence, the characteristic scheduling method described in the embodiment of the present invention can ensure the same schedulability as the traditional RM algorithm, and the scheduling result is the same as the traditional RM algorithm.

[0100] Reference Figure 8 On the upper side, software module SWC1 has 2 runnable entities: r_swc1 (c1 = 1ms, t1 = 5ms, d1 = 5ms), r_swc2 (c2 = 4.5ms, t2 = 10ms, d2 = 10ms); software module SWC2 has 2 runnable entities: r_swc3 (c3 = 0.5ms, t3 = 5ms, d3 = 5ms), r_swc4 (c4 = 0.5ms, t4 = 10ms, d4 = 10ms)

[0101] For example, in Figure 8 In the characteristic scheduling scenario shown, the characteristic scheduling method described in the embodiment of the present invention implements the following steps: 1. According to the module model of the runnable entity, the corresponding initial value of the mapping model is as follows: r_map1(o1=0ms, c1=1ms, t1=5ms, d1=5ms, f1=2, m1=0, k1=0); r_map2(o2=0ms, c2=4.5ms, t2=10ms, d2=10ms, f2=2, m2=0, k2=0); r_map3(o3=0ms, c3=0.5ms, t3=5ms, d3=5ms, f3=1, m3=0, k3=0); r_map4(o4=0ms, c4=0.5ms, t4=10ms, d4=10ms, f4=1, m4=0, k4=0); 2. Traverse all runnable entities in order from low to high according to the criticality of system characteristics. First, select r_map3 and r_map4 with the lowest criticality of system characteristics, and obtain their further model values ​​and a task model value of the lowest priority as follows: r_map3(o3=0ms, c3=0.5ms, t3=5ms, d3=5ms, f3=1, m3=1, k3=1); r_map4(o4=0ms, c4=0.5ms, t4=10ms, d4=10ms, f4=1, m4=1, k4=2); τ1(O1=0ms, C1=1ms, T1=5ms, D1=5ms, π1=1); 3. Scheduling of computing task τ1: 3.1. Map all remaining runnable entity feature groups to a hypothetical higher priority task τ x ; 3.2, then the highest priority task τ x The WCET time is C x =0.75ms+4.25ms=5ms, WCRT is R x =C x +CS1=5ms+0=5ms; 3.3, then the calculation method of WCRT of the second highest priority task τ1 is: 4. Similarly, traversing other runnable entities of the system characteristic key level, the task is still unschedulable. After the traversal, if it is unschedulable and the mapping unit is of the system characteristic key level, modify the mapping unit to a runnable entity and recursively call this algorithm; 5. Traverse all runnable entities in order from low to high by runnable entity number. First, select r_map1 with the lowest number, and obtain its further model value and the lowest priority task model value as follows: r_map1(o1=0ms, c1=1ms, t1=5ms, d1=5ms, f1=1, m1=1, k1=1); τ1(O1=0ms, C1=1ms, T1=5ms, D1=5ms, π1=1); 6. Scheduling of computing task τ1: 6.1. Map all remaining runnable entity feature groups to a hypothetical higher priority task τ x ; 6.2, then the highest priority task τ x The WCET time is C x =4.5s+0.5ms+0.5ms=5.5ms, WCRT is R x =C x +CS1=5.5ms+0=5.5ms; 6.3 The calculation method of WCRT of the second highest priority task τ1 is: because Therefore, the task is not schedulable at this time. Restore the runnable entity parameters of the above steps to their initial values, and restore the task parameters that have changed due to the runnable entity; 7. Similarly, select the executable entities r_map2, r_map3, and r_map4 in turn, and perform schedulability tests on them respectively, and finally obtain the result that r_map2 and r_map4 form τ1, and r_map1 and r_map3 form τ2. Schedulability is true; 8. This embodiment uses manual methods to calculate the predecessor graph, search tree, and scheduling path. Since the executable entities in the same task have no predecessor relationship, the current sequence value is retained without adjustment. At the same time, this example has no jitter requirement, and no offset value adjustment is made. 9. The entire algorithm ends. Finally, the executable entity mapping model parameter r_map is obtained i , task model parameter τ i , the output when Schedulability is true.

[0102] Reference Fig. 9 The embodiment of the present invention further discloses a characteristic scheduling device, including a level determination module 1, a task mapping module 2, a scheduling test module 3 and a task execution module 4.

[0103] The level determination module 1 is at least used to obtain the system characteristic criticality levels of multiple executable entities.

[0104] In some embodiments, the level determination module 1 identifies all system characteristics through system architecture design, and quantifies and calculates each system characteristic in combination with functional safety requirements (such as ASIL level) to generate a system characteristic critical level; the specific method includes summing and normalizing the functional safety level weights corresponding to the system requirements, and assigning a unique number to identify the critical level; then, in combination with the software architecture design, analyzing the mapping relationship between system characteristics and software modules, extracting the executable entities in each module, and assigning the system characteristic critical level to these executable entities through a table lookup, thereby providing basic data support for subsequent task mapping.

[0105] The task mapping module 2 is at least used to map the multiple executable entities to multiple tasks according to the criticality level of the system characteristics.

[0106] The task mapping module 2 uses the system characteristic critical level obtained by the level determination module 1 as mapping units, and allocates them to multiple tasks in order from low to high priority; at each allocation, a default offset value and sequence value are assigned to each task, and the mapping relationship is dynamically updated according to the priority of the task; after completing the preliminary mapping of all executable entities, a task model is generated to provide input for subsequent schedulability testing and optimization; this module reduces the coupling between tasks through group mapping, thereby improving the flexibility and efficiency of system scheduling.

[0107] The scheduling test module 3 is at least used to perform a schedulability test on the multiple tasks.

[0108] Scheduling test module 3 performs a schedulability test on the task mapping results through response time analysis (RTA) and calculates the worst response time (WCRT) of each task; the specific process includes: according to the task priority, accumulating the worst execution time of the task itself, the interference time of the high-priority task in the WCRT time window and the critical section blocking time, and solving the WCRT through recursive iteration; if the WCRT of all tasks is less than or equal to their deadlines, the task set is determined to be schedulable, otherwise the test failure is returned; this module ensures the real-time and reliability of task scheduling, and provides a judgment basis for triggering remapping in unschedulable situations.

[0109] The task execution module 4 is at least used for scheduling the multiple executable entities according to the mapping relationship of the multiple tasks when the schedulability test passes.

[0110] When the scheduling test module 3 determines that the task set is schedulable, the task execution module 4 optimizes the scheduling of the executable entities according to the task mapping relationship; first, the priority relationship between the executable entities in the task is analyzed through a directed acyclic graph (DAG), a predecessor graph is constructed and a search tree is generated to determine the scheduling path with the shortest computing chain delay; secondly, the sequence value of the executable entity in the task is adjusted according to the scheduling path, and the offset value is optimized according to the real-time system requirements to meet the jitter limit; finally, a scheduling table is generated according to the optimized sequence value and offset value to ensure that the task execution is efficient and meets the real-time requirements of the system.

[0111] If the schedulability test fails, the plurality of executable entities are remapped as mapping units to the plurality of tasks, and the schedulability test is performed again.

[0112] In some embodiments, when the schedulability test fails, multiple runnable entities are remapped as mapping units, specifically, the task mapping unit is adjusted from the system characteristic critical level to a single runnable entity, and is tried to be assigned to the task one by one according to its priority and mutual exclusion relationship; the schedulability test is re-executed, and if the test passes, the mapping relationship is confirmed, otherwise the mapping unit is adjusted recursively until a schedulable result is obtained or the system is determined to be unschedulable; during the adjustment process, the priority allocation and mapping relationship of the task are dynamically optimized to ensure the flexibility of scheduling and the stability of the overall system

[0113] The embodiment of the present invention also discloses a readable storage medium.

[0114] A readable storage medium stores a computer program, which, when executed by a processor, implements the steps of a characteristic scheduling method described in any one of the above embodiments. The computer-readable storage medium may include: any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. The computer program includes a computer program code. The computer program code may be in source code form, object code form, an executable file, or some intermediate form, etc. The computer-readable storage medium may include: any entity or device capable of carrying a computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0115] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention belong.

[0116] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processing module, or other system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with these instruction execution systems, apparatuses or devices.

[0117] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A characteristic scheduling method, characterized in that: include: Obtaining criticality levels of system characteristics for multiple runnable entities; Mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics; Performing schedulability test on the multiple tasks; If the schedulability test passes, scheduling the multiple executable entities according to the mapping relationship of the multiple tasks; If the schedulability test fails, the plurality of executable entities are remapped as mapping units to the plurality of tasks, and the schedulability test is performed again.

2. The characteristic scheduling method according to claim 1, characterized in that: The obtaining of the system characteristic criticality levels of the plurality of executable entities comprises: Identify system characteristics based on system architecture design; Assign a unique criticality level number to each system characteristic based on the system functional safety requirements; According to the software architecture design, the software modules and executable entities corresponding to each system feature are identified.

3. The characteristic scheduling method according to claim 2, characterized in that: The assignment of a unique criticality level number to each system characteristic according to the system functional safety requirements includes: Sum the functional safety levels of all system requirements under each system characteristic; Normalize the sum result to obtain the critical level value of the system characteristic.

4. The characteristic scheduling method according to claim 1, characterized in that: Mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics comprises: Traversing the plurality of executable entities in order of system characteristic criticality from low to high; Map runnable entities with the same system characteristic criticality level into the same task.

5. The characteristic scheduling method according to claim 1, characterized in that: The schedulability test of the multiple tasks comprises: Use response time analysis to calculate the worst-case response time for each task; Determine whether the worst-case response time of each task is less than or equal to its deadline.

6. The characteristic scheduling method according to claim 5, characterized in that: The worst-case response time of each task calculated using the response time analysis method includes: Calculate the worst execution time of the task itself; Calculate the sum of the execution time of all high-priority tasks within the response time of this task; Calculate the blocking factor of this task.

7. The characteristic scheduling method according to claim 1, characterized in that: Also includes: Orders runnables mapped to the same task.

8. The characteristic scheduling method according to claim 7, characterized in that: The sorting of runnable entities mapped to the same task includes: Use directed acyclic graphs to represent precedence relationships between runnable entities; Apply the search tree algorithm to traverse the directed acyclic graph to obtain the scheduling path; The execution order of runnable entities is determined according to the dispatch path.

9. The characteristic scheduling method according to claim 1, characterized in that: Also includes: Adjusts the offset value of runnables mapped to the same task.

10. The characteristic scheduling method according to claim 9, characterized in that: The adjustment of the offset value mapped to the runnable entity in the same task includes: Determining an offset value based on a jitter requirement of the runnable entity; Ensure that the offset value adjustment does not change the execution order of the runnable entities; Ensure that the offset value adjustment does not affect the schedulability of the task.

11. A characteristic scheduling device, characterized in that: The device comprises: A level determination module, for obtaining at least a system characteristic criticality level of a plurality of operable entities; A task mapping module, at least used for mapping the plurality of executable entities to a plurality of tasks according to the criticality level of the system characteristics; A scheduling test module, at least used to perform a schedulability test on the plurality of tasks; A task execution module is used at least to schedule the multiple executable entities according to the mapping relationship of the multiple tasks when the schedulability test passes; wherein, If the schedulability test fails, the plurality of executable entities are remapped as mapping units to the plurality of tasks, and the schedulability test is performed again.

12. A readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a computer, the characteristic scheduling method according to any one of claims 1 to 10 is executed.

Images