FIELD OF THE INVENTION

[0001] This invention relates to simulation models, and more particularly, to discrete- event models of sea base operations.

BACKGROUND OF THE INVENTION

[0002] A sea base provides the capability to perform operations without the need for land-based facilities. Sea bases comprise a complex system of operations, ships, forces, aircraft, communications, and logistics, all of which require careful planning and coordination to operate smoothly and efficiently.

[0003] Naval forces can be placed on station and sustained as needed. A predominance of command and control, aviation, and service support can stay afloat, thereby minimizing the footprint ashore, providing greater maneuverability, and decreasing assets required for "rear area" functions and protection.

[0004] Once within a theater, forces and cargo move to and from the sea base via intra-theater lift resources such as High Speed Vessels (HSV), Landing Craft Air Cushion (LCAC), or V-22 aircraft, depending upon the numbers and types of cargo necessary to support any number of missions/operations, distance to the sea base, threat, and other factors. Reception, Staging, Onward Movement and Integration (RSO&I) take place at sea, expediting the preparation and eventual employment of forces. Selective offload increases the ability to organize the sea base material handling capabilities and future pre-positioning of platforms.

[0005] Selective offload is the ability to offload desired vehicles and cargo from the ship instead of having to offload the entire ship to get to the vehicle or cargo needed to support specific missions or operations. With selective offload, only mission-essential personnel and equipment will participate in initial operations ashore. No commander can foresee every contingency. Therefore, Maritime Pre-Positioning Force (MPF) and Amphibious Task Force (ATF) ships cannot be loaded to anticipate every potential mission, enemy, or vagary of terrain. Beyond the requirement to accept and assemble additional assets and personnel at sea, the ability to seamlessly integrate the assets contained throughout the sea base is critical for the maritime component commander to be able to accomplish the mission. Selective offload will require an MPF that can reposition its contents and interact at sea with advanced lighterage such as, but not restricted to, LCAC, HSV, and ATF vertical lift

assets. Selective offload increases the ability to organize at the sea base and thereby increases the tempo of operation.

[0006] One major objective of sea basing is to compress deployment and employment times to permit ground combat power projection within days rather than weeks or months, without reliance on ports or airfields ashore. By operating from ships, the logistics base reduces the operational footprint ashore, and provides for phased at-sea assembly and arrival of equipment and selective offload of specific equipment to support a variety of missions.

[0007] Close cooperation is required to manage the finite lift resources necessary to satisfy a broad range of operational and logistics missions associated with amphibious logistics and the sea base concept.

[0008] This invention provides a simulation tool that can be used to model various aspects of a sea base. The tool can provide total asset visibility of logistics flow, allowing for improved asset availability and increased velocity of material movement through the system. This can allow lower inventory levels and promote better sustainment response.

SUMMARY OF THE INVENTION

[0009] This invention provides a method for modeling the transfer of cargo in a sea base environment. The method comprises the steps of defining a plurality of events representative of movement of the cargo, assigning attributes to the events and/or the cargo, simulating the sequential occurrence of the events in conformance with the attributes, and providing an output of the results of the simulation.

[0010] In another aspect, the invention encompasses a system for modeling the movement of cargo containers. The system comprises: a first module for calculating a time needed to move cargo within a well deck of a ship; and a second module for calculating a time needed to move cargo from afloat to ashore; wherein each of the first and second modules defines a plurality of events representative of movement of the cargo, assigns attributes to the events and/or the cargo, simulates the sequential occurrence of the events in conformance with the attributes, and provides an output of the results of the simulation.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 is a schematic representation of the modules used to implement the present invention.

[0012] FIGs. 2-6 are flow diagrams illustrating the operation of a simulation in accordance to the invention.

[0013] FIG. 7 is a block diagram illustrating the operation the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0014] This invention is referred to as a Sea Base Logistics Assessment Tool (SLAT). It is particularly applicable to the Amphibious Logistics component of a sea base. The SLAT is a dynamic, discrete-event simulation model that supports the concept of amphibious logistics by determining the time to transfer containers from afloat to ashore and back again. In one embodiment of the invention, the SLAT is comprised of at least two modules that complement, support, and are consistent with sea basing and ship-to-objective maneuver concepts.

[0015] A software representation of the dynamic or time-based behavior of the system can be used to model (or simulate) cargo transfer from afloat to ashore. While a static model involves a single computation of an equation, dynamic modeling, on the other hand, is iterative. A dynamic model constantly re-computes its equations as specified parameters change, such as time.

[0016] Dynamic modeling can predict the outcomes of possible courses of action and can account for the effects of variances or randomness. One cannot control the occurrence of random events. One can, however, use dynamic modeling to predict the likelihood and the consequences of such events.

[0017] A discrete event model is one in which the state of the model changes at only a discrete, but possibly random, set of time points, known as event times. The discrete events change state as events occur in the simulation. For example, a LCAC arrives at a ship with cargo to be unloaded. The arrival of the LCAC is an event. It occurs at a point in time. The unloading of the cargo is another event that occurs at a point in time. The state of the model changes only when those events occur. The mere passing of time has no direct effect. The time between events in a discrete event model is seldom uniform.

