Processing load estimation system and processing load estimation method

Abstract

A processing load estimation system comprising: a software component input unit to which is inputted a software component having a plurality of computation elements for realizing a predetermined computation flow, the computation path of the software component differing depending on an input value; a test suite input unit to which is inputted a test suite imparted to the software component; a processing load estimation unit that estimates a processing load per computation path; a simulation unit that simulates the software component on the basis of the test suite and outputs a dynamic feature obtained from a plurality of simulation results; and a result processing unit that processes the dynamic feature outputted from the simulation unit. The result processing unit estimates the practical processing load of the software component on the basis of the dynamic feature, a plurality of computation results that correspond to the input value, and the processing load per computation path.

Description

[Technical Field]

[0001] The present invention relates to a processing load estimation system for software components, and more particularly to a processing load estimation system that can accurately estimate processing loads even in performance evaluation of the entire system in embedded software development. [Background technology]

[0002] The embedded software implemented in vehicle control devices in recent years has become increasingly diverse and complex, and the amount of work required to design and verify the embedded software continues to increase.One method to address this is model-based embedded software development technology, which uses models for simulation design and verification.

[0003] A typical model-based development method is to use modeling tools such as Simulink. This method allows you to design a model that meets control specifications by combining basic operation blocks and function blocks, and to verify it through simulation, which enables more efficient design and development than when modeling tools are not used.

[0004] Vehicle control devices are subject to strict constraints on CPU resources, ROM / RAM capacity, and other factors, and designs must take resource constraints into account. Particularly in the field of vehicle electric control, the demand for high processing speeds has led to a shortage of CPU resources, and models that have passed functional verification in upstream processes are sometimes found to be unable to satisfy CPU resource constraints at the implementation stage, resulting in increased development man-hours due to the need to remake the model or take additional measures to reduce processing load. Therefore, for example, Patent Document 1 discloses a simulation device that not only predicts the processing load for each execution path from trace information obtained by inputting scenario data into an evaluation target system consisting of multiple functional models, but also performs performance simulations according to the scheduling algorithm of the selected OS, thereby accurately estimating the processing load when multiple processes are executed simultaneously.。

[0005] Furthermore, Patent Document 2 discloses a model-based performance prediction system that predicts the CPU processing load of the entire model at an upstream design stage from the processing time of the operation blocks that are components of the model and the number of CPU execution cycles, while taking into account delays that occur when multiple processes are started simultaneously. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Laid-Open No. 2009-258831 [Patent Document 2] Japanese Patent Application Laid-Open No. 2011-154521 Summary of the Invention [Problem to be solved by the invention]

[0007] In the invention of Patent Document 1, scenario data is input to an evaluation system having multiple function models, and the processing time is evaluated for each sequence executed in the scenario. However, this sequence does not refer to the calculation path within the model, but rather to the execution order of the function models scheduled by the OS, and since the processing time of each function model is a fixed value, it is not possible to accurately estimate the processing time of each function model.

[0008] On the other hand, in the invention of Patent Document 2, the processing time for each basic operation block, which is a component of the model, is stored in advance and the processing time for the model is predicted. By using this method, even if there are multiple operation paths in the model due to branching processing, it is possible to predict the processing time for each path. For example, it is possible to predict the maximum processing time from the path with the largest cumulative value of the processing time of the operation blocks. However, this method cannot accurately predict the average processing time when implemented and operated in a vehicle control device.

[0009] Furthermore, to predict whether the control system implemented on each CPU core will experience a processing load breakdown, it is necessary to predict the maximum processing time of all models placed on each CPU core. One possible method for predicting this maximum processing time for all models is to accumulate the theoretical maximum processing times of each model according to the results of scheduling by the OS. However, when the processing time of all models implemented on each CPU core reaches its maximum, the calculation path that results in the maximum processing time for each model is not necessarily executed. Therefore, if the accumulation of the maximum processing times of each model is used as the overall maximum processing time, the predicted maximum processing time will be greater than the actual time.

[0010] Furthermore, in recent years, tools for verifying the timing and scheduling of embedded multi-core real-time systems have begun to be introduced. These tools can verify the timing and scheduling of the entire system by inputting OS design information, such as scheduling information, periodic task information, and interrupt task information, as well as the processing time of each model to be scheduled. Therefore, when estimating processing time, there is little need to incorporate the OS scheduling function, which is a feature of Patent Documents 1 and 2. Instead, it is becoming more important to accurately determine the processing load of each individual model.

[0011] The present invention has been made in consideration of the above-mentioned problems, and provides a practical and highly accurate processing load estimation system that improves the accuracy of processing times estimated from individual software components, while also enabling performance evaluation of the entire system. 。 [Means for solving the problem]

[0012] A representative example of the invention disclosed in this application to solve the above-mentioned problems is as follows: That is, a processing load estimation system includes an arithmetic unit that executes a predetermined process and a storage device accessible by the arithmetic unit, the arithmetic unit including a software component input unit to which a software component having a plurality of arithmetic elements that realize a predetermined arithmetic flow and whose arithmetic path varies depending on an input value is input, a test suite input unit to which a test suite to be applied to the software component is input, a processing load estimation unit configured to estimate a processing load for each of the arithmetic paths, a simulation unit configured to simulate the software component based on the test suite and output dynamic features obtained from multiple simulation results, and a result processing unit configured to process the dynamic features output from the simulation unit, the result processing unit configured to estimate a practical processing load of the software component based on the dynamic features, multiple arithmetic results corresponding to the input values, and the processing load for each of the paths. [Effects of the Invention]

