JP6249665B2 - Simulation device, simulation method, and program - Google Patents

Description

  The present invention relates to a simulation apparatus. More specifically, the present invention relates to a simulation apparatus that realizes an integrated simulation environment by exchanging messages and synchronizing time among a plurality of simulators.

  In the development of mechatronics products, simulation technology that reproduces the behavior of various products on a virtual environment such as a computer is adopted. For example, an electric system simulation such as a mechanism system simulation, a mechanical system simulation represented by a structural analysis, an analog physical circuit simulation, or a digital logic circuit simulation. Or software-based simulation using a modeling language. For example, an ISS (Instruction Set Simulator) or UML (Unified Modeling Language) that simulates a CPU. There are a wide variety of simulators that execute such simulations, such as companies preparing for their own product development, or software development companies selling to companies.

  For such technical fields such as mechanical, electric, and software, each engineer uses a simulator to create quality in each technical field. In recent product development, in order to reproduce an operation closer to an actual product, as shown in Patent Document 1, technology development that links these simulations has been performed. Specifically, the motor control of the mechanism simulator is performed by signal notification from the digital logic circuit simulator, and the control of the circuit is controlled by the ISS.

  In order to perform a plurality of simulation linkages targeting various technical fields in this way, it is necessary to pay attention to the fact that each simulator has its own virtual time, and to synchronize the time between the simulators. That is, the timing at which the simulator A accepts the signal notification from the simulator B may not be the timing at which the simulator B transmits the signal. Therefore, it becomes necessary to send a signal to the simulator A at a timing when the simulator A accepts the signal notification from the simulator B. In this way, control that a certain simulator performs transmission and reception of signals with another simulator at a timing unique to the simulator is referred to as time synchronization.

  As a method of time synchronization of a plurality of simulators having such unique virtual times, simulator management that manages time synchronization and transmission / reception of control signals separately from each simulator as shown in Patent Document 2 A technique for providing a part is known.

JP 2011-107962 A Japanese Patent No. 3621392

  However, as shown in Patent Document 2, when time synchronization is performed for a plurality of simulators having different virtual times, depending on the respective synchronization timings, a situation may occur in which control signals to be notified to each other are not transmitted. That is, the control signal is lost.

The simulation apparatus according to the present invention is a simulation apparatus that links a plurality of simulators, and is a recording unit that records messages transmitted from the plurality of simulators, and another simulator that links the messages recorded in the recording unit A message recorded in the recording means based on a parameter based on a difference between the synchronization interval of the other simulator and the synchronization interval of the simulator of the message transmission source. And processing means that transmits the processed message to another simulator that cooperates.

  According to the present invention, it is possible to prevent signal loss without increasing communication overhead.

It is a sequence diagram which shows the example which a signal does not transmit. It is a figure which shows the example of a mechanical simulator and a mechanical component. 1 is a diagram illustrating an example of a configuration of a simulation apparatus according to a first embodiment. FIG. 6 is a diagram illustrating an example of an operation flow for advance preparation according to the first embodiment. It is a figure which shows the simulation participation request message which concerns on Example 1, and the example of the message recorded. It is a figure which shows the example of the screen which performs the connection definition which concerns on Example 1, and the example of the screen which designates a processing method. FIG. 10 is a diagram illustrating an operation flow of simulation execution according to the first embodiment. It is a figure which shows the example of the message recording content at the time of the simulation start request message which concerns on Example 1, the first synchronization request message, and the first synchronization request message. It is a figure which shows the synchronous timing which concerns on Example 1. FIG. FIG. 6 is a diagram illustrating an example of a synchronization request message and a message recorded according to the first embodiment. It is a figure which shows the example of the message recording content in the mechanical simulator time 880ms which concerns on Example 1, and software simulator time 900ms. It is a figure which shows the example of the synchronization request message in mechanical simulator time 960ms and software simulator time 960ms which concern on Example 1, and the recording content of those messages. It is a figure which shows the example of the simulation progress message notified at the mechanical simulator time 960ms which concerns on Example 1, and the example of the signal transmitted / received between simulators. It is a figure which shows the example of the screen which displays that there was overwriting, and the example of the screen which displays the process content. FIG. 10 is a diagram illustrating an example of a configuration of a simulation apparatus according to a fourth embodiment. FIG. 10 is a diagram illustrating an operation flow of simulation execution according to a fourth embodiment. FIG. 10 is a diagram illustrating an operation flow of a simulation calculation according to the fourth embodiment. It is a figure which shows the example of the synchronous timing which concerns on Example 4, and an internal calculation timing. It is a figure which shows the example of the message recording content of the mechanical simulator in the time of 880ms of the mechanical simulator which concerns on Example 4, and the example of the signal transmitted / received between the simulators concerned. FIG. 10 is a diagram illustrating an example of an internal calculation operation of a simulator according to a fifth embodiment. FIG. 10 is a diagram illustrating a configuration of a simulation apparatus according to a fifth embodiment. FIG. 10 is a diagram illustrating an operation flow of a simulation calculation according to the fifth embodiment. It is a figure which shows the example of the message recording content in mechanical simulator time 940ms and 960ms which concerns on Example 5, and the example of the signal transmitted / received between simulators. FIG. 10 is a diagram illustrating an example of a configuration of a simulation apparatus according to a sixth embodiment. It is a figure which shows the example of the simulation participation request message which concerns on Example 6. FIG. FIG. 10 is a diagram illustrating an operation flow of simulation execution according to a sixth embodiment. It is a figure which shows the synchronous timing which concerns on Example 6. FIG. It is a figure which shows the example of the message currently recorded on the message recording part which concerns on Example 6. FIG.

<Example of control signal not being transmitted to simulator>
First, before describing a mode for carrying out the invention, a specific example of the above-described situation in which a control signal is not transmitted to a simulator depending on synchronization timing will be described.

  FIG. 1 shows a communication sequence when two simulators take time synchronization while exchanging signals with each other. The simulator management unit manages time synchronization and transmission / reception of control signals between the simulator 1 and the simulator 2. Here, it is assumed that the simulator 1 takes time synchronization at virtual times 880 ms and 960 ms, and the simulator 2 takes time synchronization at virtual times 840 ms, 900 ms and 960 ms. That is, it is assumed that each simulator exchanges signals with other simulators at the above virtual time. In the following description, virtual time may be simply expressed as time.

  Focusing on the operation of notifying the simulator 1 of the output signal of the simulator 2 in FIG. 1, first, the simulator 2 is notified of the output signal of the simulator 2 at the virtual time 840 ms. This signal is notified from the simulator management unit to the simulator 1 at the synchronization timing of the virtual time 880 ms of the simulator 1. Subsequently, an output signal of the virtual time 900 ms of the simulator 2 is notified to the simulator management unit. However, the virtual time at which the simulator 1 next synchronizes is 960 ms, and this virtual time is the timing at which the simulator 2 also synchronizes. Therefore, the output signal notified to the simulator management unit by the simulator 2 at the virtual time of 900 ms is overwritten by the output signal notified next at 960 ms. That is, as shown in FIG. 1, the output signal of the virtual time 900 ms of the simulator 2 disappears without being notified to the simulator 1.

  In order to show a specific example of a case where control signals to be notified to each other are not correctly transmitted, here, a belt conveyor will be described as an example of a simulation target product. FIG. 2 is a mechanical simulator that simulates the mechanism operation of the belt conveyor, and corresponds to the simulator 1 of FIG. Further, a software simulator that simulates the operation of a program for controlling the belt conveyor is assumed as the simulator 2 in FIG.

  The belt conveyor of the mechanical simulator shown in FIG. This motor starts rotating when the motor drive start interrupt signal notified from the software simulator changes from low to high (called a rising edge). As the motor rotates, the roller 1 rotates, and the belt and the roller 2 operate in conjunction with each other. The baggage on the belt is carried along with the movement of the belt.

  Furthermore, a position sensor is provided to notify that the package has reached the designated position, and the mechanical simulator notifies the software simulator of this sensor signal.

  In such a configuration, a software simulator corresponding to the simulator 2 in FIG. 1 outputs the value of the motor drive start interrupt signal as Low until the virtual time 840 ms. It is assumed that High is output at a virtual time of 900 ms, and Low is output again after the virtual time of 960 ms. Under this assumption, the output signal of the virtual time 900 ms of the software simulator is overwritten with the signal of the virtual time 960 ms as described in FIG. That is, the High signal output at the virtual time of 900 ms is overwritten with Low. As a result, the mechanical simulator continues to receive a signal whose motor drive start interrupt signal value is Low from the simulator management unit, and cannot obtain a desired signal level. This means that the mechanical simulator cannot accept the interrupt signal for starting the motor drive from the software simulator, and the belt conveyor does not operate. In this way, depending on the signal, there is a problem that the operation of the product cannot be reproduced by a single oversight. In order to establish the operation of the product, it is important to reliably transmit signals in accordance with the product standard even if it is not an accurate time.

  As a general solution to such a problem, it is conceivable to make the synchronization interval sufficiently fine. In this case, however, there is another problem that the processing overhead as a whole increases because the number of communication increases by the finer amount. to be born. If the synchronization interval is halved, the number of communications is doubled.

  In an embodiment to be described later, in view of the above-described problems that occur when a plurality of simulators are linked, a simulation apparatus that prevents signal loss without increasing communication overhead is provided.

  Hereinafter, embodiments according to the present invention will be described in detail.