[0018] The Sea Base Logistics Assessment Tool provides a discrete-event simulation model that supports the concept of amphibious logistics by determining the time required to transfer cargo containers from afloat to ashore and back again. Such containers are moved by various devices, generally referred to as lift resources. The simulation model can be used in the management of finite lift resources to satisfy the broad range of operational and logistics missions that require close coordination.

[0019] Discrete event modeling considers its elements to be individual entities that can hold attributes. In one embodiment of the invention, the SLAT is comprised of two modules that complement, support, and are consistent with sea basing and ship-to-objective maneuver concepts. The first module, or component, (module 1) of the SLAT calculates the time needed to move cargo within the well deck of a ship. The parameters of the module can

be controlled to compare various scenarios. Module 1 outputs can include the average transfer rate, delay times, average wait time, max wait time, and load time per container per operational scenario.

[0020] The second module, or component, (module 2) of the SLAT expands the first module and calculates the time needed to transport mission resources from afloat to ashore and back again. This module can look at various modes of transportation including the Landing Craft Air Cushion (LCAC), V-22 Osprey and dockside, and can provide the capability to conduct basic "what-if" analysis to determine the impact that reduced transportation capabilities would have on supporting varying mission and operational scenarios.

[0021] Module 2 outputs can include comparisons of delivery times associated with varying modes of transportation such as a LCAC, V-22 Osprey,, or CH-53 helicopter. This module can be used to identify the appropriate mix of lift resources for each mission/objective and is used to identify potential shortfalls in support postures.

[0022] The Sea Based Logistics Assessment Tool can be used to track supplies, project availability, and coordinate and control ship-to-shore and ship-to-objective delivery of supplies to the forces operating ashore. It can also be constructed to offer a range of functions vital to sea basing, including the capability to locate and project timelines to access specific cargo items embarked aboard the sea base.

[0023] FIG. 1 is a schematic representation of the data interfaces for the Sea Base Logistics Assessment Tool. The first module 10 includes various data identified as ship data 11, container data 12, crane data 13, and mission support data 14. Various scenarios can be simulated as illustrated by item 15. The simulations based on these scenarios can result in outputs in the form of output files 16, ad-hoc reports 17, output reports 18, or animation 19. The second module 20 includes various data identified as V-22 Osprey data 21, LCAC data 22, sea states 23, basic "what-ifs" 24, and detailed missions 25. Various scenarios can be simulated to produce outputs in the form of output files 26, ad-hoc reports 27, output reports 28, or animation 29. A third module 30 can be added to build upon the first and second modules and provide the capability to conduct "what-if analysis. The third module can be used as a mission planning tool to support mission or operation objectives such as, cargo visibility, cargo operations, mission planning, mission tracking and mission execution. In addition, the third module can support sea basing, operational maneuvers from the sea, and ship-to-objective maneuver concepts. The modules can be implemented in software that runs on a computer 31.

[0024] Module 1 can calculate the time needed to move cargo within the well deck of a ship. This module can take into account, but is not be limited to, the following parameters:

(a) the types of cargo, including the container type;

(b) the distance and time required to trolley a crane to the cargo;

(c) delays associated with the repair of assets, for example, the repair of a crane;

(d) the distance and time to hoist/lower, and latch and unlatch a spreader bar used to lift a container;

(e) the time associated with positioning of the spreader bar;

(f) the location and height of containers in a stack of cargo; and

(g) the distance and time for translating cargo.

[0025] The module can identify containers required to support specific mission or operation requirements; add criticality/priority codes identifying which containers are used on specific mission/operations; determine the time to remove containers that interfere with 'current' loading and unloading of cargo within the well deck; and develop various operational scenarios.

[0026] Module 1 can provide outputs in the form of an animation of the ship's load/unload process within the well deck; and simulation reports and graphics that quantify key scenario results such as the average transfer rate, delay times, average wait time, maximum wait time, and the load time per container.

[0027] Predetermined reports can be produced based on the information in the input tables such as: mission/operation type, resources required for support of the mission/operation, characteristics of the sea and air transport vehicles and simulation model analyses. Such reports can include: (1) a comparison of times associated with 1 crane vs. 2 crane operation; and (2) a comparison of times associated with placement of containers in a storage area to satisfy a majority of missions or operations versus the movement of interfering containers.

[0028] Module 2 looks at various modes of transportation including the Landing Craft Air Cushion (LCAC), V- 22 Osprey and Dockside. This module can take into account, but is not limited to, the following parameters:

(a) the time required to transfer containers from the well deck to the transport vehicle;

(b) for V-22 Osprey and loading of containers Dockside, the time required to move cargo from the well deck to the topside lift vehicle;

(c) the speed and range of the cargo vehicle;

(d) the lift capacity of the vehicle;

(e) the availability of the cargo vehicle;

(f) the operating time of the cargo vehicle;

(g) the sea state and weather conditions; (h) the number of sorties per day; and

(i) basic "what-if ' analysis to determine the impact of supporting various mission and operational scenarios, with reduced transportation capability.

[0029] Module 2 can provide an expansion of the animation developed by module 1 to include loading of cargo from the well deck to topside, delivery from afloat to ashore and back again, and simulation reports and applicable graphics that quantify key scenario results such as the average transfer rate, delay times, average wait time, maximum wait time, and load time per container.

