Simulation method

Abstract

To highly accurately reproduce software execution timing in a target environment on a host environment while taking a distributed hardware configuration into consideration.SOLUTION: A simulation method includes: extracting a first host feature amount 11 obtained by executing first software 10 on a host environment 100; executing the first software 10 on a target environment 110 to thereby calculate target execution time 20 required for executing the first software 10 on the target environment 110; calculating a difference in performance between the host environment 100 and the target environment 110 on the basis of the first host feature amount 11 and the target execution time 20; extracting a second host feature amount 13 obtained by executing second software 12 on the host environment 100; and estimating time 40 required for executing the second software 12 on the target environment 110 on the basis of the second host feature amount 13 and the difference in performance.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present invention relates to a simulation method.

Background Art

[0002] As an existing technology for bringing the execution timing of a PC simulation environment closer to that of an actual ECU, there is the technology described in Patent Document 1. In Patent Document 1, the purpose is to provide a simulation device having a function of adding a delay process for bringing the execution timing of a PC simulation environment closer to that of an actual ECU. And as a solution means, it is a simulation device for converting application software into an execution code for verification and transplanting the verified execution code to another computer device, and performing time adjustment processing at the start or end of a function in units of functions of the source code of the application to adjust the execution timing in another computer device. A simulation device is described.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] According to the method described in Patent Document 1, it is possible to perform a simulation by bringing the execution timing closer to that of an actual ECU by performing time adjustment processing at the start or end of a function in units of functions of software. However, in Patent Document 1, although the execution timing is adjusted based on the speed ratio (CPU clock number ratio) between the simulation device and the computer device, the characteristics of the program such as cache and bus and the characteristics of the microcomputer are not considered to affect the execution time. Therefore, the problem is that the adjustment accuracy is not sufficient with the speed ratio alone.

[0005] In addition, Patent Document 1 does not consider a distributed hardware configuration. Therefore, there is a problem that latency due to differences in communication timing when two functions (software) operate on separate hardware cannot be reproduced.

[0006] Therefore, it is an issue to accurately reproduce the target (actual ECU) environment on the host (PC simulation) environment in consideration of the distributed hardware configuration.

Means for Solving the Problems

[0007] The simulation method for solving the above problems extracts a first host feature amount obtained by executing a first software on a host environment, calculates a target execution time required to execute the first software on a target environment by executing the first software on the target environment, calculates a performance difference between the host environment and the target environment based on the first host feature amount and the target execution time, extracts a second host feature amount obtained by executing a second software on the host environment, and estimates the time required to execute the second software on the target environment based on the second host feature amount and the performance difference.

Effects of the Invention

[0008] According to the present invention, the target environment is accurately reproduced on the host environment for developing software in consideration of the distributed hardware configuration. That is, the target environment is simulated on the host environment. Therefore, it becomes possible to verify whether the software can operate normally on the target environment without actually transplanting the software to the target environment, and the development efficiency of the software is improved. Further features related to the present invention will become apparent from the description of this specification and the accompanying drawings. Also, problems, configurations, and effects other than those described above will be clarified by the description of the following embodiments.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Mode for Carrying Out the Invention

[0010] This embodiment relates to a software simulation method. Hereinafter, an example (embodiment) of an embodiment suitable for the present invention will be described.

[0011] [Embodiment 1] <Configuration of the Host Environment> FIG. 1 is a diagram showing the configuration of a host environment (cloud) 100 in the present invention. The host environment 100 in this embodiment is for the purpose of developing and verifying the software part in the cooperative automatic driving system with traffic control. Here, the hardware configuration in the cooperative automatic driving system with traffic control has a configuration including an infrastructure sensor 101, a traffic control device 102, and a vehicle 103. Further, at least one or more microcontrollers 1030 are mounted on the vehicle 103.

[0012] Existing software 10 and new software 12 are installed on the host environment 100. These are software that is executed on the infrastructure sensor 101, the traffic control device 102, and the vehicle 103 in an actual environment. Further, since the host environment 100 does not have actual sensors 1040 and actuators 1041, the simulator 104 has existing software 10 that simulates the sensors 1040 and actuators 1041.

[0013] The new software 12 is developed on the host environment 100 and transplanted to the target environment 110 (see FIG. 2). Each software exhibits functions such as object recognition, path planning, and calculation of control command values. In FIG. 1, the new software 12 is shown as software installed in the microcontroller 1030 in the vehicle 103, but the new software 12 may be installed in another device.

[0014] <Configuration of Target Environment> FIG. 2 is a diagram showing the configuration of a target environment (controller) 110 in the present invention. The target environment 110 has an actual hardware configuration in the control cooperation automatic driving system. For example, the target environment 110 in FIG. 2 is a microcomputer 1030 mounted on a vehicle 103.

