JP5460010B2 - Simulation method, system and program - Google Patents

Description

  The present invention relates to simulation of an electronic control unit (ECU) and an engine used in an automobile or the like, and more particularly to software-based simulation.

  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 the 1970s, there has been a need to efficiently control the engine in preparation for air pollution, oil crisis, and the like, and thus 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, in automobiles such as control systems such as engines and transmissions, Anti-lock Breaking System (ABS), Electronic Stability Control (ESC), power steering as well as wiper control and security monitoring system, 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.

  Electronic control is performed by arranging a plurality of ECUs. The ECUs are connected to each other via an in-vehicle network, for example, a controller area network (CAN). In addition, an engine, a transmission, or the like, which is a control target, is directly wired from each ECU and connected.

  The ECU is a small computer and operates in response to an interrupt from a sensor input or the like. On the other hand, an engine or the like continuously performs a mechanical operation. That is, a computer-based digital system and a mechanical-system physical system perform a cooperative operation in parallel in a single system called an automobile. Naturally, the software that supports this is becoming increasingly complex, and it is urgent to implement a mechanism that not only verifies the operation of the ECU alone, but also verifies the plurality of ECUs.

  Here, the sensor that inputs a signal to the ECU includes a temperature sensor that measures the temperature of the engine, a pressure sensor that estimates the pressure sucked into the engine, and a throttle position sensor that measures the amount of depression of the access pedal Steering angle sensor, vehicle height sensor, rotational speed sensor, knock sensor, acceleration sensor, flow sensor, oxygen sensor, lean air-fuel ratio sensor, and the like.

  On the other hand, the actuator driven by the output signal of the ECU includes an electromagnetic solenoid and a motor. Solenoids are used, for example, for engine injectors, transmission shift control, brake valve control, and door locks.

  The motor is mainly used as a servo mechanism for an engine starter, engine fuel control, brake hydraulic pump, rudder angle control, steering, wiper, power window, seat belt, airbag, and the like.

  As a technique conventionally performed for such a test, there is HILS (Hardware In the Loop Simulation). In particular, the environment for testing the ECU of the entire vehicle is called full vehicle HILS. In the full vehicle HILS, a real ECU is connected to a dedicated hardware device that emulates an engine, a transmission mechanism, and the like in a laboratory, and a test is performed according to a predetermined scenario. The output from the ECU is input to a monitoring computer and further displayed on a display, and a tester checks whether there is an abnormal operation while looking at the display.

  However, HILS requires a dedicated hardware device and has to be physically wired between it and a real ECU, so preparation is difficult. In addition, the test after replacing with another ECU also takes time since it must be physically reconnected. Furthermore, since the test is performed using a real ECU, real time is required for the test. Therefore, testing many scenarios takes a huge amount of time. In addition, a hardware device for HILS emulation is generally very expensive.

  Therefore, in recent years, there is a method of configuring with software without using an expensive emulation hardware device. This method is called SILS (Software In the Loop Simulation), and is a technique in which a microcomputer, an input / output circuit, a control scenario, etc. mounted on an ECU are all configured by a software simulator. According to this, the test can be executed without the ECU hardware.

  Here, an example in which an ECU emulator and a physical device simulator, particularly an engine simulator, cooperate will be described. Hereinafter, for the sake of convenience, the operation between the actual ECU and the engine will be described instead of the ECU emulator and the engine simulator. First, at a timing 30 degrees before the piston reaches top dead center in accordance with the rotation of the crankshaft, the engine interrupts the ECU. The ECU that has received the interrupt calculates the fuel injection timing and issues an injection instruction at that time. The engine receiving it injects fuel and then calculates the operation of the crank that rotates by inertia. When the piston reaches 30 degrees before the top dead center again, the engine causes an interruption to the ECU and notifies the ECU. Then, the ECU calculates the ignition timing and issues an instruction to the engine at that time. In response, the engine explodes the fuel in the cylinder and begins calculating a new rotation action. Such an operation is repeated.

  Thus, the operation in which the engine and the ECU move alternately is regarded as a critical path. Therefore, when simulating discrete events of an automobile in parallel, due to the presence of such a critical path, the parallelism cannot be sufficiently exhibited from the viewpoint of calculation performance. Therefore, even in the full vehicle HILS using a computer of a multiprocessor system, even if individual CPUs are assigned to a plurality of ECU emulators, in the worst case, a plurality of ECU emulators and engine emulators can be obtained with one CPU. May only be of a performance that can be calculated serially.

  The simplest method for operating a plurality of logical processes in parallel without contradiction is to operate each logical process in accordance with the entire command. However, in this method, since it is necessary to perform all synchronous processing even at the time when an event such as an interrupt does not occur, the processing load is large and the processing is slow.

  In the simulation of discrete events in which a plurality of logical processes are asynchronously operated in parallel, communication between processes is performed by transmitting and receiving time-stamped events as messages. At this time, the time stamp records a common time in the entire simulation system. If such a time is called a simulation clock, the timing at which the simulation clock is processed is independent in each logical process and does not necessarily have to coincide. However, when the logical processes cooperate to perform processing, it is necessary to always perform them in the order of time stamps. As long as the process proceeds in this way, the process can proceed in the same way as when the entire process is processed serially.

  One asynchronous process is conservative synchronization. This method always handles events with the oldest time stamp.