[0030] Predetermined reports can be produced based on input tables and simulation model analyses. Such reports can include: (1) a comparison of times associated with different modes of transportation such as LCAC only, or a V-22 Osprey and LCAC mix; and (2) a comparison of times associated with the placement of containers in a storage area to satisfy a majority of the missions or operations versus the movement of interfering containers and transport times from afloat to ashore.

[0031] Due to the different types of requirements found in the transporting of cargo within the ship itself and the delivery of cargo from the ship (afloat) to its intended location on the shore (ashore), the SLAT has been developed as separate but interrelated modules. The SLAT can be implemented using an object oriented software package. The underlying structure of the SLAT simulation environment is divided into smaller sub-components that can be easily designed, implemented and tested. Through the use of inputs and outputs attached to the objects contained in the SLAT, modules can be added seamlessly as additional requirements are identified.

[0032] Modules 1 and 2 can be combined into a seamless simulation, and can be used to influence the design of the MPF(F) ship by focusing on its cargo areas. Through alternative analyses, the modules can ascertain the optimal layout for supporting various missions or objectives with regard to the operational tempo (OPTEMPO), which is the rate of usage of personnel and equipment.

[0033] The SLAT provides a tool for understanding and studying the complexities involved in a sea basing concept. Through the use of clocks and compressed time, a representation of the complex environment can be achieved.

[0034] The SLAT simulation environment can be divided into smaller subcomponents that can be easily designed, implemented and tested. The component interfaces are defined so that all components can be designed independently. The components of SLAT are defined as independent objects that contain details and characteristics of discrete events such as cargo data, cargo handling equipment data, etc. The component interfaces are the connectors for the objects that are contained within SLAT. The simulation components can be developed incrementally, and new components should not interfere with previously developed components.

[0035] From a software engineering perspective, it is good to design components that are reusable. For instance, if the form of the graphical user interface is the same for several different systems, a user will be able to quickly adapt from one simulation environment to the other.

[0036] Providing a database of possible scenarios and configurations allows for easy specification and testing of mission scenarios. Through the use of data tables, the user will be able to do partial re-runs after data post-processing and analysis, to verify a hypothesis or a problematic run.

[0037] A discrete-event simulation model is a model of discrete events occurring in time. It accounts for resource utilization and queue buildups whenever an event is scheduled that requires a specific resource that is busy. This modeling approach fits well in a container transfer situation, where the primary resources are the cranes and the entities that trigger the events are the containers. The key information that drives the simulation is an ordered entity arrival list. In the case of a sea base simulation, the entity arrival list is simply a listing of all of the containers on the ship being modeled, sorted in the order that they are to be unloaded, and identified by an exact location on the ship.

[0038] The simulation can assume that only one crane is used, based on the assumption that the overall container transfer rate will be a multiple of the single-crane transfer rate multiplied by the number of cranes incorporated in the design. This assumes that each crane will operate independently of the others and that each crane's cargo area will not overlap the others.

[0039] Assumptions are important in the design and development of a simulation.

Assumptions may not be all-inclusive, but may apply to specific simulations and analyses,

and are used to set the boundaries for the model/analyses under consideration. In one example simulation, containers are delivered to a ship using two LCACs, each carrying six 40-foot containers, double stacked. Containers are unloaded as stacks, three high. Time starts with the arrival of the LCAC at the ship. Event times are based on industry averages. The containers are not subject to sway. The ship includes two cranes, and either crane can unload all containers.

[0040] Two types of LCAC are assumed, and the types are designated as No. 1 and No. 2. LCAC No. 1 is assumed to be positioned forward. A crane unloads 27 containers starboard side and the remaining 9 containers are unloaded port side. A total six LCAC No. 1 are used. Containers are double stacked on each LCAC No. 1. A total of 36 containers are unloaded from LCAC No. 1.

[0041] LCAC No. 2 is assumed to be positioned rear. A crane unloads 36 containers port side. A total of six LCAC No. 2 are used. Six containers are double stacked on each LCAC No. 2. A total of 36 containers are unloaded from LCAC No. 2.

[0042] It is important to note that the assumption of each LCAC carrying 6 containers at a time may not be realistic. This number is used for the purposes of placing a boundary on the modeling effort. In reality, the number of containers placed on an LCAC is based on the load [gross weight] capacity of the LCAC.

[0043] Module 1 of the SLAT calculates the time it takes to unload containers, from an LCAC to the shipboard container storage area within the well deck of a ship. Initial data required by the module must be obtained. This data can include information concerning distance from the LCAC to the storage area within the well deck, as well as both loaded and unloaded basic crane trolleying and hoisting times. Where specific data is not available, assumptions can be used, such as averages based on commercial container shipping companies, with the data being modified for shipboard applications.

[0044] To determine initial inter-arrival times as well as distances, with containers traveling (trolleying, hoisting and transversing) in both directions, a preliminary model was developed in a spreadsheet format. This initial spreadsheet model provided sample inter- arrival times for inclusion in the basic 'top level' module 1.

[0045] In one example, the container transfer model includes the following nine specific steps beginning with the crane traveling unlatched from its storage position:

1. Lift the crane to a travel position on a main track;

2. Trolley the crane to a target container;

3. Lower the crane to the target container on the LCAC;

4. Focus on the target container. To focus on a container is to position the spreader bar such that it is seated on the top of the container. This ensures the correct positioning allowing for the proper latching of the spreader bar;