[0015] Regarding the peripherals (built-in devices, peripheral devices, etc.) of the target environment 110, as shown in FIG. 2, the PC 120 may simulate them, or may actually have an infrared sensor 101, a control device 102, and a vehicle 103. When having an actual hardware configuration, since a sensor 1040 and an actuator 1041 are mounted on the vehicle 103, the simulator 104 becomes unnecessary. Similarly, since each hardware exists, the PC 120 also becomes unnecessary. As described above, although the new software 12 is developed on the host environment 100, it is transplanted to the target environment 110.

[0016] Also, in FIG. 2, the new software 12 is software implemented in the microcomputer 1030 in the vehicle 103, but the new software 12 may be implemented in another device.

[0017] <Outline of Simulation Method> FIG. 3 is a diagram showing the outline of the simulation method in the first embodiment. The simulation method according to this embodiment is executed by a host feature amount acquisition unit 1, a target execution time acquisition unit 2, an execution time estimation model creation unit 3, a target execution time estimation unit 4, and a software execution management unit 5.

[0018] The host feature amount acquisition unit 1 is, for example, a functional unit mounted on the host environment 100, and calculates and acquires a host feature amount 11, which will be described later, including information such as execution time when various software is executed under the host environment.

[0019] The target execution time acquisition unit 2 is, for example, a functional unit installed in the target environment 110, and acquires the target execution time 20 required when the existing software 10 is executed on the target environment.

[0020] The execution time estimation model creation unit 3 is, for example, a functional unit installed in the host environment 100, and calculates the performance difference between the host environment 100 and the target environment 110 based on the host feature amount 11 and the target execution time 20. Then, an execution time estimation model 30 for estimating the execution time required when any software is executed on the target environment 110 is created.

[0021] The target execution time estimation unit 4 is, for example, a functional unit installed in the host environment 100, and estimates the execution time required when the new software 12 is executed on the target environment 110 from the execution time estimation model 30 and the new software host feature amount 13 obtained when the new software 12 is executed on the host environment, and generates an estimated execution time 40.

[0022] The software execution management unit 5 is, for example, a functional unit installed in the host environment 100, and manages the execution of software on the host environment 100 based on the estimated execution time 40.

[0023] Hereinafter, each of the above functional units and various data will be described in detail.

[0024] <Host feature amount acquisition unit> FIG. 4 is a diagram showing an outline of the processing flow performed by the host feature amount acquisition unit 1. In step S11, the host feature amount acquisition unit 1 acquires the software for which the feature amount is to be measured. In step S12, the measurement of the feature amount is started at the start of the periodic processing of the software. In step S13, the measurement of the feature amount is ended at the end of the periodic processing of the software, and the feature amount is saved.

[0025] In step S14, it is determined whether the execution result of the software satisfies the measurement end condition. If the measurement end condition is satisfied, the process proceeds to step S15. If the measurement end condition is not satisfied, the process returns to step S12. The measurement end condition can be determined from, for example, whether a certain period of time has elapsed, whether the software has reached the destination by autonomous driving if it is related to autonomous driving, or whether an error such as the inability to continue autonomous driving has occurred. Also, a combination of multiple measurement end conditions may be used.

[0026] In step S15, among the feature amounts saved in step S13, the feature amount at the worst execution time is extracted. Here, the worst execution time refers to the longest time required to execute a specific calculation task on a specific hardware. In this embodiment, on the host environment 100, it refers to the longest period obtained when the existing software 10 or the new software 12 is executed a certain number of times or more in a cycle. By extracting the feature amount at the worst execution time on the host environment 100, it is expected that the worst execution time on the target environment 110 can be reproduced when simulating the execution on the target environment 110 on the host environment 100, and the accuracy of verification can be ensured. In step S16, the feature amount extracted in step S15 is output as the host feature amount 11. The host feature amount acquisition unit 1 acquires the host feature amount 11 through such a procedure.

