WO2012117746A1

WO2012117746A1 - Computer software system design support device

Info

Publication number: WO2012117746A1
Application number: PCT/JP2012/001478
Authority: WO
Inventors: 幸一中本; 秀一大西
Original assignee: 兵庫県; 株式会社ヴィッツ
Priority date: 2011-03-02
Filing date: 2012-03-02
Publication date: 2012-09-07
Also published as: JP5374707B2; JPWO2012117746A1

Abstract

Provided are a computer software design support method and a design support device, wherein the design step pertaining to performance issues which is one of the serious causes for malfunction is ameliorated and development costs associated with improving the quality of embedded software and reducing the number of back track steps are reduced. At least the priory, activation cycle, execution time and execution frequency are defined for each task constituting an application processing program. Moreover, the execution flow of tasks constituting the application processing program is defined. The execution time for the execution flow of the tasks is calculated by using the priority, activation cycle, execution time and execution frequency defined for each task. The system performance is predicted from the minimum execution time, maximum execution time and execution time distribution of the application processing program.

Description

Computer software system design support device

The present invention relates to a design support method and a design support apparatus for predicting the performance of computer software that operates stand-alone and for pre-evaluating the design and performance of the computer software.

As functions required for computer-mounted devices such as information home appliances and mobile phones have increased, the amount of software mounted on devices has increased, and the number of software components mounted on one system has become enormous. In particular, in the case of a mobile phone, 200 to 300 software components such as a call function, an e-mail function, and a browser function are present together.
Therefore, there is a problem with the quality of such computer-mounted devices. Such a quality problem can be solved by a simulator or the like, but in many cases, it is not known whether or not the performance problem is satisfied only after the software parts are combined.
This is because these software components operate simultaneously while sharing one hardware resource, and therefore execution of one software component causes execution of other software components to be delayed. When a performance problem is discovered, the development process is backtracked, resulting in a huge cost.

Under such circumstances, a queuing model has been conventionally used as a server computer design model as shown in FIG. 15 (for example, Non-Patent Document 1). In particular, queuing models have been used in network systems. However, although the queuing model is effective for system design, there is a large gap between the queuing model and the software design model in software design, and it is difficult to say that it is a practical approach.
In addition, an approach method for estimating the performance of the entire system by estimating the amount of hardware resources required for each step when executing software is presented (Non-Patent Document 2). However, access to shared resources in the system often has a large effect on performance, but this performance evaluation also uses the queuing model and has the same problem as described above.

In addition, there is one that discloses an approach method for predicting performance in a computer system (Patent Document 1).
There is also a performance evaluation method for parallel computers (Patent Document 2), which also uses a queuing network model based on a queuing model and has the same problem as described above.

In addition, there is a system that actually measures performance in a system and performs performance prediction based on the data (Patent Document 3). Although this method may be effective for the development of affiliated systems, it does not work very well when initially designing a system.
Further, there is a performance prediction method at a part level with a coarse particle size in a computer system (Patent Document 4). However, in the case of performance prediction at the level of coarse parts, it is not possible to evaluate the performance of those with severe time constraints such as a real-time system.

JP-A-4-363730 JP 2000-298598 A JP 2004-220453 A JP 2004-272582 A

Embedded software malfunctions account for more than half of the causes of malfunctions in embedded systems. The reason for the failure is that sufficient measures have not been taken against the large scale and complexity of embedded software.
For example, in the case of mobile phones, as shown in FIG. 13, new functions are installed to improve product competitiveness, functions are improved using new technologies, and functions are improved to meet customer demands. , E-mail function, call function, browser function, video playback function and many other programs are installed. For this reason, the development scale of mobile phones has increased, and verification of the combined operation of programs has become difficult. Over 50% of the causes of defects are caused by programs, and these defects occur at the end of product development or after product shipment.
Therefore, by clarifying the performance requirements of individual functions of many installed programs and performing preliminary operation verification, not only the functions but also the functions are required in order to reduce the development period, process, return, and unspecified countermeasure costs. There is a demand for a tool that can support program design so that performance can be satisfied (see FIG. 14).

In view of the above situation, the present invention aims to improve a design process related to a performance problem, which is one of the major causes of failures, and to reduce the development cost by improving the quality of embedded software and reducing the number of reversals. An object is to provide a software design support method and a design support apparatus.

