Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F30/00—Computer-aided design [CAD]
  • G06F30/30—Circuit design
  • G06F30/32—Circuit design at the digital level
  • G06F30/33—Design verification, e.g. functional simulation or model checking

Definitions

• the invention relates to a co-simulation apparatus and method.
• Co-simulation is a tool used in many areas where complex simulation is required, for example vehicle engine performance.
• co-simulation comprises using multiple, linked simulation tools each simulating a component of a complete system to simulate the complete system.
• Co-simulation is particularly useful when no single simulation tool has the capability to model the entire system adequately - instead each linked simulation tool simulates one or more aspects of a system for which it is specifically designed.
• Each individual simulation tool comprises, typically, a computer application program for building and running a mathematical model of the aspect of the system that is being simulated in order to make predictions as to how that aspect of the system will behave.
• Various co-simulation tools are known. Typically in such tools a data link is established between two simulations and the data link is used to transfer information between the simulations at regular intervals as each simulation independently advances in time. For example where the physical response of an engine is simulated in the first simulation and engine control software is simulated in a second simulation then each simulation regularly updates the other as to its current operational status in order that the simulations proceed in tandem.
• inter-process communication has been used, for example, for linking Simulink from The Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with ADAMS, STAR-CD with FlowMaster, from the Math Works (used to model general dynamic systems) with
• FlowMaster Group used to model fluid and thermal systems
• WAVE used to predict performance and noise from automotive engines
• VECTIS VECTIS
• a specific code bridge is provided between the two simulations with interface code specific to the bridge embedded in each simulation such that the simulations share data as and when required.
• Various methods can be used for launching and synchronising the simulations and exchanging data and specific link types such as mechanical, fluid, control and thermal have been defined. As a result large simulations can co-simulate with little modification.
• this mechanism allows a chain of links between simulations.
• a co-simulation includes three simulations 10, 12, 14, termed here SIMl, SIM2, SIM3.
• SIMl is a parent of SIM2
• SIM2 is a parent of SIM3.
• a problem with co- simulation based on inter-process communication is that communication is only possible between simulations that are in a parent-child relationship. Accordingly a "grandparent" relationship between SIMl and SIM3 shown by dotted line 20 is not possible. Accordingly, if three simulations are linked in a chain, each one can only communicate with individual neighbours in the chain for example by link 16, 18.
• FIG. 2 An alternative possible inter-communication configuration is shown in Fig. 2 in which three simulations SIMl, SIM2 and SIM3 are arranged in a tree.
• SIMl (30) is parent to SIM2 (32) and SIM3 (34) via respective links 36,
• inter-process communication is not a viable mechanism for linking multiple simulations together with full interactivity.
• Fig. 1 is a block diagram showing a first known co-simulation architecture
• Fig. 2 is a block diagram showing a further known co-simulation architecture
• Fig. 3 is a block diagram showing co-ordination of a co-simulation according to the present invention
• Fig. 4 is a block diagram showing a co-ordination module according to the present invention
• Fig. 5 is a flow diagram showing an initialisation phase of the method according to the present invention.
• Fig. 6 is a block diagram showing communication between a co-ordination module, multiple simulation modules and a user interface according to the present invention.
• a hub 50 comprises a co- simulation control or co-ordination module and communicates with simulation modules SIMl to SIM6 52, 54, 56, 58, 60, 62.
• the co-ordinating module 50 is connected to each of the simulation modules by respective links 64, 66, 68, 70, 72, 74.
• the co-ordination module 50 is a control process or program that does not itself carry out any simulation but manages the connectivity and data flow within the co-simulation.
• the co-ordinating module 50 is responsible for launching and connecting to all the simulations and all simulation models connect back only to the co-ordination module. Each simulation module has no way of determining what other simulations it is connected to and "see" only the co-ordination module at the other end of the link.
• the co-ordination module 100 includes a data communication module 102 having a plurality of interfaces 104 for communication with respective simulation modules.
• the data communication module is connected to a processor 106 which contains the control logic for managing the co-simulation as discussed in more detail below.
• the processor 106 is also connected to data storage means 108 for storing data relating to the control and operation of the co-simulation.
• user input means 110 are provided allowing control of the co-simulation via the co-ordination module by an administrator.
• the co-ordination module 100 further comprises a display 112 or other data representation means allowing progress of the co- simulation to be observed.
• the co-ordination module detects connection with a simulation module which triggers entry into a query mode in step 132 supported by the co-ordination module and each simulation module.
• the co-ordination module receives link type and link identifier information from the simulation module.
• the co-ordination module can determine the communication protocol required for data exchange with and control of the simulation module and can also establish which other simulation modules require a "virtual" link via the co-ordination module.
• the co ⁇ ordinating module commences data and control communication with the simulation module via the established link. Accordingly, when co-ordinating a full co-simulation, to effect data exchange the hub program at the co-ordination module will associate links from one simulation with corresponding links from another. Each individual simulation is unaware of any other part of the co- simulation and can hence run without modification under the control and co- ordination of the hub program. Subsequently to effect data exchange the hub program first reads all links, storing the data internally. It then organises the data according to the connectivity and then writes back to all links.
• the co-ordination module 100 communicates with multiple simulation modules of which only two are shown in Fig. 6, reference numerals 200 and 202.
• the co-ordination module communicates with a user interface for example a PC 212.
• the co-ordination module 100 sends control commands 204, 206 to each simulation module 200, 202 and also exchanges data 208, 210 with each simulation module 200, 202.
• the co ⁇ ordination module 100 exchanges control commands 214 and data 216 with the user interface 212.
• the data received by the co-ordination module 100 comprises connectivity information concerning the simulation module in the initiation phase and, thereafter, the current status of the simulation running on the simulation module e.g. the simulation outputs.
• the data sent from the co-ordination module to the simulation module comprises outputs, if necessary suitably processed, from other simulations that will affect operation of the simulation as control inputs. This is represented in Fig. 6 by the dotted line 218 representing a virtual link between simulations.
• the control commands from the co- ordination module 100 to each simulation module comprise instructions concerning running of the simulation, the period for which the simulation should run, the time increments between reports from simulation concerning its current state and outputs, the setting of parameters shared by the individual simulations and any other tasks relating to co-ordination of the co-simulation as a whole.
• the processor 106 (Fig. 4) processes the received data in the co-ordination module and determines where the information should be sent as well as co-ordinating control of the co-simulation as a whole and ensuring that the appropriate control commands are sent to the appropriate simulations.
• the interface can comprise any appropriate graphic user interface such as a monitor, printout or other data representation allowing a co-simulation administrator to monitor progress of the co- simulation.
• control commands can be sent to the co-ordination module to allow adjustments to parameters such as state parameters of the entity being co-simulated, period for running the simulation, incremental update periods introduction of further simulation modules and so forth. Accordingly, as discussed above, the co-ordination module has the ability to monitor and display all exchanged data in addition to the main task of managing the connections.
• the co-simulation can be in relation to any type of simulated entity.
• the co-ordination module and simulation modules are shown as separate physical devices they can be run in software on a common machine as appropriate. In that case the various modules can be implemented in any appropriate manner and code. Alternatively the various modules can be implemented in hardware either on a common physical entity or on networked entities. Yet further the various simulations and/or the co ⁇ ordination module can be distributed remotely, communicating by any appropriate means such as a WAN (Wide Area Network) or the Internet.
• WAN Wide Area Network

Landscapes

• Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Evolutionary Computation (AREA)
• Geometry (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Management, Administration, Business Operations System, And Electronic Commerce (AREA)
• Debugging And Monitoring (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=33523248

Family Applications (1)

Country Status (4)

Families Citing this family (3)

Family Cites Families (1)

• 2004
  • 2004-11-05 GB GB0424501A patent/GB0424501D0/en not_active Ceased
• 2005
  • 2005-11-03 JP JP2007539633A patent/JP2008519346A/ja not_active Withdrawn
  • 2005-11-03 EP EP05801537A patent/EP1817701A1/en not_active Withdrawn
  • 2005-11-03 WO PCT/GB2005/004251 patent/WO2006048653A1/en active Application Filing

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events