Object Activation Example

It is often convenient to divide large system models into multiple, separately developed, sub-system models that interact. This also occurs for example, when attempting to combine existing models - sometimes called legacy models, of system components that were separately developed. The sub-system-, or component-, models must exchange data with each other and must coordinate events. For example, one sub-system may wait for specific events in other sub-systems. An event in one system may activate another system which in turn may need to receive data about/with the event.

CSIM provides several mechanisms for coordinating sub-system models and passing data between them. One method is to use CSIM's block diagrams to connect system segments with SEND/RECEIVE calls in the code to pass messages or activate cooresponding model elements. However, this method does not apply to all situations.

Another method is to use CSIM's Synchron mechanism to wait for events (WAIT), trigger events in other models (RESUME), and to pass data structures with the events. The models can create and share Synchron variables by unique names according to the events of interest. This method does not require diagram connections, and can be dynamic.

A related but more dynamic approach is to use the Named-Synchron mechanism to publish-and-subscribe to information or events by names. A further refinement is to use a dispatcher that enables filtering the published events according to appropriate rules.

Consider a distributed model of a warehousing complex. There are separately written models of suppliers (manufacturers), shippers, storage, inventory control systems, retailers and customers, as well as models of the stored items. Inventory control wishes to receive information about every arrival and outbound shipment, while publishing orders to all/any interested suppliers. A particular supplier is interested in receiving orders for only two kinds of items. Another supplier wishes to receive all orders.

One approach would be to use separate Synchrons for each kind of item to be ordered. The second supplier would need to explicitly subscribe to each of them. Both models would need to know all the possible item names.

Another approach would be to use a naming convention, such as order_itemName. This would enable the suppliers to become aware of all orders, and then to choose which ones to subscribe to. A variation on this method is to create a class of Orders using one synchron, and then in the data structure passed with each order would be the name of the item. The suppliers, or an intermediate dispatcher, could then filter the items of interest. For example, a supplier may be interested in shipping only to warehouses within the same state.

The best scheme depends on the degree of flexibility needed versus efficiecy. Late-binding provides maximum flexibility, but causes more run-time processing. If we know that all suppliers will only provide mutually exclusive items, then it would be more efficient to use separate synchron names for suppliers or items.

Distributed Simulation

The discussion above assumes that all models run on the same simulation host. However, it is possible that some models will run on separate computers, yet they still need to share events and communicate messages. The synchron methods can still be used, but an inter-process network communication method, such as IPC-Sockets, must be used between them. (This method will work the same whether the component models run on the same computer or separate ones.) CSIM's WormHole mechanism is useful for quickly connecting and coordinating distributed simulation models this way.

Other related methods include HLA and MSI, which provide sophisticated publish/subscribe and event coordination methods.

(Questions, Comments, & Suggestions: admin@csim.com)