Model-Based Worst-Case Execution Time Analysis for a Partitioning System

Abstract

A system and method for calculating worst-case execution times for actions in a process. The process is divided into multiple subprocesses, each performing a specific set of actions and operating according to its own partition schedule, independent of other partitions. The method includes the steps of: preparing a Unified Modeling Language (UML) activity diagram containing the actions in the process; identifying each action in the diagram; identifying each possible processing path for the actions in the process; assigning each action in each path to one of the subprocesses in the partition; determining the time it takes each action to traverse each path based on the partition schedule; and aggregating the time it takes to execute the actions in each path. The method reports the longest time for executing the process along each path based on the aggregated times.

Description

Technical Field

[0001]

[0001] The present disclosure generally relates to systems and methods for calculating worst-case execution times for actions in a process that includes a plurality of split sub-processes, and more particularly, to the process of assigning each action in each path of the process across an activity diagram to a sub-process, and the process of assigning each sub-process to a partition based on a split schedule, and systems and methods for calculating worst-case execution times for actions in a process that includes a plurality of split sub-processes. Prior Art

[0002]

[0002] Partitioned computer systems and processes are becoming an increasingly common approach to reducing the size, weight, and power requirements of embedded systems. Each partitioned process operates according to its own schedule and perhaps at its own processing speed. Partitioned processes are increasingly being used in the art to ensure time and space separation within safety-critical systems. For example, when taking up the command to fire a weapon on a fighter aircraft, it goes through various processes in a weapon launch chain that can be partitioned based on the importance of the weapon to the aircraft.

[0003]

[0003] In order to ensure that these partitioning systems meet all applicable safety requirements, they often execute a frame-based schedule within partitions, and a deterministic guarantee of system timing is often required. Such system timing is often analyzed in two ways, namely, analysis of the frame-based schedule to determine the worst-case timing, and statistical timing analysis of the implemented code. Analysis of the frame-based schedule enables early detection of timing problems in the system architecture, but it is often a cumbersome process. This is because, to determine the worst-case timing, all possible cases in the system design and partition schedule have to be manually walked through.

Summary of the Invention

Means for Solving the Problems

[0004]

[0004] The following discussion discloses and describes a system and method for calculating the worst-case execution time for actions in a process divided into a plurality of sub-processes. The plurality of sub-processes execute certain of the actions and operate according to their own partition schedules independently of other partitions. This method identifies each action executed by the process, identifies a first action from all the actions executed by the process, and checks all the paths from the first action to the end of the actions that the process may execute. Further, this method assigns each action in each path to one of the sub-processes in the partition, determines when each sub-process operates and for how long based on the partition schedule, and assigns each sub-process to a partition. Also, this method determines, based on the partition schedule, the time taken to complete the first action for one of the paths, determines whether the next action in this one path is performed in the same partition as the first action, and if so, determines the time taken to complete the next action based on the partition schedule, and if not, determines the time taken to transfer from the sub-process executing in the partition having the first action to the sub-process executing in the partition having the next action. This method continues to determine whether the next action and the immediately preceding action are performed in the same partition until the time taken to execute all the actions for one path is determined, and further determines that there are no actions left in that one path for which timing needs to be determined. This method determines whether the time taken to execute all the actions in all the possible paths has been determined, and if not, for all the paths, starting from the first action in the other paths, determines the time taken to complete the actions in the same way based on the partition schedule until the time taken to execute all the actions is determined. This method integrates the time taken to execute the actions in each path and determines how long each processing path takes.

[0005]

[0005] By considering the following description and the appended claims in conjunction with the accompanying drawings, further features of the present disclosure will become apparent.

Brief Description of the Drawings

[0006]

Figure 1

Figure 2

Figure 3

Modes for Carrying Out the Invention

[0007]

[0009] The following discussion regarding embodiments of the present disclosure directed to a system and method for calculating the worst - case execution time for actions in a process that includes multiple split sub - processes is, by its nature, merely illustrative and is not intended to limit the disclosure, nor is it intended to limit its use or application in any way.

[0008]