In order to achieve the above object, a computer software design support method of the present invention is a computer software design support method for predicting the performance of a system equipped with at least one application processing program, and includes the following steps 1) to 4): Is provided.
1) Define at least the priority, start cycle, execution time, and number of executions for each task constituting the application processing program 2) Define the execution flow of the tasks constituting the application processing program 3) Define for each task Step 4) Calculate the execution time of the task execution flow using the priority, start cycle, execution time, and number of executions. 4) Predict system performance from the minimum execution time, maximum execution time, and execution time distribution of the application processing program. Step to perform

According to this configuration, it is possible to verify in advance at the design stage the performance prediction of a system equipped with many application processing programs such as a mobile phone and an information home appliance.
The priority, start cycle, execution time, and number of executions for each task constituting the application processing program 1) will be described. Here, the application processing program is for causing the computer to realize the functions of the system. A task is a process that is a component for causing a computer to realize a function. The task priority is an index for determining the order in which the computer executes when there are a plurality of executable tasks. Also, the task activation cycle refers to the activation time interval when the task is activated periodically. If the task is a process that operates according to an event, the activation cycle is set to 0 (zero), for example. The task execution time is an estimated time for the computer to execute the task. This estimated time takes into account the processing volume performed by the task and the processing waiting time when the task accesses the hardware resource. Further, the number of executions of a task means the number of executions of a task that is periodically started up or the number of retries of a task that performs an error retry.

Next, the execution flow of the tasks constituting the application processing program 2) will be described. Here, the application processing program means, for example, in the case of a mobile phone, a program that realizes a browser function, a program that realizes an e-mail function, a program that realizes a call function, and the like. The execution flow of the tasks constituting the application processing program refers to a flowchart showing the execution order, repetition, conditional branching, exclusive control of resources between tasks, etc. of one or more tasks constituting the application processing program.

Next, how to calculate the execution time of the task execution flow using the priority, start cycle, execution time, and number of executions defined for each task in 3) above is as follows: It is to add the execution time of each task.
In the case of a system equipped with one application processing program, execution times are added in order according to the execution flow of the tasks constituting the application processing program. When a task accesses a resource that requires a processing waiting time, the processing waiting time is also added.

On the other hand, in the case of a system equipped with a plurality of application processing programs, there are a plurality of task execution flows for each application processing program. If there are multiple execution flows, there may be multiple tasks that can be executed. In this case, for example, if there is a resource processing wait time in one execution flow task or if there is an algorithm that waits for processing until a specific condition is satisfied, the task is switched to a task that can be executed in the other execution flow. The execution time is added as the task is executed. In addition, since a high priority is executed by the operating system (OS), for example, the priority of a task that can be executed in one execution flow and the priority of a task that can be executed in the other execution flow are set. In comparison, the execution time is added assuming that the task with the higher priority is executed.

In the computer software design support method of the present invention, the task execution time distribution information is preferably added to the task execution time of 1) above.
The task execution time distribution information is added by paying attention to the fact that some tasks do not always finish processing at a fixed execution time. The distribution information of task execution time includes distribution information of execution time, distribution information expressed by mathematical expressions such as probability distribution of execution time, and Gaussian distribution. Note that the task execution time distribution information is not limited to this as long as it represents variations in task execution time.

For example, the task execution time distribution information is more preferably defined by the estimated execution time and its weight. The weighting may be expressed by a probability that the estimated execution time is reached.

For example, the task execution time distribution information preferably includes the access time of the hardware resource when the task accesses the hardware resource.
Here, hardware resources include shared memory, flash memory (flash
non-volatile semiconductor memory such as memory), USB (Universal Serial Bus) memory, and hard disk. Further, the access time of hardware resources is processing waiting time such as write time and read time for accessing resources.

Further, it is more preferable that the task execution time distribution information includes the exclusive control processing waiting time when the task includes the exclusive control logic. A timeout time may be set in the exclusive control logic.

The task execution time is more preferably used as a reference index value obtained by accumulating the estimated execution time of the application interface function of the system software used for the task.
Here, the system software is a program outside the framework of the application processing program, such as an operating system (OS) or a screen drawing service program.

Further, in the computer software design support method of the present invention, when defining a predicted time region as a performance target for each application processing program, and when the execution time distribution of the simulation result deviates from the predicted time region, It is preferable to output an alarm to the application processing program.
Here, the predicted time area that is the performance target for each application processing program is the one that defines the upper limit of the processing time, the one that defines the lower limit, the one that defines the upper and lower limits, the one that defines some time, and the several time areas An example is given below.

