Real-time task execution time automatic determination method and device

Abstract

The application discloses a real-time task execution time automatic determination method and device. The method realizes configuration automation and policy by receiving configuration information containing a task cycle and an execution strategy and generating an initial execution time, and eliminates the dependence on manual experience. The initial time is safely normalized according to the worst-case execution time constraint and a safety margin, a dynamic quantifiable safety boundary is introduced, the result is ensured not to exceed the hardware safety threshold, and the system risk caused by improper configuration is eliminated. Finally, the validity of the normalized time is verified through minimum value checking and schedulability evaluation, and the effective execution time is output, so that the rationality and executability of the result are ensured. The method realizes the automation, safety and high reliability of the execution time configuration.

Description

Technical Field

[0001] This application relates to the field of computer system technology, and in particular to a method and apparatus for automatically determining the execution time of real-time tasks. Background Technology

[0002] In time-partitioned real-time scheduling systems, the execution time configuration of real-time tasks is a core parameter affecting system stability, predictability, and resource utilization. Existing solutions rely entirely on manual settings based on technical personnel's experience, lacking objective calculation basis and prone to resource waste or task timeouts due to improper configuration. Furthermore, existing methods only support a single fixed configuration mode, failing to adapt and optimize based on task characteristics and system status. More critically, the existing configuration process lacks a unified security constraint framework, failing to consider the worst-case execution time limits of the hardware, posing a risk of task execution times exceeding hardware capacity and causing system failures. In addition, when the number of system tasks increases or parameters change, manual configuration becomes inefficient and costly to maintain. Summary of the Invention

[0003] This application provides a method and apparatus for automatically determining the execution time of real-time tasks, which aims to systematically achieve automation, security and high reliability of execution time configuration.

[0004] Firstly, this application provides a method for automatically determining the execution time of a real-time task, including:

[0005] Receive task configuration information corresponding to a real-time task, wherein the configuration information includes at least the task period and a preset execution time determination strategy;

[0006] Based on the execution time determination strategy, an initial execution time corresponding to the task cycle is generated;

[0007] If the configuration information includes a worst-case execution time constraint, then the initial execution time is safely normalized according to the worst-case execution time constraint and the preset safety margin to obtain the normalized execution time;

[0008] The normalized execution time is validated, and the validated valid execution time is output.

[0009] Secondly, this application provides a device for automatically determining the execution time of a real-time task, comprising:

[0010] The first unit is used to receive task configuration information corresponding to a real-time task, wherein the configuration information includes at least the task period and a preset execution time determination strategy.

[0011] The second unit is used to determine the strategy based on the execution time and generate an initial execution time corresponding to the task cycle.

[0012] The third unit is used to perform safety regulation on the initial execution time based on the worst-case execution time constraint and the preset safety margin if the configuration information contains a worst-case execution time constraint, so as to obtain the regulated execution time.

[0013] The fourth unit is used to verify the validity of the normalized execution time and output the verified valid execution time.

[0014] Thirdly, this application provides a readable medium including executable instructions, which, when executed by a processor of an electronic device, cause the electronic device to perform any of the methods described in the first aspect.

[0015] Fourthly, this application provides an electronic device including a processor and a memory storing execution instructions, wherein when the processor executes the execution instructions stored in the memory, the processor performs the method as described in any of the first aspects.

[0016] As can be seen from the above technical solutions, the real-time task execution time automatic determination method provided in this application, by receiving task configuration information containing task cycle and execution time determination strategy, and generating an initial execution time corresponding to the task cycle based on the strategy, automates and stratifies the configuration process, fundamentally eliminating reliance on human experience and significantly improving the objectivity and scenario adaptability of the configuration. Furthermore, by determining whether the configuration information contains a worst-case execution time constraint, and if so, performing safety regularization on the initial execution time based on the constraint and a preset safety margin to obtain a regularized execution time, this method introduces a dynamic and quantifiable safety boundary for execution time configuration, ensuring that the result never exceeds the hardware safety threshold, thereby completely eliminating system stability risks caused by improper configuration. Finally, by performing validity verification on the regularized execution time, including minimum value verification and schedulability evaluation, and outputting the verified valid execution time, this process ensures the rationality and executability of the output result, enabling it to be directly used safely and efficiently by the scheduling system. In summary, this invention, through the above-mentioned sequential steps, systematically achieves automation, security, and high reliability in execution time configuration.

