WO2013099438A1 - 協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム - Google Patents

協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム Download PDF

Info

Publication number
WO2013099438A1
WO2013099438A1 PCT/JP2012/078396 JP2012078396W WO2013099438A1 WO 2013099438 A1 WO2013099438 A1 WO 2013099438A1 JP 2012078396 W JP2012078396 W JP 2012078396W WO 2013099438 A1 WO2013099438 A1 WO 2013099438A1
Authority
WO
WIPO (PCT)
Prior art keywords
simulators
simulation
test
simulator
computer system
Prior art date
Application number
PCT/JP2012/078396
Other languages
English (en)
French (fr)
Inventor
康宏 伊藤
深野　善信
Original Assignee
日立オートモティブシステムズ株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Publication of WO2013099438A1 publication Critical patent/WO2013099438A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/26—Functional testing
    • G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation

Definitions

  • the present invention relates to a computer system for co-simulation, an embedded system verification method, and a program, and more particularly to a co-simulator technology suitable for development of an embedded system composed of a mechanism, hardware, and software.
  • An embedded system is a mechanism that configures a control target, Hardware that performs control calculations based on physical quantities received from this mechanism and outputs control values to this mechanism; It is a system composed of software that operates on this hardware.
  • an embedded system for automobile engine control is It is composed of a mechanism such as an engine to be controlled, an electronic device such as a microcomputer that performs control calculations and controls the engine, and software that operates on the microcomputer.
  • Patent Document 1 discloses a technique for efficiently simulating a system having a plurality of different types of ECUs in terms of software.
  • each simulator operates independently, so it is difficult for the user to describe the dependency relationship as described above.
  • event operations and trigger exchanges between computers of multiple simulators of different types, such as domains must be communicated via the central part of the system. It was difficult to analyze the abnormal state by operating at an arbitrary timing.
  • Patent Document 1 does not disclose that a user arbitrarily inserts a disturbance condition or adds a mechanism for observing an internal state to each simulator.
  • the user operates the internal state of each simulator (data processor) via a central user interface processor.
  • each simulator data processor
  • the problem was that the desired simulation results could not be obtained.
  • the management software can test the test items according to the test description. It is desirable to execute without changing the order.
  • the object of the present invention is that the execution order of each of these operations is different from the insertion of external conditions and the internal state operations given to the simulator by a user for a cooperative simulation in which a plurality of independent different types of simulators operate in cooperation.
  • the computer system for cooperative simulation of the present invention includes a plurality of simulators that operate in cooperation and a simulation integrated controller that controls the plurality of simulators to be verified, and the simulation integrated controller and each of the simulators are connected by asynchronous communication. Shares the function of pausing and resuming the overall operation of the plurality of simulators, and when the stop condition set in any one of the simulators is satisfied, pauses the whole of the plurality of simulators, During the pause, the state of the at least one simulator is acquired or the state is rewritten.
  • the behavior of the verification target system can be improved. It is possible to make it easy to grasp.
  • FIG. 1 It is a functional block diagram which shows the example of a whole structure of the computer system for cooperative simulation which becomes a 1st Example of this invention. It is a figure which shows the structural example of the test progress control part of FIG. It is a figure which shows the example of a structure of the verification object simulation of FIG. 1, especially the test probe part which operate
  • ECU electronice control unit
  • FIG. 4A It is a figure which shows the structural example of the calculation cluster for cooperative simulation shown in FIG. 4A. It is a figure which shows an example of the connection system between the test probe supported by the system of this invention, and an object model. It is a figure which shows the structural example of the common communication protocol used with the system of this invention. It is a figure which shows the structural example of the description format of a test item and the description format of a test result used with the system of this invention. It is a figure which shows the structural example of the structure specification description format in the simulation used as the application object of this invention. It is a figure which shows the structural example of the format for describing the kind of command which performs operation, a trigger, and observation which can be utilized by this system.
  • the present invention can be applied to a computer system or a development system program in which a plurality of softwares operate in conjunction with each other.
  • a computer system for cooperative simulation includes one simulation integrated controller and a plurality of simulators to be verified that are connected to the simulation integrated controller via an asynchronous network and operate independently. It is configured.
  • Each simulator to be verified includes a test probe unit.
  • the simulation integrated controller includes a test progress control unit that communicates with each verification target simulator asynchronously.
  • the test probe units of a plurality of simulators and the test progress control unit of one simulation integrated controller share a function of temporarily suspending / resuming the operation of the entire simulator.
  • a virtual delay time is inserted into this data communication part. This stops the operation of the corresponding simulator.
  • the linked simulators are stopped in a chain.
  • the internal state can be manipulated at a designated timing in each simulator without causing communication with the central simulation integrated controller. That is, when the stop condition set for any of the simulators is satisfied, the state of each simulator is acquired or the state is rewritten after all the simulators are stopped.
  • all the simulators are temporarily stopped so that the execution order of each operation is not switched between external condition insertion and internal state operation. It becomes possible to execute.
  • a computer system for cooperative simulation constitutes a virtual verification environment (this system) in which a plurality of machine / sensor system (mechanical system) simulators and a microcomputer system simulator operate in cooperation. is doing.
  • the machine / sensor simulator corresponds to various devices / members to be controlled, such as various actuators that operate in response to commands and sensors that detect the state thereof. It corresponds to a microcomputer for controlling based on commands and sensor information.
  • FIG. 1 shows an overall configuration example of a computer system for cooperative simulation according to a first embodiment of the present invention. That is, FIG. 1 is a functional block diagram of a computer system that enables operation and observation of an internal state in a simulation environment that operates in cooperation between a plurality of simulators.
  • a computer system 10 for co-simulation includes a simulation integrated controller 100 and a plurality of simulations to be verified 104 (1) to 104 (N) connected to the simulation integrated controller via an asynchronous network 103. Yes.
  • the simulation integrated controller 100 includes a test progress control unit 101, a database (DB) 120 that holds data relating to test items and the like, an input unit 107, and an output unit 108.
  • the test progress control unit 101 of the simulation integrated controller 100 receives the test item description 0100 of the user via the input unit 107, and instructs each simulation 104 (1) to 104 (N) to execute the test item.
  • the test result 0102 of the test item is output to the output unit 108.
  • test progress control unit 101 is connected to each test probe unit 106 (0 to M) operating inside each verification target simulation 104 (1) to 104 (N) through an asynchronous network 103.
  • each simulation 104 connected via the data exchange network 111 includes models 105 (0) to 105 (0) to be verified.
  • 105 (N) exists.
  • One or a plurality of test probe units 106 can be connected to each verification target model 105.
  • FIG. 2A shows a configuration example of the test progress control unit 101 constituting this system.
  • the test progress control unit 101 receives a test item format 0100 described by a user according to a predetermined rule, and stores a test item interpretation unit 1010 that interprets the test item format 0100 and interprets the test item format and executes it in order.
  • Item queue 1011 is connected to multiple test probes in the system, and communication I / F unit 1012 for exchanging test items, test results, trigger establishment events, etc., and execution results of each test item And an expected value described in the test item format 0100, and an expected value determination unit 1013 that outputs the result as the test result 0102.
  • the communication I / F unit 1012 includes a packet communication control function 10120, and performs packet communication using a system common protocol between the test progress control unit 101 and each verification target simulation 104 (x).
  • FIG. 2B shows a configuration example of the verification target simulation 104, in particular, the test probe unit 106 that operates inside the simulation.
  • the test probe unit 106 operates as a virtual simulation model that operates within the verification target simulation 104, and is connected to the target model 105 to be operated and observed by the data communication method provided by each simulator. Yes.
  • the test probe unit 106 is connected to the test progress control unit 101 via the asynchronous network 103, receives test items, accumulates them as a test item queue 1064, and returns the results of executed test items and trigger establishment timings.
  • Communication I / F 60 1060, command interpreter 1061 for reinterpreting test items into events that can be executed by each simulator, and commands for executing the interpreted commands on the target model 105 that is actually connected The execution unit 1062 and a stop code insertion unit 1063 that intervenes in the inter-simulator data communication 111 to which the target model 105 is connected to stop the execution of the simulation.
  • FIG. 3A shows a physical configuration example of an embedded system for automobile engine control, which is a verification target of this system.
  • the basic configuration of this embedded system is an electronic control unit that performs control corresponding to the mechanical system / sensor system module 200 such as the engine 201, the brake 202, the user operation panel 203, and the vehicle body posture control system 204.
  • 210 includes an engine ECU 211, a brake ECU 212, a user interface ECU 213, and a steering ECU 214, which are connected via the in-vehicle network 230, and control is established.
  • the in-vehicle network may have a central node as the in-vehicle communication controller 220.
  • FIG. 3B is a diagram showing a basic configuration of each ECU (211-214) of the electronic control unit 210.
  • Each ECU is equipped with one or a plurality of microcontrollers 2101 serving as a base for controlling the ECU, and these are connected to an analog IO 2102 and a dedicated IC 2103 for connection to a mechanical system or sensor.
  • each ECU includes a communication interface 2104 for connection with other ECUs, and is connected to the in-vehicle network 230.
  • the in-vehicle communication controller 220 also includes a microcontroller, a communication interface, and the like.
  • FIG. 4A illustrates a simulator environment to be verified for reproducing the operation of the embedded system for automobile engine control in FIG. 3A on the cooperative simulation environment.
  • the mechanical system parts and modules such as the engine 201, the brake 202, the user operation panel 203, and the vehicle body posture control system 204 in FIG. 3A are emulated by the machine / sensor system simulators 10401, 10402, 10403, and 10404, respectively, and the electronic control unit
  • the engine ECU 211, the brake ECU 212, the user interface ECU 213, and the steering ECU 214 are emulated by the microcomputer simulators 10411, 10412, 10413, and 10414, respectively.
  • the in-vehicle network 230 and the in-vehicle communication controller 220 that have been connected to these ECUs are emulated by the in-vehicle network 160 and the communication simulator 10420, thereby reproducing the entire cooperative operation.
  • a CAN Controller Area Network
  • Each simulator constituting such a simulator to be verified is connected to the simulation integrated controller 100 via the asynchronous network 103.
  • the simulation integrated controller 100 functions as a user interface for the verification target simulator.
  • the machine / sensor system simulators 10401, 10402, 10403, 10404, the microcomputer simulators 10411, 10412, 10413, 10414, and the communication simulator 10420 may be partly or entirely the same type of simulator, or all of them may be Different types of simulators may be used.
  • different types of simulators refer to physical systems that are targeted by the simulator, that is, physical systems, mechanical systems, electronic systems, and the like that have different target “domains”.
  • the “domain” is the same, the simulator manufacturer is different, and even if the manufacturer is the same, if the creation time (version) is different, the type of simulator is different.
  • the program language C language, Java (registered trademark), Python, Ruby, etc.
  • the types of simulators are also different.
  • FIG. 4B shows an example of the configuration of a computer suitable for executing the computer system 10 for co-simulation shown in FIG. 4A.
  • This simulation in which a plurality of simulators are linked, causes a dramatic decrease in the simulation speed due to the concentration of the load when operated by a single computer and the cost of execution while replacing the plurality of simulators. Therefore, it is desirable to use a cluster type computer system in which a plurality of computers 1101 are connected by a network 1102 in this simulation.
  • the network connecting the computers may be a centralized network that gathers all the computers together, or a crossbar connection network in which any two computers are strongly connected.
  • FIG. 5 describes an example of a connection method between the test probe 106 and the target model 105 supported by this system.
  • the connection method depends on the simulator on which the target model 105 operates, its implementation method is different, but it is classified to some extent.
  • the connection method is divided into an output type and an input type bus type, and the output type is an analog output 500 that outputs a floating point value or an integer value, a digital output 501 that outputs only 0 or 1, and a clock signal.
  • a clock output 502 for communication is conceivable.
  • As an input type a digital input 503 for inputting only 0 or 1 and an analog input 504 for inputting a floating point value or an integer value are conceivable.
  • a possible bus type connection is a memory bus / communication interface 505.
  • This system has a common test item communication protocol 0600 for the purpose of executing test items that does not depend on the type of simulator included in the target co-simulation.
  • FIG. 6 shows a configuration example of a common communication protocol 0600 of the present system exchanged between the test probe unit 106 and the test progress control unit 101.
  • This communication protocol 0600 has a test description format for handling event operations and triggers in all simulators in the same way.
  • This communication protocol can have a variable-length instruction sequence.
  • Arg1 field 0605 and arg2 field 0606 in FIG. 6 are variable length parts, and the number thereof is controlled by Index 0603. Other fields are fixed.
  • the ID field 0601 indicates which test probe 106 should execute the test item.
  • a Type field 0602 designates the type of the corresponding test item.
  • the Value field 0604 when the test item is an observation or trigger event, the execution result of the item is input.
  • the Timing field 0607 describes the simulation time for executing the test item, is transmitted from the test progress control unit 101, and is returned with the simulation time actually executed by the test probe unit 106 overwritten.
  • FIG. 7 shows a configuration example of the format 0700 of the test item format 0100 and the test result 0102.
  • format 0700 which combines the format of test item format 0100 and test result 0102, is shown for the purpose of improving the visibility of test item execution results, but in the actual configuration these are divided. Even if the shape is made, the effect is not lost.
  • the test items performed in this system are configured by one measurement trigger designation 0702 and one or a plurality of expected value designations 0703 for one test item 0701.
  • Test item specification 0701 is line number 0701, test item name 0705, execution waiting time 0706 for specifying the time the system waits before executing the test item 0705, instruction 0707 indicating the specific operation of the test item, It is composed of setting values 0708 and 0709 that serve as arguments.
  • the measurement trigger designation 0702 is based on the trigger type instruction 0710, the set value 0711 as its argument, the comparison expression 0712 that specifies the trigger establishment condition, the elapsed time 0713 that the trigger establishment time is input, and the data value 0714 at that time Composed.
  • Expected value specification 703 is input when expected value type indication 0715 and its setting values 0716 and 0717, comparison expression 0718 specifying the trigger establishment condition, and value 0719 obtained when executing the expected value specification are input. It is constructed by a judgment field 0720 to which a judgment result of a comparison expression using is inputted. Even when the number of setting values of each item is different from that of the present configuration example, the test item communication protocol 0600 allows a variable number of setting values, so that the function is not affected.
  • FIG. 8 is a configuration example of a format 0800 for describing the changeable state and variables in the simulation 104 to which the present system is applied and the connection relationship between the test probes 106 to which the system is connected.
  • Examples of information included in this format include a pin number field 0801 that is an identifier on a variable system, a pin name field 0802 that is an identification name on a test item format 0100, and a test probe 106 for the pin.
  • An interface type field 0803 indicating the type of the pin
  • a function field 0804 indicating the approximate function of the pin
  • a test probe ID field 0805 indicating the ID of the test probe 106 to which the pin is connected
  • the test probe index field 0806 indicating the interface pin number with the target model 105 to which is connected.
  • FIG. 9 shows a configuration example of format 0900 for describing the types of commands that execute operations, triggers, and observations that can be used in this system.
  • the command-name field indicates the identification name on the system of the command.
  • the setting value fields 0902, 0903, 0904, 0905, and 0906 describe the number and type of arguments that each command can have. Since commands supported by this system can have variable-length arguments, the setting value field of this format can have a variable-length size. Each set value can have a plurality of types.
  • FIG. 10 shows a format 1000 for describing the correspondence between the identification name on the test item format 0100 of the command described in the command format 0900 of FIG. 9 and the command type.
  • the format 1000 includes a command type field 1001, a command identification name 1002 on the sheet, and a command identification name 1003 on the system as information.
  • the test item format 0100 is divided into a test operation, a trigger operation, and an expected value operation, and commands that perform individual operations are assigned.
  • the type is set so that (name 1002 + command type 1001 on the sheet) corresponds to the command identifier on the system.
  • FIG. 11 is a diagram showing an operation flow relating to characteristic functions of the computer system for co-simulation of this system.
  • This function inserts a disturbance condition or observes the internal state by interrupt processing based on the condition set by the user during the cooperative simulation.
  • the user can pause the entire simulator, and acquire or rewrite the state of at least one simulator during the suspension.
  • the user describes the test specifications in advance according to the determined rules, and creates the test item format 0100.
  • these data are input to the test progress control unit 101.
  • the format input format described in FIGS. 7, 8, and 9 is displayed on the GUI screen of the input unit 107, and the user describes a test specification by inputting necessary items in a predetermined field. Input is made.
  • the test progress control unit 101 receives the test item format 0100, the test item interpretation unit 300 interprets the input test specification, and automatically generates the test item. Is converted into data corresponding to the test item communication protocol 0600 shown in FIG.
  • step 601 the timing for executing the test item is set. This timing is set based on the value initially set by user data for the first time, and based on the timing at which the previous test item was executed for the second time and thereafter.
  • step 602 the test item interpreted by the test item interpretation unit 300 is stored in the test item queue 0301.
  • step 603 the test item is taken out from the test item queue 0301.
  • step 603 one or more test items are extracted.
  • it is determined whether or not the command part of the test item to be transmitted is command designation. If the test item is command designation, the process returns to step 603, and if the type of the test item is a trigger system or a test operation system, the process proceeds to step 605.
  • test item to be transmitted to the test probe 106 is a trigger system, a test operation system (Get) system), a combination of trigger system + (one or more) command designation, or a test operation.
  • System + (one or more) command designation combination is a trigger system, a test operation system (Get) system), a combination of trigger system + (one or more) command designation, or a test operation.
  • System + (one or more) command designation combination is a trigger system, a test operation system (Get) system), a combination of trigger system + (one or more) command designation, or a test operation.
  • the ID part designation of the test item is read for one or a plurality of taken out test items, the communication socket of the communication I / F unit 0302 is selected, and the communication socket is selected.
  • the target test probe 106 is selected depending on the content of the test item, there may be a plurality of target test probe parts.
  • step 606 the transmitted test items are received by each test probe unit 106.
  • step 607 the timing field 0607 of the received test item communication protocol 0600 is read, compared with the current simulation time, and if the read execution time is larger than the current simulation time, the process branches to step 608, If the value is smaller, the process branches to step 609.
  • step 608 the received test items are stored in the Event queue, wait until the designated time comes, and the process proceeds to step 609.
  • step 609 the command interpretation unit 1061 reads the Type field of the test item communication protocol, and assigns an operation / observation command defined in the command execution unit 1062.
  • step 610 the type of operation / observation command is read, and if the type is a trigger designation command (trigger system), the process branches to step 611, and other test operations and expected value systems (command designation). If it is a command, the process branches to step 614.
  • trigger system Trigger system
  • step 611 the operation / observation command assigned in step 609 is executed.
  • the arg fields 0605 and 0606 of the test item communication protocol are used as arguments of the function.
  • the result executed at this time is overwritten in the Value field 0604 of the test item communication protocol and the executed time stamp on the simulator is overwritten in the timing field 0607, and is generated as a response event.
  • step 612 the process waits until the trigger condition is satisfied and the trigger function is executed.
  • step 613 if the trigger condition is satisfied, that is, if the simulation stop condition is satisfied based on the condition given by the user, the process proceeds to step 613.
  • step 613 it is ensured that the time on the simulator has not progressed from the reception of the test item communication protocol to the steps so far.
  • the stop code insertion unit 403 is validated, and the inter-simulator communication 111 is stopped.
  • the entire simulation is stopped in a chain. That is, when the stop condition set for any one of the simulators is satisfied, the entire plurality of simulators are stopped in a chain.
  • step 617 the response event generated in the previous stage is sent back to the test progress control unit 101.
  • step 614 the trigger function designated by the trigger designation command is validated. That is, the test item is executed while the entire simulator is stopped, and the internal state of at least one simulator is acquired or the state is rewritten. The user can operate an internal state of an arbitrary simulator at a designated timing.
  • step 615 the infinite loop of the stop code insertion unit 1063 is released (step 616), and the entire cooperative simulation is resumed. That is, in step 616, when a stop cancellation command reserved in the Type field 0602 of the test item communication protocol is encountered, the stop code insertion unit 1063 is invalidated and the entire simulation is restarted.
  • the test progress control unit 101 waits for the arrival of the response Event from the event processor (step 618), and holds the timing, value, etc. inside the response event in the storage means (step 619).
  • step 620 the timing information based on the result of executing the event is acquired and stored in the storage means. The next execution timing is set based on this Timing information.
  • step 621 it is determined whether the event is the last event in the Event Queue. If not, the process returns to step 601, and when a specific simulator stop condition is satisfied, the entire simulator is stopped, and then one or more The internal state of the simulator is acquired or the state is rewritten. If it is the last event, the process ends as step 622.
  • the expected value determination unit 1013 of the test progress control unit 101 determines the information obtained and stored in the cooperative simulation and the expected value described in the test item format 0100, and outputs the result as the test result 0102. .
  • the test result is incorporated into the format of the format described in FIGS. 7, 8, and 9 and displayed on the GUI screen of the output unit 107.
  • FIG. 12 shows an example of the relationship between the “simulations to be applied” and the “priorities” of the processes to be set in the test specification written by the user.
  • There is a “brake mechanism”, and a “priority” for executing these simulations is defined.
  • Such test items are automatically generated in step 600 of FIG. 11 by interpreting the test specifications described in the test item format 0100, and these test items are stored in the test item communication protocol 0600 shown in FIG. The data is converted into applicable data and sent to the simulator probe of the corresponding IP address based on the “priority”.
  • FIG. 13 is a diagram outlining the structure in which the test probe 106 stops the simulation for the target model 105 connected thereto.
  • the simulators 104 (1) and 104 (2) included in the co-simulation environment are connected to each other by the inter-simulator communication I / F (1060), exchange data with a predetermined simulation time as a cycle, and the simulations cooperate. Works.
  • the stop code insertion unit 1063 of the simulator 104 (1) Interrupts (Stop 1) and guides the reception process to an infinite loop.
  • the cooperative simulation between the simulator 104 (1) and the simulator 104 (2) is stopped in a pseudo manner (stops 2 and 3).
  • This stopped state is not limited to the two simulations in the simulators 104 (1) and 104 (2). Since these simulators 104 (1) and 104 (2) are stopped, they are connected to each other. Data communication with other simulators 104 (3), 104 (4),-, 104 (n) will also be stopped there, and the entire progress will eventually stop in a chained manner within the operation period of the cooperative simulation. (Stop 4, 5, n)
  • the stop code insertion unit 1063 intervenes in the data synchronization communication unit of the simulator (inserts an interrupt) to generate a pseudo reception delay, thereby stopping a plurality of simulators in a chained manner.
  • the stop code insertion unit 1063 stops all of the plurality of simulators substantially simultaneously before the simulation result is affected by changing the order of the test items without communicating with all the simulators.
  • FIG. 14A shows an example of starting / stopping simulation corresponding to the test specification of FIG.
  • “priorities” are in the order of simulators A, D, B, C, and A. Therefore, the entire first simulation in the operation flow of FIG. 11 is set to the stopped state (S613), and in this state, the state of the simulator A (engine ECU) is acquired or the data is rewritten (S614, S615). During this time, all other simulations have stopped working. Thereafter, the entire simulation is restarted (S616), and the entire simulation is stopped in the next iteration cycle (S613). In this state, the state or status data of simulator D (brake mechanism) is acquired in the next cycle. (S614, S615).
  • the state of one simulator in the stopped state of each simulation, the state of one simulator is acquired and the data is rewritten.
  • the state acquisition and data are simultaneously acquired for a plurality of types of simulators. May be rewritten.
  • status acquisition and data rewriting may be performed simultaneously for the same type of simulator.
  • a failure can be given to one cylinder as a disturbance, and the state of how the other cylinders operate in association with the failure can be read and observed.
  • operations such as insertion of external conditions and observation of the internal state are performed individually in synchronization with the start and stop of the entire simulation, so the execution order of each operation does not change. That is, by providing the user with a function that allows the execution continuation condition to be injected at an arbitrary timing from the outside of the co-simulation, it is possible to easily grasp the behavior of the system to be verified.
  • the function for triggering the function for observing the state, and the internal state Since the function of giving disturbances to different types of simulators can be executed across different types of simulators, it is possible to reliably analyze an abnormal state derived from a complicated interrelation between components. In other words, it has a common test item communication protocol for the purpose of executing test items that does not depend on the type of simulator included in the target co-simulation, and allows test items to be executed across different simulators. Can do.
  • test progress control unit that communicates asynchronously with the test probe unit installed inside each simulator, and the test progress control unit shares the function of pausing and resuming the operation of the entire simulator, thereby inserting disturbance conditions.
  • test progress control unit shares the function of pausing and resuming the operation of the entire simulator, thereby inserting disturbance conditions.
  • FIG. 5 illustrates an example of a CAN connection method between the test probe 106 and the target model 105.
  • the target model 105 is a CPU model
  • a method of triggering a command for the command execution unit 1062 of another test probe 0106 from the trace of the CPU model is illustrated.
  • a command for the command execution unit 1062 of the probe of the mechanical simulator 10401 can be triggered from the communication simulator 10420 including the CPU model of FIG. 4A.
  • a task DB 1502 is generated and input in advance to the command execution unit 1062 of the test probe 106 by extracting the start and end addresses of each function from the linker information 1503 of the software executed by the CPU model 1500.
  • the software trace generation unit 1501 can detect the start and end of a function call on the CPU model 1500 by searching the task DB 1502 based on the PC trace received from the CPU model 1500.
  • the test progress control unit 101 can start command execution of the other test probe 106 in synchronization with the function call boundary.
  • the test progress control unit 101 can also have a function of enabling / disabling which function is started or ended, which trigger is generated.
  • the start and end of the function call on the CPU model 1500 is detected from the trace of the CPU model included in the target model 105, and the stop code insertion unit 1063 is detected by a command to the command execution unit 1062 of another probe. Is operated, and the operation of the emulator is stopped, so that the entire linked simulator is stopped regardless of the type of the simulator. Thereby, the user can inject the execution continuation condition at an arbitrary timing from outside the simulation, and it becomes easy to grasp detailed information about the entire embedded system and the mutual behavior between the components.
  • FIG. 5 illustrates an example of a connection method between the test probe 106 and the target model 105.
  • the target model 105 is a memory or the like
  • a method for triggering a command for another test probe 106 from a trace of a bus model included in the memory or the like is illustrated.
  • address information in the bus access trace is used.
  • bus type connection such as memory or communication appears.
  • bus access bus access
  • it is required to trace transactions exchanged via bus-type connections and to trigger on events synchronized with them.
  • a memory access trace generation unit 1603. In the command execution unit 1062 of the test probe 106, based on the memory space map information file 1605 in which the map information of the variables on the memory space is described in advance, the address DB 1604 as a correspondence table to the memory addresses of each variable is stored. Generate and enter.
  • the test progress control unit 101 can invalidate / enable a trigger for changing a specific variable in the memory for the test probe 106 for the memory test.
  • the target model 105 When a bus access 1600 occurs from the bus master device 1601 to the bus slave device 1602 in the target model 105, the target model 105 generates a bus access trace. Using the address information in the bus access trace, the memory access trace generation unit 1603 in the command execution unit 1062 searches the address DB 1604. When the trigger of the corresponding variable is enabled, a trigger establishment message is transmitted to the test progress control unit 101, and the command execution of the test probe 106 of another simulator can be started.
  • the trigger information of the variable is detected from the bus access trace generated by the target model 105, the stop code insertion unit 1063 is operated by a command for the command execution unit 1062 of another probe, and the simulator By stopping the operation, the entire linked simulator is stopped regardless of the type of the simulator. Thereby, the user can inject the execution continuation condition at an arbitrary timing from outside the simulation, and it becomes easy to grasp detailed information about the entire embedded system and the mutual behavior between the components.
  • In-vehicle network 0600 ... Communication protocol, 1010 ... Interpretation of test items 1011 ... Test item queue, 1012 ... Communication I / F unit, 1013 ... Expected value determination unit, 1060 ... Communication I / F, 1061 ... Command interpretation unit, 1062 ... Command execution unit, 1063 ... Stop code insertion unit, 1064... Test item queue, 10120 ... packet communication control function, 10420 ... communication simulator.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　独立して動作する各シミュレータ内部に装着した複数の試験用プローブ部と非同期に通信する試験進行制御部を備え、複数の試験用プローブ部と非同期に通信する試験進行制御部がシミュレータ全体の動作を一時停止・再開させる機能を共有する。これにより、独立した異種複数のシミュレータが連携して動作するシミュレーションに対し、外部条件の挿入及び内部状態の操作を、各操作の実行順序が入れ替わらない様にして実行する事を可能にする。

