WO2020017264A1 - シミュレーション装置、及びその方法、並びにｅｃｕ装置 - Google Patents

シミュレーション装置、及びその方法、並びにｅｃｕ装置 Download PDF

Info

Publication number
WO2020017264A1
WO2020017264A1 PCT/JP2019/025303 JP2019025303W WO2020017264A1 WO 2020017264 A1 WO2020017264 A1 WO 2020017264A1 JP 2019025303 W JP2019025303 W JP 2019025303W WO 2020017264 A1 WO2020017264 A1 WO 2020017264A1
Authority
WO
WIPO (PCT)
Prior art keywords
processing
function
ecu
timing
time
Prior art date
Application number
PCT/JP2019/025303
Other languages
English (en)
French (fr)
Inventor
康哲 村島
悠史 福島
成沢　文雄
Original Assignee
日立オートモティブシステムズ株式会社
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 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Priority to US16/973,315 priority Critical patent/US20210248288A1/en
Priority to DE112019002778.6T priority patent/DE112019002778T5/de
Priority to JP2020531204A priority patent/JP7045458B2/ja
Priority to CN201980031431.5A priority patent/CN112400162A/zh
Publication of WO2020017264A1 publication Critical patent/WO2020017264A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/15—Vehicle, aircraft or watercraft design
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2119/00—Details relating to the type or aim of the analysis or the optimisation
    • G06F2119/12—Timing analysis or timing optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/865—Monitoring of software