[0027] <Host Feature Amount> FIG. 5 is a diagram showing an example of the host feature amount 11 described above. The host feature amount 11 is output as a feature amount acquired for each cycle for each software. The types of feature amounts shown in FIG. 5 are an example, and candidates for the target of the feature amount are listed below. · Execution time: The time required for the execution of the software. · Number of CPU cycles: The number of CPU cycles required for the execution of the software. The value obtained by dividing this by the CPU frequency is the execution time. · Number of cache misses: When a cache miss occurs, processing that requires time, such as memory access, becomes necessary. Also, cache misses occur in the LLC (Last Level Cache), L1, and L2. · Number of context switches: When the CPU is used for a process different from the currently executing process, such as interrupt processing, processing for saving and restoring the CPU state occurs. · Number of CPU migrations: When a process moves to another CPU, processing occurs to transfer the CPU state. · Number of retired instructions: These are instructions that were speculatively executed but not used, and since the necessary instructions need to be executed after a branch, the execution time becomes slower. · Number of branch misses: This is the number of branches for which speculative execution failed, and since the necessary instructions need to be executed after a branch, the execution time becomes slower. · Number of store forwards: When an instruction to read from the same memory address is executed after an instruction to write to a certain memory address, data in the buffer rather than the cache is used, and the access times of the cache and buffer are different. · Number of load blocks: This is the number of times data loading failed, and since data loading may be attempted again as needed, the processing increases. · Number of store blocks: This is the number of times data storing failed, and since data storing may be attempted again as needed, the processing increases. · Number of out-of-bounds loads: If an attempt is made to access outside the range accessible by software, an error may occur and normal execution will not occur, so the execution time differs from normal. · Number of access failures due to incomplete addresses: Due to the alignment of incomplete addresses, data does not exist at consecutive addresses and access to another address becomes necessary. · Number of DTLB (Data-Translation Lookaside Buffer) load misses: This is the number of times the requested address was not in the TLB, and it is necessary to refer to the page table for address translation, increasing the processing. · Number of memory disambiguation events: When executing load instructions and store instructions in parallel that are in a dependency relationship, it is necessary to execute the store instruction first, and the load instruction needs to wait for the execution of the store instruction. · Number of memory access retries: The number of memory accesses that have been retried because the memory being accessed has been modified by another core, and additional processing is required for the access. · Number of hardware interrupt events: The number of times a hardware interrupt event has occurred. When an interrupt occurs, save / restore processing is required. · Number of prefetch operations: The number of times the CPU has pre-read data from memory into the cache memory in advance. The access times required for memory and cache are different. · Number of cache lock cycles: The number of cycles the cache has been locked and needs to wait until it is unlocked. · Number of cycles when execution stopped: The number of cycles when execution stopped, which affects the number of cycles of software execution. · Immediately previous executed software: Depending on the cache status of the software executed immediately before, for example, it is conceivable that the data to be read can be read quickly because it is in the cache.

[0028] <Target execution time acquisition unit> Figure 6 is a diagram showing an overview of the processing flow performed by the target execution time acquisition unit 2. In step S21, the target execution time acquisition unit 2 acquires the software for which the execution time is to be measured. In step S22, the measurement of the execution time is started at the start of the periodic processing of the software. In step S23, the measurement of the execution time is ended at the end of the periodic processing of the software, and the execution time is saved.

[0029] In step S24, it is determined whether the execution result of the software satisfies the measurement end condition. If the measurement end condition is satisfied, the process proceeds to step S25. If the measurement end condition is not satisfied, the process returns to step S22. The measurement end condition can be determined, for example, by whether a certain amount of time has elapsed, whether the software has reached the destination by autonomous driving if it is related to autonomous driving, or whether an error such as the inability to continue autonomous driving has occurred. Also, a combination of multiple measurement end conditions may be used.

[0030] In step S25, the worst execution time is extracted from the execution times saved in step S23. In step S26, the worst execution time extracted in step S25 is output as the target execution time 20. In such a procedure, the target execution time acquisition unit 2 acquires the target execution time 20.

[0031] <Target execution time> FIG. 7 is a diagram showing an example of the target execution time 20 in the present invention. In this embodiment, the worst execution time acquired for each software is stored as the target execution time 20.

[0032] <Execution time estimation model creation unit> The host feature amount 11 and the target execution time 20 obtained by the above processing are output to the execution time estimation model creation unit 3. The execution time estimation model creation unit 3 performs machine learning with the host feature amount 11 as an independent variable (explanatory variable) and the target execution time 20 as a dependent variable (objective variable) to generate an execution time estimation model 30. As the machine learning algorithm, a known algorithm such as multiple regression analysis or DNN is used.

[0033] <Execution time estimation model> The execution time estimation model 30 created by the execution time estimation model creation unit 3 is a model that outputs an estimated execution time 40 when a new software host feature amount 13 is input.

[0034] <Target Execution Time Estimation Unit> The target execution time estimation unit 4 receives, as inputs, the execution time estimation model 30 output by the execution time estimation model creation unit 3 and the new software host feature amount 13 obtained by inputting the new software 12 to the host feature amount acquisition unit 1. Then, by inputting the new software host feature amount 13 to the execution time estimation model 30, an estimated execution time 40 estimated to be required when the new software 12 is executed on the target environment 110 is obtained.

[0035] <Estimated Execution Time> The estimated execution time 40 in this embodiment is the predicted worst execution time when the new software 12 is executed on the target environment 110.

[0036] <Software Execution Management Unit> FIG. 8 is a diagram showing an outline of a processing flow performed by the software execution management unit 5. In step S51, the software execution management unit 5 acquires the new software 12 to be the subject of simulation. In step S52, the software execution management unit 5 acquires the estimated execution time 40 from the target execution time estimation unit 4. In step S53, the software execution management unit 5 starts measuring the execution time at the start of the periodic processing of the software. In step S54, the software execution management unit 5 ends the measurement of the execution time immediately before the data output process in the periodic process of the software and saves the execution time.