[0013] According to one aspect of the present invention, it is possible to estimate processing load performance with high accuracy. Problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0014] [Figure 1] 1 is a system configuration diagram of a processing load estimation system according to a first embodiment. [Figure 2] FIG. 2 is a model diagram showing a control model according to the first embodiment. [Figure 3] FIG. 3 is a diagram showing a calculation path of a control model according to the first embodiment. [Figure 4] FIG. 3 is a diagram illustrating an example of a cost database according to the first embodiment. [Figure 5] FIG. 4 is a diagram showing accumulated costs for each calculation route according to the first embodiment. [Figure 6]FIG. 2 is a diagram illustrating a test suite according to the first embodiment. [Figure 7] FIG. 4 is a diagram showing simulation result information according to the first embodiment. [Figure 8] 10 is a flowchart of a process executed by a result processing unit according to the first embodiment. [Figure 9] FIG. 10 is a diagram showing an example of a calculation result of a deviation according to the first embodiment. [Figure 10] FIG. 10 is a diagram showing a practical processing time according to the first embodiment. [Figure 11A] 10 is a flowchart of a program according to a second embodiment. [Figure 11B] FIG. 10 is a diagram illustrating an example of a calculation path of a program according to the second embodiment. [Figure 12] FIG. 10 is a diagram illustrating an example of a cost database according to the second embodiment. [Figure 13] 11 is a flowchart of a process executed by a result processing unit according to the third embodiment. [Figure 14] 13 is a flowchart of a process executed by a result processing unit according to the fourth embodiment. [Figure 15] FIG. 13 is a diagram illustrating an example of a passing rate according to the fourth embodiment. [Figure 16] FIG. 10 is a system configuration diagram of a processing load estimation system according to a fifth embodiment. [Figure 17] FIG. 13 is a diagram illustrating an example of a cost database according to the fifth embodiment. [Figure 18] FIG. 13 is a system configuration diagram of a processing load estimation system according to a seventh embodiment. [Figure 19] FIG. 13 is a data flow diagram of a control model according to the seventh embodiment. [Figure 20] FIG. 20 is a diagram illustrating an example of a cost database according to the seventh embodiment. [Figure 21] 13 is a flowchart of a process executed by a route cost evaluation unit according to the seventh embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, first to seventh embodiments of the present invention will be described with reference to the drawings. In each drawing, the same reference numerals indicate the same parts.

[0016] (First embodiment) FIG. 1 is a system configuration diagram of a software component processing load estimation system 1 according to a first embodiment of the present invention.

[0017] The processing load estimation system 1 for a software component is composed of a software component input unit 102, a test suite input unit 104, a simulation unit 105, a processing load estimation unit 106, and a result processing unit 107. The software component input unit 102 receives an input of a software component 100. The test suite input unit 104 receives an input of a test suite 103. The simulation unit 105 performs a simulation using the software component 100 input to the software component input unit 102 and the test suite 103 input to the test suite input unit 104. The processing load estimation unit 106 estimates the processing load of the software component. The result processing unit 107 estimates a practical and highly accurate processing load of the software component 100 based on the simulation result by the simulation unit 105 and the estimation result by the processing load estimation unit 106. The software component 100 is, for example, a control model 101 or a program 201.

[0018] In the first embodiment, a case where the software component 100 is a control model 101 will be described.

[0019] The processing load estimation unit 106 in this embodiment estimates the processing time of each calculation path. The processing load estimation unit 106 has a cost storage unit 108 that stores the cost related to the processing load of each calculation block that constitutes the control model 101, and a path cost evaluation unit 109 that accumulates the costs of the calculation blocks for each path while referring to the cost storage unit 108, and estimates the processing time of each calculation path of the control model 101.

[0020] In the embodiment of the present invention, a specific example of the processing load estimation unit 106 will be described in which the processing load estimation unit 106 includes the cost storage unit 108 and the path cost evaluation unit 109, but other methods may also be employed. For example, a method in which the processing time for each path is stored in advance may also be used.

[0021] The processing load estimation system 1 according to the first embodiment is configured by a computer having a processor (CPU), a memory, an auxiliary storage device, and a communication interface. The processing load estimation system 1 may also have an input interface and an output interface.

[0022] The processor is a computing device that executes programs stored in a memory. The processor executes various programs to realize the functions of the functional units (e.g., software component input unit 102, test suite input unit 104, simulation unit 105, processing load estimation unit 106, result processing unit 107, etc.) of the processing load estimation system 1. Note that some of the processing performed by the processor executing the programs may be executed by other computing devices (e.g., hardware such as ASIC and FPGA).

[0023] Memory includes ROM, which is a non-volatile storage element, and RAM, which is a volatile storage element. ROM stores unchanging programs (e.g., BIOS). RAM is a high-speed, volatile storage element such as DRAM (Dynamic Random Access Memory). Processor The program to be executed and data to be used when the program is executed (for example, the cost storage unit 108) are temporarily stored.

[0024] The auxiliary storage device is, for example, a large-capacity, non-volatile storage device such as a magnetic storage device (HDD) or a flash memory (SSD). The auxiliary storage device also stores data used by the processor when executing a program (for example, a file recording cost data expanded in RAM as the cost storage unit 108), and the program executed by the processor. That is, the program is read from the auxiliary storage device, loaded into memory, and executed by the processor to realize each function of the processing load estimation system 1.

[0025] The communication interface is a network interface device that controls communication with other devices according to a predetermined protocol.

[0026] The input interface is an interface that receives input from a user, such as a keyboard or mouse. For example, the input interface receives input of a file in which cost data is recorded and stored in an auxiliary storage device. The input interface may also provide a GUI and receive input of cost data from a user.

[0027] The output interface is an interface, such as a display device or printer, that outputs the execution results of a program in a format that can be viewed by the user. For example, in the processing load estimation system 1 according to the first embodiment, the output interface outputs data for displaying the amount of calculation and processing cost output by the result processing unit 107. The output interface may also be a data output port that outputs the execution results of a program in a format that can be viewed by the user. For example, the output interface outputs a report in a predetermined data format (e.g., PDF, HTML) that displays the amount of calculation and processing cost output by the result processing unit 107.

[0028] Note that a terminal connected to the processing load estimation system 1 via a network may provide the input interface and the output interface.

[0029] The programs executed by the processor are provided to the processing load estimation system 1 from removable media (CD-ROM, flash memory, etc.) or via a network, and are stored in a non-volatile auxiliary storage device, which is a non-transitory storage medium. For this reason, the processing load estimation system 1 preferably has an interface for reading data from removable media.

[0030] The processing load estimation system 1 is a computer system configured on one physical computer or on multiple logically or physically configured computers, and may operate on a virtual computer constructed on multiple physical computer resources. For example, the processing load estimation system 1 includes a software component input unit 102, a test suite input unit 104, a simulation unit 105, a processing load estimation unit 106, and a result processing unit. 107 Each of the components may operate on a separate physical or logical computer, or a plurality of components may be combined and operate on a single physical or logical computer.

