WO2021229718A1

WO2021229718A1 - Scheduling method and scheduling system

Info

Publication number: WO2021229718A1
Application number: PCT/JP2020/019109
Authority: WO
Inventors: 知彦東山; 広章高田; 晋也本田
Original assignee: 三菱電機株式会社
Priority date: 2020-05-13
Filing date: 2020-05-13
Publication date: 2021-11-18
Also published as: JPWO2021229718A1; JP7237245B2

Abstract

The present invention addresses the problem of quantitatively indicating a reliability index ensured at each criticality level for which scheduling is carried out. A scheduling system according to the present invention repeatedly measures the execution time of each task, determines, among the execution times of each task measured a plurality of times, the execution time corresponding to a statistical reliability defined in advance for each criticality level as the worst execution time for each criticality level, and schedules a plurality of tasks on the basis of the worst execution time.

Description

Scheduling method and scheduling system

The techniques disclosed in the present specification relate to a scheduling method and a scheduling system.

The real-time system is a computer system that is subject to the time constraint that "the processing of the task must be completed by the time limit determined for each task (hereinafter also referred to as the deadline)".

Therefore, in the real-time system, the execution completion time of each task should not exceed the deadline (hereinafter also referred to as deadline miss), that is, the deadline constraint which is the constraint to complete the task by the deadline should be satisfied. It is necessary to allocate an appropriate processor execution time to each task (real-time scheduling).

The conventional method of real-time scheduling is to first determine the scheduling possibility (that is, whether or not scheduling is possible) so that each task does not cause a deadline mistake, and then which processor is actually used. There is a method of deciding which task is assigned to which period (see, for example, Patent Document 1).

When using the above method, the worst execution time that can be assumed as the execution time of each task will be used in order to prevent deadline mistakes. Here, the worst execution time is the longest execution time that is expected to be required to execute the corresponding task.

In most cases, each task is completed in a shorter time than the worst execution time. Therefore, when a certain task set (that is, a plurality of tasks) is given and the scheduling possibility is determined on the premise of the worst execution time, there is a problem that the determination criteria of the scheduling possibility becomes too strict.

In order to solve such problems, a real-time system that sets the criticity level in advance according to the impact of a deadline mistake for each task and mixes multiple tasks with different criticity levels. Proposed. Here, a real-time system in which a plurality of tasks having different criticity levels are mixed is referred to as a mixed criticity system.

For example, Non-Patent Document 1 proposes a method for determining scheduling possibility for a mixed criticity system. According to Non-Patent Document 1, for each task in the mixed criticity system, the criticity level of the task itself and the worst execution time corresponding to the criticism level of all tasks including other than the task are defined.

In the above, it is assumed that the execution time of each task has jitter (that is, fluctuation of the time width), and it is the worst for each criticality level within the range of the execution time of each task measured repeatedly in advance. Execution time is defined. In this case, the worst execution time is set to a larger value as the criticity level of the corresponding task is higher. That is, the higher the criticality level of the corresponding task, the more pessimistic (longer) worst-case execution time is assumed.

Then, real-time scheduling is performed based on the mixed criticity guarantee scheduling policy. Here, the mixed criticity guarantee scheduling policy guarantees that if all tasks are completed in the execution time corresponding to a certain criticity level, the tasks of the criticity level or higher satisfy the deadline constraint. Is. In this case, the task below the criticality level does not have to satisfy the deadline constraint.

Japanese Unexamined Patent Publication No. 2005-284351

For example, according to the technique disclosed in Non-Patent Document 1, the mixed criticity system is appropriate according to the degree of influence of the deadline mistake of the task on the mixed criticity system while improving the scheduling possibility. It is possible to guarantee the reliability.

However, for example, in the technique disclosed in Non-Patent Document 1, the method of defining the worst execution time at each criticality level in which scheduling is performed is not mentioned. Therefore, there is a problem that the reliability index guaranteed at each criticality level (that is, the index of how much it is guaranteed not to cause deadline mistakes) cannot be quantitatively shown.

The techniques disclosed herein have been made in view of the problems described above, and are used to quantitatively indicate the reliability index guaranteed at each criticality level in which scheduling is performed. It is a technology.

A first aspect of the technique disclosed herein relates to a scheduling method in which the execution time of each task is repeatedly measured in a real-time system that schedules multiple tasks with different criticity levels. Of the execution times of each of the tasks measured a plurality of times, the execution time corresponding to the statistical reliability predetermined for each criticality level is defined as the worst execution time for each criticity level. The scheduling of the plurality of tasks is performed based on the worst execution time.

A second aspect of the technique disclosed herein is a real-time system having a plurality of tasks with different criticity levels in connection with a scheduling system, the execution time of which the execution time of each task is repeatedly measured. Of the execution time of the task measured a plurality of times with the measuring unit, the execution time corresponding to the statistical reliability predetermined for each criticity level is set as the worst execution time for each criticity level. It includes an execution time calculation unit for calculating, and a schedule derivation unit for scheduling the plurality of tasks in the real-time system based on the worst execution time.