To explain an example of conservative synchronization, assume that a logical process has queues from two upstream processes, and an event having a time t ₁ and an event having a time t ₂ have arrived at one of the queues. Assume that time t ₁ is older than time t ₂ . Also assume that nothing has arrived in the other queue. Then, the logical process is likely to be processed in order from the event with time t ₁ , but an event with a time older than time t ₁ may reach the other queue from upstream, That is, since it is not guaranteed that the time t ₁ is the oldest, the process cannot proceed. In particular, in a configuration where there is a transmission / reception loop between logical processes, such a configuration may cause a deadlock.

  In order to avoid such a situation, a method using a null message is known. In this method, an upstream message with that time is sent to the downstream logical process to indicate that the upstream logical process will not generate an event until a certain time. Such a time is called the lower bound on the timestamp (LBTS). A downstream logical process that receives such an empty message compares the time stamp of the event that has arrived with its LBTS, and can process an event with an older time stamp as definite.

A method called optimistic synchronization has been devised as a method not using empty messages. In this method, a logical process has queues from two upstream processes, an event with time t ₁ and an event with time t ₂ have arrived, and time t ₁ is older than time t ₂ And when nothing has arrived in the other queue, the processing is performed assuming that the event having time t ₁ is the oldest for the time being. After that, when an event with a time older than time t ₁ arrives in the other queue, a series of processing starting from the event at the previous time t ₁ is canceled in order by sending a retroactive message (reverse message). Then, a new event having a time older than time t ₁ is processed. In this method, the event output from the logical process is not necessarily temporarily in accordance with the time stamp, but rollback ensures that the event is finally in accordance with the time stamp.

  In this way, events can be sent out in the correct order while avoiding deadlocks. However, with such a method, serialization of processes cannot be avoided, and thus the process cannot be accelerated.

  Japanese Patent Laid-Open No. 6-161987 is intended to simulate ECU hardware and enable real machine evaluation by software. By switching matrix switches, a desired function can be obtained. Disclose to simulate hardware.

Japanese Patent Application Laid-Open No. 11-14507 discloses a vehicle simulation apparatus that includes an engine control simulation device (ECU) and a vehicle control simulation device. To do. The ECU calculates the control parameter of the engine model and transmits the calculation result to the vehicle control simulation device. The vehicle control simulation device calculates a state quantity of each part of the vehicle model using control parameters sent from the ECU, and returns the calculation result to the ECU. The vehicle model includes a driver model, an intake system model, a fuel system model, a combustion system model, an engine temperature estimation model, a drive system model, a catalyst model, an A / F sensor model, and a rear O ₂ sensor model. The driver model has vehicle speed pattern input means for inputting a change pattern of the target vehicle speed.

  However, these documents do not mention a technique for synchronizing logical processes. Accordingly, the inventors of the present application presented a technique for speculatively emulating each ECU emulator in the Japanese Patent Application No. 2008-158995 filed on June 18, 2008. That is, according to the invention, in order to execute each logical process in parallel as much as possible without creating a critical path, even if an input event does not arrive in each logical process such as an ECU emulator or each physical device simulator. The process proceeds by predicting the input. By such speculative execution, processing parallelism is improved by performing processing in advance without waiting for the output of another logical process. So, if the actual input received late and the input when speculative execution was predicted do not match, the speculation execution failed and the status is returned to the previous time, The process is re-executed based on the actual input.