In the computer software design support method of the present invention, the simulation of the minimum execution time, maximum execution time, and execution time distribution of the application processing program defines the execution probability for each of one or more tasks that are conditionally executed. It is preferable that an execution time distribution is generated.
Here, each execution probability is defined for each of one or more tasks that are conditionally executed. For example, when the process is divided into two processes, the tasks executed depending on the conditions are different. The execution time varies depending on the conditions. Therefore, by defining the execution probability of each task, we decided to simulate the minimum execution time, maximum execution time, and execution time distribution of an application processing program having logic that processes depending on conditions.

In the computer software design support method of the present invention, the simulation of the minimum execution time, maximum execution time, and execution time distribution of the application processing program performs exclusive control on hardware resources that are commonly accessed by a plurality of tasks. Thus, an execution time distribution is preferably generated.
When performing exclusive control on hardware resources commonly accessed by multiple tasks, the exclusive control is usually performed using a flag, a semaphore, a token, or the like. The time until the value of this flag changes or the time until acquisition such as a semaphore is the processing waiting time. Since this processing wait time changes depending on the task execution status, an execution time distribution occurs.

Next, the computer software system design support apparatus of the present invention will be described.
A computer software system design support apparatus according to the present invention includes a task definition input means for defining a priority, a start cycle, an execution time, and an execution count for each task constituting an application processing program and registering it as a task information database, and an application processing program Stores program definition input means that defines the execution flow of tasks used every time using flow definition parts registered in advance, and registers it as a program definition database, a task information database, a program definition database, and flow definition parts An execution time distribution simulation means for simulating an execution time distribution for each application processing program, and a result display means for displaying a performance evaluation result of the system.

According to this configuration, it is possible to verify in advance at the design stage the performance prediction of a system equipped with many application processing programs such as a mobile phone and an information home appliance.
The task definition input means for defining the priority, start cycle, execution time, and number of executions for each task constituting the application processing program and registering it as a task information database will be described. Here, the application processing program is for causing the computer to realize the functions of the system. A task is a process that is a component for causing a computer to realize a function. The task priority is an index for determining the order in which the computer executes when there are a plurality of executable tasks. Also, the task activation cycle refers to the activation time interval when the task is activated periodically. If the task is a process that operates according to an event, the activation cycle is set to 0 (zero), for example. The task execution time is an estimated time for the computer to execute the task. This estimated time takes into account the processing volume performed by the task and the processing waiting time when the task accesses the hardware resource. Further, the number of executions of a task means the number of executions of a task that is periodically started up or the number of retries of a task that performs an error retry.

The task information database is a database in which information on the priority, start cycle, execution time, and number of executions can be referred to by a unique identification number assigned to each task. The unique identification number assigned to each task may be a unique task name.

Next, a description will be given of program definition input means for defining a task execution flow used for each application processing program using a flow definition component registered in advance and registering it as a program definition database. Here, the application processing program means, for example, in the case of a mobile phone, a program that realizes a browser function, a program that realizes an e-mail function, a program that realizes a call function, and the like. The execution flow of the tasks constituting the application processing program refers to a flowchart showing the execution order, repetition, conditional branching, exclusive control of resources between tasks, etc. of one or more tasks constituting the application processing program.

A flow definition component is a symbolic representation of task execution order, repetition, conditional branching, resource exclusion control between tasks, etc. The number of repetitions, probability of conditional branching, timeout of exclusive control, etc. It has the parameter of.
The program definition database can refer to the flow definition parts and parameters used by the program, the resources accessed by the program, and the identification numbers of the tasks constituting the program, using a unique identification number assigned to each program. It is a database. The unique identification number assigned to each program may be a unique program name.

Next, an execution time distribution simulation means for simulating the execution time for each application processing program using the above-described task information database, program definition database, and flow definition component database in which flow definition components are stored will be described. The simulation of the execution time distribution for each application processing program recognizes the task to be used and the flow definition component to be used from the program definition database corresponding to the program, and executes the priority and execution from the task information database corresponding to the task. Time and the like are recognized, and the processing contents and parameters are recognized from the flow definition component database corresponding to the flow definition component.

Then, the execution time of each application processing program is simulated by adding the execution time of each task according to the task execution flow based on the priority and execution time of the recognized task, the recognized execution order, etc. To do.
In the case of a system equipped with one application processing program, execution times are added in order according to the execution flow of the tasks constituting the application processing program. When a task accesses a resource that requires a processing waiting time, the processing waiting time is also added.

Next, a result display means for displaying the performance evaluation result of the system will be described. The execution time distribution for each program as a result of the simulation displays the result on a display screen such as a liquid crystal panel attached to the apparatus with the minimum execution time, the maximum execution time, and the occurrence frequency as a graph or a table. The simulation result is stored as a different file for each program or program version.