The configuration of the first embodiment will be described first, followed by the procedure.
<Description of configuration>
FIG. 3 is a diagram illustrating an example of the configuration of the simulation apparatus 300 according to the first embodiment. As shown in FIG. 3, the simulation apparatus 300 can be realized by a computer. The simulation apparatus 300 includes a simulator management unit 310, a mechanical component 320, a mechanical simulator 330, a software component 340, a software simulator 350, and a bus 360.

  The mechanical part 320 and the software part 340 are examples of simulation parts for simulating the behavior of a product to be simulated. For example, in the case of a mechanism simulator, the simulation part is composed of 3D shape data created by 3D-CAD (Computer Aided Design) and physical phenomenon data added to 3D shape data such as gravity and friction. If it is a software simulator, it consists of a computer program.

  The simulator management unit 310 includes a communication unit 311, a message recording unit 312, a synchronization management unit 313, a connection relationship management unit 314, a processing unit 315, and a processing method designation unit 316.

  The mechanical simulator 330 includes a component reading unit 331, a simulation execution unit 332, a virtual time management unit 333, a message recording unit 334, and a communication unit 335.

  The software simulator 350 includes a component reading unit 351, a simulation execution unit 352, a virtual time management unit 353, a message recording unit 354, and a communication unit 355.

  The mechanical simulator 330 and the software simulator 350 can be described as having the same configuration except that the simulator parts to be handled are different, and therefore the configuration of the mechanical simulator 330 will be described below.

  The component reading unit 331 reads a mechanical component 320 that is a simulation component that simulates the behavior of a product to be simulated.

  The simulation execution unit 332 performs a simulation operation for simulating product behavior according to the mechanical component 320 that is a simulation component read by the component reading unit 331. Moreover, the simulation execution part 332 receives the control signal notified from another simulator, performs a simulation calculation, and produces | generates the control signal to another simulator by calculation. These control signals are stored in a message and managed by the message recording unit 334. A specific example of the message will be described in the description of the operation described later.

  The virtual time management unit 333 manages the virtual time that is advanced by the simulation calculation of the simulation execution unit 332. The virtual time management unit 333 also determines a virtual time that is time-synchronized with other simulators. This decision depends on the simulator. For example, it is every time specified in advance or when there is a change in a control signal to another simulator generated by the simulation execution unit 332.

  The message recording unit 334 manages messages transmitted / received via the communication unit 335. The message includes a virtual time of each simulator, a control signal transmitted / received between a plurality of simulators, and the like.

  The communication unit 335 performs communication for transmitting and receiving messages via the simulator management unit 310 and the bus 360.

  Next, the configuration of the simulator management unit 310 will be described.

  The communication unit 311 communicates with a plurality of simulators (mechanism simulator 330 and software simulator 350) for transmitting and receiving messages via the bus 360.

  The message recording unit 312 manages messages to be transmitted / received to / from a plurality of simulators. The message includes a virtual time notified from a plurality of simulators and a control signal notified to each other between the simulators. It also includes a parameter indicating whether the message has been notified to another simulator to be connected. Specific examples will be described later.

  The synchronization management unit 313 synchronizes time by comparing virtual times held by a plurality of simulators. Specifically, referring to the message recording unit 312, the simulator having the latest time is identified by comparing the virtual times of the simulators, and only the simulator is instructed to proceed. Specific operation will be described later.

  The connection relationship management unit 314 defines a connection relationship between a plurality of simulators. With this definition, it is possible to determine which simulator control signal should be notified to which simulator.

  The processing unit 315 processes a control signal transmitted / received between a plurality of simulators based on a processing method specified by the processing method specifying unit 316 in order to prevent the control signal from being missed.

  The processing method designation unit 316 designates how to process control signals transmitted and received between a plurality of simulators in order to prevent the control signals from being missed.

  The bus 360 exchanges information between each simulator and the simulator management unit 310.

  The simulation apparatus 300 realizes each configuration of the simulator management unit 310, the mechanical simulator 330, and the software simulator 350 when the CPU reads and executes a computer program stored in the RAM.

  In the example of FIG. 3, the simulation apparatus 300 is described as being configured on one computer, but the simulation apparatus may be configured via a plurality of computers. That is, each computer constituting each simulator may be connected to the computer constituting the simulator management unit using a network line represented by a LAN instead of the bus 360 in FIG. In this way, the simulation apparatus may be realized by a plurality of distributed computers.

  Each simulator does not necessarily have to be a simulator simulated on a computer. A part or all of the simulator may be replaced with a verification module such as an actual product or FPGA (Field Programmable Gate Array).

  An example of how the simulation is specifically performed in such a configuration will be described.