Definitions

  • the present invention relates to a simulation device having a function of adjusting execution timing, a method thereof, and an ECU device, for example, a simulation device used by a developer when developing software for an electronic control unit (ECU: Electronic Control Unit) of a vehicle, and
  • ECU Electronic Control Unit
  • the present invention relates to a method and an ECU device.
  • the specifications of the personal computer PC used for development often differ from developer to developer, and this may cause only the actual ECU and the specific PC to occur. Also occurs.
  • claim 2 of Patent Document 1 states that “simulation of a clock interrupt in which only the time when the simulation development environment actually uses the microprocessor unit of the development machine can be measured, There is a description.
  • Patent Document 1 Although the processing start timing due to the clock interrupt can be adjusted, the subsequent processing timing cannot be adjusted, resulting in a difference due to the HW performance.
  • the timing of updating variables shared between tasks may differ between the simulation environment and the real ECU environment.
  • a change in the timing of referring to the variable may cause a difference in the operation of the application software.
  • an object of the present invention is to provide a simulation device, a method thereof, and an ECU device that can make the execution timing of the PC simulation environment close to the actual ECU by a simple method.
  • the first performance measurement function for obtaining the first processing timing when the application software is executed on the first computer and the first processing timing and the second computer A first computer having a timing adjustment function for adjusting a timing of execution time of application software in the first computer based on a time difference between the second processing timings at the time of execution.
  • a first performance measuring function for obtaining a first processing timing when the application software is executed on the first computer, and a first processing timing and a time when the application software is executed on the second computer A first computer having a timing adjustment function for adjusting the execution time of the application software in the first computer based on the time difference between the second processing timings, and a processing timing when the application software is executed.
  • a second computer having a second performance measurement function to obtain the second processing timing as a second processing timing, and a communication device for connecting the first computer and the second computer. is there.
  • the first processing timing when the application software is executed on the first computer and the second processing timing when the application software is executed on the second computer are based on the time difference.
  • the execution timing in the PC simulation environment can be brought closer to the actual ECU. Since the timing can be adjusted for each PC, the amount of delay can be adjusted for each PC environment of the developer.
  • software can be verified in an environment close to the processing timing of the actual ECU even when the number of prototypes of the actual ECU under development is small, and the quality of the software can be ensured in a more upstream process. Can be contributed to.
  • FIG. 2 is a diagram showing a configuration example of a real ECU environment and a PC environment in the simulation device of the present invention.
  • FIG. 4 is a diagram showing a hardware configuration and a main processing function of a personal computer PC constituting a simulation device, particularly, a delay injection function Sw11.
  • FIG. 4 is a diagram illustrating a generation process up to creation of software to be ported to an ECU device using the simulation device.
  • FIG. 9 is a diagram showing processing related to the first stage of application development according to the second embodiment of the present invention. The figure which shows the example of the C language program used by this invention. The figure which shows the example of table setting of delay parameter file Fi3.
  • FIG. 4 is a diagram showing a hardware configuration and a main processing function of a personal computer PC constituting a simulation device, particularly, a delay injection function Sw11.
  • FIG. 4 is a diagram illustrating a generation process up to creation of software to be ported to an ECU device using the simulation device.
  • FIG. 9 is a diagram
  • FIG. 7 is a diagram illustrating an example of execution timings of a real ECU, a case where there is no timing adjustment, and a case where timing adjustment is performed in a simulator.
  • FIG. 9 is a diagram showing an example of timing when the processing speed of the ECU is faster than the processing speed of the personal computer.
  • FIG. 5 is a schematic flowchart showing processing contents in a personal computer PC and a real environment machine S executed for determining a delay amount and adjusting timing.
  • FIG. 5 is a diagram showing a time relationship before and after timing adjustment.
  • FIG. 7 is a diagram illustrating an example of a delay parameter table in an initial state before performance comparison.
  • 21 is a diagram illustrating a delay parameter table in which a delay amount for each child function is reflected in the delay parameter table in the initial state of FIG. 20;
  • the first embodiment mainly describes the hardware configuration of the simulation apparatus
  • the second to fifth embodiments use the PC simulation environment in order to bring the execution timing closer to the real ECU.
  • a delay amount for bringing the execution timing of the PC simulation environment closer to the real ECU is determined for each personal computer PC, and the delay amount is determined at a predetermined position during execution in the PC simulation environment. Adjusting the timing while executing the delay processing will be described.
  • FIG. 1 shows a configuration example of a real ECU environment and a PC environment in the simulation device of the present invention.
  • FIG. 1 shows a configuration example of a real environment machine S for realizing a real ECU environment
  • the left side shows a configuration example of a personal computer PC for realizing a PC environment.
  • the real environment machine S and a plurality of personal computers PC (PCa, PCb... PCn) are connected to the external system bus 181 via the communication device 180. Since the personal computer PC has basically the same configuration and function, the personal computer PCa will be described below as a representative example.
  • the real environment machine S and the personal computer PC are both constituted by a computer system, their hardware configurations are well known, and a CPU 102, a main storage device (RAM) 103, It is configured by connecting a hard disk drive (HDD) 104 or a ROM 108 or the like. Further, a keyboard 105, a mouse 106, and a display 107 for a developer to execute a simulation operation and a simulation result verification are connected to the personal computer PC.
  • HDD hard disk drive
  • the hardware configuration of the real environment machine S and the personal computer PC is as described above, the hard disk drive 104 or the ROM 108 has the main functions realized here.
  • the hard disk drive 104 of the personal computer PC for realizing the PC environment stores ECU application software Sw1, performance comparison software Sw2, and communication software Sw3 for communicating with the ECU as software Sw operating in the PC simulation environment.
  • the ECU application software Sw1 includes a delay injection function Sw11 and a performance measurement function Sw12
  • the performance comparison software Sw2 includes a measurement result comparison / delay parameter setting unit Sw21 and a comparison result display unit Sw22
  • the communication software Sw3 performs measurement.
  • the result receiving unit Sw31 is provided.
  • the ECU application software Sw1 represents simulation software (PC simulation software) for the personal computer PC.
  • the hard disk drive 104 of the personal computer PC that realizes the PC environment has an ECU measurement result file Fi1 that stores the measurement results of the ECU as a data file Fi for various data used when operating in the PC simulation environment.
  • a PC measurement result file Fi2 storing the measurement results and a delay parameter file Fi3 storing the delay parameters determined by comparing the contents of both measurement results are stored.
  • the ECU application software Sw4 is stored in the ROM 108 of the real environment machine S that realizes the real ECU environment.
  • the ECU application software Sw4 has a performance measurement function Sw41 and a measurement result transmission unit Sw42.
  • the measurement results of the ECU are stored as data files Fi for various data used when operating in the real ECU environment.
  • the ECU measurement result file Fi4 is stored.
  • the delay injection function Sw11 in the ECU application software Sw1 in the hard disk drive 104 of the personal computer PC executes a delay process for bringing the execution timing of the PC simulation environment closer to the real ECU. This will be described in Examples 2 to 5.
  • the other processing functions in FIG. 1 determine the amount of delay for bringing the execution timing of the PC simulation environment closer to the real ECU for each personal computer PC, and execute the delay processing at a predetermined position during execution in the PC simulation environment. This relates to timing adjustment, and will be described in Embodiment 6 and subsequent embodiments.
  • the hardware configuration of the personal computer PC constituting the simulation apparatus particularly the delay injection function Sw11, and the main processing functions will be described. Further, a generation process up to creation of software to be ported to the ECU device using the simulation device will be described.
  • the simulation apparatus of FIG. 2 is configured by a general personal computer PC, and its hardware configuration includes a CPU 102, a main storage device (RAM) on a system bus 101 of the personal computer PC. ) 103, a hard disk drive (HDD) 104, a keyboard 105, a mouse 106, a display 107, and the like.
  • a CPU 102 central processing unit
  • main storage device RAM
  • HDD hard disk drive
  • the simulation device of FIG. 2 is a specific development of the delay injection function Sw11 of FIG. 1, and can be represented as various functions or products formed in the hard disk drive 104.
  • the delay injection function Sw11 includes, specifically, an ECU source code 111 for ECU application software, a cross compiler 112 for generating an execution file for an actual ECU, a compiler 113 for generating an execution file for PC simulation, The execution file 114 for the real ECU generated by building the application software 111 using the cross compiler 112 and the execution file 115 for the PC simulator generated by building the application software 111 using the compiler 113 are retained. Or can be expressed as formed.
  • FIG. 2 there is a processing flow F1 for forming a PC simulator execution file 115 from the source code 111 of the ECU application software and a processing flow F2 for forming a real ECU execution file 114 from the source code 111 of the ECU application software.
  • these processing flows F1 and F2 are executed according to the procedure shown in FIG. 3 and described later.
  • the ECU source code 111 has ECU application software 121 that operates on both the real ECU and the PC simulator, and a delay injection function 122 that operates only in the PC simulator environment.
  • the hard disk drive 104 of the personal computer PC stores a delay parameter file Fi3 storing delay information used only in the PC simulator environment.
  • the PC simulator compiler 113 has a compile option 131 for hooking the delay injection function calling process in the ECU software.
  • the PC simulator execution file 115 contains the delay injection execution code 141.
  • the delay injection execution code 141 has a function of executing a delay process for the delay amount described in the delay parameter file Fi3.
  • the ECU application execution code 142 and the delay injection execution code 141 are generated and stored in the PC simulator execution file 115.
  • the actual ECU execution file is generated.
  • an ECU application execution code 143 is generated and stored.
  • FIG. 3 is a diagram showing a conventional generation process up to creation of software to be ported to the ECU using the simulation device.
  • FIG. 3A shows the first stage of application development.
  • the ECU application software 121 for the brake operation in the ECU is converted by the PC simulator compiler 113 and stored in the PC simulator execution file 115 in the ECU simulator. Generate the application execution code 142. The flow of this processing is shown as processing flow F1.
  • ECU application execution code 142 various simulations using the ECU application execution code 142 are executed in the personal computer PC, and the results are appropriately displayed on the display 107 or the like.
  • the developer M receives the result of the simulation displayed on the display 107, appropriately modifies the ECU application software 121 using input means such as the mouse 106 and the keyboard 105, and finally obtains the application software 121A.
  • an ECU application execution file code 142A (not shown) is obtained.
  • FIG. 3B shows the second stage of application development.
  • the ECU application software 121A finally generated in the first stage of application development is converted by the cross-compiler 112 for real ECU and executed for real ECU.
  • An ECU application execution code 143 is generated in the file 114. The flow of this processing is shown as processing flow F2.
  • FIG. 3 shows an ECU confirmation stage, in which the ECU application execution code 143 finally obtained in the second stage of application development is ported to the ECU, and various inspections and the like by the actual machine are executed.
  • the above procedure shown in FIG. 3 shows a conventional generation process up to creation of software to be ported to the ECU using the simulation device.
  • the problem in this case is that the first computer constituting the simulation device Due to the difference in HW performance (hardware performance difference) between the personal computer PC and the second computer constituting the ECU, the operation result of the application software differs between the personal computer PC environment and the ECU environment. It was a thing.
  • the HW performance difference between the first computer and the second computer will be described taking the difference in clock frequency as an example in the following example.
  • the clock frequency fe of the ECU is 1000 Hz
  • the clock frequency fp of the personal computer PC is 3000 Hz
  • the personal computer PC has higher performance than the ECU.
  • the third embodiment shows a case where the ECU has higher performance than the personal computer PC.
  • Embodiment 2 of the present invention is an improvement of the process related to the first stage of the application development in FIG.
  • FIG. 4 illustrates a process related to the first stage of application development according to the second embodiment of the present invention.
  • the following functions and processes are further added to the first stage of application development in FIG. These are included in the delay injection function 122 added to the ECU source code 111, the delay parameter file Fi3 created on the personal computer PC, the function combination option 131 added to the PC simulator compiler 113, and the PC simulator execution file 115. This is the execution code 141 for delay injection added.
  • the execution timing adjustment processing can be detached depending on whether or not the compile option is specified.
  • the programming language in the computer of the present invention is preferably C language, C ++ language, or JAVA (registered trademark). These languages are simply referred to as C language.
  • FIG. 5 is a diagram showing an example of a C language program used in the present invention.
  • the C language program is a simple program that calls the func1 function in the Main function and executes the rest of the Main function after the func1 function ends, as illustrated in FIG.
  • a plurality of func functions can be called to perform processing.
  • the Main function may be called a parent function, and the func function may be called a child function.
  • the delay injection function 122 added to the ECU source code 111 of FIG. 2 is a function for performing a function of “setting a predetermined delay time at a predetermined timing” among func functions in the C language,
  • the prologue function is used to set a delay time at the beginning of the program, and the epilogue function is used to set a delay time at the end of the program.
  • the ECU is a so-called control computer that is used by being incorporated in a vehicle. For this reason, for example, a single-task ECU is started in a period of 10 (ms), and is operated so that a series of processes described in the Main function is completed with a margin within this period every time the ECU is started. Therefore, the configuration and operation are performed on the assumption that the personal computer PC, which is a simulation device, is similarly handled as a control computer. In the case of a multitasking ECU, for example, it has a control cycle of another system which is started at a cycle of 5 (ms), and is operated with an appropriate priority.
  • FIG. 6 shows an example of a table setting in this embodiment of the delay parameter file Fi3 defined in FIG.
  • the Main function the func1 function, and the Default
  • the table of FIG. 6 shows a state after the delay amount has been set.
  • the delay amounts ⁇ t4 to ⁇ t7 set in this table are illustrated in the timing example of FIG.
  • ⁇ t4 is set as a delay amount for executing the Prologue function of the Main function (hereinafter, processing by this function is referred to as prolog processing).
  • ⁇ t7 is set as the delay amount in the Epilogue function of the func1 function (hereinafter, processing by this function is referred to as epilogue processing).
  • Default means that settings not defined by the Main function or the func function are set as standard.
  • the delay amount to be executed is set to 0 (no delay processing is performed).
  • the adjustment group 203 shown in FIG. 6 will be described later in a seventh embodiment.
  • FIG. 7 shows an execution timing in the real ECU, an execution timing in the PC simulator when there is no timing adjustment, and an example of an execution timing in the PC simulator when the timing adjustment is performed.
  • this timing process is a timing when executed under a control cycle of 10 (ms) of the ECU and a clock frequency of 1000 Hz.
  • a control cycle of 10 (ms) is started at time t0.
  • the program requires ⁇ tE1 time for the pre-processing of the Main function, ⁇ tE2 time for the processing of the func1 function, and ⁇ tE3 time for the post-processing of the Main function, and the total time is within the control cycle of 10 (ms) of the ECU. Is completed with sufficient margin.
  • the pre-processing completion time of the Main function is represented by t1
  • the processing completion time of the func1 function is represented by t2
  • the post-processing completion time of the Main function is represented by t3.
  • the execution start time is the same time t0 in both the real ECU and the PC simulation environment. Since the frequency may be 3000 Hz, a series of processing is completed in a short time. Specifically, it takes ⁇ t1 time for the pre-processing of the Main function, ⁇ t2 time for the processing of the func1 function, and ⁇ t3 time for the post-processing of the Main function, but these times are more sufficient than each time of the actual ECU. Because it is early, the execution timing is completely different from that of the real ECU. In the present invention, the delay amount of the delay parameter file Fi3 described with reference to FIG. 6 is calculated and set from the difference between the execution times in the real ECU and the PC simulation environment. The calculation of the delay amount will be described in the sixth embodiment and thereafter.
  • the program starts from the Main function.
  • the prologue processing of the Main function in the row 201 is executed. Since the delay amount in the prologue processing of the Main function is ⁇ t4, the processing of the func1 function is executed after the elapse of the delay time ⁇ t4. When the main function is executed, the func1 function is called after ⁇ t1 time. If the delay amount of the Main function prologue processing is appropriate, the timing of calling the func1 function approaches the actual ECU.
  • the program executes the prologue processing of the func1 function in line 203 with reference to the delay parameter file Fi3 in FIG. 6.
  • the delay amount is set to ⁇ t5
  • the function func1 is executed after the delay time ⁇ t5 has elapsed. Perform function processing.
  • the execution time of the func1 function is the same ⁇ t2 as in the case without timing adjustment.
  • the delay amount ⁇ t6 is set as the epilogue adjustment processing of the func1 function by the setting in the delay parameter file Fi3 of FIG. 6, and by executing the delay processing of ⁇ t6, the post-processing start time of the main function is set in the ECU. It can be set to the processing start time t2 of the main function.
  • the delay amount ⁇ t7 coefficient 3 is set as the epilogue adjustment processing of the main function by the setting in the delay parameter file Fi3 of FIG. 6, and by executing the delay processing of ⁇ t7, the post-processing end time of the main function Can be adjusted to the post-processing end time t3 of the main function in the ECU.
  • the delay time is set by the time from an absolute time (for example, the start time of the control cycle) or the time from the occurrence time of the previous event (for example, the start or end time of each function). It is possible to adopt as appropriate whether to set.
  • the processing timing in the PC simulation environment can be used for the real ECU.
  • delay processing is inserted.
  • prologue processing called at the start of the function or “epilogue processing called at the end of the function”. It is possible to implement delay processing in one of them, or to insert delay processing in both.
  • the processing of calling the delay injection function can be implemented by adding a compile option. It is preferable to use a function that can specify a function to be operated at the time of prologue and epilogue, such as the “-fininstrument-functions” option of GCC. It is unnecessary to add a process for calling a test code in application software for testing in a PC simulation environment.
  • the present invention is a simulation device for converting application software into executable code and verifying the same, and porting the verified executable code to another computer device.
  • a simulation apparatus is characterized in that time adjustment processing is performed at the start or end of a function to adjust the execution timing in the other computer device.
  • the timing between the ECU and the ECU is matched by setting a delay time before or after each function. It is. That is, delay processing is performed as time adjustment processing.
  • FIG. 8 is a diagram showing a timing example when the processing speed of the ECU is faster than the processing speed of the personal computer. This shows the correspondence in this case. For example, when the ECU takes ⁇ tE1 for the processing of the Main function, it is assumed that the personal computer will take more time. In this case, it is preferable to adjust the processing time ⁇ tE1 in the ECU by multiplying the time required for processing the Main function by the personal computer by an appropriate coefficient. This is a time reduction process performed as a time adjustment process.
  • the fourth embodiment also envisages a countermeasure when the processing speed of the ECU is faster than the processing speed of the personal computer PC.
  • Example 4 With reference to FIGS. 9 and 10, an example will be described in which the simulation speed is reduced to a value lower than the actual ECU environment. An embodiment will be described in which a real ECU is compared with a personal computer PC on which a simulator operates, and a timing adjustment function is applied when the real ECU is faster.
  • FIG. 9 shows the ratio between the number of CPU clocks of the actual ECU and the number of clocks of the personal computer PC on which the simulator operates.
  • an environment in which a real ECU has twice the performance of a personal computer PC is taken as an example.
  • FIG. 10 shows the processing timing when executed by the real ECU and the processing timing when executed by the PC simulator.
  • Periodic processing Timer events 601 and 602 are generated, and periodic processing is started by starting the main function.
  • the func1 function is called from the Main function (603, 604).
  • the process returns to the main function, and the periodic processing is completed when the main function ends (605 and 606).
  • the next periodic processing timer event (607, 608), the next periodic processing is started from the main function.
  • the timings of 606 and 608 have been interchanged that the minute processing has not been completed.
  • FIG. 10 shows the processing timing when executing at 1/2 speed in the PC simulation environment.
  • the occurrence of the timer event (609), the start of execution of the func1 function (610), and the end of the main function (611) are not different from the execution timing at the same speed reproduction in the PC simulation environment, but the occurrence of the next periodic processing timer event Since the timing (612) is twice as long as that at the time of the normal speed reproduction, the periodic processing in the PC simulation environment can be kept within the period.
  • the execution time of the function on the PC is shorter than twice the execution time on the ECU, the correction method in the prologue / epilogue is the same as in the first embodiment.
  • the change of the cycle for generating the timer event is performed in the prologue processing or epilogue processing of the function executed in the program initialization processing or the like.
  • this embodiment it is also possible to provide a virtual time, not a real time on a PC, and correct the virtual time to a time when the ECU reaches the virtual time in a prologue / epilogue.
  • virtual time is corrected instead of inserting a wait, so that simulation time can be reduced.
  • a processing request of another task having a higher priority is input, the former is interrupted, the latter is performed, and after the processing is completed, the remaining part of the former task is executed again.
  • a switching process occurs, for example.
  • FIG. 11 shows the relationship between the priorities of the tasks A and B.
  • the task A is started at a control cycle of, for example, 10 (ms)
  • the task B is started at a control cycle of, for example, 5 (ms)
  • FIG. 12 shows the concept of timing adjustment in the case of interrupt processing in multitasking.
  • the left side shows actual processing in the ECU, and task A and task B are executed under different control cycles.
  • the activation time of the periodic processing timer of task A is indicated by t0A1 and t0A2
  • the activation time of the periodic processing timer of task B is indicated by t0B.
  • the period between times t0A1 and t0A2 is the control cycle of the task A
  • the interrupting process of the task B indicates that the restart time of the task A is t1 and the end time of the task A is t2.
  • the task A starts its process triggered by a timer event at time t0A1. Thereafter, at the time t0B during the execution of the task A, the timer event of the task B is issued. At this time, the execution of the task A is interrupted and the processing of the task B is started due to the priority relationship.
  • the task A execution processing does not end before the start of the task B, and switching to the task B occurs. After the completion of the processing of the task B, the execution of the task A is resumed.
  • the simulation device can perform the time adjustment processing for each of the plurality of tasks and reproduce the interruption processing.
  • the execution time stored to adjust the timing is managed for each task, and the processing to stop counting up the execution time of the task whose resources have been deprived in the timing adjustment processing after the task is switched is executed. Good to do.
  • the execution of task A is stopped by the prologue function at the start of the periodic processing of task B.
  • the processing time count of the task A is stopped by the prologue function at the start of the task B, and the execution time count-up of the task A is restarted in the epilogue function at the end of the processing of the task B.
  • the timing adjustment time is calculated by calculating the timing adjustment time from the execution time before the task B is deprived of the resource and the execution time after the return.
  • a delay amount for bringing the execution timing of the PC simulation environment closer to the real ECU for each personal computer PC is determined, and the timing is adjusted while executing the delay processing at a predetermined position during execution in the PC simulation environment. Will be described.
  • FIG. 13 is a diagram showing the flow of processing for the delay amount determination and timing adjustment functions of the personal computer PC and the real environment machine S constituting the simulation apparatus.
  • the performance test of the hardware prototype in the real ECU environment is performed on the real environment machine S side. This is because, in the ECU application software Sw4 in the ROM 108 of the real environment machine S for realizing the real ECU environment, the performance measurement function Sw41 is activated to obtain the measurement result by the ECU simulator in the RAM 103 and save it as the ECU measurement result file Fi4. Things.
  • the ECU measurement result file Fi4 is stored in the personal computer PC via the measurement result reception unit Sw31, which is communication software in the personal computer PC, when the measurement result transmission unit Sw42 in the ECU application software Sw4 is activated. Saved as Fi1.
  • FIG. 14 is a diagram showing the concept of the delay amount determination and timing adjustment functions.
  • the above processing in the real environment machine S is performed by the ECU on the left side of FIG.
  • the start time tsE and the end time teE of the application software (real ECU) are measured as the result of the performance test (ECU measurement result file Fi1 or Fi4) of the hardware prototype.
  • a performance test of the simulator in the PC environment is performed on the personal computer PC side. This is the performance of the ECU application software Sw1 in the hard disk drive 104 of the personal computer PC that implements the simulator.
  • the performance measurement function Sw12 is activated to obtain the measurement results of the simulator in the hard disk drive 104 and saved as a PC measurement result file Fi2. It is.
  • the above processing in the personal computer PC measures the simulation start time tsP and the end time teP as the result of the simulator performance test (PC measurement result file Fi2) in the central personal computer PC (without adjustment) in FIG.
  • the respective start times tsE and tsP are displayed on the same time for convenience of explanation. In this state, the timing adjustment based on the delay processing according to the present invention is not performed.
  • the measurement result comparison / delay parameter setting unit Sw21 in the performance comparison software SW2 is operated, and the ECU measurement result file Fi1 and the PC measurement result file Fi2 are compared and verified.
  • the measurement result comparison / delay parameter setting unit Sw21 calculates the adjustment time based on the difference between the measurement results. In the illustrated example, the time difference between the start times tsE and tsP and the end times teE and teP is compared and verified, and the result is stored in the delay parameter file Fi3.
  • the measurement result comparison / delay parameter setting unit Sw21 in the performance comparison software SW2 is activated, and the ECU measurement result file Fi1 and the PC measurement result file Fi2 are compared and verified.
  • the adjustment time is recalculated based on the difference between the measurement results, and a delay parameter file Fi3 for performing an operation closer to the actual device is created.
  • the timing adjustment procedure described above may be automatically executed by the measurement result comparison / delay parameter setting unit Sw21, or may be displayed on the display 107 via the comparison result display unit SW22, and specific timing adjustment may be performed by the developer. The content may be determined and reflected.
  • the right side of FIG. 14 shows an example of the start time and the end time in the PC simulator after the timing adjustment.
  • the personal computer PC sets the start time of the personal computer process by delaying the time ts0 from the time tsE at which the processing instruction was received with respect to the ECU actual measurement time zone (start time tsE, end time teE) in the real environment machine S. Is determined to be the end time teE of the ECU actual measurement time zone in the real environment machine S when the time te0 has elapsed from the end time. That is, by setting the time before start ts0 and the time after end te0, the time in the PC simulator is made closer to the time of the ECU in the real environment machine S.
  • FIG. 14 The above flow is summarized in FIG. 14 as follows.
  • the ECU application software SW1 and SW4 are executed by the real ECU and the personal computer PC, and the time is recorded at the measurement point (start and end of the function).
  • the measurement timing in the actual ECU is shown on the left side of FIG. 14, and the execution timing in the PC simulator is shown in the center of FIG.
  • the performance comparison software SW2 on the personal computer PC compares the measurement result of the ECU with the measurement result of the personal computer PC, calculates a delay amount for filling the performance difference, and stores the delay amount in the delay parameter file Fi3.
  • the updated delay parameter information is read, the delay processing is executed at the start and end of the function, and then the ECU application software SW1 is executed.
  • the processing timing when the delay processing is executed is shown on the right side of FIG. It can be seen that the processing timing in the ECU (left side in FIG. 14) and the execution time in the PC simulator are approaching.
  • the execution time and the timing measured by the actual ECU are stored in the ECU measurement result file Fi1.
  • the execution time and timing stored in the ECU measurement result file Fi1 can be said to be target data for matching the execution time and timing stored in the PC measurement result file Fi2.
  • the procedure of measuring the target data in the real environment machine S and then performing the measurement and comparison on the personal computer PC side is shown. However, the target data is obtained in advance, and the data is stored in the ECU measurement result file Fi1. If it is secured, it goes without saying that it is not necessary to execute the measurement in the real environment machine S every time.
  • the personal computer PC is faster than the real environment machine S. Therefore, the description is made on the assumption that the timing adjustment processing is processing of the delay time.
  • the delay processing is suitably a timing adjustment processing.
  • the present invention is a timing adjustment in a broad sense.
  • timing adjustment in the present invention is not necessarily intended to perfectly match the ECU. For example, it can be said that if it is possible to achieve a match of about 90%, there will be no significant disadvantage in simulation.
  • the real environment machine S is, for example, an ECU.
  • the ECU has a performance measurement function for measuring the timing when executing application software, and holds an ECU measurement result file for storing measurement results. This is a feature of the present invention.
  • FIG. 15 is a diagram showing an example of a C language program used in the present invention as illustrated in FIG. Although a detailed description of the C language is omitted, the C language program described in FIG. 15 includes a func1 function as three sets of func functions for executing a small processing unit in a Main function 171 (10 ms_func) that performs processing at a cycle of 10 ms. 172 (eeprom_read), a func2 function 173 (nw_send), and a simple program that executes a func3 function 174 (eeprom_write).
  • a func1 function as three sets of func functions for executing a small processing unit in a Main function 171 (10 ms_func) that performs processing at a cycle of 10 ms.
  • 172 eeprom_read
  • nw_send a func2 function 173
  • a simple program that executes a func3 function 174 eeprom_write
  • the C language program has a function of storing the processing start time and end time.
  • FIG. 16 is a schematic flowchart showing the processing contents in the personal computer PC and the real environment machine S executed for determining the delay amount and adjusting the timing.
  • FIG. 16 illustrates the processing contents of the personal computer PC on the right side of FIG. 16, and the processing contents of the real environment machine S on the left side of FIG.
  • the execution time is measured in the processing step S141 on the actual ECU side.
  • the execution timing is recorded in the processing step S142.
  • the execution timing recorded by the real ECU is transmitted from the measurement result transmission unit SW42 of the real ECU to the personal computer PC connected to the same network.
  • the personal computer PC saves the received measurement result as an ECU measurement result file Fi1.
  • the personal computer executes the program in the PC simulation environment in processing step S144, and records the execution timing.
  • the execution timing is recorded by executing the performance measurement code described in the program using the set value of the delay parameter file Fi3 existing in the personal computer PC.
  • the execution timing recorded in the PC simulation environment is stored in the PC measurement result file Fi2.
  • FIG. 17 shows an example of the data structure formed in the ECU measurement result file Fi1 and the PC measurement result file Fi2 created by the above processing. These files are created in the same format, and the information recorded by the ECU and the information recorded by the personal computer PC are the same.
  • the horizontal axis items of the files Fi1 and Fi2 in FIG. 17 include time (301, 305), operation task (302, 306), function name (303, 307), and measurement timing (start / end) (304, 308). Record the four pieces of information.
  • the execution time and the operation task are recorded using the time measurement codes existing at the start and end of the function to be measured by the C language program.
  • an example of a single task is shown, and since the tasks 302 and 306 are one, they are all the same task A.
  • the start time of the Main function 171 (10 ms_func) for the task A is t0
  • the start time of the func1 function 172 (eeprom_read) is t2
  • the end time of the func1 function 172 (eeprom_read) is t6, and func2.
  • the start time of the function 173 (nw_send) is t9
  • the end time of the func2 function 173 (nw_send) is t11
  • the start time of the func3 function 174 (eprom_write) is t12
  • the end time of the func3 function 174 (eprom_write) is t13
  • the end time of (10 ms_func) is t14, indicating that data has been generated in the above order.
  • the start time of the Main function 171 (10 ms_func) is t0
  • the start time of the func1 function 172 (eeprom_read) is t1
  • the end time of the func1 function 172 (eeprom_read) is t3
  • the start time of the func2 function 173 (nw_send) is t4
  • the end time of the func2 function 173 (nw_send) is t5
  • the start time of the func3 function 174 (eeprom_write) is t7
  • the end time of the func3 function 174 (eprom_write) is t8, Ma.
  • the end time of 171 (10 ms_func) is t10, indicating that data has been generated in the above order.
  • FIG. 18 is a diagram showing a time relationship before and after the timing adjustment.
  • the two columns on the left side of FIG. 18 show the situation when the time relationship of FIG. 17 is measured.
  • the child functions 172, 173, and 174 are sequentially executed within 10 ms defined by the parent function 171.
  • the start and end times are shown on the left vertical axis.
  • the personal computer PC the child functions 172, 173, and 174 are sequentially executed in the parent function 171, but the start and end times are higher than those of the real environment machine S as described.
  • a series of child functions has been completed before the elapse of 10 ms defined by the parent function 171.
  • FIG. 19 shows a specific processing flow of updating the delay parameter file Fi3, which is processing during this time.
  • a delay amount is acquired from the delay parameter file Fi3, and in a processing step S152, a time measurement using the delay parameter file Fi3 is performed in a PC simulation environment.
  • the execution result is stored in the PC measurement result file Fi2. The processing flow during this period is as shown in FIG. Since the above series of processing is repeatedly executed a plurality of times while changing the delay parameter, the number of repetitions is counted while updating the number of executions in processing step S160.
  • the ECU measurement result and the PC measurement result are compared to calculate a performance difference.
  • the specific processing content will be described.
  • FIG. 20 shows an example of a delay parameter table in an initial state before performance comparison.
  • the function names are the Main function 171 as the parent function and the func functions 172, 173, and 174 as the child functions, and are described for each of the start and end.
  • the caller function name describes the parent function as seen from the child function, and is in the initial state before the performance comparison, so the delay amount column is set to 0.
  • an adjustment group 181 is set for each parent-child relationship
  • an adjustment group “2” is set on the parent function side
  • an adjustment group “1” is set on the child function side.
  • the order of adjustment in the processing step S154 is performed in ascending order of the adjustment groups 181 described in the delay parameter table of FIG.
  • the func functions 172, 173, and 174 ranked as the adjustment group “1” are selected in advance by the (eeprom_read), (nw_send), and (eeprom_write) functions. Will be executed.
  • processing step S155 of the processing flow of FIG. 19 first, it is determined whether or not the difference between the execution time of the child ECU (eeprom_read) in the real ECU and the execution time in the PC simulation environment is larger than a threshold value. The process moves to step S156 to perform a delay amount calculation process for executing the delay process for the designated time in the PC simulation environment. In the case of the child function (eeprom_read), the difference between the execution times is calculated as ((t6-t2)-(t3-t1)).
  • the delay amount is updated for each function.
  • the delay amount is updated for the child function (eeprom_read).
  • the delay processing is performed by the difference of the execution time in the PC simulation environment, thereby approaching the processing time in the actual ECU. Since the delay amount adjustment is performed at two points, that is, at the start of the function and at the end of the function, the amount obtained by dividing the difference between the execution times into two is written in the delay parameter file Fi3 as the delay amount.
  • the difference between the execution time of the (nw_send) and the execution time of the (eeprom_write) function obtained by the subsequent repetition processing is ((t11 ⁇ t9) ⁇ (t5 ⁇ t4)) and ((t13 ⁇ t12) ⁇ (t8 ⁇ t7), respectively. )).
  • the processing in steps S156 and S157 is sequentially performed on these, and the delay amount for each child function is determined.
  • FIG. 21 shows a delay parameter table in the first stage (step 1) in which the delay amount for each child function is reflected in the delay parameter table in the initial state of FIG. Therefore, here, the updated data of the delay amounts of the child functions (eeprom_read), (nw_send), and (eeprom_write) functions are reflected.
  • the delay amounts calculated previously are written in six places 182 to 187.
  • Examples of the delay processing include, instead of putting the task to sleep, processing that wastes the time for the delay or executes a useless while loop.
  • the time relationship of the simulator process at the child function adjustment end stage is tentatively illustrated, it is as shown in the second “Step 1” from the right in FIG.
  • the child functions are generally in a state in which the time relationship matches.
  • the execution time of the ECU as a whole is approaching the execution time of the ECU by the time length indicated by 431, but the time does not match in the part of the time length 432 yet.
  • step 2 the (10 ms_func) function, which is the function described in the adjustment group “2” described in the delay parameter table of FIG. Adjust the execution timing.
  • the timing adjustment processing of the parent function is started after the completion of all the child functions is confirmed in the processing step S158 of FIG. 19 and the number of executions is initialized to 0 in the processing step S159.
  • the timing adjustment processing of the parent function is achieved by repeatedly executing the processing steps S151, S152, S153, S160, S154, S155, S161, S156, and S157 sequentially in a required number of times, similarly to the case of the child function.
  • Step 2 The execution timing when the processing is executed again from the processing in step S151 in FIG. 19 and the performance difference from the actual ECU is measured again is described as “Step 2” on the right side of FIG.
  • the execution timing has been resolved. This execution timing is obtained by delaying the parent function execution start timing by half the time length 432. Therefore, in the personal computer environment, the timing after a lapse of half the time length 432 from the parent function execution end timing should match the end timing in the ECU environment.
  • the delay processing is first performed on the child function, and then the delay processing is performed on the parent function, thereby ending the processing. It is completed by confirming that there is no function of.
  • processing step S161 the number of repetitions of the delay processing of the function is permitted to be within a predetermined upper limit (in the example of FIG. 20, 8 which is determined by the number of functions 4 * start and end 2). It is better not to repeat the above.
  • the delay amount adjustment processing of the PC simulation environment for one personal computer PC is completed.
  • the type of personal computer PC (HW specification) used differs for each developer, but by adjusting the amount of delay for each personal computer PC, the execution timing in the PC simulation environment for each developer can be changed to the actual ECU. It is possible to get closer.
  • the delay amount is determined and the timing is adjusted in a single task environment.
  • the ECU application software often operates in a multitask environment.
  • context switching occurs based on task priorities.
  • the end time of the function changes depending on whether a context switch occurs.
  • FIG. 22 shows the contents of the measurement result file and an example of execution timing of each task when the context switching of the task occurs.
  • tasks A and B there are tasks A and B, and both A and B are tasks that are activated by a timer event and perform processing periodically.
  • the priority of task B is high, and the priority of task B is high during execution of task A. High task B is activated.
  • the task A starts processing at time t0 triggered by the timer event 201. If the timer event 202 of the task B is issued at the time t1 during the execution of the task A, the execution of the task A is interrupted due to the priority and the processing of the task B is started. Thereafter, at time t2, the processing of task B ends, the processing of task A resumes, and finally task A ends at time t3.
  • FIG. 23 is an example of the start and end times stored by each task.
  • the actual execution time is calculated by subtracting the time during which another task is operating from the execution time of the function.
  • the execution of task A interrupted by task B The time can be calculated by ((t3-t0)-(t2-t1)).
  • the time measurement function and the delay injection function are provided in the ECU software.
  • the software is executed in the real ECU and the PC simulation environment, and the execution timing (elapsed time after startup) is recorded.
  • Performance comparison software with a function to compare the contents of the processing timing data that stores the execution timing between the actual ECU and the PC simulator, determine the delay amount to be injected by the PC simulator from the difference in processing time, and save it to a file I do.
  • Time measurement is recorded at the start and end of the function whose execution timing is to be adjusted.
  • the delay processing is performed immediately after the time measurement at the start of the function and immediately before the time measurement immediately before the end of the function. It is possible to execute the delay processing in one of them, or to insert the delay processing in both.
  • the information is stored as execution timing information in the ECU by using the evaluation board of the CPU and the ECU hardware on which the development is based, and is executed by the actual ECU. It can also be used as timing.
  • System bus 102 CPU 103: Main storage device 104: HDD 105: keyboard 106: mouse 107: display 108: ROM S: Real environment machine PC (PCa, PCb... PCn): Personal computer 180: Communication device 181: External system bus Sw1: ECU application software Sw2: Performance comparison software Sw3: Communication software SW11: Delay injection function SW12: Performance measurement Function SW21: Measurement result comparison / delay parameter setting unit SW22: Comparison result display unit SW31: Measurement result reception unit Fi1: ECU measurement result file Fi2: PC measurement result Fi3: delay parameter file SW4: ECU application software SW41: performance measurement function SW42 : Measurement result transmission unit Fi4: ECU measurement result file

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Geometry (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Automation & Control Theory (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

簡便な手法によりＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づけることができるシミュレーション装置、及びその方法、並びにＥＣＵ装置を提供する事を目的とする。第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、第１の計算機におけるアプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機で構成されたことを特徴とするシミュレーション装置。

Description

シミュレーション装置、及びその方法、並びにＥＣＵ装置
　本発明は、実行タイミングを合わせる機能を備えるシミュレーション装置、及びその方法、並びにＥＣＵ装置に係り、例えば自動車の電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）のソフトウェア開発時に開発者が使用するシミュレーション装置、及びその方法、並びにＥＣＵ装置に関する。
　ＥＣＵ向けソフトウェアの開発において、開発初期段階でハードウェア試作機が出来ているケースは少ない。このため、最初にパソコンＰＣ上で設計した後、ＰＣ環境（シミュレーション環境）で動作確認を行い、ＰＣ環境で検証したソフトをハードウェア試作機である実ＥＣＵ環境へ移植し、動作確認を行う流れが一般的である。
　またハードウェア試作機が出来た後でもソフト開発者に対して割り当てられるハードウェア試作機の数は少ないことがよくあり、例えば、１台のハードウェア試作機を１０人のソフト開発者が共用することもある。
　このような場合、ハードウェア試作機である実ＥＣＵ環境とＰＣ環境の両方でソフトウェアＳＷなどの動作確認を行う形になる。
　この開発の流れにおいて、パソコンＰＣとＥＣＵのＨＷ（ハードウェア）性能差に起因し、ＰＣ環境と実ＥＣＵ環境でアプリケーションソフトの動作結果に差が出てしまう事が良く発生する。
　ＰＣ環境と実ＥＣＵ環境でアプリケーションソフトの実行タイミングに差が出る事により、どちらか片方の環境でのみ発生するような不具合が出てくる。
　またＰＣ環境と実ＥＣＵ環境の違いだけではなく、開発で使用するパソコンＰＣのスペックが開発者ごとに異なることが多く、このことに起因して実ＥＣＵと特定のＰＣでのみ発生するような状況も発生する。
　ＰＣシミュレータが使用されるソフトウェア開発の上流工程でソフトウェアの品質を高める為には、使用するパソコンＰＣ毎にＰＣシミュレーション環境での処理タイミングを実ＥＣＵ処理タイミングに近づける事が重要となっている。
　これらの点に関連して、特許文献１の請求項２には、「シミュレーション開発環境が開発マシンのマイクロプロセッサユニットを実際に使用した時間だけを測定対象にしたクロック割込みのシミュレーションが可能であり、」という記載がある。
特開平５－２８２１６０号公報
　特許文献１では、クロック割込みによる処理開始タイミングを合わせることは出来るが、それ以降の処理タイミングについては調整できない為、ＨＷ性能による差が出てしまう。
　例えば、マルチタスクオペレーティングシステム上で複数アプリを動作させる場合、タスク間で共有する変数の更新タイミングが、シミュレーション環境と実ＥＣＵ環境で差が出てしまう事がある。この結果として、変数を参照するタイミングが変わる事によりアプリケーションソフトの動作に差が出てしまう事がある。
　またＰＣシミュレータでの再現性を高めるために、タイミング調整を取る為の仕組みがあったとしても、開発者が使用するパソコンＰＣ毎に性能（クロック周波数等）の違いがあり、タイミング調整用パラメータはパソコンＰＣ毎に個別調整する必要がある。
　然るに、タイミング調整用パラメータを決める為の情報として、ＣＰＵクロック比があるが、外部メモリアクセス性能の違いや、パソコンＰＣ上で動作しているほかプロセスの影響などの要因もあり、固定の計算式のみで有効なパラメータを算出する事は難しい。
　そこで本発明では、簡便な手法によりＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づけることができるシミュレーション装置、及びその方法、並びにＥＣＵ装置を提供する事を目的とする。
　以上のことから本発明においては「第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、第１の計算機におけるアプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機で構成されたことを特徴とするシミュレーション装置」としたものである。
　また本発明においては「第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、第１の計算機におけるアプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機と、アプリケーションソフトを実行したときの処理タイミングを第２の処理タイミングとして得る第２の性能測定機能を備える第２の計算機と、第１の計算機と第２の計算機を接続する通信装置を備えることを特徴とするシミュレーション装置」としたものである。
　また本発明においては「アプリケーションソフトを実行したときに第２の処理タイミングを入手するための性能測定機能と、第２の処理タイミングを記憶する測定結果記憶部と、第２の処理タイミングを外部に送信するための通信装置を備えることを特徴とするＥＣＵ装置」としたものである。
　また本発明においては「第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングと、第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うことを特徴とするシミュレーション方法」としたものである。
　本発明によれば、ＰＣシミュレーション環境での実行タイミングを実ＥＣＵへ近づけることができる。ＰＣ毎にタイミングの調整を行えるため、開発者のＰＣ環境ごとに遅延量を調整することが出来る。
　さらに本発明の実施例によれば、開発途中の実ＥＣＵ試作機の台数が少ない状態でも実ＥＣＵでの処理タイミングに近い環境でソフトウェアを検証することができ、より上流工程でのソフトウェアの品質確保に寄与することが出来る。
本発明のシミュレーション装置における実ＥＣＵ環境とＰＣ環境の構成例を示す図。 シミュレーション装置を構成するパソコンＰＣの特に遅延注入機能Ｓｗ１１についてのハードウェア構成並びに主な処理機能について示す図。 シミュレーション装置を用いて、ＥＣＵ装置に移植するソフトウェアを作成するまでの生成過程を示す図。 本発明の実施例２に係るアプリ開発第一段階に関わる処理を示す図。 本発明で使用するＣ言語プログラム例を示す図。 遅延パラメータファイルＦｉ３のテーブル設定例を示す図。 実ＥＣＵと、タイミング調整が無い場合と、タイミング調整を実施した場合のシミュレータでの実行タイミング例を示す図。 ＥＣＵの処理速度がパソコンの処理速度よりも早い場合のタイミング例を示す図。 実ＥＣＵのＣＰＵクロック数とシミュレータが動作するパソコンＰＣのクロック数の比率を示す図。 実ＥＣＵで実行した場合の処理タイミングと、ＰＣシミュレータで実行した場合の処理タイミングを示す図。 タスクＡとＢのタスクの優先度の関係を示す図。 マルチタスクにおける割り込み処理の場合におけるタイミング調整の考え方を示す図。 シミュレーション装置を構成するパソコンＰＣ及び実環境機Ｓの遅延量決定、調整機能についての処理の流れについて示す図。 遅延量決定、調整機能についての考え方を示した図。 本発明で使用するＣ言語プログラム例を示す図。 遅延量決定及びタイミング調整のために実行されるパソコンＰＣ、及び実環境機Ｓにおける処理内容を示す概略フローチャート。 ＥＣＵ測定結果ファイルＦｉ１、ＰＣ測定結果ファイルＦｉ２の構成例を示す図。 タイミング調整前後の時間関係を示す図。 遅延パラメータファイルＦｉ３更新の具体的な処理フローを示す図。 性能比較前の初期状態における遅延パラメータテーブルの一例を示す図。 図２０の初期状態の遅延パラメータテーブルに子関数ごとの遅延量を反映させた遅延パラメータテーブルを示す図。 マルチタスクのコンテキスト切り替えが発生した場合の実行タイミング例を示す図。 各タスクが記憶した開始、終了時刻の一例を示す図。
　以下本発明に係るシミュレーション装置について、図面を参照して詳細に説明する。なお、本発明の実施例は多岐にわたることから、実施例１ではシミュレーション装置の特にハードウェア構成を主体に説明し、実施例２から実施例５ではＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延処理を実行することについて説明し、実施例６以降ではパソコンＰＣ毎にＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延量を決定し、ＰＣシミュレーション環境での実行時に所定の位置で遅延処理を実行しながらタイミング調整することについて説明する。
　実施例１ではシミュレーション装置の特にハードウェア構成を主体に説明する。図１は、本発明のシミュレーション装置における実ＥＣＵ環境とＰＣ環境の構成例を表している。
　図１の右側には実ＥＣＵ環境を実現する実環境機Ｓ、左側にはＰＣ環境を実現するパソコンＰＣの構成例が示されている。実環境機Ｓと複数のパソコンＰＣ（ＰＣａ、ＰＣｂ・・・ＰＣｎ）は、通信装置１８０を介して外部システム・バス１８１に接続されている。なおパソコンＰＣは基本的に同じ構成、機能のものであるので、以下においてはパソコンＰＣａを代表例として説明する。
　実環境機ＳおよびパソコンＰＣは、いずれも計算機システムにより構成されているので、そのハードウェア構成はよく知られているように、システム・バス１０１上に、ＣＰＵ１０２、主記憶装置（ＲＡＭ）１０３、ハードディスクドライブ（ＨＤＤ）１０４あるいはＲＯＭ１０８等を接続して構成されている。またパソコンＰＣには、開発者がシミュレーション操作やシミュレーション結果の検証を実行するためのキーボード１０５、マウス１０６、ディスプレイ１０７が接続されている。
　実環境機ＳおよびパソコンＰＣのハードウェア構成は、上記のようであるが、ハードディスクドライブ１０４あるいはＲＯＭ１０８にはここで実現される主要な機能が搭載されている。
　まずＰＣ環境を実現するパソコンＰＣのハードディスクドライブ１０４には、ＰＣシミュレーション環境で動作するソフトウェアＳｗとして、ＥＣＵアプリケーションソフトＳｗ１と、性能比較ソフトＳｗ２と、ＥＣＵとの通信を行う通信ソフトＳｗ３が格納されている。なおＥＣＵアプリケーションソフトＳｗ１には、遅延注入機能Ｓｗ１１と性能測定機能Ｓｗ１２を備え、性能比較ソフトＳｗ２には測定結果比較・遅延パラメータ設定部Ｓｗ２１、比較結果表示部Ｓｗ２２を備え、通信ソフトＳｗ３には測定結果受信部Ｓｗ３１を備えている。なおＥＣＵアプリケーションソフトＳｗ１は、パソコンＰＣにおけるシミュレーションソフト（ＰＣシミュレーションソフト）を表している。
　またＰＣ環境を実現するパソコンＰＣのハードディスクドライブ１０４には、ＰＣシミュレーション環境で動作するときに使用する各種のデータについてのデータファイルＦｉとして、ＥＣＵでの測定結果を保存したＥＣＵ測定結果ファイルＦｉ１、ＰＣ測定結果を保存したＰＣ測定結果ファイルＦｉ２、両測定結果の内容を比較し、決定した遅延パラメータを保存した遅延パラメータファイルＦｉ３が格納されている。
　他方、実ＥＣＵ環境を実現する実環境機ＳのＲＯＭ１０８には、ＥＣＵアプリケーションソフトＳｗ４が格納されている。ＥＣＵアプリケーションソフトＳｗ４は、性能測定機能Ｓｗ４１と測定結果送信部Ｓｗ４２を持つ。また実ＥＣＵ環境を実現する実環境機Ｓの主記憶装置（ＲＡＭ）１０３には、実ＥＣＵ環境で動作するときに使用する各種のデータについてのデータファイルＦｉとして、ＥＣＵでの測定結果を保存したＥＣＵ測定結果ファイルＦｉ４が格納されている。
　なお、図１で説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はない事を理解されたい。
　図１を用いて説明した各種の処理のうち、パソコンＰＣのハードディスクドライブ１０４におけるＥＣＵアプリケーションソフトＳｗ１における遅延注入機能Ｓｗ１１は、ＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延処理を実行することに係るものであり、実施例２から実施例５において説明する。また図１におけるその他の処理機能は、パソコンＰＣ毎にＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延量を決定し、ＰＣシミュレーション環境での実行時に所定の位置で遅延処理を実行しながらタイミング調整することに係るものであり、実施例６以降において説明する。
　本発明の実施例２から実施例５の説明では、シミュレーション装置を構成するパソコンＰＣの特に遅延注入機能Ｓｗ１１についてのハードウェア構成、並びに主な処理機能について説明する。またシミュレーション装置を用いて、ＥＣＵ装置に移植するソフトウェアを作成するまでの生成過程について説明する。
　まず、シミュレーション装置を構成するパソコンＰＣの特に遅延注入機能Ｓｗ１１についてのハードウェア構成並びに主な処理機能について図２を用いて説明する。
　図１で述べたように、図２のシミュレーション装置は、一般的なパソコンＰＣで構成されており、そのハードウェア構成としては、パソコンＰＣのシステム・バス１０１上に、ＣＰＵ１０２、主記憶装置（ＲＡＭ）１０３、ハードディスクドライブ（ＨＤＤ）１０４、キーボード１０５、マウス１０６、ディスプレイ１０７などが接続されている。
　図２のシミュレーション装置は、図１の遅延注入機能Ｓｗ１１を具体的に機能展開したものであり、ハードディスクドライブ１０４内に形成される各種機能或は生成物として表すことができる。遅延注入機能Ｓｗ１１は、具体的には、ＥＣＵアプリケーションソフトについてのＥＣＵソースコード１１１、実ＥＣＵ向けの実行ファイルを生成する為のクロスコンパイラ１１２、ＰＣシミュレーション用の実行ファイルを生成する為のコンパイラ１１３、クロスコンパイラ１１２を使用してアプリケーションソフト１１１をビルドする事により生成された実ＥＣＵ用実行ファイル１１４、コンパイラ１１３を使用してアプリケーションソフト１１１をビルドする事により生成されたＰＣシミュレータ用実行ファイル１１５が保持され、あるいは形成されたものとして表現することができる。
　図２によれば、ＥＣＵアプリケーションソフトのソースコード１１１からＰＣシミュレータ用実行ファイル１１５を形成する処理フローＦ１と、ＥＣＵアプリケーションソフトのソースコード１１１から実ＥＣＵ用実行ファイル１１４を形成する処理フローＦ２が存在するが、これらの処理フローＦ１、Ｆ２は、図３に示し後述する手順で実行されている。
　なおＥＣＵソースコード１１１には、実ＥＣＵとＰＣシミュレータ両方で動作するＥＣＵアプリケーションソフト１２１と、ＰＣシミュレータ環境のみで動作する遅延注入用関数１２２を持つ。
　また、パソコンＰＣのハードディスクドライブ１０４には、ＰＣシミュレータ環境のみで使用される遅延情報を保存した遅延パラメータファイルＦｉ３が格納されている。
　またＰＣシミュレータ用コンパイラ１１３には、遅延注入用機能呼び出し処理をＥＣＵソフト内にフッキングする為のコンパイルオプション１３１を持つ。ＥＣＵソースコード１１１をコンパイラ１１３でコンパイルオプション１３１を指定してコンパイルすると、ＰＣシミュレータ用実行ファイル１１５内に、遅延注入用実行コード１４１が含まれる。遅延注入用実行コード１４１は、遅延パラメータファイルＦｉ３に記載された遅延量分の遅延処理を実行する機能を持つ。
　なお処理フローＦ１でのコンパイル処理により、ＰＣシミュレータ用実行ファイル１１５内にはＥＣＵアプリケーション実行コード１４２と遅延注入用実行コード１４１が生成記憶され、処理フローＦ２でのコンパイル処理により、実ＥＣＵ用実行ファイル１１４内にはＥＣＵアプリケーション実行コード１４３が生成記憶される。
　なお、ここで説明する構成と処理は、一実施例として説明するものである、本発明の技術的範囲をこの実施例に限定して解釈する意図はない事を理解されたい。
　図３は、シミュレーション装置を用いて、ＥＣＵに移植するソフトウェアを作成するまでの従来における生成過程を示す図である。
　図３の（ａ）は、アプリ開発第一段階を表しており、例えばＥＣＵにおけるブレーキ操作についてのＥＣＵアプリケーションソフト１２１が、ＰＣシミュレータ用コンパイラ１１３により変換されて、ＰＣシミュレータ用実行ファイル１１５内にＥＣＵアプリケーション実行コード１４２を生成する。この処理の流れが処理フローＦ１で示されている。
　またこの段階では、ＥＣＵアプリケーション実行コード１４２を用いた各種のシミュレーションがパソコンＰＣ内で実行され、その結果が適宜ディスプレイ１０７などに表示されている。開発者Ｍは、ディスプレイ１０７に表示されたシミュレーションの結果を受けてマウス１０６、キーボード１０５などの入力手段を用いてＥＣＵアプリケーションソフト１２１を適宜改変し、最終的にアプリケーションソフト１２１Ａを得る。また最終的にＥＣＵアプリケーション実行ファイルコード１４２Ａ（図示せず）を得る。
　図３の（ｂ）は、アプリ開発第二段階を表しており、アプリ開発第一段階で最終的に生成したＥＣＵアプリケーションソフト１２１Ａを、実ＥＣＵ用クロスコンパイラ１１２により変換して、実ＥＣＵ用実行ファイル１１４内にＥＣＵアプリケーション実行コード１４３を生成する。この処理の流れが処理フローＦ２で示されている。
　図３の（ｃ）は、ＥＣＵ確認段階を表しており、アプリ開発第二段階において最終的に得られたＥＣＵアプリケーション実行コード１４３をＥＣＵに移植し、実機による各種の検査などを実行する。
　図３に示す上記の手順は、シミュレーション装置を用いて、ＥＣＵに移植するソフトウェアを作成するまでの従来における生成過程を示しているが、この場合の問題点がシミュレーション装置を構成する第１の計算機であるパソコンＰＣと、ＥＣＵを構成する第２の計算機との間のＨＷ性能差（ハードウェア性能差）に起因し、パソコンＰＣ環境とＥＣＵ環境でアプリケーションソフトの動作結果に差が出てしまうという事であった。
　なお第１の計算機と、第２の計算機との間のＨＷ性能差として、以下の例ではクロック周波数の差を例にとり説明するものとする。なお実施例２ではＥＣＵのクロック周波数ｆｅが１０００Ｈｚ、パソコンＰＣのクロック周波数ｆｐが３０００Ｈｚであり、パソコンＰＣの方がＥＣＵよりも高性能な事例を示している。また実施例３ではＥＣＵの方がパソコンＰＣよりも高性能な事例を示している。
　本発明の実施例２は、図３の（ａ）アプリ開発第一段階に関わる処理を改善したものである。図４は、本発明の実施例２に係るアプリ開発第一段階に関わる処理を示している。
　図４のアプリ開発第一段階では、図３の（ａ）アプリ開発第一段階にさらに以下の機能や処理が追加されている。これらは、ＥＣＵソースコード１１１に追加された遅延注入用関数１２２、パソコンＰＣ上に作成された遅延パラメータファイルＦｉ３、ＰＣシミュレータ用コンパイラ１１３に追加された関数結合オプション１３１、ＰＣシミュレータ用実行ファイル１１５に追加された遅延注入用実行コード１４１である。
　なお図４の構成によれば、コンパイルオプションの指定の有無により実行タイミング調整処理を着脱する構成のものとする事が出来る。
　これらの追加された機能は、要するに最終的に形成されるプログラム（ＰＣシミュレータ用実行ファイル１１５に生成されたＥＣＵアプリケーション実行コード１４２）中に、「予め定めたタイミングに予め定めた遅延時間を設定する」ものであり、このため本発明の計算機におけるプログラミング言語はＣ言語、Ｃ＋＋言語、ＪＡＶＡ（登録商標）を採用するのがよい。なお、これらの言語は以下単にＣ言語と略称する。
　図５は、本発明で使用するＣ言語プログラム例を示す図である。Ｃ言語プログラムでは、図５に例示するようにＭａｉｎ関数の中でｆｕｎｃ１関数を呼び出し、ｆｕｎｃ１関数終了後にＭａｉｎ関数の残りを実行する単純なプログラムである。なお、Ｍａｉｎ関数の中では、複数のｆｕｎｃ関数を呼び出して処理を行わせることができる。なおＭａｉｎ関数を親関数、ｆｕｎｃ関数を子関数と呼ぶことがある。
　図２のＥＣＵソースコード１１１に追加された遅延注入用関数１２２は、Ｃ言語のｆｕｎｃ関数のうち、「予め定めたタイミングに予め定めた遅延時間を設定する」機能を果たすための関数であり、プログラムの先頭位置に遅延時間を設定する目的で使用するのがｐｒｏｌｏｇｕｅ関数であり、プログラムの後尾に遅延時間を設定する目的で使用するのがｅｐｉｌｏｇｕｅ関数である。
　なお、ＥＣＵは車両に組み込まれて使用される、いわゆる制御用計算機である。このため例えばシングルタスクのＥＣＵは１０（ｍｓ）周期で起動され、起動の都度Ｍａｉｎ関数に記述された一連の処理をこの期間内で余裕をもって処理完了するように運用される。従って、シミュレーション装置であるパソコンＰＣも同様に制御用計算機として取り扱うことを前提として、構成運用されている。なおマルチタスクのＥＣＵの場合には、例えば５（ｍｓ）周期で起動される別体系の制御周期を有し、適宜の優先順位で運用されるものとされる。
　図６には、図２で規定した遅延パラメータファイルＦｉ３の本実施例でのテーブル設定例を記している。ここでは、Ｍａｉｎ関数、ｆｕｎｃ１関数、Ｄｅｆａｕｌｔについて、遅延時間設定位置の区別、呼び出し元関数名、遅延量、備考としての要件などを記述している。図６のテーブルは、遅延量の設定を終えた後の状態を表している。本テーブルで設定されている遅延量Δｔ４～Δｔ７については、図７のタイミング例で図示する。
　例えば、Ｍａｉｎ関数についての行２０１では、Ｍａｉｎ関数のＰｒｏｌｏｇｕｅ関数（以下この関数による処理をプロローグ処理という）で実行する遅延量としてΔｔ４が設定されている。
　ｆｕｎｃ１関数についての行２０２では、ｆｕｎｃ１関数のＥｐｉｌｏｇｕｅ関数（以下この関数による処理をエピローグ処理という）における遅延量としてΔｔ７を設定している。　なおＤｅｆａｕｌｔとは、Ｍａｉｎ関数あるいはｆｕｎｃ関数などで定義していない部分について標準的に設定を行う事を意味している。本例では、記載されていない関数のプロローグ処理及びエピローグ処理では実行する遅延量として０（遅延処理を行わない）としている。
　図６に記載の調整グループ２０３については、実施例７で後述する。
　図７は、実ＥＣＵでの実行タイミングと、タイミング調整が無い場合のＰＣシミュレータでの実行タイミングと、タイミング調整を実施した場合のＰＣシミュレータでの実行タイミング例を記している。
　まず図７左側のＥＣＵでの実行タイミングについて説明する。先にも述べたように、このタイミング処理は、ＥＣＵの１０（ｍｓ）の制御周期、かつ１０００Ｈｚのクロック周波数の下で実行された場合のタイミングである。ここでは時刻ｔ０において、１０（ｍｓ）の制御周期が開始されたものとする。
　この例では、プログラムはＭａｉｎ関数の前段処理にΔｔＥ１時間、ｆｕｎｃ１関数の処理にΔｔＥ２時間、Ｍａｉｎ関数の後段処理にΔｔＥ３時間を要し、かつこの合計時間はＥＣＵの１０（ｍｓ）の制御周期内で十分な余裕をもって完了される。なお、Ｍａｉｎ関数の前段処理完了時刻をｔ１、ｆｕｎｃ１関数の処理完了時刻をｔ２、Ｍａｉｎ関数の後段処理完了時刻をｔ３として表記している。
　これに対し、パソコンＰＣを用いたシミュレーション装置の内部では、ＥＣＵでの実行タイミングと同じタイミングを実現できるものであることが望まれる。
　この点に関し、図３で示した時間調整を実行しない従来方式（図７中央）によれば、実行開始時点は、実ＥＣＵもＰＣシミュレーション環境でも同じ時刻ｔ０であるとしているが、パソコンＰＣのクロック周波数が３０００Ｈｚであることもあり、短時間で一連の処理を完了してしまう。具体的には、Ｍａｉｎ関数の前段処理にΔｔ１時間、ｆｕｎｃ１関数の処理にΔｔ２時間、Ｍａｉｎ関数の後段処理にΔｔ３時間を要しているが、これらの時間は実ＥＣＵの各時間よりも十分に早いものであるために、実行タイミングが実ＥＣＵのそれとはまったく異なるものになっている。本発明では、実ＥＣＵとＰＣシミュレーション環境での実行時間の差から図６で説明した遅延パラメータファイルＦｉ３の遅延量を計算して設定する。遅延量の計算は実施例６以降で説明する。
　本発明では、関数の前後に適宜遅延時間を設定することで、図７左側のＥＣＵでの実行タイミングに近いものを実現する。なお図７右側のタイミング調整有の事例において、他の場合と同様に制御周期の開始時点はｔ０である。
　このとき、プログラムはＭａｉｎ関数から開始する。最初に図６の遅延パラメータファイルＦｉ３を参照して、行２０１のＭａｉｎ関数のプロローグ処理を実行する。Ｍａｉｎ関数のプロローグ処理における遅延量がΔｔ４の為、遅延時間Δｔ４の経過後にｆｕｎｃ１関数の処理を実行する。ｍａｉｎ関数を実行していくと、Δｔ１時間後にｆｕｎｃ１関数が呼ばれる。Ｍａｉｎ関数プロローグ処理の遅延量が適切であれば、ｆｕｎｃ１関数呼び出しのタイミングが実ＥＣＵに近づく。
　プログラムは次に、図６の遅延パラメータファイルＦｉ３を参照して、行２０３のｆｕｎｃ１関数のプロローグ処理を実行するが、ここでは遅延量としてΔｔ５が設定されているので、遅延時間Δｔ５の経過後にｆｕｎｃ１関数の処理を実行する。
　ｆｕｎｃ１関数の実行時間は、タイミング調整なしのケースと同じΔｔ２である。図６の遅延パラメータファイルＦｉ３での設定により、ｆｕｎｃ１関数のエピローグ調整処理として遅延量Δｔ６が設定されており、Δｔ６分の遅延処理を実行する事により、ｍａｉｎ関数の後段処理開始時刻を、ＥＣＵにおけるｍａｉｎ関数の処理開始時刻ｔ２に合わせることができる。
　同様に図６の遅延パラメータファイルＦｉ３での設定により、ｍａｉｎ関数のエピローグ調整処理として遅延量Δｔ７係数３が設定されており、Δｔ７分の遅延処理を実行することにより、ｍａｉｎ関数の後段処理終了時刻を、ＥＣＵにおけるｍａｉｎ関数の後段処理終了時刻ｔ３に合わせることができる。
　なお、各関数での遅延時間の設定に当たり、これを絶対時刻（例えば制御周期の開始時刻）からの時間で設定するか、前回イベント（例えば各関数の開始、終了時刻）の発生時刻からの時間で設定するかは適宜採用可能である。
　このように本発明では、ＰＣシミュレーション環境においてのみ動作する遅延処理を実装、追加できる仕組みを実現する事により、ＰＣシミュレーション環境での処理タイミングを実ＥＣＵに使づけることができる。
　また遅延処理を入れる場所は「関数の開始時に呼び出されるプロローグ処理」または「関数の終了時に呼び出されるエピローグ処理」とする。どちらか一方で遅延処理を実装する事も出来るし、両方で遅延処理を入れることも可能である。
　さらに遅延注入関数の呼び出し処理はコンパイルオプションの追加で実施することができる。ＧＣＣの”－ｆｉｎｓｔｒｕｍｅｎｔ－ｆｕｎｃｔｉｏｎｓ”オプションのような、プロローグとエピローグ時に動作する関数を指定できる機能を使用するのがよい。ＰＣシミュレーション環境でのテスト用にアプリケーションソフト内でテストコードを呼び出す処理を追加する事は不要である。
　以上述べたように本発明は、アプリケーションソフトを実行コードに変換して検証し、検証後の実行コードを他の計算機装置に移植するためのシミュレーション装置であって、アプリケーションのソースコードの関数単位で関数開始時、または終了時に時刻調整処理を行い、前記他の計算機装置における実行タイミングを調整することを特徴とするシミュレーション装置としたものである。
　実施例２においては、ＥＣＵの処理速度がパソコンの処理速度よりも遅いことを前提にして、各関数の前或は後に遅延時間を設定することで、ＥＣＵとの間のタイミングを合致させたものである。つまり時刻調整処理として遅延処理を行ったものである。
　これに対しＥＣＵの処理速度がパソコンの処理速度よりも早い場合がある。図８はＥＣＵの処理速度がパソコンの処理速度よりも早い場合のタイミング例を示す図である。この場合における対応を示したものであり、例えばＭａｉｎ関数の処理にＥＣＵがΔｔＥ１かかるところ、パソコンではそれ以上の時間を要してしまうことが想定される。この場合には、パソコンでのＭａｉｎ関数の処理に要した時間に適宜の係数を乗じてＥＣＵにおける処理時間ΔｔＥ１にすべく、調整するのがよい。これは時刻調整処理として時間短縮化処理を行ったものである。
　実施例４もまた、ＥＣＵの処理速度がパソコンＰＣの処理速度よりも早い場合の対応策を想定している。
　実施例４について、図９、及び図１０を使用し、シミュレーション速度を実ＥＣＵ環境よりも下げて実行する場合の例を説明する。実ＥＣＵとシミュレータが動作するパソコンＰＣを比較し、実ＥＣＵの方が高速な場合のタイミング調整機能を適用した場合の実施例を説明する。
　図５に記したｍａｉｎ関数を周期的に実行する実施例で説明する。実ＥＣＵのＣＰＵクロック数とシミュレータが動作するパソコンＰＣのクロック数の比率を図９に記す。本例は、実ＥＣＵの方がパソコンＰＣよりも２倍性能がよい環境を例にしている。
　図１０に、実ＥＣＵで実行した場合の処理タイミングと、ＰＣシミュレータで実行した場合の処理タイミングを記す。
　周期処理タイマイベント６０１、６０２が発生し、ｍａｉｎ関数を開始することで周期処理を開始する。Ｍａｉｎ関数の中からｆｕｎｃ１関数がコールされる（６０３、６０４）。Ｆｕｎｃ１関数実行後にｍａｉｎ関数へ戻り、ｍａｉｎ関数終了時点で周期処理が完了する（６０５、６０６）。次の周期処理タイマイベント発行（６０７、６０８）を受け、次回の周期処理がｍａｉｎ関数から開始されるが、本実施例の場合、ＰＣシミュレータ環境では、ＣＰＵ性能が低いことに起因して、前回分の周期処理が終わっていないことが、６０６、６０８のタイミングが入れ替わっていることから確認できる。
　ＰＣシミュレータ環境では、等倍速で実行した場合に、ＥＣＵと同じタイミングで処理することが出来ないため、ＣＰＵ比率を元に、１／２倍速することによりＰＣシミュレーション環境でのタイマイベントの発生間隔を２倍にすることにより、ＰＣシミュレーション環境での処理タイミングを実ＥＣＵに近い形で実行する事が可能となる。
　図１０の右側に、ＰＣシミュレーション環境で１／２倍速実行したときの処理タイミングを記す。タイマイベントの発生（６０９）、ｆｕｎｃ１関数の実行開始（６１０）、ｍａｉｎ関数の終了（６１１）は、ＰＣシミュレーション環境での等倍速再生時の実行タイミングと変わらないが、次の周期処理タイマイベント発生タイミング（６１２）が等倍速再生時よりも２倍後になることにより、ＰＣシミュレーション環境での周期処理を周期内に収めることが出来ている。なお、関数のＰＣでの実行時間がＥＣＵでの実行時間の２倍より短い場合の、プロローグ・エピローグでの補正方法は、実施例１と同様である。
　タイマイベントを発生させる周期の変更は、プログラム初期化処理などで実行される関数のプロローグ処理またはエピローグ処理において実施する。
　本実施例のバリエーションとして、ＰＣでの実時間でなく、仮想的な時刻を備えて、プロローグ・エピローグにおいて、仮想的な時刻をＥＣＵにおいてそこに到達する時刻に補正する方式も可能である。この方式では、待ちを挿入する代わりに仮想的な時刻の補正行うため、シミュレーション時間を削減することが出来る。
　実施例２から実施例４においては、１つのタスクのみが一つのＣＰＵ上で動作するプログラム（いわゆるシングルタスク）に対し、タイミング調整機能を適用した場合の実施例を説明した。これに対し、マルチタスク方式のＥＣＵでは、複数のタスクＡ、Ｂが一つのＣＰＵ上で動作するプログラムに対して、タイミング調整機能を適用する必要がある。
　係るマルチタスクの方式では、一方のタスク実行中に優先度の高い他のタスクの処理要求が入り、前者を中断して後者の処理を行い、その処理終了後に再度前者のタスクの残余部分を実行するといった切替処理が発生する。
　図１１は、タスクＡとＢのタスクの優先度の関係を示している。タスクＡは例えば１０（ｍｓ）の制御周期で起動され、タスクＢは例えば５（ｍｓ）の制御周期で起動されるものであり、タスクＢの優先度が高くされた事例を示している。
　図１２は、マルチタスクにおける割り込み処理の場合におけるタイミング調整の考え方を示している。図１２において左側は、ＥＣＵでの実処理を示しており、タスクＡとタスクＢは異なる制御周期の下で実行されている。ここではタスクＡの周期処理タイマ起動時刻がｔ０Ａ１、ｔ０Ａ２で、またタスクＢの周期処理タイマ起動時刻がｔ０Ｂで示されている。またこの例では時刻ｔ０Ａ１、ｔ０Ａ２間がタスクＡの制御周期であり、タスクＢの割り込む処理により、タスクＡの再開時刻がｔ１、タスクＡの終了時刻がｔ２になったことを表している。
　この図１２の例では、タスクＡが時刻ｔ０Ａ１のタイマイベントを契機に処理を開始する。その後タスクＡの処理実行中の時刻ｔ０ＢにタスクＢのタイマイベントが発行された。このとき、優先度の関係からタスクＡの実行を中断し、タスクＢの処理を開始する事となる。
　本例のイベント発生タイミングによれば、実ＥＣＵではタスクＡ実行処理がタスクＢ開始までに終了せず、タスクＢへの切替が発生している。タスクＢの処理終了後に、タスクＡの実行が再開されている。
　一方、図１２中央の従来における処理によれば、ＥＣＵよりも高速なＰＣシミュレータ環境であることから、タスクＡの実行がタスクＢ開始までに終了してしまうため、タスク切替は発生していない。つまり従来方式では、マルチタスクにおけるタスク切り替えを再現することができない。この結果として、ＰＣシミュレータ環境では１周期で実行でき、正しく動作していても、実ＥＣＵ環境に移植して動作確認をした場合に、１周期の期間内に処理が完了しないという問題などもよく発生する。
　ＰＣシミュレーション環境で関数のプロローグ、エピローグ処理でタイミング調整を入れた場合の本発明の動作を図１２の右側に記述している。この記述例によれば、適宜の遅延時間を加味することで、タスクＡの前段処理部分を形成することが可能であり、同様にタスクＢ、タスクＡの後段処理部分を形成することができ、割り込み処理を実現することができる。
　このように、実施例２と同様に関数単位で細かくタイミング調整処理が入る為、実ＥＣＵとＰＣシミュレータで同じタイミングでタスクＡ及びタスクＢのタイマイベントが発生した場合に、ＰＣシミュレータ上でもタスクの切替が発生する事となる。つまり、異なる制御周期で動作するマルチタスク方式の場合にシミュレーション装置は、複数のタスクの夫々について時刻調整処理を行い、割り込み処理を再現することができる。
　なおマルチタスク方式では、タイミングを調整する為に記憶する実行時間はタスクごとに管理し、タスクが切り替わった後のタイミング調整処理でリソースを奪われたタスクの実行時間のカウントアップを止める処理を実行するのがよい。
　本例ではタスクＢの周期処理開始時のプロローグ関数でタスクＡの実行を止めることになる。タスクＢ開始時のプロローグ関数でタスクＡの処理時間カウントを止め、タスクＢの処理終了時のエピローグ関数内でタスクＡの実行時間カウントアップを再開する。その後タイミング調整タイミングが来た時に、タスクＢにリソースを奪われる前と復帰後の実行時間からタイミング調整時間を計算して、タイミング調整を行う。
　実施例６以降では、パソコンＰＣ毎にＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延量を決定し、ＰＣシミュレーション環境での実行時に所定の位置で遅延処理を実行しながらタイミング調整することについて説明する。
　図１３は、シミュレーション装置を構成するパソコンＰＣ及び実環境機Ｓの遅延量決定、タイミング調整機能についての処理の流れについて示す図である。
　図１３によれば、実環境機Ｓ側において実ＥＣＵ環境におけるハードウェア試作機の性能試験が実行される。これは実ＥＣＵ環境を実現する実環境機ＳのＲＯＭ１０８内のＥＣＵアプリケーションソフトＳｗ４において、性能測定機能Ｓｗ４１が作動してＲＡＭ１０３内にＥＣＵシミュレータでの測定結果を得、ＥＣＵ測定結果ファイルＦｉ４として保存したものである。
　なおその後、ＥＣＵ測定結果ファイルＦｉ４は、ＥＣＵアプリケーションソフトＳｗ４内の測定結果送信部Ｓｗ４２が作動して、パソコンＰＣ内の通信ソフトである測定結果受信部Ｓｗ３１を介してパソコンＰＣ内にＥＣＵ測定結果ファイルＦｉ１として保存される。
　図１４は、遅延量決定、タイミング調整機能についての考え方を示した図であり、これと図１３の処理を対比して示すと、実環境機Ｓにおける上記処理は、図１４の左側のＥＣＵにおいてハードウェア試作機の性能試験の結果（ＥＣＵ測定結果ファイルＦｉ１またはＦｉ４）として、アプリケーションソフト（実ＥＣＵ）の開始時刻ｔｓＥと終了時刻ｔｅＥを測定したものである。
　他方、パソコンＰＣ側においてＰＣ環境におけるシミュレータの性能試験が実行される。これはシミュレータを実現するパソコンＰＣのハードディスクドライブ１０４内のＥＣＵアプリケーションソフトＳｗ１について、性能測定機能Ｓｗ１２が作動してハードディスクドライブ１０４内にシミュレータでの測定結果を得、ＰＣ測定結果ファイルＦｉ２として保存したものである。
　パソコンＰＣにおける上記処理は、図１４の中央のパソコンＰＣ（調整なし）においてシミュレータの性能試験の結果（ＰＣ測定結果ファイルＦｉ２）として、シミュレーション開始時刻ｔｓＰと終了時刻ｔｅＰを測定したものである。なお図１４においては、説明の都合上夫々の開始時刻ｔｓＥ、ｔｓＰを同一時刻上に表示している。またこの状態では、本発明による遅延処理に基づくタイミング調整は行われていないものである。
　図１３に戻り、次に性能比較ソフトＳＷ２内の測定結果比較・遅延パラメータ設定部Ｓｗ２１が作動し、ＥＣＵ測定結果ファイルＦｉ１とＰＣ測定結果ファイルＦｉ２についての比較検証を実施する。図１４に示すように、測定結果比較・遅延パラメータ設定部Ｓｗ２１は、測定結果の差分を元に調整時間を算出する。図示の例では、開始時刻ｔｓＥ、ｔｓＰと、終了時刻ｔｅＥ、ｔｅＰの時間差分が比較検証され、この結果が遅延パラメータファイルＦｉ３に保存される。
　その後、保存した遅延パラメータファイルＦｉ３を使用してパソコンＰＣ上でシミュレータの性能試験を再度実行する。これによりＰＣ測定結果ファイルＦｉ２が更新される。
　性能比較ソフトＳＷ２内の測定結果比較・遅延パラメータ設定部Ｓｗ２１が作動し、ＥＣＵ測定結果ファイルＦｉ１とＰＣ測定結果ファイルＦｉ２についての比較検証を実施する。測定結果の差分を元に調整時間が再算出され、より実機に近い動作をするための遅延パラメータファイルＦｉ３が作成される。
　タイミング調整後のシミュレータは、図１３の例ではＰＣ測定結果ファイルＦｉ２に反映され、保存されることを示しているが、適宜の場所に保存可能である。なお上記タイミング調整の手順は、測定結果比較・遅延パラメータ設定部Ｓｗ２１により自動実行されてもよいし、比較結果表示部ＳＷ２２を介してディスプレイ１０７に表示し、開発者の判断により具体的なタイミング調整内容が決定され、反映されてもよい。
　図１４の右側にはタイミング調整後のＰＣシミュレータにおける開始時刻と、終了時刻の例を示している。この例では、実環境機ＳにおけるＥＣＵ実測時間帯（開始時刻ｔｓＥ、終了時刻ｔｅＥ）に対して、パソコンＰＣは処理命令を受け付けた時刻ｔｓＥから時間ｔｓ０遅らせてパソコン処理の開始時刻とし、パソコンＰＣはその終了時刻から時間ｔｅ０経過をもって、実環境機ＳにおけるＥＣＵ実測時間帯の終了時刻ｔｅＥと判断する。つまり、開始前時間ｔｓ０と終了後時間ｔｅ０を設定することで、ＰＣシミュレータにおける時刻を実環境機ＳにおけるＥＣＵの時刻に近づけたものである。
　以上の流れを図１４に整理すると、以下のようである。まず実ＥＣＵとパソコンＰＣでＥＣＵアプリケーションソフトＳＷ１、ＳＷ４を実行し、測定ポイント（関数の開始、終了）で時間を記録する。実ＥＣＵでの測定タイミングを図１４の左側に、ＰＣシミュレータでの実行タイミングを図１４の中央に記す。パソコンＰＣ上の性能比較ソフトＳＷ２にて、ＥＣＵでの測定結果とパソコンＰＣでの測定結果を比較し、性能差を埋めるための遅延量を計算し、遅延パラメータファイルＦｉ３に遅延量を格納する。
　次にＰＣシミュレータを実行する際は、更新された遅延パラメータ情報を読み込み、関数の開始時と終了時に遅延処理を実行したうえで、ＥＣＵアプリケーションソフトＳＷ１を実行する。遅延処理を実行した場合の処理タイミングを図１４の右側に記す。ＥＣＵでの処理タイミング（図１４の左側）とＰＣシミュレータでの実行時間が近づいていることが分かる。
　以上の実施例６において、ＥＣＵ測定結果ファイルＦｉ１には、実ＥＣＵで測定した実行時間、タイミングが記憶されている。ここでＥＣＵ測定結果ファイルＦｉ１に記憶された実行時間、タイミングは、ＰＣ測定結果ファイルＦｉ２に記憶された実行時間、タイミングを合致させるための目標データと言えるものである。実施例６では実環境機Ｓにおいて目標データを計測してから、パソコンＰＣ側での計測、並びに比較を行うという手順を示しているが、目標データが予め得られ、ＥＣＵ測定結果ファイルＦｉ１にデータ確保されているのであれば、実環境機Ｓでの計測を毎回実行する必要がないことは言うまでもない。
　また上記実施例では、パソコンＰＣの方が実環境機Ｓよりも処理が速い、従ってタイミング調整処理は遅延時間の処理であることを前提として述べているが、実施例３などで述べたように、これはパソコンＰＣの方が実環境機Ｓよりも処理が遅い場合であっても対応可能である。これら両者を含む意味合いでは、遅延処理とは、タイミング調整処理というのが適切である。本発明は広い意味ではタイミング調整を行ったものである。
　なお本発明におけるタイミング調整は、必ずしもＥＣＵに完全合致させることを意図してはいない。例えば９０％程度合致させることができれば、シミュレーション上の大きな不利益を生じるものではないといえる。
　また本発明の場合に実環境機Ｓは例えばＥＣＵであり、ＥＣＵはその内部にアプリケーションソフト実行時にそのタイミングを計測する性能測定機能を備えており、かつ測定結果を記憶するＥＣＵ測定結果ファイルを保持していることが本発明の特徴である。
　実施例７では、図１５～図２１を使用し、シングルタスクで動作するプログラムに対し、タイミング調整機能を適用した場合の具体的な処理例を説明する。
　図１５は、図５に例示したと同じ本発明で使用するＣ言語プログラム例を示す図である。Ｃ言語の詳細説明は割愛するが、図１５に記載するＣ言語プログラムは、１０ｍｓ周期で処理を行うＭａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の中で、小さい処理単位を実行する３組のｆｕｎｃ関数としてｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）を実行する単純なプログラムである。これにより、Ｍａｉｎ関数１７１で規定する制御周期である１０ｍｓ内で、ｅｅｐｒｏｍからのｒｅａｄ処理、ｎｗへのｓｅｎｄ処理、ｅｅｐｒｏｍへのｗｒｉｔｅ処理が実行される。なお、Ｃ言語プログラムは、その処理開始時刻、終了時刻を記憶する機能を有している。
　本発明の実施例におけるパソコンＰＣ、及び実環境機Ｓにおける処理は、上記したＣ言語プログラムにより実行される。図１６は、遅延量決定及びタイミング調整のために実行されるパソコンＰＣ、及び実環境機Ｓにおける処理内容を示す概略フローチャートである。
　図１６の右側にはパソコンＰＣにおける処理内容、図１６の左側には実環境機Ｓにおける処理内容を例示している。
　図１６の処理フローでは、最初に実ＥＣＵ側の処理ステップＳ１４１において実行時間計測を行う。プログラム内に記載されている性能測定コードを実行する事により、処理ステップＳ１４２において実行タイミングを記録する。処理ステップＳ１４３において実ＥＣＵで記録した実行タイミングを実ＥＣＵの測定結果送信部ＳＷ４２から同一ネットワーク上につながっているパソコンＰＣ側へ送信する。パソコンＰＣ側では、受信した測定結果をＥＣＵ測定結果ファイルＦｉ１として保存する。
　次にパソコン側では、処理ステップＳ１４４においてＰＣシミュレーション環境でプログラムを実行し、実行タイミングを記録する。パソコンＰＣ内に存在する遅延パラメータファイルＦｉ３の設定値を使用して、プログラム内に記載されている性能測定コードを実行する事により、実行タイミングを記録する。また処理ステップＳ１４５においてＰＣシミュレーション環境で記録した実行タイミングをＰＣ測定結果ファイルＦｉ２に保存する。
　図１７は、上記処理により作成されたＥＣＵ測定結果ファイルＦｉ１、ＰＣ測定結果ファイルＦｉ２に形成されるデータ構成例を示している。これらのファイルは同一形式で作成されており、ＥＣＵとパソコンＰＣで記録する情報は同じである。
　図１７のファイルＦｉ１、Ｆｉ２の横軸項目としては、時間（３０１、３０５）、動作タスク（３０２、３０６）、関数名（３０３、３０７）、測定タイミング（開始・終了）（３０４、３０８）の４つの情報を記録する。Ｃ言語プログラムによる測定対象の関数の開始部と終了部に存在する時刻計測コードを使用して、実行時間と動作タスクを記録している。本実施例ではシングルタスクの例を示しており、タスク３０２、３０６は一つなので、すべて同じタスクＡである。
　このＥＣＵ測定結果ファイルＦｉ１によれば、タスクＡについてＭａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の開始時刻がｔ０、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の開始時刻がｔ２、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の終了時刻がｔ６、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の開始時刻がｔ９、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の終了時刻がｔ１１、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の開始時刻がｔ１２、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の終了時刻がｔ１３、Ｍａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の終了時刻がｔ１４であり、上記順番にてデータ生成されたことを表している。
　同様にＰＣ測定結果ファイルＦｉ２によれば、タスクＡについてＭａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の開始時刻がｔ０、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の開始時刻がｔ１、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の終了時刻がｔ３、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の開始時刻がｔ４、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の終了時刻がｔ５、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の開始時刻がｔ７、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の終了時刻がｔ８、Ｍａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の終了時刻がｔ１０であり、上記順番にてデータ生成されたことを表している。
　図１８は、タイミング調整前後の時間関係を示す図である。図１８の左側の２列には、図１７の時間関係を計測したときの状況が示されている。ＥＣＵについてみると、親関数１７１が規定する１０ｍｓの中で、子関数１７２、１７３、１７４が順次実行されており、各開始、終了の時刻が左側縦軸に記載されている。またパソコンＰＣについても親関数１７１の中で、子関数１７２、１７３、１７４が順次実行されているが、各開始、終了の時刻が記載されているように、実環境機Ｓに比較して高性能、高速のパソコンＰＣの場合には、親関数１７１が規定する１０ｍｓの時間経過前に一連の子関数の処理を完了してしまっている。
　ＥＣＵとパソコンＰＣの測定結果がそろった後で、性能比較ソフトＳＷ２を使用して測定結果の比較を行い、ＰＣシミュレーション環境で注入する遅延量を決定し、遅延パラメータファイルＦｉ３を更新する。この間の処理である遅延パラメータファイルＦｉ３更新の具体的な処理フローを図１９に示している。
　図１９の処理フローの最初の処理である処理ステップＳ１５１では、遅延パラメータファイルＦｉ３から遅延量を取得し、処理ステップＳ１５２においてＰＣシミュレーション環境で遅延パラメータファイルＦｉ３を使用した時刻測定を実施し、処理ステップＳ１５３において実行結果をＰＣ測定結果ファイルＦｉ２へ格納する。この間の処理フローは図１６に記載の内容のとおりである。なお、上記一連の処理は遅延パラメータを変更しながら複数回繰り返し実行されるので、処理ステップＳ１６０において実行回数を更新しながら繰り返し回数をカウントする。
　処理ステップＳ１５４ではＥＣＵ測定結果とＰＣ測定結果を比較し、性能差を算出するが、この具体的な処理内容について説明する。この場合に、実行時間を比較したいＣ言語プログラムによる関数（Ｍａｉｎ関数と、複数のＦｕｎｃ関数）は複数あり、それぞれの関数間で呼び出し関係があることから、性能比較、処理の小さいグループ（他から呼び出されない関数）から実施していく。
　図２０は、性能比較前の初期状態における遅延パラメータテーブルの一例を示している。この図では、横軸項目として関数名、タスク名、呼び出し元関数名、調整グループ１８１、開始、終了の区別、遅延量、備考の欄を設けている。関数名は図１５の例で言えば、親関数であるＭａｉｎ関数１７１、子関数であるｆｕｎｃ関数１７２、１７３、１７４であり、開始、終了の区別ごとに行わけして記載している。呼び出し元関数名は、子関数からみたときの親関数を記述しており、性能比較前の初期状態であるため遅延量の欄は０に設定されている。またこの表では、親子の関係毎に調整グループ１８１が設定されており、親関数側に調整グループ「２」が設定され、子関数側に調整グループ「１」が設定されている。
　処理ステップＳ１５４における調整の順番は、図２０の遅延パラメータテーブルに記載の調整グループ１８１の小さいものから順に実施していく。本実施例では一番小さい関数として、調整グループ「１」にランク付けされたｆｕｎｃ関数１７２、１７３、１７４である（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数が先行して選択され、この順序で実行されていく。
　図１７、図１８に例示した時間関係で説明すると、実ＥＣＵでの（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の、開始、終了の実行時間はそれぞれ、（ｔ６－ｔ２）、（ｔ１１－ｔ９）、（ｔ１３－ｔ１２）であり、ＰＣシミュレーション環境での実行時間はそれぞれ（ｔ３－ｔ１）、（ｔ５－ｔ４）、（ｔ８－ｔ７）である。
　図１９の処理フローの処理ステップＳ１５５では、最初に子関数（ｅｅｐｒｏｍ＿ｒｅａｄ）について、実ＥＣＵとＰＣシミュレーション環境での実行時間の差が閾値よりも大きいかどうかを判定し、閾値よりも大きい場合、処理ステップＳ１５６に移動してＰＣシミュレーション環境で指定時間分の遅延処理を実行するための遅延量計算処理を行う。子関数（ｅｅｐｒｏｍ＿ｒｅａｄ）の場合、実行時間の差は（（ｔ６－ｔ２）-（ｔ３－ｔ１））として算出される。
　処理ステップＳ１５７では、関数ごとに遅延量を更新する。最初に子関数（ｅｅｐｒｏｍ＿ｒｅａｄ）について遅延量を更新する。ここではＰＣシミュレーション環境で実行時間の差分分だけ、遅延処理を入れるものとし、これにより実ＥＣＵでの処理時間に近づけられる。遅延量調整は、関数開始時と、関数終了時の２か所で入れるため、実行時間の差を２分割した量が遅延量として遅延パラメータファイルＦｉ３に書き込まれる。
　なお、その後の繰り返し処理により求められる（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の実行時間の差はそれぞれ、（（ｔ１１－ｔ９）-（ｔ５－ｔ４））、（（ｔ１３－ｔ１２）-（ｔ８－ｔ７））である。これらに対しても順次処理ステップＳ１５６、処理ステップＳ１５７の処理が実行され、子関数ごとの遅延量が定められていく。
　図２１は、図２０の初期状態の遅延パラメータテーブルに子関数ごとの遅延量を反映させた第一段階（ｓｔｅｐ１）での遅延パラメータテーブルを示している。従ってここには、子関数である（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の遅延量の更新データが反映されている。１８２～１８７の６か所に先ほど計算した遅延量が書き込まれている。
　なお遅延処理の例としては、タスクをスリープさせるのではなく、遅延させる時間分無駄な演算や、無駄なｗｈｉｌｅループの実行などをする処理になる。
　次に図１９の処理ステップＳ１５８では、子関数である（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の調整が終わると、タイミング未調整の関数があるかどうかの判定を行う。
　子関数調整終了段階におけるシミュレータ処理の時間関係を仮に図示すると、図１８の右から２番目の「Ｓｔｅｐ１」のようになっている。ＥＣＵとの関係では、子関数通しは概ね時間関係が合致した状況になっている。子関数調整終了段階では、全体としては４３１に示す時間長だけＥＣＵの実行時間に近づいているが、未だ時間長４３２の部分で、時間が合致していない。
　次の第二段階（ｓｔｅｐ２）では、図２０の遅延パラメータテーブルに記載の調整グループ「２」に記述された関数（前述の子関数を呼び出している親関数）である（１０ｍｓ＿ｆｕｎｃ）関数についての、実行タイミング調整を行う。親関数のタイミング調整処理は、図１９の処理ステップＳ１５８において子関数の全数完了を確認し、処理ステップＳ１５９で実施回数を０に初期化した後に開始する。親関数のタイミング調整処理は、子関数の場合と同様に処理ステップＳ１５１、Ｓ１５２、Ｓ１５３、Ｓ１６０、Ｓ１５４、Ｓ１５５、Ｓ１６１、Ｓ１５６、Ｓ１５７を順次、必要回数だけ繰り返し実行することで達成される。
　図１９の処理ステップＳ１５１の処理から再度実行し、実ＥＣＵとの性能差を再度測定したときの実行タイミングは、図１８の右側に「Ｓｔｅｐ２」として記述されるものであり、時間長４３２の部分が解消された実行タイミングとされている。この実行タイミングは、時間長さ４３２について、その半分の時間長の分だけ、親関数実行開始タイミングを遅らせたものである。従って、パソコン環境下では、親関数実行終了タイミングから時間長さ４３２の半分の時間経過後のタイミングが、ＥＣＵ環境下での終了タイミングに合致するはずである。
　図１９の一連の処理によれば、最初に子関数について遅延処理を実行し、その後に親関数に遅延処理を実行することで、終了するが、この終了判断は、処理ステップＳ１５８においてタイミング未調整の関数がないことを確認することで完結とする。
　なお一連の処理では、付随的に以下の処理を行うのがよい。まず処理ステップＳ１６１では、関数の遅延処理の繰り返し回数が予め定めた上限（図２０の例では、関数数４＊開始、終了の２で定まる８）の範囲内での繰り返し処理を許可し、上限以上の繰り返しを行わないものとするのがよい。
　また性能比較ソフトＳＷ２を使用しての遅延量調整処理が終わらないケースも想定するのがよい。その時の性能調整フローを図１９で説明する。例えば、一関数の実施タイミングが変わった影響で別関数の動作が変わることが考えられる。これまでエラー処理に流れていたものが、正常処理に切り替わる場合などが例として挙げられる。
　図１９では、処理ステップＳ１５５の判定条件で性能差が閾値未満にならずに、処理ステップＳ１６１の判定条件がＹｅｓの場合（実施回数が上限を超えた場合）、閾値を変更する。図１９の処理ステップＳ１６２において、許容する性能差を緩和し、遅延量調整を行う。再調整を行い、実施回数が上限に到達し、なお性能差が閾値未満にならない場合（判定条件である処理ステップＳ１６３の結果がＮｏの場合）は、タイミング調整ができないと判定し、図１９の処理ステップＳ１６４において、遅延パラメータファイルＦｉ３の内容を初期化（遅延注入なし）し、性能調整処理を終了する。
　以上により、パソコンＰＣ１台に対するＰＣシミュレーション環境の遅延量調整処理が終わる。一般には、開発者ごとに使用しているパソコンＰＣの種類（ＨＷ仕様）が異なるが、パソコンＰＣ毎に遅延量調整を行う事により、開発者毎のＰＣシミュレーション環境での実行タイミングを実ＥＣＵに近づけることが可能となる。
　実施例７ではシングルタスク環境で遅延量決定、タイミング調整を行うことを説明したが、ＥＣＵアプリケーションソフトはマルチタスク環境で動作することが多い。
　マルチタスク環境では、タスクの優先順位に基づいたコンテキスト切り替えが発生する。コンテキスト切り替えが発生するかどうかにより関数の終了時間が変わってしまう。
　実施例８では、性能比較ソフトＳｗ２での関数の実行時間計算時に、動作タスク情報を考慮することでコンテキスト切り替えが発生した場合でも実際に処理を行った時間を計算することができる。
　本実施例で使用する２つのタスクの情報を図２２に示し説明する。
　図２２にはタスクのコンテキスト切り替えが発生した場合の測定結果ファイルの内容と各タスクの実行タイミング例を示している。
　この例では、ＡとＢのタスクがあり、Ａ、Ｂ共にタイマイベントで起動し、周期的に処理を行うタスクであるが、タスクＢの優先度が高く、タスクＡの実行中に優先度の高いタスクＢが起動される。
　時系列的には、タスクＡがタイマイベント２０１を契機に時刻ｔ０から処理を開始する。タスクＡの処理実行中に、タスクＢのタイマイベント２０２が時刻ｔ１において発行された場合、優先度の関係からタスクＡの実行を中断し、タスクＢの処理を開始する。その後時刻ｔ２においてタスクＢの処理が終了、タスクＡの処理が再開し、最終的にタスクＡは時刻ｔ３で終了となる。
　このとき、タイミングを調整する為に記憶する開始、終了時間はタスクごとに管理しており、各タスクは上記開始、終了時刻を記憶している。図２３は、各タスクが記憶した開始、終了時刻の一例である。マルチタスクの場合には、他タスクが動作している間の時間を関数の実行時間から減算することにより、実際の実行時間を算出する。
　例えば、タスクＡの関数（ｆｕｎｃ＿ａ）の開始、終了時間をｔ０、ｔ３、タスクＢの関数（ｆｕｎｃ＿ｂ）の開始、終了時間をそれぞれｔ１、ｔ２とした場合、タスクＢに割り込まれたタスクＡの実行時間は（（ｔ３－ｔ０）－（ｔ２－ｔ１））で計算することが出来る。
　上記説明の本発明では、ＥＣＵソフト内で時間計測機能と遅延注入機能を持たせる。実ＥＣＵとＰＣシミュレーション環境でソフトを実行し、実行タイミング（起動後の経過時間）を記録する。
　実ＥＣＵとＰＣシミュレータでの実行タイミングを保存した処理タイミングデータの内容を比較し、処理時間の差からＰＣシミュレータで注入する遅延量を決定し、ファイルへ保存する機能を備えた性能比較ソフトを用意する。
　性能比較ソフトを実行により更新された遅延パラメータファイルの情報を使用してＰＣシミュレーション環境でＥＣＵアプリケーションソフトを再度実行する。ＰＣシミュレーション環境で調整済みの遅延量で遅延処理を行う事でＰＣシミュレーション環境での実行タイミングを実ＥＣＵへ近づけることができる。
　時刻測定は、実行タイミングを調整したい関数の開始時と終了時で記録する。また遅延処理を入れる場所は、関数開始時の時刻計測直後と、関数終了直前の時刻計測直前で行う。どちらか一方で遅延処理を実行する事も出来るし、両方で遅延処理を入れることも可能である。
　ＥＣＵの試作ＨＷが出来ていないタイミングでは、ＣＰＵの評価ボードや、開発のベースとなっているＥＣＵハードウェアを使用することで、ＥＣＵでの実行タイミング情報として保存し、それを実ＥＣＵでの実行タイミングとして利用することも可能である。
１０１：システム・バス
１０２：ＣＰＵ
１０３：主記憶装置
１０４：ＨＤＤ
１０５：キーボード
１０６：マウス
１０７：ディスプレイ
１０８：ＲＯＭ
Ｓ：実環境機
ＰＣ（ＰＣａ、ＰＣｂ・・・ＰＣｎ）：パソコン
１８０：通信装置
１８１：外部システム・バス
Ｓｗ１：ＥＣＵアプリケーションソフト
Ｓｗ２：性能比較ソフト
Ｓｗ３：通信ソフト
ＳＷ１１：遅延注入機能
ＳＷ１２：性能測定機能
ＳＷ２１：測定結果比較・遅延パラメータ設定部
ＳＷ２２：比較結果表示部
ＳＷ３１：測定結果受信部
Ｆｉ１：ＥＣＵ測定結果ファイル
Ｆｉ２：ＰＣ測定結果
Ｆｉ３：遅延パラメータファイル
ＳＷ４：ＥＣＵアプリケーションソフト
ＳＷ４１：性能測定機能
ＳＷ４２：測定結果送信部
Ｆｉ４：ＥＣＵ測定結果ファイル

Claims (10)

  1. 　第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、前記第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機で構成されたことを特徴とするシミュレーション装置。
  2. 　請求項１に記載のシミュレーション装置であって、
    　前記第１の計算機は、通信装置を介して前記第２の計算機に接続されており、前記第２の計算機は当該第２の計算機でアプリケーションソフトを実行したときの前記第２の処理タイミングを得る第２の性能測定機能を備えることを特徴とするシミュレーション装置。
  3. 　第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、前記第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機と、
    　アプリケーションソフトを実行したときの処理タイミングを前記第２の処理タイミングとして得る第２の性能測定機能を備える第２の計算機と、
    　前記第１の計算機と前記第２の計算機を接続する通信装置を備えることを特徴とするシミュレーション装置。
  4. 　請求項１から請求項３のいずれか１項に記載のシミュレーション装置であって、
    　前記タイミング調整機能は、前記第２の処理タイミングを目標タイミングとして前記第１の処理タイミングを合わせることを特徴とするシミュレーション装置。
  5. 　請求項１から請求項４のいずれか１項に記載のシミュレーション装置であって、
    　前記アプリケーションソフトは、親関数の中で子関数が実行されるとともに親関数並びに子関数の関数開始時刻および関数終了時刻が記録される言語で記述されていることを特徴とするシミュレーション装置。
  6. 　請求項５に記載のシミュレーション装置であって、
    　前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整は、前記子関数のタイミング調整完了後に、前記親関数のタイミング調整が行われることを特徴とするシミュレーション装置。
  7. 　請求項１から請求項６のいずれか１項に記載のシミュレーション装置であって、
    　前記第２の計算機は、ＥＣＵであることを特徴とするシミュレーション装置。
  8. 　請求項１から請求項７のいずれか１項に記載のシミュレーション装置であって、
    　複数の前記第１の計算機が、通信装置を介して接続されていることを特徴とするシミュレーション装置。
  9. 　アプリケーションソフトを実行したときに第２の処理タイミングを入手するための性能測定機能と、前記第２の処理タイミングを記憶する測定結果記憶部と、前記第２の処理タイミングを外部に送信するための通信装置を備えることを特徴とするＥＣＵ装置。
  10. 　第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングと、第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うことを特徴とするシミュレーション方法。
PCT/JP2019/025303 2018-07-19 2019-06-26 シミュレーション装置、及びその方法、並びにｅｃｕ装置 WO2020017264A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US16/973,315 US20210248288A1 (en) 2018-07-19 2019-06-26 Simulation device, simulation method, and ecu device
DE112019002778.6T DE112019002778T5 (de) 2018-07-19 2019-06-26 Simulationsvorrichtung, simulationsverfahren und elektronische steuereinheitsvorrichtung
JP2020531204A JP7045458B2 (ja) 2018-07-19 2019-06-26 シミュレーション装置、及びその方法、並びにｅｃｕ装置
CN201980031431.5A CN112400162A (zh) 2018-07-19 2019-06-26 模拟装置及其方法、以及ecu装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-135829 2018-07-19
JP2018135829 2018-07-19

Publications (1)

Publication Number Publication Date
WO2020017264A1 true WO2020017264A1 (ja) 2020-01-23

Family

ID=69164715

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/025303 WO2020017264A1 (ja) 2018-07-19 2019-06-26 シミュレーション装置、及びその方法、並びにｅｃｕ装置

Country Status (5)

Country Link
US (1) US20210248288A1 (ja)
JP (1) JP7045458B2 (ja)
CN (1) CN112400162A (ja)
DE (1) DE112019002778T5 (ja)
WO (1) WO2020017264A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022144820A (ja) * 2021-03-19 2022-10-03 パナソニックＩｐマネジメント株式会社 検証システム、検証方法及びプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7072697B1 (ja) * 2021-03-12 2022-05-20 三菱電機株式会社 電子制御装置、電子制御装置の試験装置、及び電子制御装置の試験方法
CN115202495B (zh) * 2022-09-08 2022-12-16 深圳市湘凡科技有限公司 鼠标硬件的模拟移动方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012203845A (ja) * 2011-03-28 2012-10-22 Denso Wave Inc 携帯機器とプログラム実行装置を有するシステムと、そのシステムに用いられる携帯機器及びプログラム実行装置
JP2015170081A (ja) * 2014-03-06 2015-09-28 三菱電機株式会社 シミュレーション装置及びシミュレーションプログラム

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2182826B (en) * 1985-11-20 1990-08-01 Stc Plc Data transmission system
US20020194618A1 (en) * 2001-04-02 2002-12-19 Matsushita Electric Industrial Co., Ltd. Video reproduction apparatus, video reproduction method, video reproduction program, and package media for digital video content
US7730450B2 (en) * 2004-08-12 2010-06-01 National Instruments Corporation Automatic versioning and data mutation of user-defined data types
EP1788485A4 (en) * 2004-08-23 2012-09-26 Gaia System Solutions Inc SOURCE PROGRAM ANALYSIS DEVICE AND METHOD
JP4728020B2 (ja) * 2005-03-17 2011-07-20 日立オートモティブシステムズ株式会社 車両制御用ソフトウェア及び車両制御装置
JP2008059192A (ja) * 2006-08-30 2008-03-13 Oki Electric Ind Co Ltd ハード・ソフト協調検証用シミュレータ
JP5209059B2 (ja) * 2008-10-24 2013-06-12 インターナショナル・ビジネス・マシーンズ・コーポレーション ソース・コード処理方法、システム、及びプログラム
US8336036B2 (en) * 2008-11-21 2012-12-18 Korea University Industrial & Academic Collaboration Foundation System and method for translating high programming level languages code into hardware description language code
CN102043707B (zh) * 2009-10-16 2014-12-31 腾讯科技（深圳）有限公司 嵌入式应用的性能测试方法、嵌入式终端设备及网络系统
CN101694628B (zh) * 2009-10-21 2012-07-04 中国人民解放军国防科学技术大学 一种串行与并行模拟相结合的并行计算机系统性能模拟方法
CN103154890B (zh) * 2010-10-12 2016-04-13 富士通株式会社 模拟装置、方法以及程序
JP2013109673A (ja) * 2011-11-22 2013-06-06 Fujitsu Semiconductor Ltd シミュレーション装置、シミュレーション方法、およびシミュレーションプログラム
US9368027B2 (en) * 2013-11-01 2016-06-14 Here Global B.V. Traffic data simulator
JP6378128B2 (ja) * 2015-04-28 2018-08-22 ルネサスエレクトロニクス株式会社 性能検証装置、システム、方法、およびコンピュータに当該方法を実行させるためのプログラム
EP3179371A1 (en) * 2015-12-08 2017-06-14 Gilwa GmbH embedded systems Method and device for non-intrusively collecting function trace data
JP2018022317A (ja) * 2016-08-03 2018-02-08 ルネサスエレクトロニクス株式会社 Ｈｉｌシミュレーションシステム及びその制御方法
EP3285165A1 (de) * 2016-08-18 2018-02-21 dSPACE digital signal processing and control engineering GmbH Modifizieren und simulieren der betriebssoftware eines technischen systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012203845A (ja) * 2011-03-28 2012-10-22 Denso Wave Inc 携帯機器とプログラム実行装置を有するシステムと、そのシステムに用いられる携帯機器及びプログラム実行装置
JP2015170081A (ja) * 2014-03-06 2015-09-28 三菱電機株式会社 シミュレーション装置及びシミュレーションプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022144820A (ja) * 2021-03-19 2022-10-03 パナソニックＩｐマネジメント株式会社 検証システム、検証方法及びプログラム
JP7336775B2 (ja) 2021-03-19 2023-09-01 パナソニックＩｐマネジメント株式会社 検証システム、検証方法及びプログラム

Also Published As

Publication number Publication date
US20210248288A1 (en) 2021-08-12
JP7045458B2 (ja) 2022-03-31
DE112019002778T5 (de) 2021-05-20
CN112400162A (zh) 2021-02-23
JPWO2020017264A1 (ja) 2021-05-13

Similar Documents

Publication Publication Date Title
US11074049B2 (en) Method and system for generating program code modified by rule sets
WO2020017264A1 (ja) シミュレーション装置、及びその方法、並びにｅｃｕ装置
US20190258460A1 (en) Method and system for generating a software component
JP5270330B2 (ja) マルチコアマイコンシステムのシミュレーション方法及びシミュレーション装置
CN106980597B (zh) 片上系统验证方法及验证系统
EP3364296B1 (en) Simulating execution-time variations and scheduling in a block-oriented simulation system
CN110554861B (zh) 具有编译和读取-评估-打印-循环操作的软件开发环境
JP6874706B2 (ja) アプリケーションプログラムを生成する方法、装置、プログラム
US11126408B2 (en) Incremental code generation method
US10467120B2 (en) Software optimization for multicore systems
US10585650B1 (en) Method and system for generating program code
JP7003259B2 (ja) シミュレーション装置
Naderlinger Simulating execution time variations in MATLAB/Simulink
US20240061984A1 (en) A method for an automatic design and verification of a processor's programming and verification tools
US11719749B1 (en) Method and system for saving and restoring of initialization actions on dut and corresponding test environment
US20240176926A1 (en) Method and system for simulating a control program
Jämbäck Evaluation of Real-Time Linux on RISC-V processor architecture
JPH07253909A (ja) マイクロプログラム検証方法
Colnaric State of the art review paper: advances in embedded hard real-time systems design
CN117850923A (zh) 一种针对复杂系统的状态机仿真方法
Chauhan Modeling the Effects of AUTOSAR Overhead on Automotive Application Software Timing and Schedulability
Farcas et al. The TDL advantage
CN117785645A (zh) 一种risc-v指令集的验证方法、装置和电子设备
Chen et al. Timed Model-Based Mutation Operators for Simulink Models
JP2023066414A (ja) プログラムコードを生成する方法、制御装置を設定する方法およびコンピュータシステム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19837177

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2020531204

Country of ref document: JP

122 Ep: pct application non-entry in european phase

Ref document number: 19837177

Country of ref document: EP

Kind code of ref document: A1