The computer software system design support apparatus preferably further includes performance target information defining means for defining a predicted time region in the program definition database for each application processing program as performance target information for each application processing program. .
The performance target information is a minimum execution time, a maximum execution time, an average execution time, and a distribution degree.

Further, the result display means in the computer software system design support apparatus outputs an alarm to the application processing program when the execution time distribution of the simulation result deviates from the predicted time region. Is preferred.
Here, the predicted time area that is the performance target for each application processing program is the one that defines the upper limit of the processing time, the one that defines the lower limit, the one that defines the upper and lower limits, the one that defines some time, and the several time areas An example is given below.

Moreover, it is preferable that the task definition input means in the computer software system design support apparatus includes means for further registering the startup offset time, the real time attribute, and the time slice time for each task in the task information database.
Here, the activation offset time is a delay time until the task is activated. For tasks resident in main memory, the delay time can be ignored, but for non-resident tasks where the processing code is read from the hard disk every time it is started, the delay time is also taken into account in designing the overall system performance. The evaluation can be performed correctly.
In this specification, the real-time attribute means an event-driven task such as an interrupt, that is, a task that requires real-time property, or a periodic-driven task that performs processing periodically, that is, periodicity. Or a task attribute indicating whether a round robin method for distributing the CPU time to all executable tasks is required.

Further, it is preferable that the task definition input means in the computer software system design support apparatus includes means for estimating the distribution information of the task execution time and registering a plurality of sets as distribution information as one set of the estimated execution time and its weight.
The weighting may be expressed by a probability that the estimated execution time is reached. The task execution time distribution information is added by paying attention to the fact that some tasks do not always finish processing at a fixed execution time. The distribution information of task execution time includes distribution information of execution time, distribution information expressed by mathematical expressions such as probability distribution of execution time, and Gaussian distribution. Note that the task execution time distribution information is not limited to this as long as it represents variations in task execution time.

Moreover, it is preferable that the task definition input means in the computer software system design support apparatus further includes a processing wait time registration means for registering an estimated processing time of a hardware resource in which a processing wait time occurs.
Here, the hardware resource means a non-volatile semiconductor memory such as a shared memory or a flash memory, a USB memory, a hard disk, or the like, as described above. Further, the access time of hardware resources is processing waiting time such as write time and read time for accessing resources.
The hardware resource is more preferably a resource that is commonly accessed by a plurality of tasks. When exclusive control logic is required for resources that are commonly accessed by a plurality of tasks, the processing wait time for exclusive control is included. A timeout time may be set in the exclusive control logic. When performing exclusive control on hardware resources commonly accessed by multiple tasks, the exclusive control is usually performed using a flag, a semaphore, a token, or the like. The time until the value of this flag changes or the time until acquisition such as a semaphore is the processing waiting time. Since this processing wait time changes depending on the task execution status, an execution time distribution occurs.

In the computer software system design support apparatus described above, it is more preferable that the application definition input means can input at least a definition of repetitive processing, conditional branch processing, and parallel execution processing using the components registered in the flow definition component database. .

Here, it is preferable that the condition execution process can define execution probabilities for each of one or more tasks that are condition-executed.
Each execution probability is defined for one or more tasks that are executed conditionally. For example, when the process is divided into two processes, the task executed depends on the condition. The execution time will change. Therefore, by defining the execution probability of each task, we decided to simulate the minimum execution time, maximum execution time, and execution time distribution of an application processing program having logic that processes depending on conditions.

In addition, parallel execution processing is performed only when all tasks that are executed in parallel are completed, and parallel type execution that advances after that, and split type parallel execution that advances even if all tasks that are executed in parallel do not end. And preferably.

Software, particularly embedded software incorporated in a device device, needs to be designed under severe hardware constraints such as low CPU capacity and low memory.
According to the present invention, it is possible to avoid a situation in which the performance of the entire system is unachieved for the first time at the stage of designing, producing, and embedding the software module in the device. This has the effect of reducing the associated costs.

Computer software design support flow chart Illustration of application processing program Explanatory diagram of tasks used in the execution flow of application processing program Explanation of task execution flow Fig. 1 Explanation of task execution flow Fig. 2 Explanation of task execution flow Fig. 3 Explanation of task execution flow Fig. 4 Explanation of task execution flow Fig. 5 Explanation of task execution flow Fig. 6 Explanation of task execution flow Fig. 7 Functional block diagram of video playback system Flow chart of program execution in video playback system Functional block diagram of mobile phone 1 Functional block diagram of mobile phone 2 Conceptual diagram of transaction using conventional queuing model Functional block diagram of a computer software system design support device Project creation menu Project creation screen Task creation menu Task creation screen Application processing program definition screen Performance requirement analysis menu Simulation information input screen Performance target information list screen Performance target information input screen Task information list screen Task information input screen Simulation evaluation result display screen (overall information screen) Simulation evaluation result display screen (sequence screen) Simulation evaluation result display screen (task trace screen)

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The scope of the present invention is not limited to the following examples and illustrated examples, and many changes and modifications can be made.

