A federated simulation method for multi-modal transportation systems: combining a discrete event-based logistics simulator and a discrete time-step-based traffic microsimulator

Abstract

The primary focus of computer simulation in transportation engineering has been to model individual systems using modeling software packages designed for the specific system under investigation. However, this limits the ability to explore interactions between multiple disparate transportation systems in a dynamic modeling environment. To address this gap, this study develops and tests a technique to federate two transportation models, each constructed using different simulation software packages: (1) a discrete event-based simulation model of a freight trucking terminal and (2) a discrete time-step-based traffic microscopic simulation model of the network serving the terminal. The federation technique is tested to consider potential feedback loops that may arise between the models during a single simulation run. It is then applied in a notional case study of the Port of Savannah to further assess its capabilities. The findings suggest that this federated simulation technique captures the dynamic interaction of the two systems being modeled. A comparison of the observed versus expected time-based characteristics of the interactions are shown to yield statistically significant correlation.

Keywords

federation simulation transportation port Arena VISSIM HLA

1. Introduction

In transportation engineering, simulation is widely applied to systems to better understand traffic flow, traffic operations, and logistics. Over the past few decades, advances in computer simulation methods have allowed engineers and planners to better understand, analyze, and make decisions about real-world systems in a virtually risk-free environment.¹ These advances have also allowed engineers to move beyond modeling interactions within a single complex system to examining the interactions between larger “systems of systems”.² However, there are limits: Kewley et al.² noted that “large single models that enable analysis of systems of systems are not effective because no single modeling effort can account for all of the [system’s] complexities”. This suggests that to capture the complexities and interactions inherent within a system of systems, multiple models of the underlying individual systems must be combined. However, operational differences between the various simulation approaches involved in effectively modeling disparate systems can complicate the combination of such models.

Iterative simulation is one approach used to combine multiple models of individual systems within a larger system of systems. In general, this method entails running one model simulation over a particular time period and then using its output values to define the input values for one or more additional models. However, because of the sequential, not simultaneous, nature of this method, any feedback loops that would occur between the models dynamically, wherein changes to the operational characteristics of one model can affect those of the other during runtime, cannot be established. This inability to fully characterize multi-model dynamic feedback has the potential to compromise the fidelity of a system of systems simulation.

This study describes a federated simulation method that combines two transportation systems models and is designed to enable multi-model feedback loops during simultaneous execution of the two models, overcoming the limits of iterative simulation. This approach is inspired by the high-level architecture (HLA) standard for federated simulation and modeling,^3,4 which provides standardized, broadly applicable guidance for federated simulations. The first of the two federated models was developed using Arena 12.0 (Rockwell Automation Inc.), a widely used discrete event-based simulation software package, to simulate simplified truck freight terminal operations. The second model was a roadway network model developed using PTV-VISSIM 5.10 (Planung Transport Verkehr AG), a discrete time step-based traffic operations microscopic simulation software package. The federated simulation was tested to (1) demonstrate the ability to establish dynamic feedback loops between the two models during a federated simulation run, and (2) determine the relative sensitivity of the federated simulation method to several parametric changes. The federated simulation method was then applied in a case study to the combined port and roadway operations at the Port of Savannah (Georgia) to further assess its performance and capabilities.

2. Federated simulation

Federated simulation is a technique used to combine multiple simulation models and can be broadly viewed as “a composable set of interacting simulations”.⁵ To facilitate both interoperability and reuse of federated simulation components, protocols have emerged to standardize the interface of federation components. Ferenci et al.⁶ provide an overview of such protocols. Most notably, the HLA was developed by the US Department of Defense (DoD) Modeling and Simulation Coordination Office (formerly the Defense Modeling and Simulation Office)⁷ with the goal of providing a common architecture standard to “facilitate the interoperability among simulations and promote reuse of simulations and their components”.⁸ The HLA provides the structural basis of how the various federated simulation components, or federates, interface “via the services of the HLA Runtime Infrastructure (RTI) and in accordance with a common object model and a common HLA rule-set to achieve some desired purpose”.⁸

2.1. Federated simulation applications in transportation

The HLA structure provides a foundation for this study, which develops a method to federate two disparate simulators: a dedicated microscopic traffic simulator (VISSIM) and a general discrete event simulator (Arena). The final method developed here is not fully HLA compliant, but is heavily influenced by the HLA structure and rule set: specifically the HLA time management and object management services.

Federated simulation is most frequently employed in the transportation field to promote increased simulation speed (e.g. see Potuzak,⁹ Potuzak and Herout,¹⁰ Chronopoulos and Johnston,¹¹ Yoginath and Perumalla,¹² Ozaki et al.,¹³ and Ramluchumun et al.¹⁴). Often this involves separating single large models into several sub-models whose execution can be distributed across multiple processors. For example, Klein et al.¹⁵ have investigated and tested an HLA-based prototype distributed simulation of an urban traffic model. Gao et al.¹⁶ also discuss an HLA-based distributed simulation of multi-modal terminal using a discrete event simulator.

Relatively little work has investigated the federation of two or more models developed in disparate simulation software packages. An initial proof-of-concept study was conducted by Puglisi¹⁷ that employed a spreadsheet-based approach to federate a discrete event-based process/logistics simulator (Arena) with a discrete time step-based traffic simulator (VISSIM). This study builds on the time management, and database-oriented data distribution and object management methods established by Puglisi¹⁷ to create a stand-alone programming method to facilitate federated simulation of multiple complex transportation systems. Other work has federated traffic simulations with wireless communication simulators. For example, Wu et al.¹⁸ federated a microscopic traffic simulator (Corsim) with a commercial communications simulator (QualNet) to study vehicle to vehicle message propagation along an interstate corridor.

2.2. Challenges in federating multiple transportation simulation models

Ensuring time synchronization of multiple models is one of the primary challenges in federating multiple transportation simulation models. For example, Arena and VISSIM treat time differently. As a discrete event-driven simulation software package, Arena executes events on an event calendar and advances its simulation clock from the timestamp of one event to that of the next in the event calendar. The advancement of simulation time is typically not uniform from event to event.