5. Connect and latch a spreader bar to the target container;

6. Lift the container to a travel position;

7. Move the container to a designated storage position on the ship;

8. Lower the container to a designated storage position; and

9. Unlatch/disconnect the spreader bar from the container.

[0046] The simulation proceeds by stepping through these steps for each container, in turn, calculating the time to execute the step and pausing as required by conditions impacted by time constraints. It is important to observe that after Step 9 is complete, the crane can proceed to start Step 1 for the next container in parallel with the storage of the just unloaded box.

[0047] Steps 3 and 5 contain additional substeps whenever the container is located below deck in cell guides that align the containers for proper stacking and storage as in the case where a 20-foot container can be placed and secured in a space designed for a 40-foot container. In these cases, Step 3 includes additional substeps for inserting the spreader bar into the cell guide and lowering the spreader bar into the cell guide. Step 5 can also include a sub-step for lifting the container to the top of the cell guide.

[0048] The simulated process time for each of these steps is calculated by the model based on the characteristics of the crane design and the physical distances traveled. For instance, the times for Steps 1, 2, 5, 6, and 7 are based on the distance moved, divided by the crane's travel speed in that direction. All of these design factors are user-changeable inputs to the model, allowing for analysis of alternative crane designs or alternative ship configurations.

[0049] There are numerous input variables needed to construct a robust Sea Based Logistics Assessment Tool such as crane speeds, container dimensions including gross weight, fuel consumption for different types of transport vehicles when transporting cargo from afloat to ashore and back again, mission requirements, and time to locate specific cargo/containers for specific mission/objectives. The input variables used in an example simulation in Module 1 included the following:

1. The quantity and location of the containers on the LCAC;

2. The distance that the crane trolleys to the containers;

3. The distance that the spreader bar is lowered and hoisted at the LCAC;

4. The distance that the container trolleys from the LCAC to a storage location;

5. The distance that the spreader bar is lowered and hoisted at the storage location;

6. The time expended in positioning, latching and unlatching the spreader bar at the LCAC and storage location;

7. The height of the containers when stacked on the LCAC [2 level] and the storage location [3 level];

8. The crane trolleying speed; and

9. The crane hoisting and lowering speed, both loaded and unloaded. [0050] Among its other capabilities, the SLAT could be used to track supplies, project availability, and coordinate and control ship-to-shore and ship-to-objective delivery of supplies to the forces operating ashore. It can also be constructed to offer a range of functions vital to sea basing including the capability to locate and project timelines to access specific cargo items embarked aboard the sea base.

[0051] The simulation model tool can be implemented using a general-purpose simulation program such as Extend . The Extend program provides a multi-domain environment that allows one to dynamically model discrete events, continuous, linear, nonlinear, and mixed-mode systems. The model can provide Mission Execution Standard simulation output reports including applicable graphs of data such as the average transfer rate, delay times, average wait time, maximum wait time, and load time per container.

[0052] The simulation model has been demonstrated by calculating the time it takes to unload containers, from Landing Craft Air Cushions (LCAC) to the shipboard container storage area within the well deck of a ship. To demonstrate the numerous Scenarios that can be modeled, six operating Scenarios were evaluated, including:

Scenario 1 - Perfect throughput with two-crane operation;

Scenario 2 - Reduced throughput with one crane down during one half of current operation time; Scenario 3 - Reduced throughput with one crane down during the entire current operation time;

Scenario 4 - Two-crane operation with reduced throughout due to interfering containers [interfering containers are those not required for the

current mission/operation but located in- the way of target containers]; Scenario 5 - Reduced throughput with one crane down during one half of the current operation time, and interfering containers; and

Scenario 6 - Reduced throughput with one crane down during the entire current operation time, and interfering containers.

[0053] Cargo operations for Scenarios 1-3 address the unloading of containers from the LCACs. Scenarios 4-6 address the loading of containers from their on-board storage locations onto the LCACs. Though not the case in reality, for the purposes of this module, it was assumed that the tasks required to unload the LCACs and the tasks required to load the LCACs were the same with just the direction of the flow being different.

[0054] Additionally, it was assumed that the total elapsed time would be the same for the following combinations: (1) Scenarios 1 and 4, (2) Scenarios 2 and 5, (3) Scenarios 3 and 6. To bring in a measure of reality, Scenarios 4-6 introduce the time needed to remove interfering containers, in order to access required containers to support a mission/objective.

[0055] Scenario No. 1 assumed that there would be a perfect flow of cargo using two cranes in a concurrent unload operation. Neither crane would interfere with the other crane's operation. Each crane would unload a total of 36 containers. There would be no interference of containers during the cargo operation.

[0056] Concurrent operation of two cranes results in a total elapsed time equal to the longest time experienced by one crane in unloading 36 containers. As mentioned previously, the number of containers identified with each LCAC is for illustration purposes only. The total number of containers loaded onto an LCAC is based on the LCACs Gross Weight [load] capacity.

[0057] Scenario No. 2 assumes that one of the two cranes will be inoperable during the entire unload operation. All 72 containers will be unloaded from LCAC No. 1 and LCAC No. 2 using one crane. Since it was initially assumed that LCAC No. 1 would always be forward of LCAC No. 2, the total elapsed unload time for this Scenario is equal to the cumulative elapsed time for unloading LCAC No. 1 and LCAC No. 2.