[0017] The further effects of the aforementioned non-conventional preferred method will be explained below in conjunction with specific embodiments. Attached Figure Description

[0018] To more clearly illustrate the embodiments of this application or the existing technical solutions, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a method for automatically determining the execution time of a real-time task, as provided in this application;

[0020] Figure 2 A schematic diagram of a device for automatically determining the execution time of a real-time task is provided in this application;

[0021] Figure 3 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] See Figure 1 This paper illustrates a method for automatically determining the execution time of a real-time task according to an embodiment of this application. In this embodiment, the method includes the following steps:

[0024] S101: Receive the task configuration information corresponding to the real-time task.

[0025] In this embodiment, the configuration information includes at least the task cycle and a preset execution time determination strategy.

[0026] The execution time determination strategy includes at least one of the following: a manual configuration strategy directly specified by the user, a calculation strategy derived from the target CPU utilization rate, and a conservative estimation strategy that calculates the task cycle based on a preset fixed ratio.

[0027] Understandably, in this step, the system receives various parameters of the real-time task to be configured. These parameters are collectively referred to as task configuration information and are the basis for all subsequent calculations. Among them, the task period refers to the fixed time interval at which the real-time task is scheduled for execution, typically measured in microseconds (μs), and is the core benchmark parameter for calculating execution time. The execution time determination strategy is the core algorithmic logic specified by the user (or the upper-level system) for this calculation; it determines how the initial execution time value is derived from the task period. In this embodiment, the strategy includes at least one of the following:

[0028] Manual configuration strategy: The user directly specifies a fixed execution time value. This strategy is suitable for scenarios where task behavior is stable and execution time has been accurately measured.

[0029] The calculation strategy based on target CPU utilization: By setting a desired CPU utilization target, the required execution time is derived in reverse. This strategy is suitable for scenarios that aim to optimize system resource utilization.

[0030] A conservative estimation strategy based on a preset fixed percentage to adjust the task cycle: The task cycle is directly adjusted using a preset, relatively conservative percentage to obtain a safe estimate of the execution time. This strategy is suitable for scenarios where the task execution time is unknown and safety and stability are the highest priorities.

[0031] In addition, task configuration information may include other optional parameters, such as: the task name, the bound CPU core number, the real-time priority, and the time partition ID. Most importantly, it may include worst-case execution time constraints and safety margins. The worst-case execution time constraint, often called WCET (Worst-Case Execution Time), refers to the longest execution time the task may take on a specific hardware platform; this is a physical upper limit determined by both hardware characteristics and the task code. The safety margin (also known as the safety safety limit) is a percentage-based buffer value used to handle minor time fluctuations that may occur during actual operation, improving the system's robustness.

[0032] S102: Based on the execution time determination strategy, generate an initial execution time corresponding to the task cycle.

[0033] In one embodiment, when the execution time determination strategy is a calculation strategy derived based on the target CPU utilization rate, generating an initial execution time corresponding to the task cycle based on the execution time determination strategy specifically involves: obtaining the target CPU utilization rate parameter configured for the real-time task;

[0034] The initial execution time is calculated based on the positive proportional relationship between the task cycle and the target CPU utilization parameter.

[0035] In one embodiment, when the execution time determination strategy is a conservative estimation strategy that calculates the task cycle based on a preset fixed ratio, generating an initial execution time corresponding to the task cycle based on the execution time determination strategy specifically involves multiplying the task cycle by a predetermined percentage coefficient to obtain the initial execution time.

[0036] This step executes specific computational logic based on the strategy selected in S101, generating a preliminary execution time result, referred to as the initial execution time.

[0037] When the execution time determination strategy is a computational strategy derived from the target CPU utilization:

[0038] The main strategy is that the proportion of a task's execution time to its cycle should equal the proportion of CPU time it is expected to occupy. The implementation process includes: first, obtaining the target CPU utilization parameter configured for the real-time task from the configuration information (e.g., 50%, indicating that the task is expected to occupy 50% of the CPU time); then, calculating the initial execution time based on the direct proportional relationship between the task cycle and the target CPU utilization parameter. The specific calculation formula can be expressed as: Initial execution time = Task cycle × Target CPU utilization percentage / 100. For example, for a task with a cycle of 2000 microseconds (2ms), if the target CPU utilization is 50%, the calculated initial execution time is 1000 microseconds.

[0039] When the execution time determination strategy is a conservative estimation strategy based on a preset fixed ratio to calculate the task cycle:

[0040] This strategy primarily employs an empirical, conservative ratio to quickly estimate execution time. The process involves multiplying the task cycle by a predetermined percentage factor to obtain the initial execution time. In a preferred embodiment of the invention, this percentage factor is set to 10%. This means that for any task with an unknown execution time, the system assumes its execution time will not exceed 10% of its cycle. For example, a task with a cycle of 5000 microseconds will directly yield an initial execution time of 500 microseconds using this strategy. This is a simple and safe estimation method.

[0041] When the execution time determination strategy is a manually configured strategy:

[0042] The implementation process is more direct; the system directly uses the execution time value provided by the user in the configuration information as the initial execution time, without the need for additional calculations.

[0043] S103: If the configuration information includes a worst-case execution time constraint, then the initial execution time is safely normalized according to the worst-case execution time constraint and the preset safety margin to obtain the normalized execution time.

[0044] In one embodiment, a safety constraint time limit can be calculated by adding a safety margin expressed as a percentage to the worst-case execution time constraint value; the initial execution time is compared with the safety constraint time limit, and the smaller of the two is taken as the normalized execution time. In one embodiment, the safety margin is 20% or 5% to 50%.

[0045] This step is a crucial step in ensuring system security and can be called security conditioning. Its purpose is to ensure that any calculated execution time does not exceed the physical limits that the hardware can withstand (i.e., WCET), and to leave a safety buffer.

[0046] First, the system checks if the configuration information contains a valid worst-case execution time constraint value. If it does, the safety conditioning process is initiated; otherwise, this step is skipped, and the initial execution time is directly passed to the next step.

[0047] The specific implementation of safety regulations may include two sub-steps:

[0048] Calculate the upper limit of the safety constraint time: Based on the worst-case execution time constraint value, add the safety margin expressed as a percentage to obtain an upper limit of the safety constraint time. The calculation formula is: Upper limit of safety constraint time = worst-case execution time constraint value × (100 + safety margin percentage) / 100. For example, if WCET is 300μs and the safety margin is 20%, then the upper limit of the safety constraint time is 360μs. This step is equivalent to artificially setting a stricter and safer upper limit within the absolute limit of the hardware.

[0049] Comparison and Value Selection: The initial execution time is compared with the upper limit of the safety constraint time, and the smaller of the two is taken as the normalized execution time. This step follows the principle of "minimizing risk." Even if the initial execution time calculated by the strategy (e.g., 400μs) is already efficient, if it exceeds the upper limit of the safety constraint (360μs), it will be forcibly limited to that upper limit value, thereby absolutely ensuring that no hardware-level timeout risk is triggered. If the initial execution time is lower, its value is retained.

[0050] Regarding the safety margin, in one embodiment, the default value is 20%. In another embodiment, its value is limited to between 5% and 50%, and users can adjust it within this range according to the security level of the specific application scenario. The higher the value, the more conservative the system and the higher the security, but it may sacrifice some resource utilization.

[0051] S104: Verify the validity of the normalized execution time and output the verified valid execution time.

[0052] In one embodiment, if the validity verification is a minimum value threshold verification, it can be determined whether the normalized execution time is less than the preset system minimum time unit; if the normalized execution time is less than the preset system minimum time unit, the normalized execution time is adjusted to be equal to the system minimum time unit, and the adjusted normalized execution time is taken as the verified valid execution time; if the normalized execution time is greater than or equal to the preset system minimum time unit, the normalized execution time is taken as the verified valid execution time.

[0053] In one embodiment, if the validity verification is a schedulability pre-check, then if the normalized execution time does not exceed the task cycle, the normalized execution time is taken as the verified valid execution time.

[0054] Understandably, after completing the safety curvature, a final validity verification of the obtained curated execution time (or the initial execution time if step S103 is not performed) is required to ensure that it is not only mathematically sound but also theoretically feasible. Once the verification is successful, the final usable execution time is output.

[0055] Validation mainly includes two types, which can be used alone or in combination:

[0056] Minimum Threshold Verification: This is implemented by determining whether the normalized execution time is less than a preset system minimum time unit. This system minimum time unit is the smallest time granularity that the scheduling system can recognize and process, for example, 1 microsecond. If the normalized execution time is less than the preset system minimum time unit, the normalized execution time is adjusted to be equal to the system minimum time unit, and then the adjusted time is output as the verified valid execution time. If the normalized execution time is greater than or equal to the preset system minimum time unit, it is directly output as the verified valid execution time. This verification prevents meaningless (e.g., 0 or negative values) or excessively small execution times due to calculation errors or improper configuration.