Description

協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム
　本発明は、協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラムに係り、特に、メカニズム、ハードウェア、及びソフトウェアで構成される組込みシステムの開発に適した、協調シミュレータの技術に関するものである。
　組込みシステムとは、制御対象を構成するメカニズムと、
　このメカニズムから受け取った物理量を元に制御演算を行い、このメカニズムに制御値の出力を行なうハードウェアと、
　このハードウェア上で動作するソフトウェアとで構成されるシステムである。
　例えば、自動車エンジン制御向けの組込みシステムは、
　制御対象であるエンジン等のメカニズムと、制御演算を行いこのエンジン等を制御するマイコン等の電子機器と、このマイコン等の上で動作するソフトウェアとで構成されている。
　組込みシステムに含まれるソフトウェアの挙動は、制御対象のメカニズムとハードウェアの構成に強く依存するため、メカニズム、ハードウェア、ソフトウェアを併せた挙動の解析が必要である。
　近年、自動車、電気機器等の高信頼化、高機能化により組込みシステムが複雑化しており、作業期間短縮のためハードウェア、ソフトウェアの各部品を細分化して分業化が行なわれ、複数拠点での同時開発が行われている。
　分業化が進むにあたり、部品毎の動作確認だけではなく、部品の組み立て時に判明する性能不足、仕様の不具合が増加し、製品出荷前の最終段階での手戻りによる開発期間の遅延が多発しており、開発効率の悪化が問題となっている。
　この問題を解決するため、設計時点でのメカニズム・ハードウェア・ソフトウェアを協調させたシミュレーションによる性能評価、検証手法が用いられ始めている。例えば、特許文献１には、複数の異種ＥＣＵを持つシステムを、ソフトウェア的に効率的にシミュレートする技術が開示されている。
　また、特許文献２には、各々データプロセッサで構成される独立した異種複数のシミュレータが連携して動作するシミュレーションに対し、外部条件の挿入及び内部状態の操作を行う手段として、全てのシミュレータが接続されたユーザーインターフェースプロセッサを備え、このユーザーインターフェースプロセッサにより、シミュレーション全体の進行を管理し、内部状態の操作を行う手法が提案されている。
特開２０１０－３３１３０号公報 特開２００７－２６５４１５号公報
　メカニズム・ハードウェア・ソフトウェア協調のシミュレーションでは、シミュレーション対象となるメカニズムやハードウェアの構成によって利用できるシミュレータが異なる事と、すでに特定のシミュレータ用に作成されたシミュレーションモデルの蓄積がある事から、異種シミュレータの相互接続による製品全体レベルの協調シミュレーションが行なわれる。
　上記のシミュレーションを実行する際は、実行対象の動作を模したモデルを結合させるだけではなく、各シミュレータに対し外乱条件を挿入したり、内部状態を観測するための機構を付加する必要がある。
　これらの外乱条件の挿入、内部状態観測はシミュレーション開始前に予め決められた時刻に起こすだけではなく、シミュレータが到達する特定の状態をトリガとして作動することが求められる。これは、システム全体の複雑化によって、部品同士の複雑な相互関係由来による異常状態の解析の重要度が高くなっていることに起因する。
　複雑な部品同士の依存関係を記述するためには、トリガをかけるもの、状態を観測するもの、内部状態に外乱を与えるもの、以上の3つが別々のシミュレータに跨ることが求められる。
　しかし、対象とする協調シミュレーション環境では、そのそれぞれのシミュレータは独立して動作するため、上記のような依存関係の記述は利用者にとって困難であった。例えば、ドメイン等の種類が異なる複数のシミュレータのコンピュータ間でのイベントの操作・トリガのやり取りは、システムの中央部分を介して通信する必要があり、シミュレーションの実行過程で利用者が複数のシミュレータを任意のタイミングで操作して異常状態の解析を行うことは困難であった。
　特許文献１には、各シミュレータに対しユーザが、任意に外乱条件を挿入したり内部状態を観測するための機構を付加することについての開示は無い。
　特許文献２の発明は、ユーザが中央のユーザーインターフェースプロセッサ経由で各シミュレータ（データプロセッサ）の内部状態の操作を行うものである。この場合、ユーザが操作を行うべき状態を観測してから、実際にその操作が行われるまで、各シミュレータと中央のユーザーインターフェースプロセッサ部分との通信が最低１往復あることから、操作の時間精度が損なわれ、望まれたシミュレーション結果が得られなくなることが課題であった。
　協調シミュレーション環境において、ユーザが予め決められた時刻以外の任意のタイミングで何れかのシミュレータに外乱条件を挿入したりシミュレータの内部状態の観測を行う場合でも、管理ソフトウェアが試験記述にしたがって試験項目の順序が入れ替わることなく実行されることが望ましい。
　本発明の目的は、独立した異種複数のシミュレータが連携して動作する協調シミュレーションに対し、ユーザがシミュレータに与えた外部条件の挿入及び内部状態の操作に対して、これらの各操作の実行順序が入れ替わらない様に実行する事を可能にする、協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラムを提供することにある。
　本発明の代表的なものの一例を示すと、次のようになる。本発明の協調シミュレーション用計算機システムは、協調して動作する複数のシミュレータとこれら検証対象の複数のシミュレータを制御するシミュレーション統合コントローラとを備え、前記シミュレーション統合コントローラと前記各シミュレータとが、非同期通信により前記複数のシミュレータの全体の動作を一時停止・再開させる機能を共有しており、前記いずれか１つのシミュレータに設定されている停止条件が成立したとき、前記複数のシミュレータの全体を一時停止させ、該一時停止の間に前記少なくとも１つのシミュレータの状態の取得又は状態の書き換えを行うことを特徴とする。
　本発明によれば、ユーザに対し、協調シミュレーションの外部から任意のタイミングで何れかのシミュレータに対してその実行継続条件を注入可能とする機能を提供することにより、検証対象のシステムについてその挙動の把握を容易にする事が可能である。
本発明の第１の実施例になる協調シミュレーション用計算機システムの全体的な構成例を示す機能ブロック図である。 図１の試験進行制御部の構成例を示す図である。 図１の検証対象シミュレーション、特にその内部で動作する試験用プローブ部の構成例を示す図である。 本システムの検証対象となる自動車エンジン制御向けの組込みシステムの物理的な構成例を示す図である。 電子制御ユニット（ECU）の物理的構成例を示す図である。 図３Ａの自動車エンジン制御向けの組込みシステムの動作を協調シミュレーション環境上で再現するための、検証対象シミュレータ環境を示す図である。 図４Ａで示した協調シミュレーション用の計算クラスタの構成例を示す図である。 本発明のシステムでサポートされる試験用プローブと対象モデル間の接続方式の一例示す図である。 本発明のシステムで用いる、共通の通信プロトコルの構成例を示す図である。 本発明のシステムで用いる、試験項目の記述フォーマットと試験結果の記述フォーマットの構成例を示す図である。 本発明の適用対象となるシミュレーションにおける、構成仕様記述フォーマットの構成例を示す図である。 本システムで利用可能となる操作、トリガ、観測を実行するコマンドーの種類を記述するためのフォーマットの構成例を示す図である。 図９のコマンドフォーマットで記述されたコマンドーの試験項目フォーマット上での識別名称と、そのコマンドー種類との対応を記述するためのフォーマットの構成例を示す図である。 第１の実施例における協調シミュレーション用計算機システムの特徴的な機能に関する動作フローを示す図である。 ユーザが記述したテスト仕様書の中に組まれる「適用対象となるシミュレーション」とそれらの処理の「優先度」の関係の一例を示す図である。 第１の実施例における試験用プローブが、その接続している対象モデルに対してシミュレーションの停止を行う構造を概説する図である。 図１２のテスト仕様書に対応したシミュレーションの起動・停止の例を示す図である。 図１２のテスト仕様書に対応したシミュレーションの起動・停止の他の例を示す図である。 本発明の第２の実施例になる、対象モデルがCPUモデルである場合に、このCPUのトレースから、他の試験用プローブのコマンド実行部に対するコマンドをトリガする手法を示す図である。 本発明の第３の実施例になる、対象モデルがメモリ等である場合に、このメモリ等が含むバスモデルのトレースから他の試験用プローブに対するコマンドをトリガする手法を示す図である。
　本発明は、複数のソフトウェアが連動して動作する計算機システム、または開発システムのプログラムに適用することができる。
　本発明の１つの実施形態によれば、協調シミュレーション用計算機システムは、１つのシミュレーション統合コントローラと、このシミュレーション統合コントローラに非同期ネットワークを介して接続され各々独立して動作する複数の検証対象シミュレータとで構成されている。各検証対象シミュレータは、試験用プローブ部を備えている。シミュレーション統合コントローラは、各検証対象シミュレータと非同期に通信する試験進行制御部を備えている。複数のシミュレータの試験用プローブ部と１つのシミュレーション統合コントローラの試験進行制御部とが、シミュレータ全体の動作を一時停止・再開させる機能を共有する。
　本発明の協調シミュレーション用計算機システムでは、仮想検証環境を構成する複数のシミュレータが連携動作するために必要となるシミュレータ間データ通信部分に着目し、このデータ通信部分に仮想的な遅延時間を挿入することで該当するシミュレータの動作を停止させる。これにより、連携しているシミュレータ全体を連鎖的に停止させる。この性質を用いて、中央のシミュレーション統合コントローラとの通信を起こすことなく、各シミュレータにおいて、指定されたタイミングでの内部状態の操作が可能になる。すなわち、いずれかのシミュレータに設定されている停止条件が成立したときに、全てのシミュレータを止めた後に、各シミュレータの状態の取得又は状態の書き換えを行う。また、独立した異種のシミュレータが複数連携して動作するシミュレーションに対し、全てのシミュレータを一時的に停止さ、外部条件の挿入及び内部状態の操作を、各操作の実行順序が入れ替わらない様に実行する事が可能になる。
　本発明の他の実施形態によれば、協調シミュレーション用計算機システムは、複数の機械・センサ系（メカ系）シミュレータとマイコン系シミュレータとが連携して動作する、仮想検証環境（本システム）を構成している。機械・センサ系シミュレータは、指令を受けて動作する各種のアクチュエータやその状態を検知するセンサ等、制御対象となる機器・部材に対応し、マイコン系シミュレータは、上記制御対象となる機器・部材を指令やセンサ情報等に基づいて制御するためのマイコンに対応している。
　本発明の第１の実施例を、図１～図１４Ｂを参照しながら説明する。  
　図１は、本発明の第１の実施例になる協調シミュレーション用計算機システムの全体的な構成例を示している。すなわち、図１は、複数個のシミュレータ間の協調により動作するシミュレーション環境に対する、内部状態の操作や観測を可能にする計算機システムの機能ブロック図である。
　本発明の協調シミュレーション用計算機システム10は、シミュレーション統合コントローラ100と、このシミュレーション統合コントローラに非同期ネットワーク103を介して接続された複数の検証対象シミュレーション104(1)～104(N)とで構成されている。シミュレーション統合コントローラ100は、試験進行制御部101と試験項目等に関するデータを保持するデータベース（DB）120と、入力部107と、出力部108と備えている。シミュレーション統合コントローラ100の試験進行制御部101は、入力部107を介して利用者の試験項目記述0100を受け取り、各シミュレーション104(1)～104(N)に対して、試験項目の実行を指示し、当該試験項目の試験結果0102を出力部108に出力する。なお、入力部107と出力部108の一部は、共通のGUI画面で構成することができる。また、試験進行制御部101は、各検証対象シミュレーション104(1)～104(N)の内部で動作する各試験用プローブ部106（0～M）と非同期ネットワーク103で接続されている。
　また、検証対象シミュレーション104は協調シミュレーション環境中に複数個存在しており、それぞれデータ交換用ネットワーク111を介して接続されている、各シミュレーション104中には、検証対象となるモデル105（0）～105(N)が存在する。試験用プローブ部106は、各検証対象モデル105に対し、１つまたは複数個接続することが可能である。
　図２Ａに、本システムを構成する試験進行制御部101の構成例を示す。試験進行制御部101は、ユーザが予め決められた規則で記述した試験項目フォーマット0100を受け取り、其れを解釈する試験項目解釈部1010と、解釈された試験項目列を蓄積し順番に実行する試験項目待ち行列1011と、本システム中に複数個存在する試験用プローブと接続され、試験項目と試験結果、トリガ成立イベントなどをやり取りするための通信I/F部1012と、各試験項目の実行結果を蓄積し、試験項目フォーマット0100中に記述された期待値との判定を行い、その結果を試験結果0102として出力する期待値判定部1013とによって構成されている。通信I/F部1012は、パケット通信制御機能10120を備えており、試験進行制御部101と各検証対象シミュレーション104（ｘ）との間で、システムの共通プロトコルによるパケット通信を行う。
　図２Ｂは、検証対象シミュレーション104、特にその内部で動作する試験用プローブ部106の構成例を示す。
　試験用プローブ部106は、検証対象シミュレーションの104内部で動作する仮想的なシミュレーションモデルとして動作し、各シミュレータで提供されているデータ通信方式により、操作及び観測対象となる対象モデル105と接続されている。
　試験用プローブ部106は、非同期ネットワーク103を介して試験進行制御部101と接続され、試験項目を受信し試験項目待ち行列1064として蓄積すると共に実行した試験項目の結果及びトリガ成立タイミングを返信するための通信I/F 1060と、試験項目を各シミュレータが実行可能なイベントに再度解釈するためのコマンド解釈部1061と、解釈されたコマンドを実際に接続されている対象モデル105に対して実行するコマンド実行部1062と、対象モデル105が接続されているシミュレータ間データ通信111に介入しシミュレーションの実行を停止させる停止コード挿入部1063によって構成される。
　図３Ａは、本システムの検証対象となる自動車エンジン制御向けの組込みシステムの物理的な構成例を示す。この組込みシステムの基本的な構成としては、エンジン201、ブレーキ202、ユーザ操作パネル203、車体姿勢制御系204といった自動車の機械系・センサ系のモジュール200に対し、それぞれ対応する制御を行う電子制御ユニット210として、エンジンECU 211、ブレーキECU 212、ユーザインターフェイスECU 213、ステアリングECU 214が存在しており、それらが車載ネットワーク230を介して接続されることで、制御が成立している。車載ネットワークはその中心ノードが車載通信コントローラ220として存在する場合がある。
　図３Ｂは、電子制御ユニット210の各ECU（211-214）の基本構成を示す図である。各ECUにはその制御を行う母体となるマイクロコントローラ2101が１つないし複数個搭載されており、それらは機械系またはセンサと接続するためのアナログIO 2102、 専用IC 2103と接続される。また、他のECUとの接続のため、各ECUは通信インターフェイス2104を備えており、車載ネットワーク230に接続されている。車載通信コントローラ220も、マイクロコントローラや通信インターフェイス等を備えている。
　次に、本発明を適用した仮想検証環境の具体例として、複数の機械・センサ系シミュレータとマイコン系シミュレータとが連携して動作する、自動車エンジン制御向けの組込みシステムの協調シミュレータについて説明する。  
　図４Ａは、図３Ａの自動車エンジン制御向けの組込みシステムの動作を協調シミュレーション環境上で再現するための、検証対象シミュレータ環境を図示している。
　図３Ａのエンジン201、ブレーキ202、ユーザ操作パネル203、車体姿勢制御系204等の各機構系部品やモジュールは、それぞれ機械・センサ系シミュレータ10401、10402、10403、10404によりエミュレートされ、電子制御ユニットのエンジンECU211、ブレーキECU212、ユーザインターフェイスECU213、ステアリングECU214はそれぞれマイコンシミュレータ10411、10412、10413、10414によりエミュレートされる。これらのECUを接続していた車載ネットワーク230及び車載通信コントローラ220は、車載ネットワーク160及び通信シミュレータ10420によりエミュレートされることにより、全体の協調動作が再現される。車載ネットワーク160、230には、例えば、車載系のLANであるCAN (Controller Area Network)が使用される。
　このような検証対象シミュレータを構成する各シミュレータは、それぞれ、非同期ネットワーク103を介してシミュレーション統合コントローラ100と接続されている。シミュレーション統合コントローラ100は、検証対象シミュレータに対するユーザインターフェイスとして機能する。
　なお、機械・センサ系シミュレータ10401、10402、10403、10404、マイコンシミュレータ10411、10412、10413、10414、及び、通信シミュレータ10420は、一部もしくは全部が同じ種類のシミュレータであってもよく、あるいは全てが異なる種類のシミュレータであってもよい。ここで、シミュレータの種類が異なるとは、シミュレータが対象とする物理系すなわち、物理系、機構系、電子系などの対象の「ドメイン」が異なる物を指す。あるいは「ドメイン」が同じでも、シミュレータの作成メーカーが異なっていり、同じメーカーであってもその作成時期（バージョン）が異なっている場合は、シミュレータの種類が異なる。また、プログラムの言語（Ｃ言語、Ｊａｖａ（登録商標）、Ｐｙｔｈｏｎ，Ｒｕｂｙ等）が異なる場合も、シミュレータの種類が異なる。
　図４Ｂは、図４Ａで示した協調シミュレーション用の計算機システム10を実行するのにふさわしい計算機の構成の一例を示す。複数個のシミュレータが連動する本シミュレーションは、ひとつの計算機で動作させた場合その負荷の集中と、複数シミュレータを入れ替えながら実行することのコストにより、劇的なシミュレーション速度の低下を招く。このため、本シミュレーションは複数個の計算機1101がネットワーク1102により接続されたクラスタ型の計算機システムを用いることが望ましい。この時計算機間を接続するネットワークは全ての計算機をひとつに集める集中型のネットワークの他、任意の二つの計算機を強連結したクロスバー型接続のネットワークが考えられる。
　図５において、本システムでサポートされる試験用プローブ106と対象モデル105間の接続方式の一例を述べる。接続の方法は対象モデル105の動作するシミュレータに依存してその実現方式は異なるものの、ある程度のカテゴリ分けがされている。まず接続方式は、出力型、入力型、それぞれを兼ねるバス型に分けられ、出力型は浮動小数点値または整数値を出力するアナログ出力500、０または１のみを出力するデジタル出力501、クロック信号をやりとりするためのクロック出力502が考えられ、入力型としては、０または１のみを入力するデジタル入力503、浮動小数点値または整数値を入力するアナログ入力504が考えられる。バス型接続として考えられるのは、メモリバス・通信インターフェイス505である。これらの組合せは本システムでサポートされる操作の一例を示したものであり、ユーザは図５や後で述べる図９で示したフォーマットを修正することにより、任意の命令をシステムでサポートするように改造することが可能である。
　本システムでは、対象とする協調シミュレーションに含まれるシミュレータの種類に依存すること無い、試験項目の実行を目的とした共通の試験項目通信プロトコル0600を備えている。図６は、試験用プローブ部106と試験進行制御部101との間でやりとりされる本システムの共通の通信プロトコル0600の構成例を示す。この通信プロトコル0600は、全てのシミュレータにおけるイベントの操作・トリガを同一に扱うための試験記述フォーマットを保有している。本通信プロトコルは、可変長の命令列をもつことができる。
　図６中のarg1フィールド0605、arg2フィールド0606が可変長部分であり、その数はIndex 0603によって制御される。その他のフィールドは固定して存在する。IDフィールド0601は当該の試験項目をどの試験用プローブ106で実行するべきかを指示する。Typeフィールド0602は該当試験項目の種類を指定する。Valueフィールド0604は当該試験項目が観測、トリガイベントであったときその項目の実行結果が入力される。Timingフィールド0607は当該試験項目を実行するべきシミュレーション時間が記述されて試験進行制御部101から送信され試験用プローブ部106で実際に実行されたシミュレーション時間が上書きされた状態で返送される。
　図７は、試験項目フォーマット0100と試験結果0102のフォーマット0700の構成例を示す。本構成例では試験項目の実行結果の視認性を高めることを目的として、試験項目フォーマット0100と試験結果0102のフォーマットを統合した形のフォーマット0700を図示しているが、実際の構成ではこれらが分割された形であっても、その効果を失うものではない。
本システムで行われる試験項目はひとつのテスト項目0701につきひとつの測定トリガ指定0702とひとつまたは複数個の期待値指定0703がセットとなって構成される。テスト項目指定0701は行番号0701、テスト項目名0705と当該テスト項目0705を実行する前にシステムが待機する時間を指定する実行待機時間0706と、テスト項目の具体的な動作を示す指示0707と、その引数となる設定値0708、0709によって構成される。
　測定トリガ指定0702はトリガ種類の指示0710とその引数となる設定値0711と、トリガ成立条件を指定する比較式0712、トリガが成立した時間が入力される経過時間0713とその際のデータ値0714によって構成される。期待値指定703は期待値種類の指示0715とその引数となる設定値0716、0717と、トリガ成立条件を指定する比較式0718、当該期待値指定実行時に得られる値0719が入力されるとその値を用いた比較式の判定結果が入力される判定フィールド0720によって構築される。各項目の設定値の数が本構成例と異なる場合でも、試験項目通信プロトコル0600によって可変個の設定値が許容されているため、機能に影響はない。
　図８は、本システムの適用対象となるシミュレーション104における変更可能な状態、変数と、それが接続された試験用プローブ106の接続関係を記述するためのフォーマット0800の構成例である。本フォーマットに含まれる情報の例として、変数のシステム上の識別子であるピン番号フィールド0801と、試験項目フォーマット0100上での識別名称であるピン名フィールド0802と、当該ピンの試験用プローブ106上での型を示すインターフェイス型フィールド0803と、ピンのおおよその働きを示すファンクションフィールド0804と、当該ピンが接続されている試験用プローブ106のIDを示す試験用プローブIDフィールド0805と、当該試験用プローブ106が接続されている対象モデル105とのインターフェイスピン番号を示す試験用プローブインデックスフィールド0806の情報がある。
　図９は、本システムで利用可能となる操作、トリガ、観測を実行するコマンドーの種類を記述するためのフォーマット0900の構成例を示す。コマンドー名フィールドは、コマンドーのシステム上での識別名称を示す、設定値フィールド0902、0903、0904、0905、0906は、各コマンドーが持ちうる引数の数と種類を記述する。本システムでサポートするコマンドは可変長の引数を持ちうるので、本フォーマットの設定値フィールドは可変長のサイズを持ちうる。また、各設定値は複数の種類をもつことが可能である。
　図１０は、図９のコマンドフォーマット0900で記述されたコマンドーの試験項目フォーマット0100上での識別名称と、そのコマンドー種類との対応を記述するためのフォーマット1000である。本フォーマット1000では、コマンド種別フィールド1001と、シート上コマンド識別名1002、システム上コマンド識別名1003を情報として含む。本システムで利用可能なコマンドーとして、試験項目フォーマット0100は、テスト操作、トリガ操作、期待値操作に分かれており、それぞれ個別の動作をするコマンドーが割り当てられる。しかし、ユーザの視認性を考慮し、メモリやIOピンなど同じ種類の動作に対し、シート上では同じ名前を割り当てることが求められる。この問題を解決するため、（シート上の名前1002＋コマンド種別1001）が、システム上のコマンド識別子に対応するように、種別を設定する。
　図１１は、本システムの協調シミュレーション用計算機システムの特徴的な機能に関する動作フローを示す図である。この機能は、協調シミュレーションの途中において、ユーザが設定した条件に基づいて、割り込み処理により、外乱条件を挿入したり内部状態の観測を行うものである。ユーザは、シミュレータの全体を一時停止させ、該一時停止の間に少なくとも１つの前記シミュレータの状態の取得又は状態の書き換えを行うことができる。
　予め、ユーザは決められた規則でテスト仕様書を記述し、試験項目フォーマット0100として作成する。ステップ600において、これらのデータは試験進行制御部101に入力される。例えば、図７、図８、図９に記載の様式の入力フォーマットが入力部107のGUI画面に表示され、ユーザが所定の欄に必要項目を入力することでテスト仕様書を記述することで、入力がなされる。そして、ユーザがシミュレーションを起動すると、試験進行制御部101は試験項目フォーマット0100を受け取り、試験項目解釈部300は入力されたテスト仕様書を解釈し、試験項目を自動的に生成し、この試験項目を図６に示す試験項目通信プロトコル0600に当てはまるデータへと変換する。
　次に、ステップ601において、試験項目を実行するタイミングを設定する。このタイミングは、１回目はユーザのデータにより初期設定された値、２回目以降は前回の試験項目が実行されたタイミングに基づいて、各々設定される。さらに、ステップ602において、試験項目解釈部300で解釈された試験項目を試験項目待ち行列0301に格納する。次に、試験項目待ち行列0301より試験項目を取り出す。ステップ603で、1件または複数件の試験項目を取り出す。ステップ60４では、送信する試験項目のコマンド部がコマンド指定か否を判定する。当該試験項目がコマンド指定の場合はステップ603へ戻り、試験項目の種類がトリガ系統又はテスト操作系であればステップ605に進む。このようにして、試験用プローブ106に対して送信すべき試験項目が、トリガ系統、又はテスト操作系（Get 系）、トリガ系統＋（１つ若しくは複数の）コマンド指定の組み合わせ、又は、テスト操作系＋（１つ若しくは複数の）コマンド指定の組み合わせ、の何れかになるようにする。
　次のステップ605では、取り出した１つまたは複数個の試験項目に関して、試験項目のID部指定を読み出し、通信I/F部0302がもつ通信ソケットのうちどれを使用するかを選択し、通信ソケットを介して、ターゲットとする試験用プローブ106に対して送信する。試験項目の内容によっては、ターゲットとなる試験用プローブ部が複数になることもある。
　ステップ606では、送信された試験項目を、各試験用プローブ部106で受信する。
　ステップ607では、受信した試験項目通信プロトコル0600のタイミングフィールド0607を読み出し、現時点でのシミュレーション時間と比較し、読みだした実行時間が現在のシミュレーション時間よりも大きい値の場合、ステップ608に分岐し、小さい値の場合ステップ609に分岐する。
　ステップ608では、受信した試験項目をEvent Queueに貯めて、その指定時間がくるまで待機し、ステップ609に遷移する。
　ステップ609では、コマンド解釈部1061が試験項目通信プロトコルのTypeフィールドを読み出し、コマンド実行部1062に定義された、操作・観測用コマンドを引き当てる。
　ステップ610では、操作・観測用コマンドの種類を読み出し、そのタイプがトリガ指定用コマンド（トリガ系統）であった場合はステップ611に分岐し、それ以外のテスト操作、期待値系統（コマンド指定）のコマンドの場合はステップ614に分岐する。
　ステップ611では、ステップ609で引き当てられた操作・観測用コマンドを実行する。この時、試験項目通信プロトコルのargフィールド0605、0606がその関数の引数として利用される。この時実行された結果が試験項目通信プロトコルのValueフィールド0604に、実行されたシミュレータ上のタイムスタンプがタイミングフィールド0607に上書きされ、返答イベントとして生成される。
　ステップ612では、トリガ条件が成立し、トリガ関数が実行されるまで待機する。ステップ613において、トリガ条件が成立する、すなわち、ユーザの与えた条件によるシミュレーションの停止条件が成立すると、ステップ613に進む。  
　ステップ613では、試験項目通信プロトコルの受信から、ここまでのステップにて、シミュレータ上の時間は進んでいないことが保証されている。ここで、停止コード挿入部403を有効化し、シミュレータ間通信111を停止させる。これにより、シミュレーション全体を連鎖的に停止させる。すなわち、いずれか１つのシミュレータに設定されている停止条件が成立したときに、複数のシミュレータの全体を連鎖的に止める。  
　ステップ617では、前段で生成した返答イベントを試験進行制御部101へ送り返す。
　一方、ステップ610で、テスト操作、期待値系統のコマンドの場合はステップ614に分岐する。なお、ステップ614に分岐する場合は、その前のサイクルのステップ613で複数のシミュレータの全体が停止しているという前提がある。ステップ614では、トリガ指定用コマンドで指定されたトリガ関数を有効化する。すなわち、シミュレータの全体が停止している状態で、試験項目を実行し、少なくとも１つのシミュレータの内部状態の取得または状態の書き換えを行う。ユーザは、指定されたタイミングでの、任意のシミュレータの内部状態の操作が可能になる。当試験用プローブ106でのコマンド実行が終了すると（ステップ615）、停止コード挿入部1063の無限ループが解除され（ステップ616）、協調シミュレーション全体が再開される。すなわち、ステップ616において、試験項目通信プロトコルのTypeフィールド0602が予約された停止解除命令に出会った場合、停止コード挿入部1063を無効化し、シミュレーション全体を再起動させる。
　試験進行制御部101では、当該Event Processorからの応答Eventの到着を待ち（ステップ618）、応答Event内部のTiming， Valueなどを記憶手段に保持する（ステップ619）。
ステップ620では、Eventが実行された実績に基づくTiming情報を取得し記憶手段に保存する。このTiming情報に基づいて、次回の実行タイミングが設定される。
　ステップ621では、Event Queueの最後のEventかを判定し、最後でなければステップ601に戻り、特定のシミュレータの停止条件が成立したときに複数のシミュレータ全体の停止を行った後、１つ又は複数のシミュレータの内部状態の取得または状態の書き換えを行う。そして、最後のEventであればステップ622として処理を終了する。
　試験進行制御部101の期待値判定部1013は、協調シミュレーションによって得られ、保持された情報と試験項目フォーマット0100中に記述された期待値との判定を行い、その結果を試験結果0102として出力する。例えば、図７、図８、図９に記載の様式のフォーマット中に試験結果が組み込まれて、出力部107のGUI画面に表示される。
　図１２は、ユーザが記述したテスト仕様書の中に組まれる「適用対象となるシミュレーション」とそれらの処理の「優先度」の関係の一例を示している。この例では、自動車エンジン制御向けの組込みシステムの適用対象となる協調シミュレーションとして、マイコンシミュレータの「A エンジンECU」、「C ブレーキECU」、機械・センサ系シミュレータの「B エンジンのメカ」、「D ブレーキのメカ」が有り、それらのシミュレーションを実行する「優先度」が定義されている。このような試験項目は図１１のステップ600において、試験項目フォーマット0100に記述されたテスト仕様書を解釈することで自動的に生成され、これらの試験項目を図６に示す試験項目通信プロトコル0600に当てはまるデータへと変換し、「優先度」に基づいて該当するIPアドレスのシミュレータのプローブに送信する。
　図１３は、試験用プローブ106が、その接続している対象モデル105に対してシミュレーションの停止を行う構造を概説する図である。協調シミュレーション環境に含まれるシミュレータ104(1)とシミュレータ104(2)は互いにシミュレータ間通信I/F(1060)によって接続され、予め決められたシミュレーション時間を周期としてデータを交換し、シミュレーションが連携して動作する。この時、試験用プローブ106が、試験進行制御部101より操作・観測のコマンドを受け取り、ミュレーションを停止させる必要が生じた場合、シミュレータ104(1)の停止コード挿入部1063はこのシミュレータ間通信に割り込みを入れ（停止1）、受信処理を無限ループに誘導する。これによって、シミュレータ104(1)とシミュレータ104(2)の協調シミュレーションは擬似的に停止することになる（停止2，3）。
　こ停止状態は、シミュレータ104(1)、104(2)における2つシミュレーションに限定されず、これらのシミュレータ104(1)、シミュレータ104(2)が停止しているため、それらがそれぞれ接続されている他のシミュレータ104(3)、104(4)、-、104(n)とのデータ通信もそこで停止することとなり、最終的に協調シミュレーションの動作周期内に、全体の進行が連鎖的に停止する（停止4，5，n）。
　すなわち、停止コード挿入部1063は、シミュレータのデータ同期通信部に介入し（割り込みを入れ）擬似的な受信遅延を発生させることで、複数のシミュレータを連鎖的に停止させる。換言すると、停止コード挿入部1063は、全てのシミュレータに通信すること無く、試験項目の順序入替によりシミュレーション結果に影響が出る前に、前記複数のシミュレータ全体を実質上同時に停止させる。
　このシミュレータ全体の停止状態において、各操作の実行順序が入れ替わることなく、特定のシミュレータの状態の取得又は状態の書き換えを行うことができる。
　図１４Ａは、図１２のテスト仕様書に対応したシミュレーションの起動・停止の例を示している。図１２では、「優先度」が、シミュレータＡ，Ｄ，Ｂ，Ｃ，Ａの順になっている。そこで、図１１の動作フローにおける最初のシミュレーション全体を停止状態(S613)とし、この状態のままで次のサイクルにおいて、シミュレータＡ（エンジンのＥＣＵ）の状態の取得またはデータの書き換えを行う(S614，S615)。この間、他の全てのシミュレーションは動作を停止している。その後、シミュレーション全体を再起動(S616)させ、さらに次の繰り返しサイクルにおいてシミュレーション全体を停止状態(S613)とし、この状態のまま次のサイクルにおいて、シミュレータＤ（ブレーキのメカ）の状態の取得またはデータの書き換えを行う (S614，S615)。その後、シミュレーション全体を再起動させ、以下、同様に動作フローを繰り返し、ステップ状に短時間で繰り返される停止時に、順次、シミュレータＢ，Ｃ，Ａの状態の取得またはデータの書き換えを行い、一連の処理を終了する。この後、期待値判定部による判定結果が出力される。
　これにより、例えば、最初にシミュレータＡ（エンジンのＥＣＵ）に外乱条件の挿入したことによりシミュレータＤ（ブレーキのメカ）の内部状態がどのように変化するかを、次のシミュレーション停止の後にシミュレータＤの内部状態のデータを取得することができる。あるいはまた、シミュレーション全体を順次停止させ、それら順次停止している間にシミュレータＤ（ブレーキのメカ）やシミュレータＢ（エンジンのメカ）に外乱条件を挿入し、これに伴い、シミュレータＣ（ブレーキのＥＣＵ）やシミュレータＡ（エンジンのＥＣＵ）の内部状態がどのように変化するか、次のシミュレーション停止時にデータを取得することもできる。このようにして得られた各データが期待値判定部で判定され、ユーザはその観測を観察することができる。
　図１４Ｂのシミュレーションの起動・停止の例では、機械・センサ系シミュレータ「エンジン」のデータの書き換えを行い、このデータの書き換えに伴うマイコンシミュレータの「エンジンECU」の状態の変化のデータを、時間ΔＴ後の繰り返しサイクルで取得している。これは、例えば、メカ系のアクセルを急に操作したとき、それに対してエンジンのＥＣＵの制御がどのようになされるかを観察する場合に相当する。
　このように実際の車の運転時に起こり得る外乱条件を与えそれに対する挙動の観察をステップ毎に進めながら行うことで、正規のシミュレーションでは検知できない種々の条件下での、組込みシステムの性能の不足や、仕様の不具合を抽出することが可能になる。
　図１４Ａ、図４Ｂの例では、各シミュレーション全体の停止状態において、各々、１つのシミュレータの状態の取得やデータの書き換えを行っているが、同時に複数の種類のシミュレータに対して状態の取得やデータの書き換えを行っても良い。あるいはまた、同時に同じ種類のシミュレータに対して状態の取得やデータの書き換えを行っても良い。後者の場合の一例として、多気筒エンジンに関して１つのシリンダに外乱として故障を与え、それに伴って他のシリンダがどのように動作するかの状態を読み出して観察することができる。
　本実施例では、外部条件の挿入や内部状態の観察等の操作は、シミュレーション全体の起動、停止に同期して個別に行うので、各操作の実行順序が入れ替わることはない。すなわち、ユーザに対し、協調シミュレーションの外部から任意のタイミングでその実行継続条件を注入可能とする機能を提供することにより、検証対象のシステムについてその挙動の把握を容易にする事が可能である。
　本実施例では、試験項目通信プロトコルを用いた複数のシミュレータの間データ通信部分に着目し、このデータ通信部分に仮想的な遅延時間を挿入することで、該当するシミュレータの動作を停止させることにより、シミュレータの種類の如何に拘わらず、連携しているシミュレータ全体を停止させる。この性質を用いて、中央部分との通信を起こすことなく、シミュレータの種類、例えばドメインの異同を問わずに、指定されたタイミングでの、少なくとも１つのシミュレータの内部状態の操作や確認が可能になる。これにより、ユーザは、シミュレーション外部から任意のタイミングでその実行継続条件を注入することができ、組み込みシステムの全体とその構成要素間の相互の挙動について、詳細な情報の把握が容易になる。
　一般に、エンジンのメカやブレーキのメカ等のハードウェア、エンジンのＥＣＵやブレーキのＥＣＵ等のソフトウェアの各部品は細分化して分業化が行なわれ、複数拠点での同時開発が行われている。各拠点では、自動車全体のシステムに関する共通の仕様等を前提にして分業開発がなされるが、部品点数は多種多様である。そのため製品全体レベルの協調シミュレーションでは、部品同士の複雑な相互関係由来による異常状態の解析を十分に行うことが困難である。また、分業開発のため、使用されるシミュレータの種類も異なる場合が多い。
　本実施例によれば、このようなシステムを構成する部品点数が多くかつシミュレータの種類が異なる場合の製品全体レベルの協調シミュレーションであっても、トリガをかける機能、状態を観測する機能、内部状態に外乱を与える機能を、異種のシミュレータに跨って実行させることができるので、部品同士の複雑な相互関係由来による異常状態の解析を確実に行うことができる。すなわち、対象とする協調シミュレーションに含まれるシミュレータの種類に依存すること無い、試験項目の実行を目的とした共通の試験項目通信プロトコルを備えており、異種のシミュレータに跨って試験項目を実行させることができる。また、各シミュレータ内部に装着した試験用プローブ部と非同期に通信する試験進行制御部を備え、試験進行制御部がシミュレータ全体の動作を一時停止・再開させる機能を共有することにより、外乱条件の挿入、内部状態観測を容易にすると共に、各試験項目の実行時間の遅れを最小化することができる。
　本発明の第２の実施例を、図１５を参照しながら説明する。  
　図５では、試験用プローブ106と対象モデル105間のCAN接続方式の一例を述べた。本実施例では、対象モデル105がCPUモデルである場合に、このCPUモデルのトレースから、他の試験用プローブ0106のコマンド実行部1062に対するコマンドをトリガする手法を例示する。例えば、図４ＡのCPUモデルを含んだ通信シミュレータ１０４２０から、メカシミュレータ１０４０１のプローブのコマンド実行部1062に対するコマンドをトリガすることができる。
　図１５において、対象モデル105がCPUモデル1500を含んでいた場合、その上で実行された命令列のＰＣトレースを取得できる。試験用プローブ106のコマンド実行部1062に予め、CPUモデル1500で実行するソフトウェアのリンカ情報1503から各関数の開始および終了アドレスを抜き出してDB化したタスクDB1502を生成して入力する。
　ソフトウェアトレース生成部1501は、CPUモデル1500から受け取ったＰＣトレースをもとにタスクDB1502を検索することにより、CPUモデル1500上での関数呼び出しの開始と終了を検知することが可能である。関数呼び出しの境界に同期して、トリガ情報を試験進行制御部101で、他試験用プローブ106のコマンド実行を開始させることが可能になる。試験進行制御部101からはどの関数の開始または終了に対し、トリガを発生させるかを有効化、無効化する機能を持たせることも可能である。
　本実施例によれば、対象モデル105が含むCPUモデルのトレースから、CPUモデル1500上での関数呼び出しの開始と終了を検知し、他のプローブのコマンド実行部1062に対するコマンドにより停止コード挿入部1063を動作させ、該ミュレータの動作を停止させることにより、シミュレータの種類の如何に拘わらず、連携しているシミュレータ全体を停止させる。これにより、ユーザは、シミュレーション外部から任意のタイミングでその実行継続条件を注入することができ、組み込みシステムの全体とその構成要素間の相互の挙動について、詳細な情報の把握が容易になる。
　本発明の第３の実施例を、図１６を参照しながら説明する。  
　図５では、試験用プローブ106と対象モデル105間の接続方式の一例を述べた。本実施例は、対象モデル105がメモリ等である場合に、このメモリ等が含むバスモデルのトレースから他の試験用プローブ106に対するコマンドをトリガする手法を例示する。例えば、対象モデル105がメモリのとき、バスアクセストレース中のアドレス情報を利用する。
　特に、デジタル系のシミュレーションでは、メモリや通信等バス型接続(バスアクセス)1600が現れる。試験項目の記述性能を高めるためには、バス型接続でやり取りされるトランザクションをトレースし、それに同期したイベントでトリガをかけることが求められる
。コマンド実行部1062の内部には、メモリアクセストレース生成部1603がある。試験用プローブ106のコマンド実行部1062に、予め、メモリ空間上への変数のマップ情報を記述したメモリ空間マップ情報ファイル1605をもとに、各変数のメモリアドレスへの対応表としたアドレスDB1604を生成して入力する。試験進行制御部101は、そのメモリテスト用の試験用プローブ106に対して、メモリ上の特定の変数の変更に対するトリガを無効化・有効化することが可能である。
　対象モデル105内部で、バスマスタデバイス1601からバススレーブデバイス1602に対してバスアクセス1600が生じたとき、対象モデル105はバスアクセストレースを生じさせる。このバスアクセストレース中のアドレス情報を使って、コマンド実行部1062内部のメモリアクセストレース生成部1603はアドレスDB1604を検索する。該当の変数のトリガが有効化されていた場合、試験進行制御部101に対してトリガ成立メッセージを送信し、他のシミュレータの試験用プローブ106のコマンド実行を開始させることが可能になる。
　本実施例によれば、対象モデル105で生成されるバスアクセストレースから、変数のトリガ情報を検知し、他のプローブのコマンド実行部1062に対するコマンドにより停止コード挿入部1063を動作させ、該ミュレータの動作を停止させることにより、シミュレータの種類の如何に拘わらず、連携しているシミュレータ全体を停止させる。これにより、ユーザは、シミュレーション外部から任意のタイミングでその実行継続条件を注入することができ、組み込みシステムの全体とその構成要素間の相互の挙動について、詳細な情報の把握が容易になる。
　10…協調シミュレーション用計算機システム、100…シミュレーション統合コントローラ、101…試験進行制御部、103…非同期ネットワーク、104(1)～104(N) …検証対象シミュレーション、105（0）～105(N)…検証対象モデル、106（0～M）…試験用プローブ部、107…入力部、108…出力部、111…データ交換用ネットワーク、120…データベース（DB）、160…車載ネットワーク、200…機械系・センサ系のモジュール、201…エンジン、202…ブレーキ、210…電子制御ユニット、211…エンジンECU、212…ブレーキECU、220…車載通信コントローラ、230…車載ネットワーク、0600…通信プロトコル、1010…試験項目解釈部、1011…試験項目待ち行列、1012…通信I/F部、1013…期待値判定部、1060…通信I/F、1061…コマンド解釈部、1062…コマンド実行部、1063…停止コード挿入部、1064…試験項目待ち行列、10120…パケット通信制御機能、10420…通信シミュレータ。