[0037] In step S55, if the measured execution time is shorter than the estimated execution time 40, then busy-wait for the difference in time. That is, the normal host environment 100 has a higher computing processing ability than the target environment 110. Therefore, the execution time of each process when a certain software is executed on the host environment 100 is shorter than the time estimated to be required to execute that software on the target environment 110. Therefore, by waiting for the difference in time between the estimated execution time and the actual execution time for each process when the software is executed on the host environment 100, it becomes possible to accurately simulate the target environment 110 on the host environment.

[0038] In step S56, perform the output process of the data obtained as a result of the execution of the software. In step S57, determine whether the execution result of the software satisfies the measurement end condition. If the measurement end condition is satisfied, end the process. If the measurement end condition is not satisfied, return to step S53. The measurement end condition can be determined from, for example, whether a certain amount of time has elapsed, whether the software has reached the destination by autonomous driving if it is related to autonomous driving, whether an error such as the inability to continue autonomous driving has occurred, etc. Also, a combination of multiple measurement end conditions may be used. In such a procedure, the software execution management unit 5 executes the new software 12 on the host environment 100 and simulates the execution of the new software 12 on the target environment 110.

[0039] According to the simulation method in the above-described Example 1, by executing the existing software 10 in advance on the host environment 100 and on the target environment 110 respectively, an execution time estimation model 30 capable of estimating the worst execution time on the target environment 110 from the host feature amount 11 is generated. Then, by inputting the new software host feature amount 13 obtained by executing the new software 12 on the host environment 100 into the execution time estimation model 30, it is possible to estimate the worst execution time when the new software 12 is actually executed on the target environment 110 without actually transplanting the new software 12 to the target environment 110. And based on the estimated execution time 40, by executing the new software 12 on the host environment 100 while adjusting the execution time, it is possible to simulate and verify the execution of the new software 12 on the target environment 110 with high precision, so that the new software 12 developed on the host environment 100 can be seamlessly transplanted to the target environment 110.

[0040] [Example 2] Subsequently, the simulation method in Example 2 of the present invention will be described. The difference between Example 2 and Example 1 is that in addition to the information used in Example 1, the device allocation information 50, the data flow information 51, and the inter-device adjustment coefficient information 52 are used to reproduce the communication between software and adjust the execution timing of the software on the host environment 100. For the same configuration as in Example 1, the same reference numerals are given and the description thereof is omitted.

[0041] <Outline of the simulation method> FIG. 9 is a diagram showing the outline of the simulation method in Example 2. In this embodiment, in addition to the estimated execution time 40, the device allocation information 50, the data flow information 51, and the inter-device adjustment coefficient information 52 are input to the software execution management unit 5. The device allocation information 50, the data flow information 51, and the inter-device adjustment coefficient information 52 are stored, for example, in the host environment 100.

[0042] <Device Allocation Information> FIG. 10 is a diagram showing an example of device allocation information 50 in the present invention. The device allocation information 50 indicates information on which device each software is operating on. In this embodiment, for example, software A and software C operate on microcomputer A, and software B operates on microcomputer B.

[0043] <Data Flow Information> FIG. 11 is a diagram showing an example of data flow information 51 in the present invention. The data flow information 51 indicates information on which software each software transmits data to and by what communication method. In this embodiment, for example, software A transmits data to software B using CAN (Controller Area Network), and transmits data to software C within the microcomputer (such as inter-process communication).

[0044] <Inter-Device Adjustment Coefficient Information> FIG. 12 is a diagram showing an example of inter-device adjustment coefficient information 52 in the present invention. The inter-device adjustment coefficient information 52 indicates information on the inter-device adjustment coefficient for setting how much to adjust the timing of data transmission and reception between devices. For example, within the microcomputer, since data can be transmitted and received at high speed, no adjustment is required (the coefficient is 0), but in the case of WiFi (registered trademark), since it is wireless, a large delay to be adjusted is set (the coefficient is 8). The inter-device adjustment coefficient is determined by actually measuring in the target environment 110, or determined from the specifications of the target environment 110 and the size of the data to be transmitted.

[0045] <Software Execution Management Unit> FIG. 13 is a diagram showing an overview of the processing flow performed by the software execution management unit 5 in the second embodiment. In step S51, the software execution management unit 5 acquires new software 12 to be simulated. In step S52, the estimated execution time 40 is obtained from the target execution time estimation unit 4. In step S58, the device allocation information 50 is obtained. In step S59, the data flow information 51 is obtained. In step S5A, the inter-device adjustment coefficient information 52 is obtained.

[0046] In step S53, the measurement of the execution time is started at the start of the periodic processing of the software. In step S5B, the data received in that period is stored together with the information on which cycle it is.