A first aspect of the technique disclosed herein relates to a scheduling method in which the execution time of each task is repeatedly measured in a real-time system that schedules multiple tasks with different criticity levels. Of the execution times of each of the tasks measured a plurality of times, the execution time corresponding to the statistical reliability predetermined for each criticality level is defined as the worst execution time for each criticity level. The scheduling of the plurality of tasks is performed based on the worst execution time. With such a configuration, the worst execution time for each criticity level is specifically determined by the corresponding statistical reliability, so the reliability index guaranteed for each criticity level is quantitatively shown. Is possible.

A second aspect of the technique disclosed herein is a real-time system having a plurality of tasks with different criticity levels in connection with a scheduling system, the execution time of which the execution time of each task is repeatedly measured. Of the execution time of the task measured a plurality of times with the measuring unit, the execution time corresponding to the statistical reliability predetermined for each criticity level is set as the worst execution time for each criticity level. It includes an execution time calculation unit for calculating, and a schedule derivation unit for scheduling the plurality of tasks in the real-time system based on the worst execution time. With such a configuration, the worst execution time for each criticity level is specifically determined by the corresponding statistical reliability, so the reliability index guaranteed for each criticity level is quantitatively shown. Is possible.

Further, the objectives, features, aspects, and advantages associated with the technology disclosed herein will be further clarified by the detailed description and accompanying drawings shown below.

It is a figure which conceptually shows the example of the whole composition of the mixed criticity system with respect to embodiment. It is a figure which conceptually shows the example of the structure of the execution time measuring apparatus with respect to embodiment. It is a figure which conceptually shows the example of the structure of the scheduling apparatus with respect to embodiment. It is a figure which conceptually shows the example of the structure of the real-time control device which concerns on embodiment. It is a figure which shows the example of the control request table which concerns on embodiment. It is a figure which shows the example of the reliability table which concerns on embodiment. It is a figure which shows the example of the worst execution time table which concerns on embodiment. It is a figure which shows the histogram of the execution time when a certain task is executed repeatedly. It is a flowchart which shows the example of the operation of the execution time calculation part. It is a flowchart which shows the example of the operation of a scheduling apparatus. It is a flowchart which shows the example of the operation of a real-time control device. It is a flowchart which shows the example of the operation of the execution time calculation part with respect to embodiment. It is a figure which shows the example of the modified worst execution time derived. It is a figure which schematically exemplifies the hardware configuration in the case of actually operating the scheduling system shown in FIG. 1, FIG. 2 and FIG. It is a figure which schematically exemplifies the hardware configuration in the case of actually operating the scheduling system shown in FIG. 1, FIG. 2 and FIG.

Hereinafter, embodiments will be described with reference to the attached drawings. In the following embodiments, detailed features and the like are also shown for the purpose of explaining the technique, but they are examples, and not all of them are necessarily essential features in order for the embodiments to be feasible.

It should be noted that the drawings are shown schematically, and for convenience of explanation, the configuration is omitted or the configuration is simplified as appropriate in the drawings. Further, the interrelationship between the sizes and positions of the configurations and the like shown in different drawings is not always accurately described and can be changed as appropriate. Further, even in a drawing such as a plan view which is not a cross-sectional view, hatching may be added to facilitate understanding of the contents of the embodiment.

Further, in the explanation shown below, similar components are illustrated with the same reference numerals, and their names and functions are the same. Therefore, detailed description of them may be omitted to avoid duplication.

Further, in the description described below, when it is described that a certain component is "equipped", "included", or "has", the existence of the other component is excluded unless otherwise specified. Not an expression.

Also, even if ordinal numbers such as "first" or "second" may be used in the description described below, these terms facilitate the understanding of the content of the embodiments. It is used for convenience, and is not limited to the order that can be generated by these ordinal numbers.

<First Embodiment>
Hereinafter, a scheduling system and a scheduling method regarding the present embodiment will be described.

<Scheduling system configuration>
FIG. 1 is a diagram conceptually showing an example of the overall configuration of a mixed criticity system according to the present embodiment.

The mixed criticity system whose example is shown in FIG. 1 includes an execution time measuring device 11, a scheduling device 10, and a real-time control device 12.

The execution time measuring device 11 takes an executable task group constituting the mixed criticity system as an input, and acquires statistical data of the execution time for each criticity level of each task in the task group. Then, the execution time measuring device 11 outputs the acquired statistical data of the execution time for each criticality level to the scheduling device 10.

The scheduling device 10 inputs the statistical data acquired by the execution time measuring device 11, the optimization problem input by the user, and the statistical reliability of each task criticity level input by the user, as a task. The optimum schedule (hereinafter, also referred to as task schedule) is derived. Then, the scheduling device 10 outputs the derived optimum task schedule to the real-time control device 12. The real-time control device 12 executes each task according to the input task schedule.