Claims (15)

  1. 　協調して動作する複数のシミュレータとこれら検証対象の複数のシミュレータを制御するシミュレーション統合コントローラとを備え、
    　前記シミュレーション統合コントローラと前記各シミュレータとが、非同期通信により前記複数のシミュレータの全体の動作を一時停止・再開させる機能を共有しており、
    　前記いずれか１つのシミュレータに設定されている停止条件が成立したことによって前記複数のシミュレータの全体を一時停止させ、該一時停止の間に少なくとも１つの前記シミュレータの状態の取得又は状態の書き換えを行う
    ことを特徴とする協調シミュレーション用計算機システム。
  2. 　請求項１において、
    　システム共通の通信プロトコルとして、前記全てのシミュレータにおけるイベントの操作・トリガを同一に扱うための試験記述フォーマットを保有しており、
    　前記各シミュレータは少なくとも１つの試験用プローブ部と対象モデルとを備えており、
    　前記シミュレーション統合コントローラと前記各シミュレータの試験用プローブ部との間で、前記通信プロトコルにより非同期に通信を行い前記各シミュレータにおけるシミュレーションの起動・停止を行う
    ことを特徴とする協調シミュレーション用計算機システム。
  3. 　請求項２において、
    　前記複数のシミュレータは、組み込みシステムのメカニズムに対応する機械・センサ系シミュレータと、前記組み込みシステムのマイコン系シミュレータとが連携して動作する仮想検証環境として構成されており、
    　前記複数のシミュレータは、異なる種類のシミュレータを含んで構成されており、
    　前記通信プロトコルは、前記異なる種類のシミュレータが等価的にイベントを実行できる共通フォーマットで構成されている
    ことを特徴とする協調シミュレーション用計算機システム。
  4. 　請求項２において、
    　前記シミュレーション統合コントローラは、前記各シミュレータの前記試験用プローブ部と非同期に通信する試験進行制御部を備えており、
    　該試験進行制御部は、前記実行される試験項目の生成を行い、接続された前記複数のシミュレータの各々に対し、前記通信プロトコルにより前記試験項目の送信と該試験項目の実行結果の受信を行う
    ことを特徴とする協調シミュレーション用計算機システム。
  5. 　請求項４において、
    　前記試験用プローブ部は、前記各シミュレータ内部に仮想モジュールとして配置され、前記対象モデルによる前記試験項目の実行と前記全てのシミュレータの停止を行う機能を有している
    ことを特徴とする協調シミュレーション用計算機システム。
  6. 　請求項３において、
    　前記試験用プローブ部は、前記シミュレータのデータ同期通信部に介入し擬似的な受信遅延を発生させることで前記複数のシミュレータを連鎖的に停止させる、停止コード挿入部を備えている
    ことを特徴とする協調シミュレーション用計算機システム。
  7. 　請求項３において、
    　前記停止コード挿入部は、前記対象モデルが含むCPUモデルのトレースから、前記他の試験用プローブに対するコマンドにより連携している前記複数のシミュレータ全体を連鎖的に停止させる
    ことを特徴とする協調シミュレーション用計算機システム。
  8. 　請求項３において、
    　前記停止コード挿入部は、前記対象モデルが含むバスモデルのトレースから前記他の試験用プローブに対するコマンドにより連携している前記複数のシミュレータ全体を連鎖的に停止させる
    ことを特徴とする協調シミュレーション用計算機システム。
  9. 　請求項３において、
    　前記試験進行制御部は、
    　ユーザが予め決められた規則で記述した試験項目フォーマットを受け取って解釈する試験項目解釈部と、
    　該解釈された試験項目列を蓄積し順番に実行する試験項目待ち行列と、
    　前記複数のシミュレータに各々少なくとも１つ存在する試験用プローブと接続され、前記試験項目と前記試験結果、及びトリガ成立イベントをやり取りするための通信I/F部と、
    　前記各試験項目の実行結果を蓄積し、前記試験項目フォーマット中に記述された期待値との判定を行い、その結果を試験結果として出力する期待値判定部とを備えている
    ことを特徴とする協調シミュレーション用計算機システム。
  10. 　請求項９において、
    　前記通信Ｉ／Ｆ部は、パケット通信制御機能を備えており、前記試験進行制御部と前記各シミュレータの前記試験用プローブとの間で、前記共通の通信プロトコルによるパケット通信を行う
    ことを特徴とする協調シミュレーション用計算機システム。
  11. 　請求項３において、
    　複数の検証対象シミュレータは、ドメインの異なるシミュレータを含んで構成されている
    ことを特徴とする協調シミュレーション用計算機システム。
  12. 　協調シミュレーション用計算機システムを用いた組み込みシステムの検証方法であって、
    　前記協調シミュレーション用計算機システムは、シミュレーション統合コントローラと、複数の検証対象のシミュレータとを備えており、
    　前記複数の検証対象のシミュレータは、前記組み込みシステムのメカニズムに対応する機械・センサ系シミュレータと、前記組み込みシステムのマイコン系シミュレータとが連携して動作する仮想検証環境として構成されており、
    　前記シミュレーション統合コントローラと前記各シミュレータは、システム共通の通信プロトコルとして、前記全てのシミュレータにおけるイベントの操作・トリガを同一に扱うための試験記述フォーマットを保有しており、非同期通信により、前記複数のシミュレータの全体の動作を一時停止・再開させる機能を共有しており、
    　協調シミュレーションにより前記対象モデルによる試験項目を実行し、
    　前記いずれか１つのシミュレータに設定されている停止条件が成立したとき、前記複数のシミュレータの全体を一時停止させ、
    　該一時停止の間に前記少なくとも１つのシミュレータの状態の取得又は状態の書き換えを行い、
    　前記協調シミュレーションによる前記試験項目の実行結果を蓄積し、該実行結果の判定を行い、その結果を出力する
    ことを特徴とする組込みシステムの検証方法。
  13. 　請求項１２において、
    　前記複数の検証対象のシミュレータは、異なる種類のシミュレータを含んで構成されており、
    　前記各シミュレータは少なくとも１つの試験用プローブ部と対象モデルとを備えており、
    　前記シミュレーション統合コントローラが、前記各シミュレータの試験用プローブ部との間で、システム共通の通信プロトコルにより非同期に通信を行い、前記各シミュレータにおけるシミュレーションの起動・停止を行う
    ことを特徴とする組込みシステムの検証方法。
  14. 　請求項１３において、
    　前記試験用プローブ部が、前記シミュレータのデータ同期通信部に介入し擬似的な受信遅延を発生させることで前記複数のシミュレータを連鎖的に停止させる
    ことを特徴とする組込みシステムの検証方法。
  15. 　協調シミュレーション用計算機システムで動作する協調シミュレーション用プログラムであって、
    　前記協調シミュレーション用計算機システムは、複数個の計算機がネットワークにより接続されたクラスタ型の計算機システムであり、協調して動作する複数のシミュレータとこれら検証対象の複数のシミュレータを制御するシミュレーション統合コントローラとを備えており、
    　前記シミュレーション統合コントローラと前記各シミュレータとが、非同期通信により前記複数のシミュレータの全体の動作を一時停止・再開させる機能を共有しており、
    　前記計算機に、
    　協調シミュレーションにより前記対象モデルによる試験項目を実行させる手順、
    　前記いずれか１つのシミュレータに設定されている停止条件が成立したとき、前記複数のシミュレータの全体を一時停止させる手順、
    　該一時停止の間に前記少なくとも１つのシミュレータの状態の取得又は状態の書き換えを行う手順、及び
    　前記協調シミュレーションによる前記試験項目の実行結果を蓄積し、該実行結果の判定を行い、その結果を出力する手順を実行させるためのプログラム。