[0031] FIG. 2 is a model diagram showing the control model 101 according to this embodiment.

[0032] The control model 101 is composed of input ports 10101, 10102, 10103, 10104, a gain block 10105 that amplifies input values, an addition block 10106 that adds input values, a multiplication block 10107 that multiplies input values, constant blocks 10108, 10109, 10110 that output fixed values, a constant block 10111 that outputs parameter values, a one-dimensional table search block 10112 that performs a one-dimensional table search and outputs the corresponding result, a comparison operation block (comparison) 10113 that performs a comparison operation on input values, a comparison operation block (equivalent) 10114 that determines whether the input values ​​are equivalent, switch blocks 10115, 10116 that output the first input if the second input value is TRUE and the third input if the second input value is FALSE, and an output port 10117.

[0033] FIG. 3 is a diagram showing the calculation path of the control model 101 according to this embodiment.

[0034] The control model 101 has three main calculation paths MR1, MR2, and MR3 and two sub-calculation paths SR1 and SR2. The calculation paths executed in the control model 101 differ depending on the input values ​​of the control model's input ports 10101, 10102, 10103, and 10104 and the parameter value of the constant block 10111. The main calculation path MR1 is a path that is executed when the result of the sub-calculation path SR1 is TRUE and the result of the sub-calculation path SR2 is TRUE. The main calculation path MR2 is a path that is executed when the sub-calculation path SR1 is FALSE and the sub-calculation path SR2 is TRUE. The main calculation path MR3 is a path that is executed when the sub-calculation path SR2 is FALSE, regardless of the result of the sub-calculation path SR1.

[0035] The parameters set in the constant block 10111 used in this embodiment are adjustable parameters, such as calibration parameters and configuration parameters. The values ​​of both can be changed after implementation as a program. Calibration parameters are adjustable parameters intended to improve the control performance of the control model 101, and in the case of an on-board electronic control unit, for example, they are calibrated to appropriate values ​​through vehicle driving tests. On the other hand, configuration parameters are parameters that are changed when the vehicle is shipped from the factory depending on, for example, the destination, vehicle specifications, vehicle accessories, etc.

[0036] FIG. 4 is a diagram showing an example of a cost database included in the cost storage unit 108 according to this embodiment, and shows an example of a cost database in which the computation load cost for each processing block is recorded.

[0037] The cost storage unit 108 pre-stores a cost C1 of the gain block 10105, a cost C2 of the addition block 10106, a cost C3 of the multiplication block 10107, a cost C4 of the one-dimensional table lookup block 10112, a cost C5 of the comparison operation block (comparison) 10113, a cost C6 of the comparison operation block (equivalent) 10114, and a cost C7 of the switch blocks 10115 and 10116. The cost storage unit 108 is referenced by the path cost evaluation unit 109. In this embodiment, the input ports 10101, 10102, 10103, and 10104, the constant blocks 10108, 10109, 10110, and 10111, and the output port 10117 do not involve arithmetic operations such as arithmetic or logical operations, and therefore no costs are defined for these.

[0038] The cost associated with the processing load may be, for example, the processing time measured in advance by implementing each operation block as a program using a microcomputer simulator or an actual microcomputer. With this method, once the processing time of all operation blocks is measured and a database is constructed, the processing load can be easily estimated. However, because the processing time varies depending on the control device in which the program is implemented and the clock frequency, there is a problem in that the processing load must be remeasured each time the control device is changed.

[0039] RISC microcontrollers, which are commonly used in automotive electronic control units, generally perform all operations in one clock cycle and execute programs using only the minimum number of simple instructions. Furthermore, the instruction set of RISC microcontrollers is relatively consistent for low-level operations such as addition / subtraction, logical operations, comparison operations, and multiplication. However, processing time varies significantly depending on the microcontroller's clock frequency. Therefore, to enable use in as many microcontroller environments as possible and to easily estimate processing loads without remeasurement even when the microcontroller's clock frequency changes, clock cycles can be used as the cost of each processing block. Because the execution time of one clock cycle is determined by the microcontroller's clock frequency, processing time can be easily estimated from the clock cycles, even when the microcontroller's clock frequency changes.

[0040] Next, the processing load estimation unit 106 in this embodiment will be described in detail. The path cost evaluation unit 109 analyzes the control model 101 input via the software component input unit 102, and extracts three main computation paths MR1, MR2, and MR3 shown in Fig. 3, and two sub-computation paths SR1 and SR2 that determine which main computation path will be executed. Thereafter, the cost of each computation path is accumulated while referring to costs C1, C2, C3, C4, C5, C6, and C7 stored in advance in the cost storage unit 108 shown in Fig. 4, and the processing times of the three main computation paths MR1, MR2, and MR3 are estimated.

[0041] FIG. 5 is a diagram showing the cumulative costs corresponding to the estimated processing times of the main computation paths MR1, MR2, and MR3.

[0042] The main computation path MR1 is executed when the sub-computation path SR1 is TRUE and the sub-computation path SR2 is TRUE. Therefore, the cumulative cost C MR1 is determined by the sum of the accumulated costs of the operation blocks arranged on the main operation path MR1 and the accumulated costs of the operation blocks arranged on the sub operation paths SR1 and SR2. Specifically, it is determined by the cost C1 of the gain block 10105, which is an operation block on the main operation path MR1, the cost C7 of the switch blocks 10115 and 10116, and the cost C of the sub operation path SR1. SR1 and the cost C of the sub-operation path SR2 SR2 Accumulate all the accumulated costs C MR1 is C1+C7+C7+C SR1 +C SR2 The cost of the sub-operation path SR1 is calculated as follows: SR1 is the cost C5 of the comparison operation (comparison) block 10113, which is an operation block arranged in the sub-operation path SR1. do.

[0043] Cost of sub-operation path SR2 C SR2is the cost C6 of the comparison operation (equivalent) 10114, which is an operation block arranged in the sub operation path SR2. Therefore, the cumulative cost C of all operation blocks executed when the main operation path MR1 is selected MR1 is calculated by C1+C7+C7+C5+C6. In the same way, the cumulative cost C of all the operation blocks executed when the main operation route MR2 is selected is calculated by C MR2 is calculated by C2+C7+C7+C5+C6.

