JP2011154521A - Model-based performance prediction system - Google Patents

Model-based performance prediction system Download PDF

Info

Publication number
JP2011154521A
JP2011154521A JP2010015371A JP2010015371A JP2011154521A JP 2011154521 A JP2011154521 A JP 2011154521A JP 2010015371 A JP2010015371 A JP 2010015371A JP 2010015371 A JP2010015371 A JP 2010015371A JP 2011154521 A JP2011154521 A JP 2011154521A
Authority
JP
Japan
Prior art keywords
delay
storage unit
task
information
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2010015371A
Other languages
Japanese (ja)
Other versions
JP5412305B2 (en
Inventor
Akihiko Hyodo
章彦 兵頭
Original Assignee
Hitachi Advanced Digital Inc
株式会社日立アドバンストデジタル
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Advanced Digital Inc, 株式会社日立アドバンストデジタル filed Critical Hitachi Advanced Digital Inc
Priority to JP2010015371A priority Critical patent/JP5412305B2/en
Publication of JP2011154521A publication Critical patent/JP2011154521A/en
Application granted granted Critical
Publication of JP5412305B2 publication Critical patent/JP5412305B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02TCLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00Road transport of goods or passengers
    • Y02T10/80Technologies aiming to reduce greenhouse gasses emissions common to all road transportation technologies
    • Y02T10/82Elements for improving aerodynamics

Abstract

<P>PROBLEM TO BE SOLVED: To verify a temporal element such as a real time property in an upstream stage of a design, in development of a built-in system. <P>SOLUTION: This model-based performance prediction system includes: a design model storage part including a basic block database that is a set of element arithmetic blocks each having a function and delay at least as an attribute, and storing a model developed by use of the database of basic blocks; a task definition storage part wherein a combination configuration of the basic blocks, and execution priority or the like are defined about all tasks included in the model comprising one or more combinations between the basic blocks; a resource information storage part storing information about a mounted resource such as a CPU or a ROM/RAM; and a deadline storage part storing deadlines of a part of the tasks or all the tasks. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a model-based performance prediction system, and more particularly to a model-based performance prediction system capable of verifying real-time characteristics in consideration of implementation at an upstream design stage in software development of an embedded system.

  The scale of embedded system software is increasing year by year, and it is becoming difficult for existing program development to meet requirements such as development period and design quality. Under such circumstances, model-based development methods for describing specifications and designing functions using models have been widely used mainly in the automobile field.

  Model base refers to the design of a target function by combining blocks with basic functions defined using a control system modeling tool represented by Simulink (registered trademark). It is now possible to easily develop functions using models without writing program source code. Furthermore, technology for automatically generating a program from a designed function model has also made great progress in recent years and has begun to become popular. The designer combines and compiles these automatically generated programs and mounts them on a specific microcomputer.

  Japanese Patent Application Laid-Open No. 2005-228561 discloses an estimation device that can estimate the amount of microcomputer resource consumed when a program represented by a model is mounted on a microcomputer in model-based development.

  Japanese Patent Application Laid-Open No. H10-228667 discloses a time definition introduced for state transition in specification design. That is, there is a program development device that stores time information corresponding to each cell of the state transition table, accumulates processing time at the time of system simulation execution based on the information, and obtains processing time when simulating system operation. It is disclosed.

Japanese Patent Laying-Open No. 2005-078343 JP 2000-20347 A

  For example, in a field with severe cost restrictions such as an in-vehicle system, it is often the case that mounting on a microcomputer is restricted by resources such as CPU performance, ROM / RAM capacity, and communication speed.

  For this reason, it is often found that a model that has passed functional verification in the upstream process cannot satisfy the constraints given at the implementation stage. For example, if the resource usage is unexpectedly large, it is necessary to return to the function design stage and review the design significantly. Or, a large specification change is required, such as changing to a more expensive and higher performance microcomputer than expected. In general, the implementation design of embedded systems can be labor intensive, and we want to avoid such rework as much as possible. This is becoming a serious problem for software development with increasing complexity.

  Focusing on this point, in the invention of Patent Document 1, the consumption of the CPU and ROM / RAM is estimated in the design upstream process to prevent the development from being reworked. In this example, at the system design stage, the microcomputer resource consumption estimation program calculates the microcomputer resource consumption estimation amount of the object code generated from the model based on the information of the microcomputer resource consumption estimation amount of each component block of the model. To do.

  However, this method can estimate the average CPU processing load, but cannot solve the problem of peak load and real-time property. That is, the invention of Patent Document 1 relates to estimation of consumption of microcomputer resources for which development of a program has been completed, and estimates delay in a mounted state in which a plurality of programs in the development stage are operated on an actual device. There is nothing to do. In such an embedded system delay estimation including software, in addition to information on the delay time of each process in the mounted state, the timing of each interrupt occurrence and the execution priority of each task (a group of processes) For example, it is necessary to consider the interrelation between the processes.

  As described above, the implementation failure includes, for example, an erroneous output of the control value due to the fact that the processing is not completed within the restricted time while satisfying the functional requirement, and this is referred to as real-time processing.

  On the other hand, the program development device disclosed in Patent Document 2 sequentially processes the processing time of the actions described in each cell of the state transition table according to the sequentially input event and the transition destination state described in each cell. The operation of the system can be simulated by accumulating time information corresponding to the specified cell. The program development device of Patent Document 2 described above creates and compiles a source program written in a programming language in order to reflect time elements in the implementation stage for time information corresponding to each cell preset by the user, A method of preparing object code as a specific implementation form and calculating time information from the execution time is disclosed.

  However, in the functional design of a large-scale embedded system based on the model-based development method, it takes a development man-hour close to the implementation design stage to implement the method disclosed in Patent Document 2 above, and the man-hour burden is reduced. There is a great potential for increase.

  Also, in terms of real-time verification, when multiple processes are started at the same time, it is not a means of verifying the impact of each process's priority on the execution delay of the entire model. As left.

  SUMMARY OF THE INVENTION In view of the above-mentioned problems of the prior art, an object of the present invention is to provide a model-based performance prediction system capable of estimating a delay in the design upstream stage and verifying real-time characteristics in the development of an embedded system including software. And

  An example of a representative one of the present invention is as follows. The model-based performance prediction system of the present invention includes a basic block database, a design model / task definition related database, and a mounting state simulation unit. The mounting state simulation unit includes a model analysis unit and a mounting delay calculation unit. The basic block database includes a basic function storage unit that stores functions of a plurality of basic blocks, and a mounting delay element storage unit that stores information on mounting delays of elements of the basic blocks corresponding to the functions. The database related to the design model / task definition includes a design model storage unit for storing a design model created by combining the basic blocks, and a combination of the basic blocks for tasks included in the design model. Task definition storage unit that stores task definitions such as configuration and execution priority A resource information storage unit for storing resource information, wherein the mounting state simulation unit analyzes the design model based on the task definition, and implements delays in mounting the resource information and the elements of the basic blocks. Based on the above information, the design model is expected to be installed in an actual device and operated, and the operation delay of the design model is calculated as an implementation delay, and the result is output. To do.

  According to the present invention, at the upstream design stage, delay estimation and real-time performance, which are major issues at the time of mounting, can be predicted, and these problems can be solved at an early stage, so it is possible to reduce the burden on downstream processes with large man-hours. In addition, rework due to mounting defects can be suppressed. This is inevitable for systems with a large software scale.

1 is a block diagram illustrating a configuration example of a performance prediction system according to a first embodiment of the present invention. It is explanatory drawing which shows an example of the calculation block of a basic block database in the performance prediction system which concerns on the said 1st Embodiment. It is explanatory drawing of the element calculation referred in the mounted delay element memory | storage part which the basic block database comprises in the performance prediction system which concerns on the said 1st Embodiment. It is the block diagram which showed an example of the design model which concerns on the said 1st Embodiment. It is a table which shows the example of the basic block which comprises each function of the slip control system shown in FIG. 4, and those calculation elements. It is explanatory drawing which showed an example of the task definition memory | storage part in the performance prediction system which concerns on the said 1st Embodiment. It is explanatory drawing which showed an example of the resource information storage part with which the performance prediction system which concerns on the said 1st Embodiment comprises. It is the block diagram which showed the other example of the design model which concerns on the said 1st Embodiment. It is explanatory drawing regarding the communication block which a basic block database comprises in the performance prediction system which concerns on the said 1st Embodiment. It is a processing flow figure of the model analysis part in the performance prediction system concerning the 1st embodiment of the above. It is a pre-processing flowchart of the mounting delay calculation part in the performance prediction system which concerns on the said 1st Embodiment. It is a mounting delay calculation processing flowchart of the performance prediction system according to the first embodiment. It is explanatory drawing which showed an example of the task definition of the performance prediction system which concerns on the said 1st Embodiment. In the performance prediction system according to the first embodiment, it is an explanatory diagram showing an output result in the case of the task definition. It is explanatory drawing which showed an example at the time of changing a priority in the task definition of the performance prediction system which concerns on the said 1st Embodiment. In the performance prediction system according to the first embodiment, it is an explanatory diagram showing an output result in the case of the task definition. In the performance prediction system according to the first embodiment, it is a flowchart showing the implementation task delay calculation processing of the periodic task. It is explanatory drawing which showed an example at the time of defining the periodic task in the performance prediction system which concerns on the said 1st Embodiment. In the performance prediction system according to the first embodiment, it is an explanatory diagram showing an output result in the case of the task definition. It is a block diagram of a configuration example of a performance prediction system according to a second embodiment of the present invention. It is explanatory drawing of the signal input / output timing in the real-time simulation apparatus of the performance prediction system which concerns on 2nd Embodiment of this invention.

  According to an exemplary embodiment of the present invention, a model-based performance prediction system includes a basic block database, a design model / task definition related database, and a mounting state simulation unit. The mounting state simulation unit includes a mounting delay calculation unit and a real-time property determination unit. The basic block database includes a basic function storage unit that stores the functions of a plurality of basic blocks, and a mounting delay element storage unit that stores mounting delays of elements of each basic block corresponding to the functions. The model designer creates a model (software) having functions necessary for a model such as an embedded system by combining the above basic blocks, and stores the model (software) in a design model storage unit of a design model / task definition related database. Store it in. The implementation delay calculation unit takes into account resource constraints, processing priority setting information, etc., and uses the implementation delay time for each element, which causes a problem in the implementation stage of the developed software (design model). Obtain the implementation delay time that reflects the elements.

  In the present invention, the mounting delay means a delay in the operation of the design model that is expected in a state where it is assumed that the design model is incorporated into an actual device and operated.

  Further, the real-time property determination unit determines whether or not real-time processing is possible by comparing the obtained delay time of the design model with the set deadline. This makes it possible to perform model-based performance prediction for the design model under development at any stage and reflect the result in subsequent development.

The present invention can be widely applied to the development of various control systems equipped with computers, such as various control systems, digital televisions, hard disk devices, ATMs, robots, trains, etc., and built-in devices.
Hereinafter, embodiments of the present invention will be described with reference to the drawings.

A model-based performance prediction system according to a first embodiment of the present invention will be described with reference to FIGS.
FIG. 1 shows the overall configuration of a model-based performance prediction system. The model-based performance prediction system according to the first embodiment of the present invention includes a design model / task definition input device 100, a mounting state simulation unit 110, a basic block database, and a design model / task definition related database. ing. As a basic block database-related storage device, basic processing function information that is a set of element operation blocks having at least the functions and delays of a plurality of basic blocks as attributes is stored. Here, it is assumed that a basic function storage unit 101 that stores the functions of the basic block and a mounting delay element storage unit 102 that stores the mounting delay of each component of each basic block corresponding to those functions are provided.

  As a design model / task definition related database, the model designer designs software that satisfies the functions required for an embedded system by combining the basic blocks of the basic block database in the design model storage unit 103. Store what was created as a model. The task definition storage unit 103 stores task definitions such as basic block combination configurations and execution priorities for all tasks included in the design model including a combination of one or more basic blocks. The resource information storage unit 106 stores information on mounting resources such as a CPU and ROM / RAM. In addition, the deadline storage unit 106 stores information on deadlines of some or all tasks.

  In the design model / task definition input device 100, a designer inputs a design model developed using data in the basic processing function storage unit 101, for example, a design model of an embedded system, a task definition, a deadline, and the like. These are stored in the design model storage unit 102, the task definition storage unit 103, and the deadline storage unit 104, respectively. In addition, the designer inputs information related to the relationship between the task definition and the implemented resource, and the information is recorded in the resource information storage unit 106.

  The mounting state simulation unit 110 includes a model analysis unit 111, a mounting delay calculation unit 112, and a real-time property determination unit 113. The output of the mounting state simulation unit 110 is stored in the model delay storage unit 114 and further displayed on the display unit 115.

  The design model input from the design model / task definition input device 100 is associated with the task definition information in the task definition storage unit 104 in the model analysis unit 111 of the mounting state simulation unit 110, and the execution priority, deadline, etc. Corresponding to each block configuration. Then, the mounting delay calculation unit 112 refers to the delay information in the mounting delay element storage unit 102 of the basic block database and the resource information storage unit 105, and calculates the actual delay time for each block. If the implementation delay time of each block is obtained, the implementation delay time of the task can be calculated. The model-based performance prediction system is configured by connecting a plurality of computers via a network or further connecting a server, for example.

  Here, for example, an FIR filter often used in signal processing is taken up as an example of the basic block. The FIR filter is expressed by the following formula.

y [n] = h [0] · x [n] + h [1] · x [n-1] +… + h [N-1] · x [n-N + 1] (Formula 1)
Here, the filter coefficient h [i] and the filter tap length N. From the above equation, it can be seen that this is a combination of N multiplications and N additions. Therefore, by defining the clock cycles required for multiplication and addition, the total number of computation cycles can be estimated. In the present invention, a method of defining a CPU execution cycle is employed for the element operations such as multiplication and addition as described above.

  Alternatively, a method may be considered in which the basic blocks are implemented by programs, the execution time is evaluated using a microcomputer simulator or an actual microcomputer, and the information is registered in a table. This method takes time to create the first data, but once the database is constructed, it is possible to take into account the detailed execution delay of the basic block. However, there is a problem that only a delay depending on a specific implementation can be obtained.

  In general, the instruction set of a commercial microcomputer is not so different in the types of low-level operations such as addition / subtraction, logical operation, comparison operation, and multiplication. For example, a RISC system is generally used for a microcomputer used in an embedded system. RISC is an abbreviation for Reduced Instruction Set Computer, which is a kind of computer architecture. This is a technique for reducing the types of instructions and simplifying the circuit to improve the operation speed. In the RISC system, all operations are basically executed in one clock cycle, and the program is executed only with the minimum necessary simple instructions.

  Considering this, the basic block is described by a combination of the above element operations, and the number of cycles required to execute the element operations is included in the resource information storage unit 105 by setting an average value. The actual delay can be easily calculated according to the CPU operating speed information. That is, model-based performance prediction can be easily performed.

Next, the real-time property is evaluated.
Here, regarding the evaluation of real-time characteristics, taking into account the interrelationship between operations in addition to how to accurately estimate the execution delay of each operation may have a significant effect. In this case, it is necessary to take into consideration the task execution priority and the timing of interrupt processing.

  In order to realize this, a deadline storage unit 106 is provided in addition to the task definition storage unit 104, the model analysis unit 111 associates with a design model, and the implementation delay calculation unit 112 simulates an execution schedule. By doing so, the delay of the design model is calculated. Then, the obtained delay time of the design model and a preset deadline are compared in the real-time property determination unit 113 to determine whether real-time processing is possible.

  Here, FIG. 2 shows an example (101 </ b> A) of the delay definition of each basic block stored in the basic processing function storage unit 101 of the basic block database 101. Examples of basic operations often used in signal processing include FIR (finite impulse response), DFT (discrete Fourier transform), and FFT (fast Fourier transform). The delay can be calculated using the processing cycle defined for each element operation such as addition or multiplication, using the number of data points as a parameter, and the mathematical formula described in the cycle column of FIG.

  FIG. 3 shows an example (102A) of the definition of the element calculation stored in the mounting delay element storage unit 102. For example, one cycle for addition (ADD), two cycles for multiplication (MUL), etc., the number of CPU cycles required for processing, in other words, a delay element is defined. From this delay element information, for example, in the case of the 1024-point FFT in FIG. 2, it can be calculated that the delay is 30,720 cycles by substituting n = 1024, M = 2, and A = 1. In addition to the elements shown in FIG. 3, the delay element may be appropriately added depending on the application, for example, data read / write (read, write) is set to one cycle each.

  When the CPU execution cycle calculated by the above method is determined with reference to the resource information storage unit 105 in FIG. 1 and the mounted CPU type is determined, the corresponding mounting delay time can be obtained.

  Next, as a specific model of the embedded system, a vehicle slip control system as shown in FIG. 4 is shown as an application example. In the example of FIG. 4, the slip control system is configured by one microcomputer 200, and has a wheel speed (IN 1), a vehicle body speed (IN 2), and a pedal position (IN 3) as inputs, and calculates a basic torque command value (TB ) Function 204, slip ratio calculation (SR) function 202, torque correction value calculation (TC) function 203, torque basic command value and correction value addition (AD) function 205, and finally, Torque command value (OUT1) is output. Similarly, the function 206 of the task (DN) for performing fault diagnosis based on each sensor input (IN1 to IN3) also operates and outputs a diagnosis result (OUT2).

FIG. 5 shows, as a table 104A, an example of basic blocks that constitute each function of the slip control system shown in FIG. 4 and their calculation elements. For example, the slip ratio calculation (SR) function (basic block) includes one ADD and two MULs as calculation elements. FIG. 6 shows an example of task definition (104B) corresponding to the above model. Here, a priority is defined for each task ID, and a deadline is also defined for a task in the output portion.

  Next, FIG. 7 shows a part (105A) of the resource information storage unit 105. In the example of FIG. 7, the CPU of Type 1 is defined to have an operation clock of 100 MHz and an IPC (number of executed instructions per cycle) of 1. For the 1024-point FFT, divide 30,720 cycles by 100 MHz, It can be calculated as 307.2 microseconds. Further, for example, in a Type 3 CPU, 30,720 cycles are divided by 1 GHz, and further, since two instructions can be processed in one cycle, it is divided by ÷ 2. As a result, it is proved that it can be executed in 15.72 microseconds.

  Here, the basic processing function database of the basic block can include not only computation but also communication information. For example, a slip control system for a vehicle as shown in FIG. 8 is shown as an application example. In the example of FIG. 8, the slip control system includes two microcomputers 200 and 201, and the two microcomputers are connected via a communication path. In this example, the microcomputer 201 executes the functions 202 to 205, and the microcomputer 201 executes a task (DN) function 206 for fault diagnosis.

  FIG. 9 shows an example (101B) of basic communication block definitions in the example of FIG. For example, in the protocol-1 communication method, three blocks with block IDs 1, 2, and 4 are connected, and data flowing between the blocks has a communication delay determined from the baud rate setting. If a plurality of data flows through the same communication path, it is possible to determine the priority of the communication packet and calculate the communication delay considering it.

  Next, a configuration for calculating the delay of the entire model combining the above basic blocks will be described.

  The simulation unit 110 shown in FIG. 1 includes a model analysis unit 111, a mounting delay calculation unit 112, and a real time determination unit 113. First, the designer needs to define a task for any combination of blocks in the model using the design model / task definition input device 100. The design model storage unit 103 defines task IDs, execution priorities, and the like. The model analysis unit 111 analyzes the model based on information in the task definition storage unit. That is, the model is read from the design model storage unit 103, the task information is read from the task definition storage unit 104, and the task definition information is added to the corresponding block portion in the model.

  The specific processing flow of the model analysis unit 111 is shown in the flowchart of FIG. When the model analysis is started, first, the model is read from the design model storage unit 102 (P901), and then information such as task ID, priority, deadline, etc. is received from the task definition storage unit 104 or the deadline storage unit 106. Read (P902). Then, based on each read task ID, a corresponding block combination in the model is searched (P903). All task IDs and block combinations are associated (P904), and if a task ID that cannot be associated remains, a warning message is output (P905). If it does not remain, it is checked whether there is a block having no correspondence with the task ID (P906), and if there is, a warning message is output (P907). The above is the flow of model analysis.

Next, a processing flow of the mounting delay calculation unit 112 will be described with reference to FIGS. 11 and 12. The processing of the mounting delay calculation unit 112 includes preprocessing for mounting delay calculation and processing for mounting delay calculation.
FIG. 11 shows the flow of pre-processing for mounting delay calculation. First, each task includes the relationship between the block in the model and the task definition, which has been analyzed by the model analysis unit 111. All basic blocks (see table 104A in FIG. 5) are listed (P1101).

  For calculation of the basic block cycle, necessary parameters such as the amount of input data are obtained by referring to the preset data in the mounting delay element storage unit 102 (P1102).

  Next, for each task, the included basic delay is accumulated and the total cycle is calculated (P1103). Based on the CPU information stored in the resource information storage unit 105, the actual delay time of each task is calculated by the method described above. The above is the flow of pre-processing for mounting delay calculation.

  Next, the flow of processing for mounting delay calculation will be described with reference to FIG. First, when the implementation delay calculation is started, the simulation time is initialized to 0 (P1201), and a task that can be executed at the simulation time is placed in the ready queue (P1202). If there is no task in the ready queue, the unit delay ΔT (= 1 unit time) is added to the simulation time and updated (P1210). If there is a task in the ready queue, the task with the highest priority is selected and deleted from the ready queue (P1204). Thereafter, the task delay time is added to the simulation time and updated (P1205). At this time, the presence or absence of a newly activated task is checked, and if it is activated, it is placed in the ready queue (P1206). At this time, if a task still exists in the ready queue, the process returns to P1202. If there is no task in the ready queue, it is confirmed whether or not all tasks have been executed (P1208). If all the tasks have not been completed yet, the process returns to P1210. If completed, the current simulation time is output as a delay required to execute the model and stored in the model delay storage unit 114 (P1209). The above is the flow of mounting delay calculation.

  FIG. 13 is an example of a task definition corresponding to the model of FIG. 4 and also shows the delay calculation result when the preprocessing of the mounting delay calculation (FIG. 12) is performed.

  FIG. 14 is a timing chart obtained by performing the mounting delay calculation described in FIG. 12 using the delay time of each task described above. The horizontal axis represents time, with 10 unit times per memory. In the vertical direction, the execution statuses of five tasks are displayed side by side. In FIG. 14, the upward arrow indicates the time when the task can be executed, the hatched rectangular portion indicates the implementation delay that is the cumulative result of the unit delay ΔT, and the downward arrow indicates the deadline time. . From the display result, it can be verified that the implementation delay or deadline of all tasks is satisfied in the priority setting of FIG. 13 and real-time processing is possible.

  Here, FIG. 15 shows an example in which the designer creates a new task definition in which the priorities of the task AD and the task DN are reversed, for example, among the task priority settings. When the model delay time is calculated under the new task definition conditions, the timing chart of FIG. 16 is obtained.

  According to this, when the task definition is changed and the task AD for adding the torque basic command value and the correction value is executed after the failure diagnosis task (DN), the task AD is not in time for processing within the deadline. I can confirm. That is, it can be seen that the real-time property of the model is greatly influenced by the priority setting of each task. By developing and designing based on these points, it is possible to efficiently develop a model of an embedded system.

  In the above example, as a basic pattern, an example of a task that is activated only once is described, and a plurality of activations and periodic activations are not assumed. However, many periodic tasks are executed in a general control system.

  Next, a practical pattern implementation delay calculation flow including a task activated by an event such as a periodic task or an interrupt will be described with reference to FIG.

  First, since the periodic task is activated endlessly, it is necessary to set a simulation end time (P1701). Next, the simulation time is initialized to 0 (P1702), and tasks that are ready to be executed at the simulation time are put into the ready queue (P1703). At this time, if there is no task in the ready queue, the unit delay ΔT is added to the simulation time (P1705). At this time, it is determined whether or not the simulation end time has been reached (P1706). If the end time, the simulation is stopped. If not, the process returns to P1703. If there is a task in the ready queue, the task with the highest priority is selected, and the task is deleted from the ready queue (P1707).

  If the remaining time for processing the task is not set (P1708), the remaining time is set as delay time (P1709). The remaining processing time decreases as the execution time increases. However, in a so-called preemption state in which a high priority task is activated during execution and the processing is interrupted, the remaining time does not decrease during that period. If the remaining processing time has already been set, the unit delay ΔT is added to the simulation time (P1710). Thereafter, it is determined whether or not the simulation end time has been reached (P1711). If it is the end time, the simulation is stopped. If not, the unit delay is subtracted from the remaining execution time (P1712). It is determined whether the task has been executed, that is, the remaining time is 0 (P1713). If the task has been executed, the process returns to P1703.

  If the execution has not ended, the presence or absence of a new activated task is determined (P1714). If there is no activation, the process returns to P1710, and if there is activation, the priority is compared with the task being executed (P1715). If the priority is higher than the task being executed, the task being executed is returned to the ready queue, and the process returns to P1704. If the priority is lower than the task being executed, the process returns to P1710. The above is the flow of mounting delay calculation including periodic tasks.

  Here, the case where the process is composed of a plurality of periodic tasks will be described using the above-described model (FIG. 4) as an example. The task definition is shown in FIG. The task DN is a periodic task of 200 unit time, and the other is a periodic task of 100 unit time.

  FIG. 19 shows a timing chart of each task when the above-described mounting delay calculation flow (FIG. 17) is executed under the above conditions. The execution state of each task is shown in the same notation as in FIG. According to this, all the tasks are within the deadline (starting cycle), and the real-time processing can be verified. On the other hand, as in the example shown in FIG. 15, in the case of a new task definition in which the priorities of the task AD and the task DN are reversed, the task AD cannot be processed within the deadline as in the example of FIG. Was confirmed. By developing and designing based on these points, it is possible to efficiently develop a model of an embedded system.

  According to this embodiment, in the upstream design stage, it is possible to quickly solve the delay estimation and the real-time problem, which are the main issues at the time of mounting, so it is possible to reduce the burden on the downstream process with a large man-hour, Rework due to mounting defects can be suppressed. This is particularly effective for systems with a large software scale.

  A performance prediction system according to the second embodiment of the present invention will be described with reference to FIGS.

  FIG. 20 shows a configuration of a performance prediction system according to the second exemplary embodiment of the present invention. This includes all the components of the performance prediction system shown in FIG. 1, but as a difference from the first embodiment, a real-time simulation device 130 and a control target (actual machine) 140 are added.

  The real-time simulation apparatus 130 is based on the calculation execution unit 131 that executes a program generated from the design model stored in the design model storage unit 103 and the mounting delay information of the model stored in the model delay storage unit 114. Implementation delay is controlled by delaying output propagation by the implementation delay time specified by the implementation delay command unit 132 with respect to the output of the implementation delay command unit 132 that issues an instruction for occurrence of implementation delay and the calculation execution unit 131. And a signal input / output unit 134 that performs input / output using a signal from the mounting delay control unit as an output signal to the control target 140 of the actual machine.

  FIG. 21 shows calculation time and signal output timing for (a) an embedded system (real machine) to be developed, (b) a rapid prototype system (simulation) of the prior art, and (c) the real-time simulation apparatus (simulation). Is illustrated.

  The horizontal axis represents time, and T in the figure represents the activation period of the periodic task. The diamond points indicate the time when the output process is performed.

  From FIG. 21, it can be seen that in (a), the calculation is completed and the result is output in a time of 0.8T. The task is activated with a period T. (B) shows the simulation system of (a) when a general-purpose rapid proto controller used in model-based development is used. (C) is a simulation system of (a) by the real-time simulation apparatus. Here, the calculation performance of (b) and (c) is the same. It can be confirmed that these differences are signal output timings.

  Since the rapid proto controller normally outputs the calculation result of the previous cycle every set control cycle (T, 2T,-), the output timing (0.8T, 1.8T, 2.8T,- ) And the result output timing will shift. On the other hand, the real-time simulation apparatus 130 has a function of generating the mounting delay in real time based on the mounting delay information of the model. , 0.8T, T, 1.8T, 2T, −).

  This feature is advantageous in a system in which the signal output timing has a considerable influence on the operation to be controlled.