[0058] For Scenario No. 3, it was assumed that one crane would be inoperable during the first half of the LCAC unload operation. Half way through the unload operation, the second crane would be placed on-line. This Scenario assumed that the first 36 containers would be unloaded using one crane. Once the second crane is back on-line, the remaining 36

containers would be unloaded using both cranes concurrently. Therefore, the total elapsed time equals the longest elapsed time for unloading 56 containers.

[0059] Scenarios No. 4-6 address the retrieving of containers from their respective storage locations within the well deck, and loading them onto the LCACs for mission/operation support. The basic tasks during the LCAC load operation are similar to that of the LCAC unload operation with a different direction. To add a measure of realism, Scenarios 4-6 introduced hidden containers into the model. To support specific missions/objectives there would be varying numbers of containers loaded. For the purposes of module 1, it is assumed that a total of seventy-two containers would be loaded onto LCACs.

[0060] As in Scenario No. 1, Scenario No. 4 assumes that there would be a perfect flow of containers using two cranes [concurrent load operation]. Neither crane would interfere with the other crane's operation. As in Scenario No. 1, Scenario No. 4 assumes that there would be a perfect flow of containers using two cranes in a concurrent load operation. Neither crane would interfere with the other crane's operation.

[0061] Scenario No. 4 puts more reality into the model by introducing hidden containers. For the purposes of this model, hidden containers are defined as those containers that are required to support a specific mission/operation but are hidden [located] underneath other non-essential [interfering] containers.

[0062] Based on the storage location of containers onboard ship and the specific mission/operation being conducted, there are many combinations and numbers of hidden containers. For the purpose of this example, a total of ten 'hidden' containers were used. There is a 'staging' area located between the port and starboard container storage areas. As an interfering container is moved to access a required container, the interfering container is moved to the staging area, the required container or containers are then acquired by the crane, moved and loaded onto the LCAC. Afterwards, the container that was placed in the 'staging' area is moved back to its original storage location.

[0063] ' The total elapsed time for the loading of 72 containers in Scenario No. 4 is equal to the longest time experienced by one crane in unloading 36 containers plus the time it takes to locate the hidden containers; position and lock the spreader bar; trolley the interfering container to the staging area [center aisle]; and then position and lock the spreader bar onto the required container and trolley it to the LCAC to support the mission/objective. The interfering container is then replaced in its original shipboard storage position in the reverse order.

[0064] As in Scenario No. 2, Scenario No. 5 assumes that one of the two cranes will be inoperable during the entire unload LCAC operation. Therefore, all 72 containers will be unloaded from LCAC No. 1 and LCAC No. 2 using one crane.

[0065] Since it was initially assumed that LCAC No. 1 would always be forward of LCAC No. 2, the total elapsed unload time for Scenario No. 5 is equal to the cumulative elapsed time for unloading LCAC No. 1 and LCAC No. 2, plus the time it takes to locate the hidden containers; position and lock the spreader bar; trolley the interfering container to the staging area [center aisle]; and then position and lock the spreader bar onto the required container and trolley it to the LCAC to support the mission/objective. The interfering container is then replaced in its original shipboard storage position in the reverse order.

[0066] As in Scenario No. 3, Scenario No. 6 assumed that one crane would be inoperable during the first half of the LCAC unload operation. Half way through the unload operation, the second crane would be placed on-line. Scenario No. 6 assumed that the first 36 containers would be unloaded using one crane. Once the second crane is back on-line, the remaining 36 containers would be unloaded concurrently. As with Scenario No. 4, Scenario No. 6 also contains ten hidden containers.

[0067] The total elapsed time for Scenario No. 6 equals the longest elapsed time for unloading 56 containers, plus the time it takes to locate the hidden containers; position and lock the spreader bar; trolley the interfering container to the staging area [center aisle], and then position and lock the spreader bar onto the required container and trolley it to the LCAC to support the mission/objective. The interfering container is then replaced in its original shipboard storage position in the reverse order.

[0068] This invention provides a simulation that can be used as a mission-planning tool to generate alternatives to support various missions/objectives. The output of the spreadsheet model was used in the determination of the interarrival rates of the container transfers within the simulation model itself. The initial simulation used the same assumptions as that identified for the spreadsheet model as well as the same input variables. A notable exception is in the interarrival times used in each model.

[0069] The spreadsheet model represents a static model and therefore, for each scenario the total elapsed times would be constant. In reality the times would not be static but would be dynamic. Table 1 shows the distribution times and interarrival times for Scenario No. 2 based on the spreadsheet model results. Distribution here means the time it takes to move a container throughout its complete cycle be it unloading the container from the LCAC to its designated storage location or loading the container from its shipboard

location onto the LCAC. Distribution time is measured in minutes and in this instance is identified as the minimum time, maximum time or most likely time. It was an analysis of the spreadsheet distribution times that resulted in the determination of the interarrival time for the movement of the containers in the simulation. Interarrival time is a random variable and measures the time between consecutive transactions such as the discrete movement of cargo as it goes through its load or unloads cycle. Exponential random times are used to model interarrival times when there is little or no control over the arrival process. The exponential distribution allows for a very simple state of the system at time t, namely the number of pieces of cargo in the system [to be loaded to support a mission], and the piece of cargo being loaded onto or unloaded from a delivery vehicle. Examples of such arrival processes include arrival of patients at the emergency room of a hospital, or orders at an order-filling center, of ships at a harbor or sea base.