The statistical data acquired by the execution time measuring device 11 is the execution time corresponding to the statistical reliability for each criticity level defined uniformly in the entire mixed criticity system, and is measured for each task. It is a thing. The execution time is synonymous with the execution time in the real-time control device 12.

FIG. 2 is a diagram conceptually showing an example of the configuration of the execution time measuring device 11 according to the present embodiment. As shown in FIG. 2, the execution time measuring device 11 has a task group receiving unit 113 that accepts a set of a plurality of tasks (that is, an executable task group) that can be executed by the real-time control device 12, and a task group receiving unit. Statistics for each criticality level based on the execution time measuring unit 111 that repeatedly measures the execution time in the real-time control device 12 and the execution time measured by the execution time measuring unit 111 of the executable task group received by 113. It is provided with an execution time calculation unit 112 that creates the worst execution time table 105, which will be described later, by calculating the execution time corresponding to the target reliability for each task.

The execution time measuring unit 111 has a task execution environment that is the same as the real-time control device 12 or that imitates the real-time control device 12, and measures the execution time of the task by repeatedly executing the task under the environment.

FIG. 3 is a diagram conceptually showing an example of the configuration of the scheduling device 10 according to the present embodiment. As shown in FIG. 3, the scheduling apparatus 10 derives a schedule (hereinafter referred to as a mixed criticity schedule) that satisfies the mixed criticity guarantee scheduling policy by solving the constrained optimization problem. An interface that accepts the 101 and optimization problems (objective functions, additional constraints, etc.) input from the user (designer of the real-time controller 12), control information for each task, or statistical reliability for each criticality level. In the input IF 102, the control request table 103 for storing the control information set for each task, the reliability table 104 for storing the statistical reliability set for each criticality level, and the execution time measuring device 11. The worst execution time table 105 for storing the execution time corresponding to the calculated statistical reliability for each criticality level and the modified worst execution time table 106 are provided. Here, the information in the control request table 103 and the information in the reliability table 104 are input from the input IF 102.

FIG. 4 is a diagram conceptually showing an example of the configuration of the real-time control device 12 according to the present embodiment. As shown in FIG. 4, the real-time control device 12 includes a central processing unit (central processing unit, that is, a CPU) 121, a random access memory (random access memory, that is, RAM) 122, and a read-only memory (that is, RAM). It is provided with a read only memory, that is, a ROM) 123. However, these configurations are examples of the minimum configurations, and the configurations of the real-time control device 12 according to the present embodiment are not limited to the above. For example, the real-time control device 12 according to the present embodiment may include devices constituting a general computer system such as a network interface, a secondary storage device, a dedicated accelerator, or a user interface.

The ROM 123 includes the task execution file group 124 and the schedule result 125 derived by the scheduling device 10.

FIG. 5 is a diagram showing an example of the control request table 103 according to the present embodiment. As an example is shown in FIG. 5, the cycle, deadline, and criticity level of each task are assumed as the elements of the control request table 103. Here, the task cycle indicates a time interval in which the task is repeatedly executed.

Each task consists of repetition of task execution units called "jobs", and the kth job of each task is based on a certain time t ₀ (reference time t ₀ ) and has a reference time t ₀ + cycle. Execution starts after S × k and is completed _{by the deadline D k.} Here, the cycle S is a cycle in which the job is repeated.

Here, the reference time t ₀ may be the same for all tasks or may be different. When the reference time t ₀ differs between tasks, the element of the control request table 103 includes the reference time t _{0 as} well.

The criticity level indicates the magnitude of the impact on the mixed criticity system in the event of a deadline mistake, and the higher the impact (ie, the more serious the impact on the mixed criticity system), the greater the impact. Set to a higher criticality level.

FIG. 6 is a diagram showing an example of the reliability table 104 according to the present embodiment. As an example is shown in FIG. 6, statistical reliability for each criticality level is assumed as an element of the reliability table 104. Here, the statistical reliability means the statistical reliability regarding the execution time of each task.

FIG. 7 is a diagram showing an example of the worst execution time table 105 according to the present embodiment. As an example is shown in FIG. 7, the elements of the worst execution time table 105 are assumed to be their own criticity level and the execution time for each criticity level. Here, the own criticity level is the criticity level defined for each task, and is the same as the criticity level defined in the control request table 103. In addition, the execution time for each criticity level is stored as many as the number of criticity levels defined in the mixed criticity system. In the example shown in FIG. 7, worst-case execution time P ₅ from worst-case execution time P ₁ corresponding to each of the criticality level 1 to criticality level 5 it is stored. These worst execution times are calculated by the execution time calculation unit 112 in the execution time measuring device 11 based on the statistical reliability for each criticality level.

