At any major port around the globe you'll find similarities that mark the basic structure of container terminals, the most important being that each deals in the traffic of containers. The port has a berth where ships arrive to unload and load containers. It may have a gate system where trucks arrive to pick up or drop off containers and then return again to the road. It may also have a rail yard where trains arrive on the port's property to deliver and receive container cargo. All of these systems utilize the yard area where the containers are "buffered" while waiting to be routed to the next system. Although berth, rail, gate, and yard are individual components in container terminals, they interface with each other at certain locations, which contribute to the container flow in and out of the terminal. These are calledinterfaces in the FlexTerm modeling paradigm. FlexTerm models each of these four major systems of the container terminal as well as the supporting structures and equipment needed for each. FlexTerm also employs the power of abstraction to allow a modeler to focus on one key area of the port, such as just the shipping-side operation. Whether modeling a full container terminal, or only a sector or two, the modeler should choose one or more interfaces, either berth, rail, gate, or yard to be the "Master Interface." Understanding the modeling structure, abstractions and master interfaces are key concepts in working with FlexTerm. This section will explain these key concepts in detail so that you, the modeler, can create an accurate model of your container terminal. The following topics are covered: - [Container Terminal Modeling](#ContainerTerminalModeling) - [Using Abstractions](#UsingAbstractions) - [Choosing a Master Interface](#ChoosingADataDriver) <a name="ContainerTerminalModeling">Container Terminal Modeling</a> <a name="ContainerTerminalModeling"></a> Container terminal interfaces: berth, rail, gate and yard. <a name="ContainerTerminalModeling">FlexTerm breaks down a container terminal into four distinct sectors: the berth, the rail, the gate and the yard (as pictured above). Each sector is called an interface.</a> <a name="ContainerTerminalModeling">In standard FlexSim, most models consist of a </a>[source](Flexsim_Users_Manual.html)(something that introduces parts, or [flowitems](Flexsim_Users_Manual.html), into the model) and a [sink](Flexsim_Users_Manual.html)(something that removes flowitemsfrom the model). The flowitems in FlexTerm are the containers. Containers are introduced into the model by ships (berth),聽trains (rail), or trucks (gate) and are similarly removed from the model by ships, trains or trucks. A container may arrive by a ship and exit by a truck. It may arrive by a truck and exit by a train. It may arrive by a ship and also exit by a ship. Any combination is possible where one interface acts as the source and another (or the same) interface acts as the sink. In the FlexTerm modeling paradigm, the interface acting as the source is called the "Master Interface" and the interface acting as the sink is called the "Slave Interface." In other words, containers will be generated in the "Master Interface" and removed in the "Slave Interface." The yard acts as the central hub since every container must visit the yard before moving to its destination (there may be some exceptions, which can be dealt with separately). Thus the yard is neither a source nor a sink; it is a container buffer (like a large and complex [queue](Flexsim_Users_Manual.html)). Containers are buffered in the yard for a given [dwell time](Container_Types.html) that may last for moments or for several days. To summarize: - Berth: Master Interface or Slave Interface - Gate: Master Interface or Slave Interface - Rail: Master Interface or Slave Interface - Yard: Slave Interface only Each interface - berth, rail, gate, and yard - is more than just a source, sink or queue. It is also a complex operation in and of itself. The berth receives a variety of ships on a tight schedule and uses [cranes](Crane.html) and [trucks](Truck.html)to move containers on and off the ships. The rail receives a variety of trains, also on schedules, and uses cranes, trucks and special yard blocks to service the trains. The gate is a portal for trucks arriving from the civilian road system. Those Over-The-Road (OTR) trucks are often [processed](GateProcess.html)(paper work and/or scans) before being [routed](GateToYard.html)to pickup or dropoff a container. The yard uses [yard blocks](YardBlock.html) (designated container storage areas), [RTGs](RTG.html), [top loaders](TopLoader.html) and trucksto handle the constant container traffic. All these supporting objects are available in the [ContainerTerminal object library](Introduction.html). To incorporate the full function of each sector, including arrival schedules and equipment assignments, each is defined through a [planner](Planners_Overview.html) - a set of menus that help the modeler set up the schedules and assignments. <a name="UsingAbstractions">Using Abstractions</a> <a name="UsingAbstractions"> A simulation is defined as, "a purposeful and often radical abstraction of a real life system which can be used to answer questions or solve problems. It contains only those elements of reality that are </a><a name="UsingAbstractions">needed</a><a name="UsingAbstractions"> to answer the question or solve the problem." FlexTerm supports this ability by allowing you to define just those elements of a container terminal that are necessary to answer your question while everything else is abstracted. This means that the details of the abstracted portion are ignored or hidden from the model so the modeler can focus on the essential portions.</a> <a name="UsingAbstractions"></a> Ship and yard operations with gate/rail abstracted. <a name="UsingAbstractions">For example, perhaps you only want to examine the ship side operation along with the yard content (pictured above). The gate and rail operations aren't necessary so they are abstracted by FlexTerm. Now you can focus on containers that are transferred by ship only.</a> <a name="UsingAbstractions"></a> Berth operation with yard, gate and rail abstracted. <a name="UsingAbstractions">Or you may want to simulate the berth only without聽worrying about the yard (pictured above). This scenario can be modeled as well. Any portion of the container terminal can be abstracted so long as at least one master/slave interface pair is modeled.聽In other words, the yard cannot stand alone, as the yard cannot be a master interface. </a> <a name="UsingAbstractions">To include an interface in the model you must first include the associated planner in the model. The </a>[berth,](Berth_Planner_Overview.html) [gate](Gate_Planner_Overview.html), and [rail](Rail_Planner_Overview.html)planners are included in the model by dragging the planner from the library window and dropping it onto the model view. The [yard](Yard_Planner_Overview.html) planner is automatically included in every model. Any of the included planners can be accessed via the [Container Terminal menu](Container_Terminal_Menu.html) after being added to the model. The second step to including an interface in the model is to create traffic through that interface (if traffic doesn't go through the interface it is the same as not including the interface). This is done by creating container operations in the berth and/or gate planners. In the berth planner, container operations are created on the [Hatch Profiles tab](Hatch_Profiles.html). In the gate planner, container operations are created on the [Arrivals tab](Arrivals.html). Each of these tabs has a section where you list the container operations in a table (see images below).  Arrivals table from the Gate Planner.  Hatch profiles table from the Berth Planner. To create a container operation, choose the operation type in the "Operation" field, the container type, size, equipment, and destination in the "Container Profile" field (see image below) and the number of containers for that operation in the "Min" and "Max" fields. That planner now generates container traffic, so that sector is included in the model.  Container Profile Dropdown Menu from the Berth Planner The "Destination" or "Origin" field of the container profile drop down menu can also be set. This selection determines where the containers are routed to. Routing container traffic through an interface different from the one that generated the traffic will cause the other interface to also be included in the model. When routing traffic either to the same or to a different interface, the yard must be used as a buffer and will, therefore, be included in the model. To avoid including the yard choose "None" in the "Destination" or "Origin" field. It can be tricky to use the "Destination" or "Origin" field correctly so be sure to also read "[Choosing a Master Interface](#ChoosingADataDriver)." The following table lists each possible abstraction style and how to set up the model correctly for that style. It describes which planners to use in the model, which container operation table to use, your choices for the "Destination" or "Origin"field, and how the model will behave while running. Planners Used Pertinent Table(s) "Destination" or "Origin" Model Behavior Berth + Yard  Berth, Yard Hatch "Yard" or "Berth" (See Choosing a Master Interfacefor Berth) Import containers move from ship to yard, wait the dwell time, and then disappear as if leaving by gate or rail. Export containers appear in the yard prior to a ship's arrival so as to be in the yard for the set amount of dwell time. Berth only  Berth Hatch "None" Import containers are unloaded by a crane and dropped onto the ground or a truck where they disappear as if going into the yard. Export containers appear at the crane or from a truck as if delivered from the yard. Dwell times are not used. Gate + Yard  Gate, Yard Arrivals "Yard" or "Gate" (See Choosing a Master Interface for Gate) Inbound containers move from gate to yard, wait the dwell time, and then disappear as if leaving by ship or rail. Outbound containers appear in the yard prior to a truck's arrival so as to be in the yard for the set amount of dwell time. Gate only  Gate Arrivals "None" After passing the gate to yard object, inbound containers disappear from the truck as if being dropped off in the yard, while outbound containers appear on the truck as if being picked up from the yard. Dwell times are not used. Berth + Gate + Yard  Berth, Gate, Yard Hatch, Arrivals "Yard", "Berth", "Gate" See Choosing a Master Interface See "Choosing a Master Interface" section below. Rail + Yard  Rail, Yard Train Schedule "Yard", "Rail" See Choosing a Master Interface Inbound containers move from rail to yard, wait the dwell time, and then disappear as if leaving by ship or gate. Outbound containers appear in the yard prior to a train's arrival so as to be in the yard for the set amount of dwell time. Berth + Rail聽 + Yard  Berth, Rail Yard Hatch, Trail Schedule "Yard", "Berth", "Rail" See Choosing a Master Interface See "Choosing a Master Interface" section below. Berth + Gate + Rail聽 + Yard  Berth, Rail, Gate Yard Hatch, Arrivals, Trail Schedule "Yard", "Berth", "Gate" "Rail" See Choosing a Master Interface See "Choosing a Master Interface" section below. <a name="ChoosingADataDriver">Choosing a Master Interface </a> <a name="ChoosingADataDriver">When multiple interfaces of a container terminal are modeled, one interface should act as the "Master Interface" while the other interfaces, acting as "Slave Interfaces," provide or receive containers according to the demands of the master interface. Thus, the master interface has operations that generate containers in the model while the other sectors have operations called "empty buckets" that support the data driver.</a> <a name="ChoosingADataDriver">Containers are generated by any type of operation where the "Min" and "Max" values contain non-zero positive numbers. Think of it in terms of push and pull. A berth discharge operation and a gate dropoff operation </a><a name="ChoosingADataDriver">push</a><a name="ChoosingADataDriver">containers into the model. Acting as sources, they each will create the required number of containers. A berth load operation and a gate pickup operation </a><a name="ChoosingADataDriver">pull</a><a name="ChoosingADataDriver">containers into the model - not out of the model. In this case, the abstract portion of the model acts as the source to create the required number of containers (even if all three potential sources are in the model, the containers are still created by an "unknown" source).</a> <a name="ChoosingADataDriver">Containers are </a><a name="ChoosingADataDriver">not</a><a name="ChoosingADataDriver">generated by an empty bucket operation where the "Min" and "Max" values are set to 0. Rather, this allows FlexTerm to create as many operations as needed to support the master interface. These empty bucket operations must exist in the model so that FlexTerm can create the right operations. If the empty bucket operations are not included correctly, the model will halt with an error.</a> <a name="ChoosingADataDriver">To understand how these operations work together, consider the following example. Here is a hatch profile from the berth planner.</a> <a name="ChoosingADataDriver"></a> <a name="ChoosingADataDriver">Hatch profiles table from the Berth Planner.</a> <a name="ChoosingADataDriver">This hatch profile generates 1000 containers to go out through the gate, 500 containers to come in from another ship, and 200 containers to go out to an unknown (or abstract) destination, e.g. Rail, (meaning they will just disappear from the yard). Each of these operations generates containers. The discharge operations </a><a name="ChoosingADataDriver">push </a><a name="ChoosingADataDriver">containers into the model and the load operation </a><a name="ChoosingADataDriver">pulls </a><a name="ChoosingADataDriver">containers into the model. All of the containers spend time in the yard before moving to their final destination, shown in the picture below.</a> <a name="ChoosingADataDriver"></a> <a name="ChoosingADataDriver">Since 1000 containers must go out through the gate, there must also be an operation in the gate planner to accommodate this. At first, you might try to create a container pickup operation of 1000 containers coming from the ship.</a> <a name="ChoosingADataDriver"></a> Arrivals table from the Gate Planner. <a name="ChoosingADataDriver">This operation, however, actually creates an </a><a name="ChoosingADataDriver">additional</a><a name="ChoosingADataDriver">1000 containers since a gate pickup operation </a><a name="ChoosingADataDriver">pulls</a><a name="ChoosingADataDriver">containers into the model, as shown below.</a> <a name="ChoosingADataDriver"></a> <a name="ChoosingADataDriver">The correct way to do this is provide an "empty bucket" on the gate side by setting the "Min" and "Max" values to 0. This allows FlexTerm to create as many container pickup operations as needed for any containers routed to the gate. The operation is setup as follows:</a> <a name="ChoosingADataDriver"></a> Arrivals table from the Gate Planner. <a name="ChoosingADataDriver">Additionally, 500 containers must arrive through the berth so there must be an operation in the berth planner to produce these. Again, you might try to create a ship discharge operation of 500 containers.</a> <a name="ChoosingADataDriver"></a> Hatch profiles table from the Berth Planner. <a name="ChoosingADataDriver">A ship discharge operation </a><a name="ChoosingADataDriver">pushes </a><a name="ChoosingADataDriver">containers into the model, so this operation will create an </a><a name="ChoosingADataDriver">additional </a><a name="ChoosingADataDriver">500 containers.</a> <a name="ChoosingADataDriver"></a> <a name="ChoosingADataDriver">Again, the correct operation is an "empty bucket" where the "Min" and "Max" values are set to 0. This allows FlexTerm to create as many container discharge operations as needed for containers required by another ship.</a> <a name="ChoosingADataDriver"></a> <a name="ChoosingADataDriver">Hatch profiles table from the Berth Planner.</a> <a name="ChoosingADataDriver">Alternatively, you can also create a "limited bucket" operation where the "Min" value is set to -1 and the "Max" value is set to the maximum number of containers you want this operation to handle. In the following example FlexTerm can create up to 250 discharge operations:</a> <a name="ChoosingADataDriver"></a> <a name="ChoosingADataDriver">Hatch profiles table from the Berth Planner.</a> <a name="ChoosingADataDriver">It's important to remember that when using the empty or limited bucket operations you have to create both the right type of operation and the right number of operations. Any operation with a "destination" or "origin" field other than the yard needs a matching empty bucket operation on the other end. If using a limited bucket operation, either the "Max" value should be large enough to receive all of the containers or there should be multiple limited bucket operations that combine to receive all the containers. </a> Note: Currently, Rail needs to be Master Interface when working with other interfaces.