Isight Components for Co-Simulation

Any Isight component can be placed in a co-simulation group within a simulation flow. There is no special flag or designation (other than being placed in a co-simulation group) that marks a component as being capable of co-simulation. You could, for example, place a script component into a co-simulation group and implement some co-simulation communications in the body of the script. It is also possible to implement some co-simulation functionality in a component’s prologue or epilogue script.

If a particular component has no co-simulation capability, it will run normally as part of a co-simulation group—it will simply not participate in any communications with the other components of the group. Since Isight and the SIMULIA Execution Engine do not know what the runtime behavior of the component will be (and it may even be configurable), Isight does not attempt to distinguish which components are capable of co-simulation.

A component that is capable of co-simulation is an ordinary Isight component in every way—it has an editor class for design time, an executor class for run time, an optional handler class, an XML descriptor, etc. All other features and functions of Isight components apply to co-simulation components as well.

What distinguishes a co-simulation component is how it behaves at run time. It establishes communications with the other components in the co-simulation group. When you develop your co-simulation components (simulation codes), you decide the paths and protocols used for the communication between the components. Each component may be running on a different host computer; for example, on different SIMULIA Execution Engine stations. The SIMULIA Execution Engine infrastructure does not dictate how the components establish communications or what protocol is used. All components in the co-simulation group must agree on the intergroup mechanisms they will use to talk to each other. Protocols such as MPI are commonly used for this purpose, as are plain TCP/IP socket based protocols.

The SIMULIA Execution Engine infrastructure does supply some runtime services that co-simulation components can use to discover each other and to exchange messages containing details needed to establish communication paths. For example, the communications protocol may require that each component have the host name and port number of all other components running in the co-simulation. This information might then be used to open socket-based communication paths between the components. The SIMULIA Execution Engine infrastructure provides only the means for the components to exchange the communications parameters but does not provide any high volume direct communications support.

The message-exchange mechanism provided by the SIMULIA Execution Engine is a type of bulletin board. Your co-simulation components can use the runtime bulletin board service to discover the other components in the group and to exchange short, low-volume messages. A component can also discover how many members exist in the co-simulation group.