[0057] Scheduling pre-check: This implementation is based on real-time scheduling theory and determines whether a task can be successfully scheduled given a period and execution time. A basic criterion is that if the adjusted execution time does not exceed the task period, then the adjusted execution time is considered a verified valid execution time. More formally, it checks whether the ratio of "execution time / task period" is less than or equal to 1. If the ratio is greater than 1, it means that the time required for one execution of the task has exceeded its period, which is obviously unschedulable. In this case, the system can output a warning, prompting the user to readjust the strategy or parameters. In a specific embodiment, this check is implemented based on the classic Liu & Layland schedulability determination algorithm.

[0058] In one embodiment, after the step of validating the normalized execution time and outputting the verified valid execution time, the method further includes:

[0059] Monitor the actual execution time of the real-time task during runtime;

[0060] The actual execution time of the real-time task during runtime is used as the historical time data of the real-time task.

[0061] If the real-time task is executed again, the execution time determination strategy or safety margin used when determining the execution time of the same real-time task will be dynamically adjusted based on the historical time data of the real-time task.

[0062] Understandably, after outputting the effective execution time and starting the task, this method can also include a continuous optimization closed loop: monitoring the actual execution time of the real-time task during runtime; using the actual execution time of the real-time task as historical time data; and dynamically adjusting the execution time determination strategy or safety margin used when determining the execution time of the same real-time task based on the historical time data if the real-time task is executed again. For example, if the system detects that a task using a "conservative estimation strategy" has an actual execution time that is consistently much lower than the estimated value, then in the next configuration, the system can automatically suggest or switch to a "computation strategy derived from the target CPU utilization rate" to improve resource utilization. This gives the system the ability to learn from operational experience and optimize itself.

[0063] To facilitate understanding, a brief application scenario is provided here. Assume a heart rate processing task (cycle length 5000μs) in a medical monitoring device. Its precise execution time is unknown, but the hardware WCET is known to be 800μs. The user selects a "conservative estimation strategy" (10%), and the system calculates an initial execution time of 500μs in S102. In S103, based on WCET = 800μs and a safety margin of 20%, the system calculates a safety constraint upper limit of 960μs. Since 500μs < 960μs, the normalized execution time remains 500μs. In S104, it is verified that 500μs is greater than the minimum threshold of 1μs, and 500 / 5000 = 0.1 < 1, satisfying schedulability. Therefore, the final output is 500μs as the effective execution time. This method provides a safe estimate when the precise time is unknown and ensures the absolute safety of the result through WCET constraints and multiple checks.

[0064] As can be seen from the above technical solutions, the real-time task execution time automatic determination method provided in this application, by receiving task configuration information containing task cycle and execution time determination strategy, and generating an initial execution time corresponding to the task cycle based on the strategy, automates and stratifies the configuration process, fundamentally eliminating reliance on human experience and significantly improving the objectivity and scenario adaptability of the configuration. Furthermore, by determining whether the configuration information contains a worst-case execution time constraint, and if so, performing safety regularization on the initial execution time based on the constraint and a preset safety margin to obtain a regularized execution time, this method introduces a dynamic and quantifiable safety boundary for execution time configuration, ensuring that the result never exceeds the hardware safety threshold, thereby completely eliminating system stability risks caused by improper configuration. Finally, by performing validity verification on the regularized execution time, including minimum value verification and schedulability evaluation, and outputting the verified valid execution time, this process ensures the rationality and executability of the output result, enabling it to be directly used safely and efficiently by the scheduling system. In summary, this invention, through the above-mentioned sequential steps, systematically achieves automation, security, and high reliability in execution time configuration.

[0065] like Figure 2 The image shows a specific embodiment of a real-time task execution time automatic determination device provided in this application. The device described in this embodiment is a physical device used to execute the method described in the above embodiments. Its technical solution is essentially the same as that of the above embodiments, and the corresponding descriptions in the above embodiments are also applicable to this embodiment. The device in this embodiment includes:

[0066] The first unit 201 is used to receive task configuration information corresponding to a real-time task, wherein the configuration information includes at least the task period and a preset execution time determination strategy.

[0067] The second unit 202 is used to generate an initial execution time corresponding to the task cycle based on the execution time determination strategy.