<Description of operation>
In the present embodiment, a preliminary preparation step is first performed, and then a simulation execution step is performed.

  Details of the advance preparation step will be described with reference to the flowchart of FIG. The flow in FIG. 4 is realized by the CPU executing a program stored in the RAM or the like. More specifically, steps S401 to S403 are processes related to the mechanical simulator 330 and the software simulator 350, and steps S404 to S406 are processes related to the simulator management unit 310.

  In step S401, the simulation apparatus 300 activates a simulator that cooperates. That is, the simulation apparatus 300 activates the mechanical simulator 330 and the software simulator 350.

  In step S402, each simulator activated in step S401 reads a simulation part. As shown in FIG. 2, the mechanical simulator 330 reads a mechanical part 320 including mechanism information such as the shape of the belt conveyor. The software simulator 350 reads a software component 340 for controlling the belt conveyor.

  In step S403, each simulator notifies the simulator management unit 310 of a simulation participation request message. FIG. 5 is a diagram illustrating a simulation participation request message notified from each simulator to the simulator management unit 310 and an example of a message recorded in the simulator management unit 310. As shown in FIGS. 5A and 5B, the contents of the simulation participation request message include a message type (Connect) 501 indicating participation, a virtual time 502, a signal to be output to the outside, its initial value 503, and input. A list 504 of signals to be received is included. FIG. 5A shows a simulation participation request message notified by the mechanical simulator 330. Low is set as the initial value of the position sensor signal, which is the signal to be output, and the motor drive interrupt signal is specified as the signal to receive input. FIG. 5B is a simulation participation request message notified by the software simulator 350. Low is set as the initial value of the motor drive start interrupt signal, which is an output signal, and the position sensor signal is specified as a signal to be received. In the simulation participation request messages shown in FIGS. 5A and 5B, values indicating the notification source 505 and the notification destination 506 are specified. For example, in the example of the message notified from the mechanical simulator shown in FIG. 5A, the mechanical simulator is specified as the notification source 505, and the simulator management unit is specified as the notification destination 506. The message shown in FIG. 5 may be in any format as long as these pieces of information can be distinguished from each other. For example, only the simulator identifier may be specified in the notification source 505, or the signal 504 that is desired to accept an input may have a format in which a value for simply specifying the signal type is specified. The same applies to various messages described in the present specification.

  Returning to the flowchart of FIG. 4, the description of the processing will be continued. In step S404, the simulator management unit 310 receives the participation request message notified from each simulator in step S403, and records the message in the message recording unit 312. As shown in FIGS. 5C and 5D, the message to be recorded is a virtual time 551 included in the received message and a list 553 of output signals from the simulator. In order to prevent the control signal from being missed, a parameter (Send “destination simulator name” = FALSE) 552 indicating that the message at the virtual time 551 has not been notified to the simulator at the connection destination is also recorded. In this “destination simulator name”, the name of the simulator for which the connection definition described in step S405 described later is performed is designated. Linking refers to linking a simulator to another simulator. Specifically, the simulator management unit 310 defines to which simulator a message notified from a certain simulator is transmitted. It is. Details will be described later. FIG. 5C shows the content of the participation request message notified from the mechanical simulator 330 being recorded in the message recording unit 312 by the simulator management unit 310. FIG. 5D shows the content of the participation request message notified from the software simulator 350 similarly recorded in the message recording unit 312 by the simulator management unit 310. Hereinafter, a message not notified to the connection destination simulator is referred to as an unnotified message, and a notified message is referred to as a notified message. In the message recording unit 312, as shown in FIGS. 5C and 5D, for each simulator, a message notified from each simulator is recorded in association with a parameter indicating the virtual time and presence / absence of notification.

  Returning to the flowchart of FIG. 4, the description of the processing will be continued. In step S405, the connection relationship management unit 314 of the simulator management unit 310 performs connection definition. The connection definition is based on a message recorded in the message recording unit 312 and defines a connection relationship based on a list of simulators that have made a participation request and their input / output signals. That is, the control signal notification source and notification destination are defined. For example, the connection relationship management unit 314 associates an output signal (notification source) and an input signal (notification destination) of the simulator using a screen as shown in FIG. In setting 1, a linkage definition for notifying a motor drive interrupt signal from the software simulator 350 to the mechanical simulator 330 is performed. In setting 2, a connection definition for notifying the position sensor signal from the mechanical simulator 330 to the software simulator 350 is performed. Note that, as illustrated in FIG. 6A, the connection relationship management unit 314 may set the connection definition according to designation from the user. Or you may set automatically based on the information contained in the participation request message notified from each simulator.

  Returning to the flowchart of FIG. 4, the description of the processing will be continued. In step S406, the processing method designation unit 316 of the simulator management unit 310 designates a message processing method. The message processing method is specified by selecting how to process the signal output by each simulator recorded in the message recording unit 312. For example, the designation from the user is accepted using a screen as shown in FIG. The processing method has options such as maximum value, minimum value, average value, and integration, and the processing method can be selected according to the nature of the signal. In setting 1 in FIG. 6B, a processing method for obtaining the maximum value for the motor drive interrupt signal output from the software simulator 350 is specified. For example, when a motor drive interrupt signal notified from the software simulator 350 to the simulator management unit 310 is transmitted from the simulator management unit 310 to the mechanical simulator, a method for changing (that is, processing) the signal value is designated. In setting 2, a machining method for obtaining a maximum value for the position sensor signal output from the mechanical simulator 330 is designated. The processing method may be changed during the simulation.

  The advance preparation is complete. Next, details of the simulation execution procedure will be described with reference to the flowchart of FIG.

  In step S701, the simulator management unit 310 notifies each simulator of a simulation start request message. The contents of the simulation start request message are shown in FIGS. FIG. 8A shows a message notified from the simulator management unit 310 to the mechanical simulator 330. The message includes a message type (Start) 901 indicating start, a virtual time 902, and a list 903 of signals that the mechanical simulator 330 wants to accept input specified by the participation request message. The values included in this signal list are determined based on the connection definition defined in step S405. FIG. 8B similarly shows a message notified from the simulator management unit 310 to the software simulator 350. The simulator management unit 310 that has transmitted the simulation start request message waits until a synchronization request message is notified in step S704 described later. In addition, the message recorded as unnotified in step S404 (that is, the messages in FIGS. 5C and 5D) is updated to notified (Send “destination simulator name” = TRUE).

  In step S702, each simulator records the simulation start request message notified from the simulator management unit 310 in step S701 in each message recording unit 334, 354).

  In step S703, the simulation execution units 332 and 352 of each simulator start simulation calculation based on the message recorded in step S702. This simulation calculation proceeds until the synchronization time determined by the virtual time management units 333 and 353 of each simulator.

  In step S704, each simulator notifies the simulator management unit 310 of a synchronization request message when the execution of the simulation proceeds until the time of synchronization. Examples of the contents of the synchronization request message are shown in FIGS. 8 (c) and 8 (d). The synchronization request message includes a message type (Sync) 911 indicating a synchronization request, an advanced virtual time 912, an output signal 913 generated by a simulation calculation, and a list 914 of signals to be accepted. FIG. 8C is a synchronization request message notified from the mechanical simulator 330 to the simulator management unit 310, and indicates that the value of the position sensor signal at the virtual time of 80 ms is Low. Similarly, FIG. 8D is a message notified from the software simulator 350 to the simulator management unit 310, and shows that the value of the motor drive interrupt signal at time 60 ms is Low.

  Each simulator that has notified the simulator management unit 310 of the synchronization request message stands by until a simulation progress message in step S710 described later or a simulation end message in step S711 is notified. As will be described later, an input of a signal to be accepted included in the synchronization request message is included in the simulation progress message from the simulator management unit 310 and notified. Therefore, each simulator waits without proceeding with the simulation until a simulation progress message is notified. If a simulation end message is notified, the simulation is ended as it is.

  In step S705, the simulator management unit 310 records the synchronization request message notified in step S704 in the message recording unit 312. The message recorded in the message recording unit 312 is updated to the message shown in FIGS. 8E and 8F from the time when the participation request message shown in FIGS. 5C and 5D is recorded. The contents to be updated are the virtual time 821 and the output signal list 823 based on the synchronization request message notified in step S704. In order to prevent the control signal from being missed, a parameter 822 indicating that the message at the virtual time has not been notified is also recorded. As described above, the parameter 825 indicating whether or not the virtual time 0 is recorded, which is recorded at the time of requesting to participate in the simulation, is updated to “TRUE”. Thus, when the message at the virtual time is notified in the simulation progress message as described later, the parameter indicating that the message has not been notified is changed to a parameter indicating that the message has been notified.

  In step S706, if the simulator management unit 310 has not received the synchronization request message from all the simulators that have notified the participation request message recorded in step S404, the simulator management unit 310 waits until the next synchronization request message is received. For example, in the example of FIG. 8, the simulator management unit 310 does not receive the synchronization request message from the mechanical simulator 330 when it receives the synchronization request message shown in FIG. Will be. When the simulator management unit 310 notifies a simulation progress message to be described later in response to the synchronization request message, the state is changed to a state in which the synchronization request message from the notification destination simulator is not received. That is, it can be said that step S706 is a process for determining whether or not the simulator management unit 310 has received an unsupported synchronization request message from all the simulators.

  When synchronization request messages have been received from all the simulators, in step S707, the synchronization management unit 313 refers to the synchronization request messages shown in FIGS. 8E and 8F recorded in step S705, and determines the virtual time of each simulator. Compare The virtual time to be compared is a message recorded based on the latest synchronization request message notified by each simulator, such as virtual times 821 and 824 in FIGS. 8 (e) and 8 (f). The simulator with the slowest progress, that is, the simulator with the smallest virtual time is identified by comparison. If the messages shown in FIGS. 8E and 8F are used, the mechanical simulator 330 is 80 ms, and the software simulator 350 is 60 ms. Therefore, it can be determined that the progress of the software simulator 350 is most delayed. Note that the simulator having the smallest virtual time is not necessarily one. If the compared times are the same time, both simulators are identified as the simulators that are the most delayed. Similarly, when there are three or more simulators, one or more simulators having the most delayed virtual time are identified.

  In step S708, the simulator management unit 310 processes the synchronization request message based on the processing method designated in step S406 as necessary, and determines a message to be notified to the simulator that is most delayed. Note that the message processing processing in step S708 includes processing for extracting a message to be processed and processing for processing the extracted message. In step S708, although the message to be processed is extracted, the case where the message is not actually processed is also included. The case where the message is actually processed in step S708 is a case where a predetermined condition is met as will be described later. In other words, if the predetermined condition is not met, the actual processing is not executed in step S708.

  Message processing is performed first based on the following two conditions. The first condition is a message notified to the simulator management unit 310 having a virtual time before the virtual time of the simulator that receives the message from the simulator management unit 310. Here, the simulator that receives the message is the most advanced simulator identified in step S708 described above. That is, in step S708, the processing is to process a signal to be included in a synchronization progress message (described later) in response to the synchronization request message from the simulator that is most delayed. Of the messages that are desired to be accepted by the synchronization progress message, a message having a virtual time earlier than the virtual time of the simulator on the message receiving side is processed. The second condition refers to a parameter indicating whether or not the notification in the message recorded in the message recording unit 312 has been performed, and is only an unreported message (Send “destination simulator name” = FALSE). is there. If there are two or more messages that satisfy the two, the two or more messages are processed and a notification message is generated. In one case, it means that it will not be missed, and no message is processed and the message is notified. If there is none, a parameter indicating whether or not notification is made is referred to, and a message having the latest virtual time is notified among the notified messages. In this case, it will not be missed.

  Description will be made with reference to FIGS. 8E and 8F. The simulator with the slowest progress, that is, the simulator that receives the synchronization progress message is the software simulator 350. Then, referring to FIG. 8F, the virtual time of the software simulator on the receiving side is 60 ms. The message that satisfies the first condition having the virtual time before this time is only the message 925 notified by the mechanical simulator when the participation request is made, with reference to FIG. Since the message at this time is set to be notified in step S701, the second condition is not satisfied. That is, this corresponds to the case where no message satisfies the two conditions. Therefore, a message having the latest virtual time is notified among the notified messages. Therefore, as the synchronization progress message notified to the software simulator at the virtual time of 60 ms, the message having the latest virtual time of 0 ms that has been notified by the mechanical simulator is selected. That is, the position sensor signal Low at the virtual time 0 ms of the mechanical simulator 330 is notified to the software simulator 350.

  In step S709, it is determined whether the simulation end time has been reached. Whether the end time has been reached may be determined based on whether the user has issued an end instruction, or the end time may be determined in advance.

  If the simulation end time has not been reached, in step S710, the simulator management unit 310 notifies the simulation progress message to the slow progressing simulator specified in step S707. The simulation progress message includes a message type (Sync-Ack) meaning simulation progress and a list of signals for which input specified by the synchronization request message is accepted. Here, in the simulation progress message notified from the simulator management unit 310, the value determined in step S708 with respect to the position sensor signal for which the input specified in step S704 is to be received (Low in the case of FIG. 8E). ) Is set. That is, the value obtained through the processing in step S708 is set as the value of the signal for which input is to be accepted, and is notified from the simulator management unit 310 to each simulator. The message recording unit 312 of the simulator management unit 310 updates the notified message to “Notified” (Send “destination simulator name” = TRUE).

  If the simulation end time has been reached, in step S711, the simulator management unit 310 notifies each simulator of a simulation end message and ends the simulation execution. The simulation end message includes a message type (Exit) indicating the end of the simulation, a virtual time at which the simulation has been completed, and a list of signals that are desired to accept the input specified in the synchronization request message. Note that the message recording unit 312 updates the notified message and the message to be processed in step S708 to a parameter (Send “destination simulator name” = TRUE) meaning that notification has been made, as in step S710 above. To do.

  In step S710, the simulator that has received the simulation progress message notified from the simulator management unit 310 continues the simulation with the notified message as an input in step S703. When the simulation progresses to the next synchronization timing, each simulator notifies the simulator management unit 310 of a synchronization request message (step S704).