[0010] Figure 1 shows a Unified Modeling Language (UML) activity diagram 10 that depicts a specific process executed by a system. This diagram includes four partitions 12, 14, 16, and 18, each representing the location of a partitioned or parsed sub-process where a portion of the overall process is executed. Each sub-process executes simultaneously, independently of the other sub-processes, and at its own processing speed, based on its own schedule. In Figure 10, the sub-process executed in partition 12 processes the input supplied by the user in action box 22. The processed input from action box 22 is then sent to action box 24 in partition 14 to verify the input information. The action executed in action box 24 can verify the input and pass the verified and processed input to the first action action box 26 in partition 16, or pass the verified input to decision action 28 in partition 14 to determine whether this action is valid. In decision action 28, if the action is not determined to be valid, a rejection message is sent back to partition 12 in action box 30 to notify the user of an invalid action. If an action is executed in box 26, then in action box 32 in partition 18, the result of the action is verified, and the result of the verification operation is sent to the action box in partition 18 and the result is notified to partition 12. If the action is determined to be valid in decision action 28, the determined valid input is passed to the second action action box 36 in partition 16. In the second action action box 36, an action can be executed and then the processed input can be sent to action box 26, or the processed input can be passed directly to box 32.

[0009]

[0011] The flow of information between partitions and between actions as described above can follow four separate paths that require different processing times. That is, in order to determine when to execute sub-processes in other partitions 12 - 18, it is necessary to determine the maximum time that might be taken for processing in each of partitions 12 - 18. In this example, the first path includes processing of the input in box 22, then verification of the input in box 24, then execution of the action in box 26, then verification of the action result in box 32, further sending out of the result in box 34, and then providing the activity final report in partition 12. The second path includes processing of the input in box 22, then verification of the input in box 24, then determination that the action in decision action 28 is valid, then execution of the action in box 36, then verification of the result in box 32, then sending out of the result in box 34, and then providing the activity final report in partition 12. The third path includes processing of the input in box 22, then verification of the input in box 24, then determination that the action in decision diamond 28 is valid, then execution of the action in box 36, then execution of the action in box 26, then verification of the result in box 32, then sending out of the result in box 34, and then providing the activity final report in partition 12. The fourth path includes processing of the input in box 22, verification of the input in box 24, then determination that the action in decision diamond 28 is not valid, then sending out of the rejection message in box 30, and then providing the activity final report in partition 12.

[0010]

[0012] FIG. 2 is a block diagram of a system 40 that calculates worst-case execution times for actions in a process that includes a plurality of split sub-processes. Here, system 40 is intended to represent any processor, computer, or computing system that can perform the operations discussed herein. System 40 includes an activity diagram parser processor 42. This activity diagram parser processor 42 receives, on line 44, a UML activity diagram written in an extensible markup language (XML), such as in the XMI format (XML metadata interchange), which is a standard when exchanging metadata information, from a user. Processor 42 identifies each action in this diagram, identifies each possible processing path for these actions in the process, and assigns these actions to sub-processes. This information is also provided to a schedule parser processor 46. The schedule parser processor 46 also receives a split schedule from the user on line 48. The split schedule identifies when and for how long each sub-process is to be executed. Processor 46 determines, based on the schedule, the time required for each action to pass through each path. The schedule includes the time to move between partitions if the paths cross between more than one partition. The time required to execute an action for each path is supplied to a worst-case time calculator 50, which can further receive timing constraints from the user on line 52. Calculator 50 calculates the worst-case execution time for the path with the longest execution time and supplies this time on line 54.

[0011]

[0013] Figure 3 is, for example, a flowchart diagram 58 showing the operation of a processing tool that calculates the worst timing of a particular process using, for example, system 40. This tool starts at box 60 and, at box 62, opens a file provided by the user for a particular activity diagram associated with the process written in XMI format, and at box 64 identifies each individual action in the process one by one. Next, the tool determines, at box 66, the first action to be executed by the process in the diagram, and at box 68 identifies one of the possible processing paths that will complete this process by passing through from that action to the end of this diagram. Next, the tool determines, in decision diamond 70, whether all of the possible paths passing through from the first action to the end of this diagram have been identified, and if not, returns to box 68 to identify another processing path starting from the first action. If all of the processing paths have been identified in decision diamond 70, then at box 72, the tool then assigns each action in each path to a particular split sub-process. This gives the tool an understanding of the process being executed in the activity diagram. All of the operations performed in boxes 62-72 are performed in the activity diagram parser 42.