JP-A-6-161987 Japanese Patent Laid-Open No. 11-14507 Japanese Patent Application No. 2008-158995

  According to the technique described in the specification of Japanese Patent Application No. 2008-158995, it has become possible to perform simulation speculatively at high speed without being constrained by the seriality of operations in the full vehicle SILS.

  However, if the speculation still failed, it was necessary to roll back to the time of the new incoming event.

  Accordingly, it is an object of the present invention to provide a simulation technique that does not need to roll back to a new incoming event even if speculation fails.

  Another object of the present invention is to provide a simulation technique capable of avoiding error accumulation when not rolling back until a new incoming event.

  For implementing the present invention, a multi-CPU workstation is preferably provided, although it is not essential. In addition, a software emulator for each ECU is prepared. In general, an ECU software emulator is available from the ECU manufacturer.

  Each ECU's software emulator preferably interfaces with a predetermined layer of the workstation's operating system to run on a multi-CPU workstation. Preferably, each of the multi-CPUs is assigned to a software emulator of each ECU, so that each ECU emulator can operate independently by each CPU. When the number of CPUs is smaller than the number of ECUs, a plurality of ECU emulators are assigned to one CPU. In any case, the operating system allocates one process for each ECU emulator, so that each ECU emulator can perform emulation so that it operates with a different clock. That is, each ECU emulator may be a heterogeneous ECU.

  A part of the memory of the workstation is allocated to each ECU emulator as a private memory for internal processing. Furthermore, the ECU emulator can also access a portion allocated as a shared memory of the workstation, and through this shared memory, each ECU emulator exchanges data, synchronizes, and communicates with each other. It is possible. Alternatively, the ECU emulator may be connected by a CAN (controller area network) emulator.

  Physical device simulators such as engine simulators and transmission simulators that receive inputs from these ECU emulators are prepared, and are also connected to the ECU emulators using a shared memory of a workstation or a CAN (controller area network) emulator.

  Here, if the ECU emulator and the physical device simulator are collectively referred to as a logical process, according to the present invention, from the values of a plurality of events that have entered the logical process, A prediction module for predicting a plurality of values is provided. The prediction module predicts the values of multiple future events from the values of multiple past events, preferably using linear prediction techniques, until the next event arrives. Speculative speculation based on the value.

  Next, in response to the arrival of a new event, the prediction module re-predicts the values of a plurality of future events by combining the new event and the past incoming event. Then, an error occurs between a plurality of values of the event newly predicted this time and a plurality of values of the event predicted last time. Therefore, the prediction module calculates a cumulative sum (cumulative error) of errors between a plurality of newly predicted event values and a previously predicted plurality of event values, and the cumulative sum falls within a predetermined threshold. Calculate the number of events (number of steps).

  If the number of such steps is m and the step corresponding to the current time is n, the prediction module preferably rolls back the preceding speculation to (n + m), and the accumulated error is preferably stepped. Disperse and adjust until the time corresponding to n + 2m. More specifically, for example, subtracting from a plurality of values of the newly predicted event this time, the sum of the subtracted differences is from step (n + m) to step (n + 2m), for example, It should be equal to the cumulative error.

  The prediction module instructs the local scheduler of the logical process to newly pre-specify from step (n + m) with the multiple values of the predicted event thus updated.

  According to the present invention, in a simulation system such as a full vehicle SILS, a prediction module that re-predicts a sequence of events in response to a new incoming event is provided in the logical process, and according to the error of the re-prediction Since it is possible to roll back halfway without returning to the time of the incoming event, the speed of the simulation system can be improved. In addition, since the re-predicted accumulated error is eliminated during the subsequent preceding speculation, a highly accurate simulation system in which no error accumulation occurs can be obtained.

  The configuration and processing of an embodiment of the present invention will be described below 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.

  Before describing the configuration for realizing the present invention, the ECU will be described as a premise thereof. 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.

  For convenience of explanation, the present invention will be described below in connection with an ECU of an automobile. However, the present invention is not limited thereto, and it should be understood that the present invention can be applied to general mechatronic mechanisms having other ECUs such as an aircraft and a robot. .

  The ECU detects the surroundings, the environmental state, the state of the driving mechanism such as the engine, and the content of the instruction operation by a human with a sensor and inputs it as a signal. Specifically, signals from a water temperature sensor, intake air temperature sensor, boost pressure sensor, pump angle sensor, crank angle sensor, vehicle speed sensor, accelerator position sensor, A / T shift position, starter switch, air conditioner ECU, etc. is there.

  The ECU inputs these signals and outputs signals for driving electromagnetic spill valves, fuel cut solenoids, timing control valves, intake throttle VSV, glow plug relays, tachometers, air conditioner relays, etc. To do.

  Although it is not impossible for one ECU to output drive signals for controlling a plurality of different mechanisms, for example, an engine and an air conditioner that have different responsiveness and strict control. It is not rational to control with a single ECU. Therefore, in general, a plurality of ECUs are provided in an automobile.

  FIG. 1 is a diagram illustrating an example of a feedback closed loop system that is a typical control of the ECU. That is, in FIG. 1, a target signal is input to a controller 102 that is an ECU, and the ECU internally processes the target signal to output a drive signal, which is a model to be controlled, such as a plant such as an engine. The output of the plant 104 is fed back to the input of the controller 102 via the sensor 106.

  The target signal given here is, for example, throttle opening, idle control, brake force, shift, starter ON / OFF, battery voltage, injection energization time, number of times of injection energization, deposit, dwell angle, advance value, The parameters are an intake completion flag, ignition completion flag, atmospheric pressure, vehicle weight, rolling resistance coefficient, road gradient, adhesion coefficient, intake air temperature, and the like.

