On the HLA- and Internet-based Coupling of Commercial Simulation Tools For Production Networks

Abstract

The recent development of the High Level Architecture for Modeling and Simulation (HLA) has stimulated interest in the use of distributed, interoperable simulation models. This paper deals with the application of HLA-based coupling of simulation tools in the area of production networks. Results of several performance measurements will be used to discuss the problems that we detected during our tests. The paper will draw conclusions on how the integration of HLA and Internet technologies can enhance the application of distributed simulation in general and how they could be used for the simulation of production networks in specific.

Keywords

Discrete Event Simulation, Distributed Simulation, High Level Architecture, SLX, AutoMod, Production Network.

Introduction

Today it is essential to increase the efficiency of businesses at every opportunity. To meet customer demands, production networks are discussed in industry (Bryne 1993, Davidow 1992, Wiendahl 1996). Production networks are temporary networks that occur to respond to an customer order. This places high demands on the computer network, the Internet or Intranet. This paper describes how the Internet can be used to connect commercial simulators such as AutoMod and SLX. This makes it very efficient to simulate customer orders throughout the production network, without additional effort in modeling and simulation. Manufacturers and simulation specialists who are part of the network, bring their simulation capacity into the network, but they do not have to give away the know-how of their models. Thus new levels of collaboration can be achieved.

Recently, the area of simulator interoperability has been given a new momentum by the evolution of the High Level Architecture for Modeling and Simulation (HLA). The High Level Architecture is a simulation interoperability standard currently being developed by the US Department of Defense (Department of Defense 1996).

This paper focuses on how one connects different commercial simulators. An investigation on commercial simulators with respect to HLA shows two distinguished classes: open event loop and closed event loop simulators. As a base for the coupling we developed a meta model containing a dynamic model for the coordination, and an object model that stores the orders a federate places to another federate in the production network. As an example we implemented three federates in AutoMod and in SLX. AutoMod is an example of a closed event loop simulator and SLX of an open event loop simulator. Experiences with the development of a model independent HLA-connection for SLX will also be described. This solution will be compared with a similar approach for the AutoMod system.

Production Networks

In (Wiendahl 1996) production networks are defined as a unity of companies which can be dynamically re-organised according to an order. Each company concentrates on their core business and, thus, these networks can be seen as a unity of the best.

Information and Material Flows

In this paper we will concentrate on the information and the material flow of production networks. Figure 1 shows the flows among the companies. The information flow goes down stream and the material flow up stream.

Figure 1: A part of a production network

Assuming that each company has its own simulation model we have to provide mechanisms to guarantee the flows.

Time Management

A central problem in production networks is the coordination. The execution of customer orders in production networks is highly parallel per se. Therefore in a production network, where different simulators are used for modeling different elements of the network it is vital to think carefully about how to synchronize the simulators.

Traditionally discrete event simulation tools use global event lists for keeping track of all scheduled events. All events are executed in a global time stamp order. The simulator also takes care of the repeatability of the results, when events with the same time stamp occur. The same is very important for a distributed version of the simulation model (Fujimoto 1997).

Different parallel simulation protocols have been developed in the past (Fujimoto 1990). They can be classified into conservative and optimistic ones. The conservative ones need to process in time stamp order, whereas the optimistic ones allow out of order processing as long as the resulting state reflects the effect of executing the events in their time stamp order. Otherwise rollback mechanisms have to be applied.

For our experiments we used HLA as the latest development in the area of distributed simulation. The architecture is defined by:

rules which govern the behavior of the overall distributed simulation (Federation) and its members (Federates).

an interface specification, which defines the interface between each federate and the Runtime Infrastructure (RTI), a supporting software component that is responsible for providing communication and coordination services to the federates.

an Object Model Template (OMT) which defines how federations and federates have to be documented.

HLA offers mechanisms for all the synchronization problems mentioned above. In our work and the testing we applied a conservative protocol with lookahead. This approach was chosen because the simulation tools that were used in our tests do not offer any built-in support for optimistic protocols.

A Meta-Model in HLA