100 Design model / task definition input device,
101 Basic function storage unit,
102 implementation delay element storage,
103 design model storage unit,
104 deadline storage unit,
105 Resource information storage unit,
106 deadline storage unit,
110 Mounting state simulation unit,
111 Model Analysis Department,
112 Implementation delay calculator,
113 Real-time determination unit,
114 model delay storage unit,
115 display, FIR finite impulse response,
DFT discrete Fourier transform,
FFT fast Fourier transform,
ADD addition,
MUL multiplication,
CMP comparison operation,
LOG logic operation,
CPU central processing unit,
IPC Number of instructions executed per cycle.

Claims (20)

  1. It has a basic block database, a design model / task definition related database, and an implementation state simulation unit.
    The mounting state simulation unit has a model analysis unit and a mounting delay calculation unit,
    The basic block database is
    A basic function storage unit for storing functions of a plurality of basic blocks;
    An implementation delay element storage unit that stores information of implementation delay of each basic block element corresponding to each of the above functions;
    The database related to the above design model and task definition is
    A design model storage unit for storing a design model created by combining the above basic blocks;
    For the tasks included in the design model, a task definition storage unit that stores task definitions such as the combination configuration and execution priority of the basic blocks,
    A resource information storage unit for storing resource information;
    The mounting state simulation unit analyzes the design model based on the task definition, and incorporates the design model into an actual device based on the resource information and the mounting delay information of each basic block element. A model-based performance prediction system characterized by calculating an operation delay of the design model, which is expected in a state assumed to be performed, and outputting the result as delay information.
  2. In claim 1,
    The database related to the design model / task definition has a deadline storage unit for storing information on the set deadline,
    The mounting state simulation unit compares a delay time of the design model obtained by the mounting delay calculation unit with the set deadline to determine whether or not the real time processing of the design model can be performed. A model-based performance prediction system characterized by comprising
  3. In claim 1,
    Elements for realizing the processing functions of the basic block include at least elements of addition processing and multiplication processing,
    In the task definition storage unit,
    A function is defined by a combination of operations of the above elements constituting the basic block, and
    A model-based performance prediction system, wherein mathematical formulas for calculating delays of the basic blocks are stored from delay information of the element operations defined in advance in the mounting delay element storage unit.
  4. In claim 1,
    The model-based performance prediction system, wherein the task definition storage unit stores any or all of a task identifier, an execution priority, and a deadline.
  5. In claim 1,
    The resource information storage unit stores either or all of an operation clock of a CPU and a processing amount per clock cycle.
  6. In claim 1,
    The basic block database includes a communication function in a basic block,
    The basic block has multiple communication methods and multiple communication speed options in the implementation delay element storage unit,
    The model-based performance prediction system, wherein the mounting state simulation unit calculates a communication delay of the model from a combination of the communication method and the communication speed.
  7. In claim 6,
    The design model has a configuration in which a plurality of blocks are connected to a communication path by a basic block of the communication function, and when a plurality of communication data is generated on the communication path, the communication is performed according to a predetermined priority. A model-based performance prediction system having a function of processing
  8. In claim 1,
    A model delay storage unit for storing the delay information;
    A model-based performance prediction system, further comprising: a display unit that displays information related to the mounting delay based on information in the model delay storage unit.
  9. In claim 4,
    The model analysis unit
    The design model is read from the design model storage unit, information such as task ID, priority, and deadline is read from the task definition storage unit. Based on the read task IDs, all task IDs and the blocks A model-based performance prediction system characterized by associating combinations.
  10. In claim 9,
    The implementation delay calculator above
    As preprocessing, the basic blocks included in each task are listed based on the relationship between the block in the model analyzed by the design model analysis unit and the task definition, and the basic delay included in each task is listed. A model-based performance prediction system having a function of accumulating, calculating a total cycle, and calculating an actual delay time of each task based on information in the resource information storage unit.
  11. In claim 9,
    The implementation delay calculation unit initializes a simulation time, puts a task that can be executed at the simulation time into a ready queue, and adds and updates a unit delay ΔT to the simulation time when there is no task in the ready queue, If there are tasks in the ready queue, select the task with the highest priority among them, delete it from the ready queue, add the delay time of the task to the simulation time, update it, and all tasks are finished A model-based performance prediction system characterized in that the current simulation time is output as delay information required for execution of the design model.
  12. A mounting state simulation unit, a basic block database, and a database related to design models and task definitions,
    The basic block database is
    A basic function storage unit for storing a plurality of basic blocks having at least attributes of a basic function and an implementation delay;
    An implementation delay element storage unit that stores information of implementation delay of each basic block element corresponding to each of the above functions;
    The database related to the above design model and task definition is
    A design model storage unit for storing a model designed using the basic block;
    A task definition storage unit in which task information that is a set of basic blocks included in the design model is defined;
    A resource information storage unit for storing resource information including a CPU and a memory for implementing the function of the design model,
    The mounting state simulation unit is
    A model analysis unit for analyzing the design model based on the information in the task definition storage unit;
    A model-based performance prediction comprising: the basic function storage unit; and an implementation delay calculation unit that calculates an implementation delay of the design model based on information in the task definition storage unit and the resource information storage unit system.
  13. In claim 12,
    The basic function storage unit stores a design model of an embedded system generated by combining the plurality of basic blocks,
    The task definition storage unit stores the task information that gives a processing condition to each processing function of the basic block included in the design model,
    The resource information storage unit stores information on the resources including a CPU and a memory that implement the functions of the design model,
    The mounting state simulation unit is
    Using the task information, the resource information, and the information about the mounting delay for each element of the basic block of the design model, the operation delay of the design model is predicted when the design model is mounted on the embedded system. A model-based performance prediction system characterized by calculating a value and outputting the result as delay information.
  14. In claim 12,
    An input device for inputting at least one of the design model and the task definition;
    A model-based performance prediction system, further comprising a display unit for displaying information related to the mounting delay.
  15. In claim 12,
    The database related to the design model / task definition has a deadline storage unit for storing information on the set deadline,
    The mounting state simulation unit compares a delay time of the design model obtained by the mounting delay calculation unit with the set deadline to determine whether or not the real time processing of the design model can be performed. A model-based performance prediction system characterized by comprising
  16. In claim 12,
    In the basic function storage unit, a function is defined by a combination of element operations such as addition and multiplication, and a mathematical formula that can calculate the delay of the basic block from the delay information of the element operation defined in advance is stored. A model-based performance prediction system characterized by
  17. In claim 12,
    The resource information storage unit stores either or all of an operation clock of the CPU and a processing amount per clock cycle.
  18. In claim 12,
    The basic block database includes a communication function in a basic block,
    The basic block has multiple communication methods and multiple communication speed options in the implementation delay element storage unit,
    The model-based performance prediction system, wherein the mounting state simulation unit calculates a communication delay of the model from a combination of the communication method and the communication speed.
  19. A mounting state simulation unit, a real-time simulation device, a database, and an automatic code generation and mounting unit for generating a program from a given model;
    The database is
    A basic block database for storing a plurality of basic blocks having at least attributes of function and delay;
    A design model storage unit for storing a model designed using the basic block;
    A task definition storage unit in which task information that is a set of basic blocks included in the model is defined;
    A resource information storage unit for storing resource information including a CPU and a memory for implementing the function of the model,
    The mounting state simulation unit is
    A model analysis unit for analyzing the model based on the information in the task definition storage unit;
    Based on the information of the basic block database and the resource information storage unit, an implementation delay calculation unit that calculates the delay of the model,
    A model delay storage unit that stores delay information of the model calculated by the mounting delay calculation unit,
    The real-time simulation device is
    An operation execution unit for executing the generated program in real time;
    Based on the information of the model delay storage unit, a delay command unit that issues a delay time command,
    A delay control unit for generating the delay based on delay information of the delay command unit;
    A model-based performance prediction system, comprising: a signal input / output unit that outputs a signal of the delay control unit to an actual control target.
  20. In claim 19,
    The basic block has a function defined by a combination of element operations such as addition and multiplication, and stores a mathematical expression that can calculate the delay of the basic block from the delay information of the element operation defined in advance. Model-based performance prediction system characterized by