FIG. 1 shows a processing flow of the computer software design support method of the present invention.
The computer software design support method of the present invention performs performance prediction for a stand-alone system having one or more application processing programs in the following steps.
(Step 1) For each task constituting each application processing program, a priority, a start cycle, an execution time, and an execution count are defined.
(Step 2) For each application processing program, an execution flow of tasks constituting the program is defined.
(Step 3) Using the priority, start cycle, execution time, and number of executions defined for each task, the execution time of the task execution flow is calculated for each application processing program.
(Step 4) System performance prediction is performed based on the minimum execution time, maximum execution time, and execution time distribution of all application processing programs.

The relationship between the application processing program and the task will be described with reference to FIG.
FIG. 2 is a functional block diagram illustrating an example of an application processing program.
The application processing program of FIG. 2 includes processing task 1 and processing task 2. It is assumed that the processing task 1 performs processing for extracting the message data 3 from the message queue 1, processing the message data 3 and writing the data in the shared memory 5. The processing task 2 reads data from the shared memory 5, processes the data, writes data to the flash memory 6, and in some cases reads data from the flash memory 6 and sends it to the message queue 2. Assumed to be performed.

In such an application processing program, according to the above (step 1), first, the priority, the start cycle, the execution time, and the number of executions are defined for the two tasks of the processing task 1 and the processing task 2.
Here, it is assumed that the processing task 1 is designed as a message driven task and the processing task 2 is designed as a periodically driven task. The activation cycle of processing task 1 is 0 (zero), and the activation cycle of processing task 2 is 10 ms, for example. The message driven processing task 1 is generally designed with a high priority. When the process is performed only once, the number of executions is 1, and when the process is repeated a plurality of times, the number of executions is n.

With respect to the execution time, in the case of the processing task 1, the processing performed by the task, that is, the data extraction processing from the message queue 1, the writing processing to the shared memory 5, and the estimated time of each are estimated and determined. Further, in the case of the processing task 2, a process for reading data from the shared memory 5, a process for writing data to the flash memory 6, a process for sending data to the message queue 2, and an estimated time for each are predicted and determined.
Here, if there is a processing waiting time in shared memory write processing, read processing, flash memory access processing, etc., the estimated time is predicted in consideration of such processing wait times. Further, when exclusive control is performed on the shared memory 5 to which the processing task 1 and the processing task 2 respectively write and read, the estimated time is predicted in consideration of the processing waiting time until the control right is received.

FIG. 3A shows an example of the types of tasks used in the execution flow of the application processing program. Tasks are finely defined in units that can be estimated. Define things that execute tasks repeatedly, those that execute a large number of cases according to conditions, and those that execute tasks in parallel.
FIG. 3B shows an example of hardware resources. A hardware resource is given a task processing wait time for accessing the resource as attribute information.

Next, an execution flow of tasks constituting the application processing program will be described with reference to FIGS.
First, an example of an execution flow of a repetitive task is shown. FIG. 4 shows an example of the execution flow of the repetitive task. For example, assuming that the initialization task 10 is 10 μsec, the process transaction task 12 is 20 μsec, the end session task 14 is 5 μsec, and the number of repetitions of the repetition task 16 is n = 5, the execution time of the execution flow shown in FIG. Is 10 + 20 × 5 + 5 = 115 μsec.

Next, an example of a case task execution flow is shown. FIG. 5 shows an example of a case task execution flow. For example, the transaction acquisition task 20 is 15 μsec, the process A task 22 is 20 μsec, the process B task 24 is 40 μsec, and the process C task 26 is 25 μsec, and the branch probabilities a to c of the case task 28 are 0.5 and 0, respectively. .3, 0.2, the execution time of the execution flow shown in FIG. 5 is that the minimum execution time is 15 + 20 = 35 μsec, the maximum execution time is 15 + 40 = 55 μsec, and the execution time distribution is 35 μsec, 55 μsec, 15 + 25 = 40 μsec. The distribution appears at each probability.