<Specific operation explanation>
The effect of the present embodiment obtained by processing the message will be specifically described with reference to FIG. FIG. 9 shows the timing at which the simulator management unit 310 and the two simulators (mechanism simulator 330 and software simulator 350) communicate. In FIG. 9, steps S703 to S710 in FIG. 7 are continuously repeated, and it is assumed that the simulation progresses until the time 880 ms for the mechanical simulator 330 and the time 900 ms for the software simulator 350. FIG. 10A shows a synchronization request message notified from the software simulator 350 to the simulator management unit 310 at the immediately preceding time 840 ms. FIG. 10B shows the contents recorded by the simulator management unit 310 in the notified synchronization request message shown in FIG.

  FIG. 10C shows a synchronization request message that the mechanical simulator 330 notifies the simulator management unit 310 at step S704 at time 880 ms (910) in FIG. Similarly, FIG. 10D shows a synchronization request message that the software simulator 350 notifies the simulator management unit 310 at time 900 ms (940) in FIG. As shown in FIGS. 10B and 10D, the software simulator 350 assumes an operation in which the motor drive start interrupt signal output until time 840 ms is Low and becomes High for the first time at 900 ms.

  Next, the explanation is continued in the situation where the simulation is progressing until the time of 880 ms for the mechanical simulator 330 and the simulation is performed until the time of 900 ms for the software simulator 350. In step S705, the simulator management unit 310 that has received the notification of the synchronization request message from each simulator records the notified message in the message recording unit 312. The messages recorded in the message recording unit 312 of the simulator management unit 310 for each simulator at this time are shown in FIG. FIG. 11A shows a message recorded at a time of 880 ms from the mechanical simulator 330, and FIG. 11B shows a message recorded at a time of 900 ms from the software simulator 350.

  In step S707, the latest virtual time 880ms (1101) of the mechanical simulator 330 and the latest virtual time 900ms (1113) of the software simulator 350 are compared, and the mechanical simulator 330 is specified as a simulator whose progress is delayed.

  Subsequently, in step S708, the simulator management unit 310 identifies the mechanical simulator 330 whose progress is delayed as the simulator on which the message is received, and processes the message notified to the mechanical simulator. That is, it is performed by processing the message shown in FIG. 11B in which the synchronization request message from the software simulator 350 is recorded. The message to be processed is a message with a virtual time of 880 ms or less that satisfies the first condition, and an unnotified message that satisfies the second condition. Here, the message to be processed in the output signal of the software simulator 350 is only the time 840 ms (1112). Accordingly, as a response to the synchronization timing 910, the signal value included in the message at time 840 ms is directly included in the simulation progress message and notified to the mechanical simulator (step S710). At this time, the message recording unit 312 updates the message (1112 in FIG. 11B) of the software simulator at time 840 ms to be notified (TRUE).

  Subsequently, the mechanical simulator 330 that has received the progress message advances the simulation to the next synchronization timing of 960 ms (920) (step S703), and notifies the simulator management unit 310 of the synchronization request message (step S704). A message notified from the mechanical simulator at a time of 960 ms is shown in FIG.

  Upon receiving the notification of the synchronization request message shown in FIG. 12A, the simulator management unit 310 records the notified message in the message recording unit 312 (step S705). The recorded message is shown at 1202 in FIG. The simulator management unit 310 at this time compares the time 960 ms (1202) of the mechanical simulator 330 with the time 900 ms (1113 of FIG. 11B) of the software simulator 350. Then, the software simulator 350 is specified as a delayed simulator (step S707).

  Subsequently, the message shown in FIG. 11A is processed (step S708). The message to be processed is a message with a virtual time of 900 ms or less that satisfies the first condition, and an unnotified message that satisfies the second condition. That is, since the virtual time is only 880 ms (1101 in FIG. 11A), this message is notified as it is. At this time, the message recording unit 312 updates the message at time 880 ms (1101 in FIG. 11A) to be notified. Therefore, the message at the time 880 ms at 1201 in FIG.

  Similarly, the software simulator 350 that has received the progress message advances the simulation to the next synchronization timing of 960 ms (step S703), and notifies the simulator management unit 310 of the synchronization request message (step S704). The message to be notified is shown in FIG. As shown in FIG. 12B, the software simulator 350 assumes an operation of returning the motor drive start interrupt signal output at the virtual time 960 ms to Low.

  Upon receiving the notification, the simulator management unit 310 records the notified message in the message recording unit 312 (step S705). The recorded message is shown at 1213 in FIG.

  Subsequently, in step S707, the virtual time of the mechanical simulator 330 and the virtual time of the software simulator 350 are compared. From FIGS. 12C and 12D, the virtual time 960 ms (1202) of the mechanical simulator 330 and the virtual time 960 ms (1213) of the software simulator 350 both advance to 960 ms and are the same virtual time. Therefore, processing for notifying both simulators of the simulation progress message is performed.

  In step S708, the message notified to the software simulator 350 is processed. The message to be processed is a message that satisfies the virtual time of 960 ms or less from the first condition and satisfies the unnotified from the second condition. Since the message satisfying this condition is only the virtual time 960 ms (1202), the message at the time 960 ms from the mechanical simulator is notified as it is. Similarly, the output signal of the software simulator 350 notified to the mechanical simulator 330 is also confirmed. The message to be processed is a message that satisfies 960 ms or less from the first condition and satisfies unnotified from the second condition. There are two messages that satisfy this condition: virtual time 900 ms (1212) and virtual time 960 ms (1213). Therefore, processing for obtaining the maximum value, which is the method defined in step S406, is performed on the signals at these two virtual times, and the processed message is notified to the mechanical simulator (step S710). The message to be notified is shown in FIG. As shown in FIG. 13A, the mechanical simulator 330 is notified of the maximum value of High (1212) and Low (1213) as a motor drive start interrupt signal (1301). In step S710, the message recording unit 312 updates the notified messages (that is, 1202, 1212, and 1213) including the message to be processed to be notified.

  Assuming that the software simulator 350 outputs an interrupt signal for starting driving the motor as described above, the waveform thereof is shown in FIG. 13 (b-1). As a result, the mechanical simulator 330 can obtain a desired signal level as shown in FIG. As a result, the driving of the motor is started, and the cargo is carried in conjunction.

  As described above, signals that have not been notified so far are recorded and processed by a processing method designated in advance, thereby preventing signal loss.

  The processing method includes a maximum value and a minimum value if the signal level is the same as in this embodiment, and includes integration if the number of signal pulses. The processing method can be arbitrarily selected according to the signal to be processed.

  As described in the first embodiment, when one missing such as an interrupt signal greatly affects the operation of the product, the missing is not permitted. On the other hand, depending on the signal, it may not always be necessary to process the signal. For example, if there is a continuity signal or a signal with a small change amount in one synchronization, even if it is missed, there is no significant influence on the operation. In general, these signals are mixed. In such a case, in order to ascertain whether or not processing is necessary, it is necessary to visualize what kind of missing is present.

  In the second embodiment, when there is a signal that is not transmitted, the simulator management unit provides a simulation device that presents the signal that is not transmitted to the user. As a presentation method, there are various methods such as displaying on a display or notifying by voice.

  The presentation can be realized by referring to the message recording unit 312 that is recorded when a simulation participation request message or a synchronization request message is notified from the simulator. As shown in the first embodiment, since the message recording unit 312 holds a parameter indicating whether the message has been notified or not notified, it can be confirmed in the message processing step S708. Specifically, it is determined whether or not there are two or more messages to be processed described in step S708. If there is, it indicates that a missing item will occur. Taking the case of FIG. 12D as an example, two messages at time 900 ms (1212) and time 960 ms (1213) are to be processed. Conventionally, only the message at the latest time 960 ms (1213) is notified, and the message at time 900 ms (1212) is a target to be missed. That is, when there is a message to be processed, a message obtained by removing a message having the latest virtual time from the message is missed.

  As shown in FIG. 14A, the message to be missed may be displayed on the display device in real time, or may be stored in the recording device so that it can be confirmed later. FIG. 14A shows an example in which a message that has been missed is displayed on the screen of the display device in real time.

  According to the present embodiment, the user can confirm what has been missed at which timing by confirming the recorded contents. In the first simulation, processing is not performed, it is confirmed whether or not a signal has been missed, and what kind of signal has been missed. In the second and subsequent simulations, signal processing can be performed as necessary.

  In the first embodiment, an example of processing that takes a maximum value for one or more signals in time series in order to prevent interruption of an interrupt signal is shown. The processing method is not limited to the maximum value, and various processing such as total and average values can be considered. While various processing methods can be considered, a situation occurs in which an appropriate signal is not notified if the processing method is incorrectly specified.

  The third embodiment provides a simulation device that presents to a user what signals have been processed and how.

  This can be realized by recording the processing content when processing the message in processing step S708. Taking FIG. 12D as an example, two messages at time 900 ms (1212) and time 960 ms (1213) are to be processed, and since the motor drive start interrupt signals are High and Low, they are processed to High. The

  As shown in FIG. 14B, the recorded content of the message to be processed may be displayed on the display device in real time, or may be stored in the recording device so that it can be confirmed later.

  In the simulation described in the first embodiment, although a timing shift occurs, notification can be made without missing an important signal such as an interrupt signal. However, it is desirable to reduce the difference in notification timing in order to improve accuracy.

  Although the timing deviation can be reduced by reducing the synchronization interval, the number of communication increases by the amount of the synchronization interval being reduced. That is, the processing time required for executing the simulation increases.

  On the other hand, the synchronization interval is generally larger than the minimum time unit that the simulator calculates internally. For example, in the case of a digital circuit simulator, an internal circuit state calculation is performed in units of clocks (for example, 100 MHz, 100,000,000 / second) possessed by the circuit. And it synchronizes at the timing (for example, about several clocks-about several tens clocks) when the control signal output outside changes.

  In the fourth embodiment, a simulation apparatus is provided that makes use of this property to eliminate missing and reduce delay.