Also, feedback of sensor signals includes throttle opening, intake pressure, intake air amount, shift, engine speed, vehicle speed, exhaust temperature, O ₂ , cooling water temperature, air-fuel ratio, knock, ignition abnormality, etc. .

  An object controlled by the ECU is a mechanical system solved by Newton's dynamic equation, an electric drive circuit solved by a response equation of an electric circuit, or a combination thereof. These are basically differential equations and can be described by being converted into a response function by Laplace transform according to control engineering.

  FIG. 2 is an example of such a response function description. 2 corresponds to the controller 102 in FIG. 1, the portion surrounded by the broken line 204 corresponds to the control target model 104 in FIG. 1, and the sensor 106 corresponds to the block 206. Note that FIG. 2 is an example of expression by a response function, and it should be understood that the present invention is not particularly limited.

  Now, for example, it is assumed that an object controlled by the ECU is a mechanical system that is solved by Newton's dynamic equation. Then, the control output of the ECU at a certain time has internal state variables such as the position and speed of the movable part of the mechanical system, and is not determined only by the input at that time. This also applies to the electric circuit, and there are still internal state variables such as the amount of charge remaining in the capacitor of the electric circuit and the magnetic force due to the inductance of the coil.

  Accordingly, as shown in FIG. 3, the ECU outputs a value y that takes into account the internal state x with respect to the input u.

  Now, for the purpose of the test such as SILS described above, an auto parts manufacturer provides a software emulator for ECU of equipment provided by the auto part manufacturer. That is, the functions shown in FIG. 2 are realized purely in software by an executable program obtained by assembling or compiling a code written in a language such as assembler or C.

  In this embodiment of the present invention, the internal state of the software emulator of the ECU is taken out and used. Depending on the software emulator, there are a case where the internal state can be taken out and a case where the internal state cannot be taken out as it is.

  Therefore, when the internal state of the software emulator of the ECU cannot be taken out as it is, the following processing is performed by the source code analysis tool.

  If the source code of the ECU software emulator is available, it is used as it is, and if there is only an executable binary file, it is disassembled or decompiled with a predetermined tool. Then, a technique called data flow analysis is applied to the source code of the ECU software emulator to divide the source code into basic blocks. A basic block is a portion of the source code that is divided where a plurality of controls merge or where the control branches into a plurality. When such a basic block is used as a node and connected by a link of the control flow of the branch, a directed graph structure is obtained. This is also called a control flow graph. The control flow graph has a start point node and an end point node, and all nodes that can be executed by the program have valid edges from the start point node. In the basic block, all control end nodes including exit () and return statements have a valid edge to the end node.

  Next, Use / Def analysis is performed on all possible paths of the start and end nodes of the control flow graph. Here, “Use” means a case where a variable is used to store a value in another variable. Typically, it is the right side of an assignment expression. Def means that a value is stored in a certain variable. Typically, it is the left side of an assignment expression.

  In this case, for each path, it is checked whether there is a variable that is used before Def or without Def, that is, there is an undefined reference variable. If there is an undefined reference variable, the variable name is temporarily Saved.

  Thus, a wrapper code is generated using a variable name stored after all paths have been scanned, as will be described later.

  By the way, execution flow scanning and use / def analysis can be executed more efficiently by using a technique called data flow analysis.

  The first step is the calculation of the def list in each basic block. Specifically, a list of variables used in the entire program is expressed by 1 bit, and a variable defined for each basic block is expressed by a bit vector where 0 is not set.

  The second step is the calculation of the reachable def list for the entire program. That is, in each basic block, when there are a plurality of inputs, the logical product (AND) is performed and then input to itself. The output from itself takes the logical sum (OR) of the input and the def list defined by itself, and passes it to the subsequent basic block. As the order of execution, the depth priority order on the control flow graph is efficient.

  The third step is to obtain a reachable def list closure by a closure analysis algorithm. Then, the second step is repeated until the output def lists of all basic blocks are not changed. Here, the closure is a value associated with the environment.

  The fourth step is the discovery of the use of undefined variables. That is, a variable in which the input def list of each basic block is expressed as 0 is used as a use.

  For a more detailed explanation of data flow analysis, see Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman, "Compilers Principles, Technologies, and Tools", Addison-Wesley Publishing Company, 1986, p. 608-633. Please refer.

  For example, it is assumed that the original ECU simulation source code is represented by a function Func (x, y, z). Also assume that a and b are registered as undefined reference variables.

Then, for example, a function _Func (x, y, z, _a, _b) is prepared,
_Func (x, y, z, _a, _b)
{
a = _a;
b = _b;
Func (x, y, z);
_a = a;
_b = b;
return;
}