[0047] In step S5C, an inter-device adjustment coefficient corresponding to the received data is determined from the device allocation information 50 and the data flow information 51. For example, consider the case where the new software 12 is software B and the data source is software A. From the device allocation information 50 in FIG. 10 and the data flow information 51 in FIG. 11, since software A and software B communicate using CAN, referring to the corresponding row of the inter-device adjustment coefficient information 52 in FIG. 12, it can be seen that the inter-device adjustment coefficient is 1.

[0048] In step S5D, based on the inter-device adjustment coefficient determined in step S5C, among the past received data stored in step S5B, the past data selected based on the inter-device adjustment coefficient is processed as the input in the current control cycle process. In step S54, the measurement of the execution time is ended immediately before the data output process within the periodic processing of the software, and the execution time is stored. In step S55, if the measured execution time is shorter than the estimated execution time 40, a busy wait is performed for the difference time. In step S56, the data output process is performed.

[0049] In step S57, it is determined whether the execution result of the software satisfies the measurement end condition. If the measurement end condition is satisfied, the process ends. If the measurement end condition is not satisfied, the process proceeds to step S53. The measurement end condition can be determined, for example, based on whether a certain period of time has elapsed, whether the software has reached the destination by autonomous driving if it is related to autonomous driving, whether an error such as the inability to continue autonomous driving has occurred, etc. Also, a combination of multiple measurement end conditions may be used. In such a procedure, the software execution management unit 5 in the second embodiment executes the new software 12 on the host environment 100.

[0050] The processing from step S5B to S5D described above will be described in more detail. Referring to FIGS. 10 - 11, for example, software E receives data from software C running on microcomputer A and software D running on the control device. From FIGS. 11 and 12, the data communication between software C and software E is performed via WiFi, and the device - to - device adjustment coefficient is 8. This means that in the N - th execution of software E, the data generated by software C in the (N - 8) - th cycle is used. Similarly, the data communication between software D and software E is performed via Eth (Ethernet: registered trademark), and the device - to - device adjustment coefficient is 2. This means that in the N - th execution of software E, the data generated by software D in the (N - 2) - th cycle is used.

[0051] As described above, in the above example, the data used in the Nth cycle of software E is the data generated by software C in the (N - 8)th cycle and the data generated by software D in the (N - 2)th cycle. However, due to the performance difference between the host environment 100 and the target environment 110, when the same software is executed on the host environment 100, it is conceivable that the data used in the Nth cycle of software E is, for example, the data generated by software C in the (N - 2)th cycle and the data generated by software D in the (N - 2)th cycle. In this case, since the timing at which the data used for the execution of software E is generated is different from that of the target environment 110, the execution results on the host environment 100 and the execution results on the target environment 110 will be different, and it becomes impossible to reproduce the high-precision target environment 110 on the host environment 100.

[0052] On the other hand, according to the processing flow performed by the software execution management unit 5 in the second embodiment, since a delay according to the communication method between devices is inserted, it is possible to adjust so that the communication timing when the new software 12 is executed on the host environment 100 is the same as that when it is executed on the target environment 110.

[0053] Note that in this embodiment, although the process of adjusting the data is performed on the data receiving side, the same effect can be obtained even if the process of adjusting the data is performed on the data transmitting side.

[0054] As described above, according to the simulation method in the second embodiment, by using the device allocation information 50, the data flow information 51, and the inter-device adjustment coefficient information 52, the transmission and reception timing of the data when processing is performed between software is adjusted. As a result, when the new software 12 is executed on the host environment 100, it is possible to adjust so that the communication timing when it is executed on the target environment 110 is obtained. Therefore, it becomes possible to accurately reproduce the data generation timing when the software is executed on the target environment 110 on the host environment 100.

[0055] [Embodiment 3] The simulation method in Example 3 of the present invention will be described. The difference between Example 3 and Example 1 is that when executing the software group including the new software 12 in the target environment 110, the execution order is estimated, and the execution order when the software group is executed on the host environment 100 is further compared and verified. Thereby, it is possible to detect that there is a possibility that the simulation executed due to an event caused by the host environment 100 cannot be executed correctly. For the same configuration as in Example 1, the same reference numerals are given and the description thereof is omitted.

[0056] <Overview of the simulation method> FIG. 14 is a diagram showing an overview of the simulation method in Example 3. In addition to Example 1, the simulation method according to this embodiment further performs processing by the execution order estimation unit 6 and the execution order verification unit 7. The execution order estimation unit 6 and the execution order verification unit 7 are functional units installed in the host environment 100, for example.

[0057] The target execution time 20, the device allocation information 50, and the cycle information 60 are input to the execution order estimation unit 6, and the estimated execution order 61 is output. The execution order verification unit 7 verifies whether the software is correctly executed on the host environment 100 by inputting the execution result when the software is executed on the host environment 100 and the estimated execution order 61.

[0058] <Cycle information> FIG. 15 is a diagram showing an example of the cycle information 60 in the present invention. The cycle information 60 is stored in the host environment 100, for example. The cycle information 60 indicates the execution cycle information of each software. For example, software A is executed once every 50 ms.