Here, the method of calculating the worst execution time _Pcl will be described with reference to FIG. Note that FIG. 8 is a diagram showing a histogram of the execution time when a certain task is repeatedly executed. The horizontal axis shows the execution time, and the vertical axis shows the number of occurrences of the corresponding execution time.

It is assumed that the statistical reliability of the criticality level cl defined in the reliability table 104 of the task whose execution time is distributed as described above is X%. In this case, the execution time (that is, the execution time corresponding to the X percentile) in which the lower X% (X% from the shorter execution time) in the entire distribution of the execution time of the task is contained is defined as the worst execution time _Pcl . Do this for all criticity levels of all tasks.

Next, a procedure for the execution time calculation unit 112 _{to calculate the worst execution time Pcl} will be described with reference to FIG. Here, FIG. 9 is a flowchart showing an example of the operation of the execution time calculation unit 112.

First, the execution time calculation unit 112 determines whether or not the worst execution time of all tasks has been calculated (step ST100). Then, when there is a task for which the worst execution time has not been calculated yet, that is, when it corresponds to "NO" branching from step ST100 shown in FIG. 9, the execution time measuring unit 111 may use the execution time measuring unit 111. A task i for which the worst execution time has not yet been calculated is selected, and the execution time of the task i is measured a predetermined number of times (step ST101). Then, the process proceeds to step ST102.

On the other hand, if the worst execution time of all tasks is calculated, that is, if it corresponds to "YES" branching from step ST100 shown in FIG. 9, the process proceeds to step ST104.

Next, in step ST102, the execution time calculation unit 112 determines whether or not the worst execution time of the task i at all the criticity levels has been calculated. Then, when the criticality level for which the worst execution time has not been calculated still remains, that is, when it corresponds to "NO" branching from step ST102 shown in FIG. 9, the execution time calculation unit 112 Calculates the worst execution time for the criticality level for which the worst execution time has not yet been calculated (step ST103). Then, the process returns to step ST102.

On the other hand, when the worst execution time of the task i at all the criticity levels is calculated, that is, when it corresponds to "YES" branching from step ST102 shown in FIG. 9, the process goes to step ST100. return.

Then, when the worst execution time of all the tasks at all the criticity levels is calculated, in step ST104, the execution time calculation unit 112 sets all the calculated worst execution times in the worst execution time table of the scheduling device 10. Store in 105. Then, the process is terminated.

Next, the procedure for deriving the optimum schedule by the scheduling device 10 will be described with reference to FIG. Here, FIG. 10 is a flowchart showing an example of the operation of the scheduling device 10.

First, the schedule derivation unit 101 in the scheduling device 10 acquires the objective function and additional constraints input by the user via the input IF 102 (step ST400). Then, the schedule derivation unit 101 derives the modified worst execution time table 106, which will be described later (step ST401).

Here, the method of deriving the modified worst execution time will be described with reference to FIG. Note that FIG. 13 is a diagram showing an example of the derived modified worst execution time.

As an example is shown in FIG. 13, when there are tasks a, b, and c in the mixed criticity system, it is assumed that the respective criticity levels are H, M, and L. It is assumed that the height of the criticity level is H> M> L.

For the criticity level higher than the criticity level of the task itself, do as follows to simplify the optimization problem described later.

For the criticity level equal to or lower than the criticity level of the task itself, the execution time measured by the execution time measuring device 11 is set as the modified worst execution time.

In the example shown in FIG. 13, since the task a has its own criticality level of H, the worst execution time modified at the criticality levels of H, M, and L is measured by the execution time measuring device 11. The executed execution times Pa _{and H} , the execution times Pa _{and M} , and the execution times Pa _{and L} are set, respectively.

Further, since the task b has its own criticity level of M, the execution time measured by the execution time measuring device 11 is set as the modified worst execution time of which the criticity level is M or M or less. Further, the worst-case execution time for correction is set as follows for the worst-case execution time for correction when the criticity level is H.

Further, since the task c has its own criticity level L, the execution time measured by the execution time measuring device 11 is set as the modified worst execution time when the criticity level is L. Further, the worst-case execution time for modification is set as follows for the worst-case execution time for modification with criticality levels H and M.

Returning to FIG. 10, the schedule derivation unit 101 in the scheduling device 10 solves the optimization problem based on the objective function, the additional constraint, and the basic constraint described later, and derives the optimum schedule (step ST402).

The objective function is arbitrarily set by the user, and for example, maximization of the margin time to the deadline or minimization of power consumption can be considered, but the objective function is not limited to these.

Additional constraints are also optional by the user, such as specifying dependencies between tasks (such as starting another task after the completion of a particular task), or specifying the execution core of a particular task. However, it is not limited to these.

The basic constraint is a constraint specified by the schedule derivation unit 101 by default regardless of the user's specification, and can be divided into three types: deadline constraint, periodic constraint, and core constraint. The basic constraint is expressed by the following formula.