<Description of configuration>
FIG. 15 is a diagram illustrating an example of a configuration according to the fourth embodiment. Compared to FIG. 3 described in the first embodiment, the mechanical simulator 1530 and the software simulator 1550 include a message selection unit 1536 and a message selection unit 1556, respectively. Further, from the simulator management unit 1510, the processing unit 315 and the processing method designation unit 316 shown in FIG.

  Other configurations can be the same as those shown in FIG.

  Note that the message recording units 1534 and 1554 of each simulator in FIG. 15 are parameters that indicate whether or not the message has been used for simulation calculation in addition to the management of messages transmitted and received via the communication unit as in the first embodiment. Manage.

  The message selection units 1536 and 1556 select messages notified from other simulators used by the simulation execution units 1532 and 1552 for calculation. Details will be described later.

  The message recording unit 1512 of the simulator management unit manages messages that are transmitted to and received from the plurality of simulator units described above. However, the notification message is different from that in the first embodiment. Details will be described in the explanation of the operation. As in the first embodiment, two simulators are used to simplify the description.

<Description of operation>
The operation flow of the preliminary preparation in the fourth embodiment performs the process of FIG. 4 described in the first embodiment except for step S406 for specifying the processing method.

  FIG. 16 is a diagram illustrating an example of an operation flow of simulation execution according to the fourth embodiment. Steps S1601 to S1611 shown in FIG. 16 are the same operation flow except for step S708 shown in FIG. 7 of the first embodiment. The message processing step S708 shown in FIG. 7 is not performed in this embodiment. Instead, in this embodiment, the way of handling messages in steps S1603 and S1610 is changed to reduce the delay.

  First, a change in how the simulation progress message is handled in step S1610 will be described. In step S710 illustrated in FIG. 7, the example in which the process of transmitting the simulation progress message in response to the synchronization request signal from the simulator with the slowest progress has been described. In step S1610 in FIG. 16, all signals not yet notified are notified from the simulator management unit 1510 to each simulator regardless of the virtual time of the message. What kind of notification is performed will be described later in the specific operation description.

  In step S1603, the simulation execution units 1532 and 1552 select a message to be used as an external input signal from the messages recorded in the message recording units 1534 and 1554 of each simulator. At this time, the simulation execution units 1532 and 1552 select a message to be used based on the virtual time managed by the virtual time management units 1533 and 1553. A specific operation will be described with reference to the flowchart of FIG. FIG. 18 shows a detailed operation flow of step S1603.

  In step S1750, each simulator records the simulation progress message notified from the simulator management unit 1510 in the message recording units 1534 and 1554.

  In step S1751, the message selection units 1536 and 1556 select an input signal from the external simulator that is used in the next simulation calculation in step S1752 from the messages recorded by the message recording units 1534 and 1554. As the input signal, a message having a virtual time that does not exceed its current virtual time is selected.

  In step S1752, a simulation internal calculation is performed based on the input signal selected in step S1751. In general, a simulator performs a simulation calculation while advancing virtual time more finely than the synchronization interval in accordance with the simulation target. Hereinafter, this simulation calculation is referred to as an internal calculation.

  In step S1753, it is determined whether the virtual time has reached the synchronization timing as a result of performing the internal calculation in step S1752. When it reaches, the simulation calculation is terminated, and the process proceeds to step S1604. If not, the process returns to S1751 to repeat the same operation.

  As described above, the delay can be reduced by reviewing the message to be adopted as the input signal each time the simulation internal calculation is performed.