_Func (x, y, z, _a, _b)
{
a = _a;
b = _b;
Is called the input wrapper code,
_a = a;
_b = b;
return;
}
This part is called an output wrapper code.

  Note that Func (x, y, z); may be inlined, not a function call. By calling the function _Func (x, y, z, _a, _b) with appropriate values in _a and _b, the internal state of Func (x, y, z) can be set. In addition, as a result of calling _Func (x, y, z, _a, _b), the value of the internal state after processing is set in _a, _b, so save those values separately if necessary Etc. are available. The source code with wrapper code in this way is compiled or assembled to produce an executable program.

  Also, depending on the specifications of a specific processing language such as C ++, the reference operator & may be used as _Func (x, y, z, & _ a, & _ b) instead of _Func (x, y, z, _a, _b). Sometimes it is necessary to give it as an argument to the function.

  FIG. 4 schematically shows the software emulator of the ECU after the internal state or internal variable can be extracted in this way. As shown there, the software emulator 402 of the ECU is conveniently separated into a portion indicating the internal logic f and an internal state or state variable x.

  Then, the output y = f (t, x, u,...) Can be described using the internal logic f. Where t is time. In addition, since the code related to the state variable x is separated, the state variable x and preferably the input u are also stored in the hard disk drive as the state repository 404 at an arbitrary time point, that is, typically at the timing when output is performed. Can be exported.

  This is not the only effect of separating the code related to the state variable x. That is, as indicated by an arrow 406, the state variable x can be set in the software emulator 402 at an arbitrary time. Thereby, by selecting and setting the input and the state variable x from the state repository 404, the ECU software emulator 402 is returned to the state at an arbitrary time when the state variable x is written in the state repository 404. From there, you can redo the calculation.

  The processing as described above can be applied to all logical processes including not only the ECU but also the physical device simulator. Therefore, in the following, the logical process is treated as being able to retrieve internal state variables and set internal state variables to a desired value.

  Next, computer hardware used to implement the present invention will be described with reference to FIG. In FIG. 5, a plurality of CPU0 504a, CPU1 504b, CPU2 504c, and CPU3 504d are connected to the host bus 502. Further connected to the host bus 502 is a main memory 506 for arithmetic processing of the CPU0 504a, CPU1 504b, CPU2 504c, and CPU3 504d.

  On the other hand, a keyboard 510, a mouse 512, a display 514, and a hard disk drive 516 are connected to the I / O bus 508. The I / O bus 508 is connected to the host bus 502 via the I / O bridge 518. The keyboard 510 and the mouse 512 are used by an operator to enter commands or click menus to perform operations. The display 514 is used to display a menu for operating a program according to the present invention, which will be described later, using a GUI as necessary.

  IBM (R) System X is the preferred computer system hardware used for this purpose. At that time, the CPU0 504a, the CPU1 504b, the CPU2 504c, and the CPU3 504d are, for example, Intel® Core 2 DUO, and the operating system is Windows (trademark) Server 2003. The operating system is stored in the hard disk drive 516 and is read from the hard disk drive 516 into the main memory 506 when the computer system is started.

  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 that can run the simulation program of the present invention can be used. 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 logical processes such as an ECU emulator program and a physical device simulator at high speed, a computer system such as IBM (R) System P with an operating system of AIX (trademark) based on POWER (trademark) 6 is used. May be used.

  The hard disk drive 516 further stores a plurality of logical processes such as an ECU emulator and a physical device simulator, and a program for operating the plurality of logical processes in cooperation with each other, and can be activated by a keyboard 510 and a mouse 512. It is.

  Preferably, in order to realize full vehicle SILS, emulator programs of all ECUs used in one automobile are stored in the hard disk drive 516. If the ECU emulator program cannot extract an internal state variable as it is, the state variable can be set and extracted in advance by covering the above-described wrapper code.

  The hard disk drive 516 further includes a scheduler for an ECU emulator program to be described later, a physical device (plant) simulator program such as an engine, a transmission, a steering, and a wiper, and a global for synchronizing inputs of the entire system. A scheduler and a scenario generator program that stores various test scenarios such as climbing slopes, highways, and zigzag roads are also stored.

  Note that the terms “emulator” and “simulator” are used properly here, but the ECU code originally written on the assumption that it runs on another processor is targeted for CPU0 to CPU3, etc. Making it run is called emulation, and the program that does it is called an emulator. On the other hand, a system that virtually calculates the operation of a physical system such as an engine is called a simulator.

  Next, a functional logic block diagram of the simulation system of the present invention will be described with reference to FIG. In FIG. 6, the shared memory 602 may actually be a part of the main memory 506 shown in FIG. In the shared memory 602, ECU emulator programs 604a, 604b,... 604n, a global scheduler 608, and physical device simulator programs 606a,.

  The global scheduler 608 is based on the time stamps of events between the ECU emulator programs 604a, 604b,... 604n and the physical device simulator programs 606a,. Operate to maintain. A more detailed operation of the global scheduler 608 will be described later.

  The ECU emulator programs 604a, 604b,... 604n correspond to the control of different parts of the car, such as the engine, brake, transmission, steering, etc., and each operates with a clock with a different speed. It is assumed that the emulator emulator program that operates also operates at a proportional clock ratio.

As an example, a code for assigning an ECU emulator program to a plurality of CPUs by creating a thread will be described by taking C language as an example.
void * ecu_wrapper (void * parm)
{
...
/ * define state_repository * /
...
LOOP_BEGIN:
...
/ * Perform ECU unit processing * /
LOOP_END:
...
}