Next, an example of the execution flow of the Pardo task is shown. FIG. 6 shows an example of the execution flow of the pulse task. For example, it is estimated that the user input operation task 30 is 5 μsec, the remote query display task 32 is 15 μsec, the task 34 for displaying the query result on the screen is 25 μsec, the task 36 using the input data as display data is 10 μsec, and the display display task 38 is 20 μsec. In the case of time, the execution time of the execution flow shown in FIG. 6 is 5 + 25 + 10 + 20 = 60 μsec. The Pardo task 31 includes a logic in which an attached task 32 and task 34 are executed in parallel, and processing does not proceed first unless all these tasks are completed.

Next, an example of the execution flow of a task that exclusively controls the shared memory is shown. FIG. 7 shows an example of an execution flow of tasks of two programs for inputting data and writing to the shared memory. The two application processing programs are composed of a program composed of an execution flow of a repetition task 41, a data input task 42, and a write data task 43, and an execution flow of a repetition task 46, a data input task 47, and a write data task 48. It is a program. For example, if the execution time of the write data task 43 is 20 μsec and the execution time of the write data task 48 is 25 μsec, each write data task waits for processing while the other write data task is writing to the shared memory 40. The execution time of the write data task 43 is 20 μsec, the maximum execution time is 20 + 25 = 45 μsec, and the execution time of the write data task 48 is 25 μsec, and the maximum execution time is 25 + 20 = 45 μsec.

FIG. 8 shows an example of an execution flow of two program tasks, a process of writing data to the shared memory and a process of reading data. The two application processing programs are composed of a program composed of an execution flow of a repetition task 51, a data input task 52, and a write data task 53, and an execution flow of a repetition task 56, a read data task 57, and a screen display task 58. It is a program. Assume that one program writes data to the shared memory 50 and the other program reads and processes the written data. For example, if the execution time of the data input task 52 is 10 μsec, the execution time of the write data task 53 is 20 μsec, the execution time of the read data task 57 is 15 μsec, and the execution time of the screen display task 58 is 25 μsec, The minimum execution time until the screen is displayed is 10 + 20 + 15 + 25 = 70 μsec.

Here, consider a case where the priority of the data input task 52 and the priority of the read data task 57 are different. If the data input task 52 has priority over the read data task 57, the minimum execution time until data is input and displayed on the screen is 10 + 20 + 10 + 15 + 25 = 80 μsec. This is because, after the write data task 53 is completed, the read data task 57 is not operated until the data input task 52 is operated again by repetition and the data input task 52 is completed. The same applies when the data input task 10 has priority over the screen display task 58.

Next, an example of the execution flow of the task that accesses the flash memory is shown. FIG. 9 shows an example of an execution flow of a task of a program that stores data and stores it in a temporary memory or flash memory. For example, the execution time of the data storage task 60 is 15 μsec, the execution time of the storage task 62 in the temporary memory is 20 μsec, the processing waiting time of the flash memory is estimated as 50 μsec, the execution time of the storage task 63 in the flash memory is 70 μsec, and the end session task If the execution time of 65 is 5 μsec and the branch probabilities of the case task 61 are 0.8 and 0.2, respectively, the execution time of the execution flow shown in FIG. 9 is 15 + 20 = 40 μsec, the minimum execution time is 15 + 70 + 5 = At 90 μsec, the execution time distribution is 40 μsec and 90 μsec is a distribution that appears with respective probabilities.

Next, an example of the execution flow of a task that receives a message from the message queue is shown. FIG. 10 shows an example of an execution flow of a task of a program that receives a message from the message queue 70 and performs a service. For example, if the execution time of the message reception task 71 is 10 μsec, the execution time of the service processing task 72 is 50 μsec, and the execution time of the end session task 73 is 5 μsec, the execution time of the execution flow shown in FIG. 10 is 10 + 50 + 5 = 65 μsec. .

(Video playback device)
FIG. 11 shows a functional block diagram of the application processing program of the video reproduction apparatus. FIG. 11 shows a file reading task, a video decoding task, a video display task, an audio decoding task, an audio playback task, and a shared memory. The start cycle and start delay of each task, the waiting time of the shared memory, and the access unit are shown. It is shown.
First, the data read from the shared memory by the file reading task is written to another shared memory. Next, the video decoding task and the audio decoding task respectively extract and decode the data in the shared memory, and pass them to the video display task and the audio reproduction task via the shared memory, respectively.
FIG. 12 is obtained by rewriting the functional block of FIG. 11 into a task execution flow. The execution flow of each task is shown divided into two programs, an audio processing program and a video processing program. Exclusive control is not performed for the shared memories 1 to 5. The file reading task (80, 86) is a common task.