Table 1: Distribution and Interarrival Times

[0070] Module 1 addresses cargo transfer activities below deck and calculates the time needed to move cargo within the well deck of a ship either loading containers on the LCACs, or unloading containers from the LCACs.

[0071] An important consideration with running simulations is whether the simulation is continuous or starts up every day. This has an impact on a simulation's results. If the simulation starts up every day, a condition known as start-up bias comes into play. Start-up bias results in erroneous times by introducing an exaggerated initial time. To assist in precluding the effects of start-up bias, the simulation would be run for a longer period of time than would be experienced in the real world system. One thing that can assist in locating specific containers, and reduce total elapsed times, is to mark each container with criticality/priority codes.

[0072] Table 2 shows a comparison of the results of running the spreadsheet model and the simulation model for Scenario No. 1. The differences in the simulation times are due

to the dynamic properties associated with the discrete simulation model. The resultant times used in Table 2 are the longest elapsed time for each run.

Table 2: Comparison of Model Outputs

[0073] An additional module can be added to provide the capability to conduct "what- if" analyses and can be used as a mission-planning tool to support mission/operation objectives. The SLAT can be used to support, but is not limited to, the following five functional logistic areas associated with Sea Basing, Operational Maneuver From The Sea (OMFTS), and Ship-To-Objective Maneuver (STOM): Cargo Visibility, Cargo Operations, Mission Planning, Mission Tracking, and Mission Execution.

[0074] Cargo Visibility displays all cargo items and their current location: onshore, at the sea base, at an Intermediate Staging and Embarkation Point (ISEP), or en route to the ISEP aboard Navy and merchant shipping. Cargo Operations shows the current cargo location, whether onboard or en route, and estimates an item's time of arrival onshore or at the sea base. Mission Planning coordinates supply orders and determines the availability of requested items, the location that will receive the items, and how the items will reach the appropriate location in the most efficient and timely manner. Mission Tracking shows the status of the mission in near real time. Mission Execution provides for continual adjustment of the plan to meet the changing needs of the supported force.

[0075] FIGs. 2-6 are flow diagrams that illustrate the operation of the modules that comprise one embodiment of the Sea Based Logistics Assessment Tool (SLAT). Each description has an accompanying flow chart to provide a graphical representation of the simulation flow. Module 1 is divided into modules IA and IB, and module 2 is divided into modules 2A and 2B. Module IA models the transfer of cargo from an LCAC to a ship storage area [Load Component]. Module IB models the transfer of cargo from a ship storage area to an LCAC [Unload Component]. Module 2A models the transfer of cargo from ashore to afloat. Module 2B models the transfer of cargo from afloat to ashore.

[0076] FIG. 2 illustrates the operation of a model of the transfer of cargo from an LCAC to a ship storage area, as performed in module IA. In FIG. 2, the model starts 41, initializes clocks and counters [set to zero] 42, identifies the type of mission 43, identifies the cargo/resource mix 44, and identifies the type of handling equipment [i.e., a crane unique for a specific container; or "other" handling equipment (i.e., a forklift for break-bulk)] 45. The model determines if appropriate handling equipment is available 46.

[0077] If handling equipment is not available 48, defective handling equipment is sent for repair 49. After repair, the equipment is indicated as available. Alternative handling equipment can be located 50 [i.e., on other parts of the ship or on other ships]. Then the model again determines if enough handling equipment is available 51.

[0078] If sufficient handling equipment is still not available, a delay time is added to a counter 53. The model again determines if enough handling equipment is available 54. This process continues until sufficient equipment is available. Once sufficient equipment is available, the location of required cargo is identified 55. Handling equipment is sent to pick up the selected cargo 56.

[0079] If the crane is unique 57: a) position a spreader bar over a container; b) lower the spreader bar onto the top of the container; c) latch the spreader bar to the container; and d) hoist the container and prepare it for transfer. If "other" handling equipment 58, i.e. a fork lift is used, then: a) position a lifting device of appropriate cargo handling equipment into a proper position for lifting cargo; b) secure the cargo to the lifting device of the handling equipment; and c) hoist the cargo and prepare it for transfer.

[0080] The cargo is then moved to the LCAC 59. If the crane is unique 60: a) position the cargo over a storage location on LCAC; b) lower the container to an appropriate location on the LCAC; c) disconnect the spreader bar from the container; d) raise the spreader bar; and e) secure/latch the container on the LCAC.

[0081] If "other" handling equipment 61, i.e. a forklift is used, then: a) move the cargo onto the LCAC; b) position the cargo to an appropriate location on the LCAC; c) lower the cargo; d) disconnect the lifting device; and e) secure/latch the cargo on the LCAC. Then the container and cargo counters are checked 62 to determine if the container loading is complete 63. If not 64, the container counter is incremented 65, and the unload process is repeated 66.

[0082] Next the container and cargo counters are again checked 62 to determine if the container loading is complete 67. If not 68, the container counter is incremented 69, and the unload process is repeated 70. After unloading is complete, the container time clock is