Prepare code like the above,
pthread_t thread_id;
pthread_attr_t thread_attr;
pthread_attr_init (&thread_attr);
pthread_create (& thread_id, thread_attr, ecu_wrapper, NULL);
pthread_attr_destroy (&thread_attr);
Then, the operating system creates a thread and assigns it to the emulator program of the ECU. Physically, the thread is assigned to one of CPU0 to CPU3, but it is left to the operating system and is transparent to the emulator program.
Such allocation processing is performed individually for each of the ECU emulator programs 604a, 604b,.

  6, the ECU emulator programs 604a, 604b,... 604n, the physical device simulator programs 606a,... 606m, and the global scheduler 608 use the shared memory 602 for data. However, a CAN (controller area network) emulator may be used instead.

  Although not shown in the figure, a scenario generator storing various test scenarios such as an uphill road, a highway, and a zigzag road is also connected to the configuration of FIG.

  Although the ECU emulator program 604 and the physical device simulator program 606 are collectively referred to as a logical process as described above, the processing of the present invention is applicable to all logical processes. The process will be described as a configuration or process.

  FIG. 7 shows a more detailed logic block diagram within the logic process 700. The logic module 702 is a main body including the original logic of a so-called logic process.

  The local scheduler 704 has a function of returning the logical process 700 to a desired state by writing the internal state variable stored in the rollback table 706 back to the logical module 702. In the rollback table 706, in addition to internal state variables, a history of input event values, time, and output event values is recorded. The local scheduler 704 searches for an entry in the rollback table 706 and issues a rollback instruction to the logic module 702.

  The local scheduler 704 is provided with event inputs from the shared memory 602 via the communication interface module 708. On the other hand, the local scheduler 704 outputs an event input to the communication interface module 708.

  The communication interface module 708 communicates with other logical processes such as the ECU emulator 604 and the physical device simulator 606 and the global scheduler 608 via the shared memory 602. The communication method is a method of writing at a specific memory address and signaling. In addition to such a method via a shared memory, there is a method using a CAN emulator.

  The logic process 700 further includes a prediction module 710. The prediction module 710 records a plurality of past incoming events, predicts a plurality of future events by a method such as linear prediction based on the values of the plurality of recorded events, and the plurality of predicted events Based on this column, a command for instructing the local scheduler 704 to issue the speculative speculative execution of the logic module 702 is issued.

  The prediction module 710 bears the central feature of the present invention and will be described in more detail with reference to FIG.

  As shown in FIG. 8, the prediction module 710 includes a prediction curve update module 802, a rollback calculation module 804, a cumulative error distribution calculation module 806, and a prediction correction module 808. The prediction module 710 further includes an observation value recording area 810 for an incoming event and a previous prediction curve recording area 812.

  The observation value recording area 810 is preferably a predetermined area secured in the main memory 506, but is not limited to this as long as it is a readable and writable area. For example, the hard disk drive 515 It may be an area secured in the predetermined area. In the observed value recording area 810, the actual measured value of the event coming via the local scheduler 704 and the time of the event are sequentially recorded.

  The prediction curve update module 802 uses the measured values of the plurality of events recorded in the recording area 810 and the values of the times, preferably by the linear prediction algorithm, and the values of the plurality of events and the times. Predict.

  The rollback calculation module 804 calculates the number of steps m to be rolled back based on the values of the plurality of events calculated by the module 802. The rollback calculation module 804 also refers to the value from the recording area 812 of the pre-forecast curve described below. The rollback calculation module 804 receives the preceding (speculed) time from the local scheduler 704, while returning to the local scheduler 704 the number of steps to be rolled back.

  The previous prediction curve recording area 812 stores the value of the previous prediction curve as a result of the prediction calculation performed by the prediction curve update module 802 and then corrected by the prediction correction module 808.

  The cumulative error allocation calculation module 806 receives the current prediction curve value received from the prediction curve update module 802, the previous prediction curve value received from the previous prediction curve recording area 812, and the rollback calculation module 804. From the received value of the number of steps m, a correction value to be applied to each step of the current prediction curve is calculated.

  The prediction correction module 808 corrects the value predicted by the prediction curve update module 802 using the value supplied from the module 806, and sends the value to the local scheduler 704. The local scheduler 704 uses the received corrected prediction value for subsequent rollback processing.

  The prediction value corrected by the prediction correction module 808 is recorded in the previous prediction curve recording area 812 for the next use.

  FIG. 9 is a flowchart showing more detailed processing of the prediction module 710. In step 902, the local scheduler 704 waits for a new event (observation value). Therefore, a new event arrives at the local scheduler 704, and the time (number of steps) of the event is n. The local scheduler 704 sends the value to the prediction curve update module 802.

  In step 904, the prediction curve update module 802 calculates a new prediction curve using the value read from the observation value recording area 810 and the value of the new event sent from the local scheduler 704.

ここで、係数w_i ( i = 0,1,2,...,N-1 )を決定するために先ず、ステップ１００２で、下記のベクトルｘと、行列Ｈが計算される。具体的なNの数は、論理プロセスの動作の特性に依存するが、少なくとも3程度が望ましい。

なお、この式は、一般的なMについて書かれており、ここでは、Mは、Nより十分大きな値とする。 This step will be described in more detail with reference to the flowchart of FIG. In this embodiment, predicted values of x˜ ′ [n + 1] are calculated from the past n−1 values in addition to the current value based on the following formula according to the theory of linear prediction.

Here, in order to determine the coefficients w _i (i = 0, 1, 2,..., N−1), first, in step 1002, the following vector x and matrix H are calculated. The specific number of N depends on the operation characteristics of the logical process, but is preferably at least about 3.

This equation is written for general M, where M is a value sufficiently larger than N.

Thus, the coefficient w is calculated from w = (H ^T H) ⁻¹ H ^T x.
Here, w = [w ₀ , w ₁ ,..., W _N−1 ] ^T.
Further, since the routine of FIG. 10 is called every time a new event (observed value) arrives, the coefficient w _i (i = 0,1,2, ..., N-1) is calculated each time. It should also be understood that it is recalculated.

Returning to step 904, when w is obtained in this way, by increasing n in the equation (1),
x ~ '[n + 1], x ~' [n + 2], x ~ '[n + 3], ... and new prediction values can be obtained sequentially.

  Note that the values of x ~ '[n + 1], x ~' [n + 2], x ~ '[n + 3], ..., etc. obtained by linear prediction are generally event values. In addition, since an event may have a plurality of values as parameters, the value of the event may be expressed as a vector. In such a case, the different components of the vector are considered to be independent from each other, and the above linear prediction can be applied to the individual components.

  In addition, time is associated with each event, and linear prediction can be applied to the prediction calculation for that time. As a result, the predicted event as a result also has time, so that the simulation can be executed in advance by assuming that the event has entered at the predicted time.