Conversely, VISSIM uses a discrete time-step approach which tends to be better suited to simulating the continuous nature of traffic flow. Discrete time-step-based simulation can be viewed as a special case of discrete event simulation as it subdivides the time between the beginning and end of a simulation into equally sized, fixed time-step intervals (e.g. 1 second). As the model advances from one equally spaced time step to the next, the entire state of the simulation is recomputed,¹⁰ and time advances uniformly.

The disparity in approaches to time advancement between Arena and VISSIM requires the time management services of some external program or system to ensure the synchronization of both models during the execution of the federation. Consistent with the HLA structure and rule set, this time management function is best facilitated by a federation RTI. The HLA time management services define a common application program interface (API) to manage the advancement of time among simulators using different time advancement mechanisms,¹⁹ and implementation approaches as described by Fujimoto.²⁰

3. Federated systems operational overview

For the first part of this study, the federation technique is demonstrated on a simplified transportation system: the movement of container objects among trucking terminals via an interconnecting roadway network (Figure 1). A fleet of truck objects based at the home terminal carry the container objects from the home terminal to one of the two destination terminals, shown in Figure 1, and then return empty to the home terminal. The roadway network, modeled in VISSIM, consists of a signalized “T” intersection with links leading to each of the three terminals, which are modeled in Arena. The dashed line shown in Figure 1 represents the figurative boundary separating the components modeled using Arena and those using VISSIM. Interactions between the two federates during federated simulation occur across this boundary.

At the beginning of the federated simulation execution a fixed truck fleet is created in the home terminal submodel of the Arena model where they wait in a truck queue. During the run, container objects are created in the home terminal submodel of the Arena model at a constant, user-specified rate, and sent to a container queue. Awaiting containers are batched with the first available truck from the truck queue, and are then “passed” to the VISSIM roadway network model (this is discussed in Section 4.3) to travel to their assigned destinations. Upon arrival at a destination terminal, the batched pair is removed from the roadway network model and passed to the destination terminal submodel of the Arena model. The container object is deleted from the system and the truck object is delayed for some user-specified time interval (representing unloading and service time), and then passed back to the VISSIM roadway network model to return to the home terminal. Upon arrival at the home terminal, the empty truck is passed back to the Arena home terminal submodel where it is sent to the truck queue to await pairing with future outgoing container objects.

4. Federated system components

The federated simulation of the truck terminal and roadway system of systems consists of four components: (1) the Arena truck terminal model federate, (2) the VISSIM roadway network model federate, (3) the federation RTI, and (4) the federation database. Figure 2 shows the structure and interactions of these components. The RTI facilitates the movement of data and objects between port and roadway network model federates and manages the federation time to which each of the model federates is synchronized. As the federation clock advances, the RTI collects information associated with object (i.e. containers and/or trucks) transactions from one model federate, records it to the federation database, and transmits the information to the other model federate involved in the transaction. For example, when a truck leaves the home terminal for the roadway, all object and data information pertaining to that truck are collected by the RTI from the Arena model federate and stored in the federation database. The RTI then transmits that information to the VISSIM model federate, which recreates that truck on the simulated roadway network.

4.1. Truck terminal system model

The truck terminal system model used in the federation was developed using Arena 12.0. The federated model consists of three submodels: a home terminal and two identical destination terminals, numbered 1 and 2.

4.1.1. Home terminal submodel logic structure

The home terminal submodel is divided into separate logical sequences: one for incoming, and one for outgoing truck and container objects, shown in Figure 3. These two logic sequences consist of several discrete logic processes.

The “Outgoing to Roadway” logic sequence contains three discrete processes. The first assigns unique container attributes (e.g. an origin ID, a destination terminal ID, and a unique numerical ID used to identify that container throughout the federation) and then stores the container object in a first in first out (FIFO) queue. The second process batches the container with a truck object (when one becomes available), and their attributes are collected by the RTI, which passes the batched pair to the roadway network model federate. The third process then resets variables internal to the Arena model used in the previous logic process to facilitate the RTI transaction.

The “Incoming from Roadway” logic first generates a specified number of truck objects (i.e. a truck fleet) at the start of simulation execution, and assigns each truck object a unique ID number. When the RTI is notified of a truck object incoming from the roadway network, it transfers the truck object’s unique ID number to the Arena submodel, triggering the first logic process to create an Arena truck object and assign it the vehicle identification number provided by the RTI, and then delays the truck objects to simulate unloading/service time. The second process stores the truck object in a FIFO queue to await batching with other outgoing containers.

4.1.2. Destination terminal submodel logic structure

Both destination terminal submodels are identical in construction and are closely related to the home terminal submodel described above. The major distinction is the lack of logic to initially create the truck and container objects, and the addition of logic that disposes of container objects as they are no longer needed.

4.2. VISSIM roadway network model

The roadway network model was developed using PTV VISSIM 5.10, a microscopic traffic simulation software package. The layout of the roadway network is shown in Figure 1 and consists of a 90°“T” intersection with three approach roads. Each approach road consists of two links with a single 12-foot lane, one for each direction of travel. The home terminal road links are 4000 feet in length; destination terminal links are 2560 feet in length. All other link attributes use the VISSIM 5.10 default values.

Traffic signal heads are placed on each approach link at the intersection. Signal timing is discussed in Section 5. Left-turning vehicles are required to yield to oncoming traffic or conflicting right-turning traffic. Right-turn-on-red maneuvers are not permitted on any approaches.

Vehicle-detection zones (65 feet long) are placed at the end of each exiting roadway link. A stop sign placed immediately upstream of each detection zone ensures that only one vehicle occupies the detection zone during each time step and that the vehicle cannot avoid detection by passing completely over the detection zone in a single time step.

Vehicle routing is facilitated by three unique vehicle types and classes, each corresponding to a destination terminal. The RTI evaluates an exiting container object’s assigned destination ID and creates a vehicle in the VISSIM roadway network model of the type and class associated with the prescribed destination ID. Approximately half of the containers are routed to Destination Terminal 1 and half are routed to Destination Terminal 2.