[0012]

[0014] At this point, the tool determines which action is integrated with which subprocess, and the processing schedule notifies the tool of when and for how long each subprocess will operate. Using this information, the tool assigns each subprocess to one of partitions 12 - 18. Next, the tool causes the user to enter additional timing constraints in box 76. This may not be part of one of the subprocesses executed in partitions 12 - 18. Next, in box 78, the tool determines, based on the split schedule, the worst-case, i.e., the longest time, required to complete the first action for one of the possible paths, and stores this time. Once the worst-case time for the first action of that path has been identified, in decision diamond 80, the tool determines whether the next action in that path is to be performed in the same partition as the first action. If so, in box 82, the tool determines, based on the split schedule, the worst-case time required to complete the next action and stores this time. If the tool determines in decision diamond 80 that the next action in that path is not to be performed in the same partition as the first action, the tool determines in box 84 the longest time required to transition from the subprocess executed in the partition where the first action is located to the subprocess executed in the partition where the next action is located, and stores this time. In other words, synchronization of the subprocesses executed in separate partitions 12 - 18 is not taken, and it is possible that the operation of one action may have to wait for the schedule of another partition. Next, in box 82, this partition change or switch time is added to the time required to execute the subsequent action.

[0013]

[0015] Next, at decision diamond 86, the tool determines whether any actions remain for the possible path currently being analyzed. If any remain, the tool returns to decision diamond 80 and determines whether the next action in that path will occur in the same partition as the previous action. The tool processes the loop around decision diamonds 80 and 86 and boxes 82 and 84 until the worst-case timing for all actions, including partition changes, is identified and stored for the currently analyzed path. At decision diamond 86, if no actions remain for the possible path currently being analyzed, the tool then determines at decision diamond 88 whether the worst-case timing for actions has been calculated for all possible paths. If not, the tool returns to box 78 and determines the worst-case time to complete the first action in another path based on the split schedule. The tool processes the loop around decision diamonds 80, 86, and 88 and boxes 78, 82, and 84 until the worst-case timing for all actions, including partition sub-process changes, is identified and stored for all paths. In this example, there are four paths being analyzed. All the operations performed in boxes 74 - 88 are performed in the schedule parser 46.

[0014]

[0016] If the worst-case time to execute all actions in all possible paths has been calculated at decision diamond 88, the tool then aggregates, at box 90, the worst-case execution times for actions and partition switches for each path, reports, at box 92, the worst-case execution time for the slowest path and the worst-case execution time for each path, and the tool ends at box 94. All the operations performed in boxes 90 and 92 are performed in the worst-case time calculator 50.

[0015]

[0017] The above discussion merely discloses and describes exemplary embodiments of the present disclosure. It will be readily recognized by those skilled in the art that various changes, modifications, and variations can be made without departing from the spirit and scope of the present disclosure as defined in the following claims, from such discussion, and from the accompanying drawings and claims.

Claims