JP2010015371A 2010-01-27 2010-01-27 Model-based performance prediction system Active JP5412305B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010015371A JP5412305B2 (en) 2010-01-27 2010-01-27 Model-based performance prediction system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010015371A JP5412305B2 (en) 2010-01-27 2010-01-27 Model-based performance prediction system

Publications (2)

Publication Number Publication Date
JP2011154521A true JP2011154521A (en) 2011-08-11
JP5412305B2 JP5412305B2 (en) 2014-02-12

Family

ID=44540436

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010015371A Active JP5412305B2 (en) 2010-01-27 2010-01-27 Model-based performance prediction system

Country Status (1)

Country Link
JP (1) JP5412305B2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101332499B1 (en) 2011-10-12 2013-11-26 후지쯔 가부시끼가이샤 Simulation apparatus, simulation method, and recording medium
US10372422B2 (en) 2015-04-28 2019-08-06 Rensas Electronics Corporation Performance verification device for verifying performance of program, method, and recording medium having program recorded thereon for causing computer to perform the method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003177943A (en) * 2001-12-07 2003-06-27 Fujitsu Ltd Method, device, and program for simulating roughly multitask software
JP2004530193A (en) * 2001-03-05 2004-09-30 ケイデンス デザイン システムズ,インコーポレイテッド Method and apparatus for statistical evaluation of execution time of embedded software
JP2005078243A (en) * 2003-08-29 2005-03-24 Denso Corp Microcomputer resource consumption estimating program, microcomputer resource consumption estimating device, and program generating method
JP2009217531A (en) * 2008-03-11 2009-09-24 Fujitsu Ltd Virtual software generator

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004530193A (en) * 2001-03-05 2004-09-30 ケイデンス デザイン システムズ,インコーポレイテッド Method and apparatus for statistical evaluation of execution time of embedded software
JP2003177943A (en) * 2001-12-07 2003-06-27 Fujitsu Ltd Method, device, and program for simulating roughly multitask software
JP2005078243A (en) * 2003-08-29 2005-03-24 Denso Corp Microcomputer resource consumption estimating program, microcomputer resource consumption estimating device, and program generating method
JP2009217531A (en) * 2008-03-11 2009-09-24 Fujitsu Ltd Virtual software generator

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CSNG200500190017; 北口 智, 谷本 匡亮, 中田 明夫, 東野 輝夫: 'Java言語による階層バス調停ポリシーを持つバスシステムのモデリング及びシミュレーション' 情報処理学会研究報告. SLDM, [システムLSI設計技術] 第2003巻/第120号, 20031127, 第169-174頁, 社団法人情報処理学会 *
JPN6013027940; 居駒 幹夫, 大場 みち子, 酒井 三四郎: 'シンプルかつ現実的なモデルベース・テストツールの提案' 情報処理学会研究報告. ソフトウェア工学研究会報告 第2009巻/第31号, 20090311, 第295-301頁, 一般社団法人情報処理学会 *
JPN6013027944; 北口 智, 谷本 匡亮, 中田 明夫, 東野 輝夫: 'Java言語による階層バス調停ポリシーを持つバスシステムのモデリング及びシミュレーション' 情報処理学会研究報告. SLDM, [システムLSI設計技術] 第2003巻/第120号, 20031127, 第169-174頁, 社団法人情報処理学会 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101332499B1 (en) 2011-10-12 2013-11-26 후지쯔 가부시끼가이샤 Simulation apparatus, simulation method, and recording medium
US10372422B2 (en) 2015-04-28 2019-08-06 Rensas Electronics Corporation Performance verification device for verifying performance of program, method, and recording medium having program recorded thereon for causing computer to perform the method