4.3 Federation RTI

The purpose of the RTI is to manage the execution of the federated simulation and the transaction of simulation objects between the two model federates. To these ends, the RTI implements time management and object management services. The RTI was programmed in the Visual Basic (VB) language using Visual Studio 2005 (Microsoft Corp.), as both VISSIM and Arena have built-in component object model (COM) interfaces that use that language. These interfaces allow the objects, methods, and properties of each simulator to be dynamically accessed, assigned and run from within other applications (e.g. Visual Studio).²¹

The RTI implements a time-stepped time advancement protocol not unlike the time advance request (TAR)/time advance grant (TAG) services defined in the HLA. In an HLA federated simulation, an event-driven federate, such as Arena, would typically use the next event request (NER) service. Here, the Arena models do not directly interact, and the timestamps of interactions between Arena and VISSIM must be aligned with the 1-second time-steps used by VISSIM. This makes use of NER unnecessary. Further, the TAR-based approach used here simplifies the implementation of the RTI, and reduces the number of time management service calls that would be required when using a mix of NER and TAR requests.

The RTI must also support modeling the movement of trucks and containers between the Arena and VISSIM models. The RTI implements basic object management services for this purpose. For example, a service not unlike the update attribute values (UAV) service in the HLA is invoked by VISSIM to model the movement of a truck object to a terminal modeled by Arena.

The underlying structure of the RTI is a single “For-Next” loop (functionally illustrated in Figure 4), which consists of four command sequences. One complete loop iteration represents one time step of the federated simulation. For this study, the federation time steps are defined as uniform 1-second intervals (i.e. one iteration of the four-sequence RTI loop represents 1 second). A more detailed technical discussion of the RTI’s structure and operation can be found in Wall.²²

4.3.1. Federation and VISSIM clock advancement

The first sequence of RTI commands advances the federation loop by one iteration, advancing federation time. A series of commands are then executed that place a call to the VISSIM model federate, to advance the VISSIM simulation by a single time step. The time step interval of the VISSIM simulation has been preset to 1 second, consistent with the federation time step interval. Thus, at the end of the first RTI sequence the VISSIM simulation clock has advanced to become equal to the current federation time increment. Once the VISSIM model has executed the command to advance by one time step, VISSIM pauses and then notifies the RTI that it has successfully advanced, thus signaling to the RTI to continue to the next command sequence.

4.3.2. VISSIM-to-Arena object transaction

The second sequence of RTI commands manages the transaction of truck objects exiting from the VISSIM roadway network model federate to enter the Arena truck terminal model federate. During the previous step VISSIM notifies the RTI of the presence of a vehicle at each exiting link detection zone. The RTI identifies the exiting container and/or truck object and associated data using the unique object ID assigned by VISSIM. The RTI then executes a series of structured query language (SQL) commands to locate the object record in the federation database, collect the exiting object(s) information, and then transmit that information in a standardized publication format to the terminal submodel in Arena that is associated with the exiting link detection zone from VISSIM. Arena then recreates the object(s) in the associated submodel and reassigns all of the retrieved object information as object attribute data. The RTI then updates the federation database to reflect the container and/or truck object’s current location and a federation time-stamp for the transaction.

4.3.3 Arena clock advancement

Once all objects for the current timestep have been exchanged from VISSIM to Arena, a third sequence of RTI commands places a call to Arena that advances the Arena simulation by 1 second. This call has two components. First, the RTI executes a command to schedule a break-point in the Arena simulation model that is one federation time-step (i.e. 1 second) in the future. This is necessary as Arena time-steps may be non-uniform (i.e. greater than or less than 1 second, the federation time step), so this allows consistent time-step advancement of the model. The second component of the Arena advancement call executes a command that starts the Arena simulation, which advances to the scheduled break-point where the model is paused. After this Arena model advancement, the Arena simulation clock’s time is equal to the federation clock’s time (which is currently equal to the VISSIM clock’s time, see Section 4.3.1). Once the Arena model advances and then pauses at the scheduled break point, the RTI is allowed to continue to the fourth command sequence.

4.3.4. Arena-to-VISSIM object transaction

The fourth sequence of RTI commands manages the transaction of truck objects exiting the Arena truck terminal model federate to enter the VISSIM roadway network model federate. When a container and/or truck object is ready to exit an Arena truck terminal federate submodel, Arena publishes all of the object(s) information in a standardized format. At the beginning of each time step, the RTI checks the three truck terminal submodel logic sequences to see whether new container and/or truck information has been published by Arena. If the RTI finds that new information published at one of the truck terminal submodels, it identifies the exiting object(s) and collects from Arena all of the information associated with the exiting container and/or truck objects. The RTI then executes a series of commands via the COM interface to create the truck object as a vehicle in the VISSIM roadway network model, thereby passing the container and/or truck objects between the model federates. The RTI then updates the federation database to reflect the container and/or truck objects’ current location as the roadway network and a federation time-stamp for the transaction.

Once all objects for the current time step have been exchanged from Arena to VISSIM, the RTI advances to the end of the underlying loop structure, at which point it begins again with the first sequence of commands for the subsequent time step.

4.4. Federation database

The RTI’s function is time and object management. It does not store any information during the execution of the federation, but uses an associated relational database for object data storage. The Microsoft Access 2007 database used for the federation consists of six data tables (Figure 5). The first three tables are concerned with the runtime operation of the simulation: (1) Container Table, (2) Vehicle Table, and (3) Index Table. The first two respectively store the attribute values associated with each container and truck object currently active in the federation, such as their origin, destination(s), current location (e.g. port, roadway, distribution center), and the time-stamp of their last transaction. Paired truck and container objects are associated with one another via the Index Table according to a separately generated common identifier.

The tables (4) Container Log and (5) Vehicle Log record every transaction where container and vehicle objects, respectively, move between model federates, thus providing a history of all federate model interactions. The final (6) Queues Table records queue length information for various queues within the Arena truck terminal submodels for post-process performance measurement.

5. Simulation experiment overview