[0044] The main computation path MR3 is executed when the sub-computation path SR2 is FALSE, regardless of the execution result of the sub-computation path SR1. Therefore, in this embodiment, the cost of SR1 is not accumulated, and the accumulated cost C of MR3 is the sum of the accumulated costs of the computation blocks arranged on the main computation path MR3 and the sub-computation path SR2. MR3 Specifically, the cost C3 of the multiplication block 10107, which is an operation block of the main operation route MR3, the cost C4 of the one-dimensional table lookup block 10112, the cost C7 of the switch block 10115, and the cost C of the sub operation route SR2 are calculated. C SR2 , that is, by accumulating all of C6, the cumulative cost C MR3 Therefore, the accumulated cost of the operation blocks executed when the main operation route MR3 is executed is calculated by C3+C4+C7+C6.

[0045] Furthermore, the cumulative costs of the main calculation routes MR1, MR2, and MR3 are compared, and the route with the highest cumulative cost is the route that results in the theoretical maximum processing time of the control model 101. Similarly, the route with the lowest cumulative cost is the theoretical minimum processing time of the control model 101.

[0046] However, the maximum and minimum processing times estimated by the processing load estimation unit 106 do not necessarily represent routes that will be executed in an actual use case, such as an actual vehicle run. Because the inputs of the model to be estimated are determined by preprocessing of the model, inputs for executing the corresponding routes are not necessarily generated, and these routes may not be executed. Alternatively, the corresponding routes may be unreachable regardless of the input data, or may not be executed depending on adjustable parameters. For these reasons, the maximum and minimum processing times calculated using the above-described method are not maximum and minimum processing times within a practical range, making it difficult to estimate practical processing times. Furthermore, when estimating the maximum processing time of the entire system, accumulating the theoretical maximum processing times of individual models may result in an excessively long maximum processing time.

[0047] Therefore, the result processing unit 107 solves these problems by using a plurality of new calculation results obtained from the simulation unit 105 based on the results of the route cost evaluation unit 109.

[0048] 6 is a collection of multiple test cases, and is input data input to the control model 101. Input data is generally classified into two types: signals and parameters. Specifically, input signal 1, input signal 2, input signal 3, and input signal 4 of the test suite 103 are input to input ports 10101, 10102, 10103, and 10104 of the control model 101, respectively. Parameter 1 of the test suite 103 is a parameter value output by a constant block 10111 of the control model 101.

[0049] The simulation unit 105 inputs the test suite 103 into the input control model 101 and performs a simulation. Fig. 7 shows the simulation results output by the simulation unit 105. The simulation results include not only the output data for each time step output from the output port 10117, but also information on which calculation path was executed.

[0050] The result processing unit 107 analyzes the simulation results (FIG. 7) output by the simulation unit 105 and calculates multiple calculation results. Furthermore, the result processing unit 107 combines the estimated processing time for each calculation path estimated by the processing load estimation unit 106 with the multiple calculation results calculated by the simulation unit 105 to determine a final estimated processing time.

[0051] In this embodiment, a more practical processing load is estimated using dynamic features, which are values ​​relating to a plurality of computational loads obtained through analysis by the result processing unit 107. As values ​​relating to the computational loads used by the result processing unit 107, it is preferable to use the average value or standard deviation of the computational loads.

[0052] FIG. 8 is a flowchart of the processing executed by the result processing unit 107 according to the first embodiment of the present invention when estimating a practical maximum processing load.

[0053] As shown in the flowchart, the result processing unit 107 starts processing from step S107101.

[0054] In step S107102, the result processing unit 107 acquires the simulation result (FIG. 7) from the simulation unit 105.

[0055] In step S107103, the result processing unit 107 acquires the cumulative cost for each computation path (FIG. 5) from the processing load estimating unit .

[0056] In step S107104, the result processing unit 107 calculates the average cumulative cost of the test suite based on the computation path information for each time step acquired from the simulation result (FIG. 7) and the cumulative cost for each computation path (FIG. 5).

[0057] In step S107105, the result processing unit 107 calculates the dispersion (deviation) of the accumulated cost using the accumulated cost of each time step and the average accumulated cost, and then calculates the standard deviation.

[0058] In step S107106, the result processing unit 107 estimates the maximum cumulative cost that is likely to occur in the actual use case by multiplying the standard deviation by a coefficient and adding the result to the average value.

[0059] In step S107107, the result processing unit 107 extracts the largest accumulated cost from the accumulated costs for each computation path (FIG. 5).

[0060] In step S107108, the result processing unit 107 determines whether the maximum cumulative cost that is likely to be taken in the actual use case exceeds the maximum cumulative cost on the calculation path, and if the calculated maximum cumulative cost is smaller than the maximum cumulative cost on the calculation path (NO), proceeds to step S107109, and if the calculated maximum cumulative cost exceeds the maximum cumulative cost on the calculation path (YES), proceeds to step S107110.

[0061] In step S107109, the result processing unit 107 estimates the maximum cumulative cost calculated using the standard deviation as the maximum processing time and outputs it.

[0062] In step S107110, the result processing unit 107 estimates the maximum cumulative cost on the route as the maximum processing time and outputs it.

[0063] In step S107111, the result processing unit 107 ends the process.

[0064] The method for calculating the average cumulative cost Cμ of the test suite in step S107104 will be described below: The average cumulative cost Cμ is calculated by adding up all the cumulative costs of each time step included in the test suite and dividing by the total number n.

[0065]

number

[0066] Next, we will explain how to calculate the standard deviation σ in step S107105. To find the standard deviation, first find the deviation d. The deviation d can be found by subtracting the average cumulative cost Cμ from each cumulative cost Ci of the test suite. An example of the calculation result of the deviation d is shown in Figure 9. The standard deviation can be found by squaring the deviation d and dividing the result by the total number of data n, and then taking the square root of that value.

[0067]

number

[0068] Standard deviation is a statistical index that shows the degree of dispersion, and the standard deviation σ can be used to determine the dispersion of a value relative to the average. When the dispersion is large, the standard deviation σ becomes large, and when the dispersion is small, the standard deviation σ becomes small. Generally, there is a 68.3% probability that the observed data falls within the mean ± σ, a 95% probability that the observed data falls within the mean ± 2σ, and a 99.7% probability that the observed data falls within the mean ± 3σ.