Also Published As

Publication number Publication date
JP5412305B2 (en) 2014-02-12

Similar Documents

Publication Publication Date Title
Gomes et al. Co-simulation: State of the art
Di Natale et al. Moving from federated to integrated architectures in automotive: The role of standards, methods and tools
Carara et al. HeMPS-a framework for NoC-based MPSoC generation
Wolf A decade of hardware/software codesign
Schruben Simulation modeling with event graphs
Davare et al. Period optimization for hard real-time distributed automotive systems
Yen et al. Hardware-software co-synthesis of distributed embedded systems
Wartel et al. Measurement-based probabilistic timing analysis: Lessons from an integrated-modular avionics case study
Henia et al. System level performance analysis–the SymTA/S approach
Yen et al. Communication synthesis for distributed embedded systems
Overstreet et al. A specification language to assist in analysis of discrete event simulation models
Eker et al. A Matlab toolbox for real-time and control systems co-design
US8904367B1 (en) Auto pipeline insertion
Yen et al. Performance estimation for real-time distributed embedded systems
US20070220292A1 (en) Estimating software power consumption
US8433554B2 (en) Predicting system performance and capacity using software module performance statistics
Di Natale et al. Synthesis of multitask implementations of simulink models with minimum delays
JP4975544B2 (en) Simulation apparatus and program
Schliecker et al. System level performance analysis for real-time automotive multicore and network architectures
Liu et al. A generic QoS framework for cloud workflow systems
US6059835A (en) Performance evaluation of processor operation using trace pre-processing
Zhu et al. Optimization of task allocation and priority assignment in hard real-time distributed systems
Potop-Butucaru et al. Integrated worst-case execution time estimation of multicore applications
Zhang et al. Dynamic adaptation for fault tolerance and power management in embedded real-time systems
CN102262586B (en) For the robotization error-detecting of software and the method for checking

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20120802

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20130530

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130611

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130807

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131015

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131111

R150 Certificate of patent or registration of utility model

Ref document number: 5412305

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350