In step 906, the old predicted value x˜ [i] (i = n + 1, n + 2,...) And the new predicted value x˜ ′ [i] (i = n + 1, n) calculated this time. The difference from +2, ...) is calculated by Only the first equation uses measured values x [n].
e [n] = x ~ [n]-x [n]
e ~ [n + 1] = x ~ [n + 1]-x ~ '[n + 1]
e ~ [n + 2] = x ~ [n + 2]-x ~ '[n + 2]
e ~ [n + 3] = x ~ [n + 3]-x ~ '[n + 3]
.....
These values are held by the cumulative error distribution calculation module 806.

ここで、T_cは、所定の閾値であり、この不等式を満たす最大の整数mが求めるmの値である。T_cが大きいほど、mの値も大きくなる。 In step 908, the rollback calculation module 804 calculates the allowable error range (m) by the following inequality.

Here, T _c is a predetermined threshold value, and is a value of m obtained by the maximum integer m satisfying this inequality. The value of m increases as T _c increases.

  In step 910, n + m is calculated in the rollback calculation module 804 by the value of m calculated in step 908, and the rollback calculation module 804 sends the n + m step to the local scheduler 704. Send a command to instruct you to roll back to the point in time.

Incidentally, at the point of time (step) n in step 902, prior speculation Note that it has progressed to time n _s as _{n <n + 2m <n s} .
Thus, n <since n + m <n + 2m < n s, rolls and back from n _s to the time step n + m, the n _s, which means that returning the above steps m.

In step 912, the predicted correction module 808 uses the newly predicted value.
x ~ '[n + m], x ~' [n + m + 1], x ~ '[n + m + 2], ... are held by the cumulative error allocation calculation module 806 e [ n], e ~ [n + 1], e ~ [n + 2], e ~ [n + 3]... are corrected by the following equation.

x ~ '' [n + m] = x ~ '[n + m]-e ~ [n + m-1]
x ~ '' [n + m + 1] = x ~ '[n + m + 1]-e ~ [n + m-2]
x ~ '' [n + m + 2] = x ~ '[n + m + 2]-e ~ [n + m-3]
....
....
x ~ '' [n + 2m-2] = x ~ '[n + 2m-2]-e ~ [n + 1]
x ~ '' [n + 2m-1] = x ~ '[n + 2m-1]-e [n]
x ~ '' [n + 2m] = x ~ '[n + 2m]

The corrected values x ~ '' [n + m], x ~ '' [n + m + 1], x ~ '' [n + m + 2], ...,
x ~ '' [n + 2m-1], x ~ '' [n + 2m] and subsequent new predictions x ~ '[n + 2m + 1], x ~' [n + 2m + 2],
x ~ '[n + 2m + 3] .. is sent from the prediction correction module 808 to the local scheduler 704, and the local scheduler 704 sequentially executes the logical values with these corrected values from step n + m. The module 702 is controlled to operate.

Corrected values x ~ '' [n + m], x ~ '' [n + m + 1], x ~ '' [n + m + 2], ..., x ~ '' [n + 2m -1],
x ~ '' [n + 2m] and the following new predictions x ~ '[n + 2m + 1], x ~' [n + 2m + 2], x ~ '[n + 2m + 3]
It is also recorded in the recording area 812 of the previous prediction curve.

FIG. 11 is a diagram illustrating a prediction correction scheme according to the present invention. It is assumed that when the event arrives at the local scheduler 704, an event x [n] has been advanced up to n _s ahead.

At this time, the events that have been predicted and calculated from ..., x [n-2], x [n-1] and have already been speculated by the prediction correction module 808 are x ~ [n], x ~ [ n + 1], x ~ [n + 2], ..., x ~ [n _s ], but in response to the arrival of the event x [n], the prediction calculation update module 802
Again, a new prediction calculation is performed based on ..., x [n-2], x [n-1], x [n]. The predicted value of the result is x ~ '[n + 1], x ~' [n + 2] ....

  Then, rolling back to n and re-executing from x ~ '[n] causes the rollback to be too large and decreases the simulation speed.

  Therefore, rollback is reduced by allowing the error to be within a certain threshold. The result is a rollback up to n + m, and it can be seen that m steps ahead of the rollback up to n. This is advantageous for improving the simulation speed.

  However, if the above error remains, the error accumulates. In order to eliminate the error between n + m and n + 2m, the corrected value x˜ '' [n + m ], ..., x ~ '' [n + 2m] are calculated and the speculative execution is executed. As a result, it is not necessary to roll back to n while preventing accumulation of errors, so that the simulation speed can be improved.

  In the above example, the differences e ~ [n + m], ..., e ~ [n + 1], e [n] are applied from time n + m, respectively. If capacity T can be determined, subtract T from n + m to n + m + M-1 with M being the integer part of E divided by T, and at time n + m + M, E-MT is When subtracted, the distribution of errors can be completed in the minimum interval.

  As shown in FIG. 12, the global scheduler 608 has queues Q1 to Qn for each of the logical processes LP # 1 to LP # N. Each of the logical processes is any of ECU emulators # 1 to #n and physical device simulators # 1 to #m shown in FIG.

  In the queues Q1 to Qn, events come from the corresponding logical processes LP # 1 to LP # N as needed, and the incoming events are temporarily stored in the queue. The global scheduler 608 outputs a fixed event and a fixed time based on the events stored in the queues Q1 to Qn.

  FIG. 13 is a flowchart showing the processing of the global scheduler 608 for that purpose. In step 1802, the global scheduler 608 waits for a new event to arrive in any of the queues Q1-Qn (FIG. 12).

  In step 1304, it is determined whether an event has arrived in the empty queue, otherwise processing returns to step 1302.

  If it is determined in step 1304 that an event has arrived in an empty queue, the process goes to step 1306 where it is determined whether all queues Q1-Qn have at least one event. Otherwise, the process returns to step 1802.

  If it is determined in step 1306 that all queues Q1-Qn have at least one event, in step 1308, the oldest event is found in all queues Q1-Qn. This is possible because all events are time stamped.

  In step 1310, the oldest event found is determined as a confirmed event and notified to the logical processes LP # 1 to LP # N.

  In step 1312, the confirmed event is removed from the queue. Then, returning to step 1802, the global scheduler 608 waits for the arrival of the next event.

  Although specific embodiments of the present invention have been described above in connection with a simulation system having a plurality of logic processes for automobiles, the present invention is not limited to such specific embodiments and is intended for airplanes. Those skilled in the art will understand that the present invention can be applied to a simulation system of a general electromechanical control system such as a simulation system.