[0069] Next, a method for determining a practical maximum processing load in steps S107108, S107109, and S107110 will be described in detail. max is calculated using the average cumulative cost Cμ, standard deviation σ, and adjustable coefficient k using the following formula. At this time, k is an adjustable parameter coefficient, and can be adjusted to any value by the user depending on the characteristics of the system and the maturity of the test suite. However, the maximum cumulative cost C on the route extracted in step S107107 max is the theoretical maximum cumulative cost, so the result calculated using the standard deviation is C max The maximum cumulative cost calculated using the standard deviation must not exceed the theoretical maximum cumulative cost C max If it exceeds the practical maximum processing load of the PC max C max Let's say.

[0070]

number

[0071] The processing load estimation system taking variability into account according to the first embodiment can calculate a practical maximum processing time by taking variability, which is a dynamic characteristic in an area such as that shown in Fig. 10, into account. Note that although the present embodiment has described a system for estimating a practical maximum processing time, a similar method can also be used to calculate a practical minimum processing time.

[0072] According to this embodiment, not only can it eliminate paths that are not executed in actual use cases, but it can also predict the maximum processing time within the range of actual operation from a statistical perspective by using the standard deviation, even if the coverage rate of actual use cases in the input test suite is low. This makes it possible to mitigate the problem of excessive prediction results, which was a conventional issue when predicting the maximum processing time of the entire system by accumulating the theoretical maximum processing times of each model.

[0073] In this embodiment, the description has focused on the case where the processing time estimated using the standard deviation is output, but the average cumulative cost calculated in step S107104 of the flowchart in Figure 8 may also be estimated as the average processing time.

[0074] Furthermore, if the test suite has a high coverage of actual use cases, the maximum and minimum processing times in the test suite in Figure 10 may be estimated as practical maximum and minimum processing times without using the standard deviation.

[0075] (Second embodiment) In the second embodiment, when the software component 100 is a program 201, it will be described that a practical processing load can be estimated not only for the control model 101 but also for the program 201. In the second embodiment, differences from the first embodiment will be mainly described, and descriptions of the same configurations and processes as in the first embodiment will be omitted.

[0076] FIG. 11A is a flowchart of the program 201 according to this embodiment, and FIG. 11B is a diagram showing an example of the calculation path of the program 201 according to this embodiment.

[0077] As shown in the flowchart, the program 201 starts processing from step S20101.

[0078] In step S20102, the program 201 determines whether condition 1 is met, and if condition 1 is met (YES), the program proceeds to step S20103, and if condition 1 is not met (NO), the program proceeds to step S20104.

[0079] In step S20103, the program 201 executes command 1, and then proceeds to step S20104.

[0080] Steps S In 20104, the program 201 determines whether condition 2 is met. If condition 2 is met (YES), step S Proceed to 20105. If condition 2 is not met (NO), S Go to 20106.

[0081] In step S20105, the program 201 executes the instruction 2.

[0082] In step S20106, the program 201 executes instruction 3.

[0083] In step S20107, the program 201 ends the process.

[0084] 11B, the program 201 has four calculation paths: calculation path R1 in which branches 1 and 3 are executed, calculation path R2 in which branches 1 and 4 are executed, calculation path R3 in which branches 2 and 3 are executed, and calculation path R4 in which branches 2 and 4 are executed. Therefore, the program 201 has multiple calculation paths, and can be treated similarly to the control model 101 in that the results of condition determination change depending on the input and the paths to be executed differ.

[0085] FIG. 12 is a diagram showing an example of a cost database included in the cost storage unit 108 according to this embodiment, and shows an example of a cost database in which the computation load cost for each CPU computation element is recorded.

[0086] While the cost storage unit 108 according to the first embodiment stores a cost for each operation block, the cost storage unit 108 according to the present embodiment stores, as a cost, the processing load for each operation element of the CPU that constitutes the program 201. For example, the user can define the cost as desired, such as C23 for addition (ADD) and C25 for multiplication (MUL).

[0087] The cost storage unit 108 for the program 201 according to this embodiment stores costs corresponding to the operation elements of the CPU, but may store costs for each operator such as the four arithmetic operations, for example.

[0088] Next, a detailed description will be given of the operation of the path cost evaluation unit 109 when the program 201 is input. In the first embodiment, the cost of the blocks for each path is accumulated, but in this embodiment, the cost of the CPU operation elements for each operation path is accumulated.

[0089] The path cost evaluation unit 109 may, for example, analyze the syntax of the program 201 to extract the CPU operation elements of each operation path, or may compile the program and convert it to an assembler level to extract the CPU operation elements.

[0090] As described above, estimating the processing load from the program 201 allows the processing load to be estimated using calculation elements that are closer to actual operations, and thus allows for more accurate estimation of the processing load than estimating the processing load from the control model 101. On the other hand, since the processing load cannot be estimated until the program 201 is designed, there is a concern that a large amount of rework will occur compared to the method using the control model 101.

[0091] According to this embodiment, it has been explained that a practical processing load can be estimated not only for the control model 101 but also for the program 201 in the same way.

[0092] (Third embodiment) In the third embodiment, a more practical processing load is estimated by utilizing the passage information of each calculation path, which is a dynamic feature, as one of the multiple calculation results obtained by analysis in the result processing unit 107. Specifically, the result processing unit 107 identifies calculation paths that are not executed based on the passage information, and excludes the calculation paths that are not executed from the estimation target, thereby estimating a more practical processing time. Note that the third embodiment will mainly describe the differences from the previously described embodiments, and descriptions of the same configurations and processes as the previously described embodiments will be omitted. Furthermore, the software component 100 may be either the control model 101 or the program 201, but the third embodiment will be described using the control model 101 as an example.

[0093] FIG. 13 is a flowchart of the processing executed by the result processing unit 107 according to this embodiment.

[0094] As shown in the flowchart, the result processing unit 107 starts processing from step S107201.

[0095] In step S107202, the result processing unit 107 acquires the simulation result (FIG. 7) from the simulation unit 105.

[0096] In step S107203, the result processing unit 107 acquires the cumulative cost for each computation path (FIG. 5) from the processing load estimating unit .

[0097] In step S107204, the result processing unit 107 analyzes the results of the simulation by the simulation unit 105 and identifies computation paths that have not been executed.

