WO2011046089A1 - Simulation method, system, and program - Google Patents

Abstract

Provided is a V-PILS by which reproducibility of a simulation operation can be achieved while reasonably maintaining a operation speed. A peripheral scheduler starts concurrent operation of all peripheral emulators, identifies a peripheral emulator (peripheral P) which is scheduled to reach a separation of a process earliest on the basis of the process separation time of the set respective peripheral emulators, executes each processor emulator and each plant simulator until the separation time, and synchronizes data between the peripheral P and the processor emulator and the peripheral P and the plant simulator.

Description

Simulation method, system and program

The present invention relates to a simulation of a physical system such as an automobile, and more particularly to a software-based simulation system.

In the early twentieth century of the early era, automobiles consisted of mechanical parts including an engine as power and a brake, accelerator, steering wheel, transmission, and suspension. Except for the ignition of the engine plug and the headlight, Almost no electrical mechanism was used.

However, since around the 1970s, there has been a need to efficiently control the engine in preparation for air pollution, an oil crisis, and the like. For this reason, ECUs have been used for engine control. The ECU generally includes an input interface for A / D conversion, for example, an input interface from a sensor, a logical operation unit (microcomputer) that processes a digital input signal in accordance with a predetermined logic, and the processing result as an actuator. And an output interface for converting into an operation signal.

Nowadays, not only control systems such as engines and transmissions, Anti-lock Breaking System (ABS), Electronic Stability Control (ESC), power steering, wiper control and security monitoring system, etc. Not only mechanical parts but also electronic parts and software account for an important proportion. The development cost for the latter is said to be 25% or 40% of the total, accounting for 70% for hybrid type vehicles.

By the way, an automobile is composed of a power device such as an engine, a power transmission device, a traveling device such as a steering, a brake device, and other machine parts (plants) such as a body system. The operation of these plants is 30 to 70. The program of the electronic control unit (ECU) described above is dynamically determined according to sensor input (speed etc.) or human input (accelerator etc.).

Each ECU basically controls the operation of one plant. For example, the amount and timing of fuel injection (Fuel 燃料 Injection) and ignition (Ignition) into the engine are determined by software by the engine control unit. Since it is software, it is possible to increase or decrease the fuel injection amount according to the mode in a luxury car with a “sport” mode. In addition, the engine speed can be adjusted by automatically blipping in accordance with the downshift timing. In this case, the ECU of the engine and the ECU of the transmission need to operate in cooperation. In an integrated vehicle attitude stability control (ESC: Electronic Stability Control) system for preventing a side slip of an automobile, further interlocking with a braking device such as a brake is required, and the ECU software becomes complicated. Such an “intervention” function can be easily cut because it is software.

Now, in order to extract the performance of the plant sufficiently and operate it safely, it is important to fully tune and test the operating parameters in the process of ECU software design and development. In general, it is too expensive and time-consuming to prototype and then tune and test repeatedly, so the controller and plant can be virtually implemented in the computer before prototyping to move quickly and accurately. A method for confirming the operation is strongly desired. Such ECU simulations are: (1) Model-in-the-Loop (Simulation) (MILS), which logically expresses the operation of the controller using an expression form such as a state machine, (2) Data accuracy in the logical operation Software-in-the-Loop Simulation (SILS), which introduced some hardware restrictions, such as (3) Virtual processor-in-the-Loop Simulation (V) -PILS), and (4) There are four types of hardware-in-the-loop (Simulation) (HILS) that fully implements the ECU board and connects with real-time plant simulation. Close to the prototype.

MILS / SILS is mainly used in the trial and error phase to bring out the basic performance of the plant. However, since it operates differently from the software actually installed in the ECU, it cannot be used for product verification purposes. On the other hand, V-PILS uses completed ECU software, so it is very promising as a method for finding and solving unexpected operations (bugs) of the software, but it has reproducible operations. There is no example that has been achieved yet. HILS is always carried out to confirm the final operation of the completed ECU board. However, even if a failure is found, reproducibility is not guaranteed, so it cannot be used for debugging purposes.

The reason why the operation cannot be reproduced in HILS is not because the configuration of HILS is incomplete, but because each ECU is connected to each other by a network such as CAN. In general, since a network realizes loose coupling between modules, the arrival order of data is changed due to a subtle difference in timing of module operation, and as a result, the behavior of the entire system may be different. Therefore, even if an actual vehicle is prototyped, the reproducibility of the operation cannot be expected. This is the same reason that debugging a parallel distributed system is very difficult.

As described above, with the HILS configuration, that is, the loosely coupled configuration of the ECU board and the plant simulator, it is not possible to achieve operation consistency even if the speed of each component is increased. Realizing the consistency of the communication order is necessary to realize the reproducibility of the movement. V-PILS is particularly expected to solve this problem.

Fig. 1 shows a typical V-PILS configuration according to the conventional concept. This configuration includes a plurality of ECU emulators, a plurality of plant simulators, and a global scheduler 110 that schedules the overall operation. In FIG. 1, for convenience, two ECU emulators 102 and 104 and two plant simulators 106 and 108 are shown. However, it should be understood that actually, there are more ECU emulators and plant simulators than shown. .

The ECU emulator 102 includes a processor emulator 102a and a peripheral emulator 102b. Since the ECU emulator 104 is similar, detailed description of the ECU emulator 104 is omitted.

On the other hand, a clock converter 106 a is connected to the plant simulator 106. Since the plant simulator 108 is the same, detailed description of the plant simulator 108 is omitted. The plant simulator 106 is a brake simulator, for example, and the plant simulator 108 is an engine simulator.

Now, the frequency shown is an exemplary typical number of operating clocks. That is, the processor emulator 102a operates with a relatively high-speed clock of 80 MHz. On the other hand, since the plant simulator 106 is a physical mechanism simulator, it operates at a relatively low speed of 10 KHz.

Next, the operation of the configuration of FIG. 1 will be described with reference to the timing chart of FIG. In a plant simulator simulated with a fixed-step clock, input / output is repeated at a time step of, for example, 10 kHz, that is, 100 μs. The input is mainly an instruction signal from the controller, and the output is sent to the sensor.

The peripheral emulator is the interface part of the I / O IV of the ECU emulator and connects the plant simulator and processor emulator to each other. It can be seen that it typically operates at a resolution of about 10MHz (on average). This is faster than a plant simulator but slower than a processor emulator. The peripheral emulator sends a pulse signal to the plant simulator.

The clock converter is interposed between the peripheral emulator and the plant simulator, and reduces the frequency of the clock signal from the peripheral emulator so as to be compatible with the plant simulator, and the signal from the plant simulator. Has a function to increase the peripheral radix to fit the peripheral emulator.

The peripheral emulator sends and receives data to the processor emulator in response to a read / write (R / W) request and sends an interrupt (INT). In particular, a network function such as a CAN (controller area network) that interconnects processors requires communication between peripherals.

組 み 込 み Many embedded processors operate at about 80-100MHz, so they are about 10 times faster than the peripheral time resolution. The processor performs a read / write (R / W) operation on the peripheral. It also receives an interrupt signal (INT) from the peripheral.

From one aspect, the peripheral is the center of the system that interconnects the plant, processor, and processors. The processor performs R / W operation with finer time resolution than the peripheral, but when the signal for that is transmitted to the plant or other processors, it is governed by the time resolution of the peripheral. Therefore, in the entire simulation system, if the synchronization processing of sensor data and the like is performed at the peripheral time resolution, the processing sequence of I / O data and interrupts is correctly reproduced (fine-grain synchronization = minimum synchronization).

Generally, if the synchronization time interval is shortened, more correct operation can be realized, but conversely, since the processing time overhead is increased, the time required for the entire processing increases. Fine grain synchronization gives an upper limit on time resolution that does not require further refinement.

One solution is to reduce the synchronization time interval to the greatest common divisor as shown in FIG. 3 according to the global scheduler 110. As a result, accuracy can be achieved, but synchronization processing at an unnecessary timing increases, so the overhead of synchronization processing becomes very large. This significantly reduces the processing speed of the simulation system.

If it is not possible to explicitly use the peripheral processing delimiter, it is difficult to know even the greatest common divisor, so the overhead is further increased by increasing the time resolution.

On the other hand, if the time resolution is made coarse, a lot of I / O data and interrupts are pushed into the same time step, and the temporal context information is lost. This is a situation where the simulation is not executed correctly, that is, the accuracy is not achieved. In particular, the execution order of the interrupt processing is very important for operating the software as intended. The few existing V-PILS systems are in this inaccurate simulation situation, and due to the loss of order information, there is a serious problem that the ECU software cannot be sufficiently debugged.

Japanese Patent Application Laid-Open No. 2007-11720 is intended to solve the problem that it is possible to flexibly change the configuration of a system simulator while dealing with a system having a complicated configuration. The system simulator simulates the operation of a CPU. It consists of three types: an instruction set simulator that simulates the bus, a bus simulator that simulates the operation of the bus, and a peripheral simulator that simulates the operation of the peripheral. To disclose. However, this prior art does not suggest a technique for optimizing the synchronization between the peripheral and the CPU.

JP 2007-11720 A

An object of the present invention is to provide a V-PILS that makes it possible to realize the reproducibility of the simulation operation while maintaining the operation speed appropriately.

The present invention has been made to solve the above problems, and according to the present invention, a peripheral emulator, a processor emulator, and a peripheral scheduler for controlling the operation timing of the entire plant simulator are prepared.

According to the present invention, in order to enable control by the peripheral scheduler, a completion flag corresponding to each of the peripheral emulator, the processor emulator, and the plant simulator is prepared.

Each individual peripheral emulator has its own processing delimiter. Typically, the peripheral emulator is written in SystemC, and therefore, the source code can be scanned by using a program to check the specific processing delimiter. Typically, the line describing wait () is a delimiter.

The information of the processing delimiter of each peripheral emulator confirmed in this way is related to the peripheral scheduler.

Under such preparation, the peripheral scheduler starts parallel operation by releasing (OFF) the completion flag of all peripheral emulators. Then, the peripheral scheduler finds the peripheral emulator that is scheduled to reach the process break earliest based on the process break information of each peripheral emulator. I will call it Peripheral P. Assuming that the time between the processes is T, the peripheral scheduler advances the execution of each processor emulator and each plant simulator until the time T is reached.

Then, the peripheral scheduler waits for the peripheral P completion flag to be set. The peripheral P sets a completion flag when it reaches the processing break. In response to the peripheral P completion flag being set, the peripheral scheduler synchronizes data between the peripheral P and the processor emulator and plant simulator.

Next, the peripheral scheduler releases the peripheral P completion flag (OFF) and restarts its operation. This again causes all peripheral emulators to operate in parallel.

After that, the peripheral scheduler finds the peripheral emulator that is scheduled to reach the next processing break the earliest based on the set information of each peripheral emulator break. The peripheral scheduler operates the entire simulation system by such operation scheduling based on the timing of the peripheral emulator processing.

As described above, according to the present invention, in a simulation system in which individual modules communicate via a peripheral, the reproducibility of the process is guaranteed by the operation scheduling based on the timing of the peripheral emulator process. The effect that Further, since the processing synchronization is performed at an optimum granularity that is coarser than the fine-grained synchronization and that guarantees the reproducibility of the processing, that is, processing delimiter information of the peripheral emulator, optimization of the simulation is achieved.

It is a block diagram which shows the structure of the conventional V-PILS system. It is a timing diagram which shows the operation | movement of the conventional V-PILS system. FIG. 6 is a timing diagram of the operation of a conventional V-PILS system that is synchronized with maximum granularity. It is a block diagram of the hardware constitutions of a computer. It is a block diagram which shows the logical connection relation of a peripheral scheduler, a peripheral emulator, a processor emulator, and a plant simulator. It is a timing diagram which shows operation | movement of the structure of the simulation system of this invention. It is a figure which shows the function of the completion flag with respect to a peripheral emulator. It is a figure which shows the flowchart of operation | movement of a peripheral scheduler. It is a figure which shows the flowchart of operation | movement of a peripheral emulator. It is a figure which shows the function of the completion flag with respect to a processor emulator. It is a figure which shows the function of the completion flag with respect to a plant simulator. It is a figure which shows the flowchart of operation | movement of a plant simulator.

Hereinafter, the configuration and processing of an embodiment of the present invention will be described with reference to the drawings. In the following description, the same elements are referred to by the same reference numerals throughout the drawings unless otherwise specified. It should be understood that the configuration and processing described here are described as an example, and the technical scope of the present invention is not intended to be limited to this example.

First, the hardware of a computer used for carrying out the present invention will be described with reference to FIG. 4, a plurality of CPU1 404a, CPU2 404b, CPU3 404c,... CPUn 404n are connected to the host bus 402. Further connected to the host bus 402 is a main memory 406 for CPU1 404a, CPU2 404b, CPU3 404c,.

On the other hand, a keyboard 410, a mouse 412, a display 414 and a hard disk drive 416 are connected to the I / O bus 408. The I / O bus 408 is connected to the host bus 402 via the I / O bridge 418. The keyboard 410 and the mouse 412 are used by an operator to operate by typing a command or clicking a menu. The display 414 is used to display a menu for operating the process with the GUI as necessary.

As a suitable computer system hardware used for this purpose, there is IBM® System X. At that time, CPU1 404a, CPU2 404b, CPU3 404c,..., CPUn 404n are, for example, Intel (R) Xeon (R), and the operating system is Windows (trademark) Server 2003. The operating system preferably has a multitasking function. The operating system is stored on the hard disk drive 416 and is read from the hard disk drive 416 into the main memory 406 when the computer system is started.

In order to implement the present invention, it is desirable to use a multiprocessor system. Here, the multiprocessor system is generally intended to be a system using a processor having a plurality of cores of processor functions that can independently perform arithmetic processing. Therefore, a multicore single processor system or a single core multiprocessor system is used. And any multi-core multi-processor system.

The hardware of the computer system that can be used for carrying out the present invention is not limited to IBM (R) System X, and any hardware can be used as long as it can run the simulation program of the present invention. A computer system can be used. The operating system is not limited to Windows (R), and any operating system such as Linux (R) or Mac OS (R) can be used. Further, in order to operate the simulation program at a high speed, a computer system such as IBM (R) System P whose operating system is AIX (trademark) based on POWER (trademark) 6 may be used.

The hard disk drive 416 further stores programs such as a processor emulator, a peripheral scheduler, a peripheral emulator, a clock converter, and a plant simulator, which will be described later, each of which is activated when the computer system is started up. It is loaded into the main memory, assigned to the individual CPUs 1 to CPUn as individual threads or processes, and executed. For this reason, the computer system shown in FIG. 4 preferably has a sufficient number of CPUs to be allocated to individual threads of the processor emulator, peripheral scheduler, peripheral emulator, clock converter and plant simulator.

FIG. 5 shows the cooperative relationship between the processor emulator, peripheral scheduler, peripheral emulator, clock converter, and plant simulator that are assigned to the individual CPUs 1 to CPUn and operate as individual threads or processes. It is a functional block diagram shown.

As shown in FIG. 5, the present invention is characterized in that a peripheral scheduler 502, which is itself a single thread or process, is a peripheral emulator 504a, 504b, 504c,... It is to control 504z closely. This feature will be better understood in contrast to the typical prior art configuration of FIG. 1 where the peripheral emulators are within individual ECU emulators and operate independently of each other.

In FIG. 5, processor emulators 506a, 506b, 506c,... 506m, each of which is an independent thread or process, are basically interrupted from the associated peripheral emulators 504a, 504b, 504c,. In response, it operates while communicating, but also receives control from the peripheral scheduler 502 directly. The control mechanism will be described later.

On the other hand, plant simulators 508a, 508b,... 508n, each of which is an independent thread or process, communicate with peripheral emulators 504a, 504b, 504c,. Although not shown, the plant simulators 508a, 508b,... 508n incorporate a module that performs the function of the clock converter shown in FIG. Generally, the operation clock of the peripheral emulator is about 1000 times finer than the operation clock of the plant simulator. Therefore, such a clock converter function is provided to arrive at the plant simulator from the peripheral emulator. The interface needs to be matched by thinning out the pulses while increasing the number of pulses sent from the plant simulator to the peripheral emulator.

FIG. 6 is a timing chart showing an outline of operations of the peripheral emulator, the processor emulator, and the plant simulator under the control of the peripheral scheduler.

Each of the peripheral emulators has time information corresponding to a specific processing break position, and the value is obtained by, for example, analyzing a SystemC source code for describing the peripheral emulator by a computer program. Can be acquired. The delimiter position of the peripheral emulator corresponds to, for example, a line described as wait () in the case of description in SystemC.

Information on the time corresponding to the processing delimiter position of each peripheral emulator acquired in this way is associated in advance with the peripheral scheduler 502, and the peripheral scheduler 502 sets the time of the delimiter position of these processes as a value. To determine the timing of the nearest peripheral emulator processing at any point in time, and run all processor emulators and all plant simulators for that timing, aligning the synchronization steps Let

At this time, if the processing delimiter position of each peripheral emulator is periodic, if the value of such a period is stored in advance for each peripheral emulator, the peripheral scheduler can be obtained by multiplying them by an integer. 502 can calculate the timing of the next processing break. However, unless it is very limited, the processing delimiter position of the peripheral emulator is generally not periodic.

Therefore, the process in which the peripheral scheduler 502 selects the peripheral emulator whose timing is to be matched is as follows. That is, for example, by scanning the peripheral emulator SystemC source code in advance with a predetermined program, a table including the time between processing breaks is saved in a shared memory or the like for each peripheral emulator. Peripheral scheduler 502 makes this table available for reference. Accordingly, the peripheral scheduler 502 can additionally calculate the next process break based on the table entry, and selects the next process break from the current simulation time as the next target time. It becomes possible.

In the example shown in FIG. 6, the timing T ₁ related to the peripheral 2 is the timing at which the peripheral scheduler 502 recognizes that the timing of the first peripheral emulator processing after the simulation system starts is the timing T 1. Towards ₁ , the peripheral scheduler 502 causes all processor emulators and all plant simulators to execute.

Next peripheral scheduler 502, the timing T ₂ associated with the peripheral n is aware that it is time for delimiting the processing of the next peripheral emulator after simulation system start, toward the timing T _2, peripheral The scheduler 502 executes all processor emulators and all plant simulators.

The peripheral scheduler 502 determines the timing of such sequential peripheral emulator processing delimiters based on the time information of all the peripheral emulator processing delimiter positions stored in advance in the peripheral scheduler 502. Sequentially from the start of the simulation system, by finding the closest timing of any peripheral emulator.

FIG. 7 is a diagram schematically showing a mechanism for performing synchronous control by the peripheral scheduler 502. That is, according to this embodiment of the present invention, completion flags 702a, 702b, 702c,... Corresponding to the peripheral emulators 502a, 502b, 502c,. Using the completion flags 702a, 702b, 702c, etc., the peripheral scheduler 502 executes synchronous control for the peripheral emulators 502a, 502b, 502c.

Next, processing of the peripheral scheduler 502 will be described with reference to the flowchart of FIG. In FIG. 8, in step 802, the peripheral scheduler 502 initializes and starts processing of all the peripheral emulators. This initialization includes a process of resetting all the completion flags 702a, 702b, 702c... Corresponding to the peripheral emulators 502a, 502b, 502c.

In step 804, as described above, the peripheral scheduler 502 refers to the table including the time between processing breaks for each peripheral emulator, so that the peripheral time expected to arrive at the nearest time is as follows. Find an emulator.

In step 806, the peripheral scheduler 502 causes all the processor emulators and all the plant simulators to be executed simultaneously and in parallel toward the time point indicated by the closest timing found in step 804. Then wait for the completion.

In step 808, the peripheral scheduler 502 is set. The peripheral emulator associated with the timing found in step 804 waits for a processing break.

When the peripheral emulator having the timing found in step 804 as the processing break comes, the peripheral emulator turns on the completion flag and temporarily stops the processing. This process will be described in more detail with reference to the flowchart of FIG. This is communicated to the peripheral scheduler 502 by inter-thread communication, which in step 810, between the peripheral emulator and the processor emulator, and between the peripheral emulator, I / O data and the plant simulator. Synchronize the I / O data with the interrupt. When it completes, the peripheral scheduler 502 turns off the peripheral emulator completion flag associated with the timing found in step 804 and returns to step 804.

In step 804, the peripheral scheduler 502 finds a peripheral emulator that is expected to have a processing break at the next closest point. The peripheral emulator that is expected to complete processing at the next closest time point here is peripheral n in the example of FIG. 6, and timing T ₂ is selected in relation to it.

Next, the operation of the peripheral emulator will be described with reference to the flowchart of FIG. This operation first assumes that the completion flag is ON. Therefore, in step 902, the peripheral emulator waits for the completion flag to be cleared (OFF).

When the completion flag is cleared by the peripheral scheduler 502, the process proceeds to step 904, where the peripheral emulator performs a specific process. When the processing is completed, the peripheral emulator sets a completion flag (ON) in step 906, returns to step 902, and waits for the completion flag to be cleared (OFF).

Next, control of the processor emulator by the peripheral scheduler 502 will be described. In the simulation system in this embodiment, a host processor, that is, CPU1, CPU2,..., CPUn shown in FIG. 4 executes a guest processor, that is, a program developed for an actual machine such as an automobile embedded system. Is done. At this time, whether the source code is present or only the binary for the guest is present, the code is executed after being converted into binary code on the host processor.

However, according to the present invention, in order to synchronize with the peripheral scheduler 502 at the time of the code conversion, a special code is inserted at a key point.

First, a code for updating and increasing the data (T_CPU) representing the processor time is inserted at the beginning of the basic block of the code or at the end of the loop. That is, a certain constant Const is added to T_CPU as described below. This constant is determined in advance based on the time analysis of the guest code.
T_CPU + = Const

For example, the following code for determining whether to wait by comparing the simulation time (T_Peripheral) to be stopped with its own progress time at a rate of about 1 in 80 cycles is as follows. Insert into code that runs on the processor.
if (T_CPU> T_Peripheral) {
POST Completion_flag;
do {SLEEP_TEMPORARY;} while (T_CPU>T_Peripheral);
}
Here, POST Completion_flag is a process of setting (ON) a completion flag (Completion_flag). The completion flag area is preferably secured on the shared memory. The while (T_CPU> T_Peripheral) loop performs a sleep operation called SLEEP_TEMPORARY until the T_Peripheral value reserved on the shared memory is overwritten by the peripheral scheduler 502 and the T_CPU> T_Peripheral judgment is false. .

FIG. 10 is a functional block diagram for explaining the above processing. That is, the peripheral scheduler 502 sets the time T_Peripheral 1002 based on the timing of the peripheral emulator at which the processing break comes first, and each of the processor emulators 506a, 506b, 506c,. Each has its own time T_CPU1, T_CPU2, T_CPU3,.

In the initialization stage, the peripheral scheduler 502 clears (OFF) the completion flags 1004a, 1004b, 1004c,... Of each processor emulator 506a, 506b, 506c..., And each processor emulator has T_CPU> T_Peripheral. At this point, a standby state is entered by the above code.

In order to resume the operation of each processor emulator, the peripheral scheduler 502 provides a new T_Peripheral 1002 that satisfies T_CPU <T_Peripheral, and the completion flags 1004a, 506a, 506b, 506c,. 1004b, 1004c,... Are cleared (OFF).

Next, with reference to FIG. 11, the synchronization processing between the peripheral scheduler 502 and the plant simulators 508a, 508b,. A plant simulator originally calculates and updates an internal state such as a differential equation approximately by cutting time into short steps. Therefore, it can be said that it is highly adaptable to advance the processing to a given time.

In FIG. 11, the peripheral scheduler 502 sets a time T_Peripheral 1002 based on the timing of the peripheral emulator at which the processing break comes first, and each plant simulator 508a, 508b, 508c,. 1104a, 1104b, 1104c,. In the initialization stage, the peripheral scheduler 502 clears (OFF) the completion flags 1102a, 1102b, 1102c,... Of each plant simulator 508a, 508b, 508c,. The completion flags 1102a, 1102b, 1102c,... Are preferably secured on the shared memory.

Next, the plant simulator synchronization processing by the peripheral scheduler 502 will be described in more detail with reference to the flowchart of FIG. In FIG. 12, in step 1202, the plant simulator waits until the peripheral scheduler sets a new time T. This time is T_Peripheral 1002 shown in FIG.

In step 1204, the plant simulator determines whether or not my_time> で T. Here, my_time is the completion times 1104a and 1104b corresponding to the plant simulator shown in FIG.

If my_time> T is not true, the plant simulator goes to step 1206 to advance a predetermined processing step. In step 1208, my_time is advanced, and the process returns to step 1204.

In step 1204, if the plant simulator determines that my_time で <= T, the plant simulator sets (ON) the corresponding completion flag and returns to step 1202.

By the way, the completion flag of the plant simulator and the processor emulator can be implemented as a counter semaphore as an example.

Therefore, the following code is written on the peripheral scheduler side.
extern sem_t sem_start []; / * binary semaphores * /
extern sem_t sem_finish; / * counter semaphore * /
extern int n_plants; / * number of plant tasks * /
extern int n_all; / * number of all tasks * /
{
...
/ * Prepare to run the task * /
/ * For example, T_Peripheral update * /
...
/ * Run plant tasks in parallel * /
for (int k = 0; k <n_plants; k ++)
sem_post (& sem_start [k]);
...
/ * Wait until all tasks are finished * /
for (int k = 0; k <n_all; k ++)
sem_wait (&sem_finish);
...
}

On the other hand, the following code is written on the plant simulator side.
extern sem_t sem_start []; / * binary semaphores * /
extern sem_t sem_finish; / * counter semaphore * /
{
...
/ * Wait for instructions to start processing * /
sem_wait (& sem_start [k]);
...
/ * Proceed with original processing * /
...
/ * Tell the end of processing * /
sem_post (&sem_finish);
...
}

Here, n_plants is the number of plant simulators executed in the simulation system.
For (int k = 0; k <n_plants; k ++) in the peripheral scheduler
sem_post (& sem_start [k]);
Is to instruct each of n_plants tasks or threads to start processing, and on the plant simulator side,
sem_wait (& sem_start [k]);
Thus, a start instruction is received.

On the other hand, sem_post (& sem_finish) on the processor emulator and plant simulator side is for (int k = 0; k <n; k ++) in the peripheral scheduler
sem_wait (&sem_finish);
I.e., the peripheral scheduler will wait for the end of processing for all processor emulators and plant simulators. In the code inserted into the processor emulator code, the part described as POST Completion_flag corresponds to sem_post (& sem_finish) in the processor emulator. In FIG. 10 and FIG. 11, the completion flag is shown separately. However, if the counter type semaphore is used as described above, one is sufficient.

As mentioned above, specific embodiments of the present invention have been described in relation to a plurality of simulation systems for automobiles. However, the present invention is not limited to such specific embodiments, and simulation systems for airplanes, etc. Those skilled in the art will understand that the present invention can be applied to a general electromechanical control system simulation system.

The present invention is not limited to a specific computer architecture or platform, and can be implemented on any platform capable of realizing multitasking.

404 ... Processor 502 ... Peripheral scheduler 504 ... Peripheral emulator 506 ... Processor emulator 508 ... Plant simulator 702, 1004, 1102 ... Completion flag

Claims (15)

In a simulation system that performs simulation by computer processing,
A plurality of processor emulators running on the computer;
A plurality of plant simulators running on the computer;
A plurality of peripheral emulators that are executed on the computer, each having a unique processing break timing, and performing data communication between the processor emulator and the plant simulator;
Among the peripheral emulators, a peripheral emulator that arrives at the earliest timing of processing breaks and a means for finding the timing of the breaks of the processing;
Means for synchronizing the plurality of processor emulators and the plurality of plant simulators at the found timing;
Simulation system. The computer is a multitasking system, and the plurality of processor emulators, the peripheral emulator, and the plurality of plant simulators are executed as individual threads or processes of the multiprocessor system. 1. The simulation system according to 1. The computer is a multiprocessor system, and the plurality of processor emulators, the peripheral emulator, and the plurality of plant simulators are assigned to different processors or cores of the multiprocessor system and are separated from each other. The simulation system according to claim 2, wherein the simulation system is executed as a process. Means for synchronizing the plurality of processor emulators and the plurality of plant simulators is ensured in a memory of the computer, and is provided corresponding to each of the plurality of processor emulators and the plurality of plant simulators. The simulation system of claim 2, wherein synchronization is achieved by setting a flag. The simulation system according to claim 4, wherein the completion flag is realized by a counter semaphore. In a simulation method for performing simulation by computer processing,
Executing a plurality of processor emulators on the computer;
Running a plurality of plant simulators on the computer;
Executing a plurality of peripheral emulators on the computer, each having a unique processing delimiter timing and performing data communication between the processor emulator and the plant simulator;
Of the peripheral emulators, a step of finding a peripheral emulator whose processing break timing comes first and a timing of the processing break;
Synchronizing the plurality of processor emulators and the plurality of plant simulators at the found timing;
Simulation method. The computer is a multitasking system, and the plurality of processor emulators, the peripheral emulator, and the plurality of plant simulators are executed as individual threads or processes of the multiprocessor system. 6. The simulation method according to 6. The computer is a multiprocessor system, and the plurality of processor emulators, the peripheral emulator, and the plurality of plant simulators are assigned to different processors or cores of the multiprocessor system and are separated from each other. The simulation method according to claim 7, wherein the simulation method is executed as a process. Means for synchronizing the plurality of processor emulators and the plurality of plant simulators is ensured in a memory of the computer, and is provided corresponding to each of the plurality of processor emulators and the plurality of plant simulators. The simulation method according to claim 7, wherein synchronization is achieved by setting a flag. The simulation method according to claim 9, wherein the completion flag is realized by a counter semaphore.
A simulation program for performing simulation by computer processing, wherein the computer is
Running multiple processor emulators;
Running multiple plant simulators;
Executing a plurality of peripheral emulators, each having a unique processing break timing and communicating data between the processor emulator and the plant simulator;
Of the peripheral emulators, a step of finding a peripheral emulator whose processing break timing comes first and a timing of the processing break;
Causing the plurality of processor emulators and the plurality of plant simulators to synchronize at the found timing;
Simulation program. The computer is a multitasking system, and the plurality of processor emulators, the peripheral emulator, and the plurality of plant simulators are executed as individual threads or processes of the multiprocessor system. 11. The simulation program according to 11. The computer is a multiprocessor system, and the plurality of processor emulators, the peripheral emulator, and the plurality of plant simulators are assigned to different processors or cores of the multiprocessor system and are separated from each other. The simulation program according to claim 12, which is executed as a process. Means for synchronizing the plurality of processor emulators and the plurality of plant simulators is ensured in a memory of the computer, and is provided corresponding to each of the plurality of processor emulators and the plurality of plant simulators. The simulation program according to claim 12, wherein synchronization is achieved by setting a flag. 15. The simulation program according to claim 14, wherein the completion flag is realized by a counter semaphore.

Images