Two simulation experiments were undertaken: the first tests the federation method’s ability to establish feedback loops between the two model federates dynamically during simulation runtime; the second experiment investigates the relative sensitivity of the federation method to several changes in the input parameters of the constituent model federates.

5.1. Feedback loop experiment

The first experiment was designed to test whether changes in the input parameters of one system model (e.g. the roadway) could affect characteristics in the performance of the other system modeled (e.g. the port), indicating a feedback loop between the two federates. During this simulation experiment, roadway delay was increased in the VISSIM roadway network model, and impacts on queue lengths in the Arena terminal model were monitored. An increase in queue growth rate is expected at the home terminal container queue as a result of the truck fleet’s inability to return (due to increased roadway delay) at a rate sufficient to serve the arriving container demand. To test this hypothesis, the experiment compared two scenarios: (1) a baseline scenario of system performance, and (2) a second scenario with increased roadway delay.

It is well documented that sequential data points are correlated, and therefore not independent, in non-terminating time sequence simulations.^23-26 To overcome this, a series of M independent replications were conducted and combined for each scenario to form two sets of independent observations. Law²³ and Welch²⁶ suggest M = 5–10 replications. This experiment used M = 20. Each replication used a separate, unique random number seed in both VISSIM and Arena models.

5.1.1. Input parameters

Five primary input parameters were defined prior to simulation: (1) duration of the simulation, (2) destination and home terminal truck delay, (3) quantity and rate of container creation at the home terminal, (4) trucks quantity (i.e. fleet size), and (5) intersection signal timing (i.e. control delay). Simulation duration, terminal delay, container creation quantity and rate, and truck fleet size held constant between baseline scenario and increased-delay scenario, as follows: (1) federated simulation duration = 12 hours (43,200 seconds); (2) normally distributed (µ = 40 s, σ = 10 s) truck terminal unloading/service delay; (3) fleet size = 10 trucks; (4) containers created in two batches of 480 each (starting at federation time = 15 s and 21,615 s), at a constant rate of one container per 30 seconds.

Different intersection signalization plans were used in the two scenarios to facilitate increased delay in the latter. Neither scenario contained background traffic in the VISSIM model. Both scenarios consisted of 90-second cycle lengths, 3-second yellow intervals, and 2-second all-red intervals. However, green intervals were varied between scenarios to alter intersection delay and thus truck travel times. In the baseline scenario, green intervals were set to 40 seconds in both E–W and N–S directions. In the second scenario (increased delay) green intervals were set to 15 seconds in the E–W direction, and 65 seconds in the N–S direction. This imbalance in green interval times in the second scenario increases delay in the following way: due to the balance in trucks leaving and returning to the home terminal, the unequal green time splits (i.e. bias towards N–S movements) in the increased delay scenario’s cycle will result in an increase in the roundtrip roadway travel time.

5.1.2. Data collection

The container queue length at the Arena home terminal submodel provides the primary performance measure. Queue lengths were collected for each of the 20 replications of both the baseline and increased delay scenarios by the RTI and recorded in the federation database at 30-second intervals beginning at time = 30 seconds for the entirety of the federated simulation. Replicate datasets for each scenario were later combined by averaging each corresponding 30-second observation across replicates. Secondary performance measures (average vehicle travel time, and average vehicle delay) were also collected during simulation runtime to confirm the operational characteristics of the two model federates.

5.2. Simulation performance experiment

The second experiment was designed to investigate the relative sensitivity of the federated simulation method, and its components, to changes in computational load. This was accomplished by executing a series of batched simulations in which the container creation rate parameter was successively increased in the Arena model federate, and the total computation times associated with each model federate were recorded. Increasing the container creation rate in the Arena model federate increases the computational load in that model federate, as well as increasing the rate of transactions facilitated by the RTI and the number of truck objects active in the VISSIM model federate at any given time.

A series of N = 20 replications were conducted, each for 20 hours of simulation time, which were divided into five batches of 4 hours. The home terminal container creation rate was initially set to 1 container/minute in Arena, and increased by 1 container/minute for each successive batch. The computation time for each model federate was measured during the final 3 hours of each batch; the initial hour of each batch serves as a seeding period. Computation time was measured in the RTI (one for each of the two federates and one for the RTI) using the RTI each associated with one federate given the computer system time associated with the start and end of each sequence shown in Figure 4. The three counter variables were then incremented by that elapsed computation time during each iteration, and the total computation times for each federate for the simulation run were recorded. Computation times for the seeding periods were not recorded. Note that sequences 2 and 4 in Figure 4 are both associated with the RTI.

6. Simulation experiment results and discussion

Figure 6 illustrates the time-dependent average queue length for the replicate runs under the baseline and increased delay scenarios described in Section 5.1. Both scenarios show container accumulation in the home terminal container queue during both container arrival periods. This is caused by an insufficient number of trucks to move containers away from the home terminal. However, the container queue growth rate is greater in the increased delay scenario; differences in slope between the two scenarios are significant at the 99% confidence level.

The vehicle delay data collected during simulation indicates an average roadway delay of 42.1 seconds for the baseline scenario and 55.7 seconds for the increased delay scenario. The average roundtrip travel times were found to be 303.1 seconds for the baseline scenario and 316.9 seconds for the increased delay scenario; these times include processing delays (µ = 40 s, σ = 10 s) at all terminals, and a 2.5-second lag in data acquisition and transfer operations internal to Arena (this does not affect Arena or RTI execution times).

From these travel times we can calculate the average truck interarrival rate at the home terminal as the roundtrip travel time divided by the number of vehicles in the fleet. The inverse of this value is then the truck arrival rate, or 118.8 vehicles/hour in the baseline scenario, and 113.6 vehicles/hour in the increased delay scenario. The difference between the container arrival rate (one container every 30 seconds) and the truck arrival rate yields the home terminal container queue growth rate, or a rate of 1.2 containers/hour in the baseline scenario, and 6.3 containers/hour in the increased delay scenario. Figure 7(a) and (b) show the expected queue growth rates for the first and second arrival periods, respectively, in comparison with the observed queue data collected from the model federates.