Here, Ci _{, m, l, and t} are 1 if the task i is executing on the core m at the time t when the worst execution time corresponding to the criticality level l is required, and the core m. 0 if not executed above.

Further, z _{i, l, and t} are 1 if the task i is being executed at time t and 0 if the task i is not being executed when the task i requires the execution time corresponding to the criticality level l.

However, the constraint formula is not limited to the above, and a different formula may be used as long as the constraint has the intention shown below.

(A) Regarding the deadline constraint, if the task is executed at the worst execution time at its own criticality level, the task is completed before the deadline.

(B) Regarding the cycle constraint, the execution start time of the kth job of the task is k times or later of the set cycle.

(C) Regarding the core constraint, only one task is executed at each core and each time (time slot) at each criticality level.

The deadline constraint described above is to ensure that the task does not make deadline mistakes. Each task _{starts a job at time Ti, k} , and even if it is executed at the worst execution time Pi _{, l} at its own criticality level, it processes before _{the deadline time Di, k.} Need to be completed.

Further, the above periodic constraint is to guarantee that the execution start time of the job k _{does not come before t 0} + S × k.

Also, the above core constraints ensure that no more than one task runs on each core at the same time, but to meet the mixed integrity assurance scheduling policy, the integrity level. It is determined that one task is executed for each task.

Note that, with the above restrictions alone, there is a possibility that different execution cores will be determined for each criticality level in the same job, but in order to prevent this, it is the same core that performs the same job at the same time. Further restrictions may be imposed.

Next, the operation of the real-time control device 12 will be described with reference to FIG. Here, FIG. 11 is a flowchart showing an example of the operation of the real-time control device 12.

First, the real-time control device 12 acquires the schedule result 125 stored in the ROM 123 (step ST201).

Next, the real-time control device 12 sets the priority of the task in the order of the criticity level (step ST202). Specifically, the real-time control device 12 sets a higher priority for a task having a higher criticality level, and sets the same priority for a task having the same criticality level.

Next, the real-time control device 12 checks at regular intervals whether or not there is a task whose execution start time has come (step ST203). Here, as a constant interval, for example, a tick period is assumed.

Then, when there is a task whose execution start time has come, that is, when the real-time control device 12 corresponds to "YES" branching from step ST203 shown in FIG. 11, the real-time control device 12 proceeds to step ST204. On the other hand, when there is no task whose execution start time has come, that is, when it corresponds to "NO" branching from step ST203 shown in FIG. 11, the process returns to step ST203.

Next, in step ST204, the task whose execution start time has come is set to the executable state, and the process returns to step ST203.

In the present embodiment, among the execution times of each task measured repeatedly in advance, the execution time corresponding to the percentile of statistical reliability determined for each criticity level is set for each criticity level of each task. The worst execution time of.

Then, scheduling in the mixed criticity system is performed using the worst execution time for each of the above criticity levels. By doing so, the worst execution time for each criticity level is specifically determined by the corresponding statistical reliability, so that the reliability index guaranteed at each criticity level (that is, deadline mistakes) It is possible to quantitatively indicate (an index of how much it is guaranteed not to occur).

<Second embodiment>
A scheduling system and a scheduling method regarding the present embodiment will be described. In the following description, components similar to those described in the above-described embodiments will be illustrated with the same reference numerals, and detailed description thereof will be omitted as appropriate. ..

<Scheduling system configuration>
In the first embodiment, the worst execution time for each criticality level was set using percentiles. On the other hand, the worst execution time for each criticality level may be set using statistical confidence intervals.

Hereinafter, the procedure for the execution time calculation unit 112 _{to calculate the worst execution time Pcl} will be described with reference to FIG. Here, FIG. 12 is a flowchart showing an example of the operation of the execution time calculation unit 112 according to the present embodiment.

First, the execution time calculation unit 112 determines whether or not the statistical confidence intervals of all the tasks have been calculated (step ST300). Then, when there are still tasks for which the statistical confidence interval has not been calculated, that is, when corresponding to "NO" branching from step ST300 shown in FIG. 12, the execution time measuring unit 111 , The task i for which the statistical confidence interval has not been calculated is selected, and the execution time of the task i is measured a predetermined number of times (step ST301). Then, the process proceeds to step ST302.

On the other hand, when the statistical confidence intervals of all the tasks are calculated, that is, when it corresponds to "YES" branching from step ST300 shown in FIG. 12, the execution time calculation unit 112 performs processing. finish.

Next, in step ST302, the execution time calculation unit 112 calculates the standard deviation of the sample of task i using the execution time measured in step ST301 as a sample.

Next, the execution time calculation unit 112 calculates the confidence intervals of the statistical reliability corresponding to all the criticity levels defined in the reliability table 104 based on the standard deviation calculated in step ST302. Further, the upper boundary thereof is calculated (step ST303). The confidence interval is calculated on the assumption that the probability distribution of the population is a normal distribution.