PCT/JP2012/078396 2011-12-28 2012-11-01 協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム WO2013099438A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011-288339 2011-12-28
JP2011288339A JP5882052B2 (ja) 2011-12-28 2011-12-28 協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2013099438A1 true WO2013099438A1 (ja) 2013-07-04

Family

ID=48696938

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/078396 WO2013099438A1 (ja) 2011-12-28 2012-11-01 協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム

Country Status (2)

Country Link
JP (1) JP5882052B2 (ja)
WO (1) WO2013099438A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10360322B2 (en) 2015-12-01 2019-07-23 International Business Machines Corporation Simulation of virtual processors
JP2019532429A (ja) * 2016-11-02 2019-11-07 日立オートモティブシステムズ株式会社 計算機システム、テスト方法、および記録媒体
JP2021043976A (ja) * 2019-09-12 2021-03-18 バーチャル ヴィークル リサーチ ゲーエムベーハー メカトロニックシステムのシミュレーションのための操作手順を生成する方法
CN113759245A (zh) * 2021-09-14 2021-12-07 许昌开普检测研究院股份有限公司 基于统一硬件平台的继电保护静模测试和动模测试方法

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6523928B2 (ja) * 2015-11-17 2019-06-05 株式会社東芝 仮想試験システム、仮想試験方法およびプログラム
US11314907B2 (en) * 2016-08-26 2022-04-26 Hitachi, Ltd. Simulation including multiple simulators
JP6771664B2 (ja) * 2017-05-02 2020-10-21 三菱電機株式会社 試験装置、試験システム、試験方法、および、プログラム
JP7141508B1 (ja) * 2021-10-15 2022-09-22 株式会社ネクスティエレクトロニクス 協調シミュレーションシステム、協調制御方法、協調制御器及びコンピュータプログラム

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001282327A (ja) * 2000-03-31 2001-10-12 Omron Corp シミュレーションシステム及びシミュレータ並びに管理サーバ及び記録媒体
JP2008084121A (ja) * 2006-09-28 2008-04-10 Fujitsu Ten Ltd シミュレーションシステム及びシミュレーション方法
JP2008209993A (ja) * 2007-02-23 2008-09-11 Hitachi Ltd 表作成装置、表作成方法、及び、プログラム
JP2010033130A (ja) * 2008-07-25 2010-02-12 Internatl Business Mach Corp <Ibm> シミュレーション方法、システム及びプログラム
JP2010073091A (ja) * 2008-09-22 2010-04-02 Nec Electronics Corp シミュレーション装置
JP2010191480A (ja) * 2007-06-01 2010-09-02 Mitsubishi Electric Corp シミュレーションシステム
JP2011034274A (ja) * 2009-07-31 2011-02-17 Hitachi Solutions Ltd テスト自動実行システム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04195436A (ja) * 1990-11-28 1992-07-15 Hitachi Ltd 計算機システム自動テスト方式
JPH0916244A (ja) * 1995-07-04 1997-01-17 Sanyo Electric Co Ltd シミュレーション方法および装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001282327A (ja) * 2000-03-31 2001-10-12 Omron Corp シミュレーションシステム及びシミュレータ並びに管理サーバ及び記録媒体
JP2008084121A (ja) * 2006-09-28 2008-04-10 Fujitsu Ten Ltd シミュレーションシステム及びシミュレーション方法
JP2008209993A (ja) * 2007-02-23 2008-09-11 Hitachi Ltd 表作成装置、表作成方法、及び、プログラム
JP2010191480A (ja) * 2007-06-01 2010-09-02 Mitsubishi Electric Corp シミュレーションシステム
JP2010033130A (ja) * 2008-07-25 2010-02-12 Internatl Business Mach Corp <Ibm> シミュレーション方法、システム及びプログラム
JP2010073091A (ja) * 2008-09-22 2010-04-02 Nec Electronics Corp シミュレーション装置
JP2011034274A (ja) * 2009-07-31 2011-02-17 Hitachi Solutions Ltd テスト自動実行システム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10360322B2 (en) 2015-12-01 2019-07-23 International Business Machines Corporation Simulation of virtual processors
US11010505B2 (en) 2015-12-01 2021-05-18 International Business Machines Corporation Simulation of virtual processors
JP2019532429A (ja) * 2016-11-02 2019-11-07 日立オートモティブシステムズ株式会社 計算機システム、テスト方法、および記録媒体
US10810111B2 (en) 2016-11-02 2020-10-20 Hitachi Automotive Systems, Ltd. Computer system, test method, and recording medium
JP2021043976A (ja) * 2019-09-12 2021-03-18 バーチャル ヴィークル リサーチ ゲーエムベーハー メカトロニックシステムのシミュレーションのための操作手順を生成する方法
JP7111425B2 (ja) 2019-09-12 2022-08-02 バーチャル ヴィークル リサーチ ゲーエムベーハー メカトロニックシステムのシミュレーションのための操作手順を生成する方法
US11630931B2 (en) 2019-09-12 2023-04-18 Virtual Vehicle Research Gmbh Method of generating an operation procedure for a simulation of a mechatronic system
CN113759245A (zh) * 2021-09-14 2021-12-07 许昌开普检测研究院股份有限公司 基于统一硬件平台的继电保护静模测试和动模测试方法