[0068] The third unit 203 is used to perform safety regulation on the initial execution time according to the worst-case execution time constraint and the preset safety margin if the configuration information contains a worst-case execution time constraint, so as to obtain the regulated execution time.

[0069] The fourth unit 204 is used to verify the validity of the normalized execution time and output the verified valid execution time.

[0070] Optionally, the execution time determination strategy includes at least one of the following:

[0071] Manual configuration strategies specified directly by the user;

[0072] Calculation strategy derived from target CPU utilization;

[0073] A conservative estimation strategy based on a preset fixed ratio to calculate the task cycle.

[0074] Optionally, when the execution time determination strategy is a calculation strategy derived based on the target CPU utilization, generating the initial execution time corresponding to the task cycle based on the execution time determination strategy includes:

[0075] Obtain the target CPU utilization parameters configured for the real-time task;

[0076] The initial execution time is calculated based on the positive proportional relationship between the task cycle and the target CPU utilization parameter.

[0077] Optionally, when the execution time determination strategy is a conservative estimation strategy that calculates the task cycle based on a preset fixed ratio, generating an initial execution time corresponding to the task cycle based on the execution time determination strategy includes:

[0078] The initial execution time is obtained by multiplying the task cycle by a predetermined percentage coefficient.

[0079] Optionally, the step of performing safety normalization on the initial execution time based on the worst-case execution time constraint and a preset safety margin to obtain the normalized execution time includes:

[0080] Based on the worst-case execution time constraint value, and by adding the safety margin expressed as a percentage, a safety constraint time limit is calculated.

[0081] The initial execution time is compared with the upper limit of the safety constraint time, and the smaller of the two is taken as the normalized execution time.

[0082] Optionally, the safety margin is 20% or 5% to 50%.

[0083] Optionally, if the validity verification is a minimum threshold verification, then the validity verification of the normalized execution time and the output of the verified valid execution time includes:

[0084] Determine whether the normalized execution time is less than the preset minimum system time unit;

[0085] If the normalized execution time is less than the preset minimum system time unit, the normalized execution time is adjusted to be equal to the minimum system time unit, and the adjusted normalized execution time is taken as the verified effective execution time.

[0086] If the normalized execution time is greater than or equal to the preset minimum system time unit, then the normalized execution time is taken as the verified valid execution time.

[0087] Optionally, if the validity verification is a schedulability pre-check, then the validity verification of the normalized execution time and the output of the verified valid execution time includes:

[0088] If the adjusted execution time does not exceed the task cycle, the adjusted execution time will be used as the verified effective execution time.

[0089] Optionally, after the step of validating the normalized execution time and outputting the valid execution time, the method further includes:

[0090] Monitor the actual execution time of the real-time task during runtime;

[0091] The actual execution time of the real-time task during runtime is used as the historical time data of the real-time task.

[0092] If the real-time task is executed again, the execution time determination strategy or safety margin used when determining the execution time of the same real-time task will be dynamically adjusted based on the historical time data of the real-time task.

[0093] Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include RAM, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk storage device. Of course, the electronic device may also include other hardware required for other services.

[0094] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0095] Memory is used to store instructions for execution. Specifically, instructions for execution are computer programs that can be executed. Memory can include main memory and non-volatile memory, and it provides the processor with execution instructions and data.

[0096] In one possible implementation, the processor reads the corresponding execution instructions from non-volatile memory into main memory and then executes them. Alternatively, it may obtain the corresponding execution instructions from other devices to form a real-time task execution time automatic determination device at the logical level. The processor executes the execution instructions stored in the memory to implement the real-time task execution time automatic determination method provided in any embodiment of this application through the executed execution instructions.

[0097] The above is as stated in this application. Figure 1The method for automatically determining the real-time task execution time provided in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor.

[0098] The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0099] This application also proposes a readable medium that stores execution instructions. When the stored execution instructions are executed by the processor of an electronic device, the electronic device can execute the real-time task execution time automatic determination method provided in any embodiment of this application, and is specifically used to execute the above-mentioned real-time task execution time automatic determination method.

[0100] The electronic devices described in the foregoing embodiments may be computers.

[0101] Those skilled in the art will understand that the embodiments of this application can be provided as methods or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or a combination of software and hardware.

[0102] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

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