An initial transient period (while the trucks distribute themselves across the system) was identified by plotting interarrival times. Using the methods discussed by Welch,²⁶ the initial transient period was found to end near 1200 seconds, or the 40th observation. Thus, Figure 7(a) and (b) omit the first 40 observations from each set. The x-intercepts for the expected queue length plots were determined by identifying the time at which the average queue length first achieves a non-zero value for two consecutive observations, and adjusting accordingly.

Note in the first container arrival period (Figure 7(a)) that the observed container queue growth rate for the increased delay scenario is less than the expected rate calculated. This disparity is not present in the second arrival period (Figure 7(b)). An examination of the 20 individual model replications shows wide variation in the maximum queue lengths between the two arrival periods. It is suspected that the disparity in Figure 7(a) is a result of this variation although additional model replications are necessary to confirm this hypothesis. A Student t-test was performed to compare the maximum queue lengths for the first and second container arrival periods in the increased delay scenario. The null hypothesis stated that the maximum queue lengths were not statistically different. This test yielded a test statistic, p = 0.133, indicating that the null hypothesis cannot be rejected even at the 90% confidence level.

The simulation performance experiment measured changes in runtime of each federate (VISSIM, Arena, and the RTI) as a function of the computational load associated with one of five batches during simulation. Figure 8 shows the total computation times associated with the Arena and VISSIM model federates for each batch. Simple linear regression analyses indicate that both VISSIM and Arena model federates exhibit slight increases in computation time as computational load is increased in the federated system. In comparison, Figure 9 shows the total computation times associated with the Arena and VISSIM federates, and with the RTI for each batch. Simple linear regression analysis indicates that the RTI exhibit a comparatively greater increase in computation time as computational load increases in the federated system. This indicates that given the current configuration of the federated simulation, the RTI places the greatest strain on computing resources, as compared to the Arena and VISSIM model federates. Future research efforts should focus on improving this implementation, particularly on seeking greater computing efficiency in the RTI implementation.

7. Simulation case study: Port of Savannah

The federated simulation technique developed in this study was implemented in a case study of the Port of Savannah to assess its application to real-world systems. Similar to the previous experiments this case study also investigates whether changes to the operational parameters of the port model federate affect the performance of the roadway network model federate. This study used an Arena model of the Port of Savannah, developed by Gbologah,²⁷ and a notional VISSIM model of the surrounding roadway network.

The Port of Savannah Arena system (Figure 10) model consists of five submodels (the Garden City Terminal (GCT), the junction with Interstate 16 (I-16), and three distribution centers) which are connected by a VISSIM roadway network model of the surrounding roadway system.

Containers are generated at the GCT, where they are offloaded from container ships, and Interstate 16 (I-16), where long-distance trucking carriers enter the model from the interstate highway system. Containers are also deleted from the model at these two locations (the GCT where they are loaded onto ships, and the I-16 Junction where they leave the local roadway network to enter the interstate highway system). Distribution Centers 1, 2, and 3 serve as intermediate destinations for containers. Containers are neither created nor deleted at the distribution centers but processed between trucks on route to their final destinations. Containers generated at the GCT can have one of four destinations: one of the three distribution centers or the I-16 junction (i.e. not all containers have an intermediate stop at one of the distribution centers). Similarly, containers generated at the I-16 Junction from long-distance trucking can have one of four destinations: one of the three distribution centers or the GCT.

Two types of trucks exist in the federated system. Port trucks transport containers among Port of Savannah facilities (GCT and distribution centers); the fleet size is fixed and is determined prior to simulation. Roadway trucks represent long-distance carriers that exclusively transport containers between one of the four port facilities and the I-16 junction, where trucks and containers exit the simulation. An initial, user-specified quantity of long-distance roadway trucks is also generated at the GCT during simulation initialization; however, empty roadway trucks and roadway trucks carrying containers are also randomly generated at the I-16 Junction to simulate arrival from the interstate highway system. During simulation, roadway trucks are removed from the simulation at the I-16 junction where they enter the interstate highway system.

The major roadways included in this study (see Figure 10) are GA Highway 21, South Coastal Highway, Dean Forest Road/Bourne Avenue and Jimmy de Loach Parkway. Note that Jimmy de Loach Parkway contains an overpass that crosses GA Highway 21, before intersecting it from the east. All traffic flow between the three distribution centers and the port is routed along Bourne Avenue, GA Highway 21 and Jimmy de Loach Parkway. All traffic flow between the port and the long distance trucking/I-16 junction is routed along Bourne Avenue and Dean Forest Road. All roads contain non-port-related “background” traffic.

The roadway network was developed primarily using VISSIM default values for roadway link characteristics. Details concerning signal timing, vehicle routing, and other aspects of the VISSIM roadway network model are discussed further by Wall.²²

7.1. Case study experiment overview

To further investigate feedback loops established between model federates in this case study, an experiment was designed that adjusts multiple simulation input parameters at different times over the course of a simulation run, and observes related impacts to performance measures. The two input parameters are port container volume (as in the simulation performance experiment detailed earlier), and roadway congestion (i.e. the background traffic volume in the roadway network). To minimize the possibility of confounding data, these two parameters are adjusted separately, out of phase from one another, over the course of a 120-hour (5-day) simulation run. Figure 11 illustrates the adjustment of input parameters. For this experiment the intent of the 5-day simulation run is not to reflect daily cycle of background traffic (i.e. peak and not peak hours) over each day but to conduct a sufficiently long experiment to capture differing parameter values. Thus, a day in this instance should not be taken as traffic variation over a “typical” day.

The motivating hypothesis is that changes to container volume creation in the Arena port model federate may affect roadway performance in the VISSIM model federate by increasing truck activity on the roadway. This experiment also hypothesizes that increasing background traffic on the roadway network may affect Arena port model performance by congesting the VISSIM roadway model federate and inhibiting the timely return of trucks to the GCT. For this set of experiments an initialization period was not utilized, with data collection beginning at the start of simulation as the time series data is of most interest.

7.1.1. Independent input parameters