Also Published As

Publication number Publication date
JP2013137658A (ja) 2013-07-11
JP5882052B2 (ja) 2016-03-09

Similar Documents

Publication Publication Date Title
JP5882052B2 (ja) 協調シミュレーション用計算機システム、組込みシステムの検証方法及びプログラム
JP5153465B2 (ja) シミュレーション方法、システム及びプログラム
JP5179249B2 (ja) 制御装置シミュレーション方法、システム及びプログラム
EP3287901A1 (en) Simulation including multiple simulators
JP2007510992A (ja) 制御システムをシミュレーションおよび検証するためのシミュレーションシステムおよびコンピュータにより実施される方法
CN104460646B (zh) 用于对虚拟控制器进行实时测试的测试装置
CN102124448B (zh) 控制嵌入式系统开发期间的实时性
US8498856B2 (en) Simulation method, system and program
US20080183456A1 (en) Method for Testing an Electronic Control System
US11022967B2 (en) Method for generating a technical system model, executable on a test unit, and the test unit
US11366945B2 (en) Soft-real-time hub providing data transport for processor-in-the-loop (PIL) simulations
WO2014196059A1 (ja) マイコン故障注入方法及びシステム
Pohlmann et al. Generating functional mockup units from software specifications
CN112166428A (zh) 用于系统的基于事件的模拟的方法
Haberl et al. Model-level debugging of embedded real-time systems
JP5186290B2 (ja) シミュレーション方法、システム及びプログラム
Garcés et al. A model-based approach for reconciliation of polychronous execution traces
EP4036780A1 (en) Electronic control unit timing emulation
Krisp et al. Automated real-time testing of electronic control units
Resmerita et al. Verification of embedded control systems by simulation and program execution control
Verhoef et al. Interpreting Distributed System Architectures Using VDM++-A Case Study
Di Natale et al. Matching execution architecture models with functional models to analyze the time performance of CPS systems
US20210141710A1 (en) Development support device
Safar et al. Virtual electronic control unit as a Functional Mockup Unit for heterogeneous systems
KR20240009766A (ko) 차량용 소프트웨어 플랫폼의 시뮬레이션을 위한 네트워크 가상화 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12861490

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12861490

Country of ref document: EP

Kind code of ref document: A1