[0059] <Execution order estimation unit> FIG. 16 is a diagram showing an overview of the processing flow of the execution order estimation unit 6 in the present invention. The execution order estimation unit 6 acquires the device allocation information 50 in step S61. In step S62, it acquires the estimated execution time 40 from the target execution time estimation unit 4. In step S63, it acquires the target execution time 20 from the target execution time acquisition unit 2. In step S64, it acquires the cycle information 60.

[0060] In step S65, it performs scheduling to estimate the execution order of the software group. As the scheduling algorithm, a known algorithm such as the round-robin method or the rate-monotonic scheduling method is used. In step S66, it outputs the execution order estimated in step S65 as the estimated execution order 61. In such a procedure, the execution order estimation unit 6 acquires and outputs the estimated execution order 61.

[0061] <Execution order verification unit> FIG. 17 is a diagram showing an outline of the processing flow performed by the execution order verification unit 7 in the present invention. The execution order verification unit 7 acquires the estimated execution order 61 from the execution order estimation unit 6 in step S71. In step S72, it acquires the measured execution order measured when the software group is executed on the host environment 100.

[0062] In step S73, it determines whether the estimated execution order 61 and the measured execution order are the same. If the estimated execution order 61 and the measured execution order are the same, the process ends. If the estimated execution order 61 and the measured execution order are not the same, it proceeds to step S74.

[0063] In step S74, it outputs that there may be a possibility that the software could not be executed correctly. For example, in the host environment 100, it is considered that the execution order may be disrupted because software other than the software group executed this time has performed an interruption. In such a procedure, the execution order verification unit 7 evaluates the execution order.

[0064] As described above, according to the simulation method in Embodiment 3, the execution order of the software group when executed in the target environment 110 is estimated and compared with the execution order when the software group is actually executed in the host environment 100. When executing in the host environment 100, since the execution time in the target environment 110 is reproduced, the same execution order will be obtained if there is no interruption of other software. Therefore, by comparing the estimated execution order with the executed execution order, it is possible to determine whether the execution result is due to only the assumed software group.

[0065] [Embodiment 4] The simulation method in Embodiment 4 of the present invention will be described. Embodiment 4 is an embodiment in which additional processing is performed in Embodiment 3. The difference from Embodiment 3 is that further processing by the specification evaluation unit 8 and the function allocation unit 9 is performed. The specification evaluation unit 8 and the function allocation unit 9 are, for example, functional units installed in the host environment 100. The specification evaluation unit 8 determines whether the execution of the software group meets the specifications based on the estimated execution time 40, the device allocation information 50, the cycle information 60, the software specification document 80, and the estimated execution order 61. When the execution of the software group does not meet the specifications, the function allocation unit 9 executes the allocation of the software. For the same configuration as in Embodiment 3, the same reference numerals are given and the description thereof is omitted.

[0066] <Overview of the simulation method> FIG. 18 is a diagram showing an overview of the simulation method in Embodiment 4. For example, the estimated execution time 40, the device allocation information 50, the cycle information 60, the software specification document 80, and the estimated execution order 61 are input to the specification evaluation unit 8. The software specification document 80 may be installed in the host environment 100, for example, or may be given by manually inputting from the outside.

[0067] <Software specification document> FIG. 19 is a diagram showing an example of the software specification 80 in the present invention. For example, specifications such as the time required from the start of execution of Software A to the completion of execution of Software D being 100 ms or less, and the CPU load being less than 90% are described.

[0068] <Specification Evaluation Unit> FIG. 20 is a diagram showing an outline of the processing flow of the specification evaluation unit 8 in the present invention. In step S81, the specification evaluation unit 8 acquires the estimated execution time 40 from the target execution time estimation unit 4. In step S82, it acquires the device allocation information 50. In step S83, it acquires the cycle information 60. In step S84, it acquires the software specification 80. In step S85, it acquires the estimated execution order 61 from the execution order estimation unit 6.

[0069] Also, in step S86, the specification evaluation unit 8 calculates the hyper period. The hyper period refers to the least common multiple of the execution cycles of the software operating on each device. The software operating on each device can be known based on the device allocation information 50 (see FIG. 10). Also, based on the cycle information 60 (see FIG. 15), the execution cycles of the software operating on each device can be known. That is, for example, based on FIG. 10, the software operating on the microcomputer A is Software A and Software C. Based on FIG. 15, since Software A has a cycle of 50 ms and Software C has a cycle of 100 ms, this least common multiple of 100 ms becomes the hyper period.

[0070] In step S87, it determines whether there is a specification regarding the execution of the software. If a specification exists, it proceeds to step S88, and if no specification exists, the process ends. In step S88, the CPU utilization rate is calculated. The CPU utilization rate can be calculated by Σ{(estimated execution time / execution cycle) * 100}.