It is a figure which shows the example of the feedback closed loop system which is typical control of ECU. It is an example of the description by a response function of a feedback closed loop system. It is a figure which shows the time transition of the clock response of ECU software emulator. It is a block diagram of the software emulator of ECU after it became possible to take out an internal variable. FIG. 2 is a block diagram of computer hardware used to implement the present invention. It is a functional logic block diagram of the simulation system of this invention. It is a logic block diagram of a logic process. It is a detailed logic block diagram of a prediction module. It is a flowchart of a process of a prediction module. It is a flowchart of a linear prediction process. It is a figure which shows the relationship between the estimated speculation step and the correct | amended speculation step. It is a figure which shows the queue of a global scheduler. It is a flowchart of a process of a global scheduler.

Explanation of symbols

604, 606 ... logic process 810 ... first recording means 808 ... means for correcting 812 ... second recording means

Claims (13)

A simulation system having a plurality of logical processes controlled by a computer and operated by sending and receiving events having time and value,
The logical process is
First recording means for sequentially recording the value of the incoming event;
Means for calculating to predict a plurality of events for pre-speculative execution based on the recorded values of the plurality of events including the incoming event in response to the arrival of the event;
Comparing a plurality of events predicted in response to the arrival of the event with values related to previous events predicted in response to the arrival of the previous event, taking an error and accumulating Means for determining a first time point at which the error is within a predetermined threshold;
Means for rolling back the logical process to the first time point;
Correction means for correcting the predicted values of the plurality of events in a distributed manner so that the accumulated error is eliminated before reaching the second time point after the first time point; ,
Have a second recording means for recording the value of the corrected event,
The value related to the plurality of predicted previous events is the value of the previous corrected event recorded in the second recording means.
Simulation system.   The simulation system of claim 1, wherein the event prediction is performed by linear prediction.   The simulation system according to claim 1, wherein the event prediction predicts a value and a time of the event. The simulation system according to claim 1 , wherein the correction unit uses a difference between the predicted values of the plurality of events and the value of the previous corrected event. The simulation system according to claim 1, wherein the logical process is selected from an ECU emulator and a physical device simulator. A simulation method having a plurality of logical processes controlled by a computer and operated by sending and receiving events having time and value,
Sequentially recording the values of the events coming into the logical process;
Calculating to predict a plurality of events for pre-speculative execution based on the recorded values of the plurality of events including the incoming event in response to the arrival of the event;
A plurality of events predicted in response to the arrival of the event are compared with values of a plurality of previous events predicted in response to the arrival of the previous event, and an error is taken. Determining a first time point that is within a predetermined threshold;
Rolling back the logical process to the first time point;
Correcting the predicted values of the plurality of events in a distributed manner so that the accumulated error is eliminated before reaching the second time point after the first time point;
Have a step of recording the values of the corrected event,
The correcting step uses a difference between the predicted values of the plurality of events and the value of the previous corrected event.
Simulation method.   The simulation method according to claim 6, wherein the prediction of the event is executed by linear prediction.   The simulation method according to claim 6, wherein the event prediction is to predict a value and a time of the event. The simulation method according to claim 6, wherein the logical process is selected from an ECU emulator and a physical device simulator. A simulation program having a plurality of logical processes controlled by a computer and operated by sending and receiving events having time and value,
In the computer,
Sequentially recording the values of the events coming into the logical process;
Calculating to predict a plurality of events for pre-speculative execution based on the recorded values of the plurality of events including the incoming event in response to the arrival of the event;
A plurality of events predicted in response to the arrival of the event are compared with values of a plurality of previous events predicted in response to the arrival of the previous event, and an error is taken. Determining a first time point that is within a predetermined threshold;
Rolling back the logical process to the first time point;
Correcting the predicted values of the plurality of events in a distributed manner so that the accumulated error is eliminated before reaching the second time point after the first time point;
Recording the corrected event value ; and
The correcting step uses a difference between the predicted values of the plurality of events and the value of the previous corrected event.
Simulation program.   The simulation program according to claim 10, wherein the prediction of the event is executed by linear prediction.   The simulation program according to claim 10, wherein the event prediction predicts a value and a time of the event. The simulation program according to claim 10, wherein the logical process is selected from an ECU emulator and a physical device simulator.

Images