The execution time calculation unit 112 stores the value of the upper boundary calculated in step ST303 as the worst execution time corresponding to each criticity level of the task i in the worst execution time table 105.

According to this embodiment, the worst execution time can be defined by the statistical confidence interval using the average value of the worst execution time of the population estimated from the sample of the execution time. Therefore, when the probability distribution of the population is assumed to be close to the normal distribution, scheduling can be performed using the worst execution time.

<Third embodiment>
A scheduling system and a scheduling method regarding the present embodiment will be described. In the following description, components similar to those described in the above-described embodiments will be illustrated with the same reference numerals, and detailed description thereof will be omitted as appropriate. ..

<Scheduling system configuration>
In the first embodiment and the second embodiment, scheduling satisfying the mixed criticity guarantee scheduling policy was performed. However, scheduling may be done for a normal real-time system with only a single criticality level. In that case, replace the core constraint as follows.

Here, z _{i, l, and t} are 1 if the task i is executing at the time t when the task i requires the execution time corresponding to the criticality level l, and 0 otherwise. Is.

Other configurations and operations are the same as those of the first embodiment or the second embodiment.

(D) Regarding the core constraint, the number of tasks to be executed at the same time is less than or equal to the number of cores.

According to this embodiment, even for a normal real-time system having only a single criticity level, which is not a mixed criticity system, the given objective function is optimal within the range that satisfies the deadline constraint. Schedule can be derived.

<About the hardware configuration of the scheduling system>
14 and 15 are diagrams schematically illustrating a hardware configuration when the scheduling system shown in FIGS. 1, 2 and 3 is actually operated.

Note that the hardware configurations exemplified in FIGS. 14 and 15 may not match the configurations illustrated in FIGS. 1, 2, and 3, but this may be inconsistent with those shown in FIGS. 1, 2, and 2. This is because the configuration exemplified in 3 indicates a conceptual unit.

Therefore, at least one configuration exemplified in FIGS. 1, 2 and 3 comprises a plurality of hardware configurations exemplified in FIGS. 14 and 15, and is exemplified in FIGS. 1, 2 and 3. One configuration to be made corresponds to a part of the hardware configurations exemplified in FIGS. 14 and 15, and further, a plurality of configurations exemplified in FIGS. 1, 2 and 3 are shown in FIG. And it may be assumed that one hardware configuration illustrated in FIG. 15 is provided.

In FIG. 14, as a hardware configuration for realizing the execution time measuring unit 111, the execution time calculation unit 112, and the schedule derivation unit 101 in FIGS. 1, 2, and 3, the processing circuit 1102A that performs the calculation and the information are displayed. A storage device 1103 that can be stored is shown. These configurations are the same in other embodiments.

FIG. 15 shows a processing circuit 1102B that performs an operation as a hardware configuration for realizing the execution time measuring unit 111, the execution time calculation unit 112, and the schedule derivation unit 101 in FIGS. 1, 2, and 3. The configuration is the same in other embodiments.

The modified worst execution time table 106, worst execution time table 105, control request table 103, and reliability table 104 are realized by the storage device 1103 or another storage device (not shown here).

The storage device 1103 is, for example, a hard disk drive (Hard disk drive, that is, HDD), RAM, ROM, flash memory, erasable programmable read only memory (EPROM), electrically erasable EEPROM, or volatile EEPROM. Alternatively, it may be a memory (storage medium) including a non-volatile semiconductor memory, a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, a DVD, or the like, or any storage medium used in the future.

The processing circuit 1102A may execute a program stored in a storage device 1103, an external CD-ROM, an external DVD-ROM, an external flash memory, or the like. That is, for example, it may be a CPU, a microprocessor, a microcomputer, or a digital signal processor (that is, a DSP).

When the processing circuit 1102A executes a program stored in a storage device 1103, an external CD-ROM, an external DVD-ROM, an external flash memory, or the like, the execution time measuring unit 111 and the execution time calculation unit The 112 and the schedule derivation unit 101 are realized by software, firmware, or a combination of software and firmware in which the program stored in the storage device 1103 is executed by the processing circuit 1102A. The functions of the execution time measurement unit 111, the execution time calculation unit 112, and the schedule derivation unit 101 may be realized, for example, by coordinating a plurality of processing circuits.

The software and firmware may be described as a program and stored in the storage device 1103. In that case, the processing circuit 1102A realizes the above function by reading and executing the program stored in the storage device 1103. That is, the storage device 1103 may store a program in which the above functions are eventually realized by being executed by the processing circuit 1102A.

Further, the processing circuit 1102B may be dedicated hardware. That is, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an integrated circuit (application specific integrated circuit, that is, an ASIC), a field-programmable gate array (FPGA), or a combination thereof. It may be a circuit.