[0098] In step S107205, the result processing unit 107 determines whether or not there is an operation path that will not be executed. If there is an operation path that will not be executed (YES), the process proceeds to step S107206; if there is no operation path that will not be executed (NO), the process proceeds to step S107207.

[0099] In step S107206, the result processing unit 107 estimates the processing time using the accumulated costs of the operation paths obtained from the simulation unit 105, excluding the accumulated costs of operation paths that are not executed.

[0100] In step S107207, the result processing unit 107 directly uses the accumulated cost of each computation path obtained from the simulation unit 105 to estimate the processing time.

[0101] In step S107208, the result processing unit 107 ends the process.

[0102] For example, the largest accumulated cost excluding the computation paths that are not executed may be estimated as the maximum processing time. Alternatively, the smallest accumulated cost excluding the computation paths that are not executed may be estimated as the minimum processing time. Alternatively, the average value of the accumulated costs excluding the computation paths that are not executed may be calculated and estimated as the average processing load.

[0103] According to this embodiment, it is possible to exclude paths that are not executed in actual use cases, and estimate processing times more practically and with higher accuracy.

[0104] (Fourth embodiment) In the fourth embodiment, a more practical processing load is estimated by utilizing a pass rate, which represents the pass frequency of each calculation path as a dynamic feature, as one of the multiple calculation results obtained by analysis in the result processing unit 107. Specifically, a system will be described in which the result processing unit 107 estimates a more practical processing time by excluding from the estimation target any pass rate that is smaller than a predetermined threshold. Note that the fourth embodiment will mainly describe the differences from the previously described embodiments, and will omit descriptions of the same configurations and processes as the previously described embodiments. Furthermore, the software component 100 may be either the control model 101 or the program 201, but the fourth embodiment will be described using the control model 101 as an example.

[0105] FIG. 14 is a flowchart of the processing executed by the result processing unit 107 according to this embodiment.

[0106] As shown in the flowchart, the result processing unit 107 starts processing from step S107301.

[0107] In step S107302, the result processing unit 107 acquires the simulation result (FIG. 7) from the simulation unit 105.

[0108] In step S107303, the result processing unit 107 acquires the cumulative cost for each computation path (FIG. 5) from the processing load estimating unit .

[0109] In step S107304, the result processing unit 107 analyzes the results of the simulation by the simulation unit 105 and calculates the passing rate of each calculation path.

[0110] In step S107305, the result processing unit 107 compares the pass rate of each calculation path with a threshold preset by the user, and determines whether there is a calculation path with a small pass rate.If there is a calculation path with a small pass rate (YES), the process proceeds to step S107306; if there is no calculation path with a small pass rate (NO), the process proceeds to step S107307.

[0111] In step S107306, the result processing unit 107 estimates the processing time using the accumulated costs of the operation paths excluding operation paths with small passing rates.

[0112] In step S107307, the result processing unit 107 estimates the processing time using the accumulated costs of all the operation paths.

[0113] In step S107308, the result processing unit 107 ends the process.

[0114] FIG. 15 is a diagram showing an example of the passing rate in the case of the control model 101. In FIG.

[0115] If the pass rates of the calculation paths MR1, MR2, and MR3 of the control model 101 are 39.9999%, 60.0%, and 0.0001%, respectively, and the pass rate threshold is 0.001% in step S107305, the pass rate of the calculation path MR3 is below the threshold, so the cumulative cost of the calculation path MR3 is excluded, and the processing load is estimated using the cumulative costs of MR1 and MR2.

[0116] For example, the largest accumulated cost among the accumulated costs excluding calculation paths with a pass rate smaller than a threshold may be estimated as the maximum processing time. Alternatively, the smallest accumulated cost among the accumulated costs excluding calculation paths with a pass rate smaller than a threshold may be estimated as the minimum processing time. Furthermore, the average value of the accumulated costs excluding calculation paths with a pass rate smaller than a threshold may be calculated and estimated as the average processing load.

[0117] At the timings when the processing time of the entire system is maximum or minimum, the possibility that a computation path with a low execution frequency among the software components is executed is extremely small. According to this embodiment, by excluding computation paths with a low execution frequency that may be executed in an actual use case, the above-mentioned problem can be solved and the accuracy of estimating the maximum processing load and minimum processing load of the entire system can be improved.

[0118] (Fifth embodiment) In the fifth embodiment, a system will be described in which a processing load estimation unit 106 estimates a processing load by taking into account latency, which is a communication delay time for memory access. Note that in the fifth embodiment, differences from the previously described embodiments will be mainly described, and descriptions of the same configurations and processes as the previously described embodiments will be omitted. Furthermore, the software component 100 may be either a control model 101 or a program 201, but in the fifth embodiment, the control model 101 will be described as an example.

[0119] 16 is a system configuration diagram of a software component processing load estimation system 1 according to a fifth embodiment of the present invention. The difference from the system configuration diagram of the first embodiment (FIG. 1) is that a memory analysis unit 501 is added to the processing load estimation unit 106.

[0120] The memory analysis unit 501 extracts, as memory attributes, operation elements related to memory access of the software component 100, and sends them to the path cost evaluation unit 109. The path cost evaluation unit 109 acquires the extraction results of the memory analysis unit 501, reads out the pre-stored memory access latency costs from the cost storage unit 108, and accumulates the latency costs together with the accumulated costs of each operation path.

[0121] 2, input ports 10101, 10102, 10103, and 10104 of control model 101 are input interfaces of control model 101, and output port 10117 is an output interface of control model 101. For example, when designing a program with input / output interfaces as global variable access, a cost equivalent to the latency of the read process of the global variable is assigned to input ports 10101, 10102, 10103, and 10104, and a cost equivalent to the latency of the write process of the global variable is assigned to output port 10117.

[0122] 2 reads the parameter values ​​from the control model 101. In this embodiment, a cost corresponding to the latency of reading the calibration parameters from the memory area is assigned to the constant block 10111.

[0123] FIG. 17 is a diagram showing an example of a cost database included in the cost storage unit 108 according to this embodiment, and shows an example of a cost database in which the calculation load cost for each memory calculation block is recorded.