[0071] In step S89, it is determined whether the execution of the software meets the specifications. If it meets the specifications, the process proceeds to step S8C; if it does not meet the specifications, the process proceeds to step S8A. For example, when determining with respect to the CPU utilization rate in FIG. 19, it may be determined whether the CPU utilization rate obtained in step S88 is less than 90%. When determining with respect to the latency constraint, since the time until the execution is completed can be calculated from the estimated execution order 61 and the estimated execution time 40, it may be determined whether that time meets the specifications.

[0072] If it is determined in step S89 that the specifications are not met, in step S8A, the function allocation unit 9 performs function allocation. This function allocation will be described later with reference to FIG. 21. In step S8B, it is determined whether there is an allocation that meets the specifications as a result of performing function allocation. If there is an allocation that meets the specifications, the process proceeds to step S8C; if there is no allocation that meets the specifications, the process proceeds to step S8D.

[0073] In step S8C, the process moves to the next specification, returns to step S87, and continues the above process. In step S8D, an allocation error is output. Depending on the function allocation, the specifications may not be met, so for example, it is necessary to redevelop the software or review the equipment to be specified. In such a procedure, the specification evaluation unit 8 determines whether the specifications are met. If the specifications are not met, it attempts function allocation. If the specifications are still not met after performing function allocation, an allocation error is output.

[0074] <Function Allocation Unit> FIG. 21 is a diagram showing an overview of the processing flow performed by the function allocation unit 9 in the present invention. In step S91, the function allocation unit 9 determines whether there is an unexecuted combination. If there is an unexecuted combination, it proceeds to step S92. If there is no unexecuted combination, the process ends. Note that the combination in this embodiment refers to the combination of software and devices described in the device allocation information 50. That is, it is the combination of software and the device that executes the software shown in FIG. 10.

[0075] In step S92, scheduling in the new combination is performed, that is, the order of executing the software is set. In step S93, it is determined whether the execution of the software by the new combination meets the specifications. If it meets the specifications, it proceeds to step S94. If it does not meet the specifications, it returns to step S91. In step S94, the allocation information that meets the specifications is saved. In such a procedure, the function allocation unit 9 determines whether there is a function allocation that meets the specifications.

[0076] According to the simulation method in Embodiment 4, it is possible to determine whether the execution of the software group including the new software 12 meets the specifications, and even when it does not meet the specifications, it is possible to determine whether the specifications can be met by function allocation.

[0077] Although the above has been described with respect to Embodiments 1 to 4, simulations may be performed by combining two or more of these embodiments.

[0078] <Summary of the effects of each embodiment> According to the simulation method in Embodiment 1, by inputting the new software host feature amount 13 when the new software 12 is executed in the host environment 100 into the execution time estimation model 30, it is possible to estimate the worst execution time when the new software 12 is executed on the target environment 110 without transplanting the new software 12 to the target environment 110. Then, by executing the new software 12 on the host environment 100 based on the estimated execution time 40, the target environment 110 can be simulated and verified with high precision. Therefore, it becomes possible to seamlessly transplant the software developed in the host environment 100 to the target environment 110.

[0079] According to the simulation method in Embodiment 2, when the new software 12 is executed in the host environment 100, by adjusting it to be the communication timing when executed on the target environment 110 based on the device - to - device adjustment coefficient, it becomes possible to reproduce the data generation timing when the software is executed.

[0080] According to the simulation method in Embodiment 3, when a software group including the new software 12 is executed in the host environment 100, since the execution time in the target environment 110 is reproduced, if there is no interruption from another software, the same execution order will be obtained. Therefore, by comparing the estimated execution order with the executed execution order, it becomes possible to determine whether the execution result on the host environment 100 is affected by factors other than the software being executed.

[0081] According to the simulation method in Embodiment 4, it is possible to determine whether the execution of the software group including the new software 12 meets the specifications, and even if it does not meet the specifications, it is possible to determine whether the specifications can be met by function allocation.

[0082] According to the embodiments of the present invention described above, the following operational effects can be achieved. (1) The simulation method according to an embodiment of the present invention extracts a first host feature amount obtained by executing a first software on a host environment, calculates a target execution time required to execute the first software on a target environment by executing the first software on the target environment, calculates a performance difference between the host environment and the target environment based on the first host feature amount and the target execution time, extracts a second host feature amount obtained by executing a second software on the host environment, and estimates the time required to execute the second software on the target environment based on the second host feature amount and the performance difference.

[0083] With the above configuration, the target environment is reproduced with high accuracy on the host environment for software development. That is, the target environment is simulated on the host environment. Therefore, it is possible to verify whether the software can be normally executed on the target environment without actually transplanting the software to the target environment, and the software development efficiency is improved.

[0084] (2) Based on the estimated time, adjust the execution time of executing the second software on the host environment. Thereby, it becomes possible to compensate for the performance difference between the host environment and the target environment, and the target environment can be simulated with higher accuracy.

[0085] (3) Obtain an inter-device adjustment coefficient regarding the data transmission and reception timing on the target environment, and when executing the second software on the host environment, adjust the data transmission and reception timing based on the inter-device adjustment coefficient. Thereby, when executing new software 12 on the host environment, it becomes possible to adjust so that the communication timing when executed on the target environment is obtained based on the inter-device adjustment coefficient, and thus it becomes possible to synchronize the data generation timing when executing the software.

[0086] (4) Based on the target execution time, the execution time on the target environment estimated for the second software, and the cycle information of each of the first software and the second software, estimate the execution order of the first software and the second software on the target environment. As a result, the execution order when executing a software group including new software on the target environment is estimated, and it becomes possible to predict the execution result when executing the software group according to the execution order.

[0087] (5) By comparing the estimated execution order with the execution order when the first software and the second software are executed on the host environment, verify whether the second software can be correctly executed on the host environment. As a result, it is possible to evaluate cases where the execution of new software according to the estimated execution order is not correctly performed, such as when an interrupt process by other software occurs on the host environment, so that it is possible to re-set the execution order, etc.

[0088] (6) When there are a plurality of devices capable of executing the first software and the second software, compare the execution of the first software and the second software according to the estimated execution order with a predetermined specification, and if the execution of the software according to the execution order does not satisfy the specification, change the device that executes at least one of the first software or the second software. As a result, it is possible to determine whether the execution of the software group including the new software 12 satisfies the specification, and even if it does not satisfy the specification, it is possible to determine whether it is possible to satisfy the specification by re-assigning functions.

[0089] (7) The first host feature amount and the second host feature amount include at least the execution time of the software. As a result, it becomes possible to calculate the performance difference between the host environment and the target environment using the execution time of the software, and it becomes possible to reproduce the target environment with higher accuracy on the host environment where the software is developed.

[0090] Note that the present invention is not limited to the above-described embodiments, and various modifications are possible. For example, the above embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to the aspect including all the configurations described. Also, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment. Further, it is possible to add the configuration of another embodiment to the configuration of one embodiment. Also, it is possible to delete a part of the configuration of each embodiment, or add or replace other configurations.

Description of Reference Numerals

[0091] 1 Host feature amount acquisition unit, 2 Target execution time acquisition unit, 3 Execution time estimation model creation unit, 4 Target execution time estimation unit on target, 5 Software execution management unit, 6 Execution order estimation unit, 7 Execution order verification unit, 8 Specification evaluation unit, 9 Function allocation unit, 10 Existing software (first software), 11 Host feature amount (first feature amount), 12 New software (second software), 13 New software host feature amount (second feature amount), 20 Target execution time, 30 Execution time estimation model, 40 Estimated execution time, 50 Device allocation information, 51 Data flow information, 52 Inter-device adjustment coefficient information, 60 Cycle information, 61 Estimated execution order, 80 Software specification document, 100 Host environment, 110 Target environment

Claims

1. Extract a first host feature amount obtained by executing first software on a host environment, By executing the first software on a target environment, calculate a target execution time required to execute the first software on the target environment, Based on the first host feature amount and the target execution time, calculate a performance difference between the host environment and the target environment, Extract a second host feature amount obtained by executing second software on the host environment, Based on the second host feature amount and the performance difference, estimate the time required to execute the second software on the target environment, Obtain an inter-device adjustment coefficient regarding the data transmission / reception timing on the target environment, When executing the second software on the host environment, adjust the data transmission / reception timing based on the inter-device adjustment coefficient, A simulation method characterized by the above.

2. The simulation method according to Claim 1, Based on the estimated time, adjust the execution time for executing the second software on the host environment, A simulation method characterized by the above.

3. Extract a first host feature amount obtained by executing first software on a host environment, By executing the first software on a target environment, calculate a target execution time required to execute the first software on the target environment, Based on the first host feature amount and the target execution time, calculate a performance difference between the host environment and the target environment, Extract a second host feature amount obtained by executing second software on the host environment, Based on the second host feature amount and the performance difference, estimate the time required to execute the second software on the target environment, Based on the target execution time, the estimated execution time on the target environment for the second software, and the cycle information of each of the first software and the second software, estimate the execution order of the first software and the second software on the target environment, A simulation method characterized by the following.

4. The simulation method according to claim 3, by comparing the estimated execution order with the execution order when the first software and the second software are executed on the host environment, verifying whether the second software can be correctly executed on the host environment. A simulation method characterized by the following.

5. The simulation method according to claim 3, where there are a plurality of devices capable of executing the first software and the second software, comparing the execution of the first software and the second software according to the estimated execution order with a predetermined specification, and when the execution of the software according to the execution order does not meet the specification, changing the device that executes at least one of the first software or the second software. A simulation method characterized by the following.

6. The simulation method according to claim 1, where the first host feature amount and the second host feature amount include at least the execution time of the software. A simulation method characterized by the following.

Images