Container creation is determined by ship arrival rates at the GCT, and by the number of containers per ship. Ship interarrival rate was defined as two hours; containers per ship was defined as a uniform random distribution between 225 and 275 containers. Thus, the average container arrival rate is 125 containers per hour. At the end of the first day, container creation rate is increased by lowering the ship interarrival rate to 1.5 hours. This increases the average container arrival rate to 166.7 containers per hour. This rate was then decreased to the original rate at the end of day 3. The port truck fleet size was set to 150 trucks to constrain container movement at the higher container creation rate, but not at the lower container creation rate.

Baseline background traffic is created, throughout simulation, by inputting 250 vehicles/hour at each of the entering links of the major network roadways (excludes driveways, etc.). At the end of day 2, traffic input volumes were increased to 500 vehicles/hour at all locations, with the exception of two roadways. Background traffic input on Dean Forest Road, and on Highway 21 was increased to 850 vehicles/hour at the end of day 2 to accentuate observable impacts along those segments. Background traffic input rates were decreased to their initial values at the end of day 4.

All other independent input variables remained constant over the course of simulation. These input variables are further detailed by Wall²² but are briefly discussed here. Truck creation rate at the I-16 junction was defined as 200 vehicles/hour; 10% of containers created at the GCT are designated to be carried directly to the I-16 junction, whereas the remaining 90% are designated to be processed at one of the three distribution centers (equally distributed) as an intermediate destination on route to their final destination at the I-16 junction; processing times at the distribution centers were defined as 15 minutes.

7.1.2. Dependent parameters and data collected

Two types of system performance data were collected during simulation. Container and truck queue length data were collected for the GCT Arena submodel, which represents the number of trucks awaiting utilization, and the number of containers awaiting transport. Queue data were collected at even 60-second intervals over the entire simulation time. Roadway travel time data were also collected for background traffic along: (1) Dean Forest Road between the intersection with GA Highway 21 and the I-16 junction; and (2) GA Highway 21 between Bourne Avenue and Jimmy de Loach Parkway. For this experiment, M = 10 independent replications of this experiment were conducted.

7.2. Case study experiment results and discussion

7.2.1. Port truck and container queue data

Figure 12 shows the average container and port vehicle queues at the GCT. The supply of port trucks appears to converge to a steady-state queue length of approximately 40 port trucks, and maintains that state for the first day of simulation. As there is an excess supply of port trucks available for the first day, containers do not accumulate in the port container queue. At the simulation time = 1440 minutes (start of day 2), the container creation rate at the port is increased, thus increasing demand of port trucks for container transport and reducing the port truck queue length over the second day of simulation. The port truck queue drops to a sustained average queue length of zero near simulation time 2350 minutes; this roughly coincides with the container queue reaching a sustained non-zero average queue length. On average across the M = 10 replications, the non-zero container queue length occurred 1.2 minutes after the truck container queue reached a value of zero (i.e. containers begin to accumulate shortly after trucks are no longer available).

At simulation time = 2880 minutes (start of day 3), the roadway network background traffic volume is increased. Following this change, a sharp increase occurs in the port container queue length at the GCT Gate submodel. One explanation for this is that the supply of available port trucks becomes significantly delayed by the increased roadway congestion. The port truck queue length remains at zero throughout day 3 as a result of the excess demand for port trucks.

At simulation time = 4320 minutes (start of day 4) the containers creation rate at the GCT Gate submodel is reduced to its original volume. At simulation time 4525 minutes, the port container queue reaches its maximum average queue length of 399.4 containers, after which the queue begins to dissipate. At simulation time = 5760 minutes (start of day 5) the roadway network traffic volume is reduced to its original volume. This roughly coincides with the periodic accumulation of trucks in the GCT submodel port truck, however sustained non-zero truck queue lengths do not occur before the end of simulation time as sufficient container demand persists. Note that port truck queues begin to accumulate after time = 5760 minutes despite persistent container demand. It was found that container queue accumulation was significantly greater in two replications, and that the containers queue in those simulations remained positive until the end of simulation resulting in a greater than zero average queue length over the 10 replications.

7.2.2. Background traffic travel time data

Travel time data were collected for background traffic in the roadway network model federate as averages for successive 30-minute intervals. Figure 13 shows the plot of travel times for background traffic in both directions for on the Highway 21 segment. After some initial transient period, southbound travel times increase until reaching what appears to be a steady-state value near 475 seconds. The greater southbound travel time is explained by: (1) greater baseline congestion in the southbound direction (due to higher traffic volumes), (2) weaving of southbound vehicles entering the left turn lane at the intersection with Bourne Avenue, and (3) occasional spillback of the southbound left-turning queue at that location.

At 1440 minutes, the port container volume is increased. This coincides with an increase in southbound travel times, which reaches steady state near 525 seconds. At 2880 minutes, the background traffic volume is increased, coinciding with an increase in southbound travel times, which reaches steady state near 625 seconds. This steady state southbound travel time of approximately 625 seconds is maintained throughout the third and fourth days of simulation despite the decrease in port container volume at 4320 minutes. During simulation, heavy congestion was observed at the intersection of Highway 21 and Bourne Avenue. It is likely that the congestion was the determining factor for travel time, and therefore any effects of changes in container volume between days 3 and 4 are not reflected as a result. At time 5760, background traffic volume is reduced to its original level, coinciding with a decrease in southbound travel times, which after an initial transient appears to reach a steady-state value near 500 seconds. There is significantly greater variability in southbound travel time than in northbound travel times. This is likely due to lower baseline traffic volumes in the northbound direction, as well as no weaving of port trucks (port traffic travels in the right lane, making a right on to Jimmy de Loach Parkway to access the distribution centers via an overpass; there is no weaving into the left lane except for overtaking), or other significant intersection delay.

Figure 14 shows the travel time data for background traffic traveling along Dean Forest Road between Highway 21 and the I-16 Junction. Travel times in both directions along Dean Forest Road are much closer in value than those shown for Highway 21. In addition, northbound travel times appear to be affected by the increase in background traffic volume between 2880 and 5760 minutes, whereas southbound travel times do not appear to be affected by the increase in background traffic. There is no identifiable change in travel times coinciding with changes in port container volume at the beginning of day 1 and the beginning of day 3.