For example, the execution time of the file reading task (80, 86) is 20 μsec, the execution time of the audio decoding task 82 is 10 μsec, the execution time of the audio reproduction task 83 is 30 μsec, the execution time of the video decoding task 87 is 40 μsec, and the video display task 88 Is 60 μsec, the minimum execution time of the audio processing program is 60 μsec, and the minimum execution time of the video processing program is 120 μsec. Further, the maximum execution time is calculated on the assumption that the processing is delayed by the activation cycle time and that the activation delay time is further added. In the case of a speech processing program, (2 + 1) + (4 + 1) + (16 + 1) = 25 msec is added to the minimum execution time to calculate the maximum execution time. In the case of a video processing program, (2 + 1) + (4 + 1) + (16 + 1) = 25 msec is added to the minimum execution time to calculate the maximum execution time. Since the start cycle of each task is different, the execution time varies.

In the second embodiment, an aspect of a computer software system design support apparatus will be described.
The computer software system design support apparatus is composed of a general-purpose desktop computer or notebook computer.
FIG. 16 shows a functional block diagram of the computer software system design support apparatus.
The computer software system design support apparatus includes a task information database, a program definition database, and a flow definition component database surrounded by broken lines in FIG. These databases are usually stored in the hard disk of the computer software system design support apparatus.
The task information database has a unique task name, priority, start offset, start cycle, real time attribute, execution time, time slice, and number of executions assigned to each task. This database can be referenced by task name.

The program definition database is a database in which flow definition parts and parameters used by the program, resources accessed by the program, and task names constituting the program can be referred to by a unique program name assigned to each program.

The flow definition component database also displays flow definition component parameter information such as the number of repetitions, probability of conditional branching, timeout of exclusive control, etc., flow of task execution order, repetition, conditional branching, exclusive control of resources between tasks, etc. It is a database that can be referenced by a unique number assigned to a definition part.

In addition, as shown in FIG. 16, the computer software system design support apparatus is pre-registered with task definition input means for defining task information for each task and registering it as a task information database, and a task execution flow used for each program. Program definition input means for defining and registering as a program definition database.
In addition, an execution time distribution simulation unit for simulating an execution time distribution for each application processing program and a system performance evaluation result display unit are provided.

Hereinafter, description will be made with reference to the operation menu and screen of the computer software system design support apparatus.
17 and 18 show a project creation menu and a project creation screen, respectively. The computer software system design support apparatus manages a design target device or a design target system in units of projects. Therefore, create a project first.

Next, a screen for defining an application processing program and individual tasks constituting the application processing program will be described. The task is defined by drawing a class diagram in conformity with UML (Unified Modeling Language) 2.0. UML is a unified notation for program design drawings in object-oriented software development.
The definition of an application processing program is to define a task execution flow used for each application processing program using a flow definition component registered in advance. The execution flow of this task is called a software execution model.
19 and 20 show a task creation menu and a task creation screen according to UML 2.0, respectively. FIG. 21 is an application processing program definition screen.

Next, performance requirement analysis will be described. FIG. 22 shows the performance requirement analysis menu. When the performance requirement analysis is selected from the menu, the simulation information input screen of FIG. 23 is displayed. The simulation operation environment information is input using the simulation information input screen of FIG. Specifically, a simulation time and a scheduling method are input.
When the “performance target information” tab in the screen is selected on the screen of FIG. 23, the performance target information list screen of FIG. 24 is displayed. As the performance target information, the program time constraint, here, the upper limit of the execution time is displayed.
The performance target information of each task is created using the performance target information input screen shown in FIG.

Next, task information will be described.
When the “task information” tab in the screen of FIG. 23 is selected, the task information list screen of FIG. 26 is displayed. On the task information list screen, task name, priority, start offset, start cycle, real time attribute, execution time, time slice, and number of executions are displayed in a list for each task.
Individual task information is created using the task information input screen of FIG.

Next, the performance evaluation result display screen by simulation will be described.
As the overall information, as shown in FIG. 28, the simulation time, the total task execution time of the real time attribute, the CPU usage rate, and the program list not achieving the performance target are displayed as the overall information screen.
In the screen of FIG. 28, when the “sequence” tab in the screen is selected, the sequence screen of FIG. 29 is displayed. As the graph information in FIG. 28, the program name, performance target, minimum execution time, and maximum execution time are displayed. According to the sequence screen, the execution time distribution of the application processing program can be grasped.

When the “task trace” tab in the screen of FIG. 28 or 29 is selected, the task trace screen of FIG. 30 is displayed. According to the task trace screen, it is possible to grasp the execution order and execution time of the tasks constituting the application processing program. In the graph in the figure, one program consists of 5 tasks (DecodeAudio task, DecodeVideo task, Timing task, FileReader task, Playbutton task), and after the FileReader task is executed, the timing task is shown. ing.