From the modeling point of view a production network can be seen as a graph consisting of a set of vertices and a set of edges. Each vertex depicts a company and has ability to carry out orders and to place orders to others. Thus the orders are the edges of the graph. So we model two classes. The company class is identified by a name and a set of products. In the order class the attributes number and type clarify what product should be assembled to what amount. The information and material flow is managed by the attributes due date and delivery date. Figure 2 shows the two classes. This is our meta-model.

Figure 2: Order and company classes

The HLA federation consists of both classes for which each participant has to publish and subscribe. To start a new simulation each simulator creates an instance of the company class. When all the simulators have joined the federation, order objects can be created. To send an order a simulator has to register the new object. The receiver takes the ownership of the attribute delivery date. The sender is notified of the fulfilment of an order by writing the delivery date into that attribute. The order object is destroyed by the sender.

Figure 3: Realization of the meta-model in HLA

In HLA it is distinguished between remote and local objects. As shown in figure 3 federates are informed by the federation management about the instances of order and company classes created by other federates. These objects are remote objects. As a logical consequence each federate holds all objects of the federation. It is the task of the federation management to keep the federates informed about ongoing changes in existence and state of the objects.

In our case the model consists of three company objects and one order object. The order is placed by Simulator A and therefore this object is a local one. The arrow to the federation management indicates that changes in the model are sent to the federation management by the view object the RTIambassador. The arrow to the controller objects the FederateAmbassodor shows that the federation management passes all changes to each federate.

HLA Interface of Simulation Tools

HLA defines a two-part interface which federates are required to use for communicating with the Runtime Infrastructure (RTI).

General Approach

The HLA interface is based on an ambassador paradigm. A federate communicates with the RTI using its RTI ambassador. Conversely, the RTI communicates with a federate via the federate’s ambassador. From the federate programmer’s point of view these ambassadors are objects and the communication between the participants is performed by calling methods of these objects.

In order for commercial simulation tools to fit into this ambassador paradigm it is a good approach to use wrapper libraries (Straßburger et. al 1998). The wrapper library has the task to translate between the RTI functionality and the capabilities of the simulation tool (Figure 4).

Figure 4: Using wrapper libraries for connecting simulation tools to the RTI

While the wrapper library can take care of the software technological connection to the RTI, it is also necessary to consider the problems that result from the simulation side. The next section deals with the problems resulting from being member of a distributed simulation and gives a classification of simulation tools regarding their capabilities to process external events.

Open Event Loop vs. Closed Event Loop

Participants in a distributed simulation have to coordinate their local advances in logical simulation time. To do so they have to take into account their mutual dependencies.

The HLA approach includes a transparent time management that allows federates to coordinate their logical simulation clocks.

In order for this to work, the RTI requires federates to request their time advances by calling the appropriate methods of the RTI ambassador object. Issuing such a request may result in

a grant of the request

a notification about an external event, that needs to be processed prior to the local event that the request was issued for.

This is the place where our research shows that it is necessary to distinguish between two types of simulators:

Open event loop simulators

Closed event loop simulators

Open event loop simulators allow the user to integrate the external event in the local events chain. The external event can then be processed. Afterwards the simulation tool can proceed with the next local event.

An example for an open event loop simulator is SLX (Henriksen 1996, 1997). Our solution for SLX is very straight-forward (Figure 5): The user issues a nextEventRequest for a local event. If an external event needs to be processed, the return value of the function is the time stamp of this event. If no external events where received, the return value equals the time stamp of the request. In the former case, the simulator is told to advance to the time stamp of the external event and to process it. In the latter case the simulator can proceed without interruption to the time stamp of the local event.

While (simulation still in pogress) do Tlocal = next local event to be processed nextEventRequest( Tlocal ) if (grant time < Tlocal ) then /* process an external event */ else /* process the local event */ end if End while

Figure 5: Merging external and local events

Closed event loop simulators do not allow the integration of external events into the events chain of the simulator. They may not even have a built-in function to determine the time stamp of the next local event. Examples for such tools are AutoMod (Norman 1992, AutoSimulations Inc. 1993) and ProModel (ProModel Corporation 1997).