8. Conclusions

The purpose of this study was to develop a federated simulation method that combines two transportation systems modeled in disparate simulators to capture the dynamic interactions within the system of systems. The federation method was inspired by the HLA, particularly its services of time management and object management. The federated system consisted of a roadway network model developed in VISSIM, a freight truck terminal model developed in Arena, a federation RTI developed in Microsoft Visual Studio 2005, and a federation database developed in Microsoft Access 2007.

Two experiments were devised to: (1) test the presence of dynamic feedback loops between the two model federates, and (2) determine the relative sensitivity of each federation component to changes in computational load during federation runtime. The first test specifically examined whether changes to the operational characteristics of one model could be shown to affect that of the other model dynamically, during runtime, by comparing two roadway delay scenarios: a baseline scenario, and an increased roadway delay scenario. The second test incrementally increased the container creation rate in the Arena port model federate, which has the effect of increasing computational load in each of the three federation components, and the total computation times for each federate were recorded and compared to determine relative sensitivities to computational load.

The dual-peak characteristic of the time-based home terminal container queue lengths (Figure 6) result from the two container arrival periods. This suggests that the federated system of systems responds to changes in container arrival characteristics in the Arena truck terminal model. When the container arrivals stop at the end of each arrival period, the container arrival rate no longer exceeds the truck arrival rate from the VISSIM roadway network model, resulting in a rapid dissipation of the container queue.

The different queue growth rates seen in the baseline and increased roadway delay scenarios (Figure 7(a) and (b)) also suggest that changes to the operational characteristics of the roadway network model are reflected in the operational characteristics of the truck terminal model. When roadway delay was increased in the VISSIM model it caused a drop in the truck arrival rate at the Arena home terminal submodel. With a constant container arrival rate, the decreased truck arrival rate due to increased roadway delay results in an increased container queue growth rate in the Arena home terminal submodel, compared with the baseline scenario. These empirical queue length data were confirmed using simple queuing calculations given the container arrival rate (obtained from Arena) and the roadway roundtrip travel time (obtained from VISSIM and the federation database).

The federated system’s response to changes in container arrival rate (dual-peak queue length) and to changes in roadway network delay suggest that the federated simulation method developed in this study is capable of establishing feedback loops between systems dynamically during runtime. It also suggests that this federation method is able to capture the effects on performance characteristics in one model that result from changes to operational characteristics in the other model.

The simulation performance experiment increased the federated simulation’s computational load by successively increasing container creation rate across five batched simulations to assess federate and RTI performance. The results suggest slight increases in computational load associated with the VISSIM and Arena model federates. A more significant increase in computation load is seen associated with the RTI as container creation increases. This suggests that given the federated simulation’s current configuration, the RTI is the most computationally costly component. One possible explanation for this is that an increase in the number of containers produced in the Arena model will increase the number of transactions among federates, and therefore the number of queries/data exchanges between the RTI and federation database. It is also possible that additional demand in the VISSIM and Arena model federates (given their current configurations), or that new configurations of those model federates, could lead to significant increases in computational load, although none of these possibilities were tested in this study.

The federation method was then applied to a case study of the Port of Savannah to investigate the feasibility of real-world system implementation and analysis, and to assess its ability to establish feedback loops between model federates in a more complex environment. Changes in the port container and vehicle queue lengths throughout the 5-day simulation runtime suggest that the port model federate responded to changes in input parameters in both the Arena port model federate (container creation rate), and the VISSIM roadway model federate (background traffic volume). The change in the truck queue from steady state near 40 trucks during day 1 to zero trucks during day 2 shows the Arena port model’s response to changes in container arrival rate. The gradual accumulation of containers in the port container queue during day 2, which becomes greater in day 3 shows the Arena port model responding to increased congestion on the roadway, which results in greater roundtrip travel time of port trucks, and therefore a greater interarrival time between trucks returning to the GCT.

The background traffic travel time data from the VISSIM roadway network further supports the response of the two model federates to changes in input parameters between the two models. These effects are seen most readily in the southbound travel time segment on GA Highway 21, and northbound travel time segment on Dean Forest Road. Southbound travel times along the GA Highway 21 segment show a moderate increase from day 1 to day 2, when container volume is increased. This is most likely due to increased container truck volume on the roadway, and resulting congestion at the intersection of Bourne Avenue and GA Highway 21. A more pronounced increase in travel time along the same segment occurs when background traffic volume is increased at the end of day 2. Travel times appear to remain constant along this segment throughout day 3 and day 4, although container volume is decreased at the end of day 3. This suggests that during day 3 and day 4, travel times are governed by roadway congestion, not port truck volume, which is consistent with heavily congested conditions in real-world traffic operations.

Travel times along the northbound segment on Dean Forest Road show greater sensitivity to changes in roadway traffic volume, with no perceptible effect from changes in container volume. When considering this in contrast to the greater sensitivity of travel times along GA Highway 21 to changes in both input parameters, it is apparent that additional factors (e.g. traffic signalization, roadway configuration) also affect roadway performance. Therefore, in addition to capturing the influence of model federate input parameters on federate performance, the federated simulation method maintains sensitivity to other parameters related to the structure and configuration of the individual model federates.

Simple Arena modeling efforts may choose to capture roadway/transport delay internally as a statistically distributed delay value. In all likelihood, the simplified roadway network models used in this study could be adequately represented by a simple delay distribution internal to Arena. However, when modeled roadway environments increase in complexity, the characteristics of the delay they cause may become more complex than a simple statistical distribution. As has been shown, the federated simulation method developed in this study can effectively combine two transportation models developed in disparate software packages, establishing information feedback loops between model federates dynamically, during runtime. This method allows separate, complex roadway models to replace overly simple statistically distributed delay characteristics in monolithic transport and logistics models. Future research efforts should focus on expanding this federated simulation to include more complex roadway network and terminal models; they should also explore ways to implement the federation in distributed computing environments to increase execution speed, particularly the RTI and database federates. Lastly, as the relative costs of increasing computational load in each model federate were tested in isolation, future research should explore whether any compounding costs exist when computational load is changed across multiple federates simultaneously.