When the processing circuit 1102B is dedicated hardware, the execution time measuring unit 111, the execution time calculation unit 112, and the schedule derivation unit 101 are realized by operating the processing circuit 1102B. The functions of the execution time measurement unit 111, the execution time calculation unit 112, and the schedule derivation unit 101 may be realized by separate circuits or may be realized by a single circuit.

The functions of the execution time measurement unit 111, the execution time calculation unit 112, and the schedule derivation unit 101 are partially realized in the processing circuit 1102A that executes the program stored in the storage device 1103, and some of them are dedicated. It may be realized in the processing circuit 1102B which is the hardware of the above.

<Effects caused by the above-described embodiments>
Next, an example of the effect caused by the above-described embodiment will be shown. In the following description, the effect is described based on the specific configuration shown in the embodiment described above, but to the extent that the same effect occurs, the examples are described in the present specification. May be replaced with other specific configurations indicated by.

Further, the replacement may be made across a plurality of embodiments. That is, it may be the case that the respective configurations shown in the examples in different embodiments are combined to produce the same effect.

According to the embodiment described above, in the scheduling method, the execution time of each task is repeatedly measured in a real-time system that schedules a plurality of tasks having different criticality levels. Then, of the execution times of each task measured multiple times, the execution time corresponding to the statistical reliability predetermined for each criticality level is set as the worst execution time for each criticality level. Schedule multiple tasks based on.

With such a configuration, the worst-case execution time for each criticity level is specifically determined by the corresponding statistical confidence, so that the reliability index (ie, deadline miss) guaranteed at each criticity level. It is possible to quantitatively indicate (an index of how much it is guaranteed not to cause a problem).

If there are no special restrictions, the order in which each process is performed can be changed.

Further, when other configurations shown in the present specification are appropriately added to the above configurations, that is, when other configurations in the present specification not mentioned as the above configurations are appropriately added. Even if there is, the same effect can be produced.

Further, according to the embodiment described above, among the execution times of the tasks measured a plurality of times, the execution time corresponding to the percentile of the statistical reliability predetermined for each criticity level is set as the criticity. The worst execution time for each level. With such a configuration, the worst-case execution time for each criticity level is specifically determined by the corresponding statistical confidence percentile, so the reliability index guaranteed at each criticity level is quantitatively determined. It becomes possible to show.

Further, according to the embodiment described above, the execution time of the task measured multiple times is used as a sample, and the confidence interval of the statistical reliability predetermined for each criticity level is used as the sample population. Is calculated as a normal distribution, and the execution time corresponding to the upper boundary of the confidence interval is defined as the worst execution time for each criticality level. With such a configuration, the worst execution time for each criticity level is specifically determined by the confidence interval of the corresponding statistical reliability, so the reliability index guaranteed for each criticity level is quantitative. It is possible to show in.

Further, according to the embodiment described above, scheduling includes a constraint condition that the task is completed before the deadline when the task is executed at the worst execution time corresponding to its own criticity level. It is done by solving a constrained optimization problem based on. With such a configuration, appropriate real-time scheduling can be performed by solving the optimization problem so as to satisfy the deadline constraint.

Further, according to the embodiment described above, in the scheduling, when the task consists of repeating jobs, the execution start time of the kth job of the task is k times or more of the cycle in which the jobs are repeated. It is done by solving a constrained optimization problem based on constraints including that. According to such a configuration, appropriate real-time scheduling can be performed by solving the optimization problem so as to satisfy the periodic constraint.

Further, according to the embodiment described above, in the scheduling, only one task is executed in the specific core that executes the task at each criticality level, and each criticity level is executed. Is performed by solving a constrained optimization problem based on constraints, including that only one task is executed at a particular time. With such a configuration, appropriate real-time scheduling can be performed by solving the optimization problem so as to satisfy the core constraint.

Further, according to the embodiment described above, scheduling is performed by solving a constrained optimization problem based on an objective function input from the outside and at least one of additional constraints. With such a configuration, appropriate real-time scheduling can be performed by solving the optimization problem so as to satisfy at least one of the objective function and the additional constraint.

According to the embodiment described above, the scheduling system includes an execution time measuring unit 111, an execution time calculation unit 112, and a schedule derivation unit 101. The execution time measuring unit 111 repeatedly measures the execution time of each task. The execution time calculation unit 112 calculates the execution time corresponding to the statistical reliability predetermined for each criticity level among the execution times of the tasks measured a plurality of times as the worst execution time for each criticity level. .. The schedule derivation unit 101 schedules a plurality of tasks in the real-time system based on the worst execution time.

Further, according to the embodiment described above, the scheduling system includes a processing circuit 1102A and a storage device 1103 for storing a program to be executed. Then, when the processing circuit 1102A executes the program, the following operations are realized.