For this type of simulator we suggest a different approach for synchronization. Since we are not able to determine the time of the next local event we use the nextEventRequest with a virtual next event time. Synchronization occurs in intervals of T time units. All outgoing events (like sending orders or requests) for the time T+t are bundled before their release. Thus the parameter T directly determines the bundling size (Figure 6).

While (simulation still in pogress) do Tlocal = next virtual event nextEventRequest( Tlocal ) if (grant time < Tlocal ) then /* wait for (grant time – local time) */ /* get orders from the federation */ else /* wait for ( Tlocal – local time) */ /* set orders to the federation */ end if End while

Figure 6: Bundling events in closed event loop simulators

Unfortunately, this approach leads to certain inaccuracies in the simulations. Large values for T result in an increasing performance but in the same time in increasing inaccuracies of the simulation results.

A very important issue is how to control and verify these inaccuracies. In the application area of production networks it is not unusual to bundle customer orders before they are released. Thus we can extract the step size T from the simulation model (Figure 7). Testing the inaccuracies was not subject of the testing phase.

Figure 7: Work batches in production

Testing the Performance

It is obvious that a distributed simulation environment can enhance the speed or performance of simulation. However, in our case we deal with commercial simulators and a distribution of models that comes from the problem domain. We aim at finding the bottleneck and factors to enhance speed of the simulation. A main focus of our tests was how open event loop simulators perform in contrast to closed event loop simulators. Additionally, the influence of the internet is measured.

Figure 8: Screenshots obtained during the preparation phase

For our performance measurements we used a simplified model configuration which allows us to perform tests with 2 and 3 federates. The federates have the following tasks:

Federate A: supplier

Federate B: shipping agency

Federate C: assembly

In the configuration with 3 federates the shipping agency is responsible for delivering the orders between federates A and C. In the 2 federates configuration the transport is performed by A and C directly.

In a distributed simulation it is important to have a high degree of parallel processing. In HLA this can be achieved by increasing the value of the lookahead. Additionally important for the performance is the complexity of the calculations that is performed inside the federates. We simulate this complexity by applying sleep instructions which do not consume simulation time. Communication refers to how frequently customer orders appear in the system. Table 1 shows the values of the different factors and how they were changed during the tests.

Assuming that the assembly line places exactly 20 orders per 100 time units and either supplier, shipping agency and assembly line are able to perform the order we can expect an all in one model to perform 400 time units in 160 sec in the case of complexity 1 and 960 sec in the case of 6.

In our first test setup we used a Pentium 120 computer with 64 MB memory running Windows NT 4.0 and the DMSO RTI 1.0.3. All federates were executed on a single computer. Figure 8 shows screenshots obtained during the preparation phase. For the actual performance measurements all visual output was turned off. Since we do not have any knowledge about the significance of above mentioned factors and their interactions for our performance we set up a full factorial design shown in table 1.

We expected that the closed event loop simulator (here: AutoMod) would perform better than the open event loop simulator (here: SLX) in the case of a very high communication rate due to the bundling of events in the closed event loop approach. Depending on the step size of the closed event loop simulator we expected less synchronization points. Our tests partially confirmed these expectations (Table 1). When the communication rate is low (5 orders per 100 time units) the open event based approach outperforms the time-stepped approach. In the case of zero lookahead and a high communication rate (20 orders per 100 time units) the time stepped approach shows some performance advantages against the event-based approach.

Table 1: Experimental Design & Results (1)

It is interesting to notice that lookahead does not seem to have any effects on the time-stepped approach. In the event based approach the runtime in the case of lookahead = 6 is much faster then the values with zero lookahead. This is even more interesting if we consider the fact that all federates were executed on a single-processor machine where all federates share the same processor and no real parallel processing can occur. We assume that this may be due to the sleep statements, which do not "block" the entire system, but the single federate. Therefore "pseudo"-parallel processing can occur.