<Specific operation explanation>
Specific operation will be described below. As for the specific operation, similarly to the first embodiment, it is assumed that the mechanical simulator 1530 operates until the time when the simulation progresses to the time of 880 ms and the synchronization request message is notified to the simulator management unit 1510. Further, it is assumed that the software simulator 1550 has been operated up to the time of 900 ms and has been operated until the time when the simulator management unit 1510 is notified of the synchronization request message.

  The messages recorded in the message recording unit 1512 held by the simulator management unit 1510 at this point are the same except for some of the messages shown in FIGS. 11A and 11B described in the first embodiment. The difference is that the message at time 840 ms in FIG. 11B is already notified in this embodiment. The reason why it has been notified will be described later.

  Further, it is assumed that the mechanical simulator 1530 internally performs internal computation in units of 10 ms as shown in FIG. 18 and synchronizes with other simulators in units of 80 ms.

  The following process will be described under this assumption.

  In step S1607, the simulator management unit 1510 that has received the synchronization request message compares virtual times. Here, the virtual time 880 ms of the mechanical simulator 1530 and the virtual time 900 ms of the software simulator 1550 are compared, and the most delayed simulator is specified as the mechanical simulator 1530.

  The simulation progress message to be notified in step S1610 notifies all unreported messages regardless of the virtual time held by each simulator. This will be described with reference to the example of FIG. In the fourth embodiment, as described above, it is assumed that the time 840 ms in FIG. 11 is notified (TRUE). Here, the simulation progress message notified to the most delayed mechanical simulator at 880 ms includes a signal at 900 ms of the software simulator. It should be noted that the simulator management unit 1510 is notified and recorded the synchronization request message from each simulator. . Therefore, a signal corresponding to the time 900 ms of the software simulator can be included as a simulation progress message corresponding to the time 880 ms of the mechanical simulator. Therefore, in the example of FIG. 11, the simulation progress message responding to the synchronization request message of the mechanical simulator at the time 880 ms includes the signal (1113) of the software simulator at the time 900 ms that is an unreported signal. In this case, the message recording unit 1512 of the simulator management unit 1510 updates 1113 in FIG. In the description of the fourth embodiment, the reason why 1112 in FIG. 11 has already been notified is the same reason. In other words, the assumption in this embodiment is that the mechanical simulator 1530 has already notified the simulation progress message for the time 800 ms (see 1803 in FIG. 18).

  Next, the operation of the mechanical simulator 1530 that has received the notification of the simulation progress message will be described with reference to FIG.

  In step S1750, the mechanical simulator 1530 records the notified simulation progress message in the message recording unit 1534. An example of the recorded message is shown in FIG. As shown at 1920 in FIG. 19A, the value of a signal to be received based on the simulation progress message is recorded. Here, a message of 900 ms of the software simulator is recorded in response to the synchronization request message of 880 ms.

  In step S1751, the message selection unit 1536 selects a message used for the simulation calculation. The selection method is performed based on the virtual time held by the mechanical simulator 1530 and the message recorded in step S1750. At this time, the virtual time of the mechanical simulator 1530 is 880 ms when the synchronization request message is notified. As described in the first embodiment, it should be noted that each simulator waits until receiving a synchronization progress message or an end message after notifying the synchronization request message. Therefore, the message selection unit 1536 refers to the message having the latest virtual time not exceeding 880 ms. Referring to FIG. 19A, the message that does not exceed time 880 ms is the message 1910 at time 840 ms. That is, a message at time 840 ms is selected.

  In step S1752, an internal calculation for 10 ms is performed based on the message selected in step S1751. That is, the simulation execution unit 1532 of the mechanical simulator 1530 performs an internal calculation by setting the input of the motor drive start interrupt signal to Low included in the message 2010. Here, the virtual time advances to 890 ms by internal calculation (see 1801 in FIG. 18).

  In step S1753, it is determined whether the synchronization timing has been reached. The mechanical simulator 1530 does not reach the synchronization timing here because the next synchronization timing is the virtual time 960 ms. For this reason, the processing is continued again from step S1751.

  In the subsequent step S1751, a message (1910 in FIG. 19A) that does not exceed the virtual time 890 ms of the mechanical simulator is selected again. Based on the selected message, an internal calculation for 10 ms is performed, and the virtual time advances to 900 ms (see 1802 in FIG. 18). Again, since the virtual time 960 ms, which is the synchronization timing, has not been reached, the processing from step S1751 is continued again.

  In subsequent step S1751, since the virtual time of the mechanical simulator is 900 ms, the selected message is the message 1920 in FIG. 19A having the latest virtual time not exceeding the virtual time 900 ms.

  That is, the mechanical simulator 1530 performs an internal calculation for 10 ms by switching the motor drive start interrupt signal from low to high from the virtual time of 900 ms (step S1752).

  Thereafter, steps S1751 to S1753 are repeated until the next synchronization timing, which is the virtual time of 960 ms, and the simulation calculation operation ends.

  By such an operation, the mechanical simulator 1530 can accept a desired signal as shown in FIG. 19 (b-2) with respect to the output signal of the software simulator 1550 shown in FIG. 19 (b-1). . FIG. 19B shows that the delay of the motor drive interrupt signal of the mechanical simulator is smaller than that in FIG. 13B described in the first embodiment.

  According to the present embodiment, it is possible to provide a simulation device that eliminates missing and reduces delay.

  In the fourth embodiment, the mode effective when the internal calculation interval is smaller than the synchronization interval has been described. However, when the internal calculation interval is not sufficiently smaller than the synchronization interval, a situation occurs in which the overwriting occurs.

  For example, in the case of a simulator having synchronization timing and internal calculation timing as shown in FIG. Here, the software simulator described in the fourth embodiment assumes that only the synchronization timing of 900 ms is shifted to 940 ms. In other words, the motor simulator interrupt signal becomes high for the first time at a virtual time of 940 ms, and the software simulator returns to low after 960 ms. Further, it is assumed that the internal calculation of the mechanical simulator is performed in units of 40 ms as shown in FIG.

  In FIG. 20, the mechanical simulator receives an output signal at time 940 ms from the software simulator at time 880 ms. Similar to the fourth embodiment, the mechanical simulator performs a simulation calculation using the output signal of the software simulator at time 840 ms from the outside. The mechanical simulator wants to advance the calculation using the output signal at the time 940 ms of the software simulator from the time when the time 940 ms has passed in advance of the internal calculation. However, since the mechanical simulator shown here advances the internal calculation at timings of 880 ms, 920 ms, and 960 ms, the next synchronization timing is 960 ms after 940 ms. At time 960 ms, the output signal at time 960 ms is newly notified from the software simulator, so the signal at 940 ms is missed.

  In the fifth embodiment, a simulation apparatus is provided that prevents missing even in such a case.

<Description of configuration>
FIG. 21 shows a configuration diagram according to the fifth embodiment. Compared with the configuration shown in FIG. 15 of the fourth embodiment, the message selection unit is removed from each simulator, and processing method designation units 2136 and 2156 and processing units 2137 and 2157 are added to each simulator.

  Since each configuration shown in FIG. 21 can perform the same processing as that described in the fourth embodiment, a duplicate description is omitted.

  The processing method designating units 2136 and 2156 designate a method for processing a message used for the simulation calculation in order to prevent missing.

  The processing units 2137 and 2157 process a message used for simulation calculation in order to prevent missing.

  As in the case of the fourth embodiment, two simulators are used for simplicity of explanation.

<Description of operation>
The operation procedure in the present embodiment will be described. First, the preparatory operation flow is performed as in the fourth embodiment. The flow of the flow can be the same processing as the flowchart of FIG. 4 described in the first embodiment. However, the present embodiment is different from the processing of the first embodiment in that the processing method is specified not on the simulator management unit but on each simulator side.

  Next, the operation flow of simulation execution will be described. The operation flow of the simulation execution of the fifth embodiment is the same as that shown in FIG. 16 of the fourth embodiment. However, the operation of the simulation calculation performed in step S1603 is different. FIG. 22 shows a detailed flow of the operation performed in step S1603 in the fifth embodiment. Details of the simulation calculation processing will be described with reference to FIG.

  In step S2250, each simulator records the notified simulation progress message in the message recording units 2134 and 2154. At this time, a parameter indicating that the message is not used is included in the message to be recorded. “Unused” indicates that it is not used as a message used for internal calculation in the subsequent simulation internal calculation step S2252. Conversely, the message used for the internal calculation holds a parameter indicating used. Details will be described later.

  In step S2251, the processing units 2137 and 2157 of each simulator process the message. Check whether there is a message to be processed as preparation before processing. This confirmation is equivalent to the processing in which the unreported message is replaced with unused and the notified message is replaced with used in step S708 of FIG. 7 described in the first embodiment. That is, message processing is performed by extracting processing objects based on the following two conditions. The first condition is a message having a virtual time earlier than the virtual time of the simulator on the message receiving side. The second condition is only a message that holds a parameter that means unused. If there are two or more messages that satisfy these two, process the two or more messages. If the number is less than 1, no processing is performed. The processing is performed based on the method specified in the preparatory operation flow. Note that, in this embodiment, unlike the first embodiment, internal calculations in each simulator are considered. That is, in this embodiment, it should be noted that the virtual time of the simulator on the receiving side of the first condition is changed by an internal calculation.

  In step S2252, the message to be used for the internal calculation is determined as in the fourth embodiment. The determination of the message differs depending on whether or not processing has been performed in step S2251. When processing is performed, the processing result is selected as an input signal. When the processing is not performed, as in the fourth embodiment, a message that does not exceed its own virtual time among the messages recorded by the message recording units 2134 and 2154 is selected as an input signal. The message to be processed or the selected message is overwritten with a parameter indicating that it has been used.

  In step S2253, internal calculation is performed based on the input signal determined in step S2252.

  In step S2254, it is determined whether or not the virtual time has reached the synchronization timing as a result of the simulation calculation in step S2253. When it reaches, the simulation calculation is terminated, and the process proceeds to step S1604. If not, the process returns to S2251 and repeats the same operation.

  As described above, every time an internal operation is performed, if there is a signal to be missed in the message to be adopted as the input signal, the message can be prevented from being missed.