That is, the execution time of each task is repeatedly measured. Then, among the execution times of each task measured a plurality of times, the execution time corresponding to the statistical reliability predetermined for each criticality level is defined as the worst execution time for each criticality level. Then, a plurality of tasks are scheduled based on the worst execution time.

Further, according to the embodiment described above, the scheduling system includes a processing circuit 1102B. Then, the processing circuit 1102B, which is the dedicated hardware, performs the following operations.

That is, the processing circuit 1102B, which is dedicated hardware, repeatedly measures the execution time of each task. Then, among the execution times of each task measured a plurality of times, the execution time corresponding to the statistical reliability predetermined for each criticity level is defined as the worst execution time for each criticity level. Then, a plurality of tasks are scheduled based on the worst execution time.

With such a configuration, the worst execution time for each criticity level is specifically determined by the corresponding statistical reliability, so the reliability index guaranteed for each criticity level is quantitatively shown. Is possible.

In addition, when other configurations shown in the present specification are appropriately added to the above configurations, that is, when other configurations in the present specification not mentioned as the above configurations are appropriately added. Even if there is, the same effect can be produced.

<About the modified example of the embodiment described above>
In the embodiments described above, the dimensions, shapes, relative arrangement relationships, implementation conditions, etc. of each component may also be described, but these are examples in all aspects. It shall not be limited.

Therefore, innumerable variants and equivalents for which examples are not shown are envisioned within the scope of the techniques disclosed herein. For example, when transforming, adding or omitting at least one component, or when extracting at least one component in at least one embodiment and combining it with the component in another embodiment. Shall be included.

Further, as long as there is no contradiction, the components described as being provided with "one" in the above-described embodiment may be provided with "one or more".

Further, the description in the present specification is referred to for all purposes related to the present technology, and none of them is recognized as a prior art.

Further, each component described in the above-described embodiment is assumed to be software or firmware and corresponding hardware, and in both concepts, each component is a "part". Alternatively, it is referred to as a "processing circuit" or the like.

Further, the technique disclosed in the present specification may be a case where each component is distributed and provided in a plurality of devices, that is, a system such as a combination of a plurality of devices may be used. ..

10 Scheduling device, 11 Execution time measuring device, 12 Real-time control device, 101 Schedule derivation unit, 102 Input IF, 103 Control request table, 104 Reliability table, 105 Worst execution time table, 106 Modified worst execution time table, 111 Execution time Measurement unit, 112 execution time calculation unit, 113 task group reception unit, 121 CPU, 122 RAM, 123 ROM, 124 task execution file group, 125 schedule results, 1102A, 1102B processing circuit, 1103 storage device.

Claims

In a real-time system that schedules multiple tasks with different criticality levels
The execution time of each of the above tasks is repeatedly measured and measured.
Of the execution times of each of the tasks measured a plurality of times, the execution time corresponding to the statistical reliability predetermined for each criticity level is defined as the worst execution time for each criticity level.
The scheduling of the plurality of the tasks is performed based on the worst execution time.
Scheduling method.
The scheduling method according to claim 1.
Of the execution times of the task measured a plurality of times, the execution time corresponding to the percentile of the statistical reliability predetermined for each criticity level is set as the worst execution time for each criticity level.
Scheduling method.
The scheduling method according to claim 1.
Using the execution time of the task measured multiple times as a sample, and calculating the confidence interval of the statistical reliability predetermined for each criticality level, assuming that the population of the sample is a normal distribution, further. The execution time corresponding to the upper boundary of the confidence interval is set as the worst execution time for each criticality level.
Scheduling method.
The scheduling method according to any one of claims 1 to 3.
The scheduling is
It is done by solving a constrained optimization problem based on constraints, including the task being completed before the deadline when the task is executed in the worst execution time corresponding to its own criticality level. ,
Scheduling method.
The scheduling method according to any one of claims 1 to 4.
The scheduling is
When the task consists of job repetitions, a constrained optimization problem based on constraints including that the execution start time of the kth job of the task is k times or more of the cycle in which the job is repeated is solved. It is done by solving,
Scheduling method.
The scheduling method according to any one of claims 1 to 5.
The scheduling is
At each said criticality level, only one task is performed at a particular core performing the task, and at each said criticity level, the task performed at a particular time is 1. It is done by solving a constrained optimization problem based on constraints, including only one.
Scheduling method.
The scheduling method according to any one of claims 1 to 6.
The scheduling is
It is done by solving a constrained optimization problem based on an externally input objective function and at least one of the additional constraints.
Scheduling method.
A real-time system with multiple tasks with different criticity levels,
An execution time measuring unit that repeatedly measures the execution time of each task,
Of the execution times of the task measured a plurality of times, the execution time corresponding to the statistical reliability predetermined for each criticity level is calculated as the worst execution time for each criticity level. Calculation unit and
A schedule deriving unit for scheduling the plurality of tasks in the real-time system based on the worst execution time is provided.
Scheduling system.