Footnotes

Funding

Portions of this research were supported by Internal Research and Development (IRAD) funds from the Georgia Tech Research Institute (GTRI) for the development of advanced simulation methods.

Author biographies

Thomas Wall is an affiliate researcher with the School of Civil and Environmental Engineering at the Georgia Institute of Technology, Atlanta, GA. He currently works in the Risk and Infrastructure Science Center at Argonne National Laboratory, Chicago, IL.

Michael Rodgers is a principal research scientist in the School of Civil and Environmental Engineering and holds joint appointments with the School of Public Policy and the Georgia Tech Research Institute in Atlanta, GA. He also serves as deputy director of the National Center for Transportation Systems Productivity and Management.

Richard Fujimoto is a Regents’ Professor in the School of Computational Science and Engineering at the Georgia Institute of Technology, Atlanta, GA. He was the founding chair of that unit, and he led the development of the time-management services defined in the high-level architecture.

Michael Hunter is an associate professor at the School of Civil and Environmental Engineering at the Georgia Institute of Technology. He is also the director of the National Center for Transportation System Productivity and Management as well as the director of the Georgia Transportation Institute.

References

. A Framework for New Generation Transportation Simulation. In Proceedings of the 2006 Winter Simulation Conference, Monterey, CA. IEEE, 2006.

Kewley

. Federated simulations for systems of systems integration. In Proceedings of the 2008 Winter Simulation Conference, Austin, TX. IEEE, 2008.

IEEE. IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules. IEEE Std 1516-2000, IEEE, New York, 2000.

IEEE. IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Framework and Rules. IEEE Std 1516-2010, IEEE, New York, 2010.

Dahmann

. High level architecture for simulation. In First International Workshop on Distributed Interactive Simulation and Real Time Applications, Eilat. IEEE, 1997.

Ferenci

Perumalla

Fujimoto

. An approach for federating parallel simulators. In Proceedings of the Fourteenth Workshop on Parallel and Distributed Simulation, Bologne. IEEE, 2000.

DoD. High-Level Architecture. The Department of Defense (DoD) Modeling and Simulation Coordination Office (M&S CO), 2009. Available at: http://www.msco.mil/.

Dahmann

Lutz

. Persistent federations. In Proceedings of the 1998 Spring Simulation Interoperability Workshop. SISO, 1998.

Potuzak

. Distributed traffic simulation and the reduction of inter-process communication using traffic flow characteristics transfer. In Proceedings of the Tenth International Conference on Computer Modeling and Simulation, Cambridge, UK. IEEE, 2008.

10.

Potuzak

Herout

. Use of distributed traffic simulation in the JUTS project. In Proceedings of the International Conference on Computer as a Tool (EUROCON 2007), Warsaw. IEEE, 2007.

11.

Chronopoulos

Johnston

. A real-time traffic simulation system. IEEE Trans Softw Eng 1998; 47(1): 321–331.

12.

Yoginath

Perumalla

. Parallel vehicular traffic simulation using reverse computation-based optimistic execution. In 22nd Workshop on Principles of Advanced and Distributed Simulation, Roma. IEEE, 2008.

13.

Ozaki

. High performance road traffic simulation based on dynamic time step synchronization method. In 11th IEEE Symposium on Distributed Simulation and Real-Time Applications, Chania, Greece. IEEE, 2007.

14.

Ramluchumun

Kalantery

Winter

. Federating a parallel traffic simulation using HLA. In 21st European Conference on Modeling and Simulation, Prague, Czech Republic. ECMS, 2007.

15.

Klein

Schulze

Straburger

. Traffic simulation based on the high level architecture. In Proceedings of the 1998 Winter Simulation Conference, Washington, DC. IEEE, 1998.

16.

Gao

Jin

Wang

. HLA-based distributed simulation model for multimodel operation system on container terminals. In Asia Simulation Conference - 7th International Conference on System Simulation and Scientific Computing, Chengdu, China. IEEE, 2008.

17.

Puglisi

. Issues and Challenges of Federating Between Different Transportation Simulators, School of Civil and Environmental Engineering, Georgia Institute of Technology, Atlanta, GA, 2008, p. 75.

18.

. Simulated vehicle-to-vehicle message propagation efficiency on Atlanta’s I-75 Corridor. Transp Res Rec J Transp Res Board 2005; 1910: 82–89.

19.

Fujimoto

. Time management in the high level architecture. Simulation 1998; 71(6): 388-400.

20.

Fujimoto

. Parallel and Distributed Simulation Systems, Zomaya

(ed.) (Wiley Series on Parallel and Distributed Computing, vol. 300). New York: John Wiley & Sons, Inc. 2000.

21.

PTV. VISSIM 5.10-06 COM Interface Manual. Karlsruhe, Germany: Planung Transport Verkehr AG, 2008.

22.

Wall

. A Federated Simulation Approach to Modeling Port and Roadway Operations, School of Civil and Environmental Engineering, Georgia Institute of Technology, Atlanta, GA, 2010, p. 252.

23.

Law

. Simulation Modeling and Analysis, 4th edn, Case

Wolfe

(eds) (McGraw-Hill Series in Industrial Engineering and Management Science). New York: McGraw-Hill, 2007.

24.

Robinson

. A statistical process control approach to selecting a warm-up period for a discrete-event simulator. Eur J Operat Res 2007; 176: 332–346.

25.

Sandikci

Sabuncuoglu

. Analysis of the behavior of the transient period in non-terminating simulations. Eur J Operat Res 2006; 173: 252–267.

26.

Welch

. The statistical analysis of simulation results. In Lavenberg

(ed.), Computer Performance Modeling Handbook. New York: Academic Press, 1983.

27.

Gbologah

. Development of a Multimodal Port Freight Transportation Model for Estimating Container Throughput, School of Civil and Environmental Engineering, Georgia Institute of Technology, Atlanta, GA, 2010.