stopped 71, and the crane is trolleyed to a shipboard storage location and secured 72. Block 73 indicates a return to block 67.

[0083] The cargo time clock is stopped 74, "other" handling equipment is moved to a shipboard storage location 75, the container and cargo time clocks are totaled 76, and the clock data is stored 77. Reports are generated 78 as required using either: 1) a print to screen or 2) save to disk operation, and the process ends 79.

[0084] FIG. 3 illustrates the operation of a model of the transfer of cargo from a ship storage area to an LCAC, as performed in module IB. In FIG. 3, the model starts 81, and initializes clocks and counters [set to zero] 82, prior to arrival of the LCAC 83. It then identifies the type of cargo to be removed 84, and identifies the type of handling equipment [i.e., a crane unique for a specific container; or "other" handling equipment (i.e., a forklift for break-bulk)] 85. The model determines it appropriate handling equipment is available 86.

[0085] If appropriate handling equipment is not available 88, defective handling equipment is sent for repair 89. After repair, the equipment is indicated as available. Alternative handling equipment can be located 90 [i.e., on other parts of the ship or on other ships]. Then the model again determines if enough handling equipment is available 91. If sufficient handling equipment is still not available, a delay time is added to a counter 93. Then the model again determines if enough handling equipment is available (block 94). If sufficient handling equipment is available, the handling equipment is moved from the storage location to the LCAC to pick up the cargo 95. If the crane is unique 96: a) position a spreader bar over the container; b) lower the spreader bar onto the top of the container to be unloaded from the LCAC; c) latch the spreader bar to the container; and d) hoist the container and prepare it for transfer.

[0086] If "other" handling equipment 97, i.e. a fork lift is used, then: a) move the handling equipment onto the LCAC and proceed to the cargo to be unloaded; b) position a lifting device of the handling equipment into a proper position for lifting the cargo; c) secure the cargo to the lifting device of the handling equipment; and d) hoist the cargo and prepare it for transfer. Then the cargo is moved 98 to appropriate location on ship.

[0087] If the crane is unique 99, then: a) position the cargo over a storage location on the ship; b) lower the container onto the appropriate shipboard storage location; c) disconnect the spreader bar from the container; d) raise the spreader bar; and e) secure/latch the container in its appropriate shipboard storage location.

[0088] If "other" handling equipment 100, i.e. a fork lift is used, then: a) move the handling equipment with its cargo to its appropriate shipboard storage location; b) position

the cargo to an appropriate shipboard storage location; c) lower the cargo; d) disconnect the lifting device; and e) secure/latch the cargo in its appropriate shipboard storage location.

[0089] Then the container and cargo counters are checked 101 to determine if the container unloading is complete 102. If not 103, the container counter is incremented 104 and the loading process is repeated 105. The model again checks if the cargo unloading is complete 106. If not 107, the container counter is incremented 108 and the loading process is repeated.

[0090] After loading is complete, the container time clock is stopped 110, and the crane is trolleyed to a shipboard storage location and secured 111. Block 112 indicates a return to block 106. The cargo time clock is stopped 113, and the "other" handling equipment is moved to a shipboard storage location 114.

[0091] The container and cargo time clocks are totaled 115, and the clock data is stored 116. Reports are generated 117 as required using either: 1) a print to screen or 2) save to disk operation, and the process ends 118.

[0092] FIG. 4 illustrates the operation of a model of the transfer of cargo from afloat to ashore, as performed in module 2A. In FIG. 4, the model starts 120, initializes the module 2 A clocks and counters [set to zero] 122, and adds a stored value from module 1. The model determines 124 if a sea vehicle or an air vehicle is to be used. Cargo is received from below deck 125. The model then identifies the type of transport respurces (for example, V-22 or CH-53) 126, loads cargo onto the air vehicle 128, and lashes and secures the cargo 128. The loaded delivery vehicle is transferred from afloat to pre-determined location on shore 129 and cargo is delivered to a marshalling area 130. The cargo is then unlashed 131 and unloaded 132.

[0093] If any cargo is ready for return to the ship 133, the process switches to the SLAT Module 2B process illustrated in FIG. 5, as shown in block 134. The delivery vehicle is readied for return to the ship 135, and returns to the ship 136. Next the model determines if the sea delivery of cargo is complete 137. If not 138, the process is repeated 129. After delivery by the sea vehicles is complete, the sea vehicles time clocks are stopped 139. The sea vehicles are then moved to a storage location on the ship 140 and secured 141.

[0094] Next the model determines if the air delivery of cargo is complete 142. If not 143, the process is repeated. After delivery by the air vehicles is complete, the air vehicles time clocks are stopped 144. The air vehicles are then moved to a storage location on the ship 145 and secured 146. The sea and air delivery clocks are totaled 147 and the clock data

is stored 148. Reports are generated as required using either: 1) a print to screen or 2) save to disk operation, and the process ends 150.

[0095] FIG. 5 illustrates the operation of a model of the transfer of cargo from ashore to afloat, performed by module 2B. In FIG. 5, the model starts 161, initializes the module 2B clocks and counters [set to zero] 162, and adds a stored value from module 2A 163. The delivery vehicle is moved to the marshalling area 164, cargo is loaded onto the delivery vehicle 165, and the cargo is lashed and secured 166. Then the delivery vehicle is readied for return to the ship 167.