[0124] The path cost evaluation unit 109 detects blocks that meet the application conditions predetermined by the user as memory operation blocks, and accumulates the costs of the operation blocks, including the cost of the memory operation blocks, to calculate the accumulated cost for each operation path. For example, the main operation path MR1 is added with a cost corresponding to the latency of reading the global variable of the input port 10101, reading the parameter of the constant block 10111, and writing the global variable of the output port 10117. Therefore, the accumulated cost C of all operation blocks and memory operation blocks executed when the main operation path MR1 is selected is MR1 is calculated by C51+C1+C7+C7+C5+C53+C6+C52. Similarly, the cumulative cost C of all the operation blocks and memory operation blocks executed when the main operation path MR2 is selected is calculated by C51+C1+C7+C7+C5+C53+C6+C52. MR2 is calculated by C51+C51+C2+C7+C7+C5+C53+C6+C52. In addition, the cumulative cost C of all the operation blocks and memory operation blocks executed when the main operation route MR3 is selected is MR3 is calculated by C51+C3+C4+C7+C53+C6+C52.

[0125] According to this embodiment, by taking into consideration not only the processing time involved in the calculation but also the latency of memory access, the processing time can be estimated with higher accuracy.

[0126] (Sixth embodiment) In the sixth embodiment, a system will be described in which, when a processing load estimation unit 106 detects a combination of specific blocks stored in advance, the processing load is estimated by correcting the original cost to a cost (a cost associated with the combination of specific blocks) different from the original cost. Note that the sixth embodiment will mainly describe the differences from the previously described embodiments, and descriptions of the same configurations and processes as the previously described embodiments will be omitted. Furthermore, the software component 100 may be either the control model 101 or the program 201, but the sixth embodiment will be described using the control model 101 as an example.

[0127] 3, the comparison operation block (equivalent) 10114 determines whether the parameter is 1 and inputs the logical value of the determination result to the switch block 10116. The switch block then determines the input logical value and selects a path according to the logical value. At this time, processing occurs in both the comparison operation block (equivalent) 10114 and the switch block 10116, and the respective costs are accumulated.

[0128] However, in an actual program, the comparison operation process by the comparison operation block (equivalent) 10114 is omitted, and the program is generally designed so that, during the processing of the switch block 10116, specifically, whether a parameter is TRUE or FALSE is directly determined by the conditional expression of an if statement. Therefore, in order to take into account optimization that occurs in the process of converting such a model into a program, for example, when modeling is performed in the flow from the comparison operation block to the switch block, the path cost evaluation unit 109 does not simply refer to and accumulate the cost of the comparison operation block 10114 and the cost of the switch block 10116, but refers to a new cost. In addition, the cost storage unit 108 stores in advance the cost of the combination of the comparison operation block 10114 and the switch block 10116.

[0129] According to this embodiment, it is possible to calculate the cumulative cost taking into account the influence of optimization, and by approaching the actual operation, it is possible to estimate the processing load with higher accuracy.

[0130] (Seventh embodiment) In the seventh embodiment, a system in which a processing load estimation unit 106 estimates a processing load by taking data flow into consideration will be described. Note that in the seventh embodiment, differences from the previously described embodiments will be mainly described, and descriptions of configurations and processes that are the same as those in the previously described embodiments will be omitted. Furthermore, although the software component 100 may be either a control model 101 or a program 201, the seventh embodiment will be described using the control model 101 as an example.

[0131] 18 is a system configuration diagram showing a processing load estimation system 1 for software components that takes data flow into consideration according to an embodiment of the present invention. This system differs from the processing load estimation system according to the first embodiment (FIG. 1) in that a data flow analysis unit 701 is newly added to the processing load estimation unit 106.

[0132] 19, and identifies the data types of the signal lines connecting blocks. Furthermore, it analyzes blocks in which constants and parameters are set, such as the gain block 10105, constant blocks 10108, 10109, 10110, 10111, and one-dimensional table search block 10112, and identifies the data types of the set constants and parameters.

[0133] FIG. 20 is a diagram showing an example of a cost database included in the cost storage unit 108 according to this embodiment, and shows an example of a cost database in which the calculation load cost for each calculation block is recorded.

[0134] 20, since the processing time for each operation differs depending on the data type, the cost for each data type is stored in advance in the cost storage unit 108. Furthermore, since the number of cycles for type conversion also differs depending on the data type, the number of cycles for type conversion is stored in advance in the cost storage unit 108.

[0135] FIG. 21 is a flowchart of the process executed by the route cost evaluation unit 109 according to this embodiment.

[0136] As shown in the flowchart, the route cost evaluation unit 109 starts the process from step S109701.

[0137] In step S109702, the path cost evaluation unit 109 acquires, from the data flow analysis unit 701, model information including information on the data type of the signal line and the data type of the constants and parameters set in the block.

[0138] In step S109703, the path cost evaluation unit 109 identifies all operation blocks included in the control model 101 and their input data types from the model information including data type information.

[0139] In step S109704, the path cost evaluation unit 109 refers to the cost storage unit 108 and acquires the cost corresponding to each combination of operation block and data type.

[0140] In step S109705, the path cost evaluation unit 109 identifies the location where data type conversion occurs.

[0141] In step S109706, the route cost evaluation unit 109 refers to the cost storage unit 108 and acquires the cost according to the type of data type conversion.

[0142] In step S109707, the path cost evaluation unit 109 accumulates the costs according to the combination of operation block and data type obtained in step S109704 and the cost of data type conversion obtained in step S109706 for each operation path, and calculates the accumulated cost for each operation path.

[0143] In step S109708, the route cost evaluation unit 109 ends the process.

[0144] For example, the input data type of the gain block 10105 shown in Fig. 19 is double type, and the constant value 10 set in the gain block 10105 is also double type. In this case, in step S109703, the combination of the gain block 10105 and double type is identified, and in step S109704, C12, which is the cost of the double type gain block, is selected from the database of the cost storage unit 108 shown in Fig. 20.

[0145] 19, the input data type of gain block 10105 is double, the constant value 10 set in gain block 10105 is also double, and the data type of the output signal is single. Therefore, one data type conversion from double to single has occurred, and this data type conversion is identified in step S109705. Then, in step S109706, cost C91 for conversion from double to single is selected from the database of cost storage unit 108 shown in FIG.

[0146] By applying the above-mentioned concept, the cumulative cost C of all the operation blocks executed when the main operation route MR1 is selected is calculated. MR1 becomes C12+C91+C71+C71+C51+C61.