A method for determining the timing of a process, executed by a computing system, wherein the process is divided into a plurality of subprocesses, the plurality of subprocesses perform a specific action and operate on their own split schedules independently of other partitions, the method comprising: identifying each action executed by the process; identifying a first action from all of the actions executed by the process; checking all possible paths from the first action to the end of the actions that may be executed by the process; assigning each action in each path to one of the subprocesses in the partition; determining, based on the split schedule, when and for how long each subprocess is attempting to operate; assigning each subprocess to a partition; determining, based on the split schedule, the time taken to complete the first action for one of the paths; determining whether the next action in the one path is performed in the same partition as the first action, and if so, determining the time taken to complete the next action based on the split schedule, and if not, determining the time taken to move from the subprocess executing in the partition having the first action to the subprocess executing in the partition having the next action; continuing to determine whether the next action and the previous action are performed in the same partition until the time taken to execute all of the actions for the one path is determined; determining that no action remains for which the timing is to be determined in the one path; determining whether the time taken to execute all of the actions has been determined for all of the possible paths, and if not, similarly determining, based on the split schedule, the time taken to complete the actions starting from the first action in other paths until the time taken to execute all of the actions for all of the paths is determined; a step of aggregating the time taken to execute the action in each of the paths; A method for determining the timing of a process, including: **Claim 2** The method according to claim 1, wherein the step of determining the time taken to complete the action includes a step of determining the longest time taken to execute the action. **Claim 3** The method according to claim 1, further including a step of reporting the longest time taken to execute the process along each path based on the aggregation of the times. **Claim 4** The method according to claim 1, further including a step of inputting additional timing constraints for the action before determining the time taken to complete the first action. **Claim 5** The method according to claim 1, further including a step of providing a Unified Modeling Language (UML) activity diagram used to identify the action and check all the paths up to the end of the divided sub-process. **Claim 6** The method according to claim 5, wherein the UML activity diagram is written in Extensible Markup Language (XML) format. **Claim 7** The method according to claim 5, wherein the activity diagram and the divided schedule are provided by a user. **Claim 8** A method for determining the timing of a process executed by a computing system, wherein the process is divided into a plurality of sub-processes, the plurality of sub-processes execute a specific action and operate on their own divided schedules independently of other partitions, and the method includes: a step of providing a Unified Modeling Language (UML) activity diagram including actions in the process; a step of identifying each action in the diagram; a step of checking each possible path up to the end of the action that may be executed by the process; a step of assigning each action in each path to one of the sub-processes in the partition; a step of determining the time required for each action to pass through each path based on the divided schedule; a step of aggregating the time taken to execute the action in each of the paths; including. **Claim 9** The method according to claim 8, wherein the step of determining the time required for each action includes the step of determining the longest time required to execute the action, the method.

10. The method according to claim 8, further comprising the step of reporting the longest time to execute the process along each path based on the aggregation of the time, the method.

11. The method according to claim 8, further comprising the step of inputting additional timing constraints for the action before determining the time required for each action, the method.

12. A system for determining the timing of a process, wherein the process is divided into a plurality of subprocesses, the plurality of subprocesses execute a specific action and operate on their own split schedules independently of other partitions, and the system is means for identifying each action to be executed by the process; means for identifying a first action from all of the actions executed by the process; means for checking all possible paths from the first action to the end of the actions that may be executed by the process; means for allocating each action in each path to one of the subprocesses in the partition; means for determining, based on the split schedule, when and for how long each subprocess is attempting to operate; means for allocating each subprocess to a partition; means for determining, based on the split schedule, the time required to complete the first action for one of the paths; means for determining whether the next action in the one path is performed in the same partition as the first action, and if so, determining, based on the split schedule, the time required to complete the next action, and if not, determining the time required to transfer from the subprocess executing in the partition having the first action to the subprocess executing in the partition having the next action; means for continuing to determine whether the next action and the previous action are performed in the same partition until the time required to execute all of the actions for the one path is determined; means for determining that no action whose timing is to be determined remains in the one path; means for determining whether the time required to execute all of the actions has been determined for all of the possible paths, and if not, for determining, in the same manner based on the split schedule, the time required to complete the actions starting from the first action in other paths until the time required to execute all of the actions for all of the paths is determined; means for aggregating the time required to execute the action in each of the paths; A system comprising the above.

13. The system according to claim 12, wherein the means for determining the time required to complete the action determines the longest time required to execute the action.

14. The system according to claim 12, further comprising means for reporting the longest time required to execute the process along each path based on the aggregation of the time.

15. The system according to claim 12, further comprising means for inputting additional timing constraints for the action before determining the time required to complete the first action.

16. The system according to claim 12, further comprising means for providing a Unified Modeling Language (UML) activity diagram used to identify the action and check all of the paths up to the end of the split sub-process.

17. The system according to claim 16, wherein the UML activity diagram is written in an Extensible Markup Language (XML) format.

18. The system according to claim 16, wherein the activity diagram and the split schedule are provided by a user.

Images