<Specific operation>
A specific operation will be described.

  As in the first embodiment, the processing method for each signal is specified in advance by the processing method specifying units 2136 and 2156 of each simulator. Here, the maximum value is designated as in the first embodiment. Similarly to the fourth embodiment, it is assumed that the simulation has progressed to the virtual time 880 ms for the mechanical simulator 2130 and the virtual time 900 ms for the software simulator 2150. That is, it is assumed that each simulator has been operated up to the time when the simulator management unit 2110 is notified of the synchronization request message at these virtual times, and the subsequent processing will be described. The synchronization timing and calculation interval are as shown in FIG.

  In step S2250, the mechanical simulator 2130 receives the simulation progress message including the output signal of the virtual time 940ms from the software simulator 2150 at the virtual time 880ms as in the fourth embodiment (2108). The received message is recorded in the message recording unit 2134. FIG. 23A is a diagram showing the recorded contents of the message at the time 940 ms of the mechanical simulator. At this time, as shown in FIG. 23A, the message to be recorded includes a parameter (2304) indicating that it is not used. As shown in FIG. 20, the signal (2301) of the virtual time 840 ms of the software simulator 2150 is notified when the mechanical simulator 2130 is time 800 ms (2307). Therefore, since it has already been used in the internal calculation at the time 840 ms (2302) of the mechanical simulator, a parameter indicating that it has been used is recorded in FIG.

  In step S2251, the message recorded in step S2250 (that is, the message shown in FIG. 23A) is processed. However, there is no unused message which is the first condition and below time 880 ms and which is the second condition. Processing is not performed because there is no message to be processed.

  In step S2252, an external input signal message used for subsequent simulation internal computation is determined. Since no processing has been performed in S2251, a message (2301 in FIG. 23A) at 840 ms recorded in the message recording unit 2134 is determined.

  In step S2253, the simulation internal calculation is performed using the message 2301 determined in step S2252. That is, the low value is used for the simulation calculation as the motor drive start interrupt signal. The calculation is performed according to FIG. 20, and the virtual time advances to 920 ms (2001).

  In step S2254, it is determined whether or not the synchronization timing has been reached. The next synchronization timing of the mechanical simulator 2130 is 960 ms, and since the current virtual time is 920 ms, the synchronization timing has not been reached. For this reason, the processing from step S2251 is repeated again.

  In subsequent step S2251, the message is processed. Even at the virtual time 920 ms of the mechanical simulator 2130, the processing is not performed because there is no message that satisfies the first condition, ie, the time 920 ms or less, and the second condition that is not used.

  In the subsequent step S2252, a message (2301 in FIG. 23A) of the time 840 ms recorded in the message recording unit 2134 is determined in the same manner.

  In the subsequent step S2253, similarly, the simulation internal calculation is performed using the message determined in step S2252. That is, the low value is used for the simulation calculation as the motor drive start interrupt signal. The calculation is performed according to FIG. 20, and the virtual time advances to 960 ms (2004).

  In step S2254, it is determined whether the synchronization timing has been reached. Here, since the synchronization timing has been reached, the simulation calculation process is terminated.

  Subsequently, the mechanical simulator 2130 notifies the synchronization request message as before (step S1605). Subsequently, the simulator management unit 2110 records the notified synchronization request message (step S1606). Subsequently, a simulation progress message is notified to the software simulator 2150 by comparing the virtual time 960ms of the mechanical simulator 2130 and the virtual time 940ms of the software simulator (step S1607) (S1610).

  Subsequently, the software simulator 2150 that has received the simulation progress message performs a simulation calculation and advances to the virtual time 960 ms which is the next synchronization timing (step S1603). When the time 960 ms is reached, the software simulator 2150 notifies the simulator management unit 2110 of a synchronization request message (step S1603). Upon receiving the notification of the synchronization request message, the simulator management unit 2110 records the notified message in the message recording unit 2112 (step S1605).

  In step S1607, the simulator management unit 2110 compares virtual times. Here, since both the mechanical simulator 2130 and the software simulator 2150 hold the virtual time of 960 ms, both simulators are specified as the slowest progressing simulator.

  In step S1610, a simulation progress message is notified to both the mechanical simulator 2130 and the software simulator 2150.

  The following description will be given focusing on the mechanical simulator 2130. In step S2250 in the detailed processing of FIG. 22 (FIG. 22), the message notified from the simulator management unit 2110 is recorded in the message recording unit 2134. The message recorded here is shown in FIG. As shown in FIG. 23 (b), a software simulator virtual time 960ms message (2309) is added from FIG. 23 (a). In addition, a parameter indicating unused is recorded (2310).

  In step S2251, the message is processed. First, a processing target is extracted with reference to FIG. There are two unused messages of the first condition, the virtual time 960 ms or less, and the second condition, a time 940 ms (2307) and a time 960 ms (2309). Since there are two target messages, the message is processed based on the processing method specified in the predefined process. Here, the values of the motor drive start interrupt signal at each time are High (2308) and Low (2309), and since the maximum value is specified as the processing method in advance, it is processed to High. Is done.

  In step S2252, the message for the input signal used for the simulation internal calculation that follows is determined. Here, the processed motor drive start interrupt signal High is selected.

  Also, since the messages at time 940 ms (2307 in FIG. 23B) and time 960 ms (2309 in FIG. 23B) have been processed, unused (2308 and 2310 in FIG. 23B) become used. Update.

  If the same processing is continued, the mechanical simulator 2130 advances to time 1000 ms by internal calculation (see 2305 in FIG. 23). At this time, since there is no message to be processed, a message of time 960 ms that does not exceed time 1000 ms is used for internal computation. That is, the motor drive start interrupt signal Low is used for internal calculation.

  With such an operation, when the software simulator 2150 outputs the signal shown in FIG. 23 (c-1), the mechanical simulator 2130 receives the desired signal shown in FIG. 23 (c-2). The target is not missed.

  Further, as in the second and third embodiments, the user can confirm the message and the processing result that have been overlooked using the screens as shown in FIGS. 14 (a) and 14 (b).

  The simulation apparatuses shown in the fourth and fifth embodiments have an advantage that the timing delay can be reduced depending on the internal calculation interval as compared with the first embodiment. On the other hand, there is a disadvantage that it is necessary to incorporate a mechanism for managing and processing messages individually for the target simulator. Message management / processing on the simulator side shown in the fourth and fifth embodiments is referred to as a message adjustment function. In particular, a commercially available simulator is difficult to improve, and a simulator that can be incorporated and a simulator that cannot be incorporated may coexist.

  In view of this possibility of mixing, it is desirable that the user can select a suitable simulation configuration. Therefore, in this embodiment, a simulation apparatus capable of selecting a simulation configuration according to a simulator with which a user cooperates will be described.

<Description of configuration>
FIG. 24 shows an example of the configuration of this embodiment. In the example of FIG. 24, unlike the mechanical simulators (1530 and 2130) shown in the fourth and fifth embodiments, the mechanical simulator 2430 does not have a message selection unit, a processing method designation unit, and a processing unit. On the other hand, the software simulator 2450 has the same configuration as the software simulator 2150 shown in the fifth embodiment. That is, the mechanical simulator 2430 does not correspond to the configurations of the fourth and fifth embodiments, and the software simulator 2450 corresponds to the configuration of the simulator shown in the fifth embodiment.

  In the following description, a simulator that supports either of the configurations of the fourth and fifth embodiments is referred to as a supported simulator, and a simulator that does not support it is omitted as an unsupported simulator.

  The simulator management unit 2410 includes a switching unit 2417 in addition to the configuration described in the first embodiment. The simulator management unit 2410 switches the message management method to the operation of the message recording unit 312 shown in the first embodiment or the message recording unit 2112 shown in the fifth embodiment by a switching unit 2417 described below.

  The switching unit 2417 switches the message managed by the message recording unit 2412 depending on whether or not each of the linked simulators has been supported. For example, the message recording unit 2412 notifies the unsupported simulator of a message after processing by the processing unit 2415 in order to prevent missing. If the simulator has not yet been sent, a notification is sent to the corresponding simulator. For supported simulators, the message is processed on the simulator side or used for internal computation.

  Specific operations will be described in the following description. Note that the number of simulators is not limited to two as described above.