[0096] The loaded delivery vehicle is transferred from ashore to the designated ship 168, cargo is unlashed 169, and unloaded 170. The model then determines if the sea delivery of the cargo is complete 171. If not 172, at block 174 the sea vehicle returns to shore and the model 175 returns to block 164. Upon completion of the delivery, the sea vehicles time clocks are stopped 176 and the sea vehicles are moved to a storage location on the ship 177 and secured 178. Next the module determines if the air delivery of cargo is complete 179. If not 180, the air vehicle is returned to shore and the process is repeated 183.

[0097] Upon completion, the air vehicles time clocks are stopped 184, and the air vehicles are moved to a storage location on the ship 185 and secured 186. The sea and air delivery clocks are totaled 187, and the clock data is stored 188. Reports are generated 189 as required by either: 1) a print to screen or 2) save to disk operation, and the process ends 190.

[0098] FIG. 6 shows the operation of Multiple Mission Planning and Support Analysis. In FIG. 6, the model starts 201, initializes clocks and counters [set to zero] 202, and identifies the type of mission/operation [e.g. planned or contingency] 203. A Mission Name/Number is entered 204 and mission requirements are identified 205. Resources needed to support the mission are identified 206, and requested from the sea base 206. The model determines if the resources are available 208. If yes 209, weather conditions 211 and sea states 212 are entered. The transportation mix [sea vehicles and air vehicle] is identified 213 and modules IA & IB are started [as required]. Supplies, project availability, coordination and control of the delivery of supplies to the forces operating ashore are tracked. The model determines if resources are consumable or repairable 216.

[0099] The model determines if resources are available at an advanced base 219. If yes, resources are obtained from the advanced base 221. If not, resources are requisitioned from the Continental United States (CONUS) via a supply chain. Resources are sent to the

Sea Base 222, and the time to deliver the resources to the Sea Base is projected 223.

[0100] The model determines if more resources needed to support current mission 224. If yes 225, the process returns to block 207, if not 226, Goto 234. The model determines if there are any additional missions/operations 227. If yes 228, the process returns to block 203. The model determines if there are any resources in for repair 230. If yes, the resources are repaired 232, and a projected time when the resources will be available for use is determined 233. Then the model goes to block 224. Upon completion 234, the current mission/operation's counters and clocks are stopped, and the current mission/operation's clock and counter information is stored 235. Then the model goes to block 227. Reports are generated 237 as required by using either: 1) a print to screen or 2) save to disk operation, and the process ends 238.

[0101] The unique modular design of the SLAT allows for additional modules to model new or future requirements for the Sea Base concept. The SLAT can provide authorized users with the capability to access the SLAT anywhere there is secure internet access, and conduct analyses of multiple missions in terms of deployment scenarios and capability to support identified missions in an expeditious manner.

[0102] FIG. 7 is a block diagram illustrating the operation the invention. FIG. 7 shows the use of the SLAT to conduct "what-if" analyses to ascertain the impact, if any, when multiple missions occur, be they planned or contingency in nature. Blocks 250 and 252 show the various steps and parameters that can be used to model a mission. For each mission, requests for resources are made to the sea base 254. Blocks 256, 258 and 260 show that the model checks to determine if the requested resources are available. If not, failed items can be repaired (block 262) or the supply chain can be replenished (block 264). To replenish the supply chain, the resources can be procured from, for example, an advanced base 266 or the continental United States 268.

[0103] The SLAT has a flexible structure so that components can be easily changed or added, both during the development process and during simulation runs. The impact of dynamic events such as weather and/or sea states can be assessed. Performance factors for the events such as load points of the cargo, operational readiness rates, mean time to repair the handling equipment and repairable resources, can be included in the simulation. In addition, animation can be used to tracks cargo and to identify potential bottlenecks and anomalies in a cargo transfer process.

[0104] This invention provides a simulation used to model a supply chain process including activities involved in introducing new resources and the delivery of required resources from within a sea base. The supply chain process identifies consumables required

and projected alternative sources of supply from an advanced base or the continental United States.

[0105] Model mission requirements are represented by input data and various milestones to be achieved in order to move from one activity to another. Resource and usage rates are addressed, along with mission timing constraints and timeline requirements, to create and manage mission support plans during the simulation.

[0106] The model defines a sequence of operations and identifies precedence constraints representing complex processes. Constraint driven alternative sequences can be provided. The model supports planning for complex and multiple missions with all decisions made to satisfy specific missions/operations.

[0107] Repairable resources can be tracked as being available or in for repair, in terms of quantities and the projected time to be restored to a serviceable condition. The resource model describes the efficient use of resources over time and the use of multiple repairable resources, and determines when resource maintenance should be planned.

[0108] The model includes the capability to store data relative to process capabilities such as clocks and counters. Resource capacity available for use in satisfying mission/operation requirements is defined. Rules are provided for allocating resources to activities, and for controlling the flow of material between activities. The model can also identify and store information about available resources and the resources used in the support of mission objectives.

[0109] While the invention has been described in terms of several embodiments, it will be apparent to those skilled in the art that various changes can be made to the disclosed embodiments without departing from the scope of the invention as set forth in the following claims.