The computer software design support method and the computer software design support apparatus of the present invention are a software design method and a design support apparatus for a stand-alone computer-equipped device such as a mobile phone terminal and an information home appliance, and a plurality of such as an in-vehicle system and a robot control system. It is useful as a design support method and design support device for software installed in a system composed of computers.

1, 2

Message queue

3, 4 Data 5 Shared memory 6

Flash memory

11, 12 Task

Claims

A computer software design support method for predicting the performance of a system equipped with at least one application processing program,
Defining at least priority, start cycle, execution time, number of executions for each task constituting the application processing program;
Defining the execution flow of the tasks that make up the application processing program;
Calculating the execution time of the task execution flow using the priority, start cycle, execution time, and number of executions defined for each task;
Predicting system performance from minimum execution time, maximum execution time, and execution time distribution of application processing program;
A computer software design support method characterized by comprising:
The computer software design support method according to claim 1, wherein task execution time distribution information is added to the task execution time.
3. The computer software design support method according to claim 2, wherein the task execution time distribution information is defined by an estimated execution time and its weight.
3. The computer software design support method according to claim 2, wherein the task execution time distribution information includes a hardware resource access time when the task accesses a hardware resource.
3. The computer software design support method according to claim 2, wherein the task execution time distribution information includes an expected waiting time for exclusive control when the task includes exclusive control logic.
3. The computer software design support method according to claim 2, wherein as the task execution time, a value obtained by accumulating an estimated execution time of an application interface function of a system software used for the task is used as a reference index value.
A prediction time region for each application processing program is defined, and an alarm is output to the application processing program when the execution time distribution of the simulation result deviates from the prediction time region. The computer software design support method according to any one of claims 1 to 6.
In the simulation of the minimum execution time, the maximum execution time, and the execution time distribution of the application processing program, an execution time distribution is generated when each execution probability is defined for one or more tasks that are conditionally executed. The computer software design support method according to claim 1, wherein:
In the simulation of the minimum execution time, the maximum execution time, and the execution time distribution of the application processing program, an execution time distribution is generated by performing exclusive control on hardware resources commonly accessed by a plurality of tasks. The computer software design support method according to claim 1.
A task definition input means for defining the priority, start cycle, execution time, and number of executions for each task constituting the application processing program and registering it as a task information database;
A program definition input means for defining a task execution flow used for each application processing program using a flow definition component registered in advance and registering it as a program definition database;
An execution time distribution simulation means for simulating an execution time distribution for each application processing program using the task information database, a program definition database, and a flow definition component database in which the flow definition component is stored;
A result display means for displaying a system performance evaluation result;
A computer software system design support apparatus characterized by comprising:
11. The computer software system design according to claim 10, further comprising performance target information defining means for defining a predicted time region in the program definition database for each application processing program as performance target information for each application processing program. Support device.
The said result display means outputs an alarm with respect to this application processing program, when the said execution time distribution of a simulation result deviates compared with the said prediction time area | region. Computer software system design support device.
The task definition input means comprises means for further registering an activation offset time, an actual time attribute, and a time slice time for each task in a task information database. Computer software system design support device.
The task definition input means comprises means capable of registering a plurality of sets as distribution information as a set of estimated execution time and its weighting distribution information of task execution time as distribution information. The computer software system design support apparatus described.
11. The task definition input means further comprises task execution time distribution information input means capable of registering a set of estimated execution times and their weights as one set and a plurality of sets as task execution time distribution information. The computer software system design support apparatus according to any one of items 1 to 12.
16. The computer software system design according to claim 15, further comprising processing wait time registration means for registering an estimated time of processing wait time of a hardware resource in which processing wait time occurs in the task definition input means. Support device.
17. The computer software system design support apparatus according to claim 16, wherein the hardware resource is a resource that is commonly accessed by a plurality of tasks.
13. The application definition input means can input at least definitions of repetition processing, conditional branch processing, and parallel execution processing using components registered in the flow definition component database. Computer software system design support equipment.
19. The computer software system design support apparatus according to claim 18, wherein the condition execution process can define execution probabilities for each of one or more tasks to be conditionally executed.
In the parallel execution process, only when all tasks executed in parallel are finished, a parallel type parallel execution in which the subsequent processing proceeds and a split type parallel execution in which all the tasks executed in parallel do not finish are executed. The computer software system design support apparatus according to claim 18, further comprising: