KR20130105609A - Simulation method, system and program - Google Patents

Abstract

Simulation of a system having a plurality of ECUs is executed at high speed with conservative event synchronization and avoiding deadlock. A simulation system is provided that consists of four layers of ECU emulators: a processor emulator, a plant simulator, an external peripheral scheduler, and a mutual peripheral scheduler. The external peripheral scheduler runs the plant simulator up to the response time of the processor emulator (or until the next event). Then, the processor emulator is notified to run ahead of time until the plant simulator actually stops. The mutual peripheral scheduler notifies the processor emulator to run ahead of time by the communication delay time between the processor emulators (or the time until the next event). The processor emulator conservatively proceeds to the earliest time notified. Each peripheral proceeds to the earliest time of the received events.

Description

Simulation method, system and program {SIMULATION METHOD, SYSTEM AND PROGRAM}

The present invention relates to simulation of physical systems such as automobiles, and more particularly, to a simulation system in a software base.

In the early 20th century, in the early days of the car, automobiles consisted of mechanical parts, including engines as power, brakes, accelerators, steering wheels, transmissions, suspensions, and ignition, heads of engine flags. Except for the lights, the electrical structure was rarely used.

However, since the 1970s, there is a need to efficiently control engines in preparation for air pollution, oil crisis, and the like. Therefore, ECUs have been used for engine control. In general, an ECU includes an input interface for A / D conversion of an input signal from a sensor, a logic operation unit (microcomputer) for processing a digital input signal in accordance with the determined logic, and a result of the processing of the actuator ( actuator) consists of an output interface that converts into an actuation signal.

Now, as well as control systems such as engines and transmissions, anti-lock break system (ABS), Electronic Stability Control (ESC), power steering, as well as wiper control In automobiles, up to security monitoring systems and the like, not only mechanical parts but also electronics parts and software occupy an important ratio. Development costs for the latter are known as 25% or 40% of the total, and 70% for hybrid cars.

In addition, an automobile is composed of a power device such as an engine, a power transmission device, a traveling device such as steering, a brake device, and other mechanical parts (plant) such as a body system. The program of the electronic control unit (ECU) of ˜70 or more determines dynamically according to sensor input (speed or the like) or input from a human being (accelerator or the like).

The ECU basically controls the operation of one plant each. For example, the fuel injection or ignition in the engine is determined by software by the engine control unit. Because of the software, luxury cars equipped with the [Sport] mode can increase / decrease fuel injection amount depending on the mode. In addition, in accordance with the timing of the shifting down, it is possible to automatically blip (idle) to match the rotational speed of the engine. In this case, the ECU of the engine and the ECU of the transmission need to operate in tandem. In an integrated electronic stability control (ESC) system for preventing slippage of an automobile, interworking with a braking device such as a brake is also required, which complicates the ECU software. In addition, since such [intervention] function is software, it can be easily cut.

In order to fully derive the performance of the plant and to fully operate it, it is important to sufficiently tune and test the operating parameters in the course of design development of the ECU software. In general, it takes too much time and money to make a prototype of a car, and then repeat tuning and testing, so that the controller and the plant can be virtually realized in a calculator device before the prototype, In addition, there is a strong demand for a method of operating correctly and confirming the operation. Such ECU simulations include (1) Model-in-the-Loop Simulation (MILS), which logically expresses the operation of the controller using an expression form such as a state machine, and (2) the logic operation. Software-in-the-Loop Simulation (SILS) with some hardware control including data precision, (3) Process-in-the-Loop Simulation (PILS) or Virtual Hardware- There are four types of in-the-loop simulation (V-HILS) and (4) hardware-in-the-loop simulation (HILS) to fully mount the ECU board and connect with real-time plant simulation. In this order, you get closer to the prototype.

MILS / SILS is mainly used in the trial and error phase to achieve the basic performance of the plant. However, since it operates differently from the software mounted on the ECU, it cannot be used for verification of the product. On the other hand, since V-HILS utilizes the finished ECU software, it is quite promising as a way to find and solve unexpected behavior (bugs) of the software, but there is no example of achieving reproducible operation. HILS is always performed for the final operation check of the completed ECU board, but it cannot be used for debug purposes because reproducibility is not guaranteed even if a fault is found.

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 the network realizes loose coupling between modules, the order of arrival of data may change due to subtle timing differences in module operation, and as a result, the behavior of the entire system may vary. Therefore, even if the prototype of the car is made, the reproducibility of the operation cannot be expected. This is why debugging parallel distributed systems is quite difficult.

In this way, due to the configuration of the HILS, that is, the configuration of loose coupling with the ECU board and the plant simulator, even if each component is speeded up, operation consistency cannot be realized. It is necessary to realize the consistency of the order of communication in order to realize the reproducibility of the operation. V-HILS is especially expected to solve this problem.

A typical V-HILS configuration, in accordance with conventional concepts, includes a plurality of ECU emulators, a plurality of plant simulators, and a global scheduler that schedules the entire operation.

The ECU emulator includes a processor emulator and a peripheral emulator. On the other hand, the plant simulator includes a brake simulator, an engine simulator, and the like.

At this time, the processor emulator operates with a relatively high resolution clock, for example 80 MHz. On the other hand, since the plant simulator is a simulator of a physical apparatus, it operates at a relatively low resolution of, for example, 10 KHz. In general, since the low resolution can be simulated at high speed, the plant simulator is often high speed.

Plant simulators do not necessarily perform numerical calculations with a fixed length of processing step time, and there are many cases in which variable steps are required depending on the influence of calculation errors or the timing of discontinuous change points. In any case, an instruction signal is received from the controller in each step, and an internal state is output toward the sensor. In addition, the instruction signal is often in a pulse state to express the on and off of the switch.

The peripheral emulator corresponds to the I / O interface portion of the ECU emulator and interconnects the plant simulator and the processor emulator. Typically (on average) it can operate at resolutions around 10MHz. This is faster than the plant simulator but slower than the processor emulator. The peripheral emulator sends a pulsed signal to the plant simulator. In addition, the internal state from the plant simulator is read as quantized data.

The peripheral emulator performs a request for read write (R / W), transmits and receives data, and sends an interrupt (INT) to the processor emulator. In particular, in a function of a network such as a controller area network (CAN) that interconnects processors, the transmission data is received from a processor (W), and communication between the peripherals is performed via a bus, and when data is received. Interrupt is sent to the processor (INT) and responds to the request (R) of the received data read from the processor.

In one aspect, the peripheral is the center of the system, which interconnects the plant, the processor, and the processors. If there is enough time resolution to distinguish the order of signals passing through the peripheral, the order can be correctly reproduced with respect to the interaction between the plant and the processor. However, if the time taken until the next signal determines the accuracy of the data (calculation of speed, etc.), the time resolution is preferably more accurate. In other words, the magnitude of the data error is determined according to the time resolution.

In addition to the problem of data error, there is an overhead problem. In other words, in the method of providing a fixed synchronization interval, a shorter synchronization interval can realize a more suitable operation. On the contrary, the overhead required for the synchronization processing is increased, so that the time required for the entire processing increases.

Therefore, the approach of fixing the synchronization interval as small as possible is not a realistic solution from both sides of data error and overhead.

Thus, in V-HILS, the problem of synchronization is important and, in summary, there are three methods as follows.

(1) Time synchronization: In this method, the processor emulators communicate with each other to execute simulations. There is a tradeoff between execution speed and time precision, and there are quantization errors in time. In addition, as described above, in this manner, since the synchronous communication cost between the processor emulators is large, it cannot be a realistic solution.

Optimistic Event Synchronization: In this scheme, each processor emulator synchronizes with its peer by sending and receiving events with visual information. However, even though there is a possibility of "flying", the simulation is executed speculatively, so if the speculation is not corrected, it is necessary to appropriately roll back the processor emulator. The cost of synchronization is small compared to the time-synchronized method, but it is not realistic because the cost of continuously recording a state for the rollback preparation is too large.

(3) Conservative Event Synchronization: In this scheme, each processor emulator synchronizes with its partner by sending and receiving events with visual information. However, because the simulation is carried out conservatively so that causality does not contradict, deadlock may occur because events are maintained in each other. In order to avoid such deadlocks, the cost of avoidance can be high, such as sending a special null message for a high amount of time.

As a prior art of V-HILS, Japanese Unexamined Patent Publication No. 2007-11720 discloses a system simulator that solves the problem of flexibly changing the configuration of a system simulator while responding to a complicated system. It consists of three types: instruction set simulator to simulate the operation of the CPU, bus simulator to simulate the operation of the bus, and peripheral simulator to simulate the operation of the peripheral. Initiates the installation of each reference-modifiable interface. However, this prior art does not suggest a method of optimizing the synchronization between the peripheral and the CPU.

Accordingly, the present inventors have developed a structure of conservative event synchronization to provide a simulation method using a peripheral scheduler described in the specification of (Japanese) Patent Application 2009-238954. In this method, the peripheral scheduler starts parallel operation by turning off the completion flags of all the peripheral emulators. In doing so, the peripheral scheduler, based on the timing of processing break of each set of peripheral emulators, is the one that will accept the earlist processing break. Find it. It is called Peripheral P. If the time at which the processing is stopped is T, the peripheral scheduler executes each processor emulator and each plant simulator until the time T is reached. In doing so, the peripheral scheduler waits for the completion flag of the peripheral P to be set. In response to the completion flag of the peripheral P being set, the peripheral scheduler synchronizes data between the peripheral P, the processor emulator, and the plant simulator.

Recently, however, there has been a desire for a simulation that is closer to the full operation of an actual device, which simultaneously emulates a plurality of ECUs on a multi-core host computer. However, although the execution speeds on the individual hosts of the plurality of ECUs are different from each other, explicit synchronization processing between them is required, but it is not easy to synchronize the plurality of ECUs due to communication in which interruption is performed irregularly between the ECUs. Since the method described in the (Japanese) Patent Application No. 2009-238954 is intended for a single ECU, it cannot be applied to the simulation of a system having a plurality of ECUs as it is.

Patent Document 1: (Japan) Patent Publication No. 2007-11720 Patent Document 2: (Japan) Patent Application No. 2009-238954

Accordingly, it is an object of the present invention to perform a simulation with a sufficient time accuracy and minimum data error and at high speed in a system having a plurality of ECUs and plants that provide each other with notification of asynchronous data (interruption). It is to provide a way to make it possible. Here, asynchronous data notification refers to, for example, notifying the controller of a state change occurring irregularly in a plant, asynchronous CAN communication between processors, and the like.

An object of the present invention is to link three types of processor emulator, peripheral emulator and plant simulator to simulate the entire system having an ECU and a plant under control thereof.

According to the present invention, the peripherals are separated into three types, namely, a mutual peripheral, an external peripheral, and an internal peripheral, and a unique scheduler is provided. These three types of schedulers cooperate to realize accurate link operation efficiently.

The mutual primary is an intermediate layer that handles communication between processors and has its own mutual primary scheduler. Topographical peripherals have the ability to handle asynchronous communications between processors at high speeds.

The outer peripheral is the middle layer that connects the plant and the processor and has its own outer peripheral scheduler. The external peripheral has the ability to receive asynchronous notifications from the plant, deliver them to the processor, and also send instructions from the processor towards the plant.

The internal peripheral is a peripheral layer to which only a specific processor is connected, for example, a watch dog timer or a memory. There is no signal exchange with the plant or other processors. It has its own internal peripheral scheduler (or processor scheduler).

The mutual peripheral scheduler, the external peripheral scheduler, and the internal peripheral scheduler operate in parallel in a co-routine form.

In addition, the plant simulator is preferably created with a continuous value simulation modeling system such as MATLAB (R) / Simulink (R). The peripheral emulator is a transactional emulator, preferably written in SystemC / TLM. The processor emulator performs emulation by the instruction set simulator (ISS).

The external peripheral scheduler selects the earlier of the response time between the processor emulator and the time when the next event occurs, and runs the plant simulator up to that time. In addition, all processor schedulers (or internal peripheral schedulers) are notified to actually execute them up to the time when the plant simulator is stopped. In addition, the reaction delay time calculates an instruction to the plant corresponding to it after receiving the notification of the state change from the plant, and refers to the minimum time difference from the time when the instruction becomes effective in the plant.

The mutual peripheral scheduler selects the earlier of [communication delay time] between processor emulators and the time when the next event occurs, and notifies all processor schedulers (or internal peripheral schedulers) to execute ahead of that time. . In addition, the communication delay time refers to the minimum time taken after the processor transmits data and before another processor receives it.

The processor scheduler (or the internal peripheral scheduler) proceeds to the earliest time of the reported target synchronization time. In this way, time adjustment is not performed between processors, and processing is conservatively performed from two kinds of peripheral schedulers toward a given synchronization time, thereby avoiding deadlock between processors at a low cost.

Each peripheral layer receives the event of the slowest progressing processor as an event and proceeds its own processing to that time. Further, based on the updated time, the next synchronization time notification is determined.

As described above, the simulation is performed in the order of the plant, the processor, and the peripheral, and the processing in which the heterogeneous links are performed as a whole is realized.

According to the present invention, since the processor emulator is executed beforehand using the response delay time of the processor emulator and the communication delay time between the processor emulators, a high speed simulation by conservative event synchronization without the overhead for avoiding deadlock is achieved. It is possible. Moreover, since it is a synchronization method based on the event which can represent arbitrary time instead of the synchronization by fixed time interval, accurate simulation with little time error is possible.

1 is a block diagram illustrating an example of computer hardware used to practice the present invention.
2 is a diagram illustrating an embodiment of a functional block for implementing the present invention.
3 is a diagram illustrating a delay in a processor, a peripheral, and a plant.
4 is a diagram illustrating a function of emulation of a processor.
5 is a diagram illustrating an example of an emulation operation of a peripheral.
6 is a diagram illustrating an example of a simulation operation of a plant.
7 is a diagram illustrating the components of an internal peripheral scheduler.
8 is a flowchart illustrating a process of an internal peripheral scheduler.
9 is a flowchart illustrating a process of an internal peripheral scheduler.
10 is a flowchart showing a process of an internal peripheral scheduler.
11 is a diagram illustrating the components of a mutual peripheral scheduler.
12 is a flowchart illustrating a process of a mutual peripheral scheduler.
13 is a diagram illustrating the components of an external peripheral scheduler.
14 is a flowchart illustrating a process of an external peripheral scheduler.
FIG. 15 is a diagram illustrating an example of entry and exit according to time of an event of a TQ and corresponding IQ and OQ in a mutual peripheral scheduler.
16 is a diagram illustrating a configuration of a logic process.
17 is a diagram illustrating a connected logical process group.
18 is a diagram showing a state where deadlock is prevented by a null message.
19 is a diagram for describing communication delay of a processor.
20 is a diagram for describing a response delay of a processor.
21 is a diagram for explaining simulation of shared memory access.
FIG. 22 is a diagram for explaining the emulation of a peripheral having a high frequency of communication with a processor by a core such as an ISS.
FIG. 23 is a diagram for explaining a simulation of an operation of updating an adjustment upon interruption of a CAN device.
24 is a diagram for explaining reset simulation of a CAN device.
25 is a view showing another embodiment of a functional block for practicing the present invention.
Fig. 26 shows a flowchart of the operation of the external peripheral scheduler for the passive plant simulator.

EMBODIMENT OF THE INVENTION Hereinafter, with reference to drawings, the structure and process of one Example of this invention are demonstrated. In the following description, unless otherwise specified, the same elements are referred to by the same reference numerals in the drawings. It is to be understood that the configuration and processing described herein are described as an example and are not intended to limit the technical scope of the present invention to these examples.

First, with reference to FIG. 1, the hardware of the computer used for implementing this invention is demonstrated. In FIG. 1, the host bus 102 includes a plurality of CPU1 104a, CPU2 104b, CPU3 104c,... Main memory 106 for arithmetic processing of CPUn 104n is connected.

On the other hand, the keyboard 110, the mouse 112, the display 114, and the hard disk drive 116 are connected to the I / O bus 108. The I / O bus 108 is connected to the host bus 102 via the I / O bridge 118. The keyboard 110 and the mouse 112 are used for the operator to input a command, click a menu, or the like. The display 114 is used to display a menu for operating the process in the GUI, as necessary.

As hardware of the preferred computer system used for this purpose, IBM (R) System X is. At this time, CPU1 104a, CPU2 104b, CPU3 104c,... The CPUn 104n is, for example, Intel (R) Xeon (R), and the operating system is Windows (trademark) Server 2003. The operating system is preferably one having a multitasking function. The operating system is stored in the hard disk drive 116 and is read from the hard disk drive 116 to the main memory 106 at startup of the computer system.

In order to implement the present invention, it is preferable to use a multiprocessor system. The multiprocessor system is generally intended to be a system using a processor having a plurality of cores of processor functions that can be independently arithmetic, and therefore, a multicore single processor system, a single core multiprocessor system, and a multiprocessor. Please understand that any of the core multiprocessor systems may be used.

In addition, the hardware of the computer system which can be used for implementing this invention is not limited to IBM (R) System X, As long as it can operate the simulation program of this invention, arbitrary computer systems can be used. The operating system is not limited to the Windows (R) series, but any operating system such as Linux (R) or Mac OS (R) can be used. Moreover, in order to operate a simulation program at high speed, the operating system based on POWER (trademark) 6 can use computer systems, such as IBM (R) System P of AIX (trademark).

The hard disk drive 116 also stores a program such as a processor emulator, a peripheral emulator, a plant simulator, an internal peripheral scheduler, a mutual peripheral scheduler, an external peripheral scheduler, a CAN emulator, and the like, which will be described later. Each of them is loaded into the main memory 106 at the time of startup of the computer system, assigned to individual CPU1 to CPUn as individual threads or processors, and executed. For this reason, the computer system shown in FIG. 1 is preferably individually assigned to individual threads, such as a processor emulator, a peripheral emulator, a plant simulator, a mutual peripheral scheduler, an external peripheral scheduler, and a CAN emulator. Have enough CPU

Fig. 2 shows a processor emulator, a peripheral emulator, a plant simulator, a mutual periphery scheduler, an external periphery scheduler, a CAN emulator, etc., operating as individual threads or processes assigned to such individual CPUs 1 to CPUn. It is a functional block diagram showing a cooperative relationship between processing programs.

This configuration is a simulation system made from a processor emulator and a peripheral emulator corresponding to an ECU, and a plant simulator. Peripheral emulators are divided into mutual and external peripherals. In addition, although not shown in the figure, it is to be understood that the internal peripheral is included in a block of the processor emulator. In the whole, it turns out that it is a simulation system of four layers in the lateral direction of a figure.

In Fig. 2, the processor emulators 202a, 202b, ... 202z have a central function as a controller among the functions of the ECU in the simulation system. Processor emulators 202a, 202b, ... 202z load software code to perform emulation by instruction set simulator (ISS).

The peripheral emulators 204a, 204b, ... 204z, and the CAN emulator 212 are transactional emulators, and are preferably made of SystemC / TLM.

Plant simulators 206a, 206b, ... 206z are preferably created with a continuous numerical simulation modeling system such as MATLAB (R) / Simulink (R). Each of the plant simulators 206a, 206b,... 206z corresponds to a power device such as an engine, a power transmission device such as a transmission, a traveling device such as a steering, and a vehicle mechanism device such as a brake device.

Processor emulators 202a, 202b,... 202z operate with a relatively high resolution clock, typically 80 MHz, for example. On the other hand, since the plant simulators 206a, 206b, ... 206z are simulators of physical instruments, for example, they typically operate at a relatively low resolution of 10 KHz.

Therefore, since the processor emulators 202a, 202b, ... 202z and the plant simulators 206a, 206b, ... 206z cannot be directly connected, the peripheral emulators 204a, 204b, ... 204z are interposed therebetween, so that the plant simulator It converts the state change from the sensor or the value of the sensor into an event and sends it to the processor emulator, or, conversely, converts an instruction (signaling) from the processor emulator to an event and sends it to the plant simulator.

The internal peripheral scheduler performs scheduling of the processor emulator and the peripheral emulator connected to it. The peripheral emulator, which connects to the processor emulator, handles peripheral (internal peripheral) functions that are not directly related to other processors or plants, such as ROM, RAM, and watchdog timers. The internal peripheral scheduler has an important function of distributing load / store instructions from the ISS to the internal peripheral scheduler, mutual peripheral scheduler, and external peripheral scheduler by referring to the ECU's memory map specification. In the following description, the internal peripheral scheduler is referred to as a processor scheduler. However, it is noted that both refer to the same function.

The external peripheral scheduler 208 is a scheduler that processes the peripheral emulators 204a, 204b, ... 204z connected to the plant simulators 206a, 206b, ... 206z. The external peripheral scheduler 208 schedules the plant simulators 206a, 206b, ... 206z to run ahead of time by the response delay time (or the time until the next event) of the processor emulators 202a, 202b, ... 202z. do. The plant simulator stops at the specified time or before that time if notification of the update of the internal state is necessary. In fact, the processor emulator 206a, 206b, ... 206z is actually notified to the processor emulator before execution by the time when it is stopped.

The external peripheral scheduler 208 instructs the plant simulators 206a, 206b,... 206z of the signaling or sampling requested from the controller. The signaling is an event for the controller to actuate the plant, for example, an operation of indicating an ON / OFF signal of the switch. In addition, sampling is an event for instructing the reading of a value when the controller monitors the state of the plant. For example, the sampling is an operation in which the controller reads the voltage value of the battery cell (plant). Here, the controller is software loaded in the processor emulator and refers to logic that generates control signals for the plant. For signaling and sampling, the controller determines its timing, whether or not the process to be emulated is periodic.

On the other hand, the external peripheral scheduler 208 receives a notification of a state change event from the plant simulators 206a, 206b, ... 206z. This is an event where the plant notifies the controller of a change in state, and the plant determines its timing. This may be periodic, or it may be aperiodic.

The mutual peripheral scheduler 210 is a scheduler that provides a mutual peripheral function that connects the processor emulators 202a, 202b, ... 202z. The mutual peripheral scheduler 210 notifies the processor emulators 202a, 202b, ... 202z to execute in advance by the communication delay time between the processor emulators 202a, 202b, ..., 202z (or the time until the next event). . The processor emulators 202a, 202b, ... 202z conservatively proceed to the earliest time of the notified time. At this time, communication between the processor emulators is performed by, for example, a controller area network (CAN) emulator 212. The simulation when the shared memory is used for communication between the processors of the ECU will be described later with reference to FIG. 21.

As shown in FIG. 2, the events from the external peripheral scheduler 208 and the mutual peripheral scheduler 210 to the processor emulators 202a, 202b,... 202z are performed in the form of interruption INT. The events from the emulators 202a, 202b, ... 202z to the external peripheral scheduler 208 and the mutual peripheral scheduler 210 are performed in the form of a read write (R / W).

Referring to FIG. 3, a description will be given of the preceding execution using the delay in the processor emulator (or processor scheduler), the mutual peripheral scheduler, the external peripheral scheduler, and the plant simulator.

First, as shown in FIG. 3 (1), the external peripheral scheduler 208 preliminarily executes the plant simulator 206. The time actually preceded is called T _plant .

* The upper limit of the preceding time is the next signal or the one closer to ΔT _R. Here, ΔT _R is the minimum value of the delay from the input time from the plant simulator to the reaction of the processor emulator by which it is transmitted to the plant simulator, and is explained in more detail in FIG. 20.

Next, as shown in FIG. 3 (2), the external peripheral scheduler 208 notifies the processor emulator 202 to execute up to the position T _plant where the plant simulator 206 actually stopped. .

Next, as shown in Fig. 3 (3), the mutual peripheral scheduler 210 is the processor emulator 202 until the earlier of the communication delay time between the processor emulators 202 and the time until the next event. ) Is executed beforehand. In the figure, an example in which the communication delay time is earlier is shown.

The communication delay time ΔT _c will be described in more detail in FIG. 19.

Next, as shown in Fig. 3 (4), the processor emulator 202 conservatively proceeds to the earliest time of the two notified times, but it can be said that the processing proceeds without any interruption until that time. For example, if there is a read R of the shared memory, the time stops once. In the figure, the state once stops at time 4 is shown before progressing to the time 3. If there is no access to the shared memory, the process advances to time (3) at once.

As shown in Fig. 3 (5), the mutual peripheral scheduler and the external peripheral scheduler proceed their own processing to the earliest time of the events received from the processor.

Next, referring to FIG. 4, the emulation function of the processor will be described. As described above, the emulation of the processor is realized as an instruction set simulator (ISS). The emulation of the processor executes at a specified time, outputs a request for access (R / W) in accordance with an instruction (instruction), and receives an irregular interruption resulting from the peripheral.

In particular, in this embodiment, for convenience of explanation, the instruction to the ISS and the request from the ISS are described as follows.

Instruction or notice to ISS

advance (t): Instructs the ISS to execute up to time t. However, if communication is required before the time is reached, the ISS stops processing to print the request.

resume (v): Notifies the ISS of the data corresponding to the read request and resumes execution.

interrupt (i): Notifies the ISS that an interruption i has occurred.

Request or Notice from ISS

load (t, a): Requests to load data at address a at time t. After that, processing stops until the resume notification is received.

store (t, a, v): requests that data v be written to address a at time t.

complete (): Proceeds notification of completion when progressing to time t indicated in advance.

4 shows an example of an emulation operation of a processor by such an instruction. In Fig. 4, first, the processor receives a command called advance (t _g ). The processor outputs load (t ₁ , a ₁ ) at time t ₁ . In response, the processor receives resume (v ₁ ). The processor outputs store (t ₂ , a ₂ , v ₂ ) at time t ₂ .

When the time t _g is reached, the processor outputs complete () in accordance with the advance (t _g ) previously received. After that, the processor may receive an interrupt (i) depending on the plant's response. Otherwise, it receives the next advance () indication.

Next, with reference to Fig. 5, the operation of the emulation of the peripheral. As described above, the peripheral emulator is preferably implemented by SystemC. The emulation of a peripheral is to perform a transactional execution in accordance with an event loaded in a task queue.

Events include a register read request and a write request. Peripheral emulation takes this event from the beginning of the task queue, interprets it, executes it as a transaction, converts it into a new event, and inserts it back into the task queue. Some convert to one or more events, and some do not generate any events at all. The interpretation and execution of events depends on the capabilities of the individual peripherals. By repeating this process until there are no events, periphery emulation is performed. In other words, it is a repetition of pop, execute, and push.

In this embodiment, the simulation is not a simulation of the peripheral, but a simulation that links with a processor or a plant. Therefore, an event flows back and forth across task queues of a plurality of peripheral emulators. In this case, the peripheral scheduler adds the event to the appropriate task queue. That is, iteration of pop, execute, push or export, and import. However, import is an option (none) depending on the cycle.

The input and output of the plant simulator are <port_update, t, p, v> events. This informs time t of the value y that port p takes. For example, the instruction (signaling) to a plant and the notification of the change of state from a plant are represented by this.

The requests from the processor are the <read, t, r> and <write, t, r, v> events, which are events that request reading of the value that register r takes at time t, and register r at time t, respectively. This event requires that the value v be written. In contrast, the processor receives the <register_update, t, r, v> event, which notifies the value v of the register r at time t in response to the <read, t, r> request. <Interrupt, t, i> is also a reception event, which is an event for notifying that an interruption i occurs at time t.

In particular, in this embodiment, for convenience of explanation, operations related to the peripheral task queue are described as follows.

insert (e [t]): Adds an event e [t] to the task queue that occurs at time t.

next (): k: Pops up the head of the task queue, executes it, and returns a new event if necessary in response.

peek (): t: Returns the time t of the event at the head of the task queue.

New events returned by Next include internal events associated with the peripheral, such as timer ignition, but in particular, events that need to be sent to other peripherals include <interrupt, t, i>, <register_update, t, r, v>, and <port_update, t, p, v>.

The operation of the peripheral, of course, does not end with this, but first, the description relating to the operation of the present invention has been described.

5 shows an example of an emulation operation of a peripheral. In FIG. 5 (1), since the task queue operation instruction insert (e ₁ [t ₁ ]) arrives _first from the scheduler to the peripheral, the event e ₁ is added to the task queue by the FIFO. If the task queue is empty or the time of the other event is later than t ₁ , e ₁ enters the head of the task queue. Where e ₁ is the register read request.

Next, when the operation command next () arrives, the event at the head of the task queue is interpreted and executed as a transaction, and a new event <register_update, t ₁ , r ₁ , v ₁ > is output. This example is a sequence of processes from the processor making a request to read the value of a register and then obtaining the response. Because it is an event that needs to be sent externally, it is not pushed to the original task queue, but is exported to the processor's scheduler.

As shown in Fig. 5 (2), in the same way to the buffer referral, even when write request insert (e ₂ [t _2]) and the next () command to register the arrival order, e ₂ contained in the task queue If is the head, e ₂ is popped at time t ₂ , for example, a new event <port_update, t ₂ , p ₂ , v ₂ > is returned to the scheduler. This example is a case where the processor has directed signaling to the plant. The new event is converted into a format that can be interpreted by the plant simulator and forwarded.

The example of FIG. 5 (3) shows a state in which there is a notification of a change of state from the plant, and conveys it to the processor using an interrupt signal. When the scheduler adds a notification of a change of state to the task queue (insert (e ₃ [t ₃ ])) and then pops it out, the conversion to a new event is performed, resulting in <interrupt, t, i>, It is exported to the processor.

Next, with reference to FIG. 6, the operation | movement of the simulation of a plant is demonstrated. As mentioned above, the simulation of the plant is preferably realized by a continuous numerical simulation modeling system such as MATLAB ® / Simulink ®. The plant first calculates an output (vector) according to an internal state (vector) or an external input (vector) at a designated time. Next, the change (vector) of the internal state is output, but at this time, the change of the internal state is adjusted based on the specified error range, the plant-specific maximum step width, zero crossing, and the like. Decides the time of day.

In particular, in this embodiment, for convenience of description, the operation of the plant is described as follows.

Instruction to the plant

advance (t): Instructs the plant to execute up to the maximum time t. However, if the step cannot be increased to time t, the operation stops at the previous time.

input (u): notification from the plant that updates the input vector u to the plant

complete (): Signals that execution has completed until advance at the specified time.

output (t, y): At time t, notify the plant that the output vector y has been updated.

The operation of the plant, of course, does not end with this, but first, the description relating to the operation of the present invention has been described.

For reference, the correspondence with Simulink (R) 's S-Function callback routine is as follows.

mdlGetTimeOfNextVarHit () call up complete ()

mdlGetTimeOfNextVarHit () return advance (t)

mdlOutputs () call up output (t, y)

return input (u) from mdlOutputs ()

6 shows an example of the simulation operation of the plant. In FIG. 6, first, the instruction advance (t _g ) comes to the plant. The plant outputs output (t ₁ , y ₁ ) at simulation time t ₁ .

Next to the plant, input (u ₁ ) arrives. The plant outputs output (t ₂ , y ₂ ) at simulation time t ₂ .

Next to the plant, input (u _g ) arrives. When the simulation time t _g is reached, the plant outputs complete ().

As such, advance and complete, or output and input, are paired, respectively.

In the present invention, the internal peripheral scheduler, the mutual peripheral scheduler, and the external peripheral scheduler play a major role. In order to explain the operation of these three schedulers, first, the outline of the conservative event synchronization simulation and the terminology will be explained first.

First, FIG. 7 is a diagram showing a process relating to an input queue and an output queue in the internal peripheral scheduler. As shown, input queues include input queues from processors (IPs), that is, queues that receive events from other processors (update notifications in shared memory), and from IQs, ie mutual or external peripherals. There is a queue to receive messages. P _i and P _j are the i th and j th processors, respectively. The data stored in the IQ is a CAN receive or interrupt event message or a null message.

On the other hand, output queues include Output Queue Processors (OPs), that is, queues that send events (notification of shared memory updates) to other processors, and OQs, which send messages to mutual or external peripherals. . The data stored in the OQ is an event message or a progress null message of a CAN transmission.

When processors exchange events with each other, IP and OP are used as one set for each connected processor.

Next, the processing of the internal peripheral scheduler will be described with reference to the flowcharts of FIGS. 8 to 10. The initial value of the flow chart of FIG. 8 is that all IQ / IPs are empty, all OQs are the time zero progress event, all OPs are empty, and T: = 0.

In addition, the time T _k of the event arriving at the kth at IQ / IP satisfies the following conditions.

T _k ≤ T _{k + i}

The internal peripheral scheduler waits for queue input e at step 802 and at step 804 determines if all IQs have been filled (if at least one message has arrived) and if filled, step 806. In FIG. 5, the earliest time within all IQ is T ₀ , and a subroutine called [parallel] is called in step 808 to perform processing with other processors. The processing of the subroutine of [parallel] is described later with reference to the flowchart of FIG.

In step 810, the internal peripheral scheduler determines whether an event e that satisfies the condition T _e = T in Q, ie, T _e = T in IQ, is in IQ. And, if there is, the internal peripheral scheduler, at step 812, pops e from the IQ, processes it, and returns to step 810.

In step 810, if there is no event e that meets T _e = T in the IQ, the process returns to the determination in step 804.

Next, with reference to the flowchart of FIG. 9, the processing of [parallel] in step 808 will be described in more detail. The internal peripheral scheduler, at step 902, determines if the process was "read" and if it is a read, invokes the subroutine of [fill] at step 904.

The subroutine of [fill] will be described later with reference to the flowchart of FIG. Step 904 is followed by step 906. In step 902, if the process is not " read &quot;, the process proceeds directly to step 906. FIG.

Step 906 enters a value in T ₁ by the formula T ₁ : = min (T ₀ , T _top ). T _top is the top time of the IP, and T _top = ∞ when there is no IP (no processor performing shared memory communication) or when the IP is empty.

In step 908, the internal peripheral scheduler runs the processor with a target of T ₁ . That is, the process proceeds to the time indicated by the mutual peripheral scheduler or the external peripheral scheduler.

In step 910, the internal peripheral scheduler advances the time T by that amount while executing the processor, and in step 912, performs an update flash of OQ / OP.

At step 914, the internal peripheral scheduler determines if T = T ₁ , if not, at step 916, determines if the last notification from the ISS is “read” and if it is a lead. Return to step 904.

If at step 916, it is determined that the last notification from the ISS is not “read” [read], then at step 918, one of writing to the shared memory, sending a CAN, or sending a null message is performed. 908).

In step 914, if T = T ₁ , go to step 920, where it is determined whether there are events in the IP that satisfy the condition of T _e = T in IP, ie, T _e = T. If it is at the IP, in step 922, the event e is popped from the IP and processed, and returned to step 920.

If at step 920 it is determined that there is no event at the IP with the time of event e, then at step 924 it is determined whether T = T ₀ , and if so, the process ends.

If at step 924, it is determined that T = T ₀ , then at step 926, either a read on the shared memory, or the receipt of a null message is performed, returning to step 902.

Next, with reference to the flowchart of FIG. 10, the processing of [fill] in step 904 will be described in more detail. In Fig. 10, the internal peripheral scheduler creates a temporary list of entries in the queue of IPs. After the temporary list is created, all messages having a time stamp older than the current time in the IP are removed and added to the temporary list.

In step 1004, the internal peripheral scheduler determines whether all IPs are filled. If so, then at step 1006, all events in the temporary list (written to the shared memory from another processor) are processed in time stamp order. When you finish processing the temporary list, the subroutine of fill completes.

If at step 1004 it is determined that not all IPs are filled, then the process proceeds to step 1008, where the internal peripheral scheduler waits for an event e from the IP.

In step 1010, it is determined whether T &gt; T _e , and if so, in step 1014, e is added to the date and time list and updated to step 1008.

If at step 1010 it is determined that T &gt; T _e , then the internal peripheral scheduler returns to step 1004 by adding e to the IP at step 1012.

Fig. 11 is a diagram illustrating processing relating to queues in the mutual peripheral scheduler. As shown, the input queue IQ receives events from P _i and P _j , which are sent to the CAN emulator.

On the other hand, when an event comes into the output queue OQ from the CAN emulator, the processor retrieves it.

In addition, a task queue TQ is installed, which results in ignition of the CAN emulator reception. In addition, in the following description, it is noted that an event in a task queue is called a task to distinguish it from an input queue or an output queue.

Next, with reference to the flowchart of FIG. 12, the process of a mutual primary scheduler is demonstrated. The initial value here is that all IPs are empty, all OQs are empty, TQ is empty and T: = 0. In step 1202, the mutual peripheral scheduler performs a wait for update of the IQ, and in step 1204, determines whether all IQs are filled, otherwise returns to step 1202 to wait for an update of the IQ. Continue.

Thus, at step 1204, if the mutual peripheral scheduler determines that all IQs are filled, then at step 1206, the closest time of all IQs is referred to as T ₀ .

In step 1208, the mutual peripheral scheduler determines if there is a task e such that T _e = T ₀ in IQ, ie T _e = T ₀ at IQ. If so, the mutual peripheral scheduler pops event e at step 1210 and updates TQ by insert (e ₁ [t]), insert (e ₂ [t]) at step 1212. Perform. Here, event e ₁ is an event of reading the value of register r at <read, t, r>, that is, time t, and event e ₂ is a register r at <write, t, r, v>, that is, time t. Updates the value of to v.

Following step 1212, return to step 1208, where there is no task e, where the mutual peripheral scheduler determines that I _e = T _e = T ₀ , then in step 1214, T: = set to T _0, and at step 1216, by using a peek (), T _k = T in TQ that is, it is determined whether there is a TQ T _k = T k is the task.

In step 1216, if it is determined that Tk has a task k such that T _k = T, then the mutual peripheral scheduler pops k in step 1218, and in step 1220, the task is determined by next (). Run When CAN data is received here, the events <interrupt, t, i>, <register_update, t, r, v> are notified to the processor.

In step 1222, the mutual peripheral scheduler updates all OQs and returns to step 1216.

If it is determined in step 1216 that there is no task k in TQ where T _k = T, then control proceeds to step 1224, where the mutual peripheral scheduler determines whether there has been an update in OQ.

If there is no update to the OQ, the mutual peripheral scheduler adds a null message at time min (T + ΔT _c , T _top ) to all OQs at step 1226, and flashes the OQs at step 1228. The process returns to step 1204. ΔT _c is a communication delay time of the processor.

If there is an update to the OQ, the mutual peripheral scheduler flashes the OQ at step 1228 and returns to step 1204.

15, for reference, shows an example of entry and exit according to the time of the TQ and the events of the IQ and OQ corresponding thereto in the mutual peripheral scheduler. The dashed arrows indicate the progress of guest time.

In this example, the events in the message arriving from the processor scheduler (internal peripheral scheduler) at IQ are: CAN abort, CAN transmit, null (event in progress message), CAN reset in cronological order. to be. All of the above non-null messages are events that occur when the processor issues a command (performs a register write) to the CAN device. Among them, the CAN abort is an event which issues a command to perform the release of the transmission standby state and to notify the processor of the interruption in case of failure in the arbitration. CAN communication is an event that issues a command to transmit data set in advance. 15 shows an example in which CAN transmission events continue to arrive from two different processors. CAN reset is an event that issues a command to disconnect the CAN device from the bus and return to the initial state.

In this example, the event of the message sent from the OQ to the processor scheduler is null (event of null message), abort notification, CAN reception in chronological order. CAN reception is an event in which the CAN device notifies the processor by interruption that it has received CAN data. Abort notification is an event in which the CAN device notifies the processor by interruption that an adjustment has failed.

At the time when a CAN transmission event occurs (arrival at IQ), there is a case where data previously transmitted has been transmitted. In the example of FIG. 15, at the time when two CAN transmission events arrive, the CAN reception event (first) is added to the head of the TQ upon completion of the previously initiated transmission. Immediately after a CAN receive event, an adjustment is performed for the next data transfer. In the example of this figure, for simplicity, it is assumed that the time of the event of CAN reception and the event of adjustment is the same. The time stamp of a null event arriving at IQ is the same as the guest time of the CAN receive adjustment. The mutual peripheral scheduler of the present invention includes a process of notifying the processor scheduler (sending a null message) to be executed up to the leading time of the TQ. A null arriving at IQ in FIG. 15 is a progress message that the processor scheduler notifies that the processor has reached the time notified by this process. In addition, the null message initially sent by OQ of FIG. Shows that the processor scheduler was notified of the preceding execution in this process.

When the adjustment is performed, of the required CAN transmissions from two processors, one side is received (successful in the adjustment) and the other side is suspended (failed in the adjustment). In the figure, although the event of CAN reception to the processor which performed the former transmission request is an event of the interruption notification to the processor which performed the latter transmission request, it shows that all are added to TQ. In accordance with the progress of the emulation of the CAN device, two additional events are processed in order, so that the corresponding events (stop notification, CAN reception) are notified to the processor scheduler via OQ, respectively.

Fig. 13 is a diagram illustrating processing relating to queues in the external peripheral scheduler. As shown, the input queue IQ receives messages from P _i , P _j .

The event message and the null message of the interruption notification are sent to the output queue OQ, and P _i and P _j draw them out.

The task queue TQ is sorted by time stamp.

The external peripheral scheduler also retains the current signal value of the I / O port connecting to the plant.

Next, the processing of the external peripheral scheduler will be described with reference to the flowchart of FIG. 14. The initial value here is that all IQs are empty, all OQs are empty, TQ is empty, and PV (port value) is the initial value in the ECU specification, T: = 0, T _R : = ΔT _R.

In step 1402, the external peripheral scheduler performs a wait for update of the IQ, and in step 1404 it determines whether all IQs are filled, otherwise returns to step 1402 to wait for update of the IQ. Continue.

Thus, at step 1404, if the external peripheral scheduler determines that all IQs are filled, then at step 1406, the closest time of all IQs is T ₀ . Where T ≦ T _e ≦ T _p and T _p is the current plant time.

In step 1408, the external buffer referral scheduler, T _e = T ₀ in IQ, that is, determine that the IQ T _e = T _0, the task that is e. If there is, the external peripheral scheduler pops event e at step 1410 and, at step 1412, updates TQ by insert (e ₁ [t]), insert (e ₂ [t]). To perform. Here, event e ₁ is an event that reads the value of register r at <read, t, r>, that is, time t, and event e ₂ is a register at <write, t, r, v> that is, time t. This event updates the value of r to v.

Next to step 1412, return to step 1408, where the external peripheral scheduler determines that there is no task e in IQ where T _e = T ₀ , and in step 1414, T: = Set to T ₀ , and at step 1416, determine whether T = T _p .

If at step 1416 determines T = T _p , the external peripheral scheduler calls insert (e ₄ [T]) at step 1418 and fires on TQ at time T the task <plant_go Add>. Here, e ₄ is an event which runs a plant to time min {T _top , T + ΔT _R }. T _top is the start time of TQ, and T _top = ∞ when TQ is empty. This is the process of running the plant ahead, i.e. if all the processors track the plant.

Following step 1418, the process proceeds to the decision step of step 1420. If it is determined in step 1416 that T = T _p , then go directly to step 1420.

In step 1420, the external peripheral scheduler invokes peek () to determine, at TQ, if there is an event k such that T _k = T. If not, the process returns to step 1404.

In step 1420, if it is determined that there is an event k such that T _k = T in TQ, then the external peripheral scheduler proceeds to step 1422, pops k, and in step 1424, k runs the plant. Determines if

If, at step 1420, the external peripheral scheduler determines that k is a plant run, then at step 1426, advance () is invoked to execute the plant.

In a next step 1428, the external peripheral scheduler updates the TQ. In total, it receives output (t, y), executes pusg (e ₃ [t]), and references PV to notify input (u). Then send a null message. Here, e is ₃ is, events that update the <port_update, p, v> v the value of the port p using.

In a next step 1430, the external peripheral scheduler updates T _p and in a next step 1432, determines whether the process is complete. If it is determined that the process is complete, the process returns to step 1420. If it is determined that the processing is not complete, the task returns to step 1434 and then the processing returns to step 1420.

Returning to step 1424 and determining that k is not a plant run, the external peripheral scheduler proceeds to step 1434 and invokes next () to execute the task. Specifically, this executes <interrupt>, <register value>, <register_update>, and <port_update>, and transmits a null message.

In a next step 1438, the external peripheral scheduler updates the OQ. Here, if a non-null message is added to the OQ, add a task <plant_go> that fires at the time T + ΔT _R to the TQ. That is, although insert (e ₄ [T + ΔT _R ]) is executed, more specifically, e ₄ executes the plant to time min {T _top , T + ΔT _R }. Here, T _top is the start time of TQ, and when TQ is empty, T _top = ∞.

In the next step 1440, the external peripheral scheduler flashes the OQ and returns to step 1420.

In the following, deadlock occurs when performing conservative event synchronization, and a null message is required to avoid it. Again, this is not a new discovery, but is known in the art.

When dividing a simulation target to connect a simulator (or an emulator) of each region and perform a whole simulation, the simulation unit of each region including the communication interface is called a logic process. 16 shows the configuration of a logic process.

As shown in Fig. 16, in the conservative simulation of event synchronization, the logical process LPk includes an input queue IQ for receiving a message, an output queue OQ for transmitting a message, and a task queue TQ for storing a scheduled simulation task. And a scalar value representing the current time. IQ and OQ are FIFOs, and TQs are sorted in chronological order.

FIG. 17 is a diagram showing how a plurality of logic processes LP1 to LP4 are connected via a communication channel. In order to achieve such a connection, each logical process has IQ and OQ for each communication channel.

The logic process uses IQ and OQ to exchange messages with time information (time stamps). The time stamps of messages sent / received in IQ / OQ are monotonically increased each time transmission / reception is performed. For this reason, when a logic process receives a message from all other logic processes, the simulation can proceed without rolling back to the smallest time stamp of the received message. The messages exchanged include event messages and null messages.

The event message relating to the event e at time t is a message that says that the time of the next event occurring from the transmitting side to the receiving side is t, and the generated event is e.

The null message at time t is a message for saying that [the time of the next event occurring from the sending side to the receiving side is later than t] and does not affect the simulation area itself at the receiving side. The purpose of a null message is to prevent the deadlock described below. In conservative event synchronization, processing is stopped until a message with a time stamp larger than the current time is received from all other logic processes to prevent rollback. However, if the logical process of the other party waiting for the reception of the message also waits for reception from the logical process at the same time, as shown in Fig. 18A, each other is waiting for the message and processing cannot be resumed. Therefore, [read ahead] how far the external event does not occur from the current time, and sending a null message as shown in Fig. 18B, deadlock is prevented.

The outline of the processing of the logical process is as follows.

(1) Wait for a message to arrive at all IQs

(2) Pop the earliest message (t = T ₀ ) in IQ

(3) Run the simulation while advancing the current time up to T ₀ (pop the task queue and run it)

(a) future events are added to the task queue

(b) Events that occur externally are sequentially added to the OQ.

(c) Add null message to OQ without event addition (t = current time + read ahead)

Process the message popped at (2) and return to (1)

In the present invention, in particular, a null message (a null message having a current time as a time stamp when transmitting) that does not perform [read in advance] is called a progress message. The purpose of a progress message is to avoid frequent synchronization caused by a null message with a small read width. In the present invention, the internal peripheral scheduler sends a progress message. This is because the ISS driving the internal peripheral scheduler can predict the next event of another logical process with a small width.

Next, the communication delay ΔT _c of the processor will be described with reference to FIG. 19. That is, as shown, the minimum value of the delay from writing to the mutual peripheral to the interruption to the receiving / transmitting processor is the communication delay ΔT _c of the processor.

For reference, in communication with a CAN of maximum baud rate of 1.0 Mbps, the maximum delay of the data frame is 44 μs (the minimum number of bits in the frame is 44), which is a reference value of ΔT _c .

Next, the processor response delay ΔT _R will be described with reference to FIG. 20. That is, the response delay ΔT _R of the processor is, as shown, the minimum value of the delay from the input time of the plant until the response of the processor is transmitted to the plant and becomes effective. In FIG. 20, T _R is the minimum time at which the reaction of the processor is likely to reach the plant when TQ is empty.

As a premise, a register write (for example, a write to a timer start register) that defines the first event occurrence time T _reaction to the plant occurs within T _R from the time of receiving an interrupt due to a change in the state of the plant. When this write time is described as T _trigger , the following equation is established.

T _trigger ≪ TR ≤ T _reaction

Even if the plant is run ahead of time by determining the action (time T _trigger ) and then the time from the actuator to action (time T _reaction ), time precision is not lost. Based on the use, the response delay ΔT _R of the processor is used.

Next, an example of the processor response delay is shown. As a first example, in the engine fuel injection control, when a rotation pulse (state change) occurs from the plant every 15 degrees of the crank, the instruction of fuel injection or ignition is executed by using a timer to correct the time. Since the time set to the timer is calculated when one or more of the above-mentioned rotation pulses are generated, at least one pulse interval, that is, at the maximum rotational speed of 10,000 rpm, the pulse interval of 250 µs or more is sufficiently delayed until the injection ignition. This is called delayed reaction.

As another example, in control in which the processor immediately returns an instruction on input from the plant, the response delay is very small. However, this kind of control often performs periodic tasks on physical phenomena that are slower than processors (for example, directing a PWM signal to a fan whose temperature is the control amount, and a throttle (the vehicle speed as the control amount). throttle) instructions of opening). The reference periods for the control cycles of temperature, speed and torque are 1 second, 1 millisecond and 0.1 millisecond, respectively, so there is no need to provide instructions to the plant in finer units. Therefore, the time determined by the size of the time units of the plant is used as the reaction delay.

Next, with reference to FIG. 21, a simulation of shared memory access will be described. In FIG. 21, it is assumed that processors Pr1, Pr2, and Pr3 access shared memory. There, suppose that the processors Pr1 and Pr2 precede and the processor Pr3 follows the processors Pr1 and Pr2. Processor Pr3 then knows from the contents of the IQ that it is at the latest time and the time of the second processor behind it. From there, run the store and load and follow the second one. Finally, it stops just before the load, reflects all past store operations that reached IQ in chronological order, and then resumes by executing load.

The deadlock is then avoided because all processors must reach somewhere and resume [oldest time] somewhere. Conversely, in the case of a logic process in which R / W operates synchronously, no deadlock occurs. Thus, it is possible to simulate without deadlock while maintaining the consistency of the read light.

Fig. 22 shows an example of allocation to the core of the host calculator of the ISS, the peripheral emulator, the plant simulator, and the three scheduler functions of the present invention. The simulation can be performed at high speed by emulating the internal peripheral scheduler and the ISS, which are frequently communicated with the processor, on the same core 2204.

The internal peripheral scheduler refers to the ECU's memory map specification and divides the load / store instructions from the ISS into internal peripherals (SystemC in the core), mutual peripherals, and external peripherals.

In addition, the notation in FIG. Is as follows.

<ISS>

int: interrupt

rs: resume

a: advance

l: load

s: store

c: complete

<SystemC>

r: read

w: write

ru: register update

int: interrupt

pu: port update

<plant>

i: input

c: complete

o: output

<Communication channel>

r: read

w: write

ru: register update

int: interrupt

Next, using FIG. 23, it will be explained that the mutual peripheral scheduler can emulate conservatively (without rolling back) the operation in which the CAN device performs an interrupt notification to the processor after a failure of coordination. FIG. 23 shows an example in which two processors 1 and 2 perform a CAN frame transmission request for a CAN device. The frame requested by the processor 1 has a higher priority than the frame requested by the processor 2. Processor 2 instructs the CAN device to perform interruption of the transmission wait state if an adjustment fails, giving an interruption notification (abort set). In addition, the vertical arrow in the figure indicates the progress of the guest time.

In the example of FIG. 23, after two processors perform an interrupt set and a transmit set on a CAN device (mutual peripheral), an emulator (described in SystemC or the like) of the CAN device starts an adjustment process. The event of coordination start has been added to the TQ by the emulator of the CAN device, and by the processing of the mutual peripheral scheduler, all processors synchronize the guest time at this time (coordination start). In this example, the interrupt set, the two transmission sets, and the adjustments respectively correspond to the CAN interrupt arriving at IQ, the two CAN transmissions arriving at IQ, and the adjustment event added to TQ in FIG. 15. In Fig. 23, the processing of the mutual peripheral scheduler that synchronizes the processor's time is the sending of a null message and the reception of a progress message at the head of the TQ time, and are the same as the processing described with reference to Fig. 15.

In addition, the example of FIG. 23 shows that when adjustment is started, the CAN device emulator adds the event of failure notification time to TQ. When the mutual peripheral scheduler next notifies the processor of a preceding run, the time stamp of the null message sent out is not ΔT _c , but the time of the failure notification added here. For this reason, the processor 2 does not miss the time of failure notification (overhead requesting rollback).

Next, using FIG. 24, the mutual peripheral scheduler can emulate conservatively (without rolling back) the operation when a processor requesting transmission of a high priority CAN frame resets the CAN device. would. This makes it possible for the emulator of the CAN device to check for the presence of a reset before notifying the failure. The operation shown in FIG. 24 is the same as that of FIG. 23 until the start of adjustment.

The example of FIG. 24 shows that in the guest time, processor 1, which made a high priority CAN frame request, resets the CAN device from the start of the adjustment until the adjustment is completed (the victory and the defeat of the frame are confirmed). have. At the beginning of the adjustment, as described in the example of FIG. 23, an event for interrupt notification for processor 2 is added to the TQ by the emulator of the CAN device.

In the example of FIG. 24, in the processing of the event for the interrupt notification added here, the emulator of the CAN device checks whether there is a reset notification before performing the interrupt notification, and determines whether or not to perform the interrupt notification. It is shown.

In this decision process, the CAN device emulator recalculates which CAN frame wins the adjustment if there is a reset notification. As a result of the recalculation, if a frame that is expected to fail at the start of the adjustment is successful in the adjustment, no interruption occurs, so the processor is not notified of the interruption. The example of FIG. 24 shows that the CAN frame (which is expected to fail at the start of adjustment) that the processor 2 makes a transmission request succeeds in the adjustment of the result of recalculation, so that the scheduled interruption notification is not performed.

As a result of the recalculation, if a frame that was supposed to fail at the start of adjustment fails again in adjustment, an interruption occurs, so that the processor is notified of the interruption as scheduled. In the above determination process, if there is no reset notification, the success or failure of the CAN frame does not change from the start of adjustment. For this reason, even when there is no reset notification, the processor is notified of the interruption scheduled at the start of the adjustment.

In this way, the CAN device emulator checks for the presence of a reset before notifying a failure, and the processor accidentally receives a suspension notification (overhead requesting a rollback) even if the interruption did not occur. There is no

Next, another embodiment for implementing the present invention will be described with reference to FIG. 25. In Fig. 25, the processor emulators 2502a, ..., 2502m, 2504a, ..., 2504n are substantially the same in function as the processor emulators 202a, ..., 202z shown in Fig. 2.

The peripheral emulators 2506a, ..., 2506m, 2508a, ..., 2508n are also substantially the same in functional terms as the peripheral emulators 204a, ..., 204z shown in FIG.

25 differs from the configuration in FIG. 2 in that the plant simulator is divided into an active plant simulator 2510a, ..., 2510m, and a passive plant simulator 2512a, ..., 2512n. Because. Here, the active plant simulator is a plant simulator having a function of autonomously determining the timing of the state change and the like, like the engine simulator. For example, the engine is a plant that informs the crank angle by a pulse of 15 degrees, but the timing cannot be determined on the controller ECU side.

On the other hand, a passive plant simulator is a plant simulator in which timing can be determined by a controller, for example, a plant that monitors (samples) the voltage of a battery at a specified timing. In addition to that, a sensor-based plant, such as a temperature sensor, a pressure sensor, a rotational speed sensor, corresponds to a passive plant. Brake and suspension are also classified as passive plants when sensing the state by sampling.

In response to the classification of the active plant simulator and the passive plant simulator, the external peripheral scheduler also includes an external peripheral scheduler 2514a that schedules the peripheral emulator connected to the active plant simulator, and the passive plant simulator. An external peripheral scheduler 2514b is installed that schedules the connected peripheral emulator. For a peripheral emulator connected to an active plant simulator, the corresponding processor emulator has a two-way operation of notifying signal updates and receiving a state change, but for a peripheral emulator connected to a passive plant simulator. The corresponding processor emulator, in principle, only notifies you of signal updates and sampling notices.

Since the classification of the active plant simulator and the passive plant simulator basically do not affect the communication between the processor emulators, the operation of the mutual peripheral scheduler 2516 is substantially equivalent to the mutual peripheral scheduler of FIG. Same as 210, and CAN emulator 2518 is also substantially the same as CAN emulator 212 of FIG. 2.

By the way, the external peripheral scheduler 2514a for the active plant simulator is substantially the same in function as the external peripheral scheduler 208 of FIG. 2, but the external peripheral scheduler 2514b for the passive plant simulator. No processing is needed to calculate the time span preceding the plant for the processor.

Therefore, the operation of the external peripheral scheduler 2514b will be described with reference to the flowchart of FIG. 26. The initial value here is that all IQs are empty, all OQs are empty, TQ is empty, and PV (port value) is the initial value in the ECU specification, T: = 0. The external peripheral scheduler for the passive plant simulator simply needs to repeat the process of catching up with the time whenever the time of the preceding processor is notified.

In step 2602, external peripheral scheduler 2514b performs a wait for an update of the IQ, and in step 2604 it determines if all of the IQs are filled, otherwise returns to step 2602 and returns IQ Continue to wait for update.

Thus, at step 2604, if external peripheral scheduler 2514b determines that all IQs are filled, then at step 2606, the time closest to all IQs is referred to as T ₀ .

In step 2608, external peripheral scheduler 2514b determines if there is a task e such that T _e = T ₀ , i.e., T _e = T ₀ in IQ. If yes, external peripheral scheduler 2514b pops event e at step 2610 and, at step 2612, performs an update of the TQ.

Following step 2612, return to step 2608, where external peripheral scheduler 2514b determines that there is no task e in IQ where T _e = T ₀ , and in step 2614, T: = T ₀ is set.

Next, the process proceeds to step 2616, where the external peripheral scheduler 2514b executes the plant to T. At this time, since the plant is a passive plant, the external peripheral scheduler 2514b does not receive notification of the change of state.

The external peripheral scheduler 2514b then executes the TQ entry T at step 2618 and returns to step 2064.

So far, the case where CAN is an automotive LAN protocol handled by a mutual peripheral scheduler has been described. The simulation system of the present invention is not limited to CAN but can be applied to any automotive LAN protocol such as LIN and Flex Ray. Do.

In the above, specific embodiments of the present invention have been described with reference to a plurality of simulation systems for automobiles, but the present invention is not limited to these specific embodiments, and general electromechanical control such as a simulation system for airplanes and the like. It will be appreciated by those skilled in the art that it is applicable to simulation systems of a series of systems.

In addition, the present invention is not limited to the architecture and platform of a specific computer, and can be applied to any platform that can realize multitasking.

102 host bus, 104a... ... 104n CPU, 106 Main Memory, 116 Hard Disk Drive, 202 2502 2504 Processor Emulator, 204 2506 2508 Peripheral Emulator, 206 2510 2512 Plant Simulator, 208 2514a 2514b External Peripheral Scheduler, 210 2516 Peripheral scheduler, 212 2518 CAN emulator

Claims (21)

In a simulation system that performs a simulation by processing of a computer,
A plurality of processor emulators running on the computer,
A plurality of plant simulators running on the computer,
Running on the computer, up to the response delay time of the processor emulator, running the plant simulator up front, and notifying via a peripheral emulator to actually run the processor emulator up to the time the plant simulator is stopped. With an external Peripheral scheduler,
A mutual peripheral scheduler running on the computer and notifying the processor emulator to run ahead by a communication delay time between the processor emulators,
The processor emulator can proceed conservatively until the time of notification,
Simulation system. The computer system according to claim 1, wherein the computer is a multitasking system, and the plurality of processor emulators, the plurality of plant simulators, the external peripheral scheduler, and the mutual peripheral scheduler are separate threads or Run as a process,
Simulation system. The multiprocessor system of claim 2, wherein the computer is a multicore or multiprocessor system, and the plurality of processor emulators, the plurality of plant simulators, the external peripheral scheduler, and the mutual peripheral scheduler are the multiprocessor systems. A simulation system, assigned to different processors or cores of an individual and executed as individual threads or processes. The system of claim 3, wherein the plant simulator and the peripheral emulator in communication with the plant simulator are assigned to the same core or processor.
Simulation system. The system of claim 1, wherein the plurality of plant simulators has an active plant simulator that voluntarily determines a state, a passive plant simulator that determines timing at the processor emulator side, and the external peripheral scheduler includes: the active plant simulator; Having an external peripheral scheduler for the active plant to communicate with and an external peripheral scheduler for the passive plant to communicate with the passive plant simulator
Simulation system. The apparatus of claim 1, further comprising a CAN emulator, wherein the CAN emulator is scheduled by a mutual peripheral scheduler.
Simulation system. 2. The processor emulator of claim 1, wherein each of the processor emulators cooperates with an internal Peripheral scheduler having a queue and, by the time of the write event of the queue, deadlocks of shared memory access by a plurality of processor emulators. Evasive
Simulation system. In the simulation method of performing a simulation by processing of a computer,
Running on the computer a plurality of processor emulators,
Running a plurality of plant simulators on said computer;
On the computer, an external peripheral that pre-executes the plant simulator up to the response delay time of the processor emulator and actually informs the processor emulator pre-execute the processor emulator up to the time the plant simulator is stopped. Running a scheduler,
Executing a mutual peripheral scheduler on the computer, notifying the processor emulator to run ahead by a communication delay time between the processor emulators,
The processor emulator conservatively proceeds until the time of notification,
Simulation method. The computer system of claim 8, wherein the computer is a multitasking system, and the plurality of processor emulators, the plurality of plant simulators, the external peripheral scheduler, and the mutual peripheral scheduler are executed as individual threads or processes. felled
Simulation method. The multiprocessor or multiprocessor system of claim 9, wherein the computer is a multicore or multiprocessor system, and the plurality of processor emulators, the plurality of plant simulators, the external peripheral scheduler, and the mutual peripheral scheduler are the multiprocessor systems. Are individually allocated to different processors or cores of the processor and run as separate threads or processes,
Simulation method. The system of claim 10, wherein the plant simulator and the peripheral emulator in communication with the plant simulator are assigned to the same core or processor.
Simulation method. The system of claim 8, wherein the plurality of plant simulators have an active plant simulator that voluntarily determines a state, a passive plant simulator that determines timing at the processor emulator side, and the external peripheral scheduler includes: the active plant simulator; Having an external peripheral scheduler for the active plant to communicate with and an external peripheral scheduler for the passive plant to communicate with the passive plant simulator
Simulation method. 10. The method of claim 8, further comprising executing a CAN emulator, wherein the CAN emulator is scheduled by a mutual peripheral scheduler.
Simulation method. The processor of claim 8, wherein each of the processor emulators cooperates with an internal peripheral scheduler having a queue and avoids deadlocks of shared memory access by a plurality of the processor emulators by the time of the write event of the queue.
Simulation method. In a simulation program for performing simulation by computer processing,
On the computer,
Running a plurality of processor emulators,
Running a plurality of plant simulators,
To run an external peripheral scheduler, up to the response delay time of the processor emulator, to run the plant simulator up front and actually notify the processor emulator to run the processor emulator up to the time that the plant simulator is stopped. Steps,
Executing a mutual peripheral scheduler, which notifies the processor emulator to run ahead, by a communication delay time between the processor emulators,
The processor emulator conservatively proceeds until the time of notification,
Simulation program. The computer system of claim 15, wherein the computer is a multitasking system, wherein the plurality of processor emulators, the plurality of plant simulators, the external peripheral scheduler, and the mutual peripheral scheduler are executed as individual threads or processes. felled
Simulation program. The multiprocessor system of claim 16, wherein the computer is a multicore or multiprocessor system, and wherein the plurality of processor emulators, the plurality of plant simulators, the external peripheral scheduler, and the mutual peripheral scheduler are the multiprocessor systems. Are allocated to different processors or cores in the system and run as separate threads or processes
Simulation program. The system of claim 17, wherein the plant simulator and the peripheral emulator in communication with the plant simulator are assigned to the same core or processor.
Simulation program. The system of claim 15, wherein the plurality of plant simulators have an active plant simulator that voluntarily determines a state, a passive plant simulator that determines timing at the processor emulator side, and the external peripheral scheduler includes: the active plant simulator; Having an external peripheral scheduler for the active plant to communicate with and an external peripheral scheduler for the passive plant to communicate with the passive plant simulator
Simulation program. 16. The method of claim 15, further comprising executing a CAN emulator, wherein the CAN emulator is scheduled by a mutual peripheral scheduler.
Simulation program. The processor of claim 15, wherein the processor emulator cooperates with an internal peripheral scheduler having a queue, respectively, and avoids deadlock of shared memory access by a plurality of the processor emulators by the time of the write event of the queue.
Simulation program.

Images