<Description of operation>
First, the preparatory operation flow will be described. The operation flow in the sixth embodiment is the same as the flow shown in FIG. However, there are some different processes. In the following, different processes will be mainly described.

  In this embodiment, each simulator notifies the simulator management unit 2410 of a simulation participation request message in step S403. The participation request message includes a parameter (SIM_COR) indicating whether or not its own simulator has been supported. FIG. 25 is an example of a participation request message. As shown in FIG. 25, the participation request message includes a parameter (SIM_COR) 2501 indicating whether or not it has been handled. FIG. 25A shows that the mechanical simulator 2430 is not supported (SIM_COR = FALSE), and FIG. 25B shows that the software simulator is supported (SIM_COR = TRUE). In this way, each simulator notifies the simulator management unit 2410 whether or not it has been handled.

  In step S406, a processing method is designated. In this embodiment, the machining method is designated by both the machining method designation unit 2416 of the simulator management unit 2410 and the machining method designation unit 2456 of the software simulator 2450. If there are multiple compatible simulators, the processing method is specified for all the simulators.

  FIG. 26 is a diagram illustrating an operation flow of the simulation execution according to the sixth embodiment. Steps S2601 to S2607 are the same operation flow as steps S1601 to S1607 of FIG. 16 described in the fifth embodiment.

  In step S2612, the simulator management unit 2410 switches whether or not the next message processing step S2608 is performed depending on whether or not the slow progressing simulator specified in step S2607 has been supported. If it has already been handled, no processing will be performed on the simulator to manage message loss. If it is not supported, the message is processed by the processing unit 2415 in order to prevent the simulator management unit 2410 from missing it. The processing operation is the same as in the first embodiment.

  Steps S2609 and S2611 are the same processes as steps S1609 and S1611 of FIG. 16 described in the fifth embodiment.

  In step S2610, the simulator management unit 2410 notifies each simulator of a simulation progress message. However, the message to be notified is switched by the switching unit 2417. As shown in the fourth and fifth embodiments, all the unsent messages are notified to the supported simulators, regardless of the virtual time of the messages. If not supported, the latest message not exceeding the virtual time of the notification destination simulator is notified as shown in the first embodiment.

  The operation of the simulation calculation is switched depending on whether or not the simulator that has received the notification of the simulation progress message is already supported. If the simulator is already compatible, the same simulation calculation as in the fourth or fifth embodiment is performed. If not supported, the simulation calculation is performed without switching the message used for the internal calculation in the same way as in the first embodiment.

  Switching is realized by the above operation.

<Specific operation>
A specific operation will be described focusing on a message for notifying the mechanical simulator 2430 of the output signal of the software simulator 2450, taking as an example the case where synchronization and internal calculation are performed at the timing shown in FIG. Here, it is assumed that the mechanical simulator 2430 synchronizes every 200 ms, the software simulator 2450 synchronizes every 60 ms, and the mechanical simulator 2430 performs internal calculation at intervals of 50 ms. It is also assumed that the software simulator outputs a motor drive start interrupt signal at high only at time 900ms and outputs low at other times. Furthermore, similarly to the description so far, the case where the maximum value is specified as the processing method will be described as an example.

<When the mechanical simulator is not supported>
The case where the mechanical simulator 2430 is not supported will be described by focusing on the simulation progress message notified at the time 1000 ms of the mechanical simulator 2430.

  At this time (2705 in FIG. 27), the message notified from the software simulator 2450 recorded in the message recording unit 2412 of the simulator management unit 2410 in step S2605 is shown in FIG.

  In step S2612, since the mechanical simulator 2430 is not supported, the subsequent message is processed in step S2608.

  In step S2608, first, the simulator management unit 2410 extracts a message to be processed from the contents of the message recording unit 2412 shown in FIG. Here, three output signals at time 840 ms (2802), 900 ms (2803), and 960 ms (2804) of the software simulator 2450 are to be processed. Since the signal values are Low, High, and Low in this order, they are processed to the maximum value, High.

  In subsequent step S2610, the mechanical simulator 2430 is notified of the message processed in S2408. That is, the mechanical simulator 2430 can receive the High value as the motor drive start interrupt signal and proceed with the simulation.

<When the mechanical simulator is already supported>
Next, the case where the mechanical simulator is already supported will be described. Here, a description will be given focusing on a simulation progress message and a simulation calculation operation notified at the time 800 ms (2701 in FIG. 27) and 1000 ms (2705 in FIG. 27) of the mechanical simulator 2430.

  At the virtual time 800 ms (2701 in FIG. 27) of the mechanical simulator 2430, since the mechanical simulator 2430 has already been supported in step S2612, the simulator management unit 2410 proceeds to the next step without processing the message.

  In step S2710, the simulator management unit 2410 notifies the mechanical simulator 2430 of an unreported message at time 840 ms. At this time, the parameter indicating that the message of time 840 ms is not transmitted is overwritten with the notification. Thereafter, the same operation as in the fifth embodiment is performed.

    As described above, according to the present embodiment, an optimum configuration can be provided in accordance with the simulator to be linked.

Claims (12)

A simulation device that links a plurality of simulators,
Recording means for recording messages transmitted from the plurality of simulators;
A parameter indicating whether or not the message recorded in the recording means has been notified to another simulator associated with the message , based on the difference between the synchronization interval of the other simulator and the synchronization interval of the simulator from which the message is transmitted Processing means for processing a message recorded in the recording means based on parameters ;
A simulation apparatus comprising: a transmission unit configured to transmit the processed message to another simulator that cooperates.   The simulation apparatus according to claim 1, wherein the processing unit performs the processing at the time of receiving synchronization request messages from the plurality of simulators.   The simulation apparatus according to claim 1, wherein the transmission unit transmits the processed message in response to a synchronization request message transmitted from each simulator.   The processing means has two or more messages having a parameter indicating that notification is not made to other linked simulators among messages having a virtual time before the virtual time of the simulator that receives the processed message. The simulation apparatus according to claim 3, wherein the processing is performed on the two or more messages.   The simulation apparatus according to claim 4, wherein the processing unit processes a value included in the two or more messages into a common value.   The simulation apparatus according to claim 4, wherein the processing unit changes the parameter of the processed message to “notified”.   The simulation apparatus according to claim 1, further comprising a processing method specifying unit that specifies a processing method by the processing unit.   The simulation apparatus according to claim 1, further comprising a presentation unit that presents the content processed by the processing unit. A simulation device that links a plurality of simulators,
Recording means for recording messages transmitted from the plurality of simulators;
A determination means for determining whether or not the simulator to which the recorded message is notified has a function of adjusting the notified message;
When notifying the message in response to the synchronization request message from the simulator determined to have no adjustment function of the message in the determination means,
This is a parameter indicating whether or not the message recorded in the recording means has been notified to another simulator to be linked, and the difference between the synchronization interval of the other simulator and the synchronization interval of the simulator of the message transmission source Processing means for processing a message recorded in the recording means based on a parameter based thereon;
A simulation apparatus comprising: a transmission unit configured to transmit the processed message to another simulator that cooperates. The simulation apparatus according to claim 9 , wherein the determination unit performs the determination based on a parameter included in participation request messages from the plurality of simulators. A simulation method for linking multiple simulators,
A recording step of recording messages transmitted from the plurality of simulators;
A determination step of determining whether or not the simulator to which the recorded message is notified has a function of adjusting the notified message;
When notifying the message in response to the synchronization request message from the simulator that has been determined not to have the message adjustment function in the determination step,
This is a parameter indicating whether the message recorded in the recording step has been notified to other simulators that cooperate with each other, and the difference between the synchronization interval of the other simulator and the synchronization interval of the simulator from which the message is transmitted A processing step for processing the message recorded in the recording step based on a parameter based thereon;
And a transmission step of transmitting the processed message to another simulator that cooperates.   The program for functioning a computer as a simulation apparatus as described in any one of Claims 1-10.

Images