[0104] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for automatically determining the execution time of a real-time task, characterized in that, include: Receive task configuration information corresponding to a real-time task, wherein the configuration information includes at least the task period and a preset execution time determination strategy; Based on the execution time determination strategy, an initial execution time corresponding to the task cycle is generated. Specifically, when the execution time determination strategy is a calculation strategy derived based on the target CPU utilization rate, the target CPU utilization rate parameter configured for the real-time task is obtained, and the initial execution time is calculated according to the positive proportional relationship between the task cycle and the target CPU utilization rate parameter. When the execution time determination strategy is a conservative estimation strategy that calculates the task cycle based on a preset fixed ratio, the task cycle is multiplied by a predetermined percentage coefficient to obtain the initial execution time. If the configuration information includes a worst-case execution time constraint, then the initial execution time is safety-normalized according to the worst-case execution time constraint and the preset safety margin to obtain the normalized execution time; specifically, this includes: superimposing the worst-case execution time constraint value on the product of the worst-case execution time constraint value and the safety margin expressed as a percentage to calculate a safety constraint time upper limit; comparing the initial execution time with the safety constraint time upper limit, and taking the smaller value of the two as the normalized execution time; The normalized execution time is validated for effectiveness, and the validated effective execution time is output. Validity validation includes minimum threshold verification and schedulability pre-check. Minimum threshold verification specifically includes: determining whether the normalized execution time is less than a preset system minimum time unit; if the normalized execution time is less than the preset system minimum time unit, the normalized execution time is adjusted to be equal to the system minimum time unit, and the adjusted normalized execution time is taken as the validated effective execution time; if the normalized execution time is greater than or equal to the preset system minimum time unit, the normalized execution time is taken as the validated effective execution time. The schedulability pre-check includes: if the ratio of the normalized execution time to the task cycle is greater than 1, the real-time task is determined to be unschedulable, and the user is prompted to readjust the strategy. Monitor the actual execution time of the real-time task during runtime; use the actual execution time of the real-time task as the historical time data of the real-time task; if the real-time task is executed again, dynamically adjust it to the execution time determination strategy or the safety margin used when determining the execution time of the same real-time task, based on the historical time data of the real-time task.

2. The method according to claim 1, characterized in that, The safety margin is 20% or 5% to 50%.

3. A device for automatically determining the execution time of a real-time task, characterized in that, include: The first unit is used to receive task configuration information corresponding to a real-time task, wherein the configuration information includes at least the task period and a preset execution time determination strategy. The second unit is used to generate an initial execution time corresponding to the task cycle based on the execution time determination strategy. Specifically, when the execution time determination strategy is a calculation strategy derived based on the target CPU utilization rate, the unit obtains the target CPU utilization rate parameter configured for the real-time task and calculates the initial execution time according to the positive proportional relationship between the task cycle and the target CPU utilization rate parameter. When the execution time determination strategy is a conservative estimation strategy that calculates the task cycle based on a preset fixed ratio, the task cycle is multiplied by a predetermined percentage coefficient to obtain the initial execution time. The third unit is used to perform safety normalization on the initial execution time based on the worst-case execution time constraint and a preset safety margin if the configuration information includes a worst-case execution time constraint, to obtain a normalized execution time. Specifically, this includes: superimposing the worst-case execution time constraint value on the product of the worst-case execution time constraint value and the safety margin expressed as a percentage to calculate a safety constraint time upper limit; comparing the initial execution time with the safety constraint time upper limit, and taking the smaller value of the two as the normalized execution time. The fourth unit is used to verify the validity of the normalized execution time and output the verified valid execution time. The validity verification includes minimum threshold verification and schedulability pre-check. The minimum threshold verification specifically includes: determining whether the normalized execution time is less than the preset system minimum time unit; if the normalized execution time is less than the preset system minimum time unit, the normalized execution time is adjusted to be equal to the system minimum time unit, and the adjusted normalized execution time is taken as the verified valid execution time; if the normalized execution time is greater than or equal to the preset system minimum time unit, the normalized execution time is taken as the verified valid execution time. The schedulability pre-check includes: if the ratio of the normalized execution time to the task cycle is greater than 1, the real-time task is determined to be unschedulable, and the user is prompted to readjust the strategy. Monitor the actual execution time of the real-time task during runtime; use the actual execution time of the real-time task as the historical time data of the real-time task; if the real-time task is executed again, dynamically adjust it to the execution time determination strategy or the safety margin used when determining the execution time of the same real-time task, based on the historical time data of the real-time task.

Images