The ANOVA-Analysis performed on the test results leads to figure 9. Complexity and communication are to be of high impact on the performance. Lookahead and the simulator are less significant. In our set-up an increase in the number of federates did not lead to an over-significant decrease in the performance. This does not mean that the number of federates does not have an impact on the performance with higher levels than we choose.

Figure 9: Measured impact of factors and interactions

In summary the tests show that the synchronization (i.e. the number of times a communication occurs) is the main bottle neck when coupling discrete event simulators. If the application area allows the inaccuracies resulting from the time-stepped approach, it is worth considering this alternative. Since the event list handling capabilities of an open event loop simulator like SLX supercede the capabilities of a closed event loop simulator like AutoMod it is, of course, possible to use open-event loop simulators to "simulate" the behavior of closed loop simulators. Thus SLX could achieve the results obtained from AutoMod very easily by applying a time stepped synchronization approach to SLX, too. Further tests are scheduled to verify this assumption.

The second test set up aims at measuring the impact of the internet. Since we have used the internet technology so far the distance and the traffic on the internet appears as a factor that could raise as a bottle neck. Our second test set up consists of three computer that are connected via internet. One machine was used for running the rtiexec- and the fedex-processes. The federates were started on the other two computers. We used mixed models, i.e. Automod and SLX federates in one federation. Since the number of federates did not have the expected impact in the first test set up we only performed our experiments regarding complexity, lookahead, and communication. Thus the set up contained additional 8 experiments. The results are listed in table 2.

Table 2: Experimental Design & Results (2)

A comparison of both tables shows slightly different results. A high communication rate leads to a better performance in case of the internet (Table 2) than a single machine (Table 1), whereas a low communication rate effects the results not much. This has to be put down to the combination of both simulators in one federation rather than to the internet. The internet is not a bottle neck.

Conclusion and Outlook

HLA offers a new simulation interoperability standard that will influence the non-military simulation market in a similar way it currently influences the area of military training simulators. Our cross-simulator tests with AutoMod and SLX have shown that it is possible to connect simulators using standard internet technology. Response times between our two sites in Germany promise very good performance. In conjunction with web-based animation tools new application areas could open up (Lorenz and Ritter 1997).

Using HLA to connect different simulation tools can be a time consuming process. Integrating an HLA interface into a simulation tool is a task which should ideally be performed by the tool developers themselves. Today’s typical simulation tools are designed as classical stand-alone tools. Most manufactures do not see the necessity to facilitate interoperability between tools.

Although interoperability can be achieved with a model dependent HLA-interface as in our solution for the AutoMod system, it is highly desirable to build simulation model independent HLA interfaces. Given good support through the manufacturers such a solution could even be developed by third-party manufacturers as it was done for the SLX system.

References

Author Biographies

GÜNTHER SELIGER is a Professor in the Institute of Machine Tools and Factory Management. He studied industrial engineering at the Technical University of Berlin and received his doctor’s degree in 1983. In 1988 he became a professor for assembly technology and factory management at the Institute for Machine Tools and Factory Management of the Technical University of Berlin. He is the spokesman of the special research program 281 "Disassembly Factories", which started in January 1995.

PETER LORENZ is a Professor in the Institute for Simulation and Graphics at the Otto-von-Guericke University, Magdeburg. He teaches discrete simulation, computer animation, and graphics. His research interests include layout-based simulation model generation, advanced Web supported teaching concepts and applications of simulation and animation in manufacturing, logistics and traffic.

DIRK KRÜTZFELDT holds a Master’s degree in Computer Science from the Technical University of Berlin. Since 1995 he has been working in the department of assembly technology and factory management at the institute of machine tools and factory management. His research interest lies in production networks, information management and distributed simulation.

STEFFEN STRASSBURGER holds a Master’s degree in Computer Science from the Otto-von-Guericke University, Magdeburg. He is currently working towards his PhD degree at the Institute for Simulation and Graphics at the same university. His experience with inter-networking and simulation includes a one-year-stay at the University of Wisconsin, Stevens Point. His main research interests lie in distributed simulation and the High Level Architecture.