[0147] According to this embodiment, the processing load that cannot be estimated from block information alone can be estimated by taking data types into consideration, and the processing load can be estimated with higher accuracy than when only operation block information is used.

[0148] The seventh embodiment does not necessarily require the simulation unit 105 or the result processing unit 107, and can be implemented independently using only the processing load estimation unit 106.

[0149] Although multiple embodiments of the present invention have been described above, two or more embodiments can be combined in any manner.

[0150] As described above, according to the embodiments of the present invention, it is possible to estimate performance such as average processing time, minimum processing time, and maximum processing time with high accuracy at an early stage in the upstream design process, thereby reducing development man-hours by preventing rework. Furthermore, by providing practical processing times that take actual use cases into consideration, it can be used to evaluate the performance of not only individual software components but also the entire system.

[0151] The present invention is not limited to the above-described embodiments, but includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to configurations including all of the described configurations. Furthermore, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Furthermore, the configuration of another embodiment may be added to the configuration of one embodiment. Furthermore, part of the configuration of each embodiment may be added, deleted, or replaced with other configurations.

[0152] Furthermore, the aforementioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by having a processor interpret and execute a program that realizes each function.

[0153] Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0154] In addition, the control lines and information lines shown are those that are considered necessary for explanation, and do not necessarily represent all the control lines and information lines that are necessary for implementation. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0155] 100: Software component, 101: Control model, 102: Software component input unit, 103: Test suite, 104: Test suite input unit, 105: Simulation unit, 106: Processing load estimation unit, 107: Result processing unit, 108: Cost storage unit, 109: Path cost evaluation unit, 201: Program, 501: Memory analysis unit, 701: Data flow analysis unit

Claims

1. A processing load estimation system, A computing device that executes predetermined processing and a storage device that can be accessed by the computing device, a software component input unit to which a software component having a plurality of calculation elements that realize a predetermined calculation flow and having a calculation path that varies depending on an input value is input; a test suite input unit to which a test suite to be applied to the software component is input; the calculation device has a processing load estimation unit that estimates a processing load for each calculation path; a simulation unit configured to simulate the software component based on the test suite and output dynamic characteristics obtained from a plurality of simulation results; the calculation device has a result processing unit that processes dynamic features output from the simulation unit, The result processing unit estimates the actual processing load of the software component based on the dynamic characteristics, a plurality of calculation results corresponding to the input values, and the processing load for each path.

2. 2. The processing load estimation system according to claim 1, The processing load estimation system is characterized in that the calculation element is a calculation block in a model that constitutes the software component.

3. 2. The processing load estimation system according to claim 1, The processing load estimation system is characterized in that the calculation element is an operator in software that constitutes the software component.

4. 2. The processing load estimation system according to claim 1, The processing load estimation system is characterized in that the result processing unit estimates the practical processing load based on a value relating to the amount of calculation obtained as a dynamic feature from the simulation result.

5. 2. The processing load estimation system according to claim 1, The processing load estimation system is characterized in that the result processing unit estimates the actual processing load based on a standard deviation calculated from the variation in the calculation load obtained by the simulation.

6. 2. The processing load estimation system according to claim 1, The processing load estimation system is characterized in that the result processing unit estimates the actual processing load by excluding calculation paths that were not passed through in the simulation from among the theoretical calculation paths based on the software components.

7. 2. The processing load estimation system according to claim 1, The processing load estimation system is characterized in that the result processing unit estimates the actual processing load based on the frequency of passage of each calculation path in the simulation.

8. 8. A processing load estimation system according to claim 7, The processing load estimation system is characterized in that the result processing unit estimates the actual processing load by excluding calculation paths whose passing frequency in the simulation is equal to or less than a predetermined threshold.

9. 9. A processing load estimation system according to claim 1, the processing load estimation unit includes a cost storage unit that stores the processing load of the calculation element, and a path cost evaluation unit that calculates an accumulated cost by accumulating costs for each calculation path; The processing load estimation system is characterized in that the path cost evaluation unit estimates a processing load for each of the computation paths based on the accumulated cost.

10. 10. The processing load estimation system according to claim 9, the processing load estimation unit has a memory analysis unit that analyzes a calculation element related to a memory attribute of the software component; the cost storage unit stores a cost corresponding to a delay time of writing and reading for each of the memory attributes of the software component obtained by the memory analysis unit; The processing load estimation system is characterized in that the processing load estimation unit estimates the processing load taking the delay time into consideration.

11. 10. The processing load estimation system according to claim 9, the cost storage unit stores the cost of a specific combination of operation elements; The route cost evaluation unit Detecting a specific combination of computing elements, a processing load estimation system for estimating a processing load for each of the operation paths using a cost associated with the detected combination of the specific operation elements;

12. 10. The processing load estimation system according to claim 9, the processing load estimation unit has a data flow analysis unit that analyzes a data flow, The processing load estimation system is characterized in that the path cost evaluation unit estimates a processing load for each operation path based on the analysis result by the data flow analysis unit.

13. The processing load estimation system according to claim 12, the cost storage unit stores different costs according to differences in data type; The processing load estimation system is characterized in that the path cost evaluation unit estimates the processing load for each of the computation paths using costs according to differences in data type.

14. The processing load estimation system according to claim 12, the cost storage unit stores the cost of data type conversion; The data flow analysis unit detects data type conversions; The processing load estimation system, wherein the path cost evaluation unit estimates the processing load for each operation path using costs according to differences in conversion of the data type.

15. A processing load estimation method executed by a processing load estimation system, the processing load estimation system includes a computing device that executes a predetermined process and a storage device that is accessible by the computing device; The processing load estimation method includes: a software component input step in which the processing load estimation system inputs a software component having a plurality of calculation elements that realize a predetermined calculation flow, the calculation path of which varies depending on an input value; a test suite input step in which a test suite to be applied to the software component is input; a processing load estimation step in which the computing device estimates a processing load for each of the computation paths; a simulation procedure in which the computing device simulates the software component based on the test suite and outputs dynamic characteristics obtained from a plurality of simulation results; a result processing procedure, in which the computing device processes dynamic features output by the simulation procedure; In the result processing procedure, the calculation device estimates the actual processing load of the software component based on the dynamic characteristics, multiple calculation results corresponding to the